From jayk123 at hotmail.com Thu May 1 04:00:30 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 1 May 2008 02:00:30 +0000 Subject: [M3devel] tinderbox Message-ID: PPC_DARWIN: 6551 -> archiving libpatternmatching.a6552 Undefined symbols:6553 "_GlobTree__MatchTest", referenced from:6554 _L_1 in GlobTree.mo6555 _L_1 in GlobTree.moPerhaps fallout from my parse.c change? I'll look -- later. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu May 1 06:29:13 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 1 May 2008 00:29:13 -0400 Subject: [M3devel] tinderbox In-Reply-To: References: Message-ID: I wonder if we need TREE_USED(p) for proc_addr(p)? On Apr 30, 2008, at 10:00 PM, Jay wrote: > PPC_DARWIN: > > 6551 -> archiving libpatternmatching.a > 6552 Undefined symbols: > 6553 "_GlobTree__MatchTest", referenced from: > 6554 _L_1 in GlobTree.mo > 6555 _L_1 in GlobTree.mo > > > Perhaps fallout from my parse.c change? > I'll look -- later. > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu May 1 12:36:53 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 1 May 2008 10:36:53 +0000 Subject: [M3devel] tinderbox In-Reply-To: References: Message-ID: so far I can confirm: 1) "no" other solution known for AMD64_LINUX er, actually, public = (level != 0) should work but a few other solutions didn't work -- e.g. -fvisibility=hidden has no affect as expected 2) DECL_PRESERVE_P and TREE_USED both sound promising really, gcc is just a mess of hard to understand flags all over the place.. 3) I can reproduce the problem on PPC_DARWIN The "actual" uses of the functions have the names replaced by generated names -- ok, but bad for debugging The references are then from the module information...so much for dead stripping? I don't think those should be there. I don't know why the names end up generated, maybe because of static = 1? Not clear if static means "C file scope" or something else. I'll keep poking -- waiting for my PPC_DARWIN build of m3cg (hm, I must have cleaned out the previous). There is a nice optimization to my larger fix here, and it doesn't even go far enough, but for now checking (level != 0) will probably suffice. - Jay CC: m3devel at elegosoft.com From: hosking at cs.purdue.edu To: jayk123 at hotmail.com Subject: Re: [M3devel] tinderbox Date: Thu, 1 May 2008 00:29:13 -0400 I wonder if we need TREE_USED(p) for proc_addr(p)? On Apr 30, 2008, at 10:00 PM, Jay wrote:PPC_DARWIN: 6551 -> archiving libpatternmatching.a 6552 Undefined symbols: 6553 "_GlobTree__MatchTest", referenced from: 6554 _L_1 in GlobTree.mo 6555 _L_1 in GlobTree.mo Perhaps fallout from my parse.c change? I'll look -- later. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu May 1 22:55:06 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 01 May 2008 22:55:06 +0200 Subject: [M3devel] Popup Windows stalling regression tests on WinXP In-Reply-To: <495318.48565.qm@web27105.mail.ukl.yahoo.com> References: <495318.48565.qm@web27105.mail.ukl.yahoo.com> Message-ID: <20080501225506.7gxpp2zh34w8ccgs@mail.elegosoft.com> Quoting "Daniel Alejandro Benavides D." : > Hi all: > Olaf, I don't have the Win box here (just a Kubuntu one). But even > if you don't want to send the file, one can see the report file in > a window. Should be with two steps: The first click on the blue > label "Click here " in the first pop up window. That throws another > window with a label that you can click-on and actually see it > Well I found with google the instruction to disable that error pop up: > http://pcsupport.about.com/od/windowsxp/ht/disableerror.htm > I hope this helps to you. I now tried that, within a new VM (Win4BSD), and the tests ran until p204, and then crashed (without popup window, which is good). When I got home though, and had a look at the state of things, I had about ten seconds before the VM rebootet :-( So there's no more information right now; it seems that I'll have to run this test within a debugger. 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 jayk123 at hotmail.com Thu May 1 23:57:30 2008 From: jayk123 at hotmail.com (Jay) Date: Thu, 1 May 2008 21:57:30 +0000 Subject: [M3devel] Popup Windows stalling regression tests on WinXP In-Reply-To: <20080501225506.7gxpp2zh34w8ccgs@mail.elegosoft.com> References: <495318.48565.qm@web27105.mail.ukl.yahoo.com> <20080501225506.7gxpp2zh34w8ccgs@mail.elegosoft.com> Message-ID: Watch m3commit more closely :) -- the popup should be gone. You shouldn't have to twiddle any settings. Admittedly, my testing was on AMD64 XP, which is really Server 2003, therefore could vary much from x86 XP. I can try on x86 XP later (as in a day or two). But really, based on the code before and after, I think it is gone everywhere. - Jay > Date: Thu, 1 May 2008 22:55:06 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Popup Windows stalling regression tests on WinXP > > Quoting "Daniel Alejandro Benavides D." : > > > Hi all: > > Olaf, I don't have the Win box here (just a Kubuntu one). But even > > if you don't want to send the file, one can see the report file in > > a window. Should be with two steps: The first click on the blue > > label "Click here " in the first pop up window. That throws another > > window with a label that you can click-on and actually see it > > Well I found with google the instruction to disable that error pop up: > > http://pcsupport.about.com/od/windowsxp/ht/disableerror.htm > > I hope this helps to you. > > I now tried that, within a new VM (Win4BSD), and the tests ran > until p204, and then crashed (without popup window, which is good). > When I got home though, and had a look at the state of things, I had > about ten seconds before the VM rebootet :-( > > So there's no more information right now; it seems that I'll have to run > this test within a debugger. > > 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 jayk123 at hotmail.com Fri May 2 11:33:50 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 2 May 2008 09:33:50 +0000 Subject: [M3devel] in search of decent editor for Mac/Linux? In-Reply-To: <20080502090445.4496E10D495A@birch.elegosoft.com> References: <20080502090445.4496E10D495A@birch.elegosoft.com> Message-ID: Does anyone know of an IDE or editor on Linux or Mac OS Xwith a find-in-files feature anywhere nearly as goodas Visual C++ 5.0? I have tried a bunch and they have all been disappointing. It is very frustrating. Monodevelop comes close, but it won't open .m3 files as text. KDevelop -- can't navigate the results with the keyboard. I would prefer file path on every line, but ok I guess. X Code -- no find-in-files feature at all that I could find! NetBeans -- I forget, will have to try again, but I believe I was disappointed. Eclipse -- ditto Komodo -- promising, will have to try some more I think maybe only forward nav through results, but ok will have to see what the cost is JEdit -- I think it was this one, showed no results until done. Results should appear as they are found. Mac TextWrangler -- way too hard to specify directories to search in as I recall, I forget if has keyboard nav. MPW -- never seemed much good at all, despite avid following; doesn't run on current processors or operating systems, but it still works on mine I'll have to again try: NetBeans, Eclipse, Komodo, CodeWarrior, SlickEdit, search for other commercial ones. Though commercial ones won't tend to run on PPC_LINUX. vi and emacs are not under consideration.I have tried them each many times and they are alwaysvery disappointing. A really good file.open dialog would be nice too. KDevelop is annoying in that it often beeps an error if I type a directory -- to go to it. It is case sensitive. All the file.open dialogs I have seen on the Mac stink. What do people use to actually be productive?Everything I've tried hasn't come close to Visual C++ 5.0. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri May 2 15:28:24 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 02 May 2008 15:28:24 +0200 Subject: [M3devel] Popup Windows stalling regression tests on WinXP In-Reply-To: References: <495318.48565.qm@web27105.mail.ukl.yahoo.com> <20080501225506.7gxpp2zh34w8ccgs@mail.elegosoft.com> Message-ID: <20080502152824.ltfkpvoy88cg0gc0@mail.elegosoft.com> Quoting Jay : > Watch m3commit more closely :) -- the popup should be gone. You > shouldn't have to twiddle any settings. > Admittedly, my testing was on AMD64 XP, which is really Server 2003, > therefore could vary much from x86 XP. > I can try on x86 XP later (as in a day or two). > But really, based on the code before and after, I think it is gone > everywhere. Attached are my current results from NT386 m3tests. The popup is gone, but the tests terminate at p204: --- p204 --- IP address initializers cd ..\src\p2\p204 && cm3 -build -silent >NT386\stdout.build 2>NT386\stderr.build "h:\work\cm3\m3-sys\m3tests\src\m3makefile", line 248: quake runtime error: exit 1: cd ..\src\p2\p204 && cm3 -build -silent >NT386\stdout.build 2>NT386\stderr.build --procedure-- -line- -file--- exec -- run_test 248 h:\work\cm3\m3-sys\m3tests\src\m3makefile p_test 292 h:\work\cm3\m3-sys\m3tests\src\m3makefile include_dir 506 h:\work\cm3\m3-sys\m3tests\src\m3makefile 6 h:\work\cm3\m3-sys\m3tests\NT386\m3make.args Fatal Error: package build failed Not all tests in red are actually errors, as paths have changed and expected results need to be adapted. 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 jayk123 at hotmail.com Fri May 2 20:57:56 2008 From: jayk123 at hotmail.com (Jay) Date: Fri, 2 May 2008 18:57:56 +0000 Subject: [M3devel] Popup Windows stalling regression tests on WinXP In-Reply-To: <20080502152824.ltfkpvoy88cg0gc0@mail.elegosoft.com> References: <495318.48565.qm@web27105.mail.ukl.yahoo.com> <20080501225506.7gxpp2zh34w8ccgs@mail.elegosoft.com> <20080502152824.ltfkpvoy88cg0gc0@mail.elegosoft.com> Message-ID: >but the tests terminate at p204: fixed< exec("cm3") > try_exec("cm3") oh, maybe there had a minus sign before? I'll check.. -Jay > Date: Fri, 2 May 2008 15:28:24 +0200> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: RE: [M3devel] Popup Windows stalling regression tests on WinXP> > Quoting Jay :> > > Watch m3commit more closely :) -- the popup should be gone. You > > shouldn't have to twiddle any settings.> > Admittedly, my testing was on AMD64 XP, which is really Server 2003, > > therefore could vary much from x86 XP.> > I can try on x86 XP later (as in a day or two).> > But really, based on the code before and after, I think it is gone > > everywhere.> > Attached are my current results from NT386 m3tests. The popup is gone,> but the tests terminate at p204:> > --- p204 --- IP address initializers> cd ..\src\p2\p204 && cm3 -build -silent >NT386\stdout.build > 2>NT386\stderr.build> "h:\work\cm3\m3-sys\m3tests\src\m3makefile", line 248: quake runtime > error: exit 1: cd ..\src\p2\p204 && cm3 -build -silent > >NT386\stdout.build 2>NT386\stderr.build> > --procedure-- -line- -file---> exec -- > run_test 248 h:\work\cm3\m3-sys\m3tests\src\m3makefile> p_test 292 h:\work\cm3\m3-sys\m3tests\src\m3makefile> include_dir 506 h:\work\cm3\m3-sys\m3tests\src\m3makefile> 6 h:\work\cm3\m3-sys\m3tests\NT386\m3make.args> > Fatal Error: package build failed> > Not all tests in red are actually errors, as paths have changed> and expected results need to be adapted.> > 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 jayk123 at hotmail.com Sat May 3 10:11:35 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 3 May 2008 08:11:35 +0000 Subject: [M3devel] initializing with subarray(constant) In-Reply-To: <20080503080455.80F4D70DA16@birch.elegosoft.com> References: <20080503080455.80F4D70DA16@birch.elegosoft.com> Message-ID: Anyone understand this and know how to fix? Maybe the test passes with older/forked tools? I'll try it with 3.6 and maybe 4.1. It's very confusing that some of the "LV" and "LValue" functions take a parameter rhs : BOOLEAN. We end up with Variable.LoadLValue(p.obj) where p.obj is of type Constant.T The fix reveals understanding of the problem and makes the specific case work, but I think a better fix must exist. I think it'd be quite excellent for NARROW() failures to print the two types involved. Currently there isn't "room" for the data -- we call abort("narrow failed"). I put in some RTIO calls in IsSubtype to get a better handle on what is happening. Maybe m3gdb shows types well? I'm too impatient to build it so I make do with cdb and gdb.. - Jay > Date: Sat, 3 May 2008 10:04:55 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/05/03 10:04:55> > Modified files:> cm3/m3-sys/m3front/src/exprs/: QualifyExpr.m3 > cm3/m3-sys/m3front/src/values/: Constant.i3 Constant.m3 > cm3/m3-sys/m3tests/src/: m3makefile > > Log message:> enough to fix test p2/p205, but needs more attention as the fix> seems to be at the wrong abstraction level and not cover every case> > in particular, confusion around lvalues vs. non-lvalues> in particular, read the comments in QualifyExpr.m3> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat May 3 10:20:45 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 3 May 2008 08:20:45 +0000 Subject: [M3devel] FW: initializing with subarray(constant) In-Reply-To: <20080503080455.80F4D70DA16@birch.elegosoft.com> References: <20080503080455.80F4D70DA16@birch.elegosoft.com> Message-ID: truncated again.. From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: initializing with subarray(constant)Date: Sat, 3 May 2008 08:11:35 +0000 Anyone understand this and know how to fix? Maybe the test passes with older/forked tools?I'll try it with 3.6 and maybe 4.1. It's very confusing that some of the "LV" and "LValue" functions take a parameter rhs : BOOLEAN.We end up withVariable.LoadLValue(p.obj) where p.obj is of type Constant.T The fix reveals understanding of the problem and makes the specific case work, but I think a better fix must exist. I think it'd be quite excellent for NARROW() failures to print the two types involved.Currently there isn't "room" for the data -- we call abort("narrow failed").I put in some RTIO calls in IsSubtype to get a better handle on what is happening.Maybe m3gdb shows types well?I'm too impatient to build it so I make do with cdb and gdb.. - Jay > Date: Sat, 3 May 2008 10:04:55 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/05/03 10:04:55> > Modified files:> cm3/m3-sys/m3front/src/exprs/: QualifyExpr.m3 > cm3/m3-sys/m3front/src/values/: Constant.i3 Constant.m3 > cm3/m3-sys/m3tests/src/: m3makefile > > Log message:> enough to fix test p2/p205, but needs more attention as the fix> seems to be at the wrong abstraction level and not cover every case> > in particular, confusion around lvalues vs. non-lvalues> in particular, read the comments in QualifyExpr.m3> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat May 3 10:47:31 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 3 May 2008 08:47:31 +0000 Subject: [M3devel] FW: tests vs. long-ago language change? In-Reply-To: <20080503080455.80F4D70DA16@birch.elegosoft.com> References: <20080503080455.80F4D70DA16@birch.elegosoft.com> Message-ID: From: jayk123 at hotmail.comTo: jayk123 at hotmail.comSubject: tests vs. language changes?Date: Sat, 3 May 2008 08:45:59 +0000 Looking at tests p205, p206, p130p205 -- initialization involving subarray(constant open array)p206 -- initialization involving open arrayp130 -- use of type "UNSIGNED"I am led to believe that the language used to have an UNSIGNED type,but it was dropped long ago. p130 can just be thrown out.?Constant array constructors without index types couldarguably be considered fixed size with indices 0..n-1, butthey are in fact considered open, and this should remain asis.p206 is at least partly invalid. The language definition and, barely, tutorial point to this. I didn't check the green book. p205 suggests the same as p206 perhaps, perhaps thecompiler has this in mind, since there's a bunch of casesfor "types" of arrays -- open, fixed -- and the test goesdown an open path.Subarray.PrepLV is what I'm referring to in particular.The right fix for p205 might be for the case of "constant open"arrays to be implemented more like fixed arrays.In particular, avoid the call to CompileAddress.In particular, end up in case 3 instead of, I think 7.? I'll maybe look into Subarray.PrepLV later, after some other tests.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat May 3 13:24:24 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 3 May 2008 11:24:24 +0000 Subject: [M3devel] FW: NT386 jmpbuf size? In-Reply-To: <20080503111742.D803370DA16@birch.elegosoft.com> References: <20080503111742.D803370DA16@birch.elegosoft.com> Message-ID: Does anyone mind wasting an extra 32 bytes of stack in functions with a "try" on NT386? jmpbuf is declared to be 64 bytes, but if you read the assembly, _setjmp doesn't use it all, and _setjmp3 might. The difference is whether not a situation in which Modula-3 calls longjmp "past" C or C++ code, does the C __finally and C++ destructors run. Presently I think with Modula-3, not. Like, if Modula-3 passes some C/C++ a callback and the callback raises an exception and the C/C++ wanted to do some cleanup as the exception "goes by". I think it's always been this and I guess nobody noticed, so maybe leave it alone and shrink the jmpbuf back to 32 bytes from 64? Inflating from 8 to 13 also does get you some possible interop between NT386 and NT386GNU. - Jay > Date: Sat, 3 May 2008 13:17:42 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/05/03 13:17:42> > Modified files:> cm3/m3-sys/m3middle/src/: Target.m3 > > Log message:> fix and unify NT386 jmpbuf/setjmp> > it APPEARS jmpbuf was understated for Visual C++> though it was probably ok> it appears if you compile C/C++, the compiler generates a call> to _setjmp3, which indeed uses more of the declared-16 jmpbuf> but that if we call _setjmp directly, it only uses 8> > Cygwin was overstated because their setjmp.h> appears to confuse bytes and ints, it only uses 13.> > So unify the former 8 and 13 to 16.> > As well, Cygwin provides aliased setjmp and _setjmp, so> unify on _setjmp> > NOTE that using _setjmp3 for Visual C++ is probably desirable> but cross that bridge another time, perhaps we'll just stop> using setjmp entirely> > therefore making the three NT386 flavors much more similar> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat May 3 13:25:07 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 3 May 2008 11:25:07 +0000 Subject: [M3devel] FW: NT386 jmpbuf size? In-Reply-To: <20080503111742.D803370DA16@birch.elegosoft.com> References: <20080503111742.D803370DA16@birch.elegosoft.com> Message-ID: truncated again... From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: FW: NT386 jmpbuf size?Date: Sat, 3 May 2008 11:24:24 +0000 Does anyone mind wasting an extra 32 bytes of stack in functions with a "try" on NT386?jmpbuf is declared to be 64 bytes, but if you read the assembly, _setjmp doesn't use it all, and _setjmp3 might. The difference is whether not a situation in which Modula-3 calls longjmp "past" C or C++ code, does the C __finally and C++ destructors run.Presently I think with Modula-3, not.Like, if Modula-3 passes some C/C++ a callback and the callback raises an exception and the C/C++ wanted to do some cleanup as the exception "goes by". I think it's always been this and I guess nobody noticed, so maybe leave it alone and shrink the jmpbuf back to 32 bytes from 64? Inflating from 8 to 13 also does get you some possible interop between NT386 and NT386GNU. - Jay > Date: Sat, 3 May 2008 13:17:42 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/05/03 13:17:42> > Modified files:> cm3/m3-sys/m3middle/src/: Target.m3 > > Log message:> fix and unify NT386 jmpbuf/setjmp> > it APPEARS jmpbuf was understated for Visual C++> though it was probably ok> it appears if you compile C/C++, the compiler generates a call> to _setjmp3, which indeed uses more of the declared-16 jmpbuf> but that if we call _setjmp directly, it only uses 8> > Cygwin was overstated because their setjmp.h> appears to confuse bytes and ints, it only uses 13.> > So unify the former 8 and 13 to 16.> > As well, Cygwin provides aliased setjmp and _setjmp, so> unify on _setjmp> > NOTE that using _setjmp3 for Visual C++ is probably desirable> but cross that bridge another time, perhaps we'll just stop> using setjmp entirely> > therefore making the three NT386 flavors much more similar> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat May 3 15:33:12 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 3 May 2008 09:33:12 -0400 Subject: [M3devel] FW: initializing with subarray(constant) In-Reply-To: References: <20080503080455.80F4D70DA16@birch.elegosoft.com> Message-ID: This is on my list of things to do. I have some idea what the fix is and just need to go in and do it. Not enough time unfortunately. On May 3, 2008, at 4:20 AM, Jay wrote: > truncated again.. > > > > > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: initializing with subarray(constant) > Date: Sat, 3 May 2008 08:11:35 +0000 > > Anyone understand this and know how to fix? > > Maybe the test passes with older/forked tools? > I'll try it with 3.6 and maybe 4.1. > > It's very confusing that some of the "LV" and "LValue" functions > take a parameter rhs : BOOLEAN. > We end up with > Variable.LoadLValue(p.obj) where p.obj is of type Constant.T > > The fix reveals understanding of the problem and makes the specific > case work, but I think a better fix must exist. > > I think it'd be quite excellent for NARROW() failures to print the > two types involved. > Currently there isn't "room" for the data -- we call abort("narrow > failed"). > I put in some RTIO calls in IsSubtype to get a better handle on what > is happening. > Maybe m3gdb shows types well? > I'm too impatient to build it so I make do with cdb and gdb.. > > - Jay > > > > > Date: Sat, 3 May 2008 10:04:55 +0000 > > To: m3commit at elegosoft.com > > From: jkrell at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 08/05/03 10:04:55 > > > > Modified files: > > cm3/m3-sys/m3front/src/exprs/: QualifyExpr.m3 > > cm3/m3-sys/m3front/src/values/: Constant.i3 Constant.m3 > > cm3/m3-sys/m3tests/src/: m3makefile > > > > Log message: > > enough to fix test p2/p205, but needs more attention as the fix > > seems to be at the wrong abstraction level and not cover every case > > > > in particular, confusion around lvalues vs. non-lvalues > > in particular, read the comments in QualifyExpr.m3 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat May 3 16:13:00 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 03 May 2008 16:13:00 +0200 Subject: [M3devel] m3tests reporting broken? was: Re: more m3tests changes In-Reply-To: References: <20080502185151.B3DC110D4959@birch.elegosoft.com> Message-ID: <20080503161300.3krg8bcfv0oo8w4k@mail.elegosoft.com> Quoting Jay : > Olaf, disable these for nt386? Without having had a close look what the tests are about, I'd say no; I'd rather have target-specific overrides for expected values. I'd thought about it at least, but didn't get round to implement it. Something like if sdtdout.build.TARGET exists use that on TARGET. BTW, almost all tests have turned to green in the tinderbox; as I don't think somebody has fixed the underlying issues, one of us must have broken the reporting :-/ Olaf > - Jay > >> Date: Fri, 2 May 2008 20:51:51 +0000> To: m3commit at elegosoft.com> >> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > >> CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/05/02 20:51:51> > >> Modified files:> cm3/m3-sys/m3tests/src/e0/e029/: stderr.build >> stdout.build > cm3/m3-sys/m3tests/src/p0/p004/: stdout.build > >> cm3/m3-sys/m3tests/src/p0/p051/: stdout.build > >> cm3/m3-sys/m3tests/src/p2/p204/: stderr.build stdout.build > >> cm3/m3-sys/m3tests/src/p2/p205/: stderr.build > >> cm3/m3-sys/m3tests/src/p2/p207/: stdout.build > > Log message:> >> where posix and win32 vary for now, take posix, from ppc_darwin> -- 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 jayk123 at hotmail.com Sat May 3 16:37:04 2008 From: jayk123 at hotmail.com (Jay) Date: Sat, 3 May 2008 14:37:04 +0000 Subject: [M3devel] m3tests reporting broken? was: Re: more m3tests changes In-Reply-To: <20080503161300.3krg8bcfv0oo8w4k@mail.elegosoft.com> References: <20080502185151.B3DC110D4959@birch.elegosoft.com> <20080503161300.3krg8bcfv0oo8w4k@mail.elegosoft.com> Message-ID: Which is all green? Tinderbox and test status are both mixed. I have to go for a bit. Maybe more later, but currently I don't know what's recently broken, only longer term problems with a small number of tests. - Jay > Date: Sat, 3 May 2008 16:13:00 +0200> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: m3tests reporting broken? was: Re: more m3tests changes> > Quoting Jay :> > > Olaf, disable these for nt386?> > Without having had a close look what the tests are about, I'd> say no; I'd rather have target-specific overrides for> expected values. I'd thought about it at least, but didn't get> round to implement it. Something like if sdtdout.build.TARGET> exists use that on TARGET.> > BTW, almost all tests have turned to green in the tinderbox;> as I don't think somebody has fixed the underlying issues,> one of us must have broken the reporting :-/> > Olaf> > > - Jay> >> >> Date: Fri, 2 May 2008 20:51:51 +0000> To: m3commit at elegosoft.com> > >> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > > >> CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/05/02 20:51:51> > > >> Modified files:> cm3/m3-sys/m3tests/src/e0/e029/: stderr.build > >> stdout.build > cm3/m3-sys/m3tests/src/p0/p004/: stdout.build > > >> cm3/m3-sys/m3tests/src/p0/p051/: stdout.build > > >> cm3/m3-sys/m3tests/src/p2/p204/: stderr.build stdout.build > > >> cm3/m3-sys/m3tests/src/p2/p205/: stderr.build > > >> cm3/m3-sys/m3tests/src/p2/p207/: stdout.build > > Log message:> > >> where posix and win32 vary for now, take posix, from ppc_darwin>> -- > 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 Sat May 3 16:55:51 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 03 May 2008 16:55:51 +0200 Subject: [M3devel] m3tests reporting broken? was: Re: more m3tests changes In-Reply-To: References: <20080502185151.B3DC110D4959@birch.elegosoft.com> <20080503161300.3krg8bcfv0oo8w4k@mail.elegosoft.com> Message-ID: <20080503165551.3qh7w25etcwkgk8c@mail.elegosoft.com> Quoting Jay : > Which is all green? Tinderbox and test status are both mixed. > I have to go for a bit. Maybe more later, but currently I don't know > what's recently broken, only longer term problems with a small > number of tests. All the release builds should be orange (and were until yesterday) as some of the tests fail. See one of http://tinderbox.elegosoft.com/tinderbox/cm3/status.html http://tinderbox.elegosoft.com/tinderbox/all_trees.panel.html http://tinderbox.elegosoft.com/tinderbox/all_trees.express.html http://tinderbox.elegosoft.com/tinderbox/all_trees.quickparse.html The lastok columns are more or less standalone, they are usually green and turn to red in case of an incompatible runtime change (which is intended and OK). The release-build columns combine bulding of cm3 from the last release and running all available tests; as some of those usually fail, they are really not expected to be green, but orange, which means: build OK, tests failed. 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 May 3 17:00:47 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 03 May 2008 17:00:47 +0200 Subject: [M3devel] FW: NT386 jmpbuf size? In-Reply-To: References: <20080503111742.D803370DA16@birch.elegosoft.com> Message-ID: <20080503170047.ocn9oj5li8gscg88@mail.elegosoft.com> If there is a chance that more bytes are actually used under special circumstances, I'd vote to make the jmp_buf large enough to avoid memory corruption. I'm not sure if the extra bytes will have performance impacts on thread switching, but I think a special instruction could be used for copying them so that it should be not much difference. I'm no expert on the Intel processors though... Quoting Jay : > truncated again... > > From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: FW: NT386 > jmpbuf size?Date: Sat, 3 May 2008 11:24:24 +0000 > > > Does anyone mind wasting an extra 32 bytes of stack in functions > with a "try" on NT386?jmpbuf is declared to be 64 bytes, but if you > read the assembly, _setjmp doesn't use it all, and _setjmp3 might. > The difference is whether not a situation in which Modula-3 calls > longjmp "past" C or C++ code, does the C __finally and C++ > destructors run.Presently I think with Modula-3, not.Like, if > Modula-3 passes some C/C++ a callback and the callback raises an > exception and the C/C++ wanted to do some cleanup as the exception > "goes by". I think it's always been this and I guess nobody noticed, > so maybe leave it alone and shrink the jmpbuf back to 32 bytes from > 64? Inflating from 8 to 13 also does get you some possible interop > between NT386 and NT386GNU. - 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 jayk123 at hotmail.com Sun May 4 06:02:25 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 4 May 2008 04:02:25 +0000 Subject: [M3devel] test e020? Message-ID: This is half just a sanity check that I am restoring my damage properly. These can't both be right, right? http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3tests/src/e0/e020/stdout.build?rev=1.2;content-type=text%2Fplain Fatal Error: package build failed http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3tests/src/e0/e020/stderr.pgm?rev=1.1;content-type=text%2Fplain ****** illegal cycle in super types:*** child = [0x10000294 _t0xd6319321 typecode= 0 Main.W]*** parent = [0x1000022c _t0x5a31ef26 typecode= 0 Main.V]*** parent = [0x10000294 _t0xd6319321 typecode= 0 Main.W]*** ****** runtime error:*** unable to initialize runtime types*** Presumably neither is ideal, it should fail to build, with a better error message, but the currentbehavior is worse than both, it fails at runtime with what I suspect is stack overflow frominfinite recursion. C:\dev2\cm3\m3-sys\m3tests\src\e0\e020>NT386\pgm.exe ****** runtime error:*** A runtime error occurred.*** pc = 0x1002050b = FindSlot + 0xb in ..\src\runtime\common\RTType.m3*** Stack trace: FP PC Procedure--------- --------- ------------------------------- 0x32fec 0x1002679e SystemError + 0x66 in ..\src\runtime\NT386\RTSignal.m3 0x3301c 0x1002050b FindSlot + 0xb in ..\src\runtime\common\RTType.m3 0x3304c 0x1001f430 FindType + 0x28 in ..\src\runtime\common\RTType.m3 0x33088 0x1001f901 FinishTypecell + 0x67 in ..\src\runtime\common\RTType.m3 0x330b4 0x1001f489 FindType + 0x81 in ..\src\runtime\common\RTType.m3 0x330f0 0x1001f901 FinishTypecell + 0x67 in ..\src\runtime\common\RTType.m3 0x3311c 0x1001f489 FindType + 0x81 in ..\src\runtime\common\RTType.m3 0x33158 0x1001f901 FinishTypecell + 0x67 in ..\src\runtime\common\RTType.m3 0x33184 0x1001f489 FindType + 0x81 in ..\src\runtime\common\RTType.m3 0x331c0 0x1001f901 FinishTypecell + 0x67 in ..\src\runtime\common\RTType.m3......... ......... ... more frames ... agreed? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun May 4 08:27:00 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 4 May 2008 06:27:00 +0000 Subject: [M3devel] FW: NT386 jmpbuf size? In-Reply-To: <20080503170047.ocn9oj5li8gscg88@mail.elegosoft.com> References: <20080503111742.D803370DA16@birch.elegosoft.com> <20080503170047.ocn9oj5li8gscg88@mail.elegosoft.com> Message-ID: I BELIEVE: It is statically knowable: msvcrt _setjmp uses 8 words msvcrt _setjmp3 uses 16 cygwin uses I think 13 -- their header is just wrong by a factor of 4 You can tell from a mix of disassembly and source -- disassembly for msvcrt, disassembly and source for cygwin. It isn't runtime variables that make the difference. (well, the 16 case might sometimes shrink, it appears) What is less clear is if _setjmp or _setjmp3 should be used. It appears that any use of setjmp in C or C++ uses _setjmp3. The difference appears to be whether or not the generally expected interaction with C __finally and C++ destructors and exception handling occurs. "generally expected' but also "generally unknown". One might argue that if C/C++ can afford the extra 32 bytes, then so can Modula-3 BUT C/C++ have MUCH more efficient exception handling mechanisms available and so setjmp is much less used there. They get by with around 3 words for a frame with exception handling on x86, and with zero overheard everywhere else. The C/C++ behavior might also be affected by command line options. I'd have to experiment more.. To clarify, imagine Modula-3 gave a callback function to some C++ and that C++ has a local with a destructor, and the Modula-3 raises an exception. Does the C++ destructor run or not? With _setjmp probably not, with _setjmp3 probably. Similarly, imagine some C++ gives some Modula-3 a callback and the C++ raises an exception. Do the Modula-3 FINALLY blocks run? Similar dilemna really on all platforms. There relatively recently an ABI for C++ exception handling that maybe Modula-3 should use. - Jay > Date: Sat, 3 May 2008 17:00:47 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] FW: NT386 jmpbuf size?> > If there is a chance that more bytes are actually used under> special circumstances, I'd vote to make the jmp_buf large enough> to avoid memory corruption. I'm not sure if the extra bytes> will have performance impacts on thread switching, but I think> a special instruction could be used for copying them so that> it should be not much difference. I'm no expert on the Intel> processors though...> > Quoting Jay :> > > truncated again...> >> > From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: FW: NT386 > > jmpbuf size?Date: Sat, 3 May 2008 11:24:24 +0000> >> >> > Does anyone mind wasting an extra 32 bytes of stack in functions > > with a "try" on NT386?jmpbuf is declared to be 64 bytes, but if you > > read the assembly, _setjmp doesn't use it all, and _setjmp3 might. > > The difference is whether not a situation in which Modula-3 calls > > longjmp "past" C or C++ code, does the C __finally and C++ > > destructors run.Presently I think with Modula-3, not.Like, if > > Modula-3 passes some C/C++ a callback and the callback raises an > > exception and the C/C++ wanted to do some cleanup as the exception > > "goes by". I think it's always been this and I guess nobody noticed, > > so maybe leave it alone and shrink the jmpbuf back to 32 bytes from > > 64? Inflating from 8 to 13 also does get you some possible interop > > between NT386 and NT386GNU. - 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 jayk123 at hotmail.com Sun May 4 13:17:23 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 4 May 2008 11:17:23 +0000 Subject: [M3devel] order of warnings, or even to have any? In-Reply-To: <20080503170047.ocn9oj5li8gscg88@mail.elegosoft.com> References: <20080503111742.D803370DA16@birch.elegosoft.com> <20080503170047.ocn9oj5li8gscg88@mail.elegosoft.com> Message-ID: C:\dev2\cm3\m3-sys\m3tests\src\p0\p004>cm3--- building in NT386 --- new source -> compiling Main.m3"..\Main.m3", line 35: warning: exception is never raised: Main.e"..\Main.m3", line 9: warning: exception is never raised: "..\Main.m3", line 59: warning: unreachable statement"..\Main.m3", line 68: warning: unreachable statement"..\Main.m3", line 71: warning: unreachable statement"..\Main.m3", line 82: warning: unreachable statement"..\Main.m3", line 86: warning: unreachable statement"..\Main.m3", line 64: warning: unreachable statement8 warnings encountered -> linking pgm.exelink @_m3responsefile0.txt 2>&1 > pgm.lstmt /nologo /manifest pgm.exe.manifest /outputresource:pgm.exe;1.\pgm.exe >stdout.pgm.raw 2>stderr.pgm.raw Does the order of the warnings matter? Does the test even care if they are printed? The expected output and the actual output are in a different order. Neither are in order by line number, though the expected output is closer. The order is consistent on all platforms? No. LINUXLIBC6 and NT386 output in a different order. This doesn't seem all that important.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun May 4 13:46:25 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 04 May 2008 13:46:25 +0200 Subject: [M3devel] FW: NT386 jmpbuf size? In-Reply-To: References: <20080503111742.D803370DA16@birch.elegosoft.com> <20080503170047.ocn9oj5li8gscg88@mail.elegosoft.com> Message-ID: <20080504134625.az0c3vdkgs8gwsgk@mail.elegosoft.com> Quoting Jay : > I BELIEVE: > It is statically knowable: > msvcrt _setjmp uses 8 words > msvcrt _setjmp3 uses 16 > cygwin uses I think 13 -- their header is just wrong by a factor of 4 > You can tell from a mix of disassembly and source -- disassembly > for msvcrt, disassembly and source for cygwin. > > It isn't runtime variables that make the difference. > (well, the 16 case might sometimes shrink, it appears) > > What is less clear is if _setjmp or _setjmp3 should be used. > It appears that any use of setjmp in C or C++ uses _setjmp3. > > The difference appears to be whether or not the generally expected > interaction with C __finally and C++ destructors and exception > handling occurs. > "generally expected' but also "generally unknown". > > One might argue that if C/C++ can afford the extra 32 bytes, then so > can Modula-3 BUT C/C++ have MUCH more efficient exception handling > mechanisms available and so setjmp is much less used there. They get > by with around 3 words for a frame with exception handling on x86, > and with zero overheard everywhere else. > > The C/C++ behavior might also be affected by command line options. > I'd have to experiment more.. > > To clarify, imagine Modula-3 gave a callback function to some C++ > and that C++ has a local with a destructor, and the Modula-3 raises > an exception. > Does the C++ destructor run or not? > With _setjmp probably not, with _setjmp3 probably. IMO it should. > Similarly, imagine some C++ gives some Modula-3 a callback and the > C++ raises an exception. > Do the Modula-3 FINALLY blocks run? Dito. > Similar dilemna really on all platforms. > There relatively recently an ABI for C++ exception handling that > maybe Modula-3 should use. I think we should start on the safe side and try to optimize later if needed. So I'd vote for 16 bytes and use of _setjmp3. 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 May 4 13:49:37 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 04 May 2008 13:49:37 +0200 Subject: [M3devel] order of warnings, or even to have any? In-Reply-To: References: <20080503111742.D803370DA16@birch.elegosoft.com> <20080503170047.ocn9oj5li8gscg88@mail.elegosoft.com> Message-ID: <20080504134937.ejznr1mcqo0sw0ck@mail.elegosoft.com> Quoting Jay : > C:\dev2\cm3\m3-sys\m3tests\src\p0\p004>cm3--- building in NT386 --- > new source -> compiling Main.m3"..\Main.m3", line 35: warning: > exception is never raised: Main.e"..\Main.m3", line 9: warning: > exception is never raised: "..\Main.m3", line 59: warning: > unreachable statement"..\Main.m3", line 68: warning: unreachable > statement"..\Main.m3", line 71: warning: unreachable > statement"..\Main.m3", line 82: warning: unreachable > statement"..\Main.m3", line 86: warning: unreachable > statement"..\Main.m3", line 64: warning: unreachable statement8 > warnings encountered -> linking pgm.exelink @_m3responsefile0.txt > 2>&1 > pgm.lstmt /nologo /manifest pgm.exe.manifest > /outputresource:pgm.exe;1.\pgm.exe >stdout.pgm.raw 2>stderr.pgm.raw > > Does the order of the warnings matter? > Does the test even care if they are printed? > The expected output and the actual output are in a different order. > Neither are in order by line number, though the expected output is closer. > The order is consistent on all platforms? > No. LINUXLIBC6 and NT386 output in a different order. > This doesn't seem all that important.. I had noticed that, too, and postponed it at not important (enough) now to look into, though it would be interesting _why_ the error output is different between platforms. If there is a reason for it and it cannot be fixed easily within the compiler, this would be one case for a target-specific expect file. 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 jayk123 at hotmail.com Sun May 4 15:06:29 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 4 May 2008 13:06:29 +0000 Subject: [M3devel] tinderbox diff direction reversed Message-ID: fyi, I reversed the diff direction in m3tests. It seems more natural to me to diff expected actual and see what changed. Obviously it's not a huge difference (!), it works either way and no diff is the goal, but in case anyone was used to the other way or insists on it. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun May 4 15:19:30 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 04 May 2008 15:19:30 +0200 Subject: [M3devel] tinderbox diff direction reversed In-Reply-To: References: Message-ID: <20080504151930.mwlopiv400s4c8ok@mail.elegosoft.com> Quoting Jay : > fyi, I reversed the diff direction in m3tests. > It seems more natural to me to > diff expected actual > and see what changed. > Obviously it's not a huge difference (!), it works either way and no > diff is the goal, but in case anyone was used to the other way or > insists on it. That's OK. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sun May 4 15:19:48 2008 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 4 May 2008 09:19:48 -0400 Subject: [M3devel] order of warnings, or even to have any? In-Reply-To: References: <20080503111742.D803370DA16@birch.elegosoft.com> <20080503170047.ocn9oj5li8gscg88@mail.elegosoft.com> Message-ID: Why the difference on different targets? Antony Hosking | Associate 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 May 4, 2008, at 7:17 AM, Jay wrote: > C:\dev2\cm3\m3-sys\m3tests\src\p0\p004>cm3 > --- building in NT386 --- > new source -> compiling Main.m3 > "..\Main.m3", line 35: warning: exception is never raised: Main.e > "..\Main.m3", line 9: warning: exception is never raised: > "..\Main.m3", line 59: warning: unreachable statement > "..\Main.m3", line 68: warning: unreachable statement > "..\Main.m3", line 71: warning: unreachable statement > "..\Main.m3", line 82: warning: unreachable statement > "..\Main.m3", line 86: warning: unreachable statement > "..\Main.m3", line 64: warning: unreachable statement > 8 warnings encountered > -> linking pgm.exe > link @_m3responsefile0.txt 2>&1 > pgm.lst > mt /nologo /manifest pgm.exe.manifest /outputresource:pgm.exe;1 > .\pgm.exe >stdout.pgm.raw 2>stderr.pgm.raw > > > Does the order of the warnings matter? > Does the test even care if they are printed? > The expected output and the actual output are in a different order. > Neither are in order by line number, though the expected output is > closer. > The order is consistent on all platforms? > No. LINUXLIBC6 and NT386 output in a different order. > This doesn't seem all that important.. > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun May 4 15:24:58 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 4 May 2008 13:24:58 +0000 Subject: [M3devel] order of warnings, or even to have any? In-Reply-To: References: <20080503111742.D803370DA16@birch.elegosoft.com> <20080503170047.ocn9oj5li8gscg88@mail.elegosoft.com> Message-ID: not yet known.. CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] order of warnings, or even to have any?Date: Sun, 4 May 2008 09:19:48 -0400Why the difference on different targets? Antony Hosking | Associate 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 May 4, 2008, at 7:17 AM, Jay wrote: C:\dev2\cm3\m3-sys\m3tests\src\p0\p004>cm3--- building in NT386 ---new source -> compiling Main.m3"..\Main.m3", line 35: warning: exception is never raised: Main.e"..\Main.m3", line 9: warning: exception is never raised: "..\Main.m3", line 59: warning: unreachable statement"..\Main.m3", line 68: warning: unreachable statement"..\Main.m3", line 71: warning: unreachable statement"..\Main.m3", line 82: warning: unreachable statement"..\Main.m3", line 86: warning: unreachable statement"..\Main.m3", line 64: warning: unreachable statement8 warnings encountered -> linking pgm.exelink @_m3responsefile0.txt 2>&1 > pgm.lstmt /nologo /manifest pgm.exe.manifest /outputresource:pgm.exe;1.\pgm.exe >stdout.pgm.raw 2>stderr.pgm.raw Does the order of the warnings matter?Does the test even care if they are printed?The expected output and the actual output are in a different order.Neither are in order by line number, though the expected output is closer.The order is consistent on all platforms?No. LINUXLIBC6 and NT386 output in a different order.This doesn't seem all that important.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun May 4 15:30:40 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 04 May 2008 15:30:40 +0200 Subject: [M3devel] Tinderbox tests on NT386 Message-ID: <20080504153040.6jvrkwlkms80c8wc@mail.elegosoft.com> In case anybody wonders about http://www.opencm3.net/m3tests/m3tests-NT386-2008-05-03-22-37-30.html and following reports, I'm currently trying to run the m3tests on NT386 in an older version to get a usable reference for the current problems. There have been so many changes that I'm unable to keep up with them, and some things seem to be broken. Except for the problems in m3tests, the rest of the tinderbox regression test framework seems to be working now for regular regression tests on Windows XP with Cygwin. Some initialization scripts are needed for running them, but that was to be expected. The m3tests reports for the last two days for all target platforms in the tinderbox are not correct (at least, if they show no errors); there have been some structural changes and more things need to be adapted. Jay Krell is working on it. 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 jayk123 at hotmail.com Sun May 4 16:17:28 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 4 May 2008 14:17:28 +0000 Subject: [M3devel] Tinderbox tests on NT386 In-Reply-To: <20080504153040.6jvrkwlkms80c8wc@mail.elegosoft.com> References: <20080504153040.6jvrkwlkms80c8wc@mail.elegosoft.com> Message-ID: Here is a QUICK rundown. p004 I /assume/ this is the same on all platforms but didn't check p051 extra print out when building specific to NT386, fixed, but at great loss of diagnosability IF there are errors in compiling C code Specifically, given cl -nologo -c foo.c bar.cthe compiler printsfoo.cbar.c to the same channel as errors (stderr or stdout)So when running the tests, NT386.common has a hack to throwout all C compiler output. p116b floating point issue, probably same on all platformsp126 dittop172 dittop186 ditto p204 compiler bug I think this also fails on other platforms but obviously differently; needs investigation p205 was failing but I put in a fix and then Tony put in a better fix p206 I think this fails the same on all platforms, but I I think it behaves correctly and just update the std{out,err}.{pgm,build} files; since it is a compilation failure, it should be an 'e' instead of 'p', not a big deal I think p207 probably fall out from longint not being 64 bits probably should disable just for this platform r001 This test works in general but is a problem for the Tinderbox in general. LINUXLIBC6 and NT386 should be passing, but I think probably it should be turned off. In particular, the way programs exit when they fail an assertion and/or have an unhandled exception varies by platform, in terms of what they actually print. r002 needs investigation; I think it's an infinite recursion or just uses a lot of stack, and I THINK I saw it fail on other platforms r003 I hadn't looked at this AT ALL but probably the same as r001, except more interesting? There is a test that catches an assertion failure, maybe do that here? As well, there is the annoying idea of making per-platform std* files. Hard to maintain. r004 ditto -- since there are four of these, and potentially more, maybe worth coming up with something Something I considered, but rejected, back when I thought r001was the only one, is a runtime switch M3 at consistentAbort orsomesuch that will just cleanly exit(0) or exit(1) in these cases,and not print a callstack. I don't want to foul up thesystem TOO much for the sake of testing, but testabilityis an expected design goal... Again, this is an issue across platforms. LINUXLIBC6 seems to print something slightly differently every time you run these. Test.common has a gross workaround. The checked in std* files are from FreeBSD. e020 unknown so far e026 was a problem on all platforms and should be ok now; was a compiler bug, I fixed e029 unknown so far I think p209 and p210 are the most important currently.And then maybe e020, e029. I expect to be "out" all of Sunday. The Tinderbox SHOULD be OK now.Sorry... - Jay > Date: Sun, 4 May 2008 15:30:40 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] Tinderbox tests on NT386> > In case anybody wonders about> > http://www.opencm3.net/m3tests/m3tests-NT386-2008-05-03-22-37-30.html> > and following reports, I'm currently trying to run the m3tests on> NT386 in an older version to get a usable reference for the current> problems. There have been so many changes that I'm unable to keep> up with them, and some things seem to be broken.> > Except for the problems in m3tests, the rest of the tinderbox> regression test framework seems to be working now for regular> regression tests on Windows XP with Cygwin. Some initialization> scripts are needed for running them, but that was to be expected.> > The m3tests reports for the last two days for all target platforms> in the tinderbox are not correct (at least, if they show no errors);> there have been some structural changes and more things need to be> adapted. Jay Krell is working on it.> > 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 jayk123 at hotmail.com Sun May 4 16:22:57 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 4 May 2008 14:22:57 +0000 Subject: [M3devel] Tinderbox tests on NT386 In-Reply-To: References: <20080504153040.6jvrkwlkms80c8wc@mail.elegosoft.com> Message-ID: I'm also seeing lots of failures in p137 --- p137 --- bit insert and extract --- ../src/p1/p137/stderr.pgm 2008-05-04 00:10:01.925067200 -0700+++ ../src/p1/p137/NT386/stderr.pgm 2008-05-04 03:59:42.382247900 -0700@@ -1,3 +1,418 @@+************************ ERROR: 282863103 instead of 819734015+************************ ERROR: 14427647 instead of 819734015... lotsYou never saw that Olaf? I should have printed the test names below, it's too hard to read with just numbers.. Anyway, just looking busy I guess, no matter, we'll get around to them.. (And sorry about the Win32 bitmap stuff, I haven't forgotten...) Hm..maybe related? Older version of m3tests statically links to libm3/m3core but current version dynamically links. That'd be cool if it correlates -- if p137 and the bitmap stuff are the same problem. I'll go try p137 again both ways. - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Sun, 4 May 2008 14:17:28 +0000Subject: Re: [M3devel] Tinderbox tests on NT386 Here is a QUICK rundown.p004 I /assume/ this is the same on all platforms but didn't checkp051 extra print out when building specific to NT386, fixed, but at great loss of diagnosability IF there are errors in compiling C codeSpecifically, given cl -nologo -c foo.c bar.cthe compiler printsfoo.cbar.cto the same channel as errors (stderr or stdout)So when running the tests, NT386.common has a hack to throwout all C compiler output.p116b floating point issue, probably same on all platformsp126 dittop172 dittop186 dittop204 compiler bug I think this also fails on other platforms but obviously differently; needs investigationp205 was failing but I put in a fix and then Tony put in a better fix p206 I think this fails the same on all platforms, but I I think it behaves correctly and just update the std{out,err}.{pgm,build} files; since it is a compilation failure, it should be an 'e' instead of 'p', not a big deal I thinkp207 probably fall out from longint not being 64 bits probably should disable just for this platform r001 This test works in general but is a problem for the Tinderbox in general. LINUXLIBC6 and NT386 should be passing, but I think probably it should be turned off. In particular, the way programs exit when they fail an assertion and/or have an unhandled exception varies by platform, in terms of what they actually print.r002 needs investigation; I think it's an infinite recursion or just uses a lot of stack, and I THINK I saw it fail on other platforms r003 I hadn't looked at this AT ALL but probably the same as r001, except more interesting? There is a test that catches an assertion failure, maybe do that here? As well, there is the annoying idea of making per-platform std* files. Hard to maintain. r004 ditto -- since there are four of these, and potentially more, maybe worth coming up with somethingSomething I considered, but rejected, back when I thought r001was the only one, is a runtime switch M3 at consistentAbort orsomesuch that will just cleanly exit(0) or exit(1) in these cases,and not print a callstack. I don't want to foul up thesystem TOO much for the sake of testing, but testabilityis an expected design goal...Again, this is an issue across platforms. LINUXLIBC6 seems to print something slightly differently every time you run these. Test.common has a gross workaround. The checked in std* files are from FreeBSD.e020 unknown so fare026 was a problem on all platforms and should be ok now; was a compiler bug, I fixede029 unknown so farI think p209 and p210 are the most important currently.And then maybe e020, e029.I expect to be "out" all of Sunday.The Tinderbox SHOULD be OK now.Sorry... - Jay > Date: Sun, 4 May 2008 15:30:40 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] Tinderbox tests on NT386> > In case anybody wonders about> > http://www.opencm3.net/m3tests/m3tests-NT386-2008-05-03-22-37-30.html> > and following reports, I'm currently trying to run the m3tests on> NT386 in an older version to get a usable reference for the current> problems. There have been so many changes that I'm unable to keep> up with them, and some things seem to be broken.> > Except for the problems in m3tests, the rest of the tinderbox> regression test framework seems to be working now for regular> regression tests on Windows XP with Cygwin. Some initialization> scripts are needed for running them, but that was to be expected.> > The m3tests reports for the last two days for all target platforms> in the tinderbox are not correct (at least, if they show no errors);> there have been some structural changes and more things need to be> adapted. Jay Krell is working on it.> > 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 jayk123 at hotmail.com Sun May 4 16:25:26 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 4 May 2008 14:25:26 +0000 Subject: [M3devel] Tinderbox tests on NT386 In-Reply-To: References: <20080504153040.6jvrkwlkms80c8wc@mail.elegosoft.com> Message-ID: > That'd be cool if it correlates. > I'll go try p137 again both ways. It does! Standalone p137 and dynamic p137 have very different results. - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comSubject: RE: [M3devel] Tinderbox tests on NT386Date: Sun, 4 May 2008 14:22:57 +0000 I'm also seeing lots of failures in p137 --- p137 --- bit insert and extract--- ../src/p1/p137/stderr.pgm 2008-05-04 00:10:01.925067200 -0700+++ ../src/p1/p137/NT386/stderr.pgm 2008-05-04 03:59:42.382247900 -0700@@ -1,3 +1,418 @@+************************ ERROR: 282863103 instead of 819734015+************************ ERROR: 14427647 instead of 819734015...lotsYou never saw that Olaf?I should have printed the test names below, it's too hard to read with just numbers..Anyway, just looking busy I guess, no matter, we'll get around to them..(And sorry about the Win32 bitmap stuff, I haven't forgotten...) Hm..maybe related? Older version of m3tests statically links to libm3/m3core but current version dynamically links.That'd be cool if it correlates -- if p137 and the bitmap stuff are the same problem.I'll go try p137 again both ways. - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Sun, 4 May 2008 14:17:28 +0000Subject: Re: [M3devel] Tinderbox tests on NT386 Here is a QUICK rundown.p004 I /assume/ this is the same on all platforms but didn't checkp051 extra print out when building specific to NT386, fixed, but at great loss of diagnosability IF there are errors in compiling C codeSpecifically, given cl -nologo -c foo.c bar.cthe compiler printsfoo.cbar.cto the same channel as errors (stderr or stdout)So when running the tests, NT386.common has a hack to throwout all C compiler output.p116b floating point issue, probably same on all platformsp126 dittop172 dittop186 dittop204 compiler bug I think this also fails on other platforms but obviously differently; needs investigationp205 was failing but I put in a fix and then Tony put in a better fix p206 I think this fails the same on all platforms, but I I think it behaves correctly and just update the std{out,err}.{pgm,build} files; since it is a compilation failure, it should be an 'e' instead of 'p', not a big deal I thinkp207 probably fall out from longint not being 64 bits probably should disable just for this platform r001 This test works in general but is a problem for the Tinderbox in general. LINUXLIBC6 and NT386 should be passing, but I think probably it should be turned off. In particular, the way programs exit when they fail an assertion and/or have an unhandled exception varies by platform, in terms of what they actually print.r002 needs investigation; I think it's an infinite recursion or just uses a lot of stack, and I THINK I saw it fail on other platforms r003 I hadn't looked at this AT ALL but probably the same as r001, except more interesting? There is a test that catches an assertion failure, maybe do that here? As well, there is the annoying idea of making per-platform std* files. Hard to maintain. r004 ditto -- since there are four of these, and potentially more, maybe worth coming up with somethingSomething I considered, but rejected, back when I thought r001was the only one, is a runtime switch M3 at consistentAbort orsomesuch that will just cleanly exit(0) or exit(1) in these cases,and not print a callstack. I don't want to foul up thesystem TOO much for the sake of testing, but testabilityis an expected design goal...Again, this is an issue across platforms. LINUXLIBC6 seems to print something slightly differently every time you run these. Test.common has a gross workaround. The checked in std* files are from FreeBSD.e020 unknown so fare026 was a problem on all platforms and should be ok now; was a compiler bug, I fixede029 unknown so farI think p209 and p210 are the most important currently.And then maybe e020, e029.I expect to be "out" all of Sunday.The Tinderbox SHOULD be OK now.Sorry... - Jay > Date: Sun, 4 May 2008 15:30:40 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] Tinderbox tests on NT386> > In case anybody wonders about> > http://www.opencm3.net/m3tests/m3tests-NT386-2008-05-03-22-37-30.html> > and following reports, I'm currently trying to run the m3tests on> NT386 in an older version to get a usable reference for the current> problems. There have been so many changes that I'm unable to keep> up with them, and some things seem to be broken.> > Except for the problems in m3tests, the rest of the tinderbox> regression test framework seems to be working now for regular> regression tests on Windows XP with Cygwin. Some initialization> scripts are needed for running them, but that was to be expected.> > The m3tests reports for the last two days for all target platforms> in the tinderbox are not correct (at least, if they show no errors);> there have been some structural changes and more things need to be> adapted. Jay Krell is working on it.> > 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 jayk123 at hotmail.com Sun May 4 16:38:03 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 4 May 2008 14:38:03 +0000 Subject: [M3devel] Tinderbox tests on NT386 In-Reply-To: References: <20080504153040.6jvrkwlkms80c8wc@mail.elegosoft.com> Message-ID: I bet this is related to importing (dynamically linking) data -- _lowbits. _highbits and such. Dynamically linking data is a bad idea -- the codegen pretty much must vary depending on if you are going to statically link or dynamically link, whereas with functions you can just pretend you always statically link and it works out well enough, just with small lost optimization. I don't see getting to this today but should be within a few days. There is a compromise in that you can make all data that might be dynamically linked pointers to what the data otherwise would have been. And then static linking is what loses efficiency -- unnecessary pointer deref. Replace all foo with *pfoo, essentially. The next step would be to change foo to *GetFoo(), even slower, but normal for dynamic linking. So, anyway, I'll change __lowbits and such to pointers, on NT386. I think somehow dynamic linking on other systems copes with this, but I bet it is not pretty if so. Dynamic linking on NT writes to generally one page for .so to update one copy of a pointer to all the relevant addresses. No writing walk through the code is needed. If you are willing to walk through the code and patch it up, then you can dynamically link data without varying the code. Or maybe just with -fPIC, all data references are slowed down, in case they are dynamically linked. I wouldn't be surprised if this has been broken since 4.1..anytime m3core was dynamically linked on NT. Anyone want to try that? I should have noticed this earlier, as I did go hunting around for how some of this works. Anyway, I could be wrong. We'll known soon enough now. - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Sun, 4 May 2008 14:25:26 +0000Subject: Re: [M3devel] Tinderbox tests on NT386 > That'd be cool if it correlates. > I'll go try p137 again both ways. It does!Standalone p137 and dynamic p137 have very different results. - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comSubject: RE: [M3devel] Tinderbox tests on NT386Date: Sun, 4 May 2008 14:22:57 +0000 I'm also seeing lots of failures in p137 --- p137 --- bit insert and extract--- ../src/p1/p137/stderr.pgm 2008-05-04 00:10:01.925067200 -0700+++ ../src/p1/p137/NT386/stderr.pgm 2008-05-04 03:59:42.382247900 -0700@@ -1,3 +1,418 @@+************************ ERROR: 282863103 instead of 819734015+************************ ERROR: 14427647 instead of 819734015...lotsYou never saw that Olaf?I should have printed the test names below, it's too hard to read with just numbers..Anyway, just looking busy I guess, no matter, we'll get around to them..(And sorry about the Win32 bitmap stuff, I haven't forgotten...) Hm..maybe related? Older version of m3tests statically links to libm3/m3core but current version dynamically links.That'd be cool if it correlates -- if p137 and the bitmap stuff are the same problem.I'll go try p137 again both ways. - Jay From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Sun, 4 May 2008 14:17:28 +0000Subject: Re: [M3devel] Tinderbox tests on NT386 Here is a QUICK rundown.p004 I /assume/ this is the same on all platforms but didn't checkp051 extra print out when building specific to NT386, fixed, but at great loss of diagnosability IF there are errors in compiling C codeSpecifically, given cl -nologo -c foo.c bar.cthe compiler printsfoo.cbar.cto the same channel as errors (stderr or stdout)So when running the tests, NT386.common has a hack to throwout all C compiler output.p116b floating point issue, probably same on all platformsp126 dittop172 dittop186 dittop204 compiler bug I think this also fails on other platforms but obviously differently; needs investigationp205 was failing but I put in a fix and then Tony put in a better fix p206 I think this fails the same on all platforms, but I I think it behaves correctly and just update the std{out,err}.{pgm,build} files; since it is a compilation failure, it should be an 'e' instead of 'p', not a big deal I thinkp207 probably fall out from longint not being 64 bits probably should disable just for this platform r001 This test works in general but is a problem for the Tinderbox in general. LINUXLIBC6 and NT386 should be passing, but I think probably it should be turned off. In particular, the way programs exit when they fail an assertion and/or have an unhandled exception varies by platform, in terms of what they actually print.r002 needs investigation; I think it's an infinite recursion or just uses a lot of stack, and I THINK I saw it fail on other platforms r003 I hadn't looked at this AT ALL but probably the same as r001, except more interesting? There is a test that catches an assertion failure, maybe do that here? As well, there is the annoying idea of making per-platform std* files. Hard to maintain. r004 ditto -- since there are four of these, and potentially more, maybe worth coming up with somethingSomething I considered, but rejected, back when I thought r001was the only one, is a runtime switch M3 at consistentAbort orsomesuch that will just cleanly exit(0) or exit(1) in these cases,and not print a callstack. I don't want to foul up thesystem TOO much for the sake of testing, but testabilityis an expected design goal...Again, this is an issue across platforms. LINUXLIBC6 seems to print something slightly differently every time you run these. Test.common has a gross workaround. The checked in std* files are from FreeBSD.e020 unknown so fare026 was a problem on all platforms and should be ok now; was a compiler bug, I fixede029 unknown so farI think p209 and p210 are the most important currently.And then maybe e020, e029.I expect to be "out" all of Sunday.The Tinderbox SHOULD be OK now.Sorry... - Jay > Date: Sun, 4 May 2008 15:30:40 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] Tinderbox tests on NT386> > In case anybody wonders about> > http://www.opencm3.net/m3tests/m3tests-NT386-2008-05-03-22-37-30.html> > and following reports, I'm currently trying to run the m3tests on> NT386 in an older version to get a usable reference for the current> problems. There have been so many changes that I'm unable to keep> up with them, and some things seem to be broken.> > Except for the problems in m3tests, the rest of the tinderbox> regression test framework seems to be working now for regular> regression tests on Windows XP with Cygwin. Some initialization> scripts are needed for running them, but that was to be expected.> > The m3tests reports for the last two days for all target platforms> in the tinderbox are not correct (at least, if they show no errors);> there have been some structural changes and more things need to be> adapted. Jay Krell is working on it.> > 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 Sun May 4 16:49:26 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 04 May 2008 16:49:26 +0200 Subject: [M3devel] Tinderbox tests on NT386 In-Reply-To: References: <20080504153040.6jvrkwlkms80c8wc@mail.elegosoft.com> Message-ID: <20080504164926.ufqus5lpcg0o84gg@mail.elegosoft.com> Quoting Jay : > I'm also seeing lots of failures in p137 > > --- p137 --- bit insert and extract > --- ../src/p1/p137/stderr.pgm 2008-05-04 00:10:01.925067200 -0700+++ > ../src/p1/p137/NT386/stderr.pgm 2008-05-04 03:59:42.382247900 > -0700@@ -1,3 +1,418 @@+************************ ERROR: 282863103 > instead of 819734015+************************ ERROR: 14427647 > instead of 819734015... > lotsYou never saw that Olaf? p137 was OK on 2008-05-01. Use http://www.opencm3.net/m3tests/m3tests-NT386-2008-05-03-22-37-30.html as a reference; I won't overwrite that anymore now. Current results of m3tests will be reported to http://www.opencm3.net/m3tests/m3tests-NT386-2008-05-03-22-37-31.html soon (sorry for the wrong dates, I'm re-using existing workspaces here; it would take too long otherwise). I'll be out soon, but will have another look later this evening how things develop. Olaf > I should have printed the test names below, it's too hard to read > with just numbers.. > Anyway, just looking busy I guess, no matter, we'll get around to them.. > (And sorry about the Win32 bitmap stuff, I haven't forgotten...) > > Hm..maybe related? Older version of m3tests statically links to > libm3/m3core but current version dynamically links. > That'd be cool if it correlates -- if p137 and the bitmap stuff are > the same problem. > I'll go try p137 again both ways. > - Jay > > > From: jayk123 at hotmail.comTo: wagner at elegosoft.com; > m3devel at elegosoft.comDate: Sun, 4 May 2008 14:17:28 +0000Subject: > Re: [M3devel] Tinderbox tests on NT386 > > > Here is a QUICK rundown.p004 I /assume/ this is the same on all > platforms but didn't checkp051 extra print out when building > specific to NT386, fixed, but at great loss of diagnosability IF > there are errors in compiling C codeSpecifically, given cl > -nologo -c foo.c bar.cthe compiler printsfoo.cbar.cto the same > channel as errors (stderr or stdout)So when running the tests, > NT386.common has a hack to throwout all C compiler output.p116b > floating point issue, probably same on all platformsp126 dittop172 > dittop186 dittop204 compiler bug I think this also fails on other > platforms but obviously differently; needs investigationp205 was > failing but I put in a fix and then Tony put in a better fix p206 I > think this fails the same on all platforms, but I I think it > behaves correctly and just update the std{out,err}.{pgm,build} > files; since it is a compilation failure, it should be an 'e' > instead of 'p', not a big deal I thinkp207 probably fall out > from longint not being 64 bits probably should disable just for > this platform r001 This test works in general but is a problem for > the Tinderbox in general. LINUXLIBC6 and NT386 should be > passing, but I think probably it should be turned off. In > particular, the way programs exit when they fail an assertion > and/or have an unhandled exception varies by platform, in terms > of what they actually print.r002 needs investigation; I think it's > an infinite recursion or just uses a lot of stack, and I THINK I > saw it fail on other platforms r003 I hadn't looked at this AT > ALL but probably the same as r001, except more interesting? > There is a test that catches an assertion failure, maybe do that > here? As well, there is the annoying idea of making > per-platform std* files. Hard to maintain. r004 ditto -- since > there are four of these, and potentially more, maybe worth > coming up with somethingSomething I considered, but rejected, back > when I thought r001was the only one, is a runtime switch > M3 at consistentAbort orsomesuch that will just cleanly exit(0) or > exit(1) in these cases,and not print a callstack. I don't want to > foul up thesystem TOO much for the sake of testing, but > testabilityis an expected design goal...Again, this is an issue > across platforms. LINUXLIBC6 seems to print something slightly > differently every time you run these. Test.common has a gross > workaround. The checked in std* files are from FreeBSD.e020 unknown > so fare026 was a problem on all platforms and should be ok now; > was a compiler bug, I fixede029 unknown so farI think p209 and p210 > are the most important currently.And then maybe e020, e029.I expect > to be "out" all of Sunday.The Tinderbox SHOULD be OK now.Sorry... > - Jay > >> Date: Sun, 4 May 2008 15:30:40 +0200> From: wagner at elegosoft.com> >> To: m3devel at elegosoft.com> Subject: [M3devel] Tinderbox tests on >> NT386> > In case anybody wonders about> > >> http://www.opencm3.net/m3tests/m3tests-NT386-2008-05-03-22-37-30.html> > >> and following reports, I'm currently trying to run the m3tests on> >> NT386 in an older version to get a usable reference for the >> current> problems. There have been so many changes that I'm unable >> to keep> up with them, and some things seem to be broken.> > Except >> for the problems in m3tests, the rest of the tinderbox> regression >> test framework seems to be working now for regular> regression >> tests on Windows XP with Cygwin. Some initialization> scripts are >> needed for running them, but that was to be expected.> > The >> m3tests reports for the last two days for all target platforms> in >> the tinderbox are not correct (at least, if they show no errors);> >> there have been some structural changes and more things need to be> >> adapted. Jay Krell is working on it.> > Olaf> -- > Olaf Wagner -- >> elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, >> 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 >> 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | >> Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: >> Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Sun May 4 17:46:57 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 4 May 2008 15:46:57 +0000 Subject: [M3devel] pixmap problem In-Reply-To: References: <479144D6.1E75.00D7.1@scires.com> <0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu> Message-ID: Randy, Please try with /current/ source, as of this morning Sunday May 4 -- the changes are ALL in NT386.common, so you MUST use MY config files, which are checked in verbatim, or you should be able edit whatever config files you are using. (It's not really a config file issue, don't blame the general confusion people have with them.) I'll try to try later, but I don't have the source right now, gotta look on other machines, and I think it's on a machine on loan. Or send it to me again. I'd also like to know if this worked with 4.1, or with any release that offered dynamic linking to m3core.dll, on Windows. I recall a claim that it did. If today's change fixes it, I should be able to investigate 4.1. 3.6 did not have such linking. If today's change does not help, well, I still plan on debugging it at some point.. If you aren't current and getting so is difficult, just send the attachment again, it's easy for me to test. Thanks, - Jay From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rcoleburn at scires.comDate: Sat, 19 Jan 2008 08:52:08 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem I can repro the two different behaviors on XP.I was going to try on PPC_DARWIN but I guess Tony's info suffices. I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. Debugging here is a big humungous pain.NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)And bundles look pretty simple, a bundle is just a generated source file with a constant in it.Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something. The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for? I have to say this is very surprising. I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so.The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: pointer to msvcrt!fopenpointer to msvcrt!fclosenullpointer to kernel32!Sleep But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo.But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo.That doesn't work for data though. There's no ability to intervenve like that.So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it.And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.However that would suck perf in order to make an uncommon case work.I hope Modula-3 doesn't do that either. :)Though I guess since this global data in question...maybe it is rare??? Later, - Jay > From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 03:09:47 -0500> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] pixmap problem> > Looks fine to me on I386_DARWIN.> > On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:> > > > Need to know the score, the latest news, or you need your Hotmail?-get your "fix" Check it out. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun May 4 18:06:25 2008 From: jayk123 at hotmail.com (Jay) Date: Sun, 4 May 2008 16:06:25 +0000 Subject: [M3devel] Tinderbox tests on NT386 In-Reply-To: <20080504164926.ufqus5lpcg0o84gg@mail.elegosoft.com> References: <20080504153040.6jvrkwlkms80c8wc@mail.elegosoft.com> <20080504164926.ufqus5lpcg0o84gg@mail.elegosoft.com> Message-ID: Olaf, You have p137 failing now, which is/was consistent with me.And still p051 failing for you. I fixed that, but the fix is half in NT386.common, and half in m3tests. You take that for each build? The situation there is/was kind of unfortunate -- all compiler output is quashed, errors and all. If we could have per-platform std* files, this would be one to do that for. You know, if stdout.pgm.PLATFORM exists, use it, otherwise stdout.pgm. Problem is whenever the output changes, updating them all. - Jay > Date: Sun, 4 May 2008 16:49:26 +0200> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: RE: [M3devel] Tinderbox tests on NT386> > Quoting Jay :> > > I'm also seeing lots of failures in p137> >> > --- p137 --- bit insert and extract> > --- ../src/p1/p137/stderr.pgm 2008-05-04 00:10:01.925067200 -0700+++ > > ../src/p1/p137/NT386/stderr.pgm 2008-05-04 03:59:42.382247900 > > -0700@@ -1,3 +1,418 @@+************************ ERROR: 282863103 > > instead of 819734015+************************ ERROR: 14427647 > > instead of 819734015...> > lotsYou never saw that Olaf?> > p137 was OK on 2008-05-01. Use> > http://www.opencm3.net/m3tests/m3tests-NT386-2008-05-03-22-37-30.html> > as a reference; I won't overwrite that anymore now.> Current results of m3tests will be reported to> > http://www.opencm3.net/m3tests/m3tests-NT386-2008-05-03-22-37-31.html> > soon (sorry for the wrong dates, I'm re-using existing workspaces> here; it would take too long otherwise).> > I'll be out soon, but will have another look later this evening how> things develop.> > Olaf> > > > I should have printed the test names below, it's too hard to read > > with just numbers..> > Anyway, just looking busy I guess, no matter, we'll get around to them..> > (And sorry about the Win32 bitmap stuff, I haven't forgotten...)> >> > Hm..maybe related? Older version of m3tests statically links to > > libm3/m3core but current version dynamically links.> > That'd be cool if it correlates -- if p137 and the bitmap stuff are > > the same problem.> > I'll go try p137 again both ways.> > - Jay> >> >> > From: jayk123 at hotmail.comTo: wagner at elegosoft.com; > > m3devel at elegosoft.comDate: Sun, 4 May 2008 14:17:28 +0000Subject: > > Re: [M3devel] Tinderbox tests on NT386> >> >> > Here is a QUICK rundown.p004 I /assume/ this is the same on all > > platforms but didn't checkp051 extra print out when building > > specific to NT386, fixed, but at great loss of diagnosability IF > > there are errors in compiling C codeSpecifically, given cl > > -nologo -c foo.c bar.cthe compiler printsfoo.cbar.cto the same > > channel as errors (stderr or stdout)So when running the tests, > > NT386.common has a hack to throwout all C compiler output.p116b > > floating point issue, probably same on all platformsp126 dittop172 > > dittop186 dittop204 compiler bug I think this also fails on other > > platforms but obviously differently; needs investigationp205 was > > failing but I put in a fix and then Tony put in a better fix p206 I > > think this fails the same on all platforms, but I I think it > > behaves correctly and just update the std{out,err}.{pgm,build} > > files; since it is a compilation failure, it should be an 'e' > > instead of 'p', not a big deal I thinkp207 probably fall out > > from longint not being 64 bits probably should disable just for > > this platform r001 This test works in general but is a problem for > > the Tinderbox in general. LINUXLIBC6 and NT386 should be > > passing, but I think probably it should be turned off. In > > particular, the way programs exit when they fail an assertion > > and/or have an unhandled exception varies by platform, in terms > > of what they actually print.r002 needs investigation; I think it's > > an infinite recursion or just uses a lot of stack, and I THINK I > > saw it fail on other platforms r003 I hadn't looked at this AT > > ALL but probably the same as r001, except more interesting? > > There is a test that catches an assertion failure, maybe do that > > here? As well, there is the annoying idea of making > > per-platform std* files. Hard to maintain. r004 ditto -- since > > there are four of these, and potentially more, maybe worth > > coming up with somethingSomething I considered, but rejected, back > > when I thought r001was the only one, is a runtime switch > > M3 at consistentAbort orsomesuch that will just cleanly exit(0) or > > exit(1) in these cases,and not print a callstack. I don't want to > > foul up thesystem TOO much for the sake of testing, but > > testabilityis an expected design goal...Again, this is an issue > > across platforms. LINUXLIBC6 seems to print something slightly > > differently every time you run these. Test.common has a gross > > workaround. The checked in std* files are from FreeBSD.e020 unknown > > so fare026 was a problem on all platforms and should be ok now; > > was a compiler bug, I fixede029 unknown so farI think p209 and p210 > > are the most important currently.And then maybe e020, e029.I expect > > to be "out" all of Sunday.The Tinderbox SHOULD be OK now.Sorry... > > - Jay> >> >> Date: Sun, 4 May 2008 15:30:40 +0200> From: wagner at elegosoft.com> > >> To: m3devel at elegosoft.com> Subject: [M3devel] Tinderbox tests on > >> NT386> > In case anybody wonders about> > > >> http://www.opencm3.net/m3tests/m3tests-NT386-2008-05-03-22-37-30.html> > > >> and following reports, I'm currently trying to run the m3tests on> > >> NT386 in an older version to get a usable reference for the > >> current> problems. There have been so many changes that I'm unable > >> to keep> up with them, and some things seem to be broken.> > Except > >> for the problems in m3tests, the rest of the tinderbox> regression > >> test framework seems to be working now for regular> regression > >> tests on Windows XP with Cygwin. Some initialization> scripts are > >> needed for running them, but that was to be expected.> > The > >> m3tests reports for the last two days for all target platforms> in > >> the tinderbox are not correct (at least, if they show no errors);> > >> there have been some structural changes and more things need to be> > >> adapted. Jay Krell is working on it.> > Olaf> -- > Olaf Wagner -- > >> elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, > >> 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 > >> 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | > >> Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: > >> Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194>> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Mon May 5 16:59:27 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 05 May 2008 10:59:27 -0400 Subject: [M3devel] pixmap problem In-Reply-To: References: <479144D6.1E75.00D7.1@scires.com> <0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu> Message-ID: <481EE888.1E75.00D7.1@scires.com> Jay: The TestPixmap.zip is attached. I will attempt to update all my sources and try again. Not sure what you mean when you say that I must use your config files or edit what I am using. Please elaborate. The pixmap problem does not occur on 4.1. Regards, Randy >>> Jay 5/4/2008 11:46 AM >>> Randy, Please try with /current/ source, as of this morning Sunday May 4 -- the changes are ALL in NT386.common, so you MUST use MY config files, which are checked in verbatim, or you should be able edit whatever config files you are using. (It's not really a config file issue, don't blame the general confusion people have with them.) I'll try to try later, but I don't have the source right now, gotta look on other machines, and I think it's on a machine on loan. Or send it to me again. I'd also like to know if this worked with 4.1, or with any release that offered dynamic linking to m3core.dll, on Windows. I recall a claim that it did. If today's change fixes it, I should be able to investigate 4.1. 3.6 did not have such linking. If today's change does not help, well, I still plan on debugging it at some point.. If you aren't current and getting so is difficult, just send the attachment again, it's easy for me to test. Thanks, - Jay From: jayk123 at hotmail.com To: hosking at cs.purdue.edu; rcoleburn at scires.com Date: Sat, 19 Jan 2008 08:52:08 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] pixmap problem I can repro the two different behaviors on XP. I was going to try on PPC_DARWIN but I guess Tony's info suffices. I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. Debugging here is a big humungous pain. NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn) And bundles look pretty simple, a bundle is just a generated source file with a constant in it. Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something. The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for? I have to say this is very surprising. I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right? On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported. For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so. The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: pointer to msvcrt!fopen pointer to msvcrt!fclose null pointer to kernel32!Sleep But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo. But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo. That doesn't work for data though. There's no ability to intervenve like that. So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported. Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it. And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one. However that would suck perf in order to make an uncommon case work. I hope Modula-3 doesn't do that either. :) Though I guess since this global data in question...maybe it is rare??? Later, - Jay > From: hosking at cs.purdue.edu > Date: Sat, 19 Jan 2008 03:09:47 -0500 > To: rcoleburn at scires.com > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] pixmap problem > > Looks fine to me on I386_DARWIN. > > On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote: > > > > Need to know the score, the latest news, or you need your Hotmail*-get your "fix" Check it out. ( http://www.msnmobilefix.com/Default.aspx ) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: TestPixmap.zip Type: application/x-zip-compressed Size: 4870 bytes Desc: not available URL: From rcoleburn at scires.com Mon May 5 21:10:33 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 05 May 2008 15:10:33 -0400 Subject: [M3devel] build fails on NT386 References: <481EFC54.1E75.00D7.1@scires.com> Message-ID: <481F2363.1E75.00D7.1@scires.com> I have done a CVS update and decided to rebuild everything. I used the script in scripts\win\upgrade.cmd Here is a snippet of the output where it fails: ..\src\values => c:\cm3\pkg\m3front\src\values Module.i3 Module.m3 Value.i3 Value.m3 ValueRep.i3 Constant.i3 Constant.m3 Decl.m3 Decl.i3 EnumElt.i3 EnumElt.m3 Exceptionz.i3 Exceptionz.m3 External.i3 External.m3 Field.i3 Field.m3 Formal.i3 Formal.m3 Ident.i3 Ident.m3 Method.m3 Method.i3 Procedure.i3 Procedure.m3 Revelation.m3 Revelation.i3 Tipe.i3 Tipe.m3 Variable.i3 Variable.m3 === package C:\CM3_Sandbox\cm3\m3-sys\m3quake === +++ "cm3 -build -DROOT=C:\\CM3_Sandbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_VER SION_NUMBER=050700 -DCM3_LAST_CHANGED=2008-03-16 && cm3 -ship -DROOT=C:\\CM3_San dbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_VERSION_NUMBER=050700 -DCM3_LAST_CHANG ED=2008-03-16" +++ --- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_Sandbox\cm3\m3-sys\m3quake\src\m3makefile", line 14: quake runtime error : unable to open "c:\cm3\pkg\sysutils\NT386\.M3EXPORTS" for reading --procedure-- -line- -file--- import -- include_dir 14 C:\CM3_Sandbox\cm3\m3-sys\m3quake\src\m3makefile 8 C:\CM3_Sandbox\cm3\m3-sys\m3quake\NT386\m3make.args Fatal Error: package build failed ERROR: "cm3 -build -DROOT=C:\\CM3_Sandbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_ VERSION_NUMBER=050700 -DCM3_LAST_CHANGED=2008-03-16 && cm3 -ship -DROOT=C:\\CM3_ Sandbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_VERSION_NUMBER=050700 -DCM3_LAST_CH ANGED=2008-03-16" ERROR: cd C:\CM3_Sandbox\cm3\m3-sys\m3quake ERROR: set INSTALLROOT=C:\cm3 C:\CM3_Sandbox\cm3\scripts\win> Please advise. Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Mon May 5 21:21:36 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 05 May 2008 15:21:36 -0400 Subject: [M3devel] build fails on NT386 In-Reply-To: <481F2363.1E75.00D7.1@scires.com> References: <481EFC54.1E75.00D7.1@scires.com> <481F2363.1E75.00D7.1@scires.com> Message-ID: <481F25FA.1E75.00D7.1@scires.com> Update: I tried to get around the problem by manually building & shipping the sysutils package, then running scripts\win\upgrade.cmd again. Now the build fails as shown below: === package C:\CM3_Sandbox\cm3\m3-sys\m3quake === +++ "cm3 -build -DROOT=C:\\CM3_Sandbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_VER SION_NUMBER=050700 -DCM3_LAST_CHANGED=2008-03-16 && cm3 -ship -DROOT=C:\\CM3_San dbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_VERSION_NUMBER=050700 -DCM3_LAST_CHANG ED=2008-03-16" +++ --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling Quake.i3 new source -> compiling QCompiler.i3 new source -> compiling QCode.i3 new source -> compiling QValue.i3 new source -> compiling QVSeq.i3 new source -> compiling QVTbl.i3 new source -> compiling QVal.i3 new source -> compiling QMachine.i3 new source -> compiling QToken.i3 new source -> compiling QIdent.i3 new source -> compiling Quake.m3 new source -> compiling QToken.m3 new source -> compiling QIdent.m3 new source -> compiling QScanner.i3 new source -> compiling QScanner.m3 new source -> compiling QCode.m3 new source -> compiling QCompiler.m3 new source -> compiling QValue.m3 new source -> compiling QVTbl.m3 new source -> compiling QVSeqRep.i3 new source -> compiling QVSeq.m3 Fatal Error: bad version stamps: SystemWin32.m3 version stamp mismatch: WinSock.gethostname <4ccceffe6a8d6438> => SystemWin32.m3 <0e719d1414b51c34> => WinSock.i3 SystemWin32.m3: missing imported type: _te9593bef ERROR: "cm3 -build -DROOT=C:\\CM3_Sandbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_ VERSION_NUMBER=050700 -DCM3_LAST_CHANGED=2008-03-16 && cm3 -ship -DROOT=C:\\CM3_ Sandbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_VERSION_NUMBER=050700 -DCM3_LAST_CH ANGED=2008-03-16" ERROR: cd C:\CM3_Sandbox\cm3\m3-sys\m3quake ERROR: set INSTALLROOT=C:\cm3 C:\CM3_Sandbox\cm3\scripts\win> Please advise. Regards, Randy >>> "Randy Coleburn" 5/5/2008 3:10 PM >>> I have done a CVS update and decided to rebuild everything. I used the script in scripts\win\upgrade.cmd Here is a snippet of the output where it fails: ..\src\values => c:\cm3\pkg\m3front\src\values Module.i3 Module.m3 Value.i3 Value.m3 ValueRep.i3 Constant.i3 Constant.m3 Decl.m3 Decl.i3 EnumElt.i3 EnumElt.m3 Exceptionz.i3 Exceptionz.m3 External.i3 External.m3 Field.i3 Field.m3 Formal.i3 Formal.m3 Ident.i3 Ident.m3 Method.m3 Method.i3 Procedure.i3 Procedure.m3 Revelation.m3 Revelation.i3 Tipe.i3 Tipe.m3 Variable.i3 Variable.m3 === package C:\CM3_Sandbox\cm3\m3-sys\m3quake === +++ "cm3 -build -DROOT=C:\\CM3_Sandbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_VER SION_NUMBER=050700 -DCM3_LAST_CHANGED=2008-03-16 && cm3 -ship -DROOT=C:\\CM3_San dbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_VERSION_NUMBER=050700 -DCM3_LAST_CHANG ED=2008-03-16" +++ --- building in NT386 --- ignoring ..\src\m3overrides "C:\CM3_Sandbox\cm3\m3-sys\m3quake\src\m3makefile", line 14: quake runtime error : unable to open "c:\cm3\pkg\sysutils\NT386\.M3EXPORTS" for reading --procedure-- -line- -file--- import -- include_dir 14 C:\CM3_Sandbox\cm3\m3-sys\m3quake\src\m3makefile 8 C:\CM3_Sandbox\cm3\m3-sys\m3quake\NT386\m3make.args Fatal Error: package build failed ERROR: "cm3 -build -DROOT=C:\\CM3_Sandbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_ VERSION_NUMBER=050700 -DCM3_LAST_CHANGED=2008-03-16 && cm3 -ship -DROOT=C:\\CM3_ Sandbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_VERSION_NUMBER=050700 -DCM3_LAST_CH ANGED=2008-03-16" ERROR: cd C:\CM3_Sandbox\cm3\m3-sys\m3quake ERROR: set INSTALLROOT=C:\cm3 C:\CM3_Sandbox\cm3\scripts\win> Please advise. Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Mon May 5 23:13:15 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 05 May 2008 17:13:15 -0400 Subject: [M3devel] problems rebuilding everything Message-ID: <481F4025.1E75.00D7.1@scires.com> I think I've traced the problem rebuilding everything on WindowsXP to the sysutils package. I don't think this package is getting built in the correct order when running the scripts in the scripts\win folder. Can someone tell me the purpose and format of the scripts\pkginfo.txt file? It would appear that this file has something to do with defining the build order. In this file the sysutils entry is defined as: sysutils core std In looking at the m3makefile for this package, it appears to depend on: libm3 When I run the scripts\win\upgrade.cmd file, I get to a point where an error occurs because sysutils has not been built. If you then build sysutils and run the upgrade.cmd script again, you later get a version stamp mismatch problem. Please advise on how to repair this problem. Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue May 6 00:48:15 2008 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 06 May 2008 00:48:15 +0200 Subject: [M3devel] pixmap problem In-Reply-To: <481EE888.1E75.00D7.1@scires.com> References: <479144D6.1E75.00D7.1@scires.com> <0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu> <481EE888.1E75.00D7.1@scires.com> Message-ID: <20080506004815.p4vfoausgkcggsk0@mail.elegosoft.com> Quoting Randy Coleburn : > Jay: > > The TestPixmap.zip is attached. > > I will attempt to update all my sources and try again. > > Not sure what you mean when you say that I must use your config files > or edit what I am using. Please elaborate. I think he simply means that the fix is in the config files, and you must use his latest commits (cminstall/src/config/NT386*). 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 jayk123 at hotmail.com Tue May 6 01:01:22 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 5 May 2008 23:01:22 +0000 Subject: [M3devel] problems rebuilding everything In-Reply-To: <481F4025.1E75.00D7.1@scires.com> References: <481F4025.1E75.00D7.1@scires.com> Message-ID: This is all normal stuff, not indicative of any real problem. Please try scripts/python/upgrade.py. I don't use scripts/win any longer. The format of pkginfo.txt is incredibly simple: 1) it is in a particular order 2) package name followed by groups it is in almost everything is in "std". The order of the file isn't necessarily correct for "upgrade", since you have to skip building anything that uses LONGINT and first build a compiler that understands LONGINT. (I'm working on a small change with the opposite requirement, but will instead avoid it, else cause too painful bootstrapping; the change is to provide HOST and HOST_OSTYPE in quake, but that's a dependency from m3quake to m3core, if done the expected way; I'll clone Compiler.tmpl instead, and rename the interfade). - Jay Date: Mon, 5 May 2008 17:13:15 -0400 From: rcoleburn at scires.com To: m3-support at elego.de; m3devel at elegosoft.com Subject: [M3devel] problems rebuilding everything I think I've traced the problem rebuilding everything on WindowsXP to the sysutils package. I don't think this package is getting built in the correct order when running the scripts in the scripts\win folder. Can someone tell me the purpose and format of the scripts\pkginfo.txt file? It would appear that this file has something to do with defining the build order. In this file the sysutils entry is defined as: sysutils core std In looking at the m3makefile for this package, it appears to depend on: libm3 When I run the scripts\win\upgrade.cmd file, I get to a point where an error occurs because sysutils has not been built. If you then build sysutils and run the upgrade.cmd script again, you later get a version stamp mismatch problem. Please advise on how to repair this problem. Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue May 6 01:04:33 2008 From: jayk123 at hotmail.com (Jay) Date: Mon, 5 May 2008 23:04:33 +0000 Subject: [M3devel] pixmap problem In-Reply-To: <481EE888.1E75.00D7.1@scires.com> References: <479144D6.1E75.00D7.1@scires.com> <0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu> <481EE888.1E75.00D7.1@scires.com> Message-ID: Thanks. I'll look into this tonight probably, as well as with 4.1 assuming I can find my binaries and source for it (probably). COULD BE the pixmap problem is something else and 4.1 also has the problem I fixed. We'll see. No need to speculate (unless I can't find my 4.1). - Jay Date: Mon, 5 May 2008 10:59:27 -0400 From: rcoleburn at scires.com To: jayk123 at hotmail.com CC: m3devel at elegosoft.com Subject: RE: [M3devel] pixmap problem Jay: The TestPixmap.zip is attached. I will attempt to update all my sources and try again. Not sure what you mean when you say that I must use your config files or edit what I am using. Please elaborate. The pixmap problem does not occur on 4.1. Regards, Randy >>> Jay 5/4/2008 11:46 AM >>> Randy, Please try with /current/ source, as of this morning Sunday May 4 -- the changes are ALL in NT386.common, so you MUST use MY config files, which are checked in verbatim, or you should be able edit whatever config files you are using. (It's not really a config file issue, don't blame the general confusion people have with them.) I'll try to try later, but I don't have the source right now, gotta look on other machines, and I think it's on a machine on loan. Or send it to me again. I'd also like to know if this worked with 4.1, or with any release that offered dynamic linking to m3core.dll, on Windows. I recall a claim that it did. If today's change fixes it, I should be able to investigate 4.1. 3.6 did not have such linking. If today's change does not help, well, I still plan on debugging it at some point.. If you aren't current and getting so is difficult, just send the attachment again, it's easy for me to test. Thanks, - Jay From: jayk123 at hotmail.com To: hosking at cs.purdue.edu; rcoleburn at scires.com Date: Sat, 19 Jan 2008 08:52:08 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] pixmap problem I can repro the two different behaviors on XP. I was going to try on PPC_DARWIN but I guess Tony's info suffices. I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. Debugging here is a big humungous pain. NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn) And bundles look pretty simple, a bundle is just a generated source file with a constant in it. Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something. The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for? I have to say this is very surprising. I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right? On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported. For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so. The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: pointer to msvcrt!fopen pointer to msvcrt!fclose null pointer to kernel32!Sleep But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo. But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo. That doesn't work for data though. There's no ability to intervenve like that. So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported. Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it. And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one. However that would suck perf in order to make an uncommon case work. I hope Modula-3 doesn't do that either. :) Though I guess since this global data in question...maybe it is rare??? Later, - Jay > From: hosking at cs.purdue.edu > Date: Sat, 19 Jan 2008 03:09:47 -0500 > To: rcoleburn at scires.com > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] pixmap problem > > Looks fine to me on I386_DARWIN. > > On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote: > > > > Need to know the score, the latest news, or you need your Hotmail?-get your "fix" Check it out. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue May 6 03:01:10 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 05 May 2008 21:01:10 -0400 Subject: [M3devel] new problem linking on NT386 Message-ID: <481F7590.1E75.00D7.1@scires.com> I've rebuild my cm3 system using the latest sources. I am now having a failure linking certain programs that used to build without problems. I've listed the linker output from one of the programs below. The issue seems to be an unresolved external symbol _WinMain at 16 . Any ideas on what has changed and how to get this working again? Microsoft (R) Incremental Linker Version 9.00.21022.08 Copyright (C) Microsoft Corporation. All rights reserved. /out:CV_MessageTool.exe /subsystem:windows /entry:WinMainCRTStartup /nodefaultlib /debug /incremental:no /opt:ref /delayload:wsock32.dll /delayload:advapi32.dll /delayload:gdi32.dll /delayload:netapi32.dll /delayload:user32.dll /delayload:comctl32.dll delayimp.lib _m3main.obj iconRes.obj Resources.io Resources.mo Main.mo C:\cm3\pkg\windowsResources\NT386\windowsResources.lib C:\cm3\pkg\libSciRes3\NT386\libSciRes3.lib C:\cm3\pkg\stable\NT386\stable.lib C:\cm3\pkg\serial2\NT386\serial2.lib C:\cm3\pkg\netobj\NT386\m3netobj.lib C:\cm3\pkg\parseparams\NT386\m3parseparams.lib C:\cm3\pkg\formsvbt\NT386\m3formsvbt.lib C:\cm3\pkg\videovbt\NT386\videovbt.lib C:\cm3\pkg\jvideo\NT386\jvideo.lib C:\cm3\pkg\web\NT386\web.lib C:\cm3\pkg\tcp\NT386\m3tcp.lib C:\cm3\pkg\formsvbtpixmaps\NT386\m3formsvbtpixmaps.lib C:\cm3\pkg\vbtkit\NT386\m3vbtkit.lib C:\cm3\pkg\ui\NT386\m3ui.lib C:\cm3\pkg\libm3\NT386\m3.lib C:\cm3\pkg\m3core\NT386\m3core.lib winspool.lib comctl32.lib wsock32.lib comdlg32.lib netapi32.lib gdi32.lib user32.lib advapi32.lib kernel32.lib msvcrt.lib LINK : warning LNK4199: /DELAYLOAD:wsock32.dll ignored; no imports found from wsock32.dll LINK : warning LNK4199: /DELAYLOAD:advapi32.dll ignored; no imports found from advapi32.dll LINK : warning LNK4199: /DELAYLOAD:gdi32.dll ignored; no imports found from gdi32.dll LINK : warning LNK4199: /DELAYLOAD:netapi32.dll ignored; no imports found from netapi32.dll LINK : warning LNK4199: /DELAYLOAD:user32.dll ignored; no imports found from user32.dll LINK : warning LNK4199: /DELAYLOAD:comctl32.dll ignored; no imports found from comctl32.dll msvcrt.lib(crtexew.obj) : error LNK2019: unresolved external symbol _WinMain at 16 referenced in function ___tmainCRTStartup CV_MessageTool.exe : fatal error LNK1120: 1 unresolved externals Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Tue May 6 03:18:12 2008 From: rcoleburn at scires.com (Randy Coleburn) Date: Mon, 05 May 2008 21:18:12 -0400 Subject: [M3devel] pixmap problem In-Reply-To: References: <479144D6.1E75.00D7.1@scires.com> <0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu> <481EE888.1E75.00D7.1@scires.com> Message-ID: <481F798E.1E75.00D7.1@scires.com> Jay: I've updated my sandbox via CVS and I've rebuilt everything. I rebuilt the TestPixmap program, but it still does not work properly when the buildstandalone() directive is used. Regards, Randy >>> Jay 5/5/2008 7:04 PM >>> Thanks. I'll look into this tonight probably, as well as with 4.1 assuming I can find my binaries and source for it (probably). COULD BE the pixmap problem is something else and 4.1 also has the problem I fixed. We'll see. No need to speculate (unless I can't find my 4.1). - Jay Date: Mon, 5 May 2008 10:59:27 -0400 From: rcoleburn at scires.com To: jayk123 at hotmail.com CC: m3devel at elegosoft.com Subject: RE: [M3devel] pixmap problem Jay: The TestPixmap.zip is attached. I will attempt to update all my sources and try again. Not sure what you mean when you say that I must use your config files or edit what I am using. Please elaborate. The pixmap problem does not occur on 4.1. Regards, Randy >>> Jay 5/4/2008 11:46 AM >>> Randy, Please try with /current/ source, as of this morning Sunday May 4 -- the changes are ALL in NT386.common, so you MUST use MY config files, which are checked in verbatim, or you should be able edit whatever config files you are using. (It's not really a config file issue, don't blame the general confusion people have with them.) I'll try to try later, but I don't have the source right now, gotta look on other machines, and I think it's on a machine on loan. Or send it to me again. I'd also like to know if this worked with 4.1, or with any release that offered dynamic linking to m3core.dll, on Windows. I recall a claim that it did. If today's change fixes it, I should be able to investigate 4.1. 3.6 did not have such linking. If today's change does not help, well, I still plan on debugging it at some point.. If you aren't current and getting so is difficult, just send the attachment again, it's easy for me to test. Thanks, - Jay From: jayk123 at hotmail.com To: hosking at cs.purdue.edu; rcoleburn at scires.com Date: Sat, 19 Jan 2008 08:52:08 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] pixmap problem I can repro the two different behaviors on XP. I was going to try on PPC_DARWIN but I guess Tony's info suffices. I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. Debugging here is a big humungous pain. NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn) And bundles look pretty simple, a bundle is just a generated source file with a constant in it. Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something. The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for? I have to say this is very surprising. I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right? On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported. For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so. The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: pointer to msvcrt!fopen pointer to msvcrt!fclose null pointer to kernel32!Sleep But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo. But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo. That doesn't work for data though. There's no ability to intervenve like that. So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported. Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it. And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one. However that would suck perf in order to make an uncommon case work. I hope Modula-3 doesn't do that either. :) Though I guess since this global data in question...maybe it is rare??? Later, - Jay > From: hosking at cs.purdue.edu > Date: Sat, 19 Jan 2008 03:09:47 -0500 > To: rcoleburn at scires.com > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] pixmap problem > > Looks fine to me on I386_DARWIN. > > On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote: > > > > Need to know the score, the latest news, or you need your Hotmail*-get your "fix" Check it out. ( http://www.msnmobilefix.com/Default.aspx ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Tue May 6 03:46:27 2008 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 6 May 2008 03:46:27 +0200 (CEST) Subject: [M3devel] www.opencm3.net/m3tests Message-ID: <313767.59466.qm@web27115.mail.ukl.yahoo.com> Dear developers: Does the recent tests on NT386 seem broken because a recent change on the m3-sys tree, or is the HTML bad generated, I mean can you check the last tests Sunday, May 4th (p001 to p042) has a red background http://www.opencm3.net/m3tests/m3tests-NT386-2008-04-23-13-30-57.html p002 Text
Comparing files P0\P002\stdout.build and ..\SRC\P0\P002\STDOUT.BUILD
***** P0\P002\stdout.build
link @_m3responsefile0.txt 2>&1 > pgm.lst
mt /nologo /manifest pgm.exe.manifest /outputresource:pgm.exe;1
***** ..\SRC\P0\P002\STDOUT.BUILD
*****

Comparing files P0\P002\stderr.build and ..\SRC\P0\P002\STDERR.BUILD
FC: no differences encountered

Comparing files P0\P002\stdout.pgm and ..\SRC\P0\P002\STDOUT.PGM
FC: no differences encountered

Comparing files P0\P002\stderr.pgm and ..\SRC\P0\P002\STDERR.PGM
FC: no differences encountered
and almost the same pattern in the above tests.

I would suggest if it is thinkable using NT386 variant with a complete dedicated machine/system, I can try to set up one this week and send the data back (the machine is behind a proxy), but I don't remember the mail explaining the set up, and also want to know if there is a chance of run the tests with one run script.
Also what is the best natural way to put a new tests, and the standard name it should have?


Thanks

       
---------------------------------

Enviado desde Correo Yahoo!
La bandeja de entrada m?s inteligente.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Tue May  6 03:47:17 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 6 May 2008 01:47:17 +0000
Subject: [M3devel] new problem linking on NT386
In-Reply-To: <481F7590.1E75.00D7.1@scires.com>
References: <481F7590.1E75.00D7.1@scires.com>
Message-ID: 

Sounds like you missed the "gui" switch on the cm3 command lineor in the m3makefile -- in the m3makefile really.Putting it on the command line imho is only reasonable for thosesimple cases that don't have an m3makefile
 link -dump -symbols NT386\_m3main.obj | findstr /i main 
?I expect you will have main or wmain, but not WinMain or wWinMain.
 
Is this meant to be a gui app or a command line app?
If it is meant to be a command line, then the problem is something else.
  And I don't even want to explain..
Can you send me the source?
 
Also you are missing hand.obj here, so you don't have the potential pixmap fix.
 - Jay


Date: Mon, 5 May 2008 21:01:10 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: [M3devel] new problem linking on NT386

I've rebuild my cm3 system using the latest sources.
 
I am now having a failure linking certain programs that used to build without problems.
 
I've listed the linker output from one of the programs below.  The issue seems to be an unresolved external symbol _WinMain at 16 .
 
Any ideas on what has changed and how to get this working again?
 
Microsoft (R) Incremental Linker Version 9.00.21022.08Copyright (C) Microsoft Corporation.  All rights reserved.
 
/out:CV_MessageTool.exe /subsystem:windows /entry:WinMainCRTStartup /nodefaultlib /debug /incremental:no /opt:ref /delayload:wsock32.dll /delayload:advapi32.dll /delayload:gdi32.dll /delayload:netapi32.dll /delayload:user32.dll /delayload:comctl32.dll delayimp.lib _m3main.obj iconRes.obj Resources.io Resources.mo Main.mo C:\cm3\pkg\windowsResources\NT386\windowsResources.lib C:\cm3\pkg\libSciRes3\NT386\libSciRes3.lib C:\cm3\pkg\stable\NT386\stable.lib C:\cm3\pkg\serial2\NT386\serial2.lib C:\cm3\pkg\netobj\NT386\m3netobj.lib C:\cm3\pkg\parseparams\NT386\m3parseparams.lib C:\cm3\pkg\formsvbt\NT386\m3formsvbt.lib C:\cm3\pkg\videovbt\NT386\videovbt.lib C:\cm3\pkg\jvideo\NT386\jvideo.lib C:\cm3\pkg\web\NT386\web.lib C:\cm3\pkg\tcp\NT386\m3tcp.lib C:\cm3\pkg\formsvbtpixmaps\NT386\m3formsvbtpixmaps.lib C:\cm3\pkg\vbtkit\NT386\m3vbtkit.lib C:\cm3\pkg\ui\NT386\m3ui.lib C:\cm3\pkg\libm3\NT386\m3.lib C:\cm3\pkg\m3core\NT386\m3core.lib winspool.lib comctl32.lib wsock32.lib comdlg32.lib netapi32.lib gdi32.lib user32.lib advapi32.lib kernel32.lib msvcrt.lib LINK : warning LNK4199: /DELAYLOAD:wsock32.dll ignored; no imports found from wsock32.dllLINK : warning LNK4199: /DELAYLOAD:advapi32.dll ignored; no imports found from advapi32.dllLINK : warning LNK4199: /DELAYLOAD:gdi32.dll ignored; no imports found from gdi32.dllLINK : warning LNK4199: /DELAYLOAD:netapi32.dll ignored; no imports found from netapi32.dllLINK : warning LNK4199: /DELAYLOAD:user32.dll ignored; no imports found from user32.dllLINK : warning LNK4199: /DELAYLOAD:comctl32.dll ignored; no imports found from comctl32.dllmsvcrt.lib(crtexew.obj) : error LNK2019: unresolved external symbol _WinMain at 16 referenced in function ___tmainCRTStartupCV_MessageTool.exe : fatal error LNK1120: 1 unresolved externals
Regards,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Tue May  6 03:54:52 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 6 May 2008 01:54:52 +0000
Subject: [M3devel] pixmap problem
In-Reply-To: <481F798E.1E75.00D7.1@scires.com>
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	 
	<481F798E.1E75.00D7.1@scires.com>
Message-ID: 

And you took the updated config file?
The way you can tell is that, roughly speaking, hand.obj should be in NT386\_m3responsefile0.txt.
Or _m3responsefile1.txt, or, well, somewhere.
Anyway, I think I saw the attachment, I can check later..and with 4.1 as I said..
 
I can see about making the fix not depend on config file changes...but it's not terrible asis, and I'd really like to merge more of the quake code into cm3.exe..
 
 - Jay


Date: Mon, 5 May 2008 21:18:12 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem

Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly when the buildstandalone() directive is used.
 
Regards,
Randy>>> Jay  5/5/2008 7:04 PM >>>Thanks. I'll look into this tonight probably, as well as with 4.1 assuming I can find my binaries and source for it (probably).COULD BE the pixmap problem is something else and 4.1 also has the problem I fixed. We'll see. No need to speculate (unless I can't find my 4.1). - Jay


Date: Mon, 5 May 2008 10:59:27 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problem
Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy>>> Jay  5/4/2008 11:46 AM >>>Randy, Please try with /current/ source, as of this morning Sunday May 4 -- the changes are ALL in NT386.common, so you MUST use MY config files, which are checked in verbatim, or you should be able edit whatever config files you are using. (It's not really a config file issue, don't blame the general confusion people have with them.) I'll try to try later, but I don't have the source right now, gotta look on other machines, and I think it's on a machine on loan.  Or send it to me again.I'd also like to know if this worked with 4.1, or with any release that offered dynamic linking to m3core.dll, on Windows.  I recall a claim that it did. If today's change fixes it, I should be able to investigate 4.1.3.6 did not have such linking.If today's change does not help, well, I still plan on debugging it at some point.. If you aren't current and getting so is difficult, just send the attachment again, it's easy for me to test. Thanks, - Jay


From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rcoleburn at scires.comDate: Sat, 19 Jan 2008 08:52:08 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.I was going to try on PPC_DARWIN but I guess Tony's info suffices. I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. Debugging here is a big humungous pain.NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)And bundles look pretty simple, a bundle is just a generated source file with a constant in it.Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something. The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for? I have to say this is very surprising. I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so.The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: pointer to msvcrt!fopenpointer to msvcrt!fclosenullpointer to kernel32!Sleep But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo.But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo.That doesn't work for data though. There's no ability to intervenve like that.So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it.And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.However that would suck perf in order to make an uncommon case work.I hope Modula-3 doesn't do that either. :)Though I guess since this global data in question...maybe it is rare??? Later, - Jay

> From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 03:09:47 -0500> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] pixmap problem> > Looks fine to me on I386_DARWIN.> > On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:> > > > 

Need to know the score, the latest news, or you need your Hotmail?-get your "fix" Check it out. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Tue May  6 04:01:17 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 6 May 2008 02:01:17 +0000
Subject: [M3devel] www.opencm3.net/m3tests
In-Reply-To: <313767.59466.qm@web27115.mail.ukl.yahoo.com>
References: <313767.59466.qm@web27115.mail.ukl.yahoo.com>
Message-ID: 

The "problem" here, a really really small one, is just that the link and mt commands got echoed.
Olaf made them not echoed. I then made them conditionally echoed.
  I made m3-sys\m3tests define M3TESTS so that NT386.common doesn't echo.
It's not a big deal either way.
Aha -- tests in other directories would have a problem, and I think there are some.
 
I like more echoing usually, so the system explains what is going on,
instead of the vaguer "linking foo" sort of message.
Granted, nobody bothers watching gcc run assembler commands, so I guess it is just quite gray.
 
I don't know how to run the Tinderbox either yet, sorry.
I tried.
 
For adding tests, well, there is m3-sys\m3tests.
That is where a lot of the tests are, but not all.
I am not sure where tests belong. I added a small number there.
They are named with just a letter and a number.
The letters have some meaning, explained in the m3makefile.
"p" is programs that are run and their stdout/stderr compared against expected
"e" is programs build and the errors from the compiler checked to be reasonable.
  I don't think in general they are expected to successfully compile or run, though the case of "warnings" may be unclear.
"c" is programs built so a human can look at the generated code.
There is another case I think for human checking.
The numbers are just 001, 002, 003, etc.
Each hundred tests are in a separate directory, like p0\p001, p0\p002, p1\p100, p1\101, etc. 
 
Something like this.
Wherever I have details wrong, just look in m3-sys\m3tests. It's pretty simple, obvious, and well commented.
 
The output is a little clearer if you have a working diff.exe on the path.
Then what you do is search for "@@" in the output.
 
 - Jay


Date: Tue, 6 May 2008 03:46:27 +0200From: dabenavidesd at yahoo.esTo: m3devel at elegosoft.comSubject: [M3devel] www.opencm3.net/m3testsDear developers:Does the recent tests on NT386 seem broken because a recent change on the m3-sys tree, or is the HTML bad generated, I mean can you check the last tests Sunday, May 4th (p001 to p042) has a red background http://www.opencm3.net/m3tests/m3tests-NT386-2008-04-23-13-30-57.html
p002 Text
Comparing files P0\P002\stdout.build and ..\SRC\P0\P002\STDOUT.BUILD***** P0\P002\stdout.buildlink @_m3responsefile0.txt 2>&1 > pgm.lstmt /nologo /manifest pgm.exe.manifest /outputresource:pgm.exe;1***** ..\SRC\P0\P002\STDOUT.BUILD*****Comparing files P0\P002\stderr.build and ..\SRC\P0\P002\STDERR.BUILDFC: no differences encounteredComparing files P0\P002\stdout.pgm and ..\SRC\P0\P002\STDOUT.PGMFC: no differences encounteredComparing files P0\P002\stderr.pgm and ..\SRC\P0\P002\STDERR.PGMFC: no differences encounteredand almost the same pattern in the above tests.I would suggest if it is thinkable using NT386 variant with a complete dedicated machine/system, I can try to set up one this week and send the data back (the machine is behind a proxy), but I don't remember the mail explaining the set up, and also want to know if there is a chance of run the tests with one run script.Also what is the best natural way to put a new tests, and the standard name it should have?Thanks


Enviado desde Correo Yahoo!La bandeja de entrada m?s inteligente.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Tue May  6 04:08:29 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Mon, 05 May 2008 22:08:29 -0400
Subject: [M3devel] new problem linking on NT386
In-Reply-To: 
References: <481F7590.1E75.00D7.1@scires.com>
	
Message-ID: <481F8557.1E75.00D7.1@scires.com>

Jay:
 
No, I am using the -gui option in the m3makefile.  It is a windows gui application.
 
Here is the output of the command you suggested:
 
Microsoft (R) COFF/PE Dumper Version 9.00.21022.08
Copyright (C) Microsoft Corporation.  All rights reserved.
 

Dump of file NT386\_m3main.obj
 
File Type: COFF OBJECT
 
COFF SYMBOL TABLE
000 00000000 DEBUG  notype       Filename     | .file
    _m3main.mc
002 00000000 SECT1  notype       Static       | .text
    Section length   50, #relocs    4, #linenums    7, checksum        0
004 00000000 SECT2  notype       Static       | .data
    Section length   10, #relocs    3, #linenums    0, checksum        0
006 00000000 SECT3  notype       Static       | .bss
    Section length    0, #relocs    0, #linenums    0, checksum        0
008 00000000 SECT1  notype ()    External     | _main
    tag index 0000000A size 00000050 lines 00000104 next function 00000000
00A 00000000 SECT1  notype       BeginFunction | .bf
    line# 0000 end 00000000
00C 00000007 SECT1  notype       .bf or.ef    | .lf
00D 00000050 SECT1  notype       EndFunction  | .ef
    line# 0006
00F 00000000 SECT1  notype       Static       | TextSegment
010 00000000 UNDEF  notype       External     | _Main_M3
011 00000000 UNDEF  notype       External     | _RTLinker__InitRuntime
012 00000000 UNDEF  notype       External     | _RTLinker__AddUnit
013 00000000 UNDEF  notype       External     | _RTProcess__Exit
014 00000004 SECT2  notype       Static       | T$14
 
String Table Size = 0x4B bytes
 
  Summary
 
           0 .bss
          10 .data
          50 .text
As you can see, I have an
   _main  and a
   _Main_M3
 
Not sure what you mean by saying I am missing hand.obj.  I have rebuilt everything using latest CVS update.  Please elaborate.
 
Regards,
Randy

>>> Jay  5/5/2008 9:47 PM >>>
Sounds like you missed the "gui" switch on the cm3 command line
or in the m3makefile -- in the m3makefile really.
Putting it on the command line imho is only reasonable for those
simple cases that don't have an m3makefile

 link -dump -symbols NT386\_m3main.obj | findstr /i main 

?
I expect you will have main or wmain, but not WinMain or wWinMain.
 
Is this meant to be a gui app or a command line app?
If it is meant to be a command line, then the problem is something else.
  And I don't even want to explain..
Can you send me the source?
 
Also you are missing hand.obj here, so you don't have the potential pixmap fix.

 - Jay

Date: Mon, 5 May 2008 21:01:10 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com 
Subject: [M3devel] new problem linking on NT386

I've rebuild my cm3 system using the latest sources.
 
I am now having a failure linking certain programs that used to build without problems.
 
I've listed the linker output from one of the programs below.  The issue seems to be an unresolved external symbol _WinMain at 16 .
 
Any ideas on what has changed and how to get this working again?
 
Microsoft (R) Incremental Linker Version 9.00.21022.08
Copyright (C) Microsoft Corporation.  All rights reserved.
 
/out:CV_MessageTool.exe 
/subsystem:windows 
/entry:WinMainCRTStartup 
/nodefaultlib 
/debug 
/incremental:no 
/opt:ref 
/delayload:wsock32.dll 
/delayload:advapi32.dll 
/delayload:gdi32.dll 
/delayload:netapi32.dll 
/delayload:user32.dll 
/delayload:comctl32.dll 
delayimp.lib 
_m3main.obj 
iconRes.obj 
Resources.io 
Resources.mo 
Main.mo 
C:\cm3\pkg\windowsResources\NT386\windowsResources.lib 
C:\cm3\pkg\libSciRes3\NT386\libSciRes3.lib 
C:\cm3\pkg\stable\NT386\stable.lib 
C:\cm3\pkg\serial2\NT386\serial2.lib 
C:\cm3\pkg\netobj\NT386\m3netobj.lib 
C:\cm3\pkg\parseparams\NT386\m3parseparams.lib 
C:\cm3\pkg\formsvbt\NT386\m3formsvbt.lib 
C:\cm3\pkg\videovbt\NT386\videovbt.lib 
C:\cm3\pkg\jvideo\NT386\jvideo.lib 
C:\cm3\pkg\web\NT386\web.lib 
C:\cm3\pkg\tcp\NT386\m3tcp.lib 
C:\cm3\pkg\formsvbtpixmaps\NT386\m3formsvbtpixmaps.lib 
C:\cm3\pkg\vbtkit\NT386\m3vbtkit.lib 
C:\cm3\pkg\ui\NT386\m3ui.lib 
C:\cm3\pkg\libm3\NT386\m3.lib 
C:\cm3\pkg\m3core\NT386\m3core.lib 
winspool.lib 
comctl32.lib 
wsock32.lib 
comdlg32.lib 
netapi32.lib 
gdi32.lib 
user32.lib 
advapi32.lib 
kernel32.lib 
msvcrt.lib 
LINK : warning LNK4199: /DELAYLOAD:wsock32.dll ignored; no imports found from wsock32.dll
LINK : warning LNK4199: /DELAYLOAD:advapi32.dll ignored; no imports found from advapi32.dll
LINK : warning LNK4199: /DELAYLOAD:gdi32.dll ignored; no imports found from gdi32.dll
LINK : warning LNK4199: /DELAYLOAD:netapi32.dll ignored; no imports found from netapi32.dll
LINK : warning LNK4199: /DELAYLOAD:user32.dll ignored; no imports found from user32.dll
LINK : warning LNK4199: /DELAYLOAD:comctl32.dll ignored; no imports found from comctl32.dll
msvcrt.lib(crtexew.obj) : error LNK2019: unresolved external symbol _WinMain at 16 referenced in function ___tmainCRTStartup
CV_MessageTool.exe : fatal error LNK1120: 1 unresolved externals
Regards,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Tue May  6 04:26:46 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 6 May 2008 02:26:46 +0000
Subject: [M3devel] new problem linking on NT386
In-Reply-To: <481F8557.1E75.00D7.1@scires.com>
References: <481F7590.1E75.00D7.1@scires.com>
	 
	<481F8557.1E75.00D7.1@scires.com>
Message-ID: 

-gui isn't quite working for you, for reasons I can't fully tell from here.
 
If -entry:WinMainCRTStartup, as you show, then link -dump -symbols _m3main.obj | findstr /i main should find WinMain, and not main. These two things must be altered together. Subsystem usually changes with them as well, but that's optional. WinMainCRTStartup calls WinMain, mainCRTStartup calls main, etc. (also with "w" prepended for Unicode/wide)
This is up to cm3 and cm3.cfg to cooperate on.
 
I can check tonight if it works for me. Could be some config file content missing.
It should generate WinMain instead of main.
 
You don't have the latest config because if you did, the link command you show below would list "hand.obj" among the list of files.
 
e.g.
 copy /y %cvsroot%\m3-sys\cminstall\src\config\nt386* \cm3\bin 
 copy /y \cm3\bin\NT386 \cm3\bin\cm3.cfg  
 
or:
 copy /y %cvsroot%\m3-sys\cminstall\src\config\* \cm3\bin 
 copy /y %cvsroot%\m3-sys\cminstall\src\config-no-install\* \cm3\bin 
 
The second form requires %cvsroot% to stick around and be findable by \cm3\bin\cm3.cfg, such as by setting CM3_ROOT.
The first form does not have such a requirement.
 
I'm really not super keen on supporting any config files other than the exact ones checked in.
Not even necessarily the ones produced by cminstall; I never use it.
I realize there are multiple reasonable modes of operation -- either using %PATH%, %INCLUDE%, and %LIB%, or using full paths in cm3.cfg. I use the first, so I can switch between toolsets more easily, and have no problem with spaces (which I don't have anyway), cminstall uses the second so that the result doesn't depend on the environment but it also has problems with spaces. Depending on short names like "progra~1" is just not the way imho.
 
 - Jay


Date: Mon, 5 May 2008 22:08:29 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] new problem linking on NT386

Jay:
 
No, I am using the -gui option in the m3makefile.  It is a windows gui application.
 
Here is the output of the command you suggested:
 
Microsoft (R) COFF/PE Dumper Version 9.00.21022.08Copyright (C) Microsoft Corporation.  All rights reserved.
 
Dump of file NT386\_m3main.obj
 
File Type: COFF OBJECT
 
COFF SYMBOL TABLE000 00000000 DEBUG  notype       Filename     | .file    _m3main.mc002 00000000 SECT1  notype       Static       | .text    Section length   50, #relocs    4, #linenums    7, checksum        0004 00000000 SECT2  notype       Static       | .data    Section length   10, #relocs    3, #linenums    0, checksum        0006 00000000 SECT3  notype       Static       | .bss    Section length    0, #relocs    0, #linenums    0, checksum        0008 00000000 SECT1  notype ()    External     | _main    tag index 0000000A size 00000050 lines 00000104 next function 0000000000A 00000000 SECT1  notype       BeginFunction | .bf    line# 0000 end 0000000000C 00000007 SECT1  notype       .bf or.ef    | .lf00D 00000050 SECT1  notype       EndFunction  | .ef    line# 000600F 00000000 SECT1  notype       Static       | TextSegment010 00000000 UNDEF  notype       External     | _Main_M3011 00000000 UNDEF  notype       External     | _RTLinker__InitRuntime012 00000000 UNDEF  notype       External     | _RTLinker__AddUnit013 00000000 UNDEF  notype       External     | _RTProcess__Exit014 00000004 SECT2  notype       Static       | T$14
 
String Table Size = 0x4B bytes
 
  Summary
 
           0 .bss          10 .data          50 .text
As you can see, I have an
   _main  and a
   _Main_M3
 
Not sure what you mean by saying I am missing hand.obj.  I have rebuilt everything using latest CVS update.  Please elaborate.
 
Regards,
Randy>>> Jay  5/5/2008 9:47 PM >>>Sounds like you missed the "gui" switch on the cm3 command lineor in the m3makefile -- in the m3makefile really.Putting it on the command line imho is only reasonable for thosesimple cases that don't have an m3makefile link -dump -symbols NT386\_m3main.obj | findstr /i main ?I expect you will have main or wmain, but not WinMain or wWinMain. Is this meant to be a gui app or a command line app?If it is meant to be a command line, then the problem is something else.  And I don't even want to explain..Can you send me the source? Also you are missing hand.obj here, so you don't have the potential pixmap fix. - Jay


Date: Mon, 5 May 2008 21:01:10 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: [M3devel] new problem linking on NT386
I've rebuild my cm3 system using the latest sources.
 
I am now having a failure linking certain programs that used to build without problems.
 
I've listed the linker output from one of the programs below.  The issue seems to be an unresolved external symbol _WinMain at 16 .
 
Any ideas on what has changed and how to get this working again?
 
Microsoft (R) Incremental Linker Version 9.00.21022.08Copyright (C) Microsoft Corporation.  All rights reserved.
 
/out:CV_MessageTool.exe /subsystem:windows /entry:WinMainCRTStartup /nodefaultlib /debug /incremental:no /opt:ref /delayload:wsock32.dll /delayload:advapi32.dll /delayload:gdi32.dll /delayload:netapi32.dll /delayload:user32.dll /delayload:comctl32.dll delayimp.lib _m3main.obj iconRes.obj Resources.io Resources.mo Main.mo C:\cm3\pkg\windowsResources\NT386\windowsResources.lib C:\cm3\pkg\libSciRes3\NT386\libSciRes3.lib C:\cm3\pkg\stable\NT386\stable.lib C:\cm3\pkg\serial2\NT386\serial2.lib C:\cm3\pkg\netobj\NT386\m3netobj.lib C:\cm3\pkg\parseparams\NT386\m3parseparams.lib C:\cm3\pkg\formsvbt\NT386\m3formsvbt.lib C:\cm3\pkg\videovbt\NT386\videovbt.lib C:\cm3\pkg\jvideo\NT386\jvideo.lib C:\cm3\pkg\web\NT386\web.lib C:\cm3\pkg\tcp\NT386\m3tcp.lib C:\cm3\pkg\formsvbtpixmaps\NT386\m3formsvbtpixmaps.lib C:\cm3\pkg\vbtkit\NT386\m3vbtkit.lib C:\cm3\pkg\ui\NT386\m3ui.lib C:\cm3\pkg\libm3\NT386\m3.lib C:\cm3\pkg\m3core\NT386\m3core.lib winspool.lib comctl32.lib wsock32.lib comdlg32.lib netapi32.lib gdi32.lib user32.lib advapi32.lib kernel32.lib msvcrt.lib LINK : warning LNK4199: /DELAYLOAD:wsock32.dll ignored; no imports found from wsock32.dllLINK : warning LNK4199: /DELAYLOAD:advapi32.dll ignored; no imports found from advapi32.dllLINK : warning LNK4199: /DELAYLOAD:gdi32.dll ignored; no imports found from gdi32.dllLINK : warning LNK4199: /DELAYLOAD:netapi32.dll ignored; no imports found from netapi32.dllLINK : warning LNK4199: /DELAYLOAD:user32.dll ignored; no imports found from user32.dllLINK : warning LNK4199: /DELAYLOAD:comctl32.dll ignored; no imports found from comctl32.dllmsvcrt.lib(crtexew.obj) : error LNK2019: unresolved external symbol _WinMain at 16 referenced in function ___tmainCRTStartupCV_MessageTool.exe : fatal error LNK1120: 1 unresolved externals
Regards,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Tue May  6 05:28:10 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Mon, 05 May 2008 23:28:10 -0400
Subject: [M3devel] pixmap problem
In-Reply-To: 
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	
Message-ID: <481F9804.1E75.00D7.1@scires.com>

Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've
copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad
news is that now I am getting a command window opening up in addition to
the GUI window when the program runs.  This behavior does not occur on
v4.1.  The command window seems to be the stdout/stderr of the GUI
program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which
needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy

>>> Jay  5/5/2008 10:47 PM >>>
Randy, Yes.
The NT386 config files are all checked in.
You can use them verbatim. You don't need cminstall, I never use it,
and you shouldn't need to edit the config files at all, any edits I
make, I check in, and should be usable on all machines.
As long as you set %PATH%/%INCLUDE%/%LIB%.
If I'm wrong, I'd like to know why and try to fix.
 
Consider the config files just part of cm3.exe.
Not generally to be changed locally. Unless, well, unless you intend
to, and you should strive to make one form that is usable by all.
 
 - Jay


Date: Mon, 5 May 2008 22:42:30 -0400
From: rcoleburn at scires.com 
To: jayk123 at hotmail.com 
Subject: RE: [M3devel] pixmap problem

Jay,
When you say "took the updated config file", what do you mean?  Are you
saying I need a different cm3.cfg file?
Regards,
Randy

>>> Jay  5/5/2008 9:54 PM >>>
And you took the updated config file?
The way you can tell is that, roughly speaking, hand.obj should be in
NT386\_m3responsefile0.txt.
Or _m3responsefile1.txt, or, well, somewhere.
Anyway, I think I saw the attachment, I can check later..and with 4.1
as I said..
 
I can see about making the fix not depend on config file changes...but
it's not terrible asis, and I'd really like to merge more of the quake
code into cm3.exe..
 
 - Jay

Date: Mon, 5 May 2008 21:18:12 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com 
Subject: Re: [M3devel] pixmap problem

Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly
when the buildstandalone() directive is used.
 
Regards,
Randy

>>> Jay  5/5/2008 7:04 PM >>>
Thanks. I'll look into this tonight probably, as well as with 4.1
assuming I can find my binaries and source for it (probably).

COULD BE the pixmap problem is something else and 4.1 also has the
problem I fixed. We'll see. No need to speculate (unless I can't find my
4.1).

 - Jay


Date: Mon, 5 May 2008 10:59:27 -0400
From: rcoleburn at scires.com 
To: jayk123 at hotmail.com 
CC: m3devel at elegosoft.com 
Subject: RE: [M3devel] pixmap problem

Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files
or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy

>>> Jay  5/4/2008 11:46 AM >>>
Randy, Please try with /current/ source, as of this morning Sunday May
4 -- the changes are ALL in NT386.common, so you MUST use MY config
files, which are checked in verbatim, or you should be able edit
whatever config files you are using.
 
(It's not really a config file issue, don't blame the general confusion
people have with them.)
 
I'll try to try later, but I don't have the source right now, gotta
look on other machines, and I think it's on a machine on loan.
  Or send it to me again.
I'd also like to know if this worked with 4.1, or with any release that
offered dynamic linking to m3core.dll, on Windows.
  I recall a claim that it did. If today's change fixes it, I should be
able to investigate 4.1.
3.6 did not have such linking.
If today's change does not help, well, I still plan on debugging it at
some point..
 
If you aren't current and getting so is difficult, just send the
attachment again, it's easy for me to test.
 
Thanks,
 - Jay

From: jayk123 at hotmail.com 
To: hosking at cs.purdue.edu; rcoleburn at scires.com 
Date: Sat, 19 Jan 2008 08:52:08 +0000
CC: m3devel at elegosoft.com 
Subject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.
I was going to try on PPC_DARWIN but I guess Tony's info suffices.
 
I tried rolling hand.c back to before I changed (months/year ago),
since it is involved in bit twiddling, no change, phew.
 
Debugging here is a big humungous pain.
NT386 has good stacks and line numbers, but no locals or type info, I'd
really sometime like to get Codeview info into those .objs...I think it
is documented well enough, but still not necessarily easy, or maybe have
a C generating backend partly for this reason (and to bring up more
targets, using native tools), and function calls in disassembly I think
don't resolve; NT386GNU can't yet build this, though it will soon, but
I'm not familiar with gdb and there appears to be no type info. I'm
building m3gdb right now, I don't know if it will work, I hope it has
type info, and I'm not familiar with the relevant code. In gdb I
struggle just to view bytes in memory, add numbers to addresses and see
those, etc. I think for MY problem, I'm going to link in C code to dump
the structs. There is tracing code and I enabled it, but even it crashes
in Text_Length. At least MY problem crashes, hopefully near the problem,
whereas your problem goes all the way through to completion with no
stopping to hint where the problem is. Darn it. :) on the mock rudeness
and :( on the lack of a crash.
 
You write the bundle out and it matches, so that doesn't rule out
bundles as being the problem? (darn)
And bundles look pretty simple, a bundle is just a generated source
file with a constant in it.
Maybe newline problems? That wouldn't make sense. I just downloaded
some program that might let me separately view the ppm, maybe it'll
reveal something.
 
The bad behavior has like regularly spaced solid color veritical bars a
few pixels side across the whole picture, and regularly spaced vertical
stripes from the correct picture alternating with that. Perhaps someone
with ppm/bitmap/graphics experience has seen this behavior and it
results from some common pixmap mismanagement we could look for?
 
I have to say this is very surprising.
 
I always wondered, and now I pretty much assume -- Modula-3 never
imports/exports data in its dynamic linking, right? It alway
imports/exports functions, right?
On Windows, functions have an optional optimization, but data must be
handled differently at compile time if it is going to be dynamically
imported.
For functions, if you don't apply the optimization at compile time, the
linker will just generate a single instruction thunk instead.
 
That is, given a symbol Foo, there is a symbol __imp__Foo that is a
pointer to the actual foo in another .dll/.so.
The loader only patches pointers, one per import if you build your .dll
correctly, it doesn't patch instructions or code strewn throughout a
.dll, just one contiguous array of pointers. MAYBE they don't have to be
contiguous for each .dl you import from.
 
That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my
.dll/.exe typically has an array:
 
pointer to msvcrt!fopen
pointer to msvcrt!fclose
null
pointer to kernel32!Sleep
 
But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not
be adjacent.
 
So, going back, my point/question is that, if the compiler knows the
function is imported, it can call through __imp__Foo instead of calling
Foo.
But if it calls Foo and you import Foo, the linker will create the
function Foo that just jmps through __imp__Foo.
That doesn't work for data though. There's no ability to intervenve
like that.
So for imported data, the compiler must generated a read and
dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to
be imported.
Data imports may be faster when appropriate, but for this reason, I'd
say they aren't worth it.
And for this reason, I HOPE Modula-3 never imports/exports data.
 
Oh, you could, for data, always reference the pointer __imp_Foo, and if
non materializes, create one.
However that would suck perf in order to make an uncommon case work.
I hope Modula-3 doesn't do that either. :)
Though I guess since this global data in question...maybe it is
rare???
 
Later,
 - Jay



> From: hosking at cs.purdue.edu 
> Date: Sat, 19 Jan 2008 03:09:47 -0500
> To: rcoleburn at scires.com 
> CC: m3devel at elegosoft.com 
> Subject: Re: [M3devel] pixmap problem
> 
> Looks fine to me on I386_DARWIN.
> 
> On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:
> 
> > 
> 


Need to know the score, the latest news, or you need your Hotmail*-get
your "fix" Check it out. ( http://www.msnmobilefix.com/Default.aspx ) 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Tue May  6 05:38:03 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 6 May 2008 03:38:03 +0000
Subject: [M3devel] pixmap problem
In-Reply-To: <481F9804.1E75.00D7.1@scires.com>
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	 
	<481F9804.1E75.00D7.1@scires.com>
Message-ID: 

Randy, don't worry.
Two of these problems are trivial to fix -- PKG_USE and popups.
The pixmap one will need debugging.
 
 - Jay


Date: Mon, 5 May 2008 23:28:10 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem

Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad news is that now I am getting a command window opening up in addition to the GUI window when the program runs.  This behavior does not occur on v4.1.  The command window seems to be the stdout/stderr of the GUI program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy>>> Jay  5/5/2008 10:47 PM >>>Randy, Yes.The NT386 config files are all checked in.You can use them verbatim. You don't need cminstall, I never use it, and you shouldn't need to edit the config files at all, any edits I make, I check in, and should be usable on all machines.As long as you set %PATH%/%INCLUDE%/%LIB%.If I'm wrong, I'd like to know why and try to fix. Consider the config files just part of cm3.exe.Not generally to be changed locally. Unless, well, unless you intend to, and you should strive to make one form that is usable by all.  - Jay


Date: Mon, 5 May 2008 22:42:30 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay,
When you say "took the updated config file", what do you mean?  Are you saying I need a different cm3.cfg file?
Regards,
Randy>>> Jay  5/5/2008 9:54 PM >>>And you took the updated config file?The way you can tell is that, roughly speaking, hand.obj should be in NT386\_m3responsefile0.txt.Or _m3responsefile1.txt, or, well, somewhere.Anyway, I think I saw the attachment, I can check later..and with 4.1 as I said.. I can see about making the fix not depend on config file changes...but it's not terrible asis, and I'd really like to merge more of the quake code into cm3.exe..  - Jay


Date: Mon, 5 May 2008 21:18:12 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem
Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly when the buildstandalone() directive is used.
 
Regards,
Randy>>> Jay  5/5/2008 7:04 PM >>>Thanks. I'll look into this tonight probably, as well as with 4.1 assuming I can find my binaries and source for it (probably).COULD BE the pixmap problem is something else and 4.1 also has the problem I fixed. We'll see. No need to speculate (unless I can't find my 4.1). - Jay


Date: Mon, 5 May 2008 10:59:27 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problem
Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy>>> Jay  5/4/2008 11:46 AM >>>Randy, Please try with /current/ source, as of this morning Sunday May 4 -- the changes are ALL in NT386.common, so you MUST use MY config files, which are checked in verbatim, or you should be able edit whatever config files you are using. (It's not really a config file issue, don't blame the general confusion people have with them.) I'll try to try later, but I don't have the source right now, gotta look on other machines, and I think it's on a machine on loan.  Or send it to me again.I'd also like to know if this worked with 4.1, or with any release that offered dynamic linking to m3core.dll, on Windows.  I recall a claim that it did. If today's change fixes it, I should be able to investigate 4.1.3.6 did not have such linking.If today's change does not help, well, I still plan on debugging it at some point.. If you aren't current and getting so is difficult, just send the attachment again, it's easy for me to test. Thanks, - Jay


From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rcoleburn at scires.comDate: Sat, 19 Jan 2008 08:52:08 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.I was going to try on PPC_DARWIN but I guess Tony's info suffices. I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. Debugging here is a big humungous pain.NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)And bundles look pretty simple, a bundle is just a generated source file with a constant in it.Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something. The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for? I have to say this is very surprising. I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so.The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: pointer to msvcrt!fopenpointer to msvcrt!fclosenullpointer to kernel32!Sleep But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo.But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo.That doesn't work for data though. There's no ability to intervenve like that.So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it.And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.However that would suck perf in order to make an uncommon case work.I hope Modula-3 doesn't do that either. :)Though I guess since this global data in question...maybe it is rare??? Later, - Jay

> From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 03:09:47 -0500> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] pixmap problem> > Looks fine to me on I386_DARWIN.> > On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:> > > > 

Need to know the score, the latest news, or you need your Hotmail?-get your "fix" Check it out. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From wagner at elegosoft.com  Tue May  6 07:57:54 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 06 May 2008 07:57:54 +0200
Subject: [M3devel] m3cc build fails on older MacOS X
Message-ID: <20080506075754.o24j7xhx4wgokwwo@mail.elegosoft.com>

On % uname -a
Darwin apple.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30  
20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC  Power  
Macintosh powerpc:

echo ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./alloca.o  
./argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./dyn-string.o  
./fdmatch.o ./fibheap.o ./filename_cmp.o ./floatformat.o ./fnmatch.o  
./fopen_unlocked.o ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o  
./hashtab.o ./hex.o ./lbasename.o ./lrealpath.o  
./make-relative-prefix.o ./make-temp-file.o ./objalloc.o ./obstack.o  
./partition.o ./pexecute.o ./physmem.o ./pex-common.o ./pex-one.o  
./pex-unix.o ./safe-ctype.o ./sort.o ./spaces.o ./splay-tree.o  
./strerror.o ./strsignal.o ./unlink-if-ordinary.o ./xatexit.o  
./xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o  
./xstrndup.o > required-list
make[2]: Nothing to be done for `all'.
Makefile:191: *** Insufficient number of arguments (2) to function  
`patsubst'.  Stop.
make: *** [all-libcpp] Error 2
/bin/sh: line 1: cd: gcc: No such file or directory
make: *** No rule to make target `s-modes'.  Stop.
"/Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile", line 314: quake  
runtime error: unable to copy "./gcc/m3cgc1" to "./cm3cg": errno=2

--procedure--  -line-  -file---
cp_if              --  
postcp            314  /Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile
include_dir       360  /Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile
                     9   
/Users/wagner/work/cm3/m3-sys/m3cc/PPC_DARWIN/m3make.args

Fatal Error: package build failed
  ==> m3-sys/m3cc done

Any ideas?

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  Tue May  6 08:16:13 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 06 May 2008 08:16:13 +0200
Subject: [M3devel] m3tests again
Message-ID: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>

Hi Jay,

after several small fixes to the regression scripts, the nightrun
now shows for me

  >>> test_m3tests error extract:
  >>> failed tests: p116b p172 p185 p204 p206 p207 p209 p210 r001 e020  
e026 e029
  >>> 12 in test_m3tests 2008-05-06-01-30-23  
/home/wagner/work/cm3-ws/luthien-2008-05-06-01-30-23

One week ago there were only 6. Could you have a closer look at this?
I'm still busy with other projects.

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  Tue May  6 09:48:30 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 06 May 2008 09:48:30 +0200
Subject: [M3devel] build fails on NT386
In-Reply-To: <481F25FA.1E75.00D7.1@scires.com>
References: <481EFC54.1E75.00D7.1@scires.com>
	<481F2363.1E75.00D7.1@scires.com> <481F25FA.1E75.00D7.1@scires.com>
Message-ID: <20080506094830.lsbh8osejkgcs0cg@mail.elegosoft.com>

Quoting Randy Coleburn :

> Update:
>
> I tried to get around the problem by manually building & shipping   
> the sysutils package, then running scripts\win\upgrade.cmd again.

Randy, this is a new package needed for several quake extensions.
It has been added some months ago. Obviously nobody has updated
the cmd scripts. Could you add sysutils as prerequisite to all
scripts building cm3?

Olaf

> Now the build fails as shown below:
>
> === package C:\CM3_Sandbox\cm3\m3-sys\m3quake ===
> +++ "cm3 -build  -DROOT=C:\\CM3_Sandbox\\cm3   
> -DCM3_VERSION_TEXT=d5.7.0 -DCM3_VER
> SION_NUMBER=050700 -DCM3_LAST_CHANGED=2008-03-16 && cm3 -ship   
> -DROOT=C:\\CM3_San
> dbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_VERSION_NUMBER=050700   
> -DCM3_LAST_CHANG
> ED=2008-03-16" +++
> --- building in NT386 ---
>
> ignoring ..\src\m3overrides
>
> new source -> compiling Quake.i3
> new source -> compiling QCompiler.i3
> new source -> compiling QCode.i3
> new source -> compiling QValue.i3
> new source -> compiling QVSeq.i3
> new source -> compiling QVTbl.i3
> new source -> compiling QVal.i3
> new source -> compiling QMachine.i3
> new source -> compiling QToken.i3
> new source -> compiling QIdent.i3
> new source -> compiling Quake.m3
> new source -> compiling QToken.m3
> new source -> compiling QIdent.m3
> new source -> compiling QScanner.i3
> new source -> compiling QScanner.m3
> new source -> compiling QCode.m3
> new source -> compiling QCompiler.m3
> new source -> compiling QValue.m3
> new source -> compiling QVTbl.m3
> new source -> compiling QVSeqRep.i3
> new source -> compiling QVSeq.m3
>
> Fatal Error: bad version stamps: SystemWin32.m3
>
> version stamp mismatch: WinSock.gethostname
>   <4ccceffe6a8d6438> => SystemWin32.m3
>   <0e719d1414b51c34> => WinSock.i3
> SystemWin32.m3: missing imported type: _te9593bef
> ERROR: "cm3 -build  -DROOT=C:\\CM3_Sandbox\\cm3   
> -DCM3_VERSION_TEXT=d5.7.0 -DCM3_
> VERSION_NUMBER=050700 -DCM3_LAST_CHANGED=2008-03-16 && cm3 -ship   
> -DROOT=C:\\CM3_
> Sandbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_VERSION_NUMBER=050700   
> -DCM3_LAST_CH
> ANGED=2008-03-16"
> ERROR: cd C:\CM3_Sandbox\cm3\m3-sys\m3quake
> ERROR: set INSTALLROOT=C:\cm3
>
> C:\CM3_Sandbox\cm3\scripts\win>
>
> Please advise.
>
> Regards,
> Randy
>
>>>> "Randy Coleburn"  5/5/2008 3:10 PM >>>
> I have done a CVS update and decided to rebuild everything.
>
> I used the script in scripts\win\upgrade.cmd
>
> Here is a snippet of the output where it fails:
>
> ..\src\values => c:\cm3\pkg\m3front\src\values
>   Module.i3         Module.m3         Value.i3          Value.m3
>   ValueRep.i3       Constant.i3       Constant.m3       Decl.m3
>   Decl.i3           EnumElt.i3        EnumElt.m3        Exceptionz.i3
>   Exceptionz.m3     External.i3       External.m3       Field.i3
>   Field.m3          Formal.i3         Formal.m3         Ident.i3
>   Ident.m3          Method.m3         Method.i3         Procedure.i3
>   Procedure.m3      Revelation.m3     Revelation.i3     Tipe.i3
>   Tipe.m3           Variable.i3       Variable.m3
> === package C:\CM3_Sandbox\cm3\m3-sys\m3quake ===
> +++ "cm3 -build  -DROOT=C:\\CM3_Sandbox\\cm3   
> -DCM3_VERSION_TEXT=d5.7.0 -DCM3_VER
> SION_NUMBER=050700 -DCM3_LAST_CHANGED=2008-03-16 && cm3 -ship   
> -DROOT=C:\\CM3_San
> dbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_VERSION_NUMBER=050700   
> -DCM3_LAST_CHANG
> ED=2008-03-16" +++
> --- building in NT386 ---
>
> ignoring ..\src\m3overrides
>
> "C:\CM3_Sandbox\cm3\m3-sys\m3quake\src\m3makefile", line 14: quake   
> runtime error
> : unable to open "c:\cm3\pkg\sysutils\NT386\.M3EXPORTS" for reading
>
> --procedure--  -line-  -file---
> import             --  
> include_dir        14  C:\CM3_Sandbox\cm3\m3-sys\m3quake\src\m3makefile
>                     8  C:\CM3_Sandbox\cm3\m3-sys\m3quake\NT386\m3make.args
>
> Fatal Error: package build failed
> ERROR: "cm3 -build  -DROOT=C:\\CM3_Sandbox\\cm3   
> -DCM3_VERSION_TEXT=d5.7.0 -DCM3_
> VERSION_NUMBER=050700 -DCM3_LAST_CHANGED=2008-03-16 && cm3 -ship   
> -DROOT=C:\\CM3_
> Sandbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_VERSION_NUMBER=050700   
> -DCM3_LAST_CH
> ANGED=2008-03-16"
> ERROR: cd C:\CM3_Sandbox\cm3\m3-sys\m3quake
> ERROR: set INSTALLROOT=C:\cm3
>
> C:\CM3_Sandbox\cm3\scripts\win>
>
> Please advise.
>
> Regards,
> Randy
>



-- 
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  Tue May  6 10:07:11 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 06 May 2008 10:07:11 +0200
Subject: [M3devel] www.opencm3.net/m3tests
In-Reply-To: 
References: <313767.59466.qm@web27115.mail.ukl.yahoo.com>
	
Message-ID: <20080506100711.d2rzqie6ow08csgs@mail.elegosoft.com>

Quoting Jay :

> The "problem" here, a really really small one, is just that the link  
>  and mt commands got echoed.
> Olaf made them not echoed. I then made them conditionally echoed.
>   I made m3-sys\m3tests define M3TESTS so that NT386.common doesn't echo.
> It's not a big deal either way.
> Aha -- tests in other directories would have a problem, and I think   
> there are some.
>
> I like more echoing usually, so the system explains what is going on,
> instead of the vaguer "linking foo" sort of message.
> Granted, nobody bothers watching gcc run assembler commands, so I   
> guess it is just quite gray.

Jay, cm3 needs to behave the same on all platforms. By default
commands should _not_ be echoed to stdout or stderr; that's what the
-commands switch is for: this gives you exactly the commands the
compiler issues to invoke other tools.

For more verbose output, you may also depend on the -verbose or the
-debug switches.

Please adapt the configuration files that bey default all echoing
of commands is off.

Olaf

> I don't know how to run the Tinderbox either yet, sorry.
> I tried.
>
> For adding tests, well, there is m3-sys\m3tests.
> That is where a lot of the tests are, but not all.
> I am not sure where tests belong. I added a small number there.
> They are named with just a letter and a number.
> The letters have some meaning, explained in the m3makefile.
> "p" is programs that are run and their stdout/stderr compared   
> against expected
> "e" is programs build and the errors from the compiler checked to be  
>  reasonable.
>   I don't think in general they are expected to successfully compile  
>  or run, though the case of "warnings" may be unclear.
> "c" is programs built so a human can look at the generated code.
> There is another case I think for human checking.
> The numbers are just 001, 002, 003, etc.
> Each hundred tests are in a separate directory, like p0\p001,   
> p0\p002, p1\p100, p1\101, etc.
>
> Something like this.
> Wherever I have details wrong, just look in m3-sys\m3tests. It's   
> pretty simple, obvious, and well commented.
>
> The output is a little clearer if you have a working diff.exe on the path.
> Then what you do is search for "@@" in the output.
>
>  - Jay
>
>
> Date: Tue, 6 May 2008 03:46:27 +0200From: dabenavidesd at yahoo.esTo:   
> m3devel at elegosoft.comSubject: [M3devel] www.opencm3.net/m3testsDear   
> developers:Does the recent tests on NT386 seem broken because a   
> recent change on the m3-sys tree, or is the HTML bad generated, I   
> mean can you check the last tests Sunday, May 4th (p001 to p042) has  
>  a red background   
> http://www.opencm3.net/m3tests/m3tests-NT386-2008-04-23-13-30-57.html
p002 Text
Comparing files P0\P002\stdout.build and ..\SRC\P0\P002\STDOUT.BUILD***** P0\P002\stdout.buildlink @_m3responsefile0.txt 2>&1 > pgm.lstmt /nologo /manifest pgm.exe.manifest /outputresource:pgm.exe;1***** ..\SRC\P0\P002\STDOUT.BUILD*****Comparing files P0\P002\stderr.build and ..\SRC\P0\P002\STDERR.BUILDFC: no differences encounteredComparing files P0\P002\stdout.pgm and ..\SRC\P0\P002\STDOUT.PGMFC: no differences encounteredComparing files P0\P002\stderr.pgm and ..\SRC\P0\P002\STDERR.PGMFC: no differences encounteredand almost the same pattern in the above tests.I would suggest if it is thinkable using NT386 variant with a complete dedicated machine/system, I can try to set up one this week and send the data back (the machine is behind a proxy), but I don't remember the mail explaining the set up, and also want to know if there is a chance of run the tests with one run script.Also what is the best natural way to put a new tests, and the standard name it should   
> have?Thanks
>
>
> Enviado desde Correo Yahoo!La bandeja de entrada m?s inteligente.



-- 
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 jayk123 at hotmail.com  Tue May  6 12:49:11 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 6 May 2008 10:49:11 +0000
Subject: [M3devel] m3cc build fails on older MacOS X
In-Reply-To: <20080506075754.o24j7xhx4wgokwwo@mail.elegosoft.com>
References: <20080506075754.o24j7xhx4wgokwwo@mail.elegosoft.com>
Message-ID: 

I don't know what these Darwin versions are.
Mac OSX 10.0? 10.1? 10.2? 10.3? 10.4? 10.5?
I used to run 10.2 and could perhaps bring it back (though I'd hate to lose my PPC_LINUX install.. :( )
 
> make[2]: Nothing to be done for `all'.> Makefile:191: *** Insufficient number of arguments (2) to function > `patsubst'. Stop.
Hopefully that's enough context though.
 
The rest is a cascade.
What happens if you remove all my m3makefile wierdness (which works everywhere else..) and just configure and make?
 
Can I ssh into this?
 
 - Jay



> Date: Tue, 6 May 2008 07:57:54 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] m3cc build fails on older MacOS X> > On % uname -a> Darwin apple.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 > 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power > Macintosh powerpc:> > echo ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./alloca.o > ./argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./dyn-string.o > ./fdmatch.o ./fibheap.o ./filename_cmp.o ./floatformat.o ./fnmatch.o > ./fopen_unlocked.o ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o > ./hashtab.o ./hex.o ./lbasename.o ./lrealpath.o > ./make-relative-prefix.o ./make-temp-file.o ./objalloc.o ./obstack.o > ./partition.o ./pexecute.o ./physmem.o ./pex-common.o ./pex-one.o > ./pex-unix.o ./safe-ctype.o ./sort.o ./spaces.o ./splay-tree.o > ./strerror.o ./strsignal.o ./unlink-if-ordinary.o ./xatexit.o > ./xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o > ./xstrndup.o > required-list> make[2]: Nothing to be done for `all'.> Makefile:191: *** Insufficient number of arguments (2) to function > `patsubst'. Stop.> make: *** [all-libcpp] Error 2> /bin/sh: line 1: cd: gcc: No such file or directory> make: *** No rule to make target `s-modes'. Stop.> "/Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile", line 314: quake > runtime error: unable to copy "./gcc/m3cgc1" to "./cm3cg": errno=2> > --procedure-- -line- -file---> cp_if -- > postcp 314 /Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile> include_dir 360 /Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile> 9 > /Users/wagner/work/cm3/m3-sys/m3cc/PPC_DARWIN/m3make.args> > Fatal Error: package build failed> ==> m3-sys/m3cc done> > Any ideas?> > 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 jayk123 at hotmail.com  Tue May  6 12:57:01 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 6 May 2008 10:57:01 +0000
Subject: [M3devel] www.opencm3.net/m3tests
In-Reply-To: <20080506100711.d2rzqie6ow08csgs@mail.elegosoft.com>
References: <313767.59466.qm@web27115.mail.ukl.yahoo.com>
	 
	<20080506100711.d2rzqie6ow08csgs@mail.elegosoft.com>
Message-ID: 

Olaf, I don't entirely agree.
The logs should be fairly informative without intervention.
Just not too verbose. I'd would rather remove the lines that say "compiling" and show the cm3cg invocations.
But more than one line per source file is too much.
-commands doesn't really work. Lots of bogus extra commands are echoed (rm .tmp), and not all the commands that are run are echoed.
 
I understand that stability for tests is also a goal, but information for the interactive user and for post mortem debugging via a log is also valuable, and these are contrary to stability-for-tests. Somehow contradictory goals need to be met.
 
How about a compromise?
How about we always log more stuff to TARGET/cm3.log?
 And then exactly what you want to stdout/stderr?
While, as I said, more than one line per file is overkill, as part of this compromise I'd be willing to include the cm3cg and as invocation.
 
Have folks used build.exe in the Windows NT DDK?
It's model is close to what you get here.
It has three sets of information:
  to the console/stdout 
  build.log, build.exe is a wrapper over make, and this includes all the make output -- all the command lines run 
  build.err, a small subset of console/stdout output
 
My "design" here has been to avoid over-verbosity. Link and mt run on the order of once, or a small number of times, per directory, so showing the full command line (response files...) isn't so verbose -- vs. say something shown once per compiled file.
 
There's another "problem" here that I have partly fixed.
Underlying errors are not shown on console/stdout/stderr.
They are often in like TARGET/m3core.lst.
 
I changed stuff to refer to that file, after having hunted the errors down myself slowly the first time.
 
We could change things to alway says "see TARGET/cm3.log" for more information, or somesuch.
 
 - Jay



> Date: Tue, 6 May 2008 10:07:11 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] www.opencm3.net/m3tests> > Quoting Jay :> > > The "problem" here, a really really small one, is just that the link > > and mt commands got echoed.> > Olaf made them not echoed. I then made them conditionally echoed.> > I made m3-sys\m3tests define M3TESTS so that NT386.common doesn't echo.> > It's not a big deal either way.> > Aha -- tests in other directories would have a problem, and I think > > there are some.> >> > I like more echoing usually, so the system explains what is going on,> > instead of the vaguer "linking foo" sort of message.> > Granted, nobody bothers watching gcc run assembler commands, so I > > guess it is just quite gray.> > Jay, cm3 needs to behave the same on all platforms. By default> commands should _not_ be echoed to stdout or stderr; that's what the> -commands switch is for: this gives you exactly the commands the> compiler issues to invoke other tools.> > For more verbose output, you may also depend on the -verbose or the> -debug switches.> > Please adapt the configuration files that bey default all echoing> of commands is off.> > Olaf> > > I don't know how to run the Tinderbox either yet, sorry.> > I tried.> >> > For adding tests, well, there is m3-sys\m3tests.> > That is where a lot of the tests are, but not all.> > I am not sure where tests belong. I added a small number there.> > They are named with just a letter and a number.> > The letters have some meaning, explained in the m3makefile.> > "p" is programs that are run and their stdout/stderr compared > > against expected> > "e" is programs build and the errors from the compiler checked to be > > reasonable.> > I don't think in general they are expected to successfully compile > > or run, though the case of "warnings" may be unclear.> > "c" is programs built so a human can look at the generated code.> > There is another case I think for human checking.> > The numbers are just 001, 002, 003, etc.> > Each hundred tests are in a separate directory, like p0\p001, > > p0\p002, p1\p100, p1\101, etc.> >> > Something like this.> > Wherever I have details wrong, just look in m3-sys\m3tests. It's > > pretty simple, obvious, and well commented.> >> > The output is a little clearer if you have a working diff.exe on the path.> > Then what you do is search for "@@" in the output.> >> > - Jay> >> >> > Date: Tue, 6 May 2008 03:46:27 +0200From: dabenavidesd at yahoo.esTo: > > m3devel at elegosoft.comSubject: [M3devel] www.opencm3.net/m3testsDear > > developers:Does the recent tests on NT386 seem broken because a > > recent change on the m3-sys tree, or is the HTML bad generated, I > > mean can you check the last tests Sunday, May 4th (p001 to p042) has > > a red background > > http://www.opencm3.net/m3tests/m3tests-NT386-2008-04-23-13-30-57.html
p002 Text
Comparing files P0\P002\stdout.build and ..\SRC\P0\P002\STDOUT.BUILD***** P0\P002\stdout.buildlink @_m3responsefile0.txt 2>&1 > pgm.lstmt /nologo /manifest pgm.exe.manifest /outputresource:pgm.exe;1***** ..\SRC\P0\P002\STDOUT.BUILD*****Comparing files P0\P002\stderr.build and ..\SRC\P0\P002\STDERR.BUILDFC: no differences encounteredComparing files P0\P002\stdout.pgm and ..\SRC\P0\P002\STDOUT.PGMFC: no differences encounteredComparing files P0\P002\stderr.pgm and ..\SRC\P0\P002\STDERR.PGMFC: no differences encounteredand almost the same pattern in the above tests.I would suggest if it is thinkable using NT386 variant with a complete dedicated machine/system, I can try to set up one this week and send the data back (the machine is behind a proxy), but I don't remember the mail explaining the set up, and also want to know if there is a chance of run the tests with one run script.Also what is the best natural way to put a new tests, and the standard name it should > > have?Thanks> >> >> > Enviado desde Correo Yahoo!La bandeja de entrada m?s inteligente.> > > > -- > 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  Tue May  6 13:02:47 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 06 May 2008 13:02:47 +0200
Subject: [M3devel] m3cc build fails on older MacOS X
In-Reply-To: 
References: <20080506075754.o24j7xhx4wgokwwo@mail.elegosoft.com>
	
Message-ID: <20080506130247.50uj68o11twcgkog@mail.elegosoft.com>

Quoting Jay :

> I don't know what these Darwin versions are.
> Mac OSX 10.0? 10.1? 10.2? 10.3? 10.4? 10.5?
> I used to run 10.2 and could perhaps bring it back (though I'd hate   
> to lose my PPC_LINUX install.. :( )
>
>> make[2]: Nothing to be done for `all'.> Makefile:191: ***   
>> Insufficient number of arguments (2) to function > `patsubst'. Stop.
> Hopefully that's enough context though.
>
> The rest is a cascade.
> What happens if you remove all my m3makefile wierdness (which works   
> everywhere else..) and just configure and make?
>
> Can I ssh into this?

Not currently, but I could arrange that sometime this evening (19:00-
24:00 CEST), if that suits you. I'll take this computer with me on
holidays in two days, so it will probably not be available then.
But you can peek into it today if you want.

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 jayk123 at hotmail.com  Tue May  6 13:17:53 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 6 May 2008 11:17:53 +0000
Subject: [M3devel] www.opencm3.net/m3tests
In-Reply-To: 
References: <313767.59466.qm@web27115.mail.ukl.yahoo.com>
	 
	<20080506100711.d2rzqie6ow08csgs@mail.elegosoft.com> 
	
Message-ID: 

When I say show cm3cg/as invocations, I mean in this new TARGET/cm3.log.
As I said, I propose exactly the stdout/stderr you want, but then some other output always, a log file.
Also, about -commands, I have also claimed that it does work -- talking out of both sides of my mouth. The extra commands it prints are obviously harmless. I forget what doesn't print, maybe exec vs. q_exec? Also the '@' character wasn't working with q_exec, but that isn't necessarily relevant here..I forgot where I use exec vs. q_exec..
And there plenty of other ways to debug than -commands and it is "just" a debugging facility..
 
 - Jay


From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Tue, 6 May 2008 10:57:01 +0000Subject: Re: [M3devel] www.opencm3.net/m3tests


Olaf, I don't entirely agree.The logs should be fairly informative without intervention.Just not too verbose. I'd would rather remove the lines that say "compiling" and show the cm3cg invocations.But more than one line per source file is too much.-commands doesn't really work. Lots of bogus extra commands are echoed (rm .tmp), and not all the commands that are run are echoed. I understand that stability for tests is also a goal, but information for the interactive user and for post mortem debugging via a log is also valuable, and these are contrary to stability-for-tests. Somehow contradictory goals need to be met. How about a compromise?How about we always log more stuff to TARGET/cm3.log? And then exactly what you want to stdout/stderr?While, as I said, more than one line per file is overkill, as part of this compromise I'd be willing to include the cm3cg and as invocation. Have folks used build.exe in the Windows NT DDK?It's model is close to what you get here.It has three sets of information:  to the console/stdout   build.log, build.exe is a wrapper over make, and this includes all the make output -- all the command lines run   build.err, a small subset of console/stdout output My "design" here has been to avoid over-verbosity. Link and mt run on the order of once, or a small number of times, per directory, so showing the full command line (response files...) isn't so verbose -- vs. say something shown once per compiled file. There's another "problem" here that I have partly fixed.Underlying errors are not shown on console/stdout/stderr.They are often in like TARGET/m3core.lst. I changed stuff to refer to that file, after having hunted the errors down myself slowly the first time. We could change things to alway says "see TARGET/cm3.log" for more information, or somesuch.  - Jay

> Date: Tue, 6 May 2008 10:07:11 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] www.opencm3.net/m3tests> > Quoting Jay :> > > The "problem" here, a really really small one, is just that the link > > and mt commands got echoed.> > Olaf made them not echoed. I then made them conditionally echoed.> > I made m3-sys\m3tests define M3TESTS so that NT386.common doesn't echo.> > It's not a big deal either way.> > Aha -- tests in other directories would have a problem, and I think > > there are some.> >> > I like more echoing usually, so the system explains what is going on,> > instead of the vaguer "linking foo" sort of message.> > Granted, nobody bothers watching gcc run assembler commands, so I > > guess it is just quite gray.> > Jay, cm3 needs to behave the same on all platforms. By default> commands should _not_ be echoed to stdout or stderr; that's what the> -commands switch is for: this gives you exactly the commands the> compiler issues to invoke other tools.> > For more verbose output, you may also depend on the -verbose or the> -debug switches.> > Please adapt the configuration files that bey default all echoing> of commands is off.> > Olaf> > > I don't know how to run the Tinderbox either yet, sorry.> > I tried.> >> > For adding tests, well, there is m3-sys\m3tests.> > That is where a lot of the tests are, but not all.> > I am not sure where tests belong. I added a small number there.> > They are named with just a letter and a number.> > The letters have some meaning, explained in the m3makefile.> > "p" is programs that are run and their stdout/stderr compared > > against expected> > "e" is programs build and the errors from the compiler checked to be > > reasonable.> > I don't think in general they are expected to successfully compile > > or run, though the case of "warnings" may be unclear.> > "c" is programs built so a human can look at the generated code.> > There is another case I think for human checking.> > The numbers are just 001, 002, 003, etc.> > Each hundred tests are in a separate directory, like p0\p001, > > p0\p002, p1\p100, p1\101, etc.> >> > Something like this.> > Wherever I have details wrong, just look in m3-sys\m3tests. It's > > pretty simple, obvious, and well commented.> >> > The output is a little clearer if you have a working diff.exe on the path.> > Then what you do is search for "@@" in the output.> >> > - Jay> >> >> > Date: Tue, 6 May 2008 03:46:27 +0200From: dabenavidesd at yahoo.esTo: > > m3devel at elegosoft.comSubject: [M3devel] www.opencm3.net/m3testsDear > > developers:Does the recent tests on NT386 seem broken because a > > recent change on the m3-sys tree, or is the HTML bad generated, I > > mean can you check the last tests Sunday, May 4th (p001 to p042) has > > a red background > > http://www.opencm3.net/m3tests/m3tests-NT386-2008-04-23-13-30-57.html
p002 Text
Comparing files P0\P002\stdout.build and ..\SRC\P0\P002\STDOUT.BUILD***** P0\P002\stdout.buildlink @_m3responsefile0.txt 2>&1 > pgm.lstmt /nologo /manifest pgm.exe.manifest /outputresource:pgm.exe;1***** ..\SRC\P0\P002\STDOUT.BUILD*****Comparing files P0\P002\stderr.build and ..\SRC\P0\P002\STDERR.BUILDFC: no differences encounteredComparing files P0\P002\stdout.pgm and ..\SRC\P0\P002\STDOUT.PGMFC: no differences encounteredComparing files P0\P002\stderr.pgm and ..\SRC\P0\P002\STDERR.PGMFC: no differences encounteredand almost the same pattern in the above tests.I would suggest if it is thinkable using NT386 variant with a complete dedicated machine/system, I can try to set up one this week and send the data back (the machine is behind a proxy), but I don't remember the mail explaining the set up, and also want to know if there is a chance of run the tests with one run script.Also what is the best natural way to put a new tests, and the standard name it should > > have?Thanks> >> >> > Enviado desde Correo Yahoo!La bandeja de entrada m?s inteligente.> > > > -- > 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 jayk123 at hotmail.com  Tue May  6 13:25:21 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 6 May 2008 11:25:21 +0000
Subject: [M3devel] m3cc build fails on older MacOS X
In-Reply-To: <20080506130247.50uj68o11twcgkog@mail.elegosoft.com>
References: <20080506075754.o24j7xhx4wgokwwo@mail.elegosoft.com>
	 
	<20080506130247.50uj68o11twcgkog@mail.elegosoft.com>
Message-ID: 

Olaf, can you try without my m3makefile wierdness, that works elsewhere?
 
  cd %CVSROOT%/m3-sys/m3cc    mkdir obj1     cd obj1   ../gcc/configure --disable-bootstrap --enable-languages=c,cm3cg    make 
 I'm not sure of "cm3cg", it might be "m3cg".  And you can just omit that anyway, I doubt the error is m3 related. 
(Tony: I don't believe --srcdir is needed. configure figures it out; granted, maybe not trivially.) 
?
 I expect you will get the same error.  Which isn't the final answer, just some relevant data.   And if I'm wrong, well, that suggests some fix. 
 
 
 - Jay



> Date: Tue, 6 May 2008 13:02:47 +0200> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: RE: [M3devel] m3cc build fails on older MacOS X> > Quoting Jay :> > > I don't know what these Darwin versions are.> > Mac OSX 10.0? 10.1? 10.2? 10.3? 10.4? 10.5?> > I used to run 10.2 and could perhaps bring it back (though I'd hate > > to lose my PPC_LINUX install.. :( )> >> >> make[2]: Nothing to be done for `all'.> Makefile:191: *** > >> Insufficient number of arguments (2) to function > `patsubst'. Stop.> > Hopefully that's enough context though.> >> > The rest is a cascade.> > What happens if you remove all my m3makefile wierdness (which works > > everywhere else..) and just configure and make?> >> > Can I ssh into this?> > Not currently, but I could arrange that sometime this evening (19:00-> 24:00 CEST), if that suits you. I'll take this computer with me on> holidays in two days, so it will probably not be available then.> But you can peek into it today if you want.> > 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  Tue May  6 15:33:18 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 06 May 2008 15:33:18 +0200
Subject: [M3devel] cm3 command line interface and output;
	was: RE: 	www.opencm3.net/m3tests
In-Reply-To: 
References: <313767.59466.qm@web27115.mail.ukl.yahoo.com>
	
	<20080506100711.d2rzqie6ow08csgs@mail.elegosoft.com>
	
	
Message-ID: <20080506153318.a50ttk23488ksk00@mail.elegosoft.com>

Quoting Jay :

> When I say show cm3cg/as invocations, I mean in this new TARGET/cm3.log.
> As I said, I propose exactly the stdout/stderr you want, but then   
> some other output always, a log file.
> Also, about -commands, I have also claimed that it does work --   
> talking out of both sides of my mouth. The extra commands it prints   
> are obviously harmless. I forget what doesn't print, maybe exec vs.   
> q_exec? Also the '@' character wasn't working with q_exec, but that   
> isn't necessarily relevant here..I forgot where I use exec vs.   
> q_exec..
> And there plenty of other ways to debug than -commands and it is   
> "just" a debugging facility..

I've got a rather definite opinion about the output behaviour of
cm3. It's like this, and I would like others to comment, too:

  o cm3 without any switches (-commands, -debug, -verbose) should
    not output any called commands, neither to stdout nor stderr.
    It may print what it is doing in an abstract, target independent
    (short) way. This output may refer to compilation units, interfaces,
    modules, and compilation phases, but not to target specific commands
    and files (unless there are errors, of course) Even then I'd like
    to abstract from differences.

  o cm3 -silent should suppress the normal output, except for warnings
    and error messages.

  o cm3 -commands should output exactly all invokations of externals
    commands so that they can be re-executed from the command line
    if necessary.

I realize that it might not be this way in every aspect, so that
we may need to adapt the code here and there. But in my experience
it has worked this way quite well. Here are some points to consider:

  o We need consistent behaviour and output across all target platforms.
    This is not just a requirement of regression testing, but also of
    a consistent user interface. I don't want different behaviour on
    different platforms.

  o If -commands does not work as expected for some use case,
    we need to fix it.

  o If q_exec or whatever quake function is still deficient in this
    respect, we need to fix/adapt it. It should not be much effort.

  o I find the options -commands, -verbose, -debug, -silent a very
    good categorization of information types, intuitively understandable
    and usable in practive (as I've never had any problems with it, but
    have used them efficiently for years). So I don't see the point
    in changing anything, unless there is a better concept.

  o I don't think it is a good idea to write any log files by default
    (apart from the stdout and stderr streams).

This is of course just my opinion, but unless there are others in
favour of changes (and I'd like some motivation for them) I'd insist
that we keep the existing design.

Olaf

> From: jayk123 at hotmail.comTo: wagner at elegosoft.com;   
> m3devel at elegosoft.comDate: Tue, 6 May 2008 10:57:01 +0000Subject:   
> Re: [M3devel] www.opencm3.net/m3tests
>
>
> Olaf, I don't entirely agree.The logs should be fairly informative   
> without intervention.Just not too verbose. I'd would rather remove   
> the lines that say "compiling" and show the cm3cg invocations.But   
> more than one line per source file is too much.-commands doesn't   
> really work. Lots of bogus extra commands are echoed (rm .tmp), and   
> not all the commands that are run are echoed. I understand that   
> stability for tests is also a goal, but information for the   
> interactive user and for post mortem debugging via a log is also   
> valuable, and these are contrary to stability-for-tests. Somehow   
> contradictory goals need to be met. How about a compromise?How about  
>  we always log more stuff to TARGET/cm3.log? And then exactly what   
> you want to stdout/stderr?While, as I said, more than one line per   
> file is overkill, as part of this compromise I'd be willing to   
> include the cm3cg and as invocation. Have folks used build.exe in   
> the Windows NT DDK?It's model is close to what you get here.It has   
> three sets of information:  to the console/stdout   build.log,   
> build.exe is a wrapper over make, and this includes all the make   
> output -- all the command lines run   build.err, a small subset of   
> console/stdout output My "design" here has been to avoid   
> over-verbosity. Link and mt run on the order of once, or a small   
> number of times, per directory, so showing the full command line   
> (response files...) isn't so verbose -- vs. say something shown once  
>  per compiled file. There's another "problem" here that I have  
> partly  fixed.Underlying errors are not shown on  
> console/stdout/stderr.They  are often in like TARGET/m3core.lst. I  
> changed stuff to refer to  that file, after having hunted the errors  
> down myself slowly the  first time. We could change things to alway  
> says "see  TARGET/cm3.log" for more information, or somesuch.  - Jay
>
>> Date: Tue, 6 May 2008 10:07:11 +0200> From: wagner at elegosoft.com>   
>> To: m3devel at elegosoft.com> Subject: Re: [M3devel]   
>> www.opencm3.net/m3tests> > Quoting Jay :> > >   
>> The "problem" here, a really really small one, is just that the   
>> link > > and mt commands got echoed.> > Olaf made them not echoed.   
>> I then made them conditionally echoed.> > I made m3-sys\m3tests   
>> define M3TESTS so that NT386.common doesn't echo.> > It's not a big  
>>  deal either way.> > Aha -- tests in other directories would have a  
>>  problem, and I think > > there are some.> >> > I like more echoing  
>>  usually, so the system explains what is going on,> > instead of  
>> the  vaguer "linking foo" sort of message.> > Granted, nobody  
>> bothers  watching gcc run assembler commands, so I > > guess it is  
>> just  quite gray.> > Jay, cm3 needs to behave the same on all  
>> platforms.  By default> commands should _not_ be echoed to stdout  
>> or stderr;  that's what the> -commands switch is for: this gives  
>> you exactly  the commands the> compiler issues to invoke other  
>> tools.> > For  more verbose output, you may also depend on the  
>> -verbose or the>  -debug switches.> > Please adapt the  
>> configuration files that bey  default all echoing> of commands is  
>> off.> > Olaf> > > I don't know  how to run the Tinderbox either  
>> yet, sorry.> > I tried.> >> > For  adding tests, well, there is  
>> m3-sys\m3tests.> > That is where a lot  of the tests are, but not  
>> all.> > I am not sure where tests belong.  I added a small number  
>> there.> > They are named with just a letter  and a number.> > The  
>> letters have some meaning, explained in the  m3makefile.> > "p" is  
>> programs that are run and their stdout/stderr  compared > > against  
>> expected> > "e" is programs build and the  errors from the compiler  
>> checked to be > > reasonable.> > I don't  think in general they are  
>> expected to successfully compile > > or  run, though the case of  
>> "warnings" may be unclear.> > "c" is  programs built so a human can  
>> look at the generated code.> > There  is another case I think for  
>> human checking.> > The numbers are just  001, 002, 003, etc.> >  
>> Each hundred tests are in a separate  directory, like p0\p001, > >  
>> p0\p002, p1\p100, p1\101, etc.> >> >  Something like this.> >  
>> Wherever I have details wrong, just look in  m3-sys\m3tests. It's >  
>> > pretty simple, obvious, and well  commented.> >> > The output is  
>> a little clearer if you have a  working diff.exe on the path.> >  
>> Then what you do is search for  "@@" in the output.> >> > - Jay> >>  
>> >> > Date: Tue, 6 May 2008  03:46:27 +0200From:  
>> dabenavidesd at yahoo.esTo: > >  m3devel at elegosoft.comSubject:  
>> [M3devel] www.opencm3.net/m3testsDear  > > developers:Does the  
>> recent tests on NT386 seem broken because a  > > recent change on  
>> the m3-sys tree, or is the HTML bad generated,  I > > mean can you  
>> check the last tests Sunday, May 4th (p001 to  p042) has > > a red  
>> background > >   
>> http://www.opencm3.net/m3tests/m3tests-NT386-2008-04-23-13-30-57.html
p002 Text
Comparing files P0\P002\stdout.build and ..\SRC\P0\P002\STDOUT.BUILD***** P0\P002\stdout.buildlink @_m3responsefile0.txt 2>&1 > pgm.lstmt /nologo /manifest pgm.exe.manifest /outputresource:pgm.exe;1***** ..\SRC\P0\P002\STDOUT.BUILD*****Comparing files P0\P002\stderr.build and ..\SRC\P0\P002\STDERR.BUILDFC: no differences encounteredComparing files P0\P002\stdout.pgm and ..\SRC\P0\P002\STDOUT.PGMFC: no differences encounteredComparing files P0\P002\stderr.pgm and ..\SRC\P0\P002\STDERR.PGMFC: no differences encounteredand almost the same pattern in the above tests.I would suggest if it is thinkable using NT386 variant with a complete dedicated machine/system, I can try to set up one this week and send the data back (the machine is behind a proxy), but I don't remember the mail explaining the set up, and also want to know if there is a chance of run the tests with one run script.Also what is the best natural way to put a new tests, and the standard name it should > > have?Thanks> >> >> > Enviado desde Correo Yahoo!La bandeja de entrada m?s inteligente.> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:   
>> DE163214194>



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



From hosking at cs.purdue.edu  Tue May  6 15:56:40 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 6 May 2008 09:56:40 -0400
Subject: [M3devel] m3cc build fails on older MacOS X
In-Reply-To: 
References: <20080506075754.o24j7xhx4wgokwwo@mail.elegosoft.com>
	
	<20080506130247.50uj68o11twcgkog@mail.elegosoft.com>
	
Message-ID: 

yes,  it should be m m3cg.  --srcdir is not needed.

On May 6, 2008, at 7:25 AM, Jay wrote:

> Olaf, can you try without my m3makefile wierdness, that works  
> elsewhere?
>
>   cd %CVSROOT%/m3-sys/m3cc
>   mkdir obj1
>   cd obj1
>   ../gcc/configure --disable-bootstrap --enable-languages=c,cm3cg
>   make
>  I'm not sure of "cm3cg", it might be "m3cg".
>  And you can just omit that anyway, I doubt the error is m3 related.
> (Tony: I don't believe --srcdir is needed. configure figures it out;  
> granted, maybe not trivially.)
>
> ?
>  I expect you will get the same error.
>  Which isn't the final answer, just some relevant data.
>  And if I'm wrong, well, that suggests some fix.
>
>
>  - Jay
>
>
>
> > Date: Tue, 6 May 2008 13:02:47 +0200
> > From: wagner at elegosoft.com
> > To: jayk123 at hotmail.com
> > CC: m3devel at elegosoft.com
> > Subject: RE: [M3devel] m3cc build fails on older MacOS X
> >
> > Quoting Jay :
> >
> > > I don't know what these Darwin versions are.
> > > Mac OSX 10.0? 10.1? 10.2? 10.3? 10.4? 10.5?
> > > I used to run 10.2 and could perhaps bring it back (though I'd  
> hate
> > > to lose my PPC_LINUX install.. :( )
> > >
> > >> make[2]: Nothing to be done for `all'.> Makefile:191: ***
> > >> Insufficient number of arguments (2) to function > `patsubst'.  
> Stop.
> > > Hopefully that's enough context though.
> > >
> > > The rest is a cascade.
> > > What happens if you remove all my m3makefile wierdness (which  
> works
> > > everywhere else..) and just configure and make?
> > >
> > > Can I ssh into this?
> >
> > Not currently, but I could arrange that sometime this evening  
> (19:00-
> > 24:00 CEST), if that suits you. I'll take this computer with me on
> > holidays in two days, so it will probably not be available then.
> > But you can peek into it today if you want.
> >
> > 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 jayk123 at hotmail.com  Tue May  6 16:02:48 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 6 May 2008 14:02:48 +0000
Subject: [M3devel] cm3 command line interface and output;
	was: RE: 	www.opencm3.net/m3tests
In-Reply-To: <20080506153318.a50ttk23488ksk00@mail.elegosoft.com>
References: <313767.59466.qm@web27115.mail.ukl.yahoo.com>
	
	<20080506100711.d2rzqie6ow08csgs@mail.elegosoft.com>
	
	 
	<20080506153318.a50ttk23488ksk00@mail.elegosoft.com>
Message-ID: 

Well, Olaf, I see your point, but I don't entirely agree.
I believe there are contradictory goals.
Which is partly to say, there will always be "problems" here, though I think producing a more detailed log file is a good compromise.
 
In particular, consider the role of "remote debugging", or even local debugging.
Wouldn't it be great if many situations could be debugged from merely looking at "m3.log" from the first and only run that failed? What if the problem is intermittent? You can't always rely on running again with different switches. I have to post-mortem debug lots of stuff and logs are indispensible. They don't always work, and they can't always work, but they can be extremely helpful.
 
To a large extent, you need to plan for failure. There will be errors. When there is an error, what is the design that allows quickest easiest diagnosis, some large percentage of the time? A nice friendly abstract stdout that hides details, or something with more information? Or somethin in between like a friendly stdout and a verbose log file?
 
The need for a cross-platform user experience is unclear -- I want file names printed in a form my editor understands, and my editors unfortunately are not consistent. Perhaps, as you allude, the "success" ui should be cross platform, and in the face of an error, the experience can devolve and contain platform specific details. Here you can see the tests already having problems, as the paths have forward or backward slashes, and "crashes" have different appearances. So far this has been mostly papered over (which reminds me, I need to get the darwin and bsd variants; currently only NT and Linux are handled).
 
For regression tests, yes I understand.
However, stdout/stderr is a very crude thing.
It'd be nice if the code could make, uh, like, "function calls" to indicate what happened instead of random text that is meant to be both human and machine consumable.
But I know that's just too high tech to happen any time soon..
 
(Similarly, "function calls" to drive a compiler are a good idea to. "Command lines" are also very crude and type-unsafe..the whole problem with spaces....)
 
A good example I think of something that doesn't work well today is what happens when there are link errors.
The problem here isn't so much the echoing of commands, but the appearance of the linker output.
All you get is cm3 checks the exit code and/or the existance of the output file and stdout indicates a boolean success/faliure. User has to dig into another file to find the actual error. Now, again, I am talking out of both sides. I argue for a log for the verbose information, and now complain about having to dig into that log. I would at least like to have there be one such log, not one for the link output and nothing else. That would be a little better. The inconvenience of having to dig into a log is a more difficult problem, I know very well, related again to the crudeness of stdout. Because the linker has no structured way to report errors, other than an exit code, whatever wraps it is left to some crude device like attempting to "parse" the stdout. This is a well traveled path, and it can work quite well, but it is also frought with peril, as different linkers and different versions of linkers output errors differently...
 
As well, on the other end of things, you know, if you assume success, you really want less output.
make-dist.cmd is really good this way, though make-dist.py is not yet.
In there I suppress a LOT of output, but I do keep it in logs in case of failure..
 
I don't have a conclusion.
I understand the goals.
I also believe logging, to stdout or to a file, greatly aids debugging.
I think producing a log file in the output directory is a good compromise, and one I have seen successfully used.
  Though you don't want the easy out of having a log file to lead to the log file becoming too verbose. I have seen log files that take a while for some editors to open..and people throwing in "verbose" switches and not realize the damage they are doing. I did it myself once. I threw in /verbose on the Visual C++ linker and the output of that is so voluminous that it slows things down. It's great for debugging certain problems, but too expensive to put in all the time "just in case".
 
 - Jay


> Date: Tue, 6 May 2008 15:33:18 +0200> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: cm3 command line interface and output; was: RE: [M3devel] www.opencm3.net/m3tests> > Quoting Jay :> > > When I say show cm3cg/as invocations, I mean in this new TARGET/cm3.log.> > As I said, I propose exactly the stdout/stderr you want, but then > > some other output always, a log file.> > Also, about -commands, I have also claimed that it does work -- > > talking out of both sides of my mouth. The extra commands it prints > > are obviously harmless. I forget what doesn't print, maybe exec vs. > > q_exec? Also the '@' character wasn't working with q_exec, but that > > isn't necessarily relevant here..I forgot where I use exec vs. > > q_exec..> > And there plenty of other ways to debug than -commands and it is > > "just" a debugging facility..> > I've got a rather definite opinion about the output behaviour of> cm3. It's like this, and I would like others to comment, too:> > o cm3 without any switches (-commands, -debug, -verbose) should> not output any called commands, neither to stdout nor stderr.> It may print what it is doing in an abstract, target independent> (short) way. This output may refer to compilation units, interfaces,> modules, and compilation phases, but not to target specific commands> and files (unless there are errors, of course) Even then I'd like> to abstract from differences.> > o cm3 -silent should suppress the normal output, except for warnings> and error messages.> > o cm3 -commands should output exactly all invokations of externals> commands so that they can be re-executed from the command line> if necessary.> > I realize that it might not be this way in every aspect, so that> we may need to adapt the code here and there. But in my experience> it has worked this way quite well. Here are some points to consider:> > o We need consistent behaviour and output across all target platforms.> This is not just a requirement of regression testing, but also of> a consistent user interface. I don't want different behaviour on> different platforms.> > o If -commands does not work as expected for some use case,> we need to fix it.> > o If q_exec or whatever quake function is still deficient in this> respect, we need to fix/adapt it. It should not be much effort.> > o I find the options -commands, -verbose, -debug, -silent a very> good categorization of information types, intuitively understandable> and usable in practive (as I've never had any problems with it, but> have used them efficiently for years). So I don't see the point> in changing anything, unless there is a better concept.> > o I don't think it is a good idea to write any log files by default> (apart from the stdout and stderr streams).> > This is of course just my opinion, but unless there are others in> favour of changes (and I'd like some motivation for them) I'd insist> that we keep the existing design.> > Olaf> > > From: jayk123 at hotmail.comTo: wagner at elegosoft.com; > > m3devel at elegosoft.comDate: Tue, 6 May 2008 10:57:01 +0000Subject: > > Re: [M3devel] www.opencm3.net/m3tests> >> >> > Olaf, I don't entirely agree.The logs should be fairly informative > > without intervention.Just not too verbose. I'd would rather remove > > the lines that say "compiling" and show the cm3cg invocations.But > > more than one line per source file is too much.-commands doesn't > > really work. Lots of bogus extra commands are echoed (rm .tmp), and > > not all the commands that are run are echoed. I understand that > > stability for tests is also a goal, but information for the > > interactive user and for post mortem debugging via a log is also > > valuable, and these are contrary to stability-for-tests. Somehow > > contradictory goals need to be met. How about a compromise?How about > > we always log more stuff to TARGET/cm3.log? And then exactly what > > you want to stdout/stderr?While, as I said, more than one line per > > file is overkill, as part of this compromise I'd be willing to > > include the cm3cg and as invocation. Have folks used build.exe in > > the Windows NT DDK?It's model is close to what you get here.It has > > three sets of information: to the console/stdout build.log, > > build.exe is a wrapper over make, and this includes all the make > > output -- all the command lines run build.err, a small subset of > > console/stdout output My "design" here has been to avoid > > over-verbosity. Link and mt run on the order of once, or a small > > number of times, per directory, so showing the full command line > > (response files...) isn't so verbose -- vs. say something shown once > > per compiled file. There's another "problem" here that I have > > partly fixed.Underlying errors are not shown on > > console/stdout/stderr.They are often in like TARGET/m3core.lst. I > > changed stuff to refer to that file, after having hunted the errors > > down myself slowly the first time. We could change things to alway > > says "see TARGET/cm3.log" for more information, or somesuch. - Jay> >> >> Date: Tue, 6 May 2008 10:07:11 +0200> From: wagner at elegosoft.com> > >> To: m3devel at elegosoft.com> Subject: Re: [M3devel] > >> www.opencm3.net/m3tests> > Quoting Jay :> > > > >> The "problem" here, a really really small one, is just that the > >> link > > and mt commands got echoed.> > Olaf made them not echoed. > >> I then made them conditionally echoed.> > I made m3-sys\m3tests > >> define M3TESTS so that NT386.common doesn't echo.> > It's not a big > >> deal either way.> > Aha -- tests in other directories would have a > >> problem, and I think > > there are some.> >> > I like more echoing > >> usually, so the system explains what is going on,> > instead of > >> the vaguer "linking foo" sort of message.> > Granted, nobody > >> bothers watching gcc run assembler commands, so I > > guess it is > >> just quite gray.> > Jay, cm3 needs to behave the same on all > >> platforms. By default> commands should _not_ be echoed to stdout > >> or stderr; that's what the> -commands switch is for: this gives > >> you exactly the commands the> compiler issues to invoke other > >> tools.> > For more verbose output, you may also depend on the > >> -verbose or the> -debug switches.> > Please adapt the > >> configuration files that bey default all echoing> of commands is > >> off.> > Olaf> > > I don't know how to run the Tinderbox either > >> yet, sorry.> > I tried.> >> > For adding tests, well, there is > >> m3-sys\m3tests.> > That is where a lot of the tests are, but not > >> all.> > I am not sure where tests belong. I added a small number > >> there.> > They are named with just a letter and a number.> > The > >> letters have some meaning, explained in the m3makefile.> > "p" is > >> programs that are run and their stdout/stderr compared > > against > >> expected> > "e" is programs build and the errors from the compiler > >> checked to be > > reasonable.> > I don't think in general they are > >> expected to successfully compile > > or run, though the case of > >> "warnings" may be unclear.> > "c" is programs built so a human can > >> look at the generated code.> > There is another case I think for > >> human checking.> > The numbers are just 001, 002, 003, etc.> > > >> Each hundred tests are in a separate directory, like p0\p001, > > > >> p0\p002, p1\p100, p1\101, etc.> >> > Something like this.> > > >> Wherever I have details wrong, just look in m3-sys\m3tests. It's > > >> > pretty simple, obvious, and well commented.> >> > The output is > >> a little clearer if you have a working diff.exe on the path.> > > >> Then what you do is search for "@@" in the output.> >> > - Jay> >> > >> >> > Date: Tue, 6 May 2008 03:46:27 +0200From: > >> dabenavidesd at yahoo.esTo: > > m3devel at elegosoft.comSubject: > >> [M3devel] www.opencm3.net/m3testsDear > > developers:Does the > >> recent tests on NT386 seem broken because a > > recent change on > >> the m3-sys tree, or is the HTML bad generated, I > > mean can you > >> check the last tests Sunday, May 4th (p001 to p042) has > > a red > >> background > > > >> http://www.opencm3.net/m3tests/m3tests-NT386-2008-04-23-13-30-57.html
p002 Text
Comparing files P0\P002\stdout.build and ..\SRC\P0\P002\STDOUT.BUILD***** P0\P002\stdout.buildlink @_m3responsefile0.txt 2>&1 > pgm.lstmt /nologo /manifest pgm.exe.manifest /outputresource:pgm.exe;1***** ..\SRC\P0\P002\STDOUT.BUILD*****Comparing files P0\P002\stderr.build and ..\SRC\P0\P002\STDERR.BUILDFC: no differences encounteredComparing files P0\P002\stdout.pgm and ..\SRC\P0\P002\STDOUT.PGMFC: no differences encounteredComparing files P0\P002\stderr.pgm and ..\SRC\P0\P002\STDERR.PGMFC: no differences encounteredand almost the same pattern in the above tests.I would suggest if it is thinkable using NT386 variant with a complete dedicated machine/system, I can try to set up one this week and send the data back (the machine is behind a proxy), but I don't remember the mail explaining the set up, and also want to know if there is a chance of run the tests with one run script.Also what is the best natural way to put a new tests, and the standard name it should > > have?Thanks> >> >> > Enviado desde Correo Yahoo!La bandeja de entrada m?s inteligente.> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > >> DE163214194>> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From hosking at cs.purdue.edu  Tue May  6 16:05:25 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 6 May 2008 10:05:25 -0400
Subject: [M3devel] www.opencm3.net/m3tests
In-Reply-To: 
References: <313767.59466.qm@web27115.mail.ukl.yahoo.com>
	
	<20080506100711.d2rzqie6ow08csgs@mail.elegosoft.com>
	
Message-ID: <48A1BCA0-B727-4777-A16C-BD0673AC4D28@cs.purdue.edu>

On May 6, 2008, at 6:57 AM, Jay wrote:

> Olaf, I don't entirely agree.
> The logs should be fairly informative without intervention.
> Just not too verbose. I'd would rather remove the lines that say  
> "compiling" and show the cm3cg invocations.
> But more than one line per source file is too much.
> -commands doesn't really work. Lots of bogus extra commands are  
> echoed (rm .tmp), and not all the commands that are run are echoed.

Not bogus - it does exactly what one would expect - showing all  
commands executed.   I'm  with  Olaf on this one.

> I understand that stability for tests is also a goal, but  
> information for the interactive user and for post mortem debugging  
> via a log is also valuable, and these are contrary to stability-for- 
> tests. Somehow contradictory goals need to be met.

I prefer terse output for tests  that complete normally.  On detailed   
investigation l can always turn on a verbose flag.

> How about a compromise?
> How about we always log more stuff to TARGET/cm3.log?
>  And then exactly what you want to stdout/stderr?
> While, as I said, more than one line per file is overkill, as part  
> of this compromise I'd be willing to include the cm3cg and as  
> invocation.
>
> Have folks used build.exe in the Windows NT DDK?
> It's model is close to what you get here.
> It has three sets of information:
>   to the console/stdout
>   build.log, build.exe is a wrapper over make, and this includes all  
> the make output -- all the command lines run
>   build.err, a small subset of console/stdout output
>
> My "design" here has been to avoid over-verbosity. Link and mt run  
> on the order of once, or a small number of times, per directory, so  
> showing the full command line (response files...) isn't so verbose  
> -- vs. say something shown once per compiled file.
>
> There's another "problem" here that I have partly fixed.
> Underlying errors are not shown on console/stdout/stderr.
> They are often in like TARGET/m3core.lst.
>
> I changed stuff to refer to that file, after having hunted the  
> errors down myself slowly the first time.
>
> We could change things to alway says "see TARGET/cm3.log" for more  
> information, or somesuch.
>
>  - Jay
>
>
>
> > Date: Tue, 6 May 2008 10:07:11 +0200
> > From: wagner at elegosoft.com
> > To: m3devel at elegosoft.com
> > Subject: Re: [M3devel] www.opencm3.net/m3tests
> >
> > Quoting Jay :
> >
> > > The "problem" here, a really really small one, is just that the  
> link
> > > and mt commands got echoed.
> > > Olaf made them not echoed. I then made them conditionally echoed.
> > > I made m3-sys\m3tests define M3TESTS so that NT386.common  
> doesn't echo.
> > > It's not a big deal either way.
> > > Aha -- tests in other directories would have a problem, and I  
> think
> > > there are some.
> > >
> > > I like more echoing usually, so the system explains what is  
> going on,
> > > instead of the vaguer "linking foo" sort of message.
> > > Granted, nobody bothers watching gcc run assembler commands, so I
> > > guess it is just quite gray.
> >
> > Jay, cm3 needs to behave the same on all platforms. By default
> > commands should _not_ be echoed to stdout or stderr; that's what the
> > -commands switch is for: this gives you exactly the commands the
> > compiler issues to invoke other tools.
> >
> > For more verbose output, you may also depend on the -verbose or the
> > -debug switches.
> >
> > Please adapt the configuration files that bey default all echoing
> > of commands is off.
> >
> > Olaf
> >
> > > I don't know how to run the Tinderbox either yet, sorry.
> > > I tried.
> > >
> > > For adding tests, well, there is m3-sys\m3tests.
> > > That is where a lot of the tests are, but not all.
> > > I am not sure where tests belong. I added a small number there.
> > > They are named with just a letter and a number.
> > > The letters have some meaning, explained in the m3makefile.
> > > "p" is programs that are run and their stdout/stderr compared
> > > against expected
> > > "e" is programs build and the errors from the compiler checked  
> to be
> > > reasonable.
> > > I don't think in general they are expected to successfully compile
> > > or run, though the case of "warnings" may be unclear.
> > > "c" is programs built so a human can look at the generated code.
> > > There is another case I think for human checking.
> > > The numbers are just 001, 002, 003, etc.
> > > Each hundred tests are in a separate directory, like p0\p001,
> > > p0\p002, p1\p100, p1\101, etc.
> > >
> > > Something like this.
> > > Wherever I have details wrong, just look in m3-sys\m3tests. It's
> > > pretty simple, obvious, and well commented.
> > >
> > > The output is a little clearer if you have a working diff.exe on  
> the path.
> > > Then what you do is search for "@@" in the output.
> > >
> > > - Jay
> > >
> > >
> > > Date: Tue, 6 May 2008 03:46:27 +0200From: dabenavidesd at yahoo.esTo:
> > > m3devel at elegosoft.comSubject: [M3devel] www.opencm3.net/ 
> m3testsDear
> > > developers:Does the recent tests on NT386 seem broken because a
> > > recent change on the m3-sys tree, or is the HTML bad generated, I
> > > mean can you check the last tests Sunday, May 4th (p001 to p042)  
> has
> > > a red background
> > > http://www.opencm3.net/m3tests/m3tests-NT386-2008-04-23-13-30-57.html 
>
p002 class="small" width="45%"> Text
Comparing  
> files P0\P002\stdout.build and ..\SRC\P0\P002\STDOUT.BUILD*****  
> P0\P002\stdout.buildlink @_m3responsefile0.txt 2>&1 > pgm.lstmt / 
> nologo /manifest pgm.exe.manifest /outputresource:pgm.exe;1***** .. 
> \SRC\P0\P002\STDOUT.BUILD*****Comparing files P0\P002\stderr.build  
> and ..\SRC\P0\P002\STDERR.BUILDFC: no differences  
> encounteredComparing files P0\P002\stdout.pgm and ..\SRC 
> \P0\P002\STDOUT.PGMFC: no differences encounteredComparing files  
> P0\P002\stderr.pgm and ..\SRC\P0\P002\STDERR.PGMFC: no differences  
> encounteredand almost the same pattern in the above tests.I would  
> suggest if it is thinkable using NT386 variant with a complete  
> dedicated machine/system, I can try to set up one this week and send  
> the data back (the machine is behind a proxy), but I don't remember  
> the mail explaining the set up, and also want to know if there is a  
> chance of run the tests with one run script.Also what is the best  
> natural way to put a new tests, and the standard name it should
> > > have?Thanks
> > >
> > >
> > > Enviado desde Correo Yahoo!La bandeja de entrada m?s inteligente.
> >
> >
> >
> > --
> > 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 hosking at cs.purdue.edu  Tue May  6 16:06:57 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 6 May 2008 10:06:57 -0400
Subject: [M3devel] cm3 command line interface and output;
	was: RE: 	www.opencm3.net/m3tests
In-Reply-To: <20080506153318.a50ttk23488ksk00@mail.elegosoft.com>
References: <313767.59466.qm@web27115.mail.ukl.yahoo.com>
	
	<20080506100711.d2rzqie6ow08csgs@mail.elegosoft.com>
	
	
	<20080506153318.a50ttk23488ksk00@mail.elegosoft.com>
Message-ID: <2D3BBD73-E273-4E9B-AC2D-DCF9A2CCBCAB@cs.purdue.edu>

I'm am strongly with Jay on this one.

On May 6, 2008, at 9:33 AM, Olaf Wagner wrote:

> Quoting Jay :
>
>> When I say show cm3cg/as invocations, I mean in this new TARGET/ 
>> cm3.log.
>> As I said, I propose exactly the stdout/stderr you want, but then   
>> some other output always, a log file.
>> Also, about -commands, I have also claimed that it does work --   
>> talking out of both sides of my mouth. The extra commands it  
>> prints  are obviously harmless. I forget what doesn't print, maybe  
>> exec vs.  q_exec? Also the '@' character wasn't working with  
>> q_exec, but that  isn't necessarily relevant here..I forgot where I  
>> use exec vs.  q_exec..
>> And there plenty of other ways to debug than -commands and it is   
>> "just" a debugging facility..
>
> I've got a rather definite opinion about the output behaviour of
> cm3. It's like this, and I would like others to comment, too:
>
> o cm3 without any switches (-commands, -debug, -verbose) should
>   not output any called commands, neither to stdout nor stderr.
>   It may print what it is doing in an abstract, target independent
>   (short) way. This output may refer to compilation units, interfaces,
>   modules, and compilation phases, but not to target specific commands
>   and files (unless there are errors, of course) Even then I'd like
>   to abstract from differences.
>
> o cm3 -silent should suppress the normal output, except for warnings
>   and error messages.
>
> o cm3 -commands should output exactly all invokations of externals
>   commands so that they can be re-executed from the command line
>   if necessary.
>
> I realize that it might not be this way in every aspect, so that
> we may need to adapt the code here and there. But in my experience
> it has worked this way quite well. Here are some points to consider:
>
> o We need consistent behaviour and output across all target platforms.
>   This is not just a requirement of regression testing, but also of
>   a consistent user interface. I don't want different behaviour on
>   different platforms.
>
> o If -commands does not work as expected for some use case,
>   we need to fix it.
>
> o If q_exec or whatever quake function is still deficient in this
>   respect, we need to fix/adapt it. It should not be much effort.
>
> o I find the options -commands, -verbose, -debug, -silent a very
>   good categorization of information types, intuitively understandable
>   and usable in practive (as I've never had any problems with it, but
>   have used them efficiently for years). So I don't see the point
>   in changing anything, unless there is a better concept.
>
> o I don't think it is a good idea to write any log files by default
>   (apart from the stdout and stderr streams).
>
> This is of course just my opinion, but unless there are others in
> favour of changes (and I'd like some motivation for them) I'd insist
> that we keep the existing design.
>
> Olaf
>
>> From: jayk123 at hotmail.comTo: wagner at elegosoft.com;  m3devel at elegosoft.comDate 
>> : Tue, 6 May 2008 10:57:01 +0000Subject:  Re: [M3devel] www.opencm3.net/m3tests
>>
>>
>> Olaf, I don't entirely agree.The logs should be fairly informative   
>> without intervention.Just not too verbose. I'd would rather remove   
>> the lines that say "compiling" and show the cm3cg invocations.But   
>> more than one line per source file is too much.-commands doesn't   
>> really work. Lots of bogus extra commands are echoed (rm .tmp),  
>> and  not all the commands that are run are echoed. I understand  
>> that  stability for tests is also a goal, but information for the   
>> interactive user and for post mortem debugging via a log is also   
>> valuable, and these are contrary to stability-for-tests. Somehow   
>> contradictory goals need to be met. How about a compromise?How  
>> about  we always log more stuff to TARGET/cm3.log? And then exactly  
>> what  you want to stdout/stderr?While, as I said, more than one  
>> line per  file is overkill, as part of this compromise I'd be  
>> willing to  include the cm3cg and as invocation. Have folks used  
>> build.exe in  the Windows NT DDK?It's model is close to what you  
>> get here.It has  three sets of information:  to the console/ 
>> stdout   build.log,  build.exe is a wrapper over make, and this  
>> includes all the make  output -- all the command lines run    
>> build.err, a small subset of  console/stdout output My "design"  
>> here has been to avoid  over-verbosity. Link and mt run on the  
>> order of once, or a small  number of times, per directory, so  
>> showing the full command line  (response files...) isn't so verbose  
>> -- vs. say something shown once  per compiled file. There's another  
>> "problem" here that I have partly  fixed.Underlying errors are not  
>> shown on console/stdout/stderr.They  are often in like TARGET/ 
>> m3core.lst. I changed stuff to refer to  that file, after having  
>> hunted the errors down myself slowly the  first time. We could  
>> change things to alway says "see  TARGET/cm3.log" for more  
>> information, or somesuch.  - Jay
>>
>>> Date: Tue, 6 May 2008 10:07:11 +0200> From: wagner at elegosoft.com>   
>>> To: m3devel at elegosoft.com> Subject: Re: [M3devel]  www.opencm3.net/m3tests 
>>> > > Quoting Jay :> > >  The "problem" here, a  
>>> really really small one, is just that the  link > > and mt  
>>> commands got echoed.> > Olaf made them not echoed.  I then made  
>>> them conditionally echoed.> > I made m3-sys\m3tests  define  
>>> M3TESTS so that NT386.common doesn't echo.> > It's not a big  deal  
>>> either way.> > Aha -- tests in other directories would have a   
>>> problem, and I think > > there are some.> >> > I like more  
>>> echoing  usually, so the system explains what is going on,> >  
>>> instead of the  vaguer "linking foo" sort of message.> > Granted,  
>>> nobody bothers  watching gcc run assembler commands, so I > >  
>>> guess it is just  quite gray.> > Jay, cm3 needs to behave the same  
>>> on all platforms.  By default> commands should _not_ be echoed to  
>>> stdout or stderr;  that's what the> -commands switch is for: this  
>>> gives you exactly  the commands the> compiler issues to invoke  
>>> other tools.> > For  more verbose output, you may also depend on  
>>> the -verbose or the>  -debug switches.> > Please adapt the  
>>> configuration files that bey  default all echoing> of commands is  
>>> off.> > Olaf> > > I don't know  how to run the Tinderbox either  
>>> yet, sorry.> > I tried.> >> > For  adding tests, well, there is m3- 
>>> sys\m3tests.> > That is where a lot  of the tests are, but not  
>>> all.> > I am not sure where tests belong.  I added a small number  
>>> there.> > They are named with just a letter  and a number.> > The  
>>> letters have some meaning, explained in the  m3makefile.> > "p" is  
>>> programs that are run and their stdout/stderr  compared > >  
>>> against expected> > "e" is programs build and the  errors from the  
>>> compiler checked to be > > reasonable.> > I don't  think in  
>>> general they are expected to successfully compile > > or  run,  
>>> though the case of "warnings" may be unclear.> > "c" is  programs  
>>> built so a human can look at the generated code.> > There  is  
>>> another case I think for human checking.> > The numbers are just   
>>> 001, 002, 003, etc.> > Each hundred tests are in a separate   
>>> directory, like p0\p001, > > p0\p002, p1\p100, p1\101, etc.> >> >   
>>> Something like this.> > Wherever I have details wrong, just look  
>>> in  m3-sys\m3tests. It's > > pretty simple, obvious, and well   
>>> commented.> >> > The output is a little clearer if you have a   
>>> working diff.exe on the path.> > Then what you do is search for   
>>> "@@" in the output.> >> > - Jay> >> >> > Date: Tue, 6 May 2008   
>>> 03:46:27 +0200From: dabenavidesd at yahoo.esTo: > >  m3devel at elegosoft.comSubject 
>>> : [M3devel] www.opencm3.net/m3testsDear  > > developers:Does the  
>>> recent tests on NT386 seem broken because a  > > recent change on  
>>> the m3-sys tree, or is the HTML bad generated,  I > > mean can you  
>>> check the last tests Sunday, May 4th (p001 to  p042) has > > a red  
>>> background > >  http://www.opencm3.net/m3tests/m3tests-NT386-2008-04-23-13-30-57.html 
>>>
p002 >> class="small" width="45%"> Text>> class="small">
Comparing files P0\P002\stdout.build and ..\SRC 
>>> \P0\P002\STDOUT.BUILD***** P0\P002\stdout.buildlink  
>>> @_m3responsefile0.txt 2>&1 > pgm.lstmt /nologo /manifest  
>>> pgm.exe.manifest /outputresource:pgm.exe;1***** ..\SRC 
>>> \P0\P002\STDOUT.BUILD*****Comparing files P0\P002\stderr.build  
>>> and ..\SRC\P0\P002\STDERR.BUILDFC: no differences  
>>> encounteredComparing files P0\P002\stdout.pgm and ..\SRC 
>>> \P0\P002\STDOUT.PGMFC: no differences encounteredComparing files  
>>> P0\P002\stderr.pgm and ..\SRC\P0\P002\STDERR.PGMFC: no differences  
>>> encounteredand almost the same pattern in the above tests.I would  
>>> suggest if it is thinkable using NT386 variant with a complete  
>>> dedicated machine/system, I can try to set up one this week and  
>>> send the data back (the machine is behind a proxy), but I don't  
>>> remember the mail explaining the set up, and also want to know if  
>>> there is a chance of run the tests with one run script.Also what  
>>> is the best natural way to put a new tests, and the standard name  
>>> it should > > have?Thanks> >> >> > Enviado desde Correo Yahoo!La  
>>> bandeja de entrada m?s inteligente.> > > > -- > Olaf Wagner --  
>>> elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12,  
>>> 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177  
>>> 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com |  
>>> Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister:  
>>> Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:  DE163214194>
>
>
>
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin,  
> Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23  
> 45 86 95
>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz:  
> Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:  
> DE163214194
>



From hosking at cs.purdue.edu  Tue May  6 16:07:56 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 6 May 2008 10:07:56 -0400
Subject: [M3devel] cm3 command line interface and output;
	was: RE: 	www.opencm3.net/m3tests
In-Reply-To: <2D3BBD73-E273-4E9B-AC2D-DCF9A2CCBCAB@cs.purdue.edu>
References: <313767.59466.qm@web27115.mail.ukl.yahoo.com>
	
	<20080506100711.d2rzqie6ow08csgs@mail.elegosoft.com>
	
	
	<20080506153318.a50ttk23488ksk00@mail.elegosoft.com>
	<2D3BBD73-E273-4E9B-AC2D-DCF9A2CCBCAB@cs.purdue.edu>
Message-ID: <5F69E624-4EFD-43D6-A852-6938AE62C9BC@cs.purdue.edu>

Oops I meant *Olaf* !

On May 6, 2008, at 10:06 AM, Tony Hosking wrote:

> I'm am strongly with Jay on this one.
>
> On May 6, 2008, at 9:33 AM, Olaf Wagner wrote:
>
>> Quoting Jay :
>>
>>> When I say show cm3cg/as invocations, I mean in this new TARGET/ 
>>> cm3.log.
>>> As I said, I propose exactly the stdout/stderr you want, but then   
>>> some other output always, a log file.
>>> Also, about -commands, I have also claimed that it does work --   
>>> talking out of both sides of my mouth. The extra commands it  
>>> prints  are obviously harmless. I forget what doesn't print, maybe  
>>> exec vs.  q_exec? Also the '@' character wasn't working with  
>>> q_exec, but that  isn't necessarily relevant here..I forgot where  
>>> I use exec vs.  q_exec..
>>> And there plenty of other ways to debug than -commands and it is   
>>> "just" a debugging facility..
>>
>> I've got a rather definite opinion about the output behaviour of
>> cm3. It's like this, and I would like others to comment, too:
>>
>> o cm3 without any switches (-commands, -debug, -verbose) should
>>  not output any called commands, neither to stdout nor stderr.
>>  It may print what it is doing in an abstract, target independent
>>  (short) way. This output may refer to compilation units, interfaces,
>>  modules, and compilation phases, but not to target specific commands
>>  and files (unless there are errors, of course) Even then I'd like
>>  to abstract from differences.
>>
>> o cm3 -silent should suppress the normal output, except for warnings
>>  and error messages.
>>
>> o cm3 -commands should output exactly all invokations of externals
>>  commands so that they can be re-executed from the command line
>>  if necessary.
>>
>> I realize that it might not be this way in every aspect, so that
>> we may need to adapt the code here and there. But in my experience
>> it has worked this way quite well. Here are some points to consider:
>>
>> o We need consistent behaviour and output across all target  
>> platforms.
>>  This is not just a requirement of regression testing, but also of
>>  a consistent user interface. I don't want different behaviour on
>>  different platforms.
>>
>> o If -commands does not work as expected for some use case,
>>  we need to fix it.
>>
>> o If q_exec or whatever quake function is still deficient in this
>>  respect, we need to fix/adapt it. It should not be much effort.
>>
>> o I find the options -commands, -verbose, -debug, -silent a very
>>  good categorization of information types, intuitively understandable
>>  and usable in practive (as I've never had any problems with it, but
>>  have used them efficiently for years). So I don't see the point
>>  in changing anything, unless there is a better concept.
>>
>> o I don't think it is a good idea to write any log files by default
>>  (apart from the stdout and stderr streams).
>>
>> This is of course just my opinion, but unless there are others in
>> favour of changes (and I'd like some motivation for them) I'd insist
>> that we keep the existing design.
>>
>> Olaf
>>
>>> From: jayk123 at hotmail.comTo: wagner at elegosoft.com;  m3devel at elegosoft.comDate 
>>> : Tue, 6 May 2008 10:57:01 +0000Subject:  Re: [M3devel] www.opencm3.net/m3tests
>>>
>>>
>>> Olaf, I don't entirely agree.The logs should be fairly  
>>> informative  without intervention.Just not too verbose. I'd would  
>>> rather remove  the lines that say "compiling" and show the cm3cg  
>>> invocations.But  more than one line per source file is too much.- 
>>> commands doesn't  really work. Lots of bogus extra commands are  
>>> echoed (rm .tmp), and  not all the commands that are run are  
>>> echoed. I understand that  stability for tests is also a goal, but  
>>> information for the  interactive user and for post mortem  
>>> debugging via a log is also  valuable, and these are contrary to  
>>> stability-for-tests. Somehow  contradictory goals need to be met.  
>>> How about a compromise?How about  we always log more stuff to  
>>> TARGET/cm3.log? And then exactly what  you want to stdout/stderr? 
>>> While, as I said, more than one line per  file is overkill, as  
>>> part of this compromise I'd be willing to  include the cm3cg and  
>>> as invocation. Have folks used build.exe in  the Windows NT DDK? 
>>> It's model is close to what you get here.It has  three sets of  
>>> information:  to the console/stdout   build.log,  build.exe is a  
>>> wrapper over make, and this includes all the make  output -- all  
>>> the command lines run   build.err, a small subset of  console/ 
>>> stdout output My "design" here has been to avoid  over-verbosity.  
>>> Link and mt run on the order of once, or a small  number of times,  
>>> per directory, so showing the full command line  (response  
>>> files...) isn't so verbose -- vs. say something shown once  per  
>>> compiled file. There's another "problem" here that I have partly   
>>> fixed.Underlying errors are not shown on console/stdout/ 
>>> stderr.They  are often in like TARGET/m3core.lst. I changed stuff  
>>> to refer to  that file, after having hunted the errors down myself  
>>> slowly the  first time. We could change things to alway says "see   
>>> TARGET/cm3.log" for more information, or somesuch.  - Jay
>>>
>>>> Date: Tue, 6 May 2008 10:07:11 +0200> From:  
>>>> wagner at elegosoft.com>  To: m3devel at elegosoft.com> Subject: Re:  
>>>> [M3devel]  www.opencm3.net/m3tests> > Quoting Jay >>> >:> > >  The "problem" here, a really really small one, is just  
>>>> that the  link > > and mt commands got echoed.> > Olaf made them  
>>>> not echoed.  I then made them conditionally echoed.> > I made m3- 
>>>> sys\m3tests  define M3TESTS so that NT386.common doesn't echo.> >  
>>>> It's not a big  deal either way.> > Aha -- tests in other  
>>>> directories would have a  problem, and I think > > there are  
>>>> some.> >> > I like more echoing  usually, so the system explains  
>>>> what is going on,> > instead of the  vaguer "linking foo" sort of  
>>>> message.> > Granted, nobody bothers  watching gcc run assembler  
>>>> commands, so I > > guess it is just  quite gray.> > Jay, cm3  
>>>> needs to behave the same on all platforms.  By default> commands  
>>>> should _not_ be echoed to stdout or stderr;  that's what the> - 
>>>> commands switch is for: this gives you exactly  the commands the>  
>>>> compiler issues to invoke other tools.> > For  more verbose  
>>>> output, you may also depend on the -verbose or the>  -debug  
>>>> switches.> > Please adapt the configuration files that bey   
>>>> default all echoing> of commands is off.> > Olaf> > > I don't  
>>>> know  how to run the Tinderbox either yet, sorry.> > I tried.> >>  
>>>> > For  adding tests, well, there is m3-sys\m3tests.> > That is  
>>>> where a lot  of the tests are, but not all.> > I am not sure  
>>>> where tests belong.  I added a small number there.> > They are  
>>>> named with just a letter  and a number.> > The letters have some  
>>>> meaning, explained in the  m3makefile.> > "p" is programs that  
>>>> are run and their stdout/stderr  compared > > against expected> >  
>>>> "e" is programs build and the  errors from the compiler checked  
>>>> to be > > reasonable.> > I don't  think in general they are  
>>>> expected to successfully compile > > or  run, though the case of  
>>>> "warnings" may be unclear.> > "c" is  programs built so a human  
>>>> can look at the generated code.> > There  is another case I think  
>>>> for human checking.> > The numbers are just  001, 002, 003, etc.>  
>>>> > Each hundred tests are in a separate  directory, like p0\p001,  
>>>> > > p0\p002, p1\p100, p1\101, etc.> >> >  Something like this.> >  
>>>> Wherever I have details wrong, just look in  m3-sys\m3tests. It's  
>>>> > > pretty simple, obvious, and well  commented.> >> > The output  
>>>> is a little clearer if you have a  working diff.exe on the path.>  
>>>> > Then what you do is search for  "@@" in the output.> >> > -  
>>>> Jay> >> >> > Date: Tue, 6 May 2008  03:46:27 +0200From: dabenavidesd at yahoo.esTo 
>>>> : > >  m3devel at elegosoft.comSubject: [M3devel] www.opencm3.net/m3testsDear 
>>>>   > > developers:Does the recent tests on NT386 seem broken  
>>>> because a  > > recent change on the m3-sys tree, or is the HTML  
>>>> bad generated,  I > > mean can you check the last tests Sunday,  
>>>> May 4th (p001 to  p042) has > > a red background > >  http://www.opencm3.net/m3tests/m3tests-NT386-2008-04-23-13-30-57.html 
>>>>
p002 >>> class="small" width="45%"> Text>>> class="small">
Comparing files P0\P002\stdout.build and ..\SRC 
>>>> \P0\P002\STDOUT.BUILD***** P0\P002\stdout.buildlink  
>>>> @_m3responsefile0.txt 2>&1 > pgm.lstmt /nologo /manifest  
>>>> pgm.exe.manifest /outputresource:pgm.exe;1***** ..\SRC 
>>>> \P0\P002\STDOUT.BUILD*****Comparing files P0\P002\stderr.build  
>>>> and ..\SRC\P0\P002\STDERR.BUILDFC: no differences  
>>>> encounteredComparing files P0\P002\stdout.pgm and ..\SRC 
>>>> \P0\P002\STDOUT.PGMFC: no differences encounteredComparing files  
>>>> P0\P002\stderr.pgm and ..\SRC\P0\P002\STDERR.PGMFC: no  
>>>> differences encounteredand almost the same pattern in the above  
>>>> tests.I would suggest if it is thinkable using NT386 variant with  
>>>> a complete dedicated machine/system, I can try to set up one this  
>>>> week and send the data back (the machine is behind a proxy), but  
>>>> I don't remember the mail explaining the set up, and also want to  
>>>> know if there is a chance of run the tests with one run  
>>>> script.Also what is the best natural way to put a new tests, and  
>>>> the standard name it should > > have?Thanks> >> >> > Enviado  
>>>> desde Correo Yahoo!La bandeja de entrada m?s inteligente.> > > >  
>>>> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer- 
>>>> Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45  
>>>> 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com 
>>>>  | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister:  
>>>> Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:  DE163214194>
>>
>>
>>
>> -- 
>> Olaf Wagner -- elego Software Solutions GmbH
>>              Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin,  
>> Germany
>> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23  
>> 45 86 95
>>  http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz:  
>> Berlin
>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:  
>> DE163214194
>>
>



From jayk123 at hotmail.com  Tue May  6 16:16:35 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 6 May 2008 14:16:35 +0000
Subject: [M3devel] www.opencm3.net/m3tests
In-Reply-To: <48A1BCA0-B727-4777-A16C-BD0673AC4D28@cs.purdue.edu>
References: <313767.59466.qm@web27115.mail.ukl.yahoo.com>
	
	<20080506100711.d2rzqie6ow08csgs@mail.elegosoft.com>
	
	<48A1BCA0-B727-4777-A16C-BD0673AC4D28@cs.purdue.edu>
Message-ID: 

The bogus commands are actually a "simulation" of what the code is doing, I think.
It isn't so dumb as to run little rm commands here it and there. It deletes files without running anything and prints stuff that if run will approximate what it did. It is indeed worthwhile I think, though it isn't "-commands" per se.
That's my vague understanding not having read the code closely.
The "strange" thing is to see "rm" commands on NT386.
 
Planning for success is arguably wrong.
There will be errors. They need to be debugged.
You can't always rerun the scenario.
 
I think a log file with a little more information is a reasonable compromise.
 
Even that is gray. For example, the log file should not contain the output of -trace.
That's just too low level, too voluminous, and fails too rarely to be interesting.
 
Echoing command lines always into a log seems good on the assumption that command lines are expensive, so the i/o to put them in a log should be ok. This isn't entirely true, what with stuff like mkdir and rm.
On the assumption that command lines are running "big" things that "often" fail.
Again this is mixed. Most systems that show command lines still hide many.
ie: invocations of gcc are often shown, but invocations of cc1 and as not so much.
 
Personally I debug a lot of stuff and I err in favor of debuggability, be it live or post-mortem.
Debugging is hard enough, I don't like the obvious easy powers taken away from me.
I know logging and printf is incredibly crude vs. stepping through code in a debugger, but I also had it be fantastically successful and fast too many times to discount. Esp. in data-intensive code where the same code runs successfully many times before the problem occurs.
 
I will grant that in my Modula-3 use, debugging has mostly been easy enough, the repro cases available enough, that optimizing for post-mortem debugging of one and only one instance of a problem is probably overkill.
But still, a log file seems reasonable..
(The debugging has actually been not easy, quite difficult at times, the NT386GNU X windows problem, the double aligment, the stat overflow...but the repro cases and ability to peel the onion in run after run after run has been good; like cm3cg -y for example..and the logging we are talking about only helps in the easiest of cases...)
 
 - Jay


CC: wagner at elegosoft.com; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] www.opencm3.net/m3testsDate: Tue, 6 May 2008 10:05:25 -0400

On May 6, 2008, at 6:57 AM, Jay wrote:


Olaf, I don't entirely agree.The logs should be fairly informative without intervention.Just not too verbose. I'd would rather remove the lines that say "compiling" and show the cm3cg invocations.But more than one line per source file is too much.-commands doesn't really work. Lots of bogus extra commands are echoed (rm .tmp), and not all the commands that are run are echoed.

Not bogus - it does exactly what one would expect - showing all commands executed.   I'm  with  Olaf on this one.


I understand that stability for tests is also a goal, but information for the interactive user and for post mortem debugging via a log is also valuable, and these are contrary to stability-for-tests. Somehow contradictory goals need to be met.

I prefer terse output for tests  that complete normally.  On detailed  investigation l can always turn on a verbose flag.

How about a compromise?How about we always log more stuff to TARGET/cm3.log? And then exactly what you want to stdout/stderr?While, as I said, more than one line per file is overkill, as part of this compromise I'd be willing to include the cm3cg and as invocation. Have folks used build.exe in the Windows NT DDK?It's model is close to what you get here.It has three sets of information:  to the console/stdout   build.log, build.exe is a wrapper over make, and this includes all the make output -- all the command lines run   build.err, a small subset of console/stdout output My "design" here has been to avoid over-verbosity. Link and mt run on the order of once, or a small number of times, per directory, so showing the full command line (response files...) isn't so verbose -- vs. say something shown once per compiled file. There's another "problem" here that I have partly fixed.Underlying errors are not shown on console/stdout/stderr.They are often in like TARGET/m3core.lst. I changed stuff to refer to that file, after having hunted the errors down myself slowly the first time. We could change things to alway says "see TARGET/cm3.log" for more information, or somesuch.  - Jay

> Date: Tue, 6 May 2008 10:07:11 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] www.opencm3.net/m3tests> > Quoting Jay :> > > The "problem" here, a really really small one, is just that the link > > and mt commands got echoed.> > Olaf made them not echoed. I then made them conditionally echoed.> > I made m3-sys\m3tests define M3TESTS so that NT386.common doesn't echo.> > It's not a big deal either way.> > Aha -- tests in other directories would have a problem, and I think > > there are some.> >> > I like more echoing usually, so the system explains what is going on,> > instead of the vaguer "linking foo" sort of message.> > Granted, nobody bothers watching gcc run assembler commands, so I > > guess it is just quite gray.> > Jay, cm3 needs to behave the same on all platforms. By default> commands should _not_ be echoed to stdout or stderr; that's what the> -commands switch is for: this gives you exactly the commands the> compiler issues to invoke other tools.> > For more verbose output, you may also depend on the -verbose or the> -debug switches.> > Please adapt the configuration files that bey default all echoing> of commands is off.> > Olaf> > > I don't know how to run the Tinderbox either yet, sorry.> > I tried.> >> > For adding tests, well, there is m3-sys\m3tests.> > That is where a lot of the tests are, but not all.> > I am not sure where tests belong. I added a small number there.> > They are named with just a letter and a number.> > The letters have some meaning, explained in the m3makefile.> > "p" is programs that are run and their stdout/stderr compared > > against expected> > "e" is programs build and the errors from the compiler checked to be > > reasonable.> > I don't think in general they are expected to successfully compile > > or run, though the case of "warnings" may be unclear.> > "c" is programs built so a human can look at the generated code.> > There is another case I think for human checking.> > The numbers are just 001, 002, 003, etc.> > Each hundred tests are in a separate directory, like p0\p001, > > p0\p002, p1\p100, p1\101, etc.> >> > Something like this.> > Wherever I have details wrong, just look in m3-sys\m3tests. It's > > pretty simple, obvious, and well commented.> >> > The output is a little clearer if you have a working diff.exe on the path.> > Then what you do is search for "@@" in the output.> >> > - Jay> >> >> > Date: Tue, 6 May 2008 03:46:27 +0200From: dabenavidesd at yahoo.esTo: > > m3devel at elegosoft.comSubject: [M3devel] www.opencm3.net/m3testsDear > > developers:Does the recent tests on NT386 seem broken because a > > recent change on the m3-sys tree, or is the HTML bad generated, I > > mean can you check the last tests Sunday, May 4th (p001 to p042) has > > a red background > > http://www.opencm3.net/m3tests/m3tests-NT386-2008-04-23-13-30-57.html
p002 Text
Comparing files P0\P002\stdout.build and ..\SRC\P0\P002\STDOUT.BUILD***** P0\P002\stdout.buildlink @_m3responsefile0.txt 2>&1 > pgm.lstmt /nologo /manifest pgm.exe.manifest /outputresource:pgm.exe;1***** ..\SRC\P0\P002\STDOUT.BUILD*****Comparing files P0\P002\stderr.build and ..\SRC\P0\P002\STDERR.BUILDFC: no differences encounteredComparing files P0\P002\stdout.pgm and ..\SRC\P0\P002\STDOUT.PGMFC: no differences encounteredComparing files P0\P002\stderr.pgm and ..\SRC\P0\P002\STDERR.PGMFC: no differences encounteredand almost the same pattern in the above tests.I would suggest if it is thinkable using NT386 variant with a complete dedicated machine/system, I can try to set up one this week and send the data back (the machine is behind a proxy), but I don't remember the mail explaining the set up, and also want to know if there is a chance of run the tests with one run script.Also what is the best natural way to put a new tests, and the standard name it should > > have?Thanks> >> >> > Enviado desde Correo Yahoo!La bandeja de entrada m?s inteligente.> > > > -- > 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  Tue May  6 23:07:36 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 06 May 2008 23:07:36 +0200
Subject: [M3devel] m3cc build fails on older MacOS X
In-Reply-To: 
References: <20080506075754.o24j7xhx4wgokwwo@mail.elegosoft.com>
	
	<20080506130247.50uj68o11twcgkog@mail.elegosoft.com>
	
Message-ID: <20080506230736.n106yopfkwooo4s0@mail.elegosoft.com>

Quoting Jay :

> Olaf, can you try without my m3makefile wierdness, that works elsewhere?
>
>   cd %CVSROOT%/m3-sys/m3cc    mkdir obj1     cd obj1     
> ../gcc/configure --disable-bootstrap --enable-languages=c,cm3cg      
> make
>  I'm not sure of "cm3cg", it might be "m3cg".  And you can just omit  
>  that anyway, I doubt the error is m3 related.
> (Tony: I don't believe --srcdir is needed. configure figures it out;  
>  granted, maybe not trivially.)
> ?
>  I expect you will get the same error.  Which isn't the final   
> answer, just some relevant data.   And if I'm wrong, well, that   
> suggests some fix.

I got home later than expected. The build now stops at a different
step:

/Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/xgcc  
-B/Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/  
-B/usr/local/powerpc-apple-darwin7.9.0/bin/  
-B/usr/local/powerpc-apple-darwin7.9.0/lib/ -isystem  
/usr/local/powerpc-apple-darwin7.9.0/include -isystem  
/usr/local/powerpc-apple-darwin7.9.0/sys-include -O2  -O2 -g -g -O2    
-DIN_GCC    -W -Wall -Wwrite-strings -Wstrict-prototypes  
-Wmissing-prototypes -Wold-style-definition  -isystem ./include   
-Wa,-force_cpusubtype_ALL -pipe -mmacosx-version-min=10.4 -g  
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -dynamiclib  
-nodefaultlibs -install_name /usr/local/lib/libgcc_s`if test . = ppc64  
; then echo _. ; fi`.1.dylib -single_module -o ./libgcc_s.1.dylib.tmp  
-Wl,-exported_symbols_list,libgcc.map -compatibility_version 1  
-current_version 1.0 -O2 -g -g -O2 -B./ _muldi3_s.o _negdi2_s.o  
_lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o  
_clear_cache_s.o _enable_execute_stack_s.o _trampoline_s.o __main_s.o  
_absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o  
_subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o  
_ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o  
_ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o  
_popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o  
_powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o _muldc3_s.o  
_mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o  
_divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _fixunssfsi_s.o  
_fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o  
_fixtfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o  
_fixunstfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o  
_floatditf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o  
_floatunditf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o  
_udiv_w_sdiv_s.o _udivmoddi4_s.o darwin-tramp_s.o ppc64-fp_s.o  
darwin-64_s.o darwin-ldouble_s.o darwin-world_s.o unwind-dw2_s.o  
unwind-dw2-fde-darwin_s.o unwind-sjlj_s.o unwind-c_s.o  
darwin-fallback_s.o emutls_s.o -lc
/usr/bin/ld: unknown flag: -macosx_version_min
collect2: ld returned 1 exit status
make[2]: *** [libgcc_s.dylib] Error 1
make[1]: *** [all-target-libgcc] Error 2
make: *** [all] Error 2

I'm too sleepy to investigate further now,

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



From jayk123 at hotmail.com  Tue May  6 23:18:14 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 6 May 2008 21:18:14 +0000
Subject: [M3devel] m3cc build fails on older MacOS X
In-Reply-To: <20080506230736.n106yopfkwooo4s0@mail.elegosoft.com>
References: <20080506075754.o24j7xhx4wgokwwo@mail.elegosoft.com>
	
	<20080506130247.50uj68o11twcgkog@mail.elegosoft.com>
	 
	<20080506230736.n106yopfkwooo4s0@mail.elegosoft.com>
Message-ID: 

Search the web...
http://projects.scipy.org/pipermail/scipy-user/2007-March/011372.html
 
"
I've got a Mac OSx 10.4.8 machine and am compilingscipy according to the instructions on the webpage.  I'vegot gcc 4.0.0 gfortran 4.3.0 fftw3.0 and svn versions of numpyand scipy.   My python is version 2.5.Building numpy goes smoothly, but when I try scipy I have an ld error....
 
I have gcc 4.0.1 and gfortran 4.3.0 installed on my system, and I do not seethis problem. Can you try upgrading to the latest version of Xcode (which shouldhave gcc 4.0.1)? It's not coming from Python but, I suspect, gfortran.
...
Indeed-- after an almost 1Gig download of XCode 2.4.1 to get gcc 4.0.1it compiled and runs. :)  The tests give me 4 failed, but these  already havebeen noted on the email list...."
1) Upgrade to 2.4.1/4.0.1
2) configure should sniff for this and remove it if not supported.
 
 - Jay



> Date: Tue, 6 May 2008 23:07:36 +0200> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: RE: [M3devel] m3cc build fails on older MacOS X> > Quoting Jay :> > > Olaf, can you try without my m3makefile wierdness, that works elsewhere?> >> > cd %CVSROOT%/m3-sys/m3cc mkdir obj1 cd obj1 > > ../gcc/configure --disable-bootstrap --enable-languages=c,cm3cg > > make> > I'm not sure of "cm3cg", it might be "m3cg". And you can just omit > > that anyway, I doubt the error is m3 related.> > (Tony: I don't believe --srcdir is needed. configure figures it out; > > granted, maybe not trivially.)> > ?> > I expect you will get the same error. Which isn't the final > > answer, just some relevant data. And if I'm wrong, well, that > > suggests some fix.> > I got home later than expected. The build now stops at a different> step:> > /Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/xgcc > -B/Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/ > -B/usr/local/powerpc-apple-darwin7.9.0/bin/ > -B/usr/local/powerpc-apple-darwin7.9.0/lib/ -isystem > /usr/local/powerpc-apple-darwin7.9.0/include -isystem > /usr/local/powerpc-apple-darwin7.9.0/sys-include -O2 -O2 -g -g -O2 > -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes > -Wmissing-prototypes -Wold-style-definition -isystem ./include > -Wa,-force_cpusubtype_ALL -pipe -mmacosx-version-min=10.4 -g > -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -dynamiclib > -nodefaultlibs -install_name /usr/local/lib/libgcc_s`if test . = ppc64 > ; then echo _. ; fi`.1.dylib -single_module -o ./libgcc_s.1.dylib.tmp > -Wl,-exported_symbols_list,libgcc.map -compatibility_version 1 > -current_version 1.0 -O2 -g -g -O2 -B./ _muldi3_s.o _negdi2_s.o > _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o > _clear_cache_s.o _enable_execute_stack_s.o _trampoline_s.o __main_s.o > _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o > _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o > _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o > _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o > _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o > _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o _muldc3_s.o > _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o > _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _fixunssfsi_s.o > _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o > _fixtfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o > _fixunstfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o > _floatditf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o > _floatunditf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o > _udiv_w_sdiv_s.o _udivmoddi4_s.o darwin-tramp_s.o ppc64-fp_s.o > darwin-64_s.o darwin-ldouble_s.o darwin-world_s.o unwind-dw2_s.o > unwind-dw2-fde-darwin_s.o unwind-sjlj_s.o unwind-c_s.o > darwin-fallback_s.o emutls_s.o -lc> /usr/bin/ld: unknown flag: -macosx_version_min> collect2: ld returned 1 exit status> make[2]: *** [libgcc_s.dylib] Error 1> make[1]: *** [all-target-libgcc] Error 2> make: *** [all] Error 2> > I'm too sleepy to investigate further now,> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From wagner at elegosoft.com  Wed May  7 07:58:30 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Wed, 07 May 2008 07:58:30 +0200
Subject: [M3devel] m3cc build fails on older MacOS X
In-Reply-To: 
References: <20080506075754.o24j7xhx4wgokwwo@mail.elegosoft.com>
	
	<20080506130247.50uj68o11twcgkog@mail.elegosoft.com>
	
Message-ID: <20080507075830.sbcaopz70kg000co@mail.elegosoft.com>

Quoting Jay :

> Olaf, can you try without my m3makefile wierdness, that works elsewhere?
>
>   cd %CVSROOT%/m3-sys/m3cc    mkdir obj1     cd obj1     
> ../gcc/configure --disable-bootstrap --enable-languages=c,cm3cg      
> make
>  I'm not sure of "cm3cg", it might be "m3cg".  And you can just omit  
>  that anyway, I doubt the error is m3 related.
> (Tony: I don't believe --srcdir is needed. configure figures it out;  
>  granted, maybe not trivially.)
> ?
>  I expect you will get the same error.  Which isn't the final   
> answer, just some relevant data.   And if I'm wrong, well, that   
> suggests some fix.

I already answered this late yesterday evening, but somehow the mail
seems to have got lost. The build now stops with a wrong linker
switch:

mv tmp-libgcc.map libgcc.map
# @multilib_flags@ is still needed because this may use
# /Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/xgcc  
-B/Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/  
-B/usr/local/powerpc-apple-darwin7.9.0/bin/  
-B/usr/local/powerpc-apple-darwin7.9.0/lib/ -isystem  
/usr/local/powerpc-apple-darwin7.9.0/include -isystem  
/usr/local/powerpc-apple-darwin7.9.0/sys-include and -O2  -O2 -g -g  
-O2   -DIN_GCC    -W -Wall -Wwrite-strings -Wstrict-prototypes  
-Wmissing-prototypes -Wold-style-definition  -isystem ./include   
-Wa,-force_cpusubtype_ALL -pipe -mmacosx-version-min=10.4 -g  
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  directly.
# @multilib_dir@ is not really necessary, but sometimes it has
# more uses than just a directory name.
/bin/sh ../../../gcc/libgcc/../mkinstalldirs .
/Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/xgcc  
-B/Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/  
-B/usr/local/powerpc-apple-darwin7.9.0/bin/  
-B/usr/local/powerpc-apple-darwin7.9.0/lib/ -isystem  
/usr/local/powerpc-apple-darwin7.9.0/include -isystem  
/usr/local/powerpc-apple-darwin7.9.0/sys-include -O2  -O2 -g -g -O2    
-DIN_GCC    -W -Wall -Wwrite-strings -Wstrict-prototypes  
-Wmissing-prototypes -Wold-style-definition  -isystem ./include   
-Wa,-force_cpusubtype_ALL -pipe -mmacosx-version-min=10.4 -g  
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -dynamiclib  
-nodefaultlibs -install_name /usr/local/lib/libgcc_s`if test . = ppc64  
; then echo _. ; fi`.1.dylib -single_module -o ./libgcc_s.1.dylib.tmp  
-Wl,-exported_symbols_list,libgcc.map -compatibility_version 1  
-current_version 1.0 -O2 -g -g -O2 -B./ _muldi3_s.o _negdi2_s.o  
_lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o  
_clear_cache_s.o _enable_execute_stack_s.o _trampoline_s.o __main_s.o  
_absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o  
_subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o  
_ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o  
_ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o  
_popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o  
_powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o _muldc3_s.o  
_mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o  
_divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _fixunssfsi_s.o  
_fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o  
_fixtfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o  
_fixunstfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o  
_floatditf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o  
_floatunditf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o  
_udiv_w_sdiv_s.o _udivmoddi4_s.o darwin-tramp_s.o ppc64-fp_s.o  
darwin-64_s.o darwin-ldouble_s.o darwin-world_s.o unwind-dw2_s.o  
unwind-dw2-fde-darwin_s.o unwind-sjlj_s.o unwind-c_s.o  
darwin-fallback_s.o emutls_s.o -lc
/usr/bin/ld: unknown flag: -macosx_version_min
collect2: ld returned 1 exit status
make[2]: *** [libgcc_s.dylib] Error 1
make[1]: *** [all-target-libgcc] Error 2
make: *** [all] Error 2

Probably nobody cares anymore for Mac OS X 10.3.9; I'll consider an
upgrade 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 jayk123 at hotmail.com  Wed May  7 08:15:24 2008
From: jayk123 at hotmail.com (Jay)
Date: Wed, 7 May 2008 06:15:24 +0000
Subject: [M3devel] m3cc build fails on older MacOS X
In-Reply-To: <20080507075830.sbcaopz70kg000co@mail.elegosoft.com>
References: <20080506075754.o24j7xhx4wgokwwo@mail.elegosoft.com>
	
	<20080506130247.50uj68o11twcgkog@mail.elegosoft.com>
	 
	<20080507075830.sbcaopz70kg000co@mail.elegosoft.com>
Message-ID: 

I "answered" this, sort of. The mail was truncated but the important point came through.
Someone else reported this circa gcc 4.0 and then fixed in gcc 4.0.1 or such.
 
 > Probably nobody cares anymore for Mac OS X 10.3.9; I'll consider an
I'll add bringing up 10.2 or maybe 10.1 back somewhere on my list..
This should probably handled "upstream" via "configure".
 
Olaf, is what changed my m3makefile-ness or not?
That is, it fails one way with cm3, but differently/later/better with "regular" configure+make?
Could be a flaw in my m3makefile shenanigans. But so far they otherwise work and do cut out unnecessary stuff.
 
I haven't had a chance to look into anything all Tuesday.
 
 - Jay



> Date: Wed, 7 May 2008 07:58:30 +0200> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: RE: [M3devel] m3cc build fails on older MacOS X> > Quoting Jay :> > > Olaf, can you try without my m3makefile wierdness, that works elsewhere?> >> > cd %CVSROOT%/m3-sys/m3cc mkdir obj1 cd obj1 > > ../gcc/configure --disable-bootstrap --enable-languages=c,cm3cg > > make> > I'm not sure of "cm3cg", it might be "m3cg". And you can just omit > > that anyway, I doubt the error is m3 related.> > (Tony: I don't believe --srcdir is needed. configure figures it out; > > granted, maybe not trivially.)> > ?> > I expect you will get the same error. Which isn't the final > > answer, just some relevant data. And if I'm wrong, well, that > > suggests some fix.> > I already answered this late yesterday evening, but somehow the mail> seems to have got lost. The build now stops with a wrong linker> switch:> > mv tmp-libgcc.map libgcc.map> # @multilib_flags@ is still needed because this may use> # /Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/xgcc > -B/Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/ > -B/usr/local/powerpc-apple-darwin7.9.0/bin/ > -B/usr/local/powerpc-apple-darwin7.9.0/lib/ -isystem > /usr/local/powerpc-apple-darwin7.9.0/include -isystem > /usr/local/powerpc-apple-darwin7.9.0/sys-include and -O2 -O2 -g -g > -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes > -Wmissing-prototypes -Wold-style-definition -isystem ./include > -Wa,-force_cpusubtype_ALL -pipe -mmacosx-version-min=10.4 -g > -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED directly.> # @multilib_dir@ is not really necessary, but sometimes it has> # more uses than just a directory name.> /bin/sh ../../../gcc/libgcc/../mkinstalldirs .> /Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/xgcc > -B/Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/ > -B/usr/local/powerpc-apple-darwin7.9.0/bin/ > -B/usr/local/powerpc-apple-darwin7.9.0/lib/ -isystem > /usr/local/powerpc-apple-darwin7.9.0/include -isystem > /usr/local/powerpc-apple-darwin7.9.0/sys-include -O2 -O2 -g -g -O2 > -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes > -Wmissing-prototypes -Wold-style-definition -isystem ./include > -Wa,-force_cpusubtype_ALL -pipe -mmacosx-version-min=10.4 -g > -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -dynamiclib > -nodefaultlibs -install_name /usr/local/lib/libgcc_s`if test . = ppc64 > ; then echo _. ; fi`.1.dylib -single_module -o ./libgcc_s.1.dylib.tmp > -Wl,-exported_symbols_list,libgcc.map -compatibility_version 1 > -current_version 1.0 -O2 -g -g -O2 -B./ _muldi3_s.o _negdi2_s.o > _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o > _clear_cache_s.o _enable_execute_stack_s.o _trampoline_s.o __main_s.o > _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o > _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o > _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o > _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o > _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o > _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o _muldc3_s.o > _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o > _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _fixunssfsi_s.o > _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o > _fixtfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o > _fixunstfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o > _floatditf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o > _floatunditf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o > _udiv_w_sdiv_s.o _udivmoddi4_s.o darwin-tramp_s.o ppc64-fp_s.o > darwin-64_s.o darwin-ldouble_s.o darwin-world_s.o unwind-dw2_s.o > unwind-dw2-fde-darwin_s.o unwind-sjlj_s.o unwind-c_s.o > darwin-fallback_s.o emutls_s.o -lc> /usr/bin/ld: unknown flag: -macosx_version_min> collect2: ld returned 1 exit status> make[2]: *** [libgcc_s.dylib] Error 1> make[1]: *** [all-target-libgcc] Error 2> make: *** [all] Error 2> > Probably nobody cares anymore for Mac OS X 10.3.9; I'll consider an> upgrade 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> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From wagner at elegosoft.com  Wed May  7 08:23:20 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Wed, 07 May 2008 08:23:20 +0200
Subject: [M3devel] m3cc build fails on older MacOS X
In-Reply-To: 
References: <20080506075754.o24j7xhx4wgokwwo@mail.elegosoft.com>
	
	<20080506130247.50uj68o11twcgkog@mail.elegosoft.com>
	
	<20080507075830.sbcaopz70kg000co@mail.elegosoft.com>
	
Message-ID: <20080507082320.iuho7zbpz4w8cw4g@mail.elegosoft.com>

Quoting Jay :

> I "answered" this, sort of. The mail was truncated but the important  
>  point came through.
> Someone else reported this circa gcc 4.0 and then fixed in gcc 4.0.1 or such.

I don't get you here. If there already is a fix or workaround, why
isn't it checked-in? Could you please point me to your corresponding
mail?

>  > Probably nobody cares anymore for Mac OS X 10.3.9; I'll consider an
> I'll add bringing up 10.2 or maybe 10.1 back somewhere on my list..
> This should probably handled "upstream" via "configure".
>
> Olaf, is what changed my m3makefile-ness or not?
> That is, it fails one way with cm3, but differently/later/better   
> with "regular" configure+make?

Yes, it fails differently. I haven't investigated why, though.

> Could be a flaw in my m3makefile shenanigans. But so far they   
> otherwise work and do cut out unnecessary stuff.
>
> I haven't had a chance to look into anything all Tuesday.

No problem, neither had I except for a few minutes.

Olaf

>  - Jay
>
>
>
>> Date: Wed, 7 May 2008 07:58:30 +0200> From: wagner at elegosoft.com>   
>> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: RE:   
>> [M3devel] m3cc build fails on older MacOS X> > Quoting Jay   
>> :> > > Olaf, can you try without my m3makefile  
>>  wierdness, that works elsewhere?> >> > cd %CVSROOT%/m3-sys/m3cc   
>> mkdir obj1 cd obj1 > > ../gcc/configure --disable-bootstrap   
>> --enable-languages=c,cm3cg > > make> > I'm not sure of "cm3cg", it   
>> might be "m3cg". And you can just omit > > that anyway, I doubt the  
>>  error is m3 related.> > (Tony: I don't believe --srcdir is needed.  
>>  configure figures it out; > > granted, maybe not trivially.)> > ?>  
>>  > I expect you will get the same error. Which isn't the final > >   
>> answer, just some relevant data. And if I'm wrong, well, that > >   
>> suggests some fix.> > I already answered this late yesterday   
>> evening, but somehow the mail> seems to have got lost. The build   
>> now stops with a wrong linker> switch:> > mv tmp-libgcc.map   
>> libgcc.map> # @multilib_flags@ is still needed because this may   
>> use> # /Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/xgcc >   
>> -B/Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/ >   
>> -B/usr/local/powerpc-apple-darwin7.9.0/bin/ >   
>> -B/usr/local/powerpc-apple-darwin7.9.0/lib/ -isystem >   
>> /usr/local/powerpc-apple-darwin7.9.0/include -isystem >   
>> /usr/local/powerpc-apple-darwin7.9.0/sys-include and -O2 -O2 -g -g   
>> > -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes >   
>> -Wmissing-prototypes -Wold-style-definition -isystem ./include >   
>> -Wa,-force_cpusubtype_ALL -pipe -mmacosx-version-min=10.4 -g >   
>> -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   
>> directly.> # @multilib_dir@ is not really necessary, but sometimes   
>> it has> # more uses than just a directory name.> /bin/sh   
>> ../../../gcc/libgcc/../mkinstalldirs .>   
>> /Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/xgcc >   
>> -B/Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/ >   
>> -B/usr/local/powerpc-apple-darwin7.9.0/bin/ >   
>> -B/usr/local/powerpc-apple-darwin7.9.0/lib/ -isystem >   
>> /usr/local/powerpc-apple-darwin7.9.0/include -isystem >   
>> /usr/local/powerpc-apple-darwin7.9.0/sys-include -O2 -O2 -g -g -O2   
>> > -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes >   
>> -Wmissing-prototypes -Wold-style-definition -isystem ./include >   
>> -Wa,-force_cpusubtype_ALL -pipe -mmacosx-version-min=10.4 -g >   
>> -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   
>> -dynamiclib > -nodefaultlibs -install_name   
>> /usr/local/lib/libgcc_s`if test . = ppc64 > ; then echo _. ;   
>> fi`.1.dylib -single_module -o ./libgcc_s.1.dylib.tmp >   
>> -Wl,-exported_symbols_list,libgcc.map -compatibility_version 1 >   
>> -current_version 1.0 -O2 -g -g -O2 -B./ _muldi3_s.o _negdi2_s.o >   
>> _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o >   
>> _clear_cache_s.o _enable_execute_stack_s.o _trampoline_s.o   
>> __main_s.o > _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o   
>> _subvsi3_s.o > _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o   
>> _negvdi2_s.o > _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o   
>> _clzsi2_s.o _clzdi2_s.o > _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o  
>>  _popcountsi2_s.o > _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o   
>> _powisf2_s.o > _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o   
>> _muldc3_s.o > _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o   
>> _divxc3_s.o > _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o   
>> _fixunssfsi_s.o > _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o   
>> _fixdfdi_s.o _fixxfdi_s.o > _fixtfdi_s.o _fixunssfdi_s.o   
>> _fixunsdfdi_s.o _fixunsxfdi_s.o > _fixunstfdi_s.o _floatdisf_s.o   
>> _floatdidf_s.o _floatdixf_s.o > _floatditf_s.o _floatundisf_s.o   
>> _floatundidf_s.o _floatundixf_s.o > _floatunditf_s.o _divdi3_s.o   
>> _moddi3_s.o _udivdi3_s.o _umoddi3_s.o > _udiv_w_sdiv_s.o   
>> _udivmoddi4_s.o darwin-tramp_s.o ppc64-fp_s.o > darwin-64_s.o   
>> darwin-ldouble_s.o darwin-world_s.o unwind-dw2_s.o >   
>> unwind-dw2-fde-darwin_s.o unwind-sjlj_s.o unwind-c_s.o >   
>> darwin-fallback_s.o emutls_s.o -lc> /usr/bin/ld: unknown flag:   
>> -macosx_version_min> collect2: ld returned 1 exit status> make[2]:   
>> *** [libgcc_s.dylib] Error 1> make[1]: *** [all-target-libgcc]   
>> Error 2> make: *** [all] Error 2> > Probably nobody cares anymore   
>> for Mac OS X 10.3.9; I'll consider an> upgrade 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>



-- 
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 jayk123 at hotmail.com  Thu May  8 00:09:36 2008
From: jayk123 at hotmail.com (Jay)
Date: Wed, 7 May 2008 22:09:36 +0000
Subject: [M3devel] AMD64_LINUX snapshots available,
	without garbage collection
Message-ID: 


Now available at http://modula3.elegosoft.com/cm3/uploaded-archives/index.html


  cm3-min-POSIX-AMD64_LINUX-d5.7.0.tar.bz2
  cm3-min-POSIX-AMD64_LINUX-d5.7.0.tar.bz2


With some MAJOR caveats:


formsedit crashes
I haven't run most of the binaries.
Juno comes up.
Calculator comes up.
It builds itself -- cm3 works.
cm3cg is x86 hosted, can target x86 or AMD64 with -m32 or -m64.
cm3 is AMD64 hosted.


GARBAGE COLLECTION IS TURNED OFF via a one line hack in RTCollector.m3.
Turning it on crashes, not always in the same place.
This needs to be debugged.


This in a cminstall-less form, made with scripts/python/make-dist.py
  and manually patched to have Linux.common.


I have not yet tried m3tests.
I will shortly.


I also have TextLiteral.i3 locally changed to enable building from a 32 bit cm3.
Not a big deal, but if you are a stickler for binaries matching source..


If anyone else wants to debug the crashes with the garbage collector enabled, be my guest.
An easy repro is to build in m3-win/import-libs with cm3 -trace.
I assume -trace just causes more stuff to occur, more time to pass.


I didn't handle Uin.i3/Uucontext.i3 yet, hm.


This target is easily bootstrapped using x86 tools on an AMD64 system.
(ie: cm3; cm3cg as I said is still x86).
Hopefully soon I'll bring up platforms that don't have this 'cheat' available. :)

I do like:

 su
 cd /
 rm -rf /cm3
 tar xvf /cm3-min-POSIX-AMD64_LINUX-d5.7.0.tar.bz2
 cp -Rpv cm3-min-POSIX-AMD64_LINUX-d5.7.0 /cm3
 chown -R jay:jay /cm3
export PATH=$PATH:/cm3/bin
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/cm3/lib

However those are wrong if the paths are empty. They add the current working directory to the path if so, since "empty" is equivalent to ".", unfortunately. It should just be skipped/ignored but oh well.

I am using Ubuntu 8.4 Hardy Heron.
(Xubuntu, that was disappointing, so then apt-get-install kde or such)

 - Jay


From jayk123 at hotmail.com  Thu May  8 17:38:23 2008
From: jayk123 at hotmail.com (Jay)
Date: Thu, 8 May 2008 15:38:23 +0000
Subject: [M3devel] the matter of logging vs. NT386 C compilation
Message-ID: 

The Visual C++ compiler outputs source file name as they are compiled:
D:\dev2\cm3\m3-libs\m3core>cl -nologo -c nul.cnul.c
 
D:\dev2\cm3\m3-libs\m3core>cl -nologo -c nul.cnul.c
 
D:\dev2\cm3\m3-libs\m3core>cl -nologo -c nul.c nul.cnul.cnul.cGenerating Code...
I believe that suppressing this will suppress all other warning/error output.
See, they both go to stdout:
D:\dev2\cm3\m3-libs\m3core>echo error > foo.c
D:\dev2\cm3\m3-libs\m3core>cl -nologo -c foo.cfoo.cfoo.c(2) : fatal error C1004: unexpected end-of-file found
 
D:\dev2\cm3\m3-libs\m3core>cl -nologo -c foo.c >nul
 
D:\dev2\cm3\m3-libs\m3core>cl -nologo -c foo.c 2>nulfoo.cfoo.c(2) : fatal error C1004: unexpected end-of-file found
 
I tried something annoyingly expensive likecl -nologo -c foo.c | findstr /v /b /e foo.c 
 
which would only include lines that don't begin and end foo.c, but in normaluse, there are no such lines, there is just the one line, and so findstr fails, and so the overall command fails, not good.
 
You could do this:
 (echo. && cl -nologo -c foo.c)  | findstr /v /b /e foo.c 
Which nets you just a blank line output, but this seems to be heading to deep end, and even that blank line shouldn't be there.
Suggestions?
Maybe a change in cm3? Moving compile_c into it?My idea of moving Quake code into cm3 would be that cm3 has a definition of compile_c,but that if the user supplies compile_c, use that instead.
Doing that to solve just this is overkill, but it's not a bad idea anyway.
Smaller ideas could be considered, including:
1) Have all the compile_c implementations echo the source file, so they'd all have the same outputWhile is this is noisy in the user experience, there isn't much C.It does pollute all the platforms to cover up a small NT-specific problem.
2) What I suggested before, allow but to not encourage test cases to have per-platform results.This particular problem only affects test cases with C code, which is rare.There is one.
This would be very easy and solve the problem well.
It shouldn't be encouraged though, as it makes it more difficult to change the expected output of a test.
3) Currently if M3TESTS is defined, NT386.common redirects all C compiler output to nul.Good enough?
Related, in usage of GNU libtool, files are often compiled twice, once PIC, once not.The way it works, one invocation is directed to /dev/null, one is not.This would kinda sorta seem to set a precedent for redirecting C compiler output to /dev/null,except that they do run it both ways. It's not that errors are lost, just that they aren't doubled.
Also related, again, I suggest a log file.A detail hilighted here is that in fact ALL command would go to the log, and NONE would likelygo to stdout/stderr. Stdout/stderr would be strictly the domain of cm3.Perhaps cm3 could "sniff" for errors and pass them along, perhaps.
 
 
You know, really, the log file approach is already what is used for linking.
Why just linking? Why not everything run in the directory?
Ah, it looks like that isn't for all platforms though, just NT386.
 
I am half just making trouble here.
I think the logging should be more verbose, but even making it quiet is surprisingly difficult.
I guess the linking example shows the way though, I should just redirect C compiler output always to a file.
Maybe the same file as linking uses, maybe not.
The user experience in the face of error is, initially, badly degraded.
However there are ways to mitigate.
First, as with linking, upon error, we can tell the user about the file.
Second, upon error, we could just echo the file's contents to stdout.
It's just that for success, saying less is better.
 
I'll do that -- redirect to a file.
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Thu May  8 20:38:18 2008
From: jayk123 at hotmail.com (Jay)
Date: Thu, 8 May 2008 18:38:18 +0000
Subject: [M3devel] m3tests again
In-Reply-To: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
References: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
Message-ID: 

Olaf, sorry, not much here yet, except at least I do/did see problems where you see problems. Which ones are regressions?My numbers don't add up.I added one new failing test case, and I fixed one or two.
p116b floating pointp172  floating pointp185  floating point
--- p204 --- IP address initializers compiler crashes I think not new needs investigation
--- p206 --- ARRAY constructors in var decls using named open array types
 compiler gives reasonable error I think the compiler is correct. Updated expected outputs? Considering moving to category "e"?
 
--- p207 --- subrange declarations
 I think requires longint to really work. Disable for this platform?
--- p209 --- open array initializers compile failure
 compiler crashes (assertion failure) I think not new does need further investigation I changed the compiler to assert earlier for this
oh, also, I recently added this, knowing it doesn't pass yet
it is similar to p208 and/or p206.
 
--- p210 --- open array initializers runtime failure this is a new test I added I know it doesn't pass yet It shows a preexisting problem. And I messed up when I added it -- fixed now.
 
p209 and p210 are similar, but one fails an assertion in the compiler and one at runtime
--- r001 --- unhandled exception I believe this succeeds but possibly  the checking in the harness needs updated. I thought I had fixed it though. Darwin and FreeBSD need an update here though, simple.
--- e020 --- illegal recursive declaration builds and runs but is supposed to output a good error  and I think intead it infinitely recurses
--- e026 --- two types with the same brand I commited a fix in the compiler for this a few days ago.
 It was a simple error in yet another reinvention of linked lists.
--- e029 --- use type instead of value as an initializer fails assertion in compiler
 needs more investigation..
For most of these, I get no "@@" in the output,so maybe the test harness isn't working..But cd'ing around works.
sorry, I have to get going for nowmuch more hopefully later.
 - Jay


> Date: Tue, 6 May 2008 08:16:13 +0200> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: m3tests again> > Hi Jay,> > after several small fixes to the regression scripts, the nightrun> now shows for me> > >>> test_m3tests error extract:> >>> failed tests: p116b p172 p185 p204 p206 p207 p209 p210 r001 e020 > e026 e029> >>> 12 in test_m3tests 2008-05-06-01-30-23 > /home/wagner/work/cm3-ws/luthien-2008-05-06-01-30-23> > One week ago there were only 6. Could you have a closer look at this?> I'm still busy with other projects.> > 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 jayk123 at hotmail.com  Thu May  8 20:46:16 2008
From: jayk123 at hotmail.com (Jay)
Date: Thu, 8 May 2008 18:46:16 +0000
Subject: [M3devel] new NT386 snapshots
In-Reply-To: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
References: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
Message-ID: 

http://modula3.elegosoft.com/cm3/uploaded-archives/
 
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0.zip
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-WIN32-NT386-d5.7.0.zip
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0-symbols.zip
 
These should have:
  latest quake extensions 
  set relation fixes 
  other set fixes revealed through dynamic linking of one regression test 
  hypothetical ability to cross-build to AMD64_LINUX, AMD64_DARWIN  
  one jmpbuf size for all NT386 configurations (NT386, NT386GNU, NT386MINGNU) 
 
Built with Visual C++ 9.0 Express, so you'll want:
http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en
 
 
Still more work to do though, e.g. assertion failures in unit tests, pixmap..
 
Fuller disclosure:
Something is leaking memory on my system such that "everything" starts "failing" and I have to reboot.
This isn't Modula-3 related.
Hopefully these files aren't damaged as a result.
Must be some buggy driver or something..
 
Aside:
 The environment variable thingy has been bugging me a long time and I finally looked deeper at it.
It appears broken in CM3 4.x. I didn't check 3.x yet.
I'm still mulling a fix, and haven't run a repro of the break, but it's not a big deal either way.
Basically console apps use main that takes char** and gui apps use WinMain that doesn't get environment variables but the generated code calls GetEvironmentStrings() which returns null separated strings.
Must be that hardly anyone uses environment variables in Modula-3 on Win32 for this to have lingered so long, at least gui apps.
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Thu May  8 20:57:08 2008
From: jayk123 at hotmail.com (Jay)
Date: Thu, 8 May 2008 18:57:08 +0000
Subject: [M3devel] pixmap problem
In-Reply-To: <481F9804.1E75.00D7.1@scires.com>
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	 
	<481F9804.1E75.00D7.1@scires.com> 
Message-ID: 

Randy, At first very quick glance, this stuff looks ok.CM3-IDE probably doesn't really understand the config file, similar to m3cgcat's partial misunderstanding.
  (Which is why I keep TARGET declared in NT386* instead of just NT386.common.)
PKG_USE is defined I think, but it takes a really accurate understanding of Quake to get it.
 
The entry/subsystem stuff also seems complete but I didn't try examples yet.
Sorry, didn't give this all much time yet.
I did get me to look at the environment variable bug that's been sitting there forever, with a bogus fix..
 
Can CM3-IDE default PKG_USE to CM3_ROOT + "/pkg"? Or INSTALL_ROOT + "/pkg"? Or whatever?
That is what it always is, in anything that is checked in or that cminstall will give you.
It takes hand editing of cm3.cfg to get anything else I think.
 
Or CM3-IDE users can just edit the file some. Not a lot. But some.
Given an incomplete understanding of the config files, probably putting in CM3-IDE wants but under if FALSE will perhaps work.
Personally I wasn't impressed with Reactor... VC5 find-in-files gets me all I need. Anything besides plain text search doesn't scale..
 
 - Jay


From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problemDate: Tue, 6 May 2008 03:38:03 +0000


Randy, don't worry.Two of these problems are trivial to fix -- PKG_USE and popups.The pixmap one will need debugging.  - Jay


Date: Mon, 5 May 2008 23:28:10 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad news is that now I am getting a command window opening up in addition to the GUI window when the program runs.  This behavior does not occur on v4.1.  The command window seems to be the stdout/stderr of the GUI program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy>>> Jay  5/5/2008 10:47 PM >>>Randy, Yes.The NT386 config files are all checked in.You can use them verbatim. You don't need cminstall, I never use it, and you shouldn't need to edit the config files at all, any edits I make, I check in, and should be usable on all machines.As long as you set %PATH%/%INCLUDE%/%LIB%.If I'm wrong, I'd like to know why and try to fix. Consider the config files just part of cm3.exe.Not generally to be changed locally. Unless, well, unless you intend to, and you should strive to make one form that is usable by all.  - Jay


Date: Mon, 5 May 2008 22:42:30 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay,
When you say "took the updated config file", what do you mean?  Are you saying I need a different cm3.cfg file?
Regards,
Randy>>> Jay  5/5/2008 9:54 PM >>>And you took the updated config file?The way you can tell is that, roughly speaking, hand.obj should be in NT386\_m3responsefile0.txt.Or _m3responsefile1.txt, or, well, somewhere.Anyway, I think I saw the attachment, I can check later..and with 4.1 as I said.. I can see about making the fix not depend on config file changes...but it's not terrible asis, and I'd really like to merge more of the quake code into cm3.exe..  - Jay


Date: Mon, 5 May 2008 21:18:12 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem
Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly when the buildstandalone() directive is used.
 
Regards,
Randy>>> Jay  5/5/2008 7:04 PM >>>Thanks. I'll look into this tonight probably, as well as with 4.1 assuming I can find my binaries and source for it (probably).COULD BE the pixmap problem is something else and 4.1 also has the problem I fixed. We'll see. No need to speculate (unless I can't find my 4.1). - Jay


Date: Mon, 5 May 2008 10:59:27 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problem
Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy>>> Jay  5/4/2008 11:46 AM >>>Randy, Please try with /current/ source, as of this morning Sunday May 4 -- the changes are ALL in NT386.common, so you MUST use MY config files, which are checked in verbatim, or you should be able edit whatever config files you are using. (It's not really a config file issue, don't blame the general confusion people have with them.) I'll try to try later, but I don't have the source right now, gotta look on other machines, and I think it's on a machine on loan.  Or send it to me again.I'd also like to know if this worked with 4.1, or with any release that offered dynamic linking to m3core.dll, on Windows.  I recall a claim that it did. If today's change fixes it, I should be able to investigate 4.1.3.6 did not have such linking.If today's change does not help, well, I still plan on debugging it at some point.. If you aren't current and getting so is difficult, just send the attachment again, it's easy for me to test. Thanks, - Jay


From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rcoleburn at scires.comDate: Sat, 19 Jan 2008 08:52:08 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.I was going to try on PPC_DARWIN but I guess Tony's info suffices. I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. Debugging here is a big humungous pain.NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)And bundles look pretty simple, a bundle is just a generated source file with a constant in it.Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something. The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for? I have to say this is very surprising. I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so.The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: pointer to msvcrt!fopenpointer to msvcrt!fclosenullpointer to kernel32!Sleep But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo.But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo.That doesn't work for data though. There's no ability to intervenve like that.So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it.And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.However that would suck perf in order to make an uncommon case work.I hope Modula-3 doesn't do that either. :)Though I guess since this global data in question...maybe it is rare??? Later, - Jay

> From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 03:09:47 -0500> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] pixmap problem> > Looks fine to me on I386_DARWIN.> > On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:> > > > 

Need to know the score, the latest news, or you need your Hotmail?-get your "fix" Check it out. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Thu May  8 21:21:49 2008
From: jayk123 at hotmail.com (Jay)
Date: Thu, 8 May 2008 19:21:49 +0000
Subject: [M3devel] FW:  pixmap problem
In-Reply-To: <481F9804.1E75.00D7.1@scires.com>
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	 
	<481F9804.1E75.00D7.1@scires.com>  
Message-ID: 

truncated again...


From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problemDate: Thu, 8 May 2008 18:57:08 +0000


Randy, At first very quick glance, this stuff looks ok.CM3-IDE probably doesn't really understand the config file, similar to m3cgcat's partial misunderstanding.  (Which is why I keep TARGET declared in NT386* instead of just NT386.common.)PKG_USE is defined I think, but it takes a really accurate understanding of Quake to get it. The entry/subsystem stuff also seems complete but I didn't try examples yet.Sorry, didn't give this all much time yet.I did get me to look at the environment variable bug that's been sitting there forever, with a bogus fix.. Can CM3-IDE default PKG_USE to CM3_ROOT + "/pkg"? Or INSTALL_ROOT + "/pkg"? Or whatever?That is what it always is, in anything that is checked in or that cminstall will give you.It takes hand editing of cm3.cfg to get anything else I think. Or CM3-IDE users can just edit the file some. Not a lot. But some.Given an incomplete understanding of the config files, probably putting in CM3-IDE wants but under if FALSE will perhaps work.Personally I wasn't impressed with Reactor... VC5 find-in-files gets me all I need. Anything besides plain text search doesn't scale..  - Jay


From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problemDate: Tue, 6 May 2008 03:38:03 +0000

Randy, don't worry.Two of these problems are trivial to fix -- PKG_USE and popups.The pixmap one will need debugging.  - Jay


Date: Mon, 5 May 2008 23:28:10 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad news is that now I am getting a command window opening up in addition to the GUI window when the program runs.  This behavior does not occur on v4.1.  The command window seems to be the stdout/stderr of the GUI program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy>>> Jay  5/5/2008 10:47 PM >>>Randy, Yes.The NT386 config files are all checked in.You can use them verbatim. You don't need cminstall, I never use it, and you shouldn't need to edit the config files at all, any edits I make, I check in, and should be usable on all machines.As long as you set %PATH%/%INCLUDE%/%LIB%.If I'm wrong, I'd like to know why and try to fix. Consider the config files just part of cm3.exe.Not generally to be changed locally. Unless, well, unless you intend to, and you should strive to make one form that is usable by all.  - Jay


Date: Mon, 5 May 2008 22:42:30 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay,
When you say "took the updated config file", what do you mean?  Are you saying I need a different cm3.cfg file?
Regards,
Randy>>> Jay  5/5/2008 9:54 PM >>>And you took the updated config file?The way you can tell is that, roughly speaking, hand.obj should be in NT386\_m3responsefile0.txt.Or _m3responsefile1.txt, or, well, somewhere.Anyway, I think I saw the attachment, I can check later..and with 4.1 as I said.. I can see about making the fix not depend on config file changes...but it's not terrible asis, and I'd really like to merge more of the quake code into cm3.exe..  - Jay


Date: Mon, 5 May 2008 21:18:12 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem
Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly when the buildstandalone() directive is used.
 
Regards,
Randy>>> Jay  5/5/2008 7:04 PM >>>Thanks. I'll look into this tonight probably, as well as with 4.1 assuming I can find my binaries and source for it (probably).COULD BE the pixmap problem is something else and 4.1 also has the problem I fixed. We'll see. No need to speculate (unless I can't find my 4.1). - Jay


Date: Mon, 5 May 2008 10:59:27 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problem
Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy>>> Jay  5/4/2008 11:46 AM >>>Randy, Please try with /current/ source, as of this morning Sunday May 4 -- the changes are ALL in NT386.common, so you MUST use MY config files, which are checked in verbatim, or you should be able edit whatever config files you are using. (It's not really a config file issue, don't blame the general confusion people have with them.) I'll try to try later, but I don't have the source right now, gotta look on other machines, and I think it's on a machine on loan.  Or send it to me again.I'd also like to know if this worked with 4.1, or with any release that offered dynamic linking to m3core.dll, on Windows.  I recall a claim that it did. If today's change fixes it, I should be able to investigate 4.1.3.6 did not have such linking.If today's change does not help, well, I still plan on debugging it at some point.. If you aren't current and getting so is difficult, just send the attachment again, it's easy for me to test. Thanks, - Jay


From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rcoleburn at scires.comDate: Sat, 19 Jan 2008 08:52:08 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.I was going to try on PPC_DARWIN but I guess Tony's info suffices. I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. Debugging here is a big humungous pain.NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)And bundles look pretty simple, a bundle is just a generated source file with a constant in it.Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something. The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for? I have to say this is very surprising. I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so.The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: pointer to msvcrt!fopenpointer to msvcrt!fclosenullpointer to kernel32!Sleep But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo.But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo.That doesn't work for data though. There's no ability to intervenve like that.So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it.And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.However that would suck perf in order to make an uncommon case work.I hope Modula-3 doesn't do that either. :)Though I guess since this global data in question...maybe it is rare??? Later, - Jay

> From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 03:09:47 -0500> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] pixmap problem> > Looks fine to me on I386_DARWIN.> > On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:> > > > 

Need to know the score, the latest news, or you need your Hotmail?-get your "fix" Check it out. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Thu May  8 22:17:37 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Thu, 08 May 2008 16:17:37 -0400
Subject: [M3devel] new NT386 snapshots
In-Reply-To: 
References: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
	
Message-ID: <4823279D.1E75.00D7.1@scires.com>

Jay:
 
I have both console and gui programs built using 4.1 that do pull stuff out of the environment.  I've not noticed any problems with either mode.
 
>From my perspective, the old 4.1 seems more reliable than the current system in a number of respects.  I have a new project with a hard deadline that I would like to use the new cm3 system for, but until these problems (pixmaps, buildstandalone, environ vars, serial i/o, etc.) can be resolved, I'm going to keep using 4.1 for my production work.
 
Regards,
Randy

>>> Jay  5/8/2008 2:46 PM >>>
http://modula3.elegosoft.com/cm3/uploaded-archives/ 
 
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0.zip 
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-WIN32-NT386-d5.7.0.zip 
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0-symbols.zip 
 
These should have:
  latest quake extensions 
  set relation fixes 
  other set fixes revealed through dynamic linking of one regression test 
  hypothetical ability to cross-build to AMD64_LINUX, AMD64_DARWIN  
  one jmpbuf size for all NT386 configurations (NT386, NT386GNU, NT386MINGNU) 
 
Built with Visual C++ 9.0 Express, so you'll want:
http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en 
 
 
Still more work to do though, e.g. assertion failures in unit tests, pixmap..
 
Fuller disclosure:
Something is leaking memory on my system such that "everything" starts "failing" and I have to reboot.
This isn't Modula-3 related.
Hopefully these files aren't damaged as a result.
Must be some buggy driver or something..
 
Aside:
 The environment variable thingy has been bugging me a long time and I finally looked deeper at it.
It appears broken in CM3 4.x. I didn't check 3.x yet.
I'm still mulling a fix, and haven't run a repro of the break, but it's not a big deal either way.
Basically console apps use main that takes char** and gui apps use WinMain that doesn't get environment variables but the generated code calls GetEvironmentStrings() which returns null separated strings.
Must be that hardly anyone uses environment variables in Modula-3 on Win32 for this to have lingered so long, at least gui apps.
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Thu May  8 22:35:54 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Thu, 08 May 2008 16:35:54 -0400
Subject: [M3devel] FW:  pixmap problem
In-Reply-To: 
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	
	<481F9804.1E75.00D7.1@scires.com> <481F9804.1E75.00D7.1@scires.com>
	
Message-ID: <48232BE6.1E75.00D7.1@scires.com>

Jay:
 
I've made some changes to CM3IDE that seem to allow it to cope with
your new cm3.cfg file.  
 
[Aside:  I do not understand your insistence that we can no longer have
all of the variables defined that used to be there back in the 4.1 days.
 When you make these types of unilateral changes without making
provision for reliant code, you wind up breaking stuff that used to
work.]
 
Bottom line, I've got CM3IDE working now for me on WindowsXP using your
NT386/NT386.common for cm3.cfg.  Others will need to test on other
platforms once we get the final go-ahead to put the code in the
repository.
 
As for the difference in the console window startup for gui programs,
that will be real show-stopper for production code.  I can't deliver a
GUI program that is going to have a command shell window popped open for
stdout/stderr output.
 
The pixmap problem is another show-stopper for production code.
 
I can't use the new cm3 for production code until these major problems
are resolved.  Any help you can offer in resolving these is
appreciated.
 
[Aside:  What is the deal with your email program truncating your
messages?  This is very bothersome.]
 
Regards,
Randy

>>> Jay  5/8/2008 3:21 PM >>>
truncated again...




From: jayk123 at hotmail.com 
To: rcoleburn at scires.com; m3devel at elegosoft.com 
Subject: RE: [M3devel] pixmap problem
Date: Thu, 8 May 2008 18:57:08 +0000

Randy, At first very quick glance, this stuff looks ok.
CM3-IDE probably doesn't really understand the config file, similar to
m3cgcat's partial misunderstanding.
  (Which is why I keep TARGET declared in NT386* instead of just
NT386.common.)
PKG_USE is defined I think, but it takes a really accurate
understanding of Quake to get it.
 
The entry/subsystem stuff also seems complete but I didn't try examples
yet.
Sorry, didn't give this all much time yet.
I did get me to look at the environment variable bug that's been
sitting there forever, with a bogus fix..
 
Can CM3-IDE default PKG_USE to CM3_ROOT + "/pkg"? Or INSTALL_ROOT +
"/pkg"? Or whatever?
That is what it always is, in anything that is checked in or that
cminstall will give you.
It takes hand editing of cm3.cfg to get anything else I think.
 
Or CM3-IDE users can just edit the file some. Not a lot. But some.
Given an incomplete understanding of the config files, probably putting
in CM3-IDE wants but under if FALSE will perhaps work.
Personally I wasn't impressed with Reactor... VC5 find-in-files gets me
all I need. Anything besides plain text search doesn't scale..
 
 - Jay
From: jayk123 at hotmail.com 
To: rcoleburn at scires.com; m3devel at elegosoft.com 
Subject: RE: [M3devel] pixmap problem
Date: Tue, 6 May 2008 03:38:03 +0000

Randy, don't worry.
Two of these problems are trivial to fix -- PKG_USE and popups.
The pixmap one will need debugging.
 
 - Jay

Date: Mon, 5 May 2008 23:28:10 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com; jayk123 at hotmail.com 
Subject: RE: [M3devel] pixmap problem

Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've
copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad
news is that now I am getting a command window opening up in addition to
the GUI window when the program runs.  This behavior does not occur on
v4.1.  The command window seems to be the stdout/stderr of the GUI
program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which
needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy

>>> Jay  5/5/2008 10:47 PM >>>
Randy, Yes.
The NT386 config files are all checked in.
You can use them verbatim. You don't need cminstall, I never use it,
and you shouldn't need to edit the config files at all, any edits I
make, I check in, and should be usable on all machines.
As long as you set %PATH%/%INCLUDE%/%LIB%.
If I'm wrong, I'd like to know why and try to fix.
 
Consider the config files just part of cm3.exe.
Not generally to be changed locally. Unless, well, unless you intend
to, and you should strive to make one form that is usable by all.
 
 - Jay


Date: Mon, 5 May 2008 22:42:30 -0400
From: rcoleburn at scires.com 
To: jayk123 at hotmail.com 
Subject: RE: [M3devel] pixmap problem

Jay,
When you say "took the updated config file", what do you mean?  Are you
saying I need a different cm3.cfg file?
Regards,
Randy

>>> Jay  5/5/2008 9:54 PM >>>
And you took the updated config file?
The way you can tell is that, roughly speaking, hand.obj should be in
NT386\_m3responsefile0.txt.
Or _m3responsefile1.txt, or, well, somewhere.
Anyway, I think I saw the attachment, I can check later..and with 4.1
as I said..
 
I can see about making the fix not depend on config file changes...but
it's not terrible asis, and I'd really like to merge more of the quake
code into cm3.exe..
 
 - Jay

Date: Mon, 5 May 2008 21:18:12 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com 
Subject: Re: [M3devel] pixmap problem

Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly
when the buildstandalone() directive is used.
 
Regards,
Randy

>>> Jay  5/5/2008 7:04 PM >>>
Thanks. I'll look into this tonight probably, as well as with 4.1
assuming I can find my binaries and source for it (probably).

COULD BE the pixmap problem is something else and 4.1 also has the
problem I fixed. We'll see. No need to speculate (unless I can't find my
4.1).

 - Jay


Date: Mon, 5 May 2008 10:59:27 -0400
From: rcoleburn at scires.com 
To: jayk123 at hotmail.com 
CC: m3devel at elegosoft.com 
Subject: RE: [M3devel] pixmap problem

Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files
or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy

>>> Jay  5/4/2008 11:46 AM >>>
Randy, Please try with /current/ source, as of this morning Sunday May
4 -- the changes are ALL in NT386.common, so you MUST use MY config
files, which are checked in verbatim, or you should be able edit
whatever config files you are using.
 
(It's not really a config file issue, don't blame the general confusion
people have with them.)
 
I'll try to try later, but I don't have the source right now, gotta
look on other machines, and I think it's on a machine on loan.
  Or send it to me again.
I'd also like to know if this worked with 4.1, or with any release that
offered dynamic linking to m3core.dll, on Windows.
  I recall a claim that it did. If today's change fixes it, I should be
able to investigate 4.1.
3.6 did not have such linking.
If today's change does not help, well, I still plan on debugging it at
some point..
 
If you aren't current and getting so is difficult, just send the
attachment again, it's easy for me to test.
 
Thanks,
 - Jay

From: jayk123 at hotmail.com 
To: hosking at cs.purdue.edu; rcoleburn at scires.com 
Date: Sat, 19 Jan 2008 08:52:08 +0000
CC: m3devel at elegosoft.com 
Subject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.
I was going to try on PPC_DARWIN but I guess Tony's info suffices.
 
I tried rolling hand.c back to before I changed (months/year ago),
since it is involved in bit twiddling, no change, phew.
 
Debugging here is a big humungous pain.
NT386 has good stacks and line numbers, but no locals or type info, I'd
really sometime like to get Codeview info into those .objs...I think it
is documented well enough, but still not necessarily easy, or maybe have
a C generating backend partly for this reason (and to bring up more
targets, using native tools), and function calls in disassembly I think
don't resolve; NT386GNU can't yet build this, though it will soon, but
I'm not familiar with gdb and there appears to be no type info. I'm
building m3gdb right now, I don't know if it will work, I hope it has
type info, and I'm not familiar with the relevant code. In gdb I
struggle just to view bytes in memory, add numbers to addresses and see
those, etc. I think for MY problem, I'm going to link in C code to dump
the structs. There is tracing code and I enabled it, but even it crashes
in Text_Length. At least MY problem crashes, hopefully near the problem,
whereas your problem goes all the way through to completion with no
stopping to hint where the problem is. Darn it. :) on the mock rudeness
and :( on the lack of a crash.
 
You write the bundle out and it matches, so that doesn't rule out
bundles as being the problem? (darn)
And bundles look pretty simple, a bundle is just a generated source
file with a constant in it.
Maybe newline problems? That wouldn't make sense. I just downloaded
some program that might let me separately view the ppm, maybe it'll
reveal something.
 
The bad behavior has like regularly spaced solid color veritical bars a
few pixels side across the whole picture, and regularly spaced vertical
stripes from the correct picture alternating with that. Perhaps someone
with ppm/bitmap/graphics experience has seen this behavior and it
results from some common pixmap mismanagement we could look for?
 
I have to say this is very surprising.
 
I always wondered, and now I pretty much assume -- Modula-3 never
imports/exports data in its dynamic linking, right? It alway
imports/exports functions, right?
On Windows, functions have an optional optimization, but data must be
handled differently at compile time if it is going to be dynamically
imported.
For functions, if you don't apply the optimization at compile time, the
linker will just generate a single instruction thunk instead.
 
That is, given a symbol Foo, there is a symbol __imp__Foo that is a
pointer to the actual foo in another .dll/.so.
The loader only patches pointers, one per import if you build your .dll
correctly, it doesn't patch instructions or code strewn throughout a
.dll, just one contiguous array of pointers. MAYBE they don't have to be
contiguous for each .dl you import from.
 
That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my
.dll/.exe typically has an array:
 
pointer to msvcrt!fopen
pointer to msvcrt!fclose
null
pointer to kernel32!Sleep
 
But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not
be adjacent.
 
So, going back, my point/question is that, if the compiler knows the
function is imported, it can call through __imp__Foo instead of calling
Foo.
But if it calls Foo and you import Foo, the linker will create the
function Foo that just jmps through __imp__Foo.
That doesn't work for data though. There's no ability to intervenve
like that.
So for imported data, the compiler must generated a read and
dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to
be imported.
Data imports may be faster when appropriate, but for this reason, I'd
say they aren't worth it.
And for this reason, I HOPE Modula-3 never imports/exports data.
 
Oh, you could, for data, always reference the pointer __imp_Foo, and if
non materializes, create one.
However that would suck perf in order to make an uncommon case work.
I hope Modula-3 doesn't do that either. :)
Though I guess since this global data in question...maybe it is
rare???
 
Later,
 - Jay



> From: hosking at cs.purdue.edu 
> Date: Sat, 19 Jan 2008 03:09:47 -0500
> To: rcoleburn at scires.com 
> CC: m3devel at elegosoft.com 
> Subject: Re: [M3devel] pixmap problem
> 
> Looks fine to me on I386_DARWIN.
> 
> On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:
> 
> > 
> 


Need to know the score, the latest news, or you need your Hotmail*-get
your "fix" Check it out. ( http://www.msnmobilefix.com/Default.aspx ) 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Thu May  8 23:05:15 2008
From: jayk123 at hotmail.com (Jay)
Date: Thu, 8 May 2008 21:05:15 +0000
Subject: [M3devel] FW:  pixmap problem
In-Reply-To: <48232BE6.1E75.00D7.1@scires.com>
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	
	<481F9804.1E75.00D7.1@scires.com> <481F9804.1E75.00D7.1@scires.com>
	 
	<48232BE6.1E75.00D7.1@scires.com>
Message-ID: 

Randy, I don't insist on not having it -- it is in fact there. CM3IDE may have its own parser for quake files such that it doesn't understand it, but it is there. But indeed, variables that are either unused or almost never used, shouldn't stick around. Things get crufty when there is too much "just in case". Things get hard to change when some things depend on too many imlementation details.The gui problem is simple no matter what. There's just not much there. I'll look later.
 - Jay


Date: Thu, 8 May 2008 16:35:54 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] FW: pixmap problem

Jay:
 
I've made some changes to CM3IDE that seem to allow it to cope with your new cm3.cfg file.  
 
[Aside:  I do not understand your insistence that we can no longer have all of the variables defined that used to be there back in the 4.1 days.  When you make these types of unilateral changes without making provision for reliant code, you wind up breaking stuff that used to work.]
 
Bottom line, I've got CM3IDE working now for me on WindowsXP using your NT386/NT386.common for cm3.cfg.  Others will need to test on other platforms once we get the final go-ahead to put the code in the repository.
 
As for the difference in the console window startup for gui programs, that will be real show-stopper for production code.  I can't deliver a GUI program that is going to have a command shell window popped open for stdout/stderr output.
 
The pixmap problem is another show-stopper for production code.
 
I can't use the new cm3 for production code until these major problems are resolved.  Any help you can offer in resolving these is appreciated.
 
[Aside:  What is the deal with your email program truncating your messages?  This is very bothersome.]
 
Regards,
Randy>>> Jay  5/8/2008 3:21 PM >>>truncated again...


From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problemDate: Thu, 8 May 2008 18:57:08 +0000

Randy, At first very quick glance, this stuff looks ok.CM3-IDE probably doesn't really understand the config file, similar to m3cgcat's partial misunderstanding.  (Which is why I keep TARGET declared in NT386* instead of just NT386.common.)PKG_USE is defined I think, but it takes a really accurate understanding of Quake to get it. The entry/subsystem stuff also seems complete but I didn't try examples yet.Sorry, didn't give this all much time yet.I did get me to look at the environment variable bug that's been sitting there forever, with a bogus fix.. Can CM3-IDE default PKG_USE to CM3_ROOT + "/pkg"? Or INSTALL_ROOT + "/pkg"? Or whatever?That is what it always is, in anything that is checked in or that cminstall will give you.It takes hand editing of cm3.cfg to get anything else I think. Or CM3-IDE users can just edit the file some. Not a lot. But some.Given an incomplete understanding of the config files, probably putting in CM3-IDE wants but under if FALSE will perhaps work.Personally I wasn't impressed with Reactor... VC5 find-in-files gets me all I need. Anything besides plain text search doesn't scale..  - Jay


From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problemDate: Tue, 6 May 2008 03:38:03 +0000

Randy, don't worry.Two of these problems are trivial to fix -- PKG_USE and popups.The pixmap one will need debugging.  - Jay


Date: Mon, 5 May 2008 23:28:10 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad news is that now I am getting a command window opening up in addition to the GUI window when the program runs.  This behavior does not occur on v4.1.  The command window seems to be the stdout/stderr of the GUI program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy>>> Jay  5/5/2008 10:47 PM >>>Randy, Yes.The NT386 config files are all checked in.You can use them verbatim. You don't need cminstall, I never use it, and you shouldn't need to edit the config files at all, any edits I make, I check in, and should be usable on all machines.As long as you set %PATH%/%INCLUDE%/%LIB%.If I'm wrong, I'd like to know why and try to fix. Consider the config files just part of cm3.exe.Not generally to be changed locally. Unless, well, unless you intend to, and you should strive to make one form that is usable by all.  - Jay


Date: Mon, 5 May 2008 22:42:30 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay,
When you say "took the updated config file", what do you mean?  Are you saying I need a different cm3.cfg file?
Regards,
Randy>>> Jay  5/5/2008 9:54 PM >>>And you took the updated config file?The way you can tell is that, roughly speaking, hand.obj should be in NT386\_m3responsefile0.txt.Or _m3responsefile1.txt, or, well, somewhere.Anyway, I think I saw the attachment, I can check later..and with 4.1 as I said.. I can see about making the fix not depend on config file changes...but it's not terrible asis, and I'd really like to merge more of the quake code into cm3.exe..  - Jay


Date: Mon, 5 May 2008 21:18:12 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem
Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly when the buildstandalone() directive is used.
 
Regards,
Randy>>> Jay  5/5/2008 7:04 PM >>>Thanks. I'll look into this tonight probably, as well as with 4.1 assuming I can find my binaries and source for it (probably).COULD BE the pixmap problem is something else and 4.1 also has the problem I fixed. We'll see. No need to speculate (unless I can't find my 4.1). - Jay


Date: Mon, 5 May 2008 10:59:27 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problem
Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy>>> Jay  5/4/2008 11:46 AM >>>Randy, Please try with /current/ source, as of this morning Sunday May 4 -- the changes are ALL in NT386.common, so you MUST use MY config files, which are checked in verbatim, or you should be able edit whatever config files you are using. (It's not really a config file issue, don't blame the general confusion people have with them.) I'll try to try later, but I don't have the source right now, gotta look on other machines, and I think it's on a machine on loan.  Or send it to me again.I'd also like to know if this worked with 4.1, or with any release that offered dynamic linking to m3core.dll, on Windows.  I recall a claim that it did. If today's change fixes it, I should be able to investigate 4.1.3.6 did not have such linking.If today's change does not help, well, I still plan on debugging it at some point.. If you aren't current and getting so is difficult, just send the attachment again, it's easy for me to test. Thanks, - Jay


From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rcoleburn at scires.comDate: Sat, 19 Jan 2008 08:52:08 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.I was going to try on PPC_DARWIN but I guess Tony's info suffices. I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. Debugging here is a big humungous pain.NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)And bundles look pretty simple, a bundle is just a generated source file with a constant in it.Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something. The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for? I have to say this is very surprising. I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so.The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: pointer to msvcrt!fopenpointer to msvcrt!fclosenullpointer to kernel32!Sleep But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo.But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo.That doesn't work for data though. There's no ability to intervenve like that.So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it.And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.However that would suck perf in order to make an uncommon case work.I hope Modula-3 doesn't do that either. :)Though I guess since this global data in question...maybe it is rare??? Later, - Jay

> From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 03:09:47 -0500> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] pixmap problem> > Looks fine to me on I386_DARWIN.> > On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:> > > > 

Need to know the score, the latest news, or you need your Hotmail?-get your "fix" Check it out. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Thu May  8 23:18:04 2008
From: jayk123 at hotmail.com (Jay)
Date: Thu, 8 May 2008 21:18:04 +0000
Subject: [M3devel] new NT386 snapshots
In-Reply-To: <4823279D.1E75.00D7.1@scires.com>
References: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
	 
	<4823279D.1E75.00D7.1@scires.com>
Message-ID: 

The code in 4.1 in clearly, by inspection, incorrect. I'll have to test it out and debug it though. Inspection isn't enough.I have no idea why my mail gets truncated. I agree it is annoying.
 
F:\products\modula3\CONTRIB\SRC-M3\m3\m3core\src\runtime\WIN32\RTArgs.m3(7):(* In Windows/NT, "envp" points at a null-terminated block ofF:\products\modula3\CONTRIB\SRC-M3\m3\m3core\src\runtime\WIN32\RTArgs.m3(144):    envp : Ctypes.char_star := RTLinker.info.envp;
f:\products\modula3\CONTRIB\SRC-M3\m3\m3linker\src\MxGen.m3(117):    Out (s, "  _ADDRESS envp;", s.eol);f:\products\modula3\CONTRIB\SRC-M3\m3\m3linker\src\MxGen.m3(480):    Out (s, "  /* envp       */ 0,", s.eol);f:\products\modula3\CONTRIB\SRC-M3\m3\m3linker\src\MxGen.m3(498):      Out (s, "    _m3_link_info.envp = (_ADDRESS)GetEnvironmentStrings();", s.eol);f:\products\modula3\CONTRIB\SRC-M3\m3\m3linker\src\MxGen.m3(501):      Out (s, "int main (argc, argv, envp)", s.eol);f:\products\modula3\CONTRIB\SRC-M3\m3\m3linker\src\MxGen.m3(504):      Out (s, "char **envp;", s.eol);f:\products\modula3\CONTRIB\SRC-M3\m3\m3linker\src\MxGen.m3(512):      Out (s, "    _m3_link_info.envp = (_ADDRESS)(envp);", s.eol); > serial i/o?
 
I haven't touched it, looked it really, or heard of any problems.
I looked at it for purposes of NT386GNU but didn't really do anything.
 
Pixmaps need debugging, indeed.
 
I found my 4.1 CD. :)
 
- Jay


Date: Thu, 8 May 2008 16:17:37 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] new NT386 snapshots

Jay:
 
I have both console and gui programs built using 4.1 that do pull stuff out of the environment.  I've not noticed any problems with either mode.
 
>From my perspective, the old 4.1 seems more reliable than the current system in a number of respects.  I have a new project with a hard deadline that I would like to use the new cm3 system for, but until these problems (pixmaps, buildstandalone, environ vars, serial i/o, etc.) can be resolved, I'm going to keep using 4.1 for my production work.
 
Regards,
Randy>>> Jay  5/8/2008 2:46 PM >>>http://modula3.elegosoft.com/cm3/uploaded-archives/ http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0.ziphttp://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-WIN32-NT386-d5.7.0.ziphttp://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0-symbols.zip These should have:  latest quake extensions   set relation fixes   other set fixes revealed through dynamic linking of one regression test   hypothetical ability to cross-build to AMD64_LINUX, AMD64_DARWIN    one jmpbuf size for all NT386 configurations (NT386, NT386GNU, NT386MINGNU)  Built with Visual C++ 9.0 Express, so you'll want:http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en  Still more work to do though, e.g. assertion failures in unit tests, pixmap.. Fuller disclosure:Something is leaking memory on my system such that "everything" starts "failing" and I have to reboot.This isn't Modula-3 related.Hopefully these files aren't damaged as a result.Must be some buggy driver or something.. Aside: The environment variable thingy has been bugging me a long time and I finally looked deeper at it.It appears broken in CM3 4.x. I didn't check 3.x yet.I'm still mulling a fix, and haven't run a repro of the break, but it's not a big deal either way.Basically console apps use main that takes char** and gui apps use WinMain that doesn't get environment variables but the generated code calls GetEvironmentStrings() which returns null separated strings.Must be that hardly anyone uses environment variables in Modula-3 on Win32 for this to have lingered so long, at least gui apps.  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Thu May  8 23:53:26 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Thu, 08 May 2008 17:53:26 -0400
Subject: [M3devel] new NT386 snapshots
In-Reply-To: 
References: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
	
	<4823279D.1E75.00D7.1@scires.com>
	
Message-ID: <48233E12.1E75.00D7.1@scires.com>

Jay:
 
I have a working serial-I/O module for Windows and one for HPUX, so maybe I should compare it to what is out there now and make some fixes.
 
Regards,
Randy

>>> Jay  5/8/2008 5:18 PM >>>
The code in 4.1 in clearly, by inspection, incorrect. I'll have to test it out and debug it though. Inspection isn't enough.
I have no idea why my mail gets truncated. I agree it is annoying.
 
F:\products\modula3\CONTRIB\SRC-M3\m3\m3core\src\runtime\WIN32\RTArgs.m3(7):(* In Windows/NT, "envp" points at a null-terminated block of
F:\products\modula3\CONTRIB\SRC-M3\m3\m3core\src\runtime\WIN32\RTArgs.m3(144):    envp : Ctypes.char_star := RTLinker.info.envp;


f:\products\modula3\CONTRIB\SRC-M3\m3\m3linker\src\MxGen.m3(117):    Out (s, "  _ADDRESS envp;", s.eol);
f:\products\modula3\CONTRIB\SRC-M3\m3\m3linker\src\MxGen.m3(480):    Out (s, "  /* envp       */ 0,", s.eol);
f:\products\modula3\CONTRIB\SRC-M3\m3\m3linker\src\MxGen.m3(498):      Out (s, "    _m3_link_info.envp = (_ADDRESS)GetEnvironmentStrings();", s.eol);
f:\products\modula3\CONTRIB\SRC-M3\m3\m3linker\src\MxGen.m3(501):      Out (s, "int main (argc, argv, envp)", s.eol);
f:\products\modula3\CONTRIB\SRC-M3\m3\m3linker\src\MxGen.m3(504):      Out (s, "char **envp;", s.eol);
f:\products\modula3\CONTRIB\SRC-M3\m3\m3linker\src\MxGen.m3(512):      Out (s, "    _m3_link_info.envp = (_ADDRESS)(envp);", s.eol);

 > serial i/o?
 
I haven't touched it, looked it really, or heard of any problems.
I looked at it for purposes of NT386GNU but didn't really do anything.
 
Pixmaps need debugging, indeed.
 
I found my 4.1 CD. :)
 
- Jay

Date: Thu, 8 May 2008 16:17:37 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com 
Subject: Re: [M3devel] new NT386 snapshots

Jay:
 
I have both console and gui programs built using 4.1 that do pull stuff out of the environment.  I've not noticed any problems with either mode.
 
>From my perspective, the old 4.1 seems more reliable than the current system in a number of respects.  I have a new project with a hard deadline that I would like to use the new cm3 system for, but until these problems (pixmaps, buildstandalone, environ vars, serial i/o, etc.) can be resolved, I'm going to keep using 4.1 for my production work.
 
Regards,
Randy

>>> Jay  5/8/2008 2:46 PM >>>
http://modula3.elegosoft.com/cm3/uploaded-archives/ 
 
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0.zip 
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-WIN32-NT386-d5.7.0.zip 
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0-symbols.zip 
 
These should have:
  latest quake extensions 
  set relation fixes 
  other set fixes revealed through dynamic linking of one regression test 
  hypothetical ability to cross-build to AMD64_LINUX, AMD64_DARWIN  
  one jmpbuf size for all NT386 configurations (NT386, NT386GNU, NT386MINGNU) 
 
Built with Visual C++ 9.0 Express, so you'll want:
http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en 
 
 
Still more work to do though, e.g. assertion failures in unit tests, pixmap..
 
Fuller disclosure:
Something is leaking memory on my system such that "everything" starts "failing" and I have to reboot.
This isn't Modula-3 related.
Hopefully these files aren't damaged as a result.
Must be some buggy driver or something..
 
Aside:
 The environment variable thingy has been bugging me a long time and I finally looked deeper at it.
It appears broken in CM3 4.x. I didn't check 3.x yet.
I'm still mulling a fix, and haven't run a repro of the break, but it's not a big deal either way.
Basically console apps use main that takes char** and gui apps use WinMain that doesn't get environment variables but the generated code calls GetEvironmentStrings() which returns null separated strings.
Must be that hardly anyone uses environment variables in Modula-3 on Win32 for this to have lingered so long, at least gui apps.
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Fri May  9 07:43:08 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 9 May 2008 05:43:08 +0000
Subject: [M3devel] consoles appearing in gui apps (was pixmap...)
In-Reply-To: <481F9804.1E75.00D7.1@scires.com>
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	 
	<481F9804.1E75.00D7.1@scires.com>   
Message-ID: 

  > The bad news is that now I am getting a command window
  > opening up in addition to the GUI window when the program runs. 
  > This behavior does not occur on v4.1.  
 
Randy I've experimented with -gui. Just a few minutes, but I've covered all of the ground I can think of, except I only used -gui and not an m3makefile.
>From what I see, it all works as it should.
 
Here is my little program:
 
C:\dev2\j\m3\3>type Main.m3MODULE Main;IMPORT IO;IMPORT WinBase;
BEGIN  (* IO.Put("Hello\n"); *)  WinBase.Sleep(10000); (* 10 seconds *)
IF I uncomment out the IO.Put, and use -gui, then there is a "popup", and hello is printed there.
If I don't have the IO.Put however, no popup.
 
Is anything appearing in your console window? Or it is just empty?
Are you maybe running processes from your app? Or running them from Explorer?
I am running just one Modula-3 test app, from cmd.
 
It is possible that 4.1 does not bring up a console if you use stdout/stderr?
There is specific code in the current code to do this.
I don't have 4.1 handy..ok, I have 3.6.
 
This appears to have been a deliberate change.
 
 3.6
C:\net\modula3\m3\libm3\src\os\WIN32\ProcessWin32.m3(185):PROCEDURE GetFileHandle(hd: WinDef.DWORD; ds: FileWin32.DirectionSet): File.T =
PROCEDURE GetFileHandle(hd: WinDef.DWORD; ds: FileWin32.DirectionSet): File.T =  VAR h := WinBase.GetStdHandle(hd);  BEGIN    IF (h = NIL)      OR (h = LOOPHOLE (WinBase.INVALID_HANDLE_VALUE, WinDef.HANDLE)) THEN      RETURN NIL;    END;    TRY RETURN FileWin32.New(h, ds)    EXCEPT OSError.E => (* not available *)    END;    RETURN NIL;  END GetFileHandle;
 
vs.
 
current
 
C:\dev2\cm3\m3-libs\libm3\src\os\WIN32\ProcessWin32.m3(231):PROCEDURE GetFileHandle(hd: WinDef.DWORD; ds: FileWin32.DirectionSet): File.T =
PROCEDURE GetFileHandle(hd: WinDef.DWORD; ds: FileWin32.DirectionSet): File.T =  VAR h := WinBase.GetStdHandle(hd);  BEGIN    IF (h # NIL)      AND (h # LOOPHOLE (WinBase.INVALID_HANDLE_VALUE, WinDef.HANDLE)) THEN      TRY RETURN FileWin32.New(h, ds)      EXCEPT OSError.E => (* not available *)      END;    END;    (* if we can't get the standard handles, we might be a GUI program       so we'll lazily allocate a console if needed. *)    RETURN LazyConsole.New (hd, ds);  END GetFileHandle;
 
 
Ok, this change came in in the upgrade from Critical Mass 4.1 to 5.1.
4.1 being as I understand the actual one and only commercial release.
5.1 I guess being the then current but unreleated Critical Mass tree.
 
http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/WIN32/ProcessWin32.m3.diff?r1=1.1.1.1;r2=1.1.1.2;f=u
 
Please advise.
 
Also, to double check that things are working, run link -dump -headers foo.exe | findstr /i "subsystem entry"
 
GUI apps should show:
 
C:\dev2\j\m3\3>link -dump -headers NT386\prog.exe | findstr /i "subsystem entry"
            1C60 entry point (00401C60) _WinMainCRTStartup               2 subsystem (Windows GUI)
 
console apps should show:
 
C:\dev2\j\m3\3>link -dump -headers NT386\prog.exe | findstr /i "subsystem entry"
            1BE1 entry point (00401BE1) _mainCRTStartup               3 subsystem (Windows CUI)
C for console/commandline, G for gui/graphical.
 
If that is not what you are seeing, let's delve into that.
If my test program always brings up a popup, when compiled with -gui, with the IO.Put commented out, let's delve into that.
If your console is empty, let's look into that.
If you console has output in it, well, I'm inclined to say you are seeing improved correct behavior, but we can debate it, I guess.
 
 - Jay


From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: FW: [M3devel] pixmap problemDate: Thu, 8 May 2008 19:21:49 +0000


truncated again...


From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problemDate: Thu, 8 May 2008 18:57:08 +0000

Randy, At first very quick glance, this stuff looks ok.CM3-IDE probably doesn't really understand the config file, similar to m3cgcat's partial misunderstanding.  (Which is why I keep TARGET declared in NT386* instead of just NT386.common.)PKG_USE is defined I think, but it takes a really accurate understanding of Quake to get it. The entry/subsystem stuff also seems complete but I didn't try examples yet.Sorry, didn't give this all much time yet.I did get me to look at the environment variable bug that's been sitting there forever, with a bogus fix.. Can CM3-IDE default PKG_USE to CM3_ROOT + "/pkg"? Or INSTALL_ROOT + "/pkg"? Or whatever?That is what it always is, in anything that is checked in or that cminstall will give you.It takes hand editing of cm3.cfg to get anything else I think. Or CM3-IDE users can just edit the file some. Not a lot. But some.Given an incomplete understanding of the config files, probably putting in CM3-IDE wants but under if FALSE will perhaps work.Personally I wasn't impressed with Reactor... VC5 find-in-files gets me all I need. Anything besides plain text search doesn't scale..  - Jay


From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problemDate: Tue, 6 May 2008 03:38:03 +0000

Randy, don't worry.Two of these problems are trivial to fix -- PKG_USE and popups.The pixmap one will need debugging.  - Jay


Date: Mon, 5 May 2008 23:28:10 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad news is that now I am getting a command window opening up in addition to the GUI window when the program runs.  This behavior does not occur on v4.1.  The command window seems to be the stdout/stderr of the GUI program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy>>> Jay  5/5/2008 10:47 PM >>>Randy, Yes.The NT386 config files are all checked in.You can use them verbatim. You don't need cminstall, I never use it, and you shouldn't need to edit the config files at all, any edits I make, I check in, and should be usable on all machines.As long as you set %PATH%/%INCLUDE%/%LIB%.If I'm wrong, I'd like to know why and try to fix. Consider the config files just part of cm3.exe.Not generally to be changed locally. Unless, well, unless you intend to, and you should strive to make one form that is usable by all.  - Jay


Date: Mon, 5 May 2008 22:42:30 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay,
When you say "took the updated config file", what do you mean?  Are you saying I need a different cm3.cfg file?
Regards,
Randy>>> Jay  5/5/2008 9:54 PM >>>And you took the updated config file?The way you can tell is that, roughly speaking, hand.obj should be in NT386\_m3responsefile0.txt.Or _m3responsefile1.txt, or, well, somewhere.Anyway, I think I saw the attachment, I can check later..and with 4.1 as I said.. I can see about making the fix not depend on config file changes...but it's not terrible asis, and I'd really like to merge more of the quake code into cm3.exe..  - Jay


Date: Mon, 5 May 2008 21:18:12 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem
Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly when the buildstandalone() directive is used.
 
Regards,
Randy>>> Jay  5/5/2008 7:04 PM >>>Thanks. I'll look into this tonight probably, as well as with 4.1 assuming I can find my binaries and source for it (probably).COULD BE the pixmap problem is something else and 4.1 also has the problem I fixed. We'll see. No need to speculate (unless I can't find my 4.1). - Jay


Date: Mon, 5 May 2008 10:59:27 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problem
Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy>>> Jay  5/4/2008 11:46 AM >>>Randy, Please try with /current/ source, as of this morning Sunday May 4 -- the changes are ALL in NT386.common, so you MUST use MY config files, which are checked in verbatim, or you should be able edit whatever config files you are using. (It's not really a config file issue, don't blame the general confusion people have with them.) I'll try to try later, but I don't have the source right now, gotta look on other machines, and I think it's on a machine on loan.  Or send it to me again.I'd also like to know if this worked with 4.1, or with any release that offered dynamic linking to m3core.dll, on Windows.  I recall a claim that it did. If today's change fixes it, I should be able to investigate 4.1.3.6 did not have such linking.If today's change does not help, well, I still plan on debugging it at some point.. If you aren't current and getting so is difficult, just send the attachment again, it's easy for me to test. Thanks, - Jay


From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rcoleburn at scires.comDate: Sat, 19 Jan 2008 08:52:08 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.I was going to try on PPC_DARWIN but I guess Tony's info suffices. I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. Debugging here is a big humungous pain.NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)And bundles look pretty simple, a bundle is just a generated source file with a constant in it.Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something. The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for? I have to say this is very surprising. I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so.The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: pointer to msvcrt!fopenpointer to msvcrt!fclosenullpointer to kernel32!Sleep But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo.But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo.That doesn't work for data though. There's no ability to intervenve like that.So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it.And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.However that would suck perf in order to make an uncommon case work.I hope Modula-3 doesn't do that either. :)Though I guess since this global data in question...maybe it is rare??? Later, - Jay

> From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 03:09:47 -0500> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] pixmap problem> > Looks fine to me on I386_DARWIN.> > On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:> > > > 

Need to know the score, the latest news, or you need your Hotmail?-get your "fix" Check it out. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Fri May  9 09:44:09 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 9 May 2008 07:44:09 +0000
Subject: [M3devel] NT386 environment variables (new NT386 snapshots)
In-Reply-To: <4823279D.1E75.00D7.1@scires.com>
References: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
	 
	<4823279D.1E75.00D7.1@scires.com>
Message-ID: 

 > these problems (pixmaps, buildstandalone, environ vars, serial i/o, etc...
 
 Ok, here is the story with environment variables.
I tested 3.6 and current, gui and console.
This is the program:
C:\dev2\j\m3\3>type src\m3makefile
import ("m3core")import ("libm3")m3_option ("-gui")     twiddle this line in and out with a commentimplementation ("Main")program ("pgm")
 
C:\dev2\j\m3\3>type src\Main.m3
MODULE Main;IMPORT IO;IMPORT RTArgs;
 
BEGIN
(* IO.Put just crashes in 3.6 gui apps *)  IO.Put(RTArgs.GetArg(2));  IO.Put(RTArgs.GetEnv(2));
 
(* use this for gui apps *)  EVAL RTArgs.GetArg(2);  EVAL RTArgs.GetEnv(2);END Main.
In 3.6 console apps, RTArgs.GetEnv returns garbage. That makes sense from the code.
In current console apps, GetEnv works.In current gui apps, GetEnv access violates, or returns an invalid pointer.  This also makes sense from the code.
Randy, does this actually work for you?I'd be quite surprised.I haven't tried 4.1 yet, just 3.6 and current.
I will apply an easy fix.
 - Jay


Date: Thu, 8 May 2008 16:17:37 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] new NT386 snapshots

Jay:
 
I have both console and gui programs built using 4.1 that do pull stuff out of the environment.  I've not noticed any problems with either mode.
 
>From my perspective, the old 4.1 seems more reliable than the current system in a number of respects.  I have a new project with a hard deadline that I would like to use the new cm3 system for, but until these problems (pixmaps, buildstandalone, environ vars, serial i/o, etc.) can be resolved, I'm going to keep using 4.1 for my production work.
 
Regards,
Randy>>> Jay  5/8/2008 2:46 PM >>>http://modula3.elegosoft.com/cm3/uploaded-archives/ http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0.ziphttp://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-WIN32-NT386-d5.7.0.ziphttp://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0-symbols.zip These should have:  latest quake extensions   set relation fixes   other set fixes revealed through dynamic linking of one regression test   hypothetical ability to cross-build to AMD64_LINUX, AMD64_DARWIN    one jmpbuf size for all NT386 configurations (NT386, NT386GNU, NT386MINGNU)  Built with Visual C++ 9.0 Express, so you'll want:http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en  Still more work to do though, e.g. assertion failures in unit tests, pixmap.. Fuller disclosure:Something is leaking memory on my system such that "everything" starts "failing" and I have to reboot.This isn't Modula-3 related.Hopefully these files aren't damaged as a result.Must be some buggy driver or something.. Aside: The environment variable thingy has been bugging me a long time and I finally looked deeper at it.It appears broken in CM3 4.x. I didn't check 3.x yet.I'm still mulling a fix, and haven't run a repro of the break, but it's not a big deal either way.Basically console apps use main that takes char** and gui apps use WinMain that doesn't get environment variables but the generated code calls GetEvironmentStrings() which returns null separated strings.Must be that hardly anyone uses environment variables in Modula-3 on Win32 for this to have lingered so long, at least gui apps.  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Fri May  9 10:19:33 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 9 May 2008 08:19:33 +0000
Subject: [M3devel] FW:  NT386 environment variables (new NT386 snapshots)
In-Reply-To: <4823279D.1E75.00D7.1@scires.com>
References: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
	 
	<4823279D.1E75.00D7.1@scires.com> 
Message-ID: 

truncated again...
m3support -- nothing interesting in any logs regarding my mail?
And nobody else uses hotmail, right?
 
> I will apply an easy fix.
done


From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] NT386 environment variables (new NT386 snapshots)Date: Fri, 9 May 2008 07:44:09 +0000


 > these problems (pixmaps, buildstandalone, environ vars, serial i/o, etc...  Ok, here is the story with environment variables.I tested 3.6 and current, gui and console.This is the program:C:\dev2\j\m3\3>type src\m3makefileimport ("m3core")import ("libm3")m3_option ("-gui")     twiddle this line in and out with a commentimplementation ("Main")program ("pgm") C:\dev2\j\m3\3>type src\Main.m3MODULE Main;IMPORT IO;IMPORT RTArgs; BEGIN(* IO.Put just crashes in 3.6 gui apps *)  IO.Put(RTArgs.GetArg(2));  IO.Put(RTArgs.GetEnv(2)); (* use this for gui apps *)  EVAL RTArgs.GetArg(2);  EVAL RTArgs.GetEnv(2);END Main.In 3.6 console apps, RTArgs.GetEnv returns garbage. That makes sense from the code.In current console apps, GetEnv works.In current gui apps, GetEnv access violates, or returns an invalid pointer.  This also makes sense from the code.Randy, does this actually work for you?I'd be quite surprised.I haven't tried 4.1 yet, just 3.6 and current.I will apply an easy fix. - Jay


Date: Thu, 8 May 2008 16:17:37 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] new NT386 snapshots
Jay:
 
I have both console and gui programs built using 4.1 that do pull stuff out of the environment.  I've not noticed any problems with either mode.
 
>From my perspective, the old 4.1 seems more reliable than the current system in a number of respects.  I have a new project with a hard deadline that I would like to use the new cm3 system for, but until these problems (pixmaps, buildstandalone, environ vars, serial i/o, etc.) can be resolved, I'm going to keep using 4.1 for my production work.
 
Regards,
Randy>>> Jay  5/8/2008 2:46 PM >>>http://modula3.elegosoft.com/cm3/uploaded-archives/ http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0.ziphttp://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-WIN32-NT386-d5.7.0.ziphttp://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0-symbols.zip These should have:  latest quake extensions   set relation fixes   other set fixes revealed through dynamic linking of one regression test   hypothetical ability to cross-build to AMD64_LINUX, AMD64_DARWIN    one jmpbuf size for all NT386 configurations (NT386, NT386GNU, NT386MINGNU)  Built with Visual C++ 9.0 Express, so you'll want:http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en  Still more work to do though, e.g. assertion failures in unit tests, pixmap.. Fuller disclosure:Something is leaking memory on my system such that "everything" starts "failing" and I have to reboot.This isn't Modula-3 related.Hopefully these files aren't damaged as a result.Must be some buggy driver or something.. Aside: The environment variable thingy has been bugging me a long time and I finally looked deeper at it.It appears broken in CM3 4.x. I didn't check 3.x yet.I'm still mulling a fix, and haven't run a repro of the break, but it's not a big deal either way.Basically console apps use main that takes char** and gui apps use WinMain that doesn't get environment variables but the generated code calls GetEvironmentStrings() which returns null separated strings.Must be that hardly anyone uses environment variables in Modula-3 on Win32 for this to have lingered so long, at least gui apps.  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Fri May  9 11:10:36 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 9 May 2008 09:10:36 +0000
Subject: [M3devel] pixmap problem
In-Reply-To: <481F9804.1E75.00D7.1@scires.com>
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	 
	<481F9804.1E75.00D7.1@scires.com>
Message-ID: 

 > Also, more bad news, the pixmap problem is not solved.
 
Randy, this DOES actually fix it, but you have to rebuild more.
 
Try:
   cd scripts\python  
  .\do-cm3-std.py realclean  
  .\upgrade.py   (probably not needed) 
   do-cm3-std.py buildship  
 
Make sure "hand.obj" occurs in the various NT386\foo.lst files.
 
I think the fix should be restated to have the code reference *__imp__highbits instead of highbits, and go back to dynamic linking the data.
But ok for now.
 
The std distribution I put yesterday should work, though it is missing the RTArgs fix.
I'll see about making another.
 
  - Jay


Date: Mon, 5 May 2008 23:28:10 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem

Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad news is that now I am getting a command window opening up in addition to the GUI window when the program runs.  This behavior does not occur on v4.1.  The command window seems to be the stdout/stderr of the GUI program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy>>> Jay  5/5/2008 10:47 PM >>>Randy, Yes.The NT386 config files are all checked in.You can use them verbatim. You don't need cminstall, I never use it, and you shouldn't need to edit the config files at all, any edits I make, I check in, and should be usable on all machines.As long as you set %PATH%/%INCLUDE%/%LIB%.If I'm wrong, I'd like to know why and try to fix. Consider the config files just part of cm3.exe.Not generally to be changed locally. Unless, well, unless you intend to, and you should strive to make one form that is usable by all.  - Jay


Date: Mon, 5 May 2008 22:42:30 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay,
When you say "took the updated config file", what do you mean?  Are you saying I need a different cm3.cfg file?
Regards,
Randy>>> Jay  5/5/2008 9:54 PM >>>And you took the updated config file?The way you can tell is that, roughly speaking, hand.obj should be in NT386\_m3responsefile0.txt.Or _m3responsefile1.txt, or, well, somewhere.Anyway, I think I saw the attachment, I can check later..and with 4.1 as I said.. I can see about making the fix not depend on config file changes...but it's not terrible asis, and I'd really like to merge more of the quake code into cm3.exe..  - Jay


Date: Mon, 5 May 2008 21:18:12 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem
Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly when the buildstandalone() directive is used.
 
Regards,
Randy>>> Jay  5/5/2008 7:04 PM >>>Thanks. I'll look into this tonight probably, as well as with 4.1 assuming I can find my binaries and source for it (probably).COULD BE the pixmap problem is something else and 4.1 also has the problem I fixed. We'll see. No need to speculate (unless I can't find my 4.1). - Jay


Date: Mon, 5 May 2008 10:59:27 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problem
Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy>>> Jay  5/4/2008 11:46 AM >>>Randy, Please try with /current/ source, as of this morning Sunday May 4 -- the changes are ALL in NT386.common, so you MUST use MY config files, which are checked in verbatim, or you should be able edit whatever config files you are using. (It's not really a config file issue, don't blame the general confusion people have with them.) I'll try to try later, but I don't have the source right now, gotta look on other machines, and I think it's on a machine on loan.  Or send it to me again.I'd also like to know if this worked with 4.1, or with any release that offered dynamic linking to m3core.dll, on Windows.  I recall a claim that it did. If today's change fixes it, I should be able to investigate 4.1.3.6 did not have such linking.If today's change does not help, well, I still plan on debugging it at some point.. If you aren't current and getting so is difficult, just send the attachment again, it's easy for me to test. Thanks, - Jay


From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rcoleburn at scires.comDate: Sat, 19 Jan 2008 08:52:08 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.I was going to try on PPC_DARWIN but I guess Tony's info suffices. I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. Debugging here is a big humungous pain.NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)And bundles look pretty simple, a bundle is just a generated source file with a constant in it.Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something. The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for? I have to say this is very surprising. I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so.The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: pointer to msvcrt!fopenpointer to msvcrt!fclosenullpointer to kernel32!Sleep But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo.But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo.That doesn't work for data though. There's no ability to intervenve like that.So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it.And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.However that would suck perf in order to make an uncommon case work.I hope Modula-3 doesn't do that either. :)Though I guess since this global data in question...maybe it is rare??? Later, - Jay

> From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 03:09:47 -0500> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] pixmap problem> > Looks fine to me on I386_DARWIN.> > On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:> > > > 

Need to know the score, the latest news, or you need your Hotmail?-get your "fix" Check it out. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Sat May 10 10:31:04 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Sat, 10 May 2008 04:31:04 -0400
Subject: [M3devel] consoles appearing in gui apps (was pixmap...)
In-Reply-To: 
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	
	<481F9804.1E75.00D7.1@scires.com> <481F9804.1E75.00D7.1@scires.com>
	
Message-ID: <48252503.1E75.00D7.1@scires.com>

Jay:
 
Here are my results using your test program.  In all cases I have
created a desktop shortcut to the EXE and double-click this shortcut to
start the program:
 
1.  cm3 v4.1, VS 2005, with IO.Put commented out, no pop-up.
 
2.  cm3 v4.1, VS 2005, using IO.Put, I have to put "@M3novm" on command
line, but then get a pop-up showing a crash "runtime error, illegal
memory access, LockMutexx in ThreadWin32.m3"
 
3.  cm3 v.d5.7.0, VS 2008, with IO.Put commented out, no pop-up
 
4.  cm3 v.d5.7.0, VS 2008, using IO.Put, I get a pop-up window with the
word "Hello".
 
Also, I checked the "link dump" for GUI vs. CUI on both versions and it
appears to be working correctly.
 
Regards,
Randy

>>> Jay  5/9/2008 1:43 AM >>>
  > The bad news is that now I am getting a command window
  > opening up in addition to the GUI window when the program runs. 
  > This behavior does not occur on v4.1.  
 
Randy I've experimented with -gui. Just a few minutes, but I've covered
all of the ground I can think of, except I only used -gui and not an
m3makefile.
>From what I see, it all works as it should.
 
Here is my little program:
 
C:\dev2\j\m3\3>type Main.m3
MODULE Main;
IMPORT IO;
IMPORT WinBase;
BEGIN
  (* IO.Put("Hello\n"); *)
  WinBase.Sleep(10000); (* 10 seconds *)


IF I uncomment out the IO.Put, and use -gui, then there is a "popup",
and hello is printed there.
If I don't have the IO.Put however, no popup.
 
Is anything appearing in your console window? Or it is just empty?
Are you maybe running processes from your app? Or running them from
Explorer?
I am running just one Modula-3 test app, from cmd.
 
It is possible that 4.1 does not bring up a console if you use
stdout/stderr?
There is specific code in the current code to do this.
I don't have 4.1 handy..ok, I have 3.6.
 
This appears to have been a deliberate change.
 
 3.6
C:\net\modula3\m3\libm3\src\os\WIN32\ProcessWin32.m3(185):PROCEDURE
GetFileHandle(hd: WinDef.DWORD; ds: FileWin32.DirectionSet): File.T =

PROCEDURE GetFileHandle(hd: WinDef.DWORD; ds: FileWin32.DirectionSet):
File.T =
  VAR h := WinBase.GetStdHandle(hd);
  BEGIN
    IF (h = NIL)
      OR (h = LOOPHOLE (WinBase.INVALID_HANDLE_VALUE, WinDef.HANDLE))
THEN
      RETURN NIL;
    END;
    TRY RETURN FileWin32.New(h, ds)
    EXCEPT OSError.E => (* not available *)
    END;
    RETURN NIL;
  END GetFileHandle;

 
vs.
 
current
 
C:\dev2\cm3\m3-libs\libm3\src\os\WIN32\ProcessWin32.m3(231):PROCEDURE
GetFileHandle(hd: WinDef.DWORD; ds: FileWin32.DirectionSet): File.T =

PROCEDURE GetFileHandle(hd: WinDef.DWORD; ds: FileWin32.DirectionSet):
File.T =
  VAR h := WinBase.GetStdHandle(hd);
  BEGIN
    IF (h # NIL)
      AND (h # LOOPHOLE (WinBase.INVALID_HANDLE_VALUE, WinDef.HANDLE))
THEN
      TRY RETURN FileWin32.New(h, ds)
      EXCEPT OSError.E => (* not available *)
      END;
    END;
    (* if we can't get the standard handles, we might be a GUI program
       so we'll lazily allocate a console if needed. *)
    RETURN LazyConsole.New (hd, ds);
  END GetFileHandle;
 
 
Ok, this change came in in the upgrade from Critical Mass 4.1 to 5.1.
4.1 being as I understand the actual one and only commercial release.
5.1 I guess being the then current but unreleated Critical Mass tree.
 
http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/WIN32/ProcessWin32.m3.diff?r1=1.1.1.1;r2=1.1.1.2;f=u

 
Please advise.
 
Also, to double check that things are working, run link -dump -headers
foo.exe | findstr /i "subsystem entry"
 
GUI apps should show:
 

C:\dev2\j\m3\3>link -dump -headers NT386\prog.exe | findstr /i
"subsystem entry"
            1C60 entry point (00401C60) _WinMainCRTStartup
               2 subsystem (Windows GUI)
 
console apps should show:
 
C:\dev2\j\m3\3>link -dump -headers NT386\prog.exe | findstr /i
"subsystem entry"
            1BE1 entry point (00401BE1) _mainCRTStartup
               3 subsystem (Windows CUI)

C for console/commandline, G for gui/graphical.
 
If that is not what you are seeing, let's delve into that.
If my test program always brings up a popup, when compiled with -gui,
with the IO.Put commented out, let's delve into that.
If your console is empty, let's look into that.
If you console has output in it, well, I'm inclined to say you are
seeing improved correct behavior, but we can debate it, I guess.
 
 - Jay

From: jayk123 at hotmail.com 
To: rcoleburn at scires.com; m3devel at elegosoft.com 
Subject: FW: [M3devel] pixmap problem
Date: Thu, 8 May 2008 19:21:49 +0000

truncated again...




From: jayk123 at hotmail.com 
To: rcoleburn at scires.com; m3devel at elegosoft.com 
Subject: RE: [M3devel] pixmap problem
Date: Thu, 8 May 2008 18:57:08 +0000

Randy, At first very quick glance, this stuff looks ok.
CM3-IDE probably doesn't really understand the config file, similar to
m3cgcat's partial misunderstanding.
  (Which is why I keep TARGET declared in NT386* instead of just
NT386.common.)
PKG_USE is defined I think, but it takes a really accurate
understanding of Quake to get it.
 
The entry/subsystem stuff also seems complete but I didn't try examples
yet.
Sorry, didn't give this all much time yet.
I did get me to look at the environment variable bug that's been
sitting there forever, with a bogus fix..
 
Can CM3-IDE default PKG_USE to CM3_ROOT + "/pkg"? Or INSTALL_ROOT +
"/pkg"? Or whatever?
That is what it always is, in anything that is checked in or that
cminstall will give you.
It takes hand editing of cm3.cfg to get anything else I think.
 
Or CM3-IDE users can just edit the file some. Not a lot. But some.
Given an incomplete understanding of the config files, probably putting
in CM3-IDE wants but under if FALSE will perhaps work.
Personally I wasn't impressed with Reactor... VC5 find-in-files gets me
all I need. Anything besides plain text search doesn't scale..
 
 - Jay
From: jayk123 at hotmail.com 
To: rcoleburn at scires.com; m3devel at elegosoft.com 
Subject: RE: [M3devel] pixmap problem
Date: Tue, 6 May 2008 03:38:03 +0000

Randy, don't worry.
Two of these problems are trivial to fix -- PKG_USE and popups.
The pixmap one will need debugging.
 
 - Jay

Date: Mon, 5 May 2008 23:28:10 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com; jayk123 at hotmail.com 
Subject: RE: [M3devel] pixmap problem

Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've
copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad
news is that now I am getting a command window opening up in addition to
the GUI window when the program runs.  This behavior does not occur on
v4.1.  The command window seems to be the stdout/stderr of the GUI
program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which
needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy

>>> Jay  5/5/2008 10:47 PM >>>
Randy, Yes.
The NT386 config files are all checked in.
You can use them verbatim. You don't need cminstall, I never use it,
and you shouldn't need to edit the config files at all, any edits I
make, I check in, and should be usable on all machines.
As long as you set %PATH%/%INCLUDE%/%LIB%.
If I'm wrong, I'd like to know why and try to fix.
 
Consider the config files just part of cm3.exe.
Not generally to be changed locally. Unless, well, unless you intend
to, and you should strive to make one form that is usable by all.
 
 - Jay


Date: Mon, 5 May 2008 22:42:30 -0400
From: rcoleburn at scires.com 
To: jayk123 at hotmail.com 
Subject: RE: [M3devel] pixmap problem

Jay,
When you say "took the updated config file", what do you mean?  Are you
saying I need a different cm3.cfg file?
Regards,
Randy

>>> Jay  5/5/2008 9:54 PM >>>
And you took the updated config file?
The way you can tell is that, roughly speaking, hand.obj should be in
NT386\_m3responsefile0.txt.
Or _m3responsefile1.txt, or, well, somewhere.
Anyway, I think I saw the attachment, I can check later..and with 4.1
as I said..
 
I can see about making the fix not depend on config file changes...but
it's not terrible asis, and I'd really like to merge more of the quake
code into cm3.exe..
 
 - Jay

Date: Mon, 5 May 2008 21:18:12 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com 
Subject: Re: [M3devel] pixmap problem

Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly
when the buildstandalone() directive is used.
 
Regards,
Randy

>>> Jay  5/5/2008 7:04 PM >>>
Thanks. I'll look into this tonight probably, as well as with 4.1
assuming I can find my binaries and source for it (probably).

COULD BE the pixmap problem is something else and 4.1 also has the
problem I fixed. We'll see. No need to speculate (unless I can't find my
4.1).

 - Jay


Date: Mon, 5 May 2008 10:59:27 -0400
From: rcoleburn at scires.com 
To: jayk123 at hotmail.com 
CC: m3devel at elegosoft.com 
Subject: RE: [M3devel] pixmap problem

Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files
or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy

>>> Jay  5/4/2008 11:46 AM >>>
Randy, Please try with /current/ source, as of this morning Sunday May
4 -- the changes are ALL in NT386.common, so you MUST use MY config
files, which are checked in verbatim, or you should be able edit
whatever config files you are using.
 
(It's not really a config file issue, don't blame the general confusion
people have with them.)
 
I'll try to try later, but I don't have the source right now, gotta
look on other machines, and I think it's on a machine on loan.
  Or send it to me again.
I'd also like to know if this worked with 4.1, or with any release that
offered dynamic linking to m3core.dll, on Windows.
  I recall a claim that it did. If today's change fixes it, I should be
able to investigate 4.1.
3.6 did not have such linking.
If today's change does not help, well, I still plan on debugging it at
some point..
 
If you aren't current and getting so is difficult, just send the
attachment again, it's easy for me to test.
 
Thanks,
 - Jay

From: jayk123 at hotmail.com 
To: hosking at cs.purdue.edu; rcoleburn at scires.com 
Date: Sat, 19 Jan 2008 08:52:08 +0000
CC: m3devel at elegosoft.com 
Subject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.
I was going to try on PPC_DARWIN but I guess Tony's info suffices.
 
I tried rolling hand.c back to before I changed (months/year ago),
since it is involved in bit twiddling, no change, phew.
 
Debugging here is a big humungous pain.
NT386 has good stacks and line numbers, but no locals or type info, I'd
really sometime like to get Codeview info into those .objs...I think it
is documented well enough, but still not necessarily easy, or maybe have
a C generating backend partly for this reason (and to bring up more
targets, using native tools), and function calls in disassembly I think
don't resolve; NT386GNU can't yet build this, though it will soon, but
I'm not familiar with gdb and there appears to be no type info. I'm
building m3gdb right now, I don't know if it will work, I hope it has
type info, and I'm not familiar with the relevant code. In gdb I
struggle just to view bytes in memory, add numbers to addresses and see
those, etc. I think for MY problem, I'm going to link in C code to dump
the structs. There is tracing code and I enabled it, but even it crashes
in Text_Length. At least MY problem crashes, hopefully near the problem,
whereas your problem goes all the way through to completion with no
stopping to hint where the problem is. Darn it. :) on the mock rudeness
and :( on the lack of a crash.
 
You write the bundle out and it matches, so that doesn't rule out
bundles as being the problem? (darn)
And bundles look pretty simple, a bundle is just a generated source
file with a constant in it.
Maybe newline problems? That wouldn't make sense. I just downloaded
some program that might let me separately view the ppm, maybe it'll
reveal something.
 
The bad behavior has like regularly spaced solid color veritical bars a
few pixels side across the whole picture, and regularly spaced vertical
stripes from the correct picture alternating with that. Perhaps someone
with ppm/bitmap/graphics experience has seen this behavior and it
results from some common pixmap mismanagement we could look for?
 
I have to say this is very surprising.
 
I always wondered, and now I pretty much assume -- Modula-3 never
imports/exports data in its dynamic linking, right? It alway
imports/exports functions, right?
On Windows, functions have an optional optimization, but data must be
handled differently at compile time if it is going to be dynamically
imported.
For functions, if you don't apply the optimization at compile time, the
linker will just generate a single instruction thunk instead.
 
That is, given a symbol Foo, there is a symbol __imp__Foo that is a
pointer to the actual foo in another .dll/.so.
The loader only patches pointers, one per import if you build your .dll
correctly, it doesn't patch instructions or code strewn throughout a
.dll, just one contiguous array of pointers. MAYBE they don't have to be
contiguous for each .dl you import from.
 
That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my
.dll/.exe typically has an array:
 
pointer to msvcrt!fopen
pointer to msvcrt!fclose
null
pointer to kernel32!Sleep
 
But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not
be adjacent.
 
So, going back, my point/question is that, if the compiler knows the
function is imported, it can call through __imp__Foo instead of calling
Foo.
But if it calls Foo and you import Foo, the linker will create the
function Foo that just jmps through __imp__Foo.
That doesn't work for data though. There's no ability to intervenve
like that.
So for imported data, the compiler must generated a read and
dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to
be imported.
Data imports may be faster when appropriate, but for this reason, I'd
say they aren't worth it.
And for this reason, I HOPE Modula-3 never imports/exports data.
 
Oh, you could, for data, always reference the pointer __imp_Foo, and if
non materializes, create one.
However that would suck perf in order to make an uncommon case work.
I hope Modula-3 doesn't do that either. :)
Though I guess since this global data in question...maybe it is
rare???
 
Later,
 - Jay



> From: hosking at cs.purdue.edu 
> Date: Sat, 19 Jan 2008 03:09:47 -0500
> To: rcoleburn at scires.com 
> CC: m3devel at elegosoft.com 
> Subject: Re: [M3devel] pixmap problem
> 
> Looks fine to me on I386_DARWIN.
> 
> On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:
> 
> > 
> 


Need to know the score, the latest news, or you need your Hotmail*-get
your "fix" Check it out. ( http://www.msnmobilefix.com/Default.aspx ) 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Sat May 10 10:51:23 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Sat, 10 May 2008 04:51:23 -0400
Subject: [M3devel] pixmap problem
In-Reply-To: 
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	
	<481F9804.1E75.00D7.1@scires.com><481F9804.1E75.00D7.1@scires.com>
	
Message-ID: <482529C7.1E75.00D7.1@scires.com>

Jay:
 
I do not have python installed on my computer, so I can't run your
scripts.
 
I used the scripts in scripts\win to upgrade a few days ago.
 
I am not seeing hand.obj in the .lst file.
 
I will do a CVS update and try the upgrade again followed by
do-cm3-standard.
 
Regards,
Randy

>>> Jay  5/9/2008 5:10 AM >>>
 > Also, more bad news, the pixmap problem is not solved.
 
Randy, this DOES actually fix it, but you have to rebuild more.
 
Try:
   cd scripts\python  
  .\do-cm3-std.py realclean  
  .\upgrade.py   (probably not needed) 
   do-cm3-std.py buildship  
 
Make sure "hand.obj" occurs in the various NT386\foo.lst files.
 
I think the fix should be restated to have the code reference
*__imp__highbits instead of highbits, and go back to dynamic linking the
data.
But ok for now.
 
The std distribution I put yesterday should work, though it is missing
the RTArgs fix.
I'll see about making another.
 
  - Jay

Date: Mon, 5 May 2008 23:28:10 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com; jayk123 at hotmail.com 
Subject: RE: [M3devel] pixmap problem

Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've
copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad
news is that now I am getting a command window opening up in addition to
the GUI window when the program runs.  This behavior does not occur on
v4.1.  The command window seems to be the stdout/stderr of the GUI
program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which
needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy

>>> Jay  5/5/2008 10:47 PM >>>
Randy, Yes.
The NT386 config files are all checked in.
You can use them verbatim. You don't need cminstall, I never use it,
and you shouldn't need to edit the config files at all, any edits I
make, I check in, and should be usable on all machines.
As long as you set %PATH%/%INCLUDE%/%LIB%.
If I'm wrong, I'd like to know why and try to fix.
 
Consider the config files just part of cm3.exe.
Not generally to be changed locally. Unless, well, unless you intend
to, and you should strive to make one form that is usable by all.
 
 - Jay


Date: Mon, 5 May 2008 22:42:30 -0400
From: rcoleburn at scires.com 
To: jayk123 at hotmail.com 
Subject: RE: [M3devel] pixmap problem

Jay,
When you say "took the updated config file", what do you mean?  Are you
saying I need a different cm3.cfg file?
Regards,
Randy

>>> Jay  5/5/2008 9:54 PM >>>
And you took the updated config file?
The way you can tell is that, roughly speaking, hand.obj should be in
NT386\_m3responsefile0.txt.
Or _m3responsefile1.txt, or, well, somewhere.
Anyway, I think I saw the attachment, I can check later..and with 4.1
as I said..
 
I can see about making the fix not depend on config file changes...but
it's not terrible asis, and I'd really like to merge more of the quake
code into cm3.exe..
 
 - Jay

Date: Mon, 5 May 2008 21:18:12 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com 
Subject: Re: [M3devel] pixmap problem

Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly
when the buildstandalone() directive is used.
 
Regards,
Randy

>>> Jay  5/5/2008 7:04 PM >>>
Thanks. I'll look into this tonight probably, as well as with 4.1
assuming I can find my binaries and source for it (probably).

COULD BE the pixmap problem is something else and 4.1 also has the
problem I fixed. We'll see. No need to speculate (unless I can't find my
4.1).

 - Jay


Date: Mon, 5 May 2008 10:59:27 -0400
From: rcoleburn at scires.com 
To: jayk123 at hotmail.com 
CC: m3devel at elegosoft.com 
Subject: RE: [M3devel] pixmap problem

Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files
or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy

>>> Jay  5/4/2008 11:46 AM >>>
Randy, Please try with /current/ source, as of this morning Sunday May
4 -- the changes are ALL in NT386.common, so you MUST use MY config
files, which are checked in verbatim, or you should be able edit
whatever config files you are using.
 
(It's not really a config file issue, don't blame the general confusion
people have with them.)
 
I'll try to try later, but I don't have the source right now, gotta
look on other machines, and I think it's on a machine on loan.
  Or send it to me again.
I'd also like to know if this worked with 4.1, or with any release that
offered dynamic linking to m3core.dll, on Windows.
  I recall a claim that it did. If today's change fixes it, I should be
able to investigate 4.1.
3.6 did not have such linking.
If today's change does not help, well, I still plan on debugging it at
some point..
 
If you aren't current and getting so is difficult, just send the
attachment again, it's easy for me to test.
 
Thanks,
 - Jay

From: jayk123 at hotmail.com 
To: hosking at cs.purdue.edu; rcoleburn at scires.com 
Date: Sat, 19 Jan 2008 08:52:08 +0000
CC: m3devel at elegosoft.com 
Subject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.
I was going to try on PPC_DARWIN but I guess Tony's info suffices.
 
I tried rolling hand.c back to before I changed (months/year ago),
since it is involved in bit twiddling, no change, phew.
 
Debugging here is a big humungous pain.
NT386 has good stacks and line numbers, but no locals or type info, I'd
really sometime like to get Codeview info into those .objs...I think it
is documented well enough, but still not necessarily easy, or maybe have
a C generating backend partly for this reason (and to bring up more
targets, using native tools), and function calls in disassembly I think
don't resolve; NT386GNU can't yet build this, though it will soon, but
I'm not familiar with gdb and there appears to be no type info. I'm
building m3gdb right now, I don't know if it will work, I hope it has
type info, and I'm not familiar with the relevant code. In gdb I
struggle just to view bytes in memory, add numbers to addresses and see
those, etc. I think for MY problem, I'm going to link in C code to dump
the structs. There is tracing code and I enabled it, but even it crashes
in Text_Length. At least MY problem crashes, hopefully near the problem,
whereas your problem goes all the way through to completion with no
stopping to hint where the problem is. Darn it. :) on the mock rudeness
and :( on the lack of a crash.
 
You write the bundle out and it matches, so that doesn't rule out
bundles as being the problem? (darn)
And bundles look pretty simple, a bundle is just a generated source
file with a constant in it.
Maybe newline problems? That wouldn't make sense. I just downloaded
some program that might let me separately view the ppm, maybe it'll
reveal something.
 
The bad behavior has like regularly spaced solid color veritical bars a
few pixels side across the whole picture, and regularly spaced vertical
stripes from the correct picture alternating with that. Perhaps someone
with ppm/bitmap/graphics experience has seen this behavior and it
results from some common pixmap mismanagement we could look for?
 
I have to say this is very surprising.
 
I always wondered, and now I pretty much assume -- Modula-3 never
imports/exports data in its dynamic linking, right? It alway
imports/exports functions, right?
On Windows, functions have an optional optimization, but data must be
handled differently at compile time if it is going to be dynamically
imported.
For functions, if you don't apply the optimization at compile time, the
linker will just generate a single instruction thunk instead.
 
That is, given a symbol Foo, there is a symbol __imp__Foo that is a
pointer to the actual foo in another .dll/.so.
The loader only patches pointers, one per import if you build your .dll
correctly, it doesn't patch instructions or code strewn throughout a
.dll, just one contiguous array of pointers. MAYBE they don't have to be
contiguous for each .dl you import from.
 
That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my
.dll/.exe typically has an array:
 
pointer to msvcrt!fopen
pointer to msvcrt!fclose
null
pointer to kernel32!Sleep
 
But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not
be adjacent.
 
So, going back, my point/question is that, if the compiler knows the
function is imported, it can call through __imp__Foo instead of calling
Foo.
But if it calls Foo and you import Foo, the linker will create the
function Foo that just jmps through __imp__Foo.
That doesn't work for data though. There's no ability to intervenve
like that.
So for imported data, the compiler must generated a read and
dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to
be imported.
Data imports may be faster when appropriate, but for this reason, I'd
say they aren't worth it.
And for this reason, I HOPE Modula-3 never imports/exports data.
 
Oh, you could, for data, always reference the pointer __imp_Foo, and if
non materializes, create one.
However that would suck perf in order to make an uncommon case work.
I hope Modula-3 doesn't do that either. :)
Though I guess since this global data in question...maybe it is
rare???
 
Later,
 - Jay



> From: hosking at cs.purdue.edu 
> Date: Sat, 19 Jan 2008 03:09:47 -0500
> To: rcoleburn at scires.com 
> CC: m3devel at elegosoft.com 
> Subject: Re: [M3devel] pixmap problem
> 
> Looks fine to me on I386_DARWIN.
> 
> On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:
> 
> > 
> 


Need to know the score, the latest news, or you need your Hotmail*-get
your "fix" Check it out. ( http://www.msnmobilefix.com/Default.aspx ) 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sat May 10 11:01:22 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 10 May 2008 09:01:22 +0000
Subject: [M3devel] consoles appearing in gui apps (was pixmap...)
In-Reply-To: <48252503.1E75.00D7.1@scires.com>
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	
	<481F9804.1E75.00D7.1@scires.com> <481F9804.1E75.00D7.1@scires.com>
	 
	<48252503.1E75.00D7.1@scires.com>
Message-ID: 

Randy, this is about what I expect. I only tried 3.6 so far; will try 4.1 later.
Are you satisfied now or not?
Or is your larger actual program showing a popup without output?
 
Or you want output to stderr/stdout in gui apps to just disappear as in 4.1?
 
There definitely is a change from 4.1, and it came in with the Critical Mass code in 5.1.
 
We could I guess put in an @M3 switch to either disappear stdout/stderr in gui apps, or specify a file or files for them to go to. We could also export a function that you'd call to change the global behavior. That's better. It wouldn't do anything on Unix (unless there is a way...?)
 
"Regular" C/C++ stdout/stderr in Windows gui apps does just disappear, but the Modula-3 libraries don't necessarily have to be "the same".
 
There isn't as far as I know an analog on Unix.
I think if you launch something from a typical gui (KDE Kicker, GNOME panels, etc.), stdout/stderr is lost.
If you launch from a console, it is not. I see quite a bit of stdout/stderr spew in gui apps like Kate, KDevelop, etc., seems like bugs (kind of like Windows's OutputDebugString?)
 
 - Jay


Date: Sat, 10 May 2008 04:31:04 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] consoles appearing in gui apps (was pixmap...)

Jay:
 
Here are my results using your test program.  In all cases I have created a desktop shortcut to the EXE and double-click this shortcut to start the program:
 
1.  cm3 v4.1, VS 2005, with IO.Put commented out, no pop-up.
 
2.  cm3 v4.1, VS 2005, using IO.Put, I have to put "@M3novm" on command line, but then get a pop-up showing a crash "runtime error, illegal memory access, LockMutexx in ThreadWin32.m3"
 
3.  cm3 v.d5.7.0, VS 2008, with IO.Put commented out, no pop-up
 
4.  cm3 v.d5.7.0, VS 2008, using IO.Put, I get a pop-up window with the word "Hello".
 
Also, I checked the "link dump" for GUI vs. CUI on both versions and it appears to be working correctly.
 
Regards,
Randy>>> Jay  5/9/2008 1:43 AM >>>  > The bad news is that now I am getting a command window  > opening up in addition to the GUI window when the program runs.   > This behavior does not occur on v4.1.   Randy I've experimented with -gui. Just a few minutes, but I've covered all of the ground I can think of, except I only used -gui and not an m3makefile.From what I see, it all works as it should. Here is my little program: C:\dev2\j\m3\3>type Main.m3MODULE Main;IMPORT IO;IMPORT WinBase;BEGIN  (* IO.Put("Hello\n"); *)  WinBase.Sleep(10000); (* 10 seconds *)IF I uncomment out the IO.Put, and use -gui, then there is a "popup", and hello is printed there.If I don't have the IO.Put however, no popup. Is anything appearing in your console window? Or it is just empty?Are you maybe running processes from your app? Or running them from Explorer?I am running just one Modula-3 test app, from cmd. It is possible that 4.1 does not bring up a console if you use stdout/stderr?There is specific code in the current code to do this.I don't have 4.1 handy..ok, I have 3.6. This appears to have been a deliberate change.  3.6C:\net\modula3\m3\libm3\src\os\WIN32\ProcessWin32.m3(185):PROCEDURE GetFileHandle(hd: WinDef.DWORD; ds: FileWin32.DirectionSet): File.T =PROCEDURE GetFileHandle(hd: WinDef.DWORD; ds: FileWin32.DirectionSet): File.T =  VAR h := WinBase.GetStdHandle(hd);  BEGIN    IF (h = NIL)      OR (h = LOOPHOLE (WinBase.INVALID_HANDLE_VALUE, WinDef.HANDLE)) THEN      RETURN NIL;    END;    TRY RETURN FileWin32.New(h, ds)    EXCEPT OSError.E => (* not available *)    END;    RETURN NIL;  END GetFileHandle; vs. current C:\dev2\cm3\m3-libs\libm3\src\os\WIN32\ProcessWin32.m3(231):PROCEDURE GetFileHandle(hd: WinDef.DWORD; ds: FileWin32.DirectionSet): File.T =PROCEDURE GetFileHandle(hd: WinDef.DWORD; ds: FileWin32.DirectionSet): File.T =  VAR h := WinBase.GetStdHandle(hd);  BEGIN    IF (h # NIL)      AND (h # LOOPHOLE (WinBase.INVALID_HANDLE_VALUE, WinDef.HANDLE)) THEN      TRY RETURN FileWin32.New(h, ds)      EXCEPT OSError.E => (* not available *)      END;    END;    (* if we can't get the standard handles, we might be a GUI program       so we'll lazily allocate a console if needed. *)    RETURN LazyConsole.New (hd, ds);  END GetFileHandle;  Ok, this change came in in the upgrade from Critical Mass 4.1 to 5.1.4.1 being as I understand the actual one and only commercial release.5.1 I guess being the then current but unreleated Critical Mass tree. http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/WIN32/ProcessWin32.m3.diff?r1=1.1.1.1;r2=1.1.1.2;f=u Please advise. Also, to double check that things are working, run link -dump -headers foo.exe | findstr /i "subsystem entry" GUI apps should show: C:\dev2\j\m3\3>link -dump -headers NT386\prog.exe | findstr /i "subsystem entry"            1C60 entry point (00401C60) _WinMainCRTStartup               2 subsystem (Windows GUI) console apps should show: C:\dev2\j\m3\3>link -dump -headers NT386\prog.exe | findstr /i "subsystem entry"            1BE1 entry point (00401BE1) _mainCRTStartup               3 subsystem (Windows CUI)C for console/commandline, G for gui/graphical. If that is not what you are seeing, let's delve into that.If my test program always brings up a popup, when compiled with -gui, with the IO.Put commented out, let's delve into that.If your console is empty, let's look into that.If you console has output in it, well, I'm inclined to say you are seeing improved correct behavior, but we can debate it, I guess.  - Jay


From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: FW: [M3devel] pixmap problemDate: Thu, 8 May 2008 19:21:49 +0000

truncated again...


From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problemDate: Thu, 8 May 2008 18:57:08 +0000

Randy, At first very quick glance, this stuff looks ok.CM3-IDE probably doesn't really understand the config file, similar to m3cgcat's partial misunderstanding.  (Which is why I keep TARGET declared in NT386* instead of just NT386.common.)PKG_USE is defined I think, but it takes a really accurate understanding of Quake to get it. The entry/subsystem stuff also seems complete but I didn't try examples yet.Sorry, didn't give this all much time yet.I did get me to look at the environment variable bug that's been sitting there forever, with a bogus fix.. Can CM3-IDE default PKG_USE to CM3_ROOT + "/pkg"? Or INSTALL_ROOT + "/pkg"? Or whatever?That is what it always is, in anything that is checked in or that cminstall will give you.It takes hand editing of cm3.cfg to get anything else I think. Or CM3-IDE users can just edit the file some. Not a lot. But some.Given an incomplete understanding of the config files, probably putting in CM3-IDE wants but under if FALSE will perhaps work.Personally I wasn't impressed with Reactor... VC5 find-in-files gets me all I need. Anything besides plain text search doesn't scale..  - Jay


From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problemDate: Tue, 6 May 2008 03:38:03 +0000

Randy, don't worry.Two of these problems are trivial to fix -- PKG_USE and popups.The pixmap one will need debugging.  - Jay


Date: Mon, 5 May 2008 23:28:10 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad news is that now I am getting a command window opening up in addition to the GUI window when the program runs.  This behavior does not occur on v4.1.  The command window seems to be the stdout/stderr of the GUI program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy>>> Jay  5/5/2008 10:47 PM >>>Randy, Yes.The NT386 config files are all checked in.You can use them verbatim. You don't need cminstall, I never use it, and you shouldn't need to edit the config files at all, any edits I make, I check in, and should be usable on all machines.As long as you set %PATH%/%INCLUDE%/%LIB%.If I'm wrong, I'd like to know why and try to fix. Consider the config files just part of cm3.exe.Not generally to be changed locally. Unless, well, unless you intend to, and you should strive to make one form that is usable by all.  - Jay


Date: Mon, 5 May 2008 22:42:30 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay,
When you say "took the updated config file", what do you mean?  Are you saying I need a different cm3.cfg file?
Regards,
Randy>>> Jay  5/5/2008 9:54 PM >>>And you took the updated config file?The way you can tell is that, roughly speaking, hand.obj should be in NT386\_m3responsefile0.txt.Or _m3responsefile1.txt, or, well, somewhere.Anyway, I think I saw the attachment, I can check later..and with 4.1 as I said.. I can see about making the fix not depend on config file changes...but it's not terrible asis, and I'd really like to merge more of the quake code into cm3.exe..  - Jay


Date: Mon, 5 May 2008 21:18:12 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem
Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly when the buildstandalone() directive is used.
 
Regards,
Randy>>> Jay  5/5/2008 7:04 PM >>>Thanks. I'll look into this tonight probably, as well as with 4.1 assuming I can find my binaries and source for it (probably).COULD BE the pixmap problem is something else and 4.1 also has the problem I fixed. We'll see. No need to speculate (unless I can't find my 4.1). - Jay


Date: Mon, 5 May 2008 10:59:27 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problem
Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy>>> Jay  5/4/2008 11:46 AM >>>Randy, Please try with /current/ source, as of this morning Sunday May 4 -- the changes are ALL in NT386.common, so you MUST use MY config files, which are checked in verbatim, or you should be able edit whatever config files you are using. (It's not really a config file issue, don't blame the general confusion people have with them.) I'll try to try later, but I don't have the source right now, gotta look on other machines, and I think it's on a machine on loan.  Or send it to me again.I'd also like to know if this worked with 4.1, or with any release that offered dynamic linking to m3core.dll, on Windows.  I recall a claim that it did. If today's change fixes it, I should be able to investigate 4.1.3.6 did not have such linking.If today's change does not help, well, I still plan on debugging it at some point.. If you aren't current and getting so is difficult, just send the attachment again, it's easy for me to test. Thanks, - Jay


From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rcoleburn at scires.comDate: Sat, 19 Jan 2008 08:52:08 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.I was going to try on PPC_DARWIN but I guess Tony's info suffices. I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. Debugging here is a big humungous pain.NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)And bundles look pretty simple, a bundle is just a generated source file with a constant in it.Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something. The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for? I have to say this is very surprising. I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so.The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: pointer to msvcrt!fopenpointer to msvcrt!fclosenullpointer to kernel32!Sleep But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo.But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo.That doesn't work for data though. There's no ability to intervenve like that.So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it.And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.However that would suck perf in order to make an uncommon case work.I hope Modula-3 doesn't do that either. :)Though I guess since this global data in question...maybe it is rare??? Later, - Jay

> From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 03:09:47 -0500> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] pixmap problem> > Looks fine to me on I386_DARWIN.> > On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:> > > > 

Need to know the score, the latest news, or you need your Hotmail?-get your "fix" Check it out. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sat May 10 11:19:59 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 10 May 2008 09:19:59 +0000
Subject: [M3devel] pixmap problem
In-Reply-To: <482529C7.1E75.00D7.1@scires.com>
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	
	<481F9804.1E75.00D7.1@scires.com><481F9804.1E75.00D7.1@scires.com>
	 
	<482529C7.1E75.00D7.1@scires.com>
Message-ID: 

Randy, I strongly recommend you install Python. It is trivial, and gives you something good.
"Try it. You'll like it."
It is WAY more pleasant than dealing with sh or cmd or Perl, and I've spent quite a while fighting with cmd and Perl.
 
scripts\win\do-cm3-std buildship will probably work too.
I'm hoping to find some excuse to delete that directory, like some grand new important feature in the *.sh and *.py files.
 
I put up an updated distribution, and cleaned out older ones.
 
I do consider it a bit of a flaw that cm3 has a "builder", but not a "multi directory builder".
As well, it should be easy to put the build intermediates outside of the source tree.
As well, it should be possible to build outputs directly into the install, for the very optimistic scenario.
I went to build distributions with make-dist.cmd and make-dist.py at the same time and that fails because they fight over intermediate directories.
 
 > I am not seeing hand.obj in the .lst file.
 
You REALLY need to fix that, besides building std.
Linking to hand.obj is THE FIX, at least the current form of it.
My config files always link to it.
You do have to rebuild m3core in order to produce and ship it, which do-cm3-std will do, and upgrade will do.
 
The .lst file I speak of..oh, I guess there's others now, but the main one is the linker output.
  Which is really to say, it is the linker dumping the response file contents.
Or you can check the _m3response0.txt, _m3response1.txt files.
There are now a few more .lst files where there is a C compilation, in order to quash the C compiler output that upsets Olaf and Tony. But these are rare, hand.lst, dtoa.lst, RTLinkerC.lst, we could remove two of them.
 
I can probably remove hand.obj, but a reason to push people away from wierdo heavily customized config files is a good thing.
 
I am certain this bug is fixed.
 
 - Jay



Date: Sat, 10 May 2008 04:51:23 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem


Jay:
 
I do not have python installed on my computer, so I can't run your scripts.
 
I used the scripts in scripts\win to upgrade a few days ago.
 
I am not seeing hand.obj in the .lst file.
 
I will do a CVS update and try the upgrade again followed by do-cm3-standard.
 
Regards,
Randy>>> Jay  5/9/2008 5:10 AM >>>
 > Also, more bad news, the pixmap problem is not solved. Randy, this DOES actually fix it, but you have to rebuild more. Try:   cd scripts\python    .\do-cm3-std.py realclean    .\upgrade.py   (probably not needed)    do-cm3-std.py buildship   Make sure "hand.obj" occurs in the various NT386\foo.lst files. I think the fix should be restated to have the code reference *__imp__highbits instead of highbits, and go back to dynamic linking the data.But ok for now. The std distribution I put yesterday should work, though it is missing the RTArgs fix.I'll see about making another.   - Jay


Date: Mon, 5 May 2008 23:28:10 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad news is that now I am getting a command window opening up in addition to the GUI window when the program runs.  This behavior does not occur on v4.1.  The command window seems to be the stdout/stderr of the GUI program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy>>> Jay  5/5/2008 10:47 PM >>>Randy, Yes.The NT386 config files are all checked in.You can use them verbatim. You don't need cminstall, I never use it, and you shouldn't need to edit the config files at all, any edits I make, I check in, and should be usable on all machines.As long as you set %PATH%/%INCLUDE%/%LIB%.If I'm wrong, I'd like to know why and try to fix. Consider the config files just part of cm3.exe.Not generally to be changed locally. Unless, well, unless you intend to, and you should strive to make one form that is usable by all.  - Jay


Date: Mon, 5 May 2008 22:42:30 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay,
When you say "took the updated config file", what do you mean?  Are you saying I need a different cm3.cfg file?
Regards,
Randy>>> Jay  5/5/2008 9:54 PM >>>And you took the updated config file?The way you can tell is that, roughly speaking, hand.obj should be in NT386\_m3responsefile0.txt.Or _m3responsefile1.txt, or, well, somewhere.Anyway, I think I saw the attachment, I can check later..and with 4.1 as I said.. I can see about making the fix not depend on config file changes...but it's not terrible asis, and I'd really like to merge more of the quake code into cm3.exe..  - Jay


Date: Mon, 5 May 2008 21:18:12 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem
Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly when the buildstandalone() directive is used.
 
Regards,
Randy>>> Jay  5/5/2008 7:04 PM >>>Thanks. I'll look into this tonight probably, as well as with 4.1 assuming I can find my binaries and source for it (probably).COULD BE the pixmap problem is something else and 4.1 also has the problem I fixed. We'll see. No need to speculate (unless I can't find my 4.1). - Jay


Date: Mon, 5 May 2008 10:59:27 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problem
Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy>>> Jay  5/4/2008 11:46 AM >>>Randy, Please try with /current/ source, as of this morning Sunday May 4 -- the changes are ALL in NT386.common, so you MUST use MY config files, which are checked in verbatim, or you should be able edit whatever config files you are using. (It's not really a config file issue, don't blame the general confusion people have with them.) I'll try to try later, but I don't have the source right now, gotta look on other machines, and I think it's on a machine on loan.  Or send it to me again.I'd also like to know if this worked with 4.1, or with any release that offered dynamic linking to m3core.dll, on Windows.  I recall a claim that it did. If today's change fixes it, I should be able to investigate 4.1.3.6 did not have such linking.If today's change does not help, well, I still plan on debugging it at some point.. If you aren't current and getting so is difficult, just send the attachment again, it's easy for me to test. Thanks, - Jay


From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rcoleburn at scires.comDate: Sat, 19 Jan 2008 08:52:08 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.I was going to try on PPC_DARWIN but I guess Tony's info suffices. I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. Debugging here is a big humungous pain.NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)And bundles look pretty simple, a bundle is just a generated source file with a constant in it.Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something. The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for? I have to say this is very surprising. I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so.The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: pointer to msvcrt!fopenpointer to msvcrt!fclosenullpointer to kernel32!Sleep But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo.But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo.That doesn't work for data though. There's no ability to intervenve like that.So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it.And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.However that would suck perf in order to make an uncommon case work.I hope Modula-3 doesn't do that either. :)Though I guess since this global data in question...maybe it is rare??? Later, - Jay

> From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 03:09:47 -0500> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] pixmap problem> > Looks fine to me on I386_DARWIN.> > On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:> > > > 

Need to know the score, the latest news, or you need your Hotmail?-get your "fix" Check it out. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Sat May 10 11:23:35 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Sat, 10 May 2008 05:23:35 -0400
Subject: [M3devel] pixmap problem
In-Reply-To: <482529C7.1E75.00D7.1@scires.com>
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	
	<481F9804.1E75.00D7.1@scires.com><481F9804.1E75.00D7.1@scires.com>
	
	<482529C7.1E75.00D7.1@scires.com>
Message-ID: <48253152.1E75.00D7.1@scires.com>

Jay:
 
I've performed the following and it seems to have fixed the problem
with the TestPixmap program when built standalone:
 
1.  performed CVS update
2.  updated cm3.cfg and NT386* in \cm3\bin based on sources in
cminstall\config
3.  scripts\win\upgrade
4.  scripts\win\do-cm3-std buildship
 
I checked the .lst file and I am now seeing "hand.obj"
 
Regards,
Randy

>>> "Randy Coleburn"  5/10/2008 4:51 AM >>>
Jay:
 
I do not have python installed on my computer, so I can't run your
scripts.
 
I used the scripts in scripts\win to upgrade a few days ago.
 
I am not seeing hand.obj in the .lst file.
 
I will do a CVS update and try the upgrade again followed by
do-cm3-standard.
 
Regards,
Randy

>>> Jay  5/9/2008 5:10 AM >>>
 > Also, more bad news, the pixmap problem is not solved.
 
Randy, this DOES actually fix it, but you have to rebuild more.
 
Try:
   cd scripts\python  
  .\do-cm3-std.py realclean  
  .\upgrade.py   (probably not needed) 
   do-cm3-std.py buildship  
 
Make sure "hand.obj" occurs in the various NT386\foo.lst files.
 
I think the fix should be restated to have the code reference
*__imp__highbits instead of highbits, and go back to dynamic linking the
data.
But ok for now.
 
The std distribution I put yesterday should work, though it is missing
the RTArgs fix.
I'll see about making another.
 
  - Jay

Date: Mon, 5 May 2008 23:28:10 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com; jayk123 at hotmail.com 
Subject: RE: [M3devel] pixmap problem

Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've
copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad
news is that now I am getting a command window opening up in addition to
the GUI window when the program runs.  This behavior does not occur on
v4.1.  The command window seems to be the stdout/stderr of the GUI
program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which
needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy

>>> Jay  5/5/2008 10:47 PM >>>
Randy, Yes.
The NT386 config files are all checked in.
You can use them verbatim. You don't need cminstall, I never use it,
and you shouldn't need to edit the config files at all, any edits I
make, I check in, and should be usable on all machines.
As long as you set %PATH%/%INCLUDE%/%LIB%.
If I'm wrong, I'd like to know why and try to fix.
 
Consider the config files just part of cm3.exe.
Not generally to be changed locally. Unless, well, unless you intend
to, and you should strive to make one form that is usable by all.
 
 - Jay


Date: Mon, 5 May 2008 22:42:30 -0400
From: rcoleburn at scires.com 
To: jayk123 at hotmail.com 
Subject: RE: [M3devel] pixmap problem

Jay,
When you say "took the updated config file", what do you mean?  Are you
saying I need a different cm3.cfg file?
Regards,
Randy

>>> Jay  5/5/2008 9:54 PM >>>
And you took the updated config file?
The way you can tell is that, roughly speaking, hand.obj should be in
NT386\_m3responsefile0.txt.
Or _m3responsefile1.txt, or, well, somewhere.
Anyway, I think I saw the attachment, I can check later..and with 4.1
as I said..
 
I can see about making the fix not depend on config file changes...but
it's not terrible asis, and I'd really like to merge more of the quake
code into cm3.exe..
 
 - Jay

Date: Mon, 5 May 2008 21:18:12 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com 
Subject: Re: [M3devel] pixmap problem

Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly
when the buildstandalone() directive is used.
 
Regards,
Randy

>>> Jay  5/5/2008 7:04 PM >>>
Thanks. I'll look into this tonight probably, as well as with 4.1
assuming I can find my binaries and source for it (probably).

COULD BE the pixmap problem is something else and 4.1 also has the
problem I fixed. We'll see. No need to speculate (unless I can't find my
4.1).

 - Jay


Date: Mon, 5 May 2008 10:59:27 -0400
From: rcoleburn at scires.com 
To: jayk123 at hotmail.com 
CC: m3devel at elegosoft.com 
Subject: RE: [M3devel] pixmap problem

Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files
or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy

>>> Jay  5/4/2008 11:46 AM >>>
Randy, Please try with /current/ source, as of this morning Sunday May
4 -- the changes are ALL in NT386.common, so you MUST use MY config
files, which are checked in verbatim, or you should be able edit
whatever config files you are using.
 
(It's not really a config file issue, don't blame the general confusion
people have with them.)
 
I'll try to try later, but I don't have the source right now, gotta
look on other machines, and I think it's on a machine on loan.
  Or send it to me again.
I'd also like to know if this worked with 4.1, or with any release that
offered dynamic linking to m3core.dll, on Windows.
  I recall a claim that it did. If today's change fixes it, I should be
able to investigate 4.1.
3.6 did not have such linking.
If today's change does not help, well, I still plan on debugging it at
some point..
 
If you aren't current and getting so is difficult, just send the
attachment again, it's easy for me to test.
 
Thanks,
 - Jay

From: jayk123 at hotmail.com 
To: hosking at cs.purdue.edu; rcoleburn at scires.com 
Date: Sat, 19 Jan 2008 08:52:08 +0000
CC: m3devel at elegosoft.com 
Subject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.
I was going to try on PPC_DARWIN but I guess Tony's info suffices.
 
I tried rolling hand.c back to before I changed (months/year ago),
since it is involved in bit twiddling, no change, phew.
 
Debugging here is a big humungous pain.
NT386 has good stacks and line numbers, but no locals or type info, I'd
really sometime like to get Codeview info into those .objs...I think it
is documented well enough, but still not necessarily easy, or maybe have
a C generating backend partly for this reason (and to bring up more
targets, using native tools), and function calls in disassembly I think
don't resolve; NT386GNU can't yet build this, though it will soon, but
I'm not familiar with gdb and there appears to be no type info. I'm
building m3gdb right now, I don't know if it will work, I hope it has
type info, and I'm not familiar with the relevant code. In gdb I
struggle just to view bytes in memory, add numbers to addresses and see
those, etc. I think for MY problem, I'm going to link in C code to dump
the structs. There is tracing code and I enabled it, but even it crashes
in Text_Length. At least MY problem crashes, hopefully near the problem,
whereas your problem goes all the way through to completion with no
stopping to hint where the problem is. Darn it. :) on the mock rudeness
and :( on the lack of a crash.
 
You write the bundle out and it matches, so that doesn't rule out
bundles as being the problem? (darn)
And bundles look pretty simple, a bundle is just a generated source
file with a constant in it.
Maybe newline problems? That wouldn't make sense. I just downloaded
some program that might let me separately view the ppm, maybe it'll
reveal something.
 
The bad behavior has like regularly spaced solid color veritical bars a
few pixels side across the whole picture, and regularly spaced vertical
stripes from the correct picture alternating with that. Perhaps someone
with ppm/bitmap/graphics experience has seen this behavior and it
results from some common pixmap mismanagement we could look for?
 
I have to say this is very surprising.
 
I always wondered, and now I pretty much assume -- Modula-3 never
imports/exports data in its dynamic linking, right? It alway
imports/exports functions, right?
On Windows, functions have an optional optimization, but data must be
handled differently at compile time if it is going to be dynamically
imported.
For functions, if you don't apply the optimization at compile time, the
linker will just generate a single instruction thunk instead.
 
That is, given a symbol Foo, there is a symbol __imp__Foo that is a
pointer to the actual foo in another .dll/.so.
The loader only patches pointers, one per import if you build your .dll
correctly, it doesn't patch instructions or code strewn throughout a
.dll, just one contiguous array of pointers. MAYBE they don't have to be
contiguous for each .dl you import from.
 
That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my
.dll/.exe typically has an array:
 
pointer to msvcrt!fopen
pointer to msvcrt!fclose
null
pointer to kernel32!Sleep
 
But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not
be adjacent.
 
So, going back, my point/question is that, if the compiler knows the
function is imported, it can call through __imp__Foo instead of calling
Foo.
But if it calls Foo and you import Foo, the linker will create the
function Foo that just jmps through __imp__Foo.
That doesn't work for data though. There's no ability to intervenve
like that.
So for imported data, the compiler must generated a read and
dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to
be imported.
Data imports may be faster when appropriate, but for this reason, I'd
say they aren't worth it.
And for this reason, I HOPE Modula-3 never imports/exports data.
 
Oh, you could, for data, always reference the pointer __imp_Foo, and if
non materializes, create one.
However that would suck perf in order to make an uncommon case work.
I hope Modula-3 doesn't do that either. :)
Though I guess since this global data in question...maybe it is
rare???
 
Later,
 - Jay



> From: hosking at cs.purdue.edu 
> Date: Sat, 19 Jan 2008 03:09:47 -0500
> To: rcoleburn at scires.com 
> CC: m3devel at elegosoft.com 
> Subject: Re: [M3devel] pixmap problem
> 
> Looks fine to me on I386_DARWIN.
> 
> On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:
> 
> > 
> 


Need to know the score, the latest news, or you need your Hotmail*-get
your "fix" Check it out. ( http://www.msnmobilefix.com/Default.aspx ) 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Sat May 10 11:24:31 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Sat, 10 May 2008 05:24:31 -0400
Subject: [M3devel] NT386 environment variables (new NT386	snapshots)
References: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
	
	<4823279D.1E75.00D7.1@scires.com>
	
	<482528BA.1E75.00D7.1@scires.com>
Message-ID: <4825318A.1E75.00D7.1@scires.com>

Jay:
 
Here are my results using the program you supplied:
 
1.  cm3 v4.1, VS 2005, GUI mode, get a pop-up dos window, but program crashes
 
2.  cm3 v4.1, VS 2005, console mode, program crashes
 
3.  cm3 v.d5.7.0, VS 2008 GUI mode, get a pop-up window but it disappears too fast to see any contents
 
4.  cm3 v.d5.7.0, VS 2008 console mode, program crashes
 
Regards,
Randy

>>> Jay  5/9/2008 3:44 AM >>>
 > these problems (pixmaps, buildstandalone, environ vars, serial i/o, etc...
 
 Ok, here is the story with environment variables.

I tested 3.6 and current, gui and console.

This is the program:

C:\dev2\j\m3\3>type src\m3makefile

import ("m3core")
import ("libm3")
m3_option ("-gui")     twiddle this line in and out with a comment
implementation ("Main")
program ("pgm")
 
C:\dev2\j\m3\3>type src\Main.m3
MODULE Main;
IMPORT IO;
IMPORT RTArgs;
 
BEGIN
(* IO.Put just crashes in 3.6 gui apps *)
  IO.Put(RTArgs.GetArg(2));
  IO.Put(RTArgs.GetEnv(2));
 
(* use this for gui apps *)
  EVAL RTArgs.GetArg(2);
  EVAL RTArgs.GetEnv(2);
END Main.

In 3.6 console apps, RTArgs.GetEnv returns garbage. That makes sense from the code.
In current console apps, GetEnv works.
In current gui apps, GetEnv access violates, or returns an invalid pointer.
  This also makes sense from the code.

Randy, does this actually work for you?
I'd be quite surprised.
I haven't tried 4.1 yet, just 3.6 and current.

I will apply an easy fix.

 - Jay

Date: Thu, 8 May 2008 16:17:37 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com 
Subject: Re: [M3devel] new NT386 snapshots

Jay:
 
I have both console and gui programs built using 4.1 that do pull stuff out of the environment.  I've not noticed any problems with either mode.
 
>From my perspective, the old 4.1 seems more reliable than the current system in a number of respects.  I have a new project with a hard deadline that I would like to use the new cm3 system for, but until these problems (pixmaps, buildstandalone, environ vars, serial i/o, etc.) can be resolved, I'm going to keep using 4.1 for my production work.
 
Regards,
Randy

>>> Jay  5/8/2008 2:46 PM >>>
http://modula3.elegosoft.com/cm3/uploaded-archives/ 
 
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0.zip 
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-WIN32-NT386-d5.7.0.zip 
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0-symbols.zip 
 
These should have:
  latest quake extensions 
  set relation fixes 
  other set fixes revealed through dynamic linking of one regression test 
  hypothetical ability to cross-build to AMD64_LINUX, AMD64_DARWIN  
  one jmpbuf size for all NT386 configurations (NT386, NT386GNU, NT386MINGNU) 
 
Built with Visual C++ 9.0 Express, so you'll want:
http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en 
 
 
Still more work to do though, e.g. assertion failures in unit tests, pixmap..
 
Fuller disclosure:
Something is leaking memory on my system such that "everything" starts "failing" and I have to reboot.
This isn't Modula-3 related.
Hopefully these files aren't damaged as a result.
Must be some buggy driver or something..
 
Aside:
 The environment variable thingy has been bugging me a long time and I finally looked deeper at it.
It appears broken in CM3 4.x. I didn't check 3.x yet.
I'm still mulling a fix, and haven't run a repro of the break, but it's not a big deal either way.
Basically console apps use main that takes char** and gui apps use WinMain that doesn't get environment variables but the generated code calls GetEvironmentStrings() which returns null separated strings.
Must be that hardly anyone uses environment variables in Modula-3 on Win32 for this to have lingered so long, at least gui apps.
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sat May 10 11:38:30 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 10 May 2008 09:38:30 +0000
Subject: [M3devel] pixmap problem
In-Reply-To: <48253152.1E75.00D7.1@scires.com>
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	
	<481F9804.1E75.00D7.1@scires.com><481F9804.1E75.00D7.1@scires.com>
	
	<482529C7.1E75.00D7.1@scires.com>  <48253152.1E75.00D7.1@scires.com>
Message-ID: 

Randy, clarification, the bug occured when NOT building standalone.
You must know that, since you reproed it recently.
Just try both ways, both should work.
 
(You don't have to take my cm3.cfg, but you do need NT386.common, and then either copy NT386 to cm3.cfg, or take NT386 and have cm3.cfg be just one line, include("NT386"))
 
Any reason left for you to stick with 4.1? :)
Something with serialio?
 
At least one question does remain -- the TestPixmap behavior and why on 4.1.
I'll look into that shortly.
3.6 isn't relevant, since it didn't have .dlls.
 
Thanks,
 - Jay


Date: Sat, 10 May 2008 05:23:35 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem

Jay:
 
I've performed the following and it seems to have fixed the problem with the TestPixmap program when built standalone:
 
1.  performed CVS update
2.  updated cm3.cfg and NT386* in \cm3\bin based on sources in cminstall\config
3.  scripts\win\upgrade
4.  scripts\win\do-cm3-std buildship
 
I checked the .lst file and I am now seeing "hand.obj"
 
Regards,
Randy>>> "Randy Coleburn"  5/10/2008 4:51 AM >>>
Jay:
 
I do not have python installed on my computer, so I can't run your scripts.
 
I used the scripts in scripts\win to upgrade a few days ago.
 
I am not seeing hand.obj in the .lst file.
 
I will do a CVS update and try the upgrade again followed by do-cm3-standard.
 
Regards,
Randy>>> Jay  5/9/2008 5:10 AM >>>
 > Also, more bad news, the pixmap problem is not solved. Randy, this DOES actually fix it, but you have to rebuild more. Try:   cd scripts\python    .\do-cm3-std.py realclean    .\upgrade.py   (probably not needed)    do-cm3-std.py buildship   Make sure "hand.obj" occurs in the various NT386\foo.lst files. I think the fix should be restated to have the code reference *__imp__highbits instead of highbits, and go back to dynamic linking the data.But ok for now. The std distribution I put yesterday should work, though it is missing the RTArgs fix.I'll see about making another.   - Jay


Date: Mon, 5 May 2008 23:28:10 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad news is that now I am getting a command window opening up in addition to the GUI window when the program runs.  This behavior does not occur on v4.1.  The command window seems to be the stdout/stderr of the GUI program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy>>> Jay  5/5/2008 10:47 PM >>>Randy, Yes.The NT386 config files are all checked in.You can use them verbatim. You don't need cminstall, I never use it, and you shouldn't need to edit the config files at all, any edits I make, I check in, and should be usable on all machines.As long as you set %PATH%/%INCLUDE%/%LIB%.If I'm wrong, I'd like to know why and try to fix. Consider the config files just part of cm3.exe.Not generally to be changed locally. Unless, well, unless you intend to, and you should strive to make one form that is usable by all.  - Jay


Date: Mon, 5 May 2008 22:42:30 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay,
When you say "took the updated config file", what do you mean?  Are you saying I need a different cm3.cfg file?
Regards,
Randy>>> Jay  5/5/2008 9:54 PM >>>And you took the updated config file?The way you can tell is that, roughly speaking, hand.obj should be in NT386\_m3responsefile0.txt.Or _m3responsefile1.txt, or, well, somewhere.Anyway, I think I saw the attachment, I can check later..and with 4.1 as I said.. I can see about making the fix not depend on config file changes...but it's not terrible asis, and I'd really like to merge more of the quake code into cm3.exe..  - Jay


Date: Mon, 5 May 2008 21:18:12 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem
Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly when the buildstandalone() directive is used.
 
Regards,
Randy>>> Jay  5/5/2008 7:04 PM >>>Thanks. I'll look into this tonight probably, as well as with 4.1 assuming I can find my binaries and source for it (probably).COULD BE the pixmap problem is something else and 4.1 also has the problem I fixed. We'll see. No need to speculate (unless I can't find my 4.1). - Jay


Date: Mon, 5 May 2008 10:59:27 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problem
Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy>>> Jay  5/4/2008 11:46 AM >>>Randy, Please try with /current/ source, as of this morning Sunday May 4 -- the changes are ALL in NT386.common, so you MUST use MY config files, which are checked in verbatim, or you should be able edit whatever config files you are using. (It's not really a config file issue, don't blame the general confusion people have with them.) I'll try to try later, but I don't have the source right now, gotta look on other machines, and I think it's on a machine on loan.  Or send it to me again.I'd also like to know if this worked with 4.1, or with any release that offered dynamic linking to m3core.dll, on Windows.  I recall a claim that it did. If today's change fixes it, I should be able to investigate 4.1.3.6 did not have such linking.If today's change does not help, well, I still plan on debugging it at some point.. If you aren't current and getting so is difficult, just send the attachment again, it's easy for me to test. Thanks, - Jay


From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rcoleburn at scires.comDate: Sat, 19 Jan 2008 08:52:08 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.I was going to try on PPC_DARWIN but I guess Tony's info suffices. I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. Debugging here is a big humungous pain.NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)And bundles look pretty simple, a bundle is just a generated source file with a constant in it.Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something. The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for? I have to say this is very surprising. I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so.The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: pointer to msvcrt!fopenpointer to msvcrt!fclosenullpointer to kernel32!Sleep But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo.But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo.That doesn't work for data though. There's no ability to intervenve like that.So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it.And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.However that would suck perf in order to make an uncommon case work.I hope Modula-3 doesn't do that either. :)Though I guess since this global data in question...maybe it is rare??? Later, - Jay

> From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 03:09:47 -0500> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] pixmap problem> > Looks fine to me on I386_DARWIN.> > On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:> > > > 

Need to know the score, the latest news, or you need your Hotmail?-get your "fix" Check it out. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sat May 10 11:43:45 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 10 May 2008 09:43:45 +0000
Subject: [M3devel] NT386 environment variables (new NT386	snapshots)
In-Reply-To: <4825318A.1E75.00D7.1@scires.com>
References: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
	
	<4823279D.1E75.00D7.1@scires.com>
	
	<482528BA.1E75.00D7.1@scires.com>  <4825318A.1E75.00D7.1@scires.com>
Message-ID: 

Randy,You can make the popup stick around easily enough, put in WinBase.Sleep(10000), or maybe run under a debugger.
For 5.7 to work, you need the very recent fix to RTArgs.m3 AND you need to pass a few parameters to the test program, like
NT386\pgm abc def ghi
 
 - Jay


Date: Sat, 10 May 2008 05:24:31 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] NT386 environment variables (new NT386 snapshots)

Jay:
 
Here are my results using the program you supplied:
 
1.  cm3 v4.1, VS 2005, GUI mode, get a pop-up dos window, but program crashes
 
2.  cm3 v4.1, VS 2005, console mode, program crashes
 
3.  cm3 v.d5.7.0, VS 2008 GUI mode, get a pop-up window but it disappears too fast to see any contents
 
4.  cm3 v.d5.7.0, VS 2008 console mode, program crashes
 
Regards,
Randy>>> Jay  5/9/2008 3:44 AM >>> > these problems (pixmaps, buildstandalone, environ vars, serial i/o, etc...  Ok, here is the story with environment variables.I tested 3.6 and current, gui and console.This is the program:C:\dev2\j\m3\3>type src\m3makefileimport ("m3core")import ("libm3")m3_option ("-gui")     twiddle this line in and out with a commentimplementation ("Main")program ("pgm") C:\dev2\j\m3\3>type src\Main.m3MODULE Main;IMPORT IO;IMPORT RTArgs; BEGIN(* IO.Put just crashes in 3.6 gui apps *)  IO.Put(RTArgs.GetArg(2));  IO.Put(RTArgs.GetEnv(2)); (* use this for gui apps *)  EVAL RTArgs.GetArg(2);  EVAL RTArgs.GetEnv(2);END Main.In 3.6 console apps, RTArgs.GetEnv returns garbage. That makes sense from the code.In current console apps, GetEnv works.In current gui apps, GetEnv access violates, or returns an invalid pointer.  This also makes sense from the code.Randy, does this actually work for you?I'd be quite surprised.I haven't tried 4.1 yet, just 3.6 and current.I will apply an easy fix. - Jay


Date: Thu, 8 May 2008 16:17:37 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] new NT386 snapshots
Jay:
 
I have both console and gui programs built using 4.1 that do pull stuff out of the environment.  I've not noticed any problems with either mode.
 
>From my perspective, the old 4.1 seems more reliable than the current system in a number of respects.  I have a new project with a hard deadline that I would like to use the new cm3 system for, but until these problems (pixmaps, buildstandalone, environ vars, serial i/o, etc.) can be resolved, I'm going to keep using 4.1 for my production work.
 
Regards,
Randy>>> Jay  5/8/2008 2:46 PM >>>http://modula3.elegosoft.com/cm3/uploaded-archives/ http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0.ziphttp://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-WIN32-NT386-d5.7.0.ziphttp://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0-symbols.zip These should have:  latest quake extensions   set relation fixes   other set fixes revealed through dynamic linking of one regression test   hypothetical ability to cross-build to AMD64_LINUX, AMD64_DARWIN    one jmpbuf size for all NT386 configurations (NT386, NT386GNU, NT386MINGNU)  Built with Visual C++ 9.0 Express, so you'll want:http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en  Still more work to do though, e.g. assertion failures in unit tests, pixmap.. Fuller disclosure:Something is leaking memory on my system such that "everything" starts "failing" and I have to reboot.This isn't Modula-3 related.Hopefully these files aren't damaged as a result.Must be some buggy driver or something.. Aside: The environment variable thingy has been bugging me a long time and I finally looked deeper at it.It appears broken in CM3 4.x. I didn't check 3.x yet.I'm still mulling a fix, and haven't run a repro of the break, but it's not a big deal either way.Basically console apps use main that takes char** and gui apps use WinMain that doesn't get environment variables but the generated code calls GetEvironmentStrings() which returns null separated strings.Must be that hardly anyone uses environment variables in Modula-3 on Win32 for this to have lingered so long, at least gui apps.  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Sat May 10 11:46:16 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Sat, 10 May 2008 05:46:16 -0400
Subject: [M3devel] NT386 environment variables (new	NT386	snapshots)
In-Reply-To: 
References: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
	
	<4823279D.1E75.00D7.1@scires.com>
	
	<482528BA.1E75.00D7.1@scires.com>
	
Message-ID: <482536A3.1E75.00D7.1@scires.com>

Jay:
 
Ok, I've added the sleep.
Here are the new results using my newly rebuilt cm3 and my old v4.1:
 
v4.1:  pgm.exe @M3novm abc def ghi
v5.7:  pgm.exe abc def ghi
 
1.  cm3 4.1, VS 2005, GUI mode, popup with runtime error crash message
 
2.  cm3 4.1, VS 2005, console mode, no popup, output shows "def*5;"
 
3.  cm3 d5.7.0, VS 2008, GUI mode, popup with output shows
"def=ExitCode=00000000"
 
4.  cm3 d5.7.0, VS 2008, console mode, no popup with output shows
"def=ExitCode=00000000"
 
Regards,
Randy

>>> Jay  5/10/2008 5:04 AM >>>
Randy,
You can make the popup stick around, put in WinBase.Sleep(10000), or
run under a debugger.
Since 5.7 is crashing, I assume you don't have the fix I very recently
commited? Or the last point.
I assume if 5.7 doesn't crash, you are satisfied.
 
I forgot to tell you -- make sure you pass a few command line options
to the program, like
 
NT386\pgm.exe abc def ghi.
 
 - Jay

Date: Sat, 10 May 2008 04:46:54 -0400
From: rcoleburn at scires.com 
To: jayk123 at hotmail.com 
Subject: RE: [M3devel] NT386 environment variables (new NT386
snapshots)

Jay:
 
Here are my results using the program you supplied:
 
1.  cm3 v4.1, VS 2005, GUI mode, get a pop-up dos window, but program
crashes
 
2.  cm3 v4.1, VS 2005, console mode, program crashes
 
3.  cm3 v.d5.7.0, VS 2008 GUI mode, get a pop-up window but it
disappears too fast to see any contents
 
4.  cm3 v.d5.7.0, VS 2008 console mode, program crashes
 
Regards,
Randy

>>> Jay  5/9/2008 3:44 AM >>>
 > these problems (pixmaps, buildstandalone, environ vars, serial i/o,
etc...
 
 Ok, here is the story with environment variables.

I tested 3.6 and current, gui and console.

This is the program:

C:\dev2\j\m3\3>type src\m3makefile

import ("m3core")
import ("libm3")
m3_option ("-gui")     twiddle this line in and out with a comment
implementation ("Main")
program ("pgm")
 
C:\dev2\j\m3\3>type src\Main.m3
MODULE Main;
IMPORT IO;
IMPORT RTArgs;
 
BEGIN
(* IO.Put just crashes in 3.6 gui apps *)
  IO.Put(RTArgs.GetArg(2));
  IO.Put(RTArgs.GetEnv(2));
 
(* use this for gui apps *)
  EVAL RTArgs.GetArg(2);
  EVAL RTArgs.GetEnv(2);
END Main.

In 3.6 console apps, RTArgs.GetEnv returns garbage. That makes sense
from the code.
In current console apps, GetEnv works.
In current gui apps, GetEnv access violates, or returns an invalid
pointer.
  This also makes sense from the code.

Randy, does this actually work for you?
I'd be quite surprised.
I haven't tried 4.1 yet, just 3.6 and current.

I will apply an easy fix.

 - Jay

Date: Thu, 8 May 2008 16:17:37 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com 
Subject: Re: [M3devel] new NT386 snapshots

Jay:
 
I have both console and gui programs built using 4.1 that do pull stuff
out of the environment.  I've not noticed any problems with either
mode.
 
>From my perspective, the old 4.1 seems more reliable than the current
system in a number of respects.  I have a new project with a hard
deadline that I would like to use the new cm3 system for, but until
these problems (pixmaps, buildstandalone, environ vars, serial i/o,
etc.) can be resolved, I'm going to keep using 4.1 for my production
work.
 
Regards,
Randy

>>> Jay  5/8/2008 2:46 PM >>>
http://modula3.elegosoft.com/cm3/uploaded-archives/ 
 
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0.zip

http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-WIN32-NT386-d5.7.0.zip

http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0-symbols.zip

 
These should have:
  latest quake extensions 
  set relation fixes 
  other set fixes revealed through dynamic linking of one regression
test 
  hypothetical ability to cross-build to AMD64_LINUX, AMD64_DARWIN  
  one jmpbuf size for all NT386 configurations (NT386, NT386GNU,
NT386MINGNU) 
 
Built with Visual C++ 9.0 Express, so you'll want:
http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en

 
 
Still more work to do though, e.g. assertion failures in unit tests,
pixmap..
 
Fuller disclosure:
Something is leaking memory on my system such that "everything" starts
"failing" and I have to reboot.
This isn't Modula-3 related.
Hopefully these files aren't damaged as a result.
Must be some buggy driver or something..
 
Aside:
 The environment variable thingy has been bugging me a long time and I
finally looked deeper at it.
It appears broken in CM3 4.x. I didn't check 3.x yet.
I'm still mulling a fix, and haven't run a repro of the break, but it's
not a big deal either way.
Basically console apps use main that takes char** and gui apps use
WinMain that doesn't get environment variables but the generated code
calls GetEvironmentStrings() which returns null separated strings.
Must be that hardly anyone uses environment variables in Modula-3 on
Win32 for this to have lingered so long, at least gui apps.
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sat May 10 12:01:09 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 10 May 2008 10:01:09 +0000
Subject: [M3devel] NT386 environment variables (new	NT386	snapshots)
In-Reply-To: <482536A3.1E75.00D7.1@scires.com>
References: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
	
	<4823279D.1E75.00D7.1@scires.com>
	
	<482528BA.1E75.00D7.1@scires.com>
	 
	<482536A3.1E75.00D7.1@scires.com>
Message-ID: 

 > I have both console and gui programs built using 4.1 that do pull stuff out of the environment.
I assume you weren't using RTArgs?
 
Everything good, move along?
 
(Not "everything", there are still m3tests failures..though I guess -- maybe also try them with 3.6, 4.1, 5.1...)
 
 - Jay


Date: Sat, 10 May 2008 05:46:16 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] NT386 environment variables (new NT386 snapshots)

Jay:
 
Ok, I've added the sleep.
Here are the new results using my newly rebuilt cm3 and my old v4.1:
 
v4.1:  pgm.exe @M3novm abc def ghi

v5.7:  pgm.exe abc def ghi
 
1.  cm3 4.1, VS 2005, GUI mode, popup with runtime error crash message
 
2.  cm3 4.1, VS 2005, console mode, no popup, output shows "def?5;"
 
3.  cm3 d5.7.0, VS 2008, GUI mode, popup with output shows "def=ExitCode=00000000"
 
4.  cm3 d5.7.0, VS 2008, console mode, no popup with output shows "def=ExitCode=00000000"
 
Regards,
Randy>>> Jay  5/10/2008 5:04 AM >>>Randy,You can make the popup stick around, put in WinBase.Sleep(10000), or run under a debugger.Since 5.7 is crashing, I assume you don't have the fix I very recently commited? Or the last point.I assume if 5.7 doesn't crash, you are satisfied. I forgot to tell you -- make sure you pass a few command line options to the program, like NT386\pgm.exe abc def ghi.  - Jay


Date: Sat, 10 May 2008 04:46:54 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comSubject: RE: [M3devel] NT386 environment variables (new NT386 snapshots)
Jay:
 
Here are my results using the program you supplied:
 
1.  cm3 v4.1, VS 2005, GUI mode, get a pop-up dos window, but program crashes
 
2.  cm3 v4.1, VS 2005, console mode, program crashes
 
3.  cm3 v.d5.7.0, VS 2008 GUI mode, get a pop-up window but it disappears too fast to see any contents
 
4.  cm3 v.d5.7.0, VS 2008 console mode, program crashes
 
Regards,
Randy>>> Jay  5/9/2008 3:44 AM >>> > these problems (pixmaps, buildstandalone, environ vars, serial i/o, etc...  Ok, here is the story with environment variables.I tested 3.6 and current, gui and console.This is the program:C:\dev2\j\m3\3>type src\m3makefileimport ("m3core")import ("libm3")m3_option ("-gui")     twiddle this line in and out with a commentimplementation ("Main")program ("pgm") C:\dev2\j\m3\3>type src\Main.m3MODULE Main;IMPORT IO;IMPORT RTArgs; BEGIN(* IO.Put just crashes in 3.6 gui apps *)  IO.Put(RTArgs.GetArg(2));  IO.Put(RTArgs.GetEnv(2)); (* use this for gui apps *)  EVAL RTArgs.GetArg(2);  EVAL RTArgs.GetEnv(2);END Main.In 3.6 console apps, RTArgs.GetEnv returns garbage. That makes sense from the code.In current console apps, GetEnv works.In current gui apps, GetEnv access violates, or returns an invalid pointer.  This also makes sense from the code.Randy, does this actually work for you?I'd be quite surprised.I haven't tried 4.1 yet, just 3.6 and current.I will apply an easy fix. - Jay


Date: Thu, 8 May 2008 16:17:37 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] new NT386 snapshots
Jay:
 
I have both console and gui programs built using 4.1 that do pull stuff out of the environment.  I've not noticed any problems with either mode.
 
>From my perspective, the old 4.1 seems more reliable than the current system in a number of respects.  I have a new project with a hard deadline that I would like to use the new cm3 system for, but until these problems (pixmaps, buildstandalone, environ vars, serial i/o, etc.) can be resolved, I'm going to keep using 4.1 for my production work.
 
Regards,
Randy>>> Jay  5/8/2008 2:46 PM >>>http://modula3.elegosoft.com/cm3/uploaded-archives/ http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0.ziphttp://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-WIN32-NT386-d5.7.0.ziphttp://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0-symbols.zip These should have:  latest quake extensions   set relation fixes   other set fixes revealed through dynamic linking of one regression test   hypothetical ability to cross-build to AMD64_LINUX, AMD64_DARWIN    one jmpbuf size for all NT386 configurations (NT386, NT386GNU, NT386MINGNU)  Built with Visual C++ 9.0 Express, so you'll want:http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en  Still more work to do though, e.g. assertion failures in unit tests, pixmap.. Fuller disclosure:Something is leaking memory on my system such that "everything" starts "failing" and I have to reboot.This isn't Modula-3 related.Hopefully these files aren't damaged as a result.Must be some buggy driver or something.. Aside: The environment variable thingy has been bugging me a long time and I finally looked deeper at it.It appears broken in CM3 4.x. I didn't check 3.x yet.I'm still mulling a fix, and haven't run a repro of the break, but it's not a big deal either way.Basically console apps use main that takes char** and gui apps use WinMain that doesn't get environment variables but the generated code calls GetEvironmentStrings() which returns null separated strings.Must be that hardly anyone uses environment variables in Modula-3 on Win32 for this to have lingered so long, at least gui apps.  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Sat May 10 12:05:02 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Sat, 10 May 2008 06:05:02 -0400
Subject: [M3devel] pixmap problem
In-Reply-To: 
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	
	<481F9804.1E75.00D7.1@scires.com><481F9804.1E75.00D7.1@scires.com>
	
	<482529C7.1E75.00D7.1@scires.com>
	<48253152.1E75.00D7.1@scires.com><48253152.1E75.00D7.1@scires.com>
	
Message-ID: <48253B09.1E75.00D7.1@scires.com>

Jay:
 
I get correct behavior now for TestPixmap on d5.7 when built either
way, with or without standalone option.
THANKS!
 
On 4.1, TestPixmap also works both ways.  The problem was occurring
before your fix on d5.7 (and on earlier releases after 4.1).  Not sure
what your fix does or what changed from 4.1 to d5.7 that made your fix
necessary.
 
I am using your NT386 stuff for cm3.cfg now.
 
I don't have 3.6.
 
I will need to run tests now with d5.7 against my programs to see if
they are working correctly before I can abandon 4.1.  Also, we will need
to drive a stake in the ground at some point soon to create an official
5.7 release.  My company will want to be able to point to a given
development environment for future support of the product I'm working
on.  They won't accept a "d5.7" release that is in a state of flux.
 
Also, the other issue I'll have to work is getting all the GUI changes
incorporated into this edition.  We will need the custom look&feel that
CMass put together for us.  I'll check into it.  If I am successful, I
can create a branch on CVS with this edition in case anyone else wants
it.
 
Regards,
Randy

>>> Jay  5/10/2008 5:38 AM >>>
Randy, clarification, the bug occured when NOT building standalone.
You must know that, since you reproed it recently.
Just try both ways, both should work.
 
(You don't have to take my cm3.cfg, but you do need NT386.common, and
then either copy NT386 to cm3.cfg, or take NT386 and have cm3.cfg be
just one line, include("NT386"))
 
Any reason left for you to stick with 4.1? :)
Something with serialio?
 
At least one question does remain -- the TestPixmap behavior and why on
4.1.
I'll look into that shortly.
3.6 isn't relevant, since it didn't have .dlls.
 
Thanks,
 - Jay
Date: Sat, 10 May 2008 05:23:35 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com 
Subject: Re: [M3devel] pixmap problem

Jay:
 
I've performed the following and it seems to have fixed the problem
with the TestPixmap program when built standalone:
 
1.  performed CVS update
2.  updated cm3.cfg and NT386* in \cm3\bin based on sources in
cminstall\config
3.  scripts\win\upgrade
4.  scripts\win\do-cm3-std buildship
 
I checked the .lst file and I am now seeing "hand.obj"
 
Regards,
Randy

>>> "Randy Coleburn"  5/10/2008 4:51 AM >>>
Jay:
 
I do not have python installed on my computer, so I can't run your
scripts.
 
I used the scripts in scripts\win to upgrade a few days ago.
 
I am not seeing hand.obj in the .lst file.
 
I will do a CVS update and try the upgrade again followed by
do-cm3-standard.
 
Regards,
Randy

>>> Jay  5/9/2008 5:10 AM >>>
 > Also, more bad news, the pixmap problem is not solved.
 
Randy, this DOES actually fix it, but you have to rebuild more.
 
Try:
   cd scripts\python  
  .\do-cm3-std.py realclean  
  .\upgrade.py   (probably not needed) 
   do-cm3-std.py buildship  
 
Make sure "hand.obj" occurs in the various NT386\foo.lst files.
 
I think the fix should be restated to have the code reference
*__imp__highbits instead of highbits, and go back to dynamic linking the
data.
But ok for now.
 
The std distribution I put yesterday should work, though it is missing
the RTArgs fix.
I'll see about making another.
 
  - Jay

Date: Mon, 5 May 2008 23:28:10 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com; jayk123 at hotmail.com 
Subject: RE: [M3devel] pixmap problem

Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've
copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad
news is that now I am getting a command window opening up in addition to
the GUI window when the program runs.  This behavior does not occur on
v4.1.  The command window seems to be the stdout/stderr of the GUI
program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which
needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy

>>> Jay  5/5/2008 10:47 PM >>>
Randy, Yes.
The NT386 config files are all checked in.
You can use them verbatim. You don't need cminstall, I never use it,
and you shouldn't need to edit the config files at all, any edits I
make, I check in, and should be usable on all machines.
As long as you set %PATH%/%INCLUDE%/%LIB%.
If I'm wrong, I'd like to know why and try to fix.
 
Consider the config files just part of cm3.exe.
Not generally to be changed locally. Unless, well, unless you intend
to, and you should strive to make one form that is usable by all.
 
 - Jay


Date: Mon, 5 May 2008 22:42:30 -0400
From: rcoleburn at scires.com 
To: jayk123 at hotmail.com 
Subject: RE: [M3devel] pixmap problem

Jay,
When you say "took the updated config file", what do you mean?  Are you
saying I need a different cm3.cfg file?
Regards,
Randy

>>> Jay  5/5/2008 9:54 PM >>>
And you took the updated config file?
The way you can tell is that, roughly speaking, hand.obj should be in
NT386\_m3responsefile0.txt.
Or _m3responsefile1.txt, or, well, somewhere.
Anyway, I think I saw the attachment, I can check later..and with 4.1
as I said..
 
I can see about making the fix not depend on config file changes...but
it's not terrible asis, and I'd really like to merge more of the quake
code into cm3.exe..
 
 - Jay

Date: Mon, 5 May 2008 21:18:12 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com 
Subject: Re: [M3devel] pixmap problem

Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly
when the buildstandalone() directive is used.
 
Regards,
Randy

>>> Jay  5/5/2008 7:04 PM >>>
Thanks. I'll look into this tonight probably, as well as with 4.1
assuming I can find my binaries and source for it (probably).

COULD BE the pixmap problem is something else and 4.1 also has the
problem I fixed. We'll see. No need to speculate (unless I can't find my
4.1).

 - Jay


Date: Mon, 5 May 2008 10:59:27 -0400
From: rcoleburn at scires.com 
To: jayk123 at hotmail.com 
CC: m3devel at elegosoft.com 
Subject: RE: [M3devel] pixmap problem

Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files
or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy

>>> Jay  5/4/2008 11:46 AM >>>
Randy, Please try with /current/ source, as of this morning Sunday May
4 -- the changes are ALL in NT386.common, so you MUST use MY config
files, which are checked in verbatim, or you should be able edit
whatever config files you are using.
 
(It's not really a config file issue, don't blame the general confusion
people have with them.)
 
I'll try to try later, but I don't have the source right now, gotta
look on other machines, and I think it's on a machine on loan.
  Or send it to me again.
I'd also like to know if this worked with 4.1, or with any release that
offered dynamic linking to m3core.dll, on Windows.
  I recall a claim that it did. If today's change fixes it, I should be
able to investigate 4.1.
3.6 did not have such linking.
If today's change does not help, well, I still plan on debugging it at
some point..
 
If you aren't current and getting so is difficult, just send the
attachment again, it's easy for me to test.
 
Thanks,
 - Jay

From: jayk123 at hotmail.com 
To: hosking at cs.purdue.edu; rcoleburn at scires.com 
Date: Sat, 19 Jan 2008 08:52:08 +0000
CC: m3devel at elegosoft.com 
Subject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.
I was going to try on PPC_DARWIN but I guess Tony's info suffices.
 
I tried rolling hand.c back to before I changed (months/year ago),
since it is involved in bit twiddling, no change, phew.
 
Debugging here is a big humungous pain.
NT386 has good stacks and line numbers, but no locals or type info, I'd
really sometime like to get Codeview info into those .objs...I think it
is documented well enough, but still not necessarily easy, or maybe have
a C generating backend partly for this reason (and to bring up more
targets, using native tools), and function calls in disassembly I think
don't resolve; NT386GNU can't yet build this, though it will soon, but
I'm not familiar with gdb and there appears to be no type info. I'm
building m3gdb right now, I don't know if it will work, I hope it has
type info, and I'm not familiar with the relevant code. In gdb I
struggle just to view bytes in memory, add numbers to addresses and see
those, etc. I think for MY problem, I'm going to link in C code to dump
the structs. There is tracing code and I enabled it, but even it crashes
in Text_Length. At least MY problem crashes, hopefully near the problem,
whereas your problem goes all the way through to completion with no
stopping to hint where the problem is. Darn it. :) on the mock rudeness
and :( on the lack of a crash.
 
You write the bundle out and it matches, so that doesn't rule out
bundles as being the problem? (darn)
And bundles look pretty simple, a bundle is just a generated source
file with a constant in it.
Maybe newline problems? That wouldn't make sense. I just downloaded
some program that might let me separately view the ppm, maybe it'll
reveal something.
 
The bad behavior has like regularly spaced solid color veritical bars a
few pixels side across the whole picture, and regularly spaced vertical
stripes from the correct picture alternating with that. Perhaps someone
with ppm/bitmap/graphics experience has seen this behavior and it
results from some common pixmap mismanagement we could look for?
 
I have to say this is very surprising.
 
I always wondered, and now I pretty much assume -- Modula-3 never
imports/exports data in its dynamic linking, right? It alway
imports/exports functions, right?
On Windows, functions have an optional optimization, but data must be
handled differently at compile time if it is going to be dynamically
imported.
For functions, if you don't apply the optimization at compile time, the
linker will just generate a single instruction thunk instead.
 
That is, given a symbol Foo, there is a symbol __imp__Foo that is a
pointer to the actual foo in another .dll/.so.
The loader only patches pointers, one per import if you build your .dll
correctly, it doesn't patch instructions or code strewn throughout a
.dll, just one contiguous array of pointers. MAYBE they don't have to be
contiguous for each .dl you import from.
 
That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my
.dll/.exe typically has an array:
 
pointer to msvcrt!fopen
pointer to msvcrt!fclose
null
pointer to kernel32!Sleep
 
But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not
be adjacent.
 
So, going back, my point/question is that, if the compiler knows the
function is imported, it can call through __imp__Foo instead of calling
Foo.
But if it calls Foo and you import Foo, the linker will create the
function Foo that just jmps through __imp__Foo.
That doesn't work for data though. There's no ability to intervenve
like that.
So for imported data, the compiler must generated a read and
dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to
be imported.
Data imports may be faster when appropriate, but for this reason, I'd
say they aren't worth it.
And for this reason, I HOPE Modula-3 never imports/exports data.
 
Oh, you could, for data, always reference the pointer __imp_Foo, and if
non materializes, create one.
However that would suck perf in order to make an uncommon case work.
I hope Modula-3 doesn't do that either. :)
Though I guess since this global data in question...maybe it is
rare???
 
Later,
 - Jay



> From: hosking at cs.purdue.edu 
> Date: Sat, 19 Jan 2008 03:09:47 -0500
> To: rcoleburn at scires.com 
> CC: m3devel at elegosoft.com 
> Subject: Re: [M3devel] pixmap problem
> 
> Looks fine to me on I386_DARWIN.
> 
> On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:
> 
> > 
> 


Need to know the score, the latest news, or you need your Hotmail*-get
your "fix" Check it out. ( http://www.msnmobilefix.com/Default.aspx ) 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Sat May 10 12:14:46 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Sat, 10 May 2008 06:14:46 -0400
Subject: [M3devel] NT386 environment variables	(new	NT386	snapshots)
In-Reply-To: 
References: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
	
	<4823279D.1E75.00D7.1@scires.com>
	
	<482528BA.1E75.00D7.1@scires.com>
	
	<482536A3.1E75.00D7.1@scires.com><482536A3.1E75.00D7.1@scires.com>
	
Message-ID: <48253D51.1E75.00D7.1@scires.com>

Jay:
 
No, I don't think I was using RTArgs.  I was using Env.Get().
 
Regards,
Randy

>>> Jay  5/10/2008 6:01 AM >>>
 > I have both console and gui programs built using 4.1 that do pull
stuff out of the environment.

I assume you weren't using RTArgs?
 
Everything good, move along?
 
(Not "everything", there are still m3tests failures..though I guess --
maybe also try them with 3.6, 4.1, 5.1...)
 
 - Jay

Date: Sat, 10 May 2008 05:46:16 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com 
Subject: Re: [M3devel] NT386 environment variables (new NT386
snapshots)

Jay:
 
Ok, I've added the sleep.
Here are the new results using my newly rebuilt cm3 and my old v4.1:
 
v4.1:  pgm.exe @M3novm abc def ghi
v5.7:  pgm.exe abc def ghi
 
1.  cm3 4.1, VS 2005, GUI mode, popup with runtime error crash message
 
2.  cm3 4.1, VS 2005, console mode, no popup, output shows "def*5;"
 
3.  cm3 d5.7.0, VS 2008, GUI mode, popup with output shows
"def=ExitCode=00000000"
 
4.  cm3 d5.7.0, VS 2008, console mode, no popup with output shows
"def=ExitCode=00000000"
 
Regards,
Randy

>>> Jay  5/10/2008 5:04 AM >>>
Randy,
You can make the popup stick around, put in WinBase.Sleep(10000), or
run under a debugger.
Since 5.7 is crashing, I assume you don't have the fix I very recently
commited? Or the last point.
I assume if 5.7 doesn't crash, you are satisfied.
 
I forgot to tell you -- make sure you pass a few command line options
to the program, like
 
NT386\pgm.exe abc def ghi.
 
 - Jay

Date: Sat, 10 May 2008 04:46:54 -0400
From: rcoleburn at scires.com 
To: jayk123 at hotmail.com 
Subject: RE: [M3devel] NT386 environment variables (new NT386
snapshots)

Jay:
 
Here are my results using the program you supplied:
 
1.  cm3 v4.1, VS 2005, GUI mode, get a pop-up dos window, but program
crashes
 
2.  cm3 v4.1, VS 2005, console mode, program crashes
 
3.  cm3 v.d5.7.0, VS 2008 GUI mode, get a pop-up window but it
disappears too fast to see any contents
 
4.  cm3 v.d5.7.0, VS 2008 console mode, program crashes
 
Regards,
Randy

>>> Jay  5/9/2008 3:44 AM >>>
 > these problems (pixmaps, buildstandalone, environ vars, serial i/o,
etc...
 
 Ok, here is the story with environment variables.

I tested 3.6 and current, gui and console.

This is the program:

C:\dev2\j\m3\3>type src\m3makefile

import ("m3core")
import ("libm3")
m3_option ("-gui")     twiddle this line in and out with a comment
implementation ("Main")
program ("pgm")
 
C:\dev2\j\m3\3>type src\Main.m3
MODULE Main;
IMPORT IO;
IMPORT RTArgs;
 
BEGIN
(* IO.Put just crashes in 3.6 gui apps *)
  IO.Put(RTArgs.GetArg(2));
  IO.Put(RTArgs.GetEnv(2));
 
(* use this for gui apps *)
  EVAL RTArgs.GetArg(2);
  EVAL RTArgs.GetEnv(2);
END Main.

In 3.6 console apps, RTArgs.GetEnv returns garbage. That makes sense
from the code.
In current console apps, GetEnv works.
In current gui apps, GetEnv access violates, or returns an invalid
pointer.
  This also makes sense from the code.

Randy, does this actually work for you?
I'd be quite surprised.
I haven't tried 4.1 yet, just 3.6 and current.

I will apply an easy fix.

 - Jay

Date: Thu, 8 May 2008 16:17:37 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com 
Subject: Re: [M3devel] new NT386 snapshots

Jay:
 
I have both console and gui programs built using 4.1 that do pull stuff
out of the environment.  I've not noticed any problems with either
mode.
 
>From my perspective, the old 4.1 seems more reliable than the current
system in a number of respects.  I have a new project with a hard
deadline that I would like to use the new cm3 system for, but until
these problems (pixmaps, buildstandalone, environ vars, serial i/o,
etc.) can be resolved, I'm going to keep using 4.1 for my production
work.
 
Regards,
Randy

>>> Jay  5/8/2008 2:46 PM >>>
http://modula3.elegosoft.com/cm3/uploaded-archives/ 
 
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0.zip

http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-WIN32-NT386-d5.7.0.zip

http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0-symbols.zip

 
These should have:
  latest quake extensions 
  set relation fixes 
  other set fixes revealed through dynamic linking of one regression
test 
  hypothetical ability to cross-build to AMD64_LINUX, AMD64_DARWIN  
  one jmpbuf size for all NT386 configurations (NT386, NT386GNU,
NT386MINGNU) 
 
Built with Visual C++ 9.0 Express, so you'll want:
http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en

 
 
Still more work to do though, e.g. assertion failures in unit tests,
pixmap..
 
Fuller disclosure:
Something is leaking memory on my system such that "everything" starts
"failing" and I have to reboot.
This isn't Modula-3 related.
Hopefully these files aren't damaged as a result.
Must be some buggy driver or something..
 
Aside:
 The environment variable thingy has been bugging me a long time and I
finally looked deeper at it.
It appears broken in CM3 4.x. I didn't check 3.x yet.
I'm still mulling a fix, and haven't run a repro of the break, but it's
not a big deal either way.
Basically console apps use main that takes char** and gui apps use
WinMain that doesn't get environment variables but the generated code
calls GetEvironmentStrings() which returns null separated strings.
Must be that hardly anyone uses environment variables in Modula-3 on
Win32 for this to have lingered so long, at least gui apps.
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sat May 10 12:48:08 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 10 May 2008 10:48:08 +0000
Subject: [M3devel] pixmap problem
In-Reply-To: <48253B09.1E75.00D7.1@scires.com>
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	
	<481F9804.1E75.00D7.1@scires.com><481F9804.1E75.00D7.1@scires.com>
	
	<482529C7.1E75.00D7.1@scires.com>
	<48253152.1E75.00D7.1@scires.com><48253152.1E75.00D7.1@scires.com>
	 
	<48253B09.1E75.00D7.1@scires.com>
Message-ID: 

Randy, 3.6 is still available for download on the web, and it still works.
 
I know exactly what my fix does and why it wasn't working before in the immediate past -- some set operations are dependent on data in m3core, in hand.c, and importing data from a .dll requires dereferencing a pointer to get the data. Whereas getting data from a static .lib does not. The pointer for data "foo" is usually called "__imp__foo", though that is just a convention implemented by the linker. So, let's say foo is a function. The generated code to call foo can be, and in Modula-3 always is, merely "call foo", or maybe "call _foo". x86 Windows tends to put a leading underscore on everything. That's a different matter. Now, again, foo is a function let's say, and the code says "call foo". Now, if foo ends up being imported from a .dll, what the linker does is generate a one instruction function like so:
 
foo:
  jmp dword ptr [__imp__foo]
 
And then __imp__foo is also special. __imp__foo is created such that at runtime, at load time, it is overwritten with the address of the actual location of the actual foo function in another .dll. All the __imp__ symbols are adjacent, so these writes aren't scattered around and written pages are kept to a minimum, at least in this regard.
 
Now, if you KNOW you are going to import foo, you can give the compiler a small optimization hint, and the compiler can "call dword ptr [__imp__foo]" directly, skipping the one instruction -- said instruction also having poor locality. As well, the Visual C++ compiler is smart enough to prefetch the instruction, and if you make repeated calls to an imported function, even keep it around in a register. There is no way to get this in Modula-3 today, and really it doesn't seem like a big deal to me. See, you know, if you don't know if foo will be dynamically linked or statically linked, "call foo" is reasonable efficient generic code. If you think it will be imported, you can generate "call dword ptr [__imp__foo]" instead, but then if you are wrong, either a) you get a link error, or b) you can go ahead and generate the pointer that points to the function, and you will pay an extra pointer dereference in the function calls, but at least not an extra instruction. As I wildly guess, calls to statically linked functions are more common than calls to dynamically linked functions, so erring toward making the static call more efficient seems better. On the other hand, it appears to me that Windows is alone here. My brief look into the Linux and Darwin calling conventions indicates they use big inefficient methods, worse than the "worst case" Windows uses, when you take either of the deoptimizations I describe. Granted, everyone else tends to get actually position independent code, and Windows does not. Windows get relocatable code, but not position independent, and the cost of the relocation can be high (every page written, loss of physical memory sharing, dirty pages backed by pagefile instead of the original .exe/.dll).
AMD64 Windows has mostly position independent code via the new RIP-relative addressing mode, but not fully. What often bites you is pointers in your data, like vtables. I do wish Windows had fully position independent code and I don't know if that would result in exactly the inefficient sequences I see on Linux and Darwin or not.
 
 
Ok now. That only mentioned functions. There was no mention of data.
You must pay close attention to particular details. In particular, the code always says "call foo" and if foo is imported, the linker generates a single instruction function, named foo, just like expected, that indirects through a pointer. You must indirect through a pointer for dynamic linking. And since there is a function call involved, a function can be generated to fit.
There's some saying here, like, you know that "any problem can be solved by an extra level of indirection", well, there's some corralary like "give me a function call and I can add indirection afterward".
 
But if you think about data, compiler generates something like "mov eax, foo" -- there's no way for the linker to intercede there -- there is no function call. It actually should fail to link. That is a different related matter. If you make the kind of error in C code that we have in Modula-3, you would get a link error. I'll show you in a sec. What happens in Modula-3, is, well, something, like mklib, doesn't know foo is data instead of a function, and goes ahead and generates foo that jmps through __imp__foo. That function foo is what these data references end up using, with fairly "random" results.
 
What my fix does is statically link in foo (_highbits, _lowbits). So the regular "mov eax, foo" works. No pointer derefence is needed for static linking, no __imp__ foo. I should go and fix the compiler to reference __imp__foo, and if we end up statically linked, like for standalone, there can be an extra pointer __imp_foo = &foo, and standalone will pay an extra, unnecessary, pointer deref.
 
Here is how you can see this problem in C.
 
  dll.c  
  __declspec(dllexport) int foo;  
   
  exe.c  
  extern int foo;   
  int main()  
 {  
   printf("%d\n", foo);    
  return 0;     }  
 
 cl -LD dll.c -link -noentry -nodefaultlib 
 rem really that's all it takes to make a .dll 
 cl exe.c dll.lib 
 rem really, that's it takes to build an .exe that uses the .dll 
 
 >> exe.obj : error LNK2019: unresolved external symbol foo referenced in function main 
 
But if you change it to:
 
  __declspec(dllimport) extern int foo;  
 
then it works. I don't fully understand this -- something somewhere knows that foo is data and doesn't generate the function for it. If you use a .def file, you mark the symbol as "data".
 
The GNU tools, ld --help, suggests some workaround here. That they let you generate the "wrong" code and the linker somehow makes it work. I don't know what it is..the only thing I can think of might not work and would look really ugly. I think link -dump crashes on ld output so I stopped looking..
 
I will look into 4.1 to determine what changed and why it worked.
 
The result in 5.x is actually not guaranteeably wrong, just very very difficult to predict the outcome of.
Instead of referencing the correct data, some fairly arbitrary data is used. But of course not every bit matters.
Could be the 4.1 code doesn't use the set operations here even, avoiding this problem.
We'll see. "There is no need to speculate; just debug it and know." :)
That's my own saying. I see so much unnecessary speculation and metaphorical throwing of hands in the air, and not enough debugging. :)  (Granted, something is screwy on my XP AMD64 machine and I'm more likely to reinstall than debug it...and maybe if it recurs then I'll debug some...can't do much without source and symbols though...that's where my debugging skills rapidly fall off...(which is a complaint I have about Modula-3, there's a certain lack of symbols for global data I believe, probably should be fixed...)) 
 
 - Jay


Date: Sat, 10 May 2008 06:05:02 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem

Jay:
 
I get correct behavior now for TestPixmap on d5.7 when built either way, with or without standalone option.
THANKS!
 
On 4.1, TestPixmap also works both ways.  The problem was occurring before your fix on d5.7 (and on earlier releases after 4.1).  Not sure what your fix does or what changed from 4.1 to d5.7 that made your fix necessary.
 
I am using your NT386 stuff for cm3.cfg now.
 
I don't have 3.6.
 
I will need to run tests now with d5.7 against my programs to see if they are working correctly before I can abandon 4.1.  Also, we will need to drive a stake in the ground at some point soon to create an official 5.7 release.  My company will want to be able to point to a given development environment for future support of the product I'm working on.  They won't accept a "d5.7" release that is in a state of flux.
 
Also, the other issue I'll have to work is getting all the GUI changes incorporated into this edition.  We will need the custom look&feel that CMass put together for us.  I'll check into it.  If I am successful, I can create a branch on CVS with this edition in case anyone else wants it.
 
Regards,
Randy>>> Jay  5/10/2008 5:38 AM >>>Randy, clarification, the bug occured when NOT building standalone.You must know that, since you reproed it recently.Just try both ways, both should work. (You don't have to take my cm3.cfg, but you do need NT386.common, and then either copy NT386 to cm3.cfg, or take NT386 and have cm3.cfg be just one line, include("NT386")) Any reason left for you to stick with 4.1? :)Something with serialio? At least one question does remain -- the TestPixmap behavior and why on 4.1.I'll look into that shortly.3.6 isn't relevant, since it didn't have .dlls. Thanks, - Jay


Date: Sat, 10 May 2008 05:23:35 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem
Jay:
 
I've performed the following and it seems to have fixed the problem with the TestPixmap program when built standalone:
 
1.  performed CVS update
2.  updated cm3.cfg and NT386* in \cm3\bin based on sources in cminstall\config
3.  scripts\win\upgrade
4.  scripts\win\do-cm3-std buildship
 
I checked the .lst file and I am now seeing "hand.obj"
 
Regards,
Randy>>> "Randy Coleburn"  5/10/2008 4:51 AM >>>
Jay:
 
I do not have python installed on my computer, so I can't run your scripts.
 
I used the scripts in scripts\win to upgrade a few days ago.
 
I am not seeing hand.obj in the .lst file.
 
I will do a CVS update and try the upgrade again followed by do-cm3-standard.
 
Regards,
Randy>>> Jay  5/9/2008 5:10 AM >>>
 > Also, more bad news, the pixmap problem is not solved. Randy, this DOES actually fix it, but you have to rebuild more. Try:   cd scripts\python    .\do-cm3-std.py realclean    .\upgrade.py   (probably not needed)    do-cm3-std.py buildship   Make sure "hand.obj" occurs in the various NT386\foo.lst files. I think the fix should be restated to have the code reference *__imp__highbits instead of highbits, and go back to dynamic linking the data.But ok for now. The std distribution I put yesterday should work, though it is missing the RTArgs fix.I'll see about making another.   - Jay


Date: Mon, 5 May 2008 23:28:10 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad news is that now I am getting a command window opening up in addition to the GUI window when the program runs.  This behavior does not occur on v4.1.  The command window seems to be the stdout/stderr of the GUI program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy>>> Jay  5/5/2008 10:47 PM >>>Randy, Yes.The NT386 config files are all checked in.You can use them verbatim. You don't need cminstall, I never use it, and you shouldn't need to edit the config files at all, any edits I make, I check in, and should be usable on all machines.As long as you set %PATH%/%INCLUDE%/%LIB%.If I'm wrong, I'd like to know why and try to fix. Consider the config files just part of cm3.exe.Not generally to be changed locally. Unless, well, unless you intend to, and you should strive to make one form that is usable by all.  - Jay


Date: Mon, 5 May 2008 22:42:30 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay,
When you say "took the updated config file", what do you mean?  Are you saying I need a different cm3.cfg file?
Regards,
Randy>>> Jay  5/5/2008 9:54 PM >>>And you took the updated config file?The way you can tell is that, roughly speaking, hand.obj should be in NT386\_m3responsefile0.txt.Or _m3responsefile1.txt, or, well, somewhere.Anyway, I think I saw the attachment, I can check later..and with 4.1 as I said.. I can see about making the fix not depend on config file changes...but it's not terrible asis, and I'd really like to merge more of the quake code into cm3.exe..  - Jay


Date: Mon, 5 May 2008 21:18:12 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem
Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly when the buildstandalone() directive is used.
 
Regards,
Randy>>> Jay  5/5/2008 7:04 PM >>>Thanks. I'll look into this tonight probably, as well as with 4.1 assuming I can find my binaries and source for it (probably).COULD BE the pixmap problem is something else and 4.1 also has the problem I fixed. We'll see. No need to speculate (unless I can't find my 4.1). - Jay


Date: Mon, 5 May 2008 10:59:27 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problem
Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy>>> Jay  5/4/2008 11:46 AM >>>Randy, Please try with /current/ source, as of this morning Sunday May 4 -- the changes are ALL in NT386.common, so you MUST use MY config files, which are checked in verbatim, or you should be able edit whatever config files you are using. (It's not really a config file issue, don't blame the general confusion people have with them.) I'll try to try later, but I don't have the source right now, gotta look on other machines, and I think it's on a machine on loan.  Or send it to me again.I'd also like to know if this worked with 4.1, or with any release that offered dynamic linking to m3core.dll, on Windows.  I recall a claim that it did. If today's change fixes it, I should be able to investigate 4.1.3.6 did not have such linking.If today's change does not help, well, I still plan on debugging it at some point.. If you aren't current and getting so is difficult, just send the attachment again, it's easy for me to test. Thanks, - Jay


From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rcoleburn at scires.comDate: Sat, 19 Jan 2008 08:52:08 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.I was going to try on PPC_DARWIN but I guess Tony's info suffices. I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. Debugging here is a big humungous pain.NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)And bundles look pretty simple, a bundle is just a generated source file with a constant in it.Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something. The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for? I have to say this is very surprising. I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so.The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: pointer to msvcrt!fopenpointer to msvcrt!fclosenullpointer to kernel32!Sleep But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo.But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo.That doesn't work for data though. There's no ability to intervenve like that.So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it.And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.However that would suck perf in order to make an uncommon case work.I hope Modula-3 doesn't do that either. :)Though I guess since this global data in question...maybe it is rare??? Later, - Jay

> From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 03:09:47 -0500> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] pixmap problem> > Looks fine to me on I386_DARWIN.> > On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:> > > > 

Need to know the score, the latest news, or you need your Hotmail?-get your "fix" Check it out. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sat May 10 17:40:40 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 10 May 2008 15:40:40 +0000
Subject: [M3devel] _lowbits / _highbits (Pixmap bug-- 4.1 vs. buggy 5.x)
Message-ID: 

There is SOME evidence that this lowbits/highbitsproblem is a regression introduced in Critical Mass 5.1.And there are inconsistent data.
(I believe 5.1 is the name given to the Critical Mass tree at the time it was open-sourced, vs. 4.1 which was commercially released, and some source withheld.)
 
The source history is a little incomplete.Critical Mass 4.1 did not ship with complete source.In particular, the compiler source is missing.Libraries are there.
 
Aside: I wonder if the 4.1 release can be made more widelyavailable, for purposes such as this. For one thing, I can contributehow to trivially patch the NT386 binary to not care about the registration key.I did buy it, but finding the key is..difficult.
 
The Elegosoft repository claims to have an import of 4.1 followed by an update to 5.1, but it is suspicious.
 
3.6 Stackx86.m3 -- no reference to  _lowbits / _highbits3.6 hand.c -- no implementation of ditto3.6 didn't offer dynamic linking, so it would have been ok.
 
The 4.1 CD includes the 3.6 source in "contrib" and some of the4.1 source in "source". That confused me at first, to have two of everything.I merely ASSUME what is what. I didn't look in detail.
 
4.1 CD hand.c -- no implementation of _lowbits / _highbits4.1 CD Stackx86.m3 -- source not available, darn it
 
4.1 in repository hand.c -- no implementation of ditto4.1 in repositoy Stackx86.m3 -- references _lowbits / _highbits
 
5.1 in repository hand.c -- implementation of ditto5.1 in repositoy Stackx86.m3 -- no change
 
The supposed 4.1 to 5.1 lack of diff (not that I understand CVS revision numbers or anything...) http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3back/src/Stackx86.m3.diff?r1=1.1;r2=1.1.1.1
 
introduction of _lowbits / _highbits in a more belieable 4.1 to 5.1 diff: http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/Csupport/Common/hand.c.diff?r1=1.1.1.1;r2=1.1.1.2
 
This is all a bit tedious so someone please double check me.
 
The 4.1 source in the repository is not self consistent.I contend it is wrong.I contend that the 4.1 Stackx86.m3 is more like the 3.6 -- no use of highbits / lowbits.
Since the symbols are not exported from the 4.1 CD m3core.dll nor are in the 4.1 CD hand.c source.
 
5.1 in the repository is self consistent, and I contend has the bug.
 
The 4.1 m3core.dll does export HiBits / LoBits -- different spelling, different casing,  and none of the .dlls in the system import them.
  Several versions have LoBits / HiBits be file-level static, further    implying they aren't used outside of hand.c.
  It is difficult for me to browse the old version of the tree however.  I guess I should try something like checkout -revision 1 and then search that locally?
  Inspection says that HiBits / LoBits went static in 2003 here:
 
 http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/Csupport/Common/hand.c
 
  and then later, I made them non-static FOR 32 BIT TARGETS, as part of merging them with  _lowbits / _highbits. This is a bit tangential, but the point is to exonerate  LoBits / HiBits of any involvement. _lowbits / _highbits are the relevant party.  They are nearly identical. See hand.c for how they relate. There is an extra  entry in one pair or the other, either at the start or the end, and one is uint and the  other ulong, when sizeof(uint) == sizeof(ulong), they share storage, my doing.  The NT386 compiler references _lowbits / _highbits. LoBits / HiBits are only used internally to hand.c.
  The gcc backend does not reference _lowbits / _highbits.
So obviously another fix is to go back to the 3.6 code and remove the symbols entirely.And make sure m3tests passes with that.I didn't look at the code yet.In general the code quality is not super high so it probably matters little.
Also obviously it would be prudent to review the code here to make sure it is correct,or to look at the relevant unit test and see if it seems comprhensive.
 
 
Thoughts?
 
 
Presume Critical Mass introduced the regression in 5.1, and give up attaining accurate 4.1 source??
I should findstr (grep) against the 4.1 cm3, but the lack of the symbols in its m3core is pretty conclusive.
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sun May 11 07:08:22 2008
From: jayk123 at hotmail.com (Jay)
Date: Sun, 11 May 2008 05:08:22 +0000
Subject: [M3devel] _lowbits / _highbits (Pixmap bug-- 4.1 vs. buggy 5.x)
Message-ID: 

Clarification: I now see that 3.6 did have these tables. They had different names. It appears they were generated for every ...I don't know, every source file or every .dll/.exe. That would work. That is similar to what we have now with my fix, though my fix statically links more than this -- everything in hand.obj.
 
D:\cm3-4.1\CONTRIB\SRC-M3\m3\m3back\src\Codex86.m3(2033):PROCEDURE init_intvar (t: T; size: ByteSize; f_lit: FLiteral; abscall: AbsCall;
D:\cm3-4.1\CONTRIB\SRC-M3\m3\m3back\src\Codex86.i3(96):TYPE IntnlVar = { Lowset_table, Highset_table };D:\cm3-4.1\CONTRIB\SRC-M3\m3\m3back\src\Codex86.m3(2077):      IntnlVar.Lowset_table =>D:\cm3-4.1\CONTRIB\SRC-M3\m3\m3back\src\Stackx86.m3(1953):                             o := ORD(IntnlVar.Lowset_table),
D:\cm3-4.1\CONTRIB\SRC-M3\m3\m3back\src\Stackx86.m3(34):        lowset_table  : MVar;D:\cm3-4.1\CONTRIB\SRC-M3\m3\m3back\src\Stackx86.m3(1298):        t.cg.tableOp(Op.oAND, stop2, stop0, 4, t.lowset_table);D:\cm3-4.1\CONTRIB\SRC-M3\m3\m3back\src\Stackx86.m3(1430):      t.cg.tableOp(Op.oMOV, t.cg.reg[maskreg], stop0, 4, t.lowset_table);D:\cm3-4.1\CONTRIB\SRC-M3\m3\m3back\src\Stackx86.m3(1443):      t.cg.tableOp(Op.oMOV, t.cg.reg[maskreg], stop0, 4, t.lowset_table);D:\cm3-4.1\CONTRIB\SRC-M3\m3\m3back\src\Stackx86.m3(1495):      intable := t.lowset_table;D:\cm3-4.1\CONTRIB\SRC-M3\m3\m3back\src\Stackx86.m3(1952):    t.lowset_table := MVar { var := t.cg.internalvar,
That at least clarifies there wasn't likely an older less efficient table-less codegen, just that the tables were gotten differently.
 
 - Jay


From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: _lowbits / _highbits (Pixmap bug-- 4.1 vs. buggy 5.x)Date: Sat, 10 May 2008 15:40:40 +0000


There is SOME evidence that this lowbits/highbitsproblem is a regression introduced in Critical Mass 5.1.And there are inconsistent data.(I believe 5.1 is the name given to the Critical Mass tree at the time it was open-sourced, vs. 4.1 which was commercially released, and some source withheld.) The source history is a little incomplete.Critical Mass 4.1 did not ship with complete source.In particular, the compiler source is missing.Libraries are there. Aside: I wonder if the 4.1 release can be made more widelyavailable, for purposes such as this. For one thing, I can contributehow to trivially patch the NT386 binary to not care about the registration key.I did buy it, but finding the key is..difficult. The Elegosoft repository claims to have an import of 4.1 followed by an update to 5.1, but it is suspicious. 3.6 Stackx86.m3 -- no reference to  _lowbits / _highbits3.6 hand.c -- no implementation of ditto3.6 didn't offer dynamic linking, so it would have been ok. The 4.1 CD includes the 3.6 source in "contrib" and some of the4.1 source in "source". That confused me at first, to have two of everything.I merely ASSUME what is what. I didn't look in detail. 4.1 CD hand.c -- no implementation of _lowbits / _highbits4.1 CD Stackx86.m3 -- source not available, darn it 4.1 in repository hand.c -- no implementation of ditto4.1 in repositoy Stackx86.m3 -- references _lowbits / _highbits 5.1 in repository hand.c -- implementation of ditto5.1 in repositoy Stackx86.m3 -- no change The supposed 4.1 to 5.1 lack of diff (not that I understand CVS revision numbers or anything...) http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3back/src/Stackx86.m3.diff?r1=1.1;r2=1.1.1.1 introduction of _lowbits / _highbits in a more belieable 4.1 to 5.1 diff: http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/Csupport/Common/hand.c.diff?r1=1.1.1.1;r2=1.1.1.2 This is all a bit tedious so someone please double check me. The 4.1 source in the repository is not self consistent.I contend it is wrong.I contend that the 4.1 Stackx86.m3 is more like the 3.6 -- no use of highbits / lowbits.Since the symbols are not exported from the 4.1 CD m3core.dll nor are in the 4.1 CD hand.c source. 5.1 in the repository is self consistent, and I contend has the bug. The 4.1 m3core.dll does export HiBits / LoBits -- different spelling, different casing,  and none of the .dlls in the system import them.  Several versions have LoBits / HiBits be file-level static, further    implying they aren't used outside of hand.c.  It is difficult for me to browse the old version of the tree however.  I guess I should try something like checkout -revision 1 and then search that locally?  Inspection says that HiBits / LoBits went static in 2003 here:  http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/Csupport/Common/hand.c   and then later, I made them non-static FOR 32 BIT TARGETS, as part of merging them with  _lowbits / _highbits. This is a bit tangential, but the point is to exonerate  LoBits / HiBits of any involvement. _lowbits / _highbits are the relevant party.  They are nearly identical. See hand.c for how they relate. There is an extra  entry in one pair or the other, either at the start or the end, and one is uint and the  other ulong, when sizeof(uint) == sizeof(ulong), they share storage, my doing.  The NT386 compiler references _lowbits / _highbits. LoBits / HiBits are only used internally to hand.c.  The gcc backend does not reference _lowbits / _highbits.So obviously another fix is to go back to the 3.6 code and remove the symbols entirely.And make sure m3tests passes with that.I didn't look at the code yet.In general the code quality is not super high so it probably matters little.Also obviously it would be prudent to review the code here to make sure it is correct,or to look at the relevant unit test and see if it seems comprhensive.  Thoughts?  Presume Critical Mass introduced the regression in 5.1, and give up attaining accurate 4.1 source??I should findstr (grep) against the 4.1 cm3, but the lack of the symbols in its m3core is pretty conclusive.  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sun May 11 07:45:31 2008
From: jayk123 at hotmail.com (Jay)
Date: Sun, 11 May 2008 05:45:31 +0000
Subject: [M3devel] RTLinker/RTArgs breaking change
Message-ID: 

RTLinker/RTArgs breaking change
I would like to cleanup my RTArgs change.
In particular, the interface among main <=> RTLinker <=> RTArgs
will change, on Windows.Posix should be unchanged.(Ok, at least Posix main <=> RTLinker unchanged, RTLinker <=> RTArgs maybe not).
One of the things holding me back is the knowledge thata current compiler must work against an old runtime,and the code did sometimes work.
However, m3-sys has no references to RTArgs,  nor to ".envp", so I am fairly confident that this can  be changed without breaking bootstrapping.
  My own near future experience implementing it should prove it one way or the other.
The change would be that for Win32 targets, MxGen.m3will always pass NIL for the envp parameter to RTLinker.InitRuntime.The parameter is ignored in current RTLinker with my recent change anyway.And then Win32/RTArgs will always just call GetEnvironmentStringsitself, ignoring RTLinker.envp.
RTLinker.envp should probably just go away, since it had no easily portable use.And then, RTLinker.InitRuntime should probably call a new functionRTArgs.SetEnv that would do nothing on Win32 and would set an internal variablein Posix/RTArgs.
That is, partly, since RTLinker.envp was fairly broken, remove it.RTArgs.GetEnv was also fairly broken, but repair it (it is already repaired).
As well, interfaces should have more functions and less data.
That is, as well, leverage that RTArgs is already platform-split, so use it  for "all" platform-specificity here. Well, as much as is reasonale.  MxGen would have a platform-switch as to what it is targeting.  My new RTLinkerC.c would go away. It could have been Modula-3 in the first place,   but it would have been platform-split.
ok?
This is really not a big deal actually.But I don't want to break bootstrapping a new compiler with an old runtime.My current fix, while a bit ugly, definitely does not break that, as  it avoided this change.
 
Another avenue is to clarify whether or not "envp" is always available from the C runtime,
such as via char** environ. I suspect it is. "But data imports are bad".
Win32 GUI and console apps could perhaps just use that.
 
Ah -- http://msdn.microsoft.com/en-us/library/aa246422(VS.60).aspx
Calling getenv("") forces environ to be initialized. Maybe reasonable.
There is an issue as to just how many copies of the environment there are..
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Tue May 13 01:35:16 2008
From: jayk123 at hotmail.com (Jay)
Date: Mon, 12 May 2008 23:35:16 +0000
Subject: [M3devel] eliminate Target.Global_handler_stack?
In-Reply-To: <20080511164932.GA4829@fuseki.my.domain>
References: 
	<20080511164932.GA4829@fuseki.my.domain> 
Message-ID: 

Target.Global_handler_stack is FALSE for targets that ever use kernel threads.Target.Global_handler_stack is TRUE for targets that never use kernel threads.
Targets that can go either way set it to FALSE.
 
When Global_handler_stack is TRUE, inline code is generated to,  I guess, manipulate a per-thread linked list of stack frames.
 
When Global_handler_stack is FALSE, function calls are generated  to do same.
 
That is, Global_handler_stack is TRUE is a little more efficient.
 
Given that Global_handler_stack is TRUE for all "recent", "active", "interesting"  targets, with the presumably temporary exception of PPC_LINUX, how about  we remove Global_handler_stack as a variable and just act as if it is always FALSE?
 
(I have some suspicion that this linked list is absent on targets with a stack walker, so it'd make no difference on them. I'll check later..NT386 ought use fs:0 but it doesn't.)
 
I figure target-specificity should be minimized.
Make it easier to bring up new targets -- not that the code isn't pretty
  well commented and easy to understand, so it's really no easier without this.
 
The counterpoints would be:  Even if it is target-specific, it does work and isn't complicated, so leave it alone.  If those old targets are alive, and lack pthreads, it is slightly faster this way.  If people want current/new targets to have a "faster" single threaded mode, this    could be part of that. Note though that single threaded apps can't/don't exist,
   unless maybe if you never heap allocate, since the heap allocator/garbage collector
   creates a thread at initialization (shouldn't it wait for a heap allocation? Maybe.
   If there really is a chance it won't occur or won't occur for a while).
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From hosking at cs.purdue.edu  Tue May 13 01:43:35 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 12 May 2008 19:43:35 -0400
Subject: [M3devel] eliminate Target.Global_handler_stack?
In-Reply-To: 
References: 
	<20080511164932.GA4829@fuseki.my.domain>
	
Message-ID: 


On May 12, 2008, at 7:35 PM, Jay wrote:

> Target.Global_handler_stack is FALSE for targets that ever use  
> kernel threads.
> Target.Global_handler_stack is TRUE for targets that never use  
> kernel threads.
> Targets that can go either way set it to FALSE.
>
>
> When Global_handler_stack is TRUE, inline code is generated to,
>   I guess, manipulate a per-thread linked list of stack frames.
>
>
> When Global_handler_stack is FALSE, function calls are generated
>   to do same.
>
>
> That is, Global_handler_stack is TRUE is a little more efficient.
>
>
> Given that Global_handler_stack is TRUE for all "recent", "active",  
> "interesting"
>   targets, with the presumably temporary exception of PPC_LINUX, how  
> about
>   we remove Global_handler_stack as a variable and just act as if it  
> is always FALSE?

Don't you mean "false" for all current targets (i.e., using threads)?

> (I have some suspicion that this linked list is absent on targets
> with a stack walker, so it'd make no difference on them. I'll check  
> later..
> NT386 ought use fs:0 but it doesn't.)

Indeed, the list is absent on such targets.

> I figure target-specificity should be minimized.
> Make it easier to bring up new targets -- not that the code isn't  
> pretty
>   well commented and easy to understand, so it's really no easier  
> without this.

I have no  objection.

> The counterpoints would be:
>   Even if it is target-specific, it does work and isn't complicated,  
> so leave it alone.
>   If those old targets are alive, and lack pthreads, it is slightly  
> faster this way.
>   If people want current/new targets to have a "faster" single  
> threaded mode, this
>    could be part of that. Note though that single threaded apps  
> can't/don't exist,
>    unless maybe if you never heap allocate, since the heap allocator/ 
> garbage collector
>    creates a thread at initialization (shouldn't it wait for a heap  
> allocation? Maybe.
>    If there really is a chance it won't occur or won't occur for a  
> while).

When does the GC currently create a thread?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Tue May 13 02:23:43 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 13 May 2008 00:23:43 +0000
Subject: [M3devel] eliminate Target.Global_handler_stack?
In-Reply-To: 
References: 
	<20080511164932.GA4829@fuseki.my.domain>
	
	
Message-ID: 

Tony, Yep, I got my true/false backwards at least once.
 
 > I have no  objection. 
 
Thanks. Expect a few deleted lines "soon".
 
 > When does the GC currently create a thread?
 
I'd have to double check. I thought it was in RTAllocator's module initialization. But maybe not.
No mystery here, just that I'm out of Modula-3 mode for a few hours.
It might be on-demand actually -- which would then have to be synchronized -- so doing it early might be preferable..er...well...actually..problem either way I now realize, depending..
 
There is this interesting useful but problematic aspect of .dlls on Windows.
.dlls have an "entry point", a "main" if you will. Usually called DllMain, but the name can be anything. It isn't exported, it's a field in the file format. The signature is
BOOLEAN DlMain(int reason, ADDRESS opaqueHandleToSelf, ADDRESS additionalBit);
 
The reasons are
  process attach, process detach, thread attach, thread detach 
  the opaqueHandleToSelf can be used for example to load "resources" from yourself
  additionalBit has a null vs. non-null meaning
    when reason == process detach, the nullness indicates if the .dll is being unloaded because the process is going away, or it is being unloaded but the process is staying around -- if the process is going away, basically nothing should be done, if the process is not going away, cleanup any process-global resources 
 
Process attach means the .dll was "just" loaded.
 
If you return false for failure from process attach, then the process will fail to launch or the LoadLibrary (dlopen) will fail, depending on if you are a static dependency of the .exe, or dynamically loaded via LoadLibrary (dlopen).
 
I believe the return values from all the other reasons are ignored.
 
There are many oddities here. Including the fact that threads can be created before the .dll loads and destroyed after it unloads, so the interface of thread attach/detach isn't what it seems -- you don't necessarily get the calls, you only get the calls for threads created/destroyed while you are already loaded (and perhaps one extra when you get loaded/unloaded?)
 
Folks who think they can do their per-thread cleanup in thread detach are sorely wrong.
What you have to do is keep all your thread-locals in a global list and free them in process detach.
Or just don't have any, that's the best policy.
 
Now, the important aspect here is that there is a lock around all DllMain calls, be they the process or thread ones.
 
This is "useful" because it means you can initialize your globals without worrying about synchronization.
Now, because of the lock, there isn't much you can do without risking deadlock.
But you would typically limit your activities to heap allocation, TlsAlloc (pthread_threadspecific_allocate_key or such), and critical section initialization. Win32 critical sections sadly require an initialization call, rather than just being initialized to all zeros. There's an API in Vista to allow static initialization.
(Cygwin's pthreads stuff also doesn't have zero initialization, but at least static).
 
On-demand initialization outside of DllMain must be synchronized, as threads can be created fairly arbitrarily early.
If you create a thread in DllMain, it essentially won't start until all the DllMains return.
It is possible though to have multiple threads running concurrently with "main".
 
And just because "you" don't create a thread in your app/.exe, doesn't mean some .dll you loaded didn't create some.
There's no such thing as a single-threaded process.
 
I suspect there is therefore a problem here in Modula-3. Or at least some double checking needed -- around the thread safety of various initialization.
 
A common pattern in Win32 is /ROUGHLY/:
 
T* g_pt; // global pointer to a T
 
T* GetTheT(void)
{
  if (g_pt != NULL)
    return g_pt;
  T* pt = new T();
  MemoryBarrier(); // ensure T's constructor finished before storing the global pointer
  if (InterlockedCompareExchangePointer(&g_pt, pt, NULL) != NULL)
   {
     // somebody else won the race
    delete pt;
   }
   return g_pt;
}
 
This way, initialization is done on-demand and thread safely.
This code assumes that race conditions will be rare vs. the expense of creating a T that is thrown away, and that creating, multiple T's in the event of a race, only to cleanup all but one right away, is ok.
 
If you must not ever create more than one T, then other code is needed.
Easiest is to initialize a critical section in DllMain and then just use that.
 
Or implement a little spin lock, assuming initialization of T is cheap.
 
In Vista there is a "once" synchronization object for handling this.
It is very disappointing that this wasn't introduced 10+ years ago.
As well as statically initializable locks and reader/writer locks.
 
I keep tending to think that Modula-3 module intializers have this same lock, at least on Windows.
But that is definitely NOT necessariiy true, at least in the face of static linking, and probably even with dynamic linking, since Modula-3 implements this stuff itself.
 
I'll have to review the code. Maybe it is just fine already.
 
If it isn't, well, there are a few easy solutions.
As well, this could be a problem on all platforms.
So it might make sense for the runtime to recognize when it is calling module initializers and endeavor to "not start" any threads while they are running.
 
Corrallary, on Win32, and in this scheme, that if you create  a thread in DllMain/thread initializer and then wait for it to make progress, you deadlock.
 
Gotta run,
 - Jay


CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] eliminate Target.Global_handler_stack?Date: Mon, 12 May 2008 19:43:35 -0400

On May 12, 2008, at 7:35 PM, Jay wrote:

Target.Global_handler_stack is FALSE for targets that ever use kernel threads.Target.Global_handler_stack is TRUE for targets that never use kernel threads.Targets that can go either way set it to FALSE. When Global_handler_stack is TRUE, inline code is generated to,  I guess, manipulate a per-thread linked list of stack frames. When Global_handler_stack is FALSE, function calls are generated  to do same. That is, Global_handler_stack is TRUE is a little more efficient. Given that Global_handler_stack is TRUE for all "recent", "active", "interesting"  targets, with the presumably temporary exception of PPC_LINUX, how about  we remove Global_handler_stack as a variable and just act as if it is always FALSE?
Don't you mean "false" for all current targets (i.e., using threads)?


(I have some suspicion that this linked list is absent on targets with a stack walker, so it'd make no difference on them. I'll check later..NT386 ought use fs:0 but it doesn't.)

Indeed, the list is absent on such targets.

I figure target-specificity should be minimized.Make it easier to bring up new targets -- not that the code isn't pretty  well commented and easy to understand, so it's really no easier without this.
I have no  objection. 


The counterpoints would be:  Even if it is target-specific, it does work and isn't complicated, so leave it alone.  If those old targets are alive, and lack pthreads, it is slightly faster this way.  If people want current/new targets to have a "faster" single threaded mode, this    could be part of that. Note though that single threaded apps can't/don't exist,   unless maybe if you never heap allocate, since the heap allocator/garbage collector   creates a thread at initialization (shouldn't it wait for a heap allocation? Maybe.   If there really is a chance it won't occur or won't occur for a while).

When does the GC currently create a thread?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Tue May 13 03:09:12 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 13 May 2008 01:09:12 +0000
Subject: [M3devel] FW:  eliminate Target.Global_handler_stack?
In-Reply-To: 
References: 
	<20080511164932.GA4829@fuseki.my.domain>
	
	 
Message-ID: 

 truncated yet again..
Olaf is there anything in any mail log on your end?
 
 - Jay


From: jayk123 at hotmail.comTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] eliminate Target.Global_handler_stack?Date: Tue, 13 May 2008 00:23:43 +0000


Tony, Yep, I got my true/false backwards at least once.  > I have no  objection.  Thanks. Expect a few deleted lines "soon". 
 > When does the GC currently create a thread? I'd have to double check. I thought it was in RTAllocator's module initialization. But maybe not.No mystery here, just that I'm out of Modula-3 mode for a few hours.It might be on-demand actually -- which would then have to be synchronized -- so doing it early might be preferable..er...well...actually..problem either way I now realize, depending.. There is this interesting useful but problematic aspect of .dlls on Windows..dlls have an "entry point", a "main" if you will. Usually called DllMain, but the name can be anything. It isn't exported, it's a field in the file format. The signature isBOOLEAN DlMain(int reason, ADDRESS opaqueHandleToSelf, ADDRESS additionalBit); The reasons are  process attach, process detach, thread attach, thread detach   the opaqueHandleToSelf can be used for example to load "resources" from yourself  additionalBit has a null vs. non-null meaning    when reason == process detach, the nullness indicates if the .dll is being unloaded because the process is going away, or it is being unloaded but the process is staying around -- if the process is going away, basically nothing should be done, if the process is not going away, cleanup any process-global resources  Process attach means the .dll was "just" loaded. If you return false for failure from process attach, then the process will fail to launch or the LoadLibrary (dlopen) will fail, depending on if you are a static dependency of the .exe, or dynamically loaded via LoadLibrary (dlopen). I believe the return values from all the other reasons are ignored. There are many oddities here. Including the fact that threads can be created before the .dll loads and destroyed after it unloads, so the interface of thread attach/detach isn't what it seems -- you don't necessarily get the calls, you only get the calls for threads created/destroyed while you are already loaded (and perhaps one extra when you get loaded/unloaded?) Folks who think they can do their per-thread cleanup in thread detach are sorely wrong.What you have to do is keep all your thread-locals in a global list and free them in process detach.Or just don't have any, that's the best policy. Now, the important aspect here is that there is a lock around all DllMain calls, be they the process or thread ones. This is "useful" because it means you can initialize your globals without worrying about synchronization.Now, because of the lock, there isn't much you can do without risking deadlock.But you would typically limit your activities to heap allocation, TlsAlloc (pthread_threadspecific_allocate_key or such), and critical section initialization. Win32 critical sections sadly require an initialization call, rather than just being initialized to all zeros. There's an API in Vista to allow static initialization.(Cygwin's pthreads stuff also doesn't have zero initialization, but at least static). On-demand initialization outside of DllMain must be synchronized, as threads can be created fairly arbitrarily early.If you create a thread in DllMain, it essentially won't start until all the DllMains return.It is possible though to have multiple threads running concurrently with "main". And just because "you" don't create a thread in your app/.exe, doesn't mean some .dll you loaded didn't create some.There's no such thing as a single-threaded process. I suspect there is therefore a problem here in Modula-3. Or at least some double checking needed -- around the thread safety of various initialization. A common pattern in Win32 is /ROUGHLY/: T* g_pt; // global pointer to a T T* GetTheT(void){  if (g_pt != NULL)    return g_pt;  T* pt = new T();  MemoryBarrier(); // ensure T's constructor finished before storing the global pointer  if (InterlockedCompareExchangePointer(&g_pt, pt, NULL) != NULL)   {     // somebody else won the race    delete pt;   }   return g_pt;} This way, initialization is done on-demand and thread safely.This code assumes that race conditions will be rare vs. the expense of creating a T that is thrown away, and that creating, multiple T's in the event of a race, only to cleanup all but one right away, is ok. If you must not ever create more than one T, then other code is needed.Easiest is to initialize a critical section in DllMain and then just use that. Or implement a little spin lock, assuming initialization of T is cheap. In Vista there is a "once" synchronization object for handling this.It is very disappointing that this wasn't introduced 10+ years ago.As well as statically initializable locks and reader/writer locks. I keep tending to think that Modula-3 module intializers have this same lock, at least on Windows.But that is definitely NOT necessariiy true, at least in the face of static linking, and probably even with dynamic linking, since Modula-3 implements this stuff itself. I'll have to review the code. Maybe it is just fine already. If it isn't, well, there are a few easy solutions.As well, this could be a problem on all platforms.So it might make sense for the runtime to recognize when it is calling module initializers and endeavor to "not start" any threads while they are running. Corrallary, on Win32, and in this scheme, that if you create  a thread in DllMain/thread initializer and then wait for it to make progress, you deadlock. Gotta run, - Jay


CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] eliminate Target.Global_handler_stack?Date: Mon, 12 May 2008 19:43:35 -0400

On May 12, 2008, at 7:35 PM, Jay wrote:

Target.Global_handler_stack is FALSE for targets that ever use kernel threads.Target.Global_handler_stack is TRUE for targets that never use kernel threads.Targets that can go either way set it to FALSE. When Global_handler_stack is TRUE, inline code is generated to,  I guess, manipulate a per-thread linked list of stack frames. When Global_handler_stack is FALSE, function calls are generated  to do same. That is, Global_handler_stack is TRUE is a little more efficient. Given that Global_handler_stack is TRUE for all "recent", "active", "interesting"  targets, with the presumably temporary exception of PPC_LINUX, how about  we remove Global_handler_stack as a variable and just act as if it is always FALSE?
Don't you mean "false" for all current targets (i.e., using threads)?


(I have some suspicion that this linked list is absent on targets with a stack walker, so it'd make no difference on them. I'll check later..NT386 ought use fs:0 but it doesn't.)

Indeed, the list is absent on such targets.

I figure target-specificity should be minimized.Make it easier to bring up new targets -- not that the code isn't pretty  well commented and easy to understand, so it's really no easier without this.
I have no  objection. 


The counterpoints would be:  Even if it is target-specific, it does work and isn't complicated, so leave it alone.  If those old targets are alive, and lack pthreads, it is slightly faster this way.  If people want current/new targets to have a "faster" single threaded mode, this    could be part of that. Note though that single threaded apps can't/don't exist,   unless maybe if you never heap allocate, since the heap allocator/garbage collector   creates a thread at initialization (shouldn't it wait for a heap allocation? Maybe.   If there really is a chance it won't occur or won't occur for a while).

When does the GC currently create a thread?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Tue May 13 15:52:08 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 13 May 2008 13:52:08 +0000
Subject: [M3devel] open vs. fixed arrays?
Message-ID: 




I'm being a bit lazy here. I could experiment more with the compiler and check the green book.  The compiler does not correctly implement:    VAR a : ARRAY [0..0] OF CHAR := ARRAY OF CHAR {'a'};  at least for reasons of alignment.  What is this code supposed to mean?  Is ARRAY OF CHAR {'a'} a constant fixed array with a deduced size of 1?Or a constant open array with a deduced size of 1?I believe it is supposed to be a constant open array.  And then, what is the difference?What are the visible differences?  Between  VAR a : ARRAY [0..0] OF CHAR := ARRAY OF CHAR {'a'};and  VAR a : ARRAY [0..0] OF CHAR := ARRAY [0..0] OF CHAR {'a'}; Can I act on "a" different at runtime between the two?Given that its static type is the same, I doubt it. But I haven't really thought about it.  If there is no visible difference, should the compiler implement it as the second -- probably saving a tiny bit of space.  And if not, is it supposed to generate an open array, and an initializer to do the copy?  A constant likeCONST a = ARRAY OF CHAR{'a'}  is an open array I believe, with visible differences, I think, not sure,so in the unlikely even that a "bigger" change is ok here, it has to be careful of this and other scenarios.  Really, I'm just being a bit slow. I bet these should remain open arrays but somewhere the compiler gets confused and computes the alignment and perhaps size as a fixed array, leading to assertion failures in the compiler, depending on the actual sizes, e.g.:  MODULE Main;<*UNUSED*> VAR a : ARRAY [0..0] OF CHAR := ARRAY OF CHAR {'a'};<*UNUSED*> VAR b : ARRAY OF CHAR := ARRAY OF CHAR {'a'};BEGINEND.  fails an assertion in the compiler, depending on the target -- but I expect all x86/AMD64 targets. Thanks,  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From hosking at cs.purdue.edu  Tue May 13 17:28:24 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 13 May 2008 11:28:24 -0400
Subject: [M3devel] open vs. fixed arrays?
In-Reply-To: 
References: 
Message-ID: 


On May 13, 2008, at 9:52 AM, Jay wrote:

> I'm being a bit lazy here. I could experiment more with the compiler  
> and check the green book.
>
>
> The compiler does not correctly implement:
>
>
>
>  VAR a : ARRAY [0..0] OF CHAR := ARRAY OF CHAR {'a'};
>
> at least for reasons of alignment.
>
>
> What is this code supposed to mean?
It should assign the elements of the open array to those of the fixed  
array.
>
>
>
> Is ARRAY OF CHAR {'a'} a constant fixed array with a deduced size of  
> 1?

No, it is open.

>
> Or a constant open array with a deduced size of 1?
No.
> I believe it is supposed to be a constant open array.
Yes.

>
>
> And then, what is the difference?
> What are the visible differences?
>
>
> Between
>
>  VAR a : ARRAY [0..0] OF CHAR := ARRAY OF CHAR {'a'};
> and
>   VAR a : ARRAY [0..0] OF CHAR := ARRAY [0..0] OF CHAR {'a'};
>
> Can I act on "a" different at runtime between the two?
> Given that its static type is the same, I doubt it. But I haven't  
> really thought about it.
>
>
> If there is no visible difference, should the compiler implement it  
> as the second -- probably saving a tiny bit of space.
>
>
> And if not, is it supposed to generate an open array, and an  
> initializer to do the copy?
Probably should.

>
>
>
> A constant like
> CONST a = ARRAY OF CHAR{'a'}
>
>
> is an open array I believe, with visible differences, I think, not  
> sure,
> so in the unlikely even that a "bigger" change is ok here, it has to  
> be careful of this and other scenarios.
>
>
> Really, I'm just being a bit slow. I bet these should remain open  
> arrays but somewhere the compiler gets confused and computes the  
> alignment and perhaps size as a fixed array, leading to assertion  
> failures in the compiler, depending on the actual sizes, e.g.:
>
>
> MODULE Main;
> <*UNUSED*> VAR a : ARRAY [0..0] OF CHAR := ARRAY OF CHAR {'a'};
> <*UNUSED*> VAR b : ARRAY OF CHAR := ARRAY OF CHAR {'a'};
> BEGIN
> END.
>
>
> fails an assertion in the compiler, depending on the target -- but I  
> expect all x86/AMD64 targets.
>
> Thanks,
>  - Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Wed May 14 19:18:54 2008
From: jayk123 at hotmail.com (Jay)
Date: Wed, 14 May 2008 17:18:54 +0000
Subject: [M3devel] _lowbits / _highbits (Pixmap bug-- 4.1 vs. buggy 5.x)
In-Reply-To: 
References: 
Message-ID: 

1) Just fyi, NT386GNU didn't build with my fix, so it is disabled there only, and the bug could very well be present there.
Er, then again, this stuff works differently for the gcc backend, so I don't know, I'll have to look, and run the tests, not today.
Which reminds me also, these symbols should be static hand.c, except for NT386 -- the source can't tell, so it'll have to be a define from the m3makefile.
 
2) Can anyone confirm my history and the missing source?
ie: Confirm that what is marked as 4.1 and 5.1 in CVS really is 4.1 and 5.1? I don't think 4.1 is accurately marked.
In particular, I don't think the 4.1 Stackx86.m3  is what 4.1 actually shipped.
 
3) Or confirm my analysis that leads to the "accusation"? It was tedious.
 
 - Jay


From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Sat, 10 May 2008 15:40:40 +0000Subject: [M3devel] _lowbits / _highbits (Pixmap bug-- 4.1 vs. buggy 5.x)


There is SOME evidence that this lowbits/highbitsproblem is a regression introduced in Critical Mass 5.1.And there are inconsistent data.(I believe 5.1 is the name given to the Critical Mass tree at the time it was open-sourced, vs. 4.1 which was commercially released, and some source withheld.) The source history is a little incomplete.Critical Mass 4.1 did not ship with complete source.In particular, the compiler source is missing.Libraries are there. Aside: I wonder if the 4.1 release can be made more widelyavailable, for purposes such as this. For one thing, I can contributehow to trivially patch the NT386 binary to not care about the registration key.I did buy it, but finding the key is..difficult. The Elegosoft repository claims to have an import of 4.1 followed by an update to 5.1, but it is suspicious. 3.6 Stackx86.m3 -- no reference to  _lowbits / _highbits3.6 hand.c -- no implementation of ditto3.6 didn't offer dynamic linking, so it would have been ok. The 4.1 CD includes the 3.6 source in "contrib" and some of the4.1 source in "source". That confused me at first, to have two of everything.I merely ASSUME what is what. I didn't look in detail. 4.1 CD hand.c -- no implementation of _lowbits / _highbits4.1 CD Stackx86.m3 -- source not available, darn it 4.1 in repository hand.c -- no implementation of ditto4.1 in repositoy Stackx86.m3 -- references _lowbits / _highbits 5.1 in repository hand.c -- implementation of ditto5.1 in repositoy Stackx86.m3 -- no change The supposed 4.1 to 5.1 lack of diff (not that I understand CVS revision numbers or anything...) http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3back/src/Stackx86.m3.diff?r1=1.1;r2=1.1.1.1 introduction of _lowbits / _highbits in a more belieable 4.1 to 5.1 diff: http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/Csupport/Common/hand.c.diff?r1=1.1.1.1;r2=1.1.1.2 This is all a bit tedious so someone please double check me. The 4.1 source in the repository is not self consistent.I contend it is wrong.I contend that the 4.1 Stackx86.m3 is more like the 3.6 -- no use of highbits / lowbits.Since the symbols are not exported from the 4.1 CD m3core.dll nor are in the 4.1 CD hand.c source. 5.1 in the repository is self consistent, and I contend has the bug. The 4.1 m3core.dll does export HiBits / LoBits -- different spelling, different casing,  and none of the .dlls in the system import them.  Several versions have LoBits / HiBits be file-level static, further    implying they aren't used outside of hand.c.  It is difficult for me to browse the old version of the tree however.  I guess I should try something like checkout -revision 1 and then search that locally?  Inspection says that HiBits / LoBits went static in 2003 here:  http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/Csupport/Common/hand.c   and then later, I made them non-static FOR 32 BIT TARGETS, as part of merging them with  _lowbits / _highbits. This is a bit tangential, but the point is to exonerate  LoBits / HiBits of any involvement. _lowbits / _highbits are the relevant party.  They are nearly identical. See hand.c for how they relate. There is an extra  entry in one pair or the other, either at the start or the end, and one is uint and the  other ulong, when sizeof(uint) == sizeof(ulong), they share storage, my doing.  The NT386 compiler references _lowbits / _highbits. LoBits / HiBits are only used internally to hand.c.  The gcc backend does not reference _lowbits / _highbits.So obviously another fix is to go back to the 3.6 code and remove the symbols entirely.And make sure m3tests passes with that.I didn't look at the code yet.In general the code quality is not super high so it probably matters little.Also obviously it would be prudent to review the code here to make sure it is correct,or to look at the relevant unit test and see if it seems comprhensive.  Thoughts?  Presume Critical Mass introduced the regression in 5.1, and give up attaining accurate 4.1 source??I should findstr (grep) against the 4.1 cm3, but the lack of the symbols in its m3core is pretty conclusive.  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Wed May 14 19:25:38 2008
From: jayk123 at hotmail.com (Jay)
Date: Wed, 14 May 2008 17:25:38 +0000
Subject: [M3devel] which platforms?
In-Reply-To: 
References: 
Message-ID: 

What do people run?In particular: NetBSD? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN? I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM_WINCE? AMD64_NT?
 
Just curious, I'll probably bring up whatever I can, it's fun, and yes, get back and fix AMD64_LINUX to have
garbage collection, NT386GNU and NT386 tests, cross-platform sets, setup some Tinderboxes, etc...
 
(AMD64_NT: the gcc available for this includes a bunch of patches, so I'm inclined to either wait for them to go upstream,
or seek an alternate route such as "port" the in-proc backend, llvm, generate C, or maybe write an interpreter for the IL;
and "porting" the backend is probably best preceded by a) x86 LONGINT support b) other x86 targets "for practise", at least one,
though regarding .obj file formats, that would be tangential.)
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Wed May 14 19:46:15 2008
From: jayk123 at hotmail.com (Jay)
Date: Wed, 14 May 2008 17:46:15 +0000
Subject: [M3devel] SPARC32_LINUX
In-Reply-To: 
References: 
Message-ID: 





  I was having some hardware/network problem and as an indirect result, am not running Linux/sparc for a bit.         I was going to make distributions and bring up SPARC64_LINUX, but it'll wait some.          If anyone can help me a bit with Sun-specific problems, please ping me privately.       In the meantime, there is:       http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-base-POSIX-SPARC32_LINUX-1.tar.bz2       It should be called "boot", but something didn't like that.       roughly:       wget http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-base-POSIX-SPARC32_LINUX-1.tar.bz2    tar xf cm3-base-POSIX-SPARC32_LINUX-1.tar.bz2    cd cm3-boot-POSIX-SPARC32_LINUX-1    . ./1.sh    mkdir -p /cm3/bin   cp exe/cm3 /cm3/bin   export PATH=/cm3/bin:$PATH   cd $CVSROOT/scripts/python      ./upgrade.py    and then optionally ./make-dist.py    
 
or, I'm not sure upgrade ships/installs/copies cm3cg, so:
  cd $CVSROOT/scripts/python      ./do-pkg.py m3cc 
  cp ../../m3-sys/m3cc/SPARC32_LINUX/cm3cg /cm3/bin    OMIT_GCC=yes ./upgrade.py         SHOULD work. /usr/local/cm3 should work, but I find that rather long.Actually I never built beyond "front".   And dynamic linking and garbage collection are both off, for now.      Then again, I suspect nobody runs Linux on SPARC, esp. not here.   It was educational though to bring up a platform on which I couldnot rely on an existing ability to run cm3.
I'll TRY to get back and tie up a bunch of loose ends, there are a lot now, I know..
    - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From hosking at cs.purdue.edu  Thu May 15 17:44:21 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 15 May 2008 11:44:21 -0400
Subject: [M3devel] which platforms?
In-Reply-To: 
References: 
	
Message-ID: <6AF85D14-364B-4155-A186-840119342DF7@cs.purdue.edu>


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



On May 14, 2008, at 1:25 PM, Jay wrote:

> What do people run?
> In particular: NetBSD? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN?  
> I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM_WINCE? AMD64_NT?
>
> Just curious, I'll probably bring up whatever I can, it's fun, and  
> yes, get back and fix AMD64_LINUX to have
> garbage collection, NT386GNU and NT386 tests, cross-platform sets,  
> setup some Tinderboxes, etc...
>
> (AMD64_NT: the gcc available for this includes a bunch of patches,  
> so I'm inclined to either wait for them to go upstream,
> or seek an alternate route such as "port" the in-proc backend, llvm,  
> generate C, or maybe write an interpreter for the IL;
> and "porting" the backend is probably best preceded by a) x86  
> LONGINT support b) other x86 targets "for practise", at least one,
> though regarding .obj file formats, that would be tangential.)
>
>  - Jay
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From hosking at cs.purdue.edu  Thu May 15 17:47:41 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 15 May 2008 11:47:41 -0400
Subject: [M3devel] which platforms?
In-Reply-To: 
References: 
	
Message-ID: <948C63CA-8763-46AE-9FDB-54DAF01CC28D@cs.purdue.edu>

SOLgnu
PPC_DARWIN
I386_DARWIN
AMD64_DARWIN
LINUXLIBC6
I'd like AMD64_LINUX, SPARC64_SOLARISN but no time right now to devote  
to them.

On May 14, 2008, at 1:25 PM, Jay wrote:

> What do people run?
> In particular: NetBSD? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN?  
> I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM_WINCE? AMD64_NT?
>
> Just curious, I'll probably bring up whatever I can, it's fun, and  
> yes, get back and fix AMD64_LINUX to have
> garbage collection, NT386GNU and NT386 tests, cross-platform sets,  
> setup some Tinderboxes, etc...
>
> (AMD64_NT: the gcc available for this includes a bunch of patches,  
> so I'm inclined to either wait for them to go upstream,
> or seek an alternate route such as "port" the in-proc backend, llvm,  
> generate C, or maybe write an interpreter for the IL;
> and "porting" the backend is probably best preceded by a) x86  
> LONGINT support b) other x86 targets "for practise", at least one,
> though regarding .obj file formats, that would be tangential.)
>
>  - Jay
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From darko at darko.org  Thu May 15 21:50:31 2008
From: darko at darko.org (Darko)
Date: Thu, 15 May 2008 21:50:31 +0200
Subject: [M3devel] which platforms?
In-Reply-To: 
References: 
	
Message-ID: <4599968C-BCFA-4A5E-B50A-7E1A589B7C30@darko.org>

I'd really like to see some ARM backends in particular ARM_DARWIN  
(iPod Touch, iPhone), ARM_NOKIA (on their Open C API) and ARM_WINCE.  
This would have CM3 the gamut from servers to small handheld devices.


On 14/05/2008, at 7:25 PM, Jay wrote:

> What do people run?
> In particular: NetBSD? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN?  
> I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM_WINCE? AMD64_NT?
>
> Just curious, I'll probably bring up whatever I can, it's fun, and  
> yes, get back and fix AMD64_LINUX to have
> garbage collection, NT386GNU and NT386 tests, cross-platform sets,  
> setup some Tinderboxes, etc...
>
> (AMD64_NT: the gcc available for this includes a bunch of patches,  
> so I'm inclined to either wait for them to go upstream,
> or seek an alternate route such as "port" the in-proc backend, llvm,  
> generate C, or maybe write an interpreter for the IL;
> and "porting" the backend is probably best preceded by a) x86  
> LONGINT support b) other x86 targets "for practise", at least one,
> though regarding .obj file formats, that would be tangential.)
>
>  - Jay
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Thu May 15 22:19:16 2008
From: jayk123 at hotmail.com (Jay)
Date: Thu, 15 May 2008 20:19:16 +0000
Subject: [M3devel] which platforms?
In-Reply-To: <4599968C-BCFA-4A5E-B50A-7E1A589B7C30@darko.org>
References: 
	
	<4599968C-BCFA-4A5E-B50A-7E1A589B7C30@darko.org>
Message-ID: 

Oh -- iPod Touch -- iPhone hardware/software without a service plan. Clever. :)
I don't know about Nokia but definitely CE and somewhat iPhone "intrigue" me (as in, I never use this stuff, but a port sounds interesting).
I'm hoping CE can be done with free beer emulators but I don't have anything up and running dev tool wise there, other than older command line compilers (for a bunch of CE -- arm, mips, powepc, sh, x86). I'm not confident gcc will move so easily to new Windows platforms, without significant patches, so C or LLVM might be good.
Yeah I wasn't sure ARM_IPHONE or ARM_DARWIN. :)
I'd still like to call it ARCH_MACOSX or ARCH_MACX oh well too late.
 
None of these things have X servers, right?
And gui is hard anyway on small screens, "less portable".
Port to Qt??
I'm not going there any time soon, very little familiarity with either Trestle or the underlying systems..
Headless servers and command line apps on phones for now. :)
 
 - Jay
 



CC: m3devel at elegosoft.comFrom: darko at darko.orgTo: jayk123 at hotmail.comSubject: Re: [M3devel] which platforms?Date: Thu, 15 May 2008 21:50:31 +0200

I'd really like to see some ARM backends in particular ARM_DARWIN (iPod Touch, iPhone), ARM_NOKIA (on their Open C API) and ARM_WINCE. This would have CM3 the gamut from servers to small handheld devices.


On 14/05/2008, at 7:25 PM, Jay wrote:

What do people run?In particular: NetBSD? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN? I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM_WINCE? AMD64_NT? Just curious, I'll probably bring up whatever I can, it's fun, and yes, get back and fix AMD64_LINUX to havegarbage collection, NT386GNU and NT386 tests, cross-platform sets, setup some Tinderboxes, etc... (AMD64_NT: the gcc available for this includes a bunch of patches, so I'm inclined to either wait for them to go upstream,or seek an alternate route such as "port" the in-proc backend, llvm, generate C, or maybe write an interpreter for the IL;and "porting" the backend is probably best preceded by a) x86 LONGINT support b) other x86 targets "for practise", at least one,though regarding .obj file formats, that would be tangential.)  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From darko at darko.org  Thu May 15 22:55:58 2008
From: darko at darko.org (Darko)
Date: Thu, 15 May 2008 22:55:58 +0200
Subject: [M3devel] which platforms?
In-Reply-To: 
References: 
	
	<4599968C-BCFA-4A5E-B50A-7E1A589B7C30@darko.org>
	
Message-ID: <21F3FBDA-3DE6-4DA0-951A-E5F4BE999F52@darko.org>

I haven't seen X for any of them but I guess its not beyond the realm  
of possibility. I'm mostly interested in native user interfaces and  
porting the native APIs for M3. Darwin is the name of lower levels of  
the OS of the Mac and iPhone and is open source, so its appropriate.

Apple provide a GCC for the ARM and Darwin. There is GCC for ARM under  
WinCE platforms. I would have though the issues are mainly with the M3  
runtime on these platforms.



On 15/05/2008, at 10:19 PM, Jay wrote:

> Oh -- iPod Touch -- iPhone hardware/software without a service plan.  
> Clever. :)
> I don't know about Nokia but definitely CE and somewhat iPhone  
> "intrigue" me (as in, I never use this stuff, but a port sounds  
> interesting).
> I'm hoping CE can be done with free beer emulators but I don't have  
> anything up and running dev tool wise there, other than older  
> command line compilers (for a bunch of CE -- arm, mips, powepc, sh,  
> x86). I'm not confident gcc will move so easily to new Windows  
> platforms, without significant patches, so C or LLVM might be good.
> Yeah I wasn't sure ARM_IPHONE or ARM_DARWIN. :)
> I'd still like to call it ARCH_MACOSX or ARCH_MACX oh well too late.
>
> None of these things have X servers, right?
> And gui is hard anyway on small screens, "less portable".
> Port to Qt??
> I'm not going there any time soon, very little familiarity with  
> either Trestle or the underlying systems..
> Headless servers and command line apps on phones for now. :)
>
>  - Jay
>
>
>
> CC: m3devel at elegosoft.com
> From: darko at darko.org
> To: jayk123 at hotmail.com
> Subject: Re: [M3devel] which platforms?
> Date: Thu, 15 May 2008 21:50:31 +0200
>
>
> I'd really like to see some ARM backends in particular ARM_DARWIN  
> (iPod Touch, iPhone), ARM_NOKIA (on their Open C API) and ARM_WINCE.  
> This would have CM3 the gamut from servers to small handheld devices.
>
>
> On 14/05/2008, at 7:25 PM, Jay wrote:
>
> What do people run?
> In particular: NetBSD? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN?  
> I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM_WINCE? AMD64_NT?
>
> Just curious, I'll probably bring up whatever I can, it's fun, and  
> yes, get back and fix AMD64_LINUX to have
> garbage collection, NT386GNU and NT386 tests, cross-platform sets,  
> setup some Tinderboxes, etc...
>
> (AMD64_NT: the gcc available for this includes a bunch of patches,  
> so I'm inclined to either wait for them to go upstream,
> or seek an alternate route such as "port" the in-proc backend, llvm,  
> generate C, or maybe write an interpreter for the IL;
> and "porting" the backend is probably best preceded by a) x86  
> LONGINT support b) other x86 targets "for practise", at least one,
> though regarding .obj file formats, that would be tangential.)
>
>  - Jay
>
>
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mika at async.caltech.edu  Thu May 15 23:30:36 2008
From: mika at async.caltech.edu (Mika Nystrom)
Date: Thu, 15 May 2008 14:30:36 -0700
Subject: [M3devel] which platforms?
In-Reply-To: Your message of "Thu, 15 May 2008 11:47:41 EDT."
	<948C63CA-8763-46AE-9FDB-54DAF01CC28D@cs.purdue.edu> 
Message-ID: <200805152130.m4FLUa9B060478@camembert.async.caltech.edu>

here it is:

FreeBSD4
PPC_DARWIN
NT386GNU
LINUXLIBC6

I386_DARWIN coming soon

Tony Hosking writes:
>
>--Apple-Mail-4-631028010
>Content-Type: text/plain;
>	charset=US-ASCII;
>	format=flowed;
>	delsp=yes
>Content-Transfer-Encoding: 7bit
>
>SOLgnu
>PPC_DARWIN
>I386_DARWIN
>AMD64_DARWIN
>LINUXLIBC6
>I'd like AMD64_LINUX, SPARC64_SOLARISN but no time right now to devote  
>to them.
>
>On May 14, 2008, at 1:25 PM, Jay wrote:
>
>> What do people run?
>> In particular: NetBSD? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN?  
>> I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM_WINCE? AMD64_NT?
>>
>> Just curious, I'll probably bring up whatever I can, it's fun, and  
>> yes, get back and fix AMD64_LINUX to have
>> garbage collection, NT386GNU and NT386 tests, cross-platform sets,  
>> setup some Tinderboxes, etc...
>>
>> (AMD64_NT: the gcc available for this includes a bunch of patches,  
>> so I'm inclined to either wait for them to go upstream,
>> or seek an alternate route such as "port" the in-proc backend, llvm,  
>> generate C, or maybe write an interpreter for the IL;
>> and "porting" the backend is probably best preceded by a) x86  
>> LONGINT support b) other x86 targets "for practise", at least one,
>> though regarding .obj file formats, that would be tangential.)
>>
>>  - Jay
>>
>>
>>
>>
>
>
>--Apple-Mail-4-631028010
>Content-Type: text/html;
>	charset=US-ASCII
>Content-Transfer-Encoding: quoted-printable
>
>-webkit-line-break: after-white-space; ">
apple-content-edited=3D"true">style=3D"border-collapse: separate; border-spacing: 0px 0px; color: =
>rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
>normal; font-variant: normal; font-weight: normal; letter-spacing: =
>normal; line-height: normal; text-align: auto; =
>-khtml-text-decorations-in-effect: none; text-indent: 0px; =
>-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; ">
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
>-khtml-line-break: after-white-space; ">style=3D"border-collapse: separate; border-spacing: 0px 0px; color: =
>rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
>normal; font-variant: normal; font-weight: normal; letter-spacing: =
>normal; line-height: normal; text-align: auto; =
>-khtml-text-decorations-in-effect: none; text-indent: 0px; =
>-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; =
>">SOLgnu
-khtml-nbsp-mode: space; -khtml-line-break: after-white-space; =
>">PPC_DARWIN
space; -khtml-line-break: after-white-space; ">I386_DARWIN
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
>-khtml-line-break: after-white-space; ">AMD64_DARWIN
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
>-khtml-line-break: after-white-space; ">LINUXLIBC6
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
>-khtml-line-break: after-white-space; ">I'd like AMD64_LINUX, class=3D"Apple-style-span" style=3D"font-family: Tahoma; font-size: =
>13px; ">SPARC64_SOLARISN but no time right now to devote to =
>them.

On May 14, 2008, at 1:25 =
>PM, Jay wrote:

type=3D"cite">separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; orphans: 2; text-align: =
>auto; text-indent: 0px; text-transform: none; white-space: normal; =
>widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
>-webkit-border-vertical-spacing: 0px; =
>-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
>auto; -webkit-text-stroke-width: 0; ">
style=3D"font-size: 10pt; font-family: Tahoma; ">What do people =
>run?
In particular: NetBSD? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN? =
>I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM_WINCE? =
>AMD64_NT?
 
Just curious, I'll probably bring up whatever I =
>can, it's fun, and yes, get back and fix AMD64_LINUX to have
garbage =
>collection, NT386GNU and NT386 tests, cross-platform sets, setup =
>some Tinderboxes, etc...
 
(AMD64_NT: the gcc available for =
>this includes a bunch of patches, so I'm inclined to either wait for =
>them to go upstream,
or seek an alternate route such as "port" the =
>in-proc backend, llvm, generate C, or maybe write an interpreter for the =
>IL;
and "porting" the backend is probably best preceded by a) x86 =
>LONGINT support b) other x86 targets "for practise", at least =
>one,
though regarding .obj file formats, that would be =
>tangential.)
 
 - =
>Jay





=
>
>--Apple-Mail-4-631028010--


From jayk123 at hotmail.com  Fri May 16 00:43:30 2008
From: jayk123 at hotmail.com (Jay)
Date: Thu, 15 May 2008 22:43:30 +0000
Subject: [M3devel] which platforms? and questions about FreeBSD
 versioning
In-Reply-To: <200805152130.m4FLUa9B060478@camembert.async.caltech.edu>
References: Your message of "Thu, 15 May 2008 11:47:41 EDT."
	<948C63CA-8763-46AE-9FDB-54DAF01CC28D@cs.purdue.edu>  
	<200805152130.m4FLUa9B060478@camembert.async.caltech.edu>
Message-ID: 

Mika, ok, this is tangential: Have you tried the current NT386GNU cm3?
 
I meant, more about what "operating systems" that Modula-3 does not support do people here use, would like to see Modula-3 on. Or maybe I meant both.
 
Speaking of the "4" in FreeBSD4:
 
Has FreeBSD, and the other BSDs, really broken backward compat?
They really change interfaces a lot such that binaries built with current headers/libs won't run on older versions?
And there isn't an easy way on current platforms to build something using older tools to run on older and newer platforms?
Look at Windows for example. If you call a "new" function directly, you will fail to load on older platforms. So either don't call them, or use LoadLibrary/GetProcAddress. Structures almost never change size, though there is some screwiness there, stuff like:
 
struct FOO {  size_t Size;
  int Field1;
#if VERSION > 1234
  int Field2;
#endif
};
 
I think it should be more like:
 
struct FOO {  size_t Size;
  int Field1;
#if VERSION > 1234
  int Field2;
#endif
};
 
struct FOO_V1{  size_t Size;
  int Field1;
};
 
struct FOO_V2 {  size_t Size;
  int Field1;
  int Field2;
};
 
#if VERSION > 1234
typedef FOO_V2 FOO;
#else
typedef FOO_V1 FOO;
#endif
 
I understand that binaries built on the older platform will continue to work on the newer platform.
That is one thing.
But it is also useful to be able to build binaries on the newer platform that will on the older platform.
Apple also invests a bunch here.
 
Well, ok, if it was really "bad", there'd be FreeBSD5, 6, 7.
I guess maybe they broke this stuff sometimes but haven't in a while?
That you can build FreeBSD4 binaries on FreeBSD7 and the run down to 4?
 
And then, same questions about OpenBSD and NetBSD.
I understand -- I could/must go and install a bajillion operating systems and test and find out, but I don't expect to spend the time that way and push comes to shove, any BSD (and Linux, Solaris, NT, CE, etc.) variants I introduce will have no version number in them, will be built on whatever I have, and it will be unknown if they work on older. And maybe something will materialize to be more portable, like interfacing to the Posix via C instead of cloned headers.
 
 - Jay



> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] which platforms? > Date: Thu, 15 May 2008 14:30:36 -0700> From: mika at async.caltech.edu> > here it is:> > FreeBSD4> PPC_DARWIN> NT386GNU> LINUXLIBC6> > I386_DARWIN coming soon> > Tony Hosking writes:> >> >--Apple-Mail-4-631028010> >Content-Type: text/plain;> > charset=US-ASCII;> > format=flowed;> > delsp=yes> >Content-Transfer-Encoding: 7bit> >> >SOLgnu> >PPC_DARWIN> >I386_DARWIN> >AMD64_DARWIN> >LINUXLIBC6> >I'd like AMD64_LINUX, SPARC64_SOLARISN but no time right now to devote > >to them.> >> >On May 14, 2008, at 1:25 PM, Jay wrote:> >> >> What do people run?> >> In particular: NetBSD? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN? > >> I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM_WINCE? AMD64_NT?> >>> >> Just curious, I'll probably bring up whatever I can, it's fun, and > >> yes, get back and fix AMD64_LINUX to have> >> garbage collection, NT386GNU and NT386 tests, cross-platform sets, > >> setup some Tinderboxes, etc...> >>> >> (AMD64_NT: the gcc available for this includes a bunch of patches, > >> so I'm inclined to either wait for them to go upstream,> >> or seek an alternate route such as "port" the in-proc backend, llvm, > >> generate C, or maybe write an interpreter for the IL;> >> and "porting" the backend is probably best preceded by a) x86 > >> LONGINT support b) other x86 targets "for practise", at least one,> >> though regarding .obj file formats, that would be tangential.)> >>> >> - Jay> >>> >>> >>> >>> >> >> >--Apple-Mail-4-631028010> >Content-Type: text/html;> > charset=US-ASCII> >Content-Transfer-Encoding: quoted-printable> >> > >-webkit-line-break: after-white-space; ">
 >apple-content-edited=3D"true"> >style=3D"border-collapse: separate; border-spacing: 0px 0px; color: => >rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: => >normal; font-variant: normal; font-weight: normal; letter-spacing: => >normal; line-height: normal; text-align: auto; => >-khtml-text-decorations-in-effect: none; text-indent: 0px; => >-apple-text-size-adjust: auto; text-transform: none; orphans: 2; => >white-space: normal; widows: 2; word-spacing: 0px; ">
 >style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; => >-khtml-line-break: after-white-space; "> >style=3D"border-collapse: separate; border-spacing: 0px 0px; color: => >rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: => >normal; font-variant: normal; font-weight: normal; letter-spacing: => >normal; line-height: normal; text-align: auto; => >-khtml-text-decorations-in-effect: none; text-indent: 0px; => >-apple-text-size-adjust: auto; text-transform: none; orphans: 2; => >white-space: normal; widows: 2; word-spacing: 0px; => >">SOLgnu
 >-khtml-nbsp-mode: space; -khtml-line-break: after-white-space; => >">PPC_DARWIN
 >space; -khtml-line-break: after-white-space; ">I386_DARWIN
 >style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; => >-khtml-line-break: after-white-space; ">AMD64_DARWIN
 >style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; => >-khtml-line-break: after-white-space; ">LINUXLIBC6
 >style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; => >-khtml-line-break: after-white-space; ">I'd like AMD64_LINUX,  >class=3D"Apple-style-span" style=3D"font-family: Tahoma; font-size: => >13px; ">SPARC64_SOLARISN but no time right now to devote to => >them.

On May 14, 2008, at 1:25 => >PM, Jay wrote:

 >type=3D"cite"> >separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; => >font-style: normal; font-variant: normal; font-weight: normal; => >letter-spacing: normal; line-height: normal; orphans: 2; text-align: => >auto; text-indent: 0px; text-transform: none; white-space: normal; => >widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; => >-webkit-border-vertical-spacing: 0px; => >-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: => >auto; -webkit-text-stroke-width: 0; ">
 >style=3D"font-size: 10pt; font-family: Tahoma; ">What do people => >run?
In particular: NetBSD? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN? => >I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM_WINCE? => >AMD64_NT?
 
Just curious, I'll probably bring up whatever I => >can, it's fun, and yes, get back and fix AMD64_LINUX to have
garbage => >collection, NT386GNU and NT386 tests, cross-platform sets, setup => >some Tinderboxes, etc...
 
(AMD64_NT: the gcc available for => >this includes a bunch of patches, so I'm inclined to either wait for => >them to go upstream,
or seek an alternate route such as "port" the => >in-proc backend, llvm, generate C, or maybe write an interpreter for the => >IL;
and "porting" the backend is probably best preceded by a) x86 => >LONGINT support b) other x86 targets "for practise", at least => >one,
though regarding .obj file formats, that would be => >tangential.)
 
 - => >Jay





=> >> >--Apple-Mail-4-631028010--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mika at async.caltech.edu  Fri May 16 07:54:28 2008
From: mika at async.caltech.edu (Mika Nystrom)
Date: Thu, 15 May 2008 22:54:28 -0700
Subject: [M3devel] which platforms? and questions about FreeBSD
	versioning
In-Reply-To: Your message of "Thu, 15 May 2008 22:43:30 -0000."
	 
Message-ID: <200805160554.m4G5sShX067480@camembert.async.caltech.edu>


No, sorry, haven't gotten around to testing the current NT386GNU
cm3... I have a lot of version synchronizing to do, unfortunately :(

Yes, FreeBSD is backwards-compatible, *not* forwards-compatible.
That is, you can build even fairly complex software packages on an old
FreeBSD system and expect it to run on the latest release.  You cannot,
as a general rule, build anything on a newer system and expect it to work
on an older one.  There must be "some" way of doing it that way, but
I don't know what it is, and I don't know if it's very well supported.
I keep FreeBSD 4.x systems around for precisely this reason: the binaries
compiled there work fine on 5.x and 6.x (as far as I have tested).  Not
the other way around!  In fact it has never worked the other way, as 
long as I can remember, with FreeBSD.

This is also why I suggest that a "FreeBSD4" bootstrap should actually
be built on FreeBSD 4.x and not 5.x, 6.x, or 7.x!

    Mika

Jay writes:
>--_14c076c4-fb7c-48b0-b705-2e38d4b4a333_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>Mika, ok, this is tangential: Have you tried the current NT386GNU cm3?
>=20
>I meant, more about what "operating systems" that Modula-3 does not support=
> do people here use, would like to see Modula-3 on. Or maybe I meant both.
>=20
>Speaking of the "4" in FreeBSD4:
>=20
>Has FreeBSD, and the other BSDs, really broken backward compat?
>They really change interfaces a lot such that binaries built with current h=
>eaders/libs won't run on older versions?
>And there isn't an easy way on current platforms to build something using o=
>lder tools to run on older and newer platforms?
>Look at Windows for example. If you call a "new" function directly, you wil=
>l fail to load on older platforms. So either don't call them, or use LoadLi=
>brary/GetProcAddress. Structures almost never change size, though there is =
>some screwiness there, stuff like:
>=20
>struct FOO {  size_t Size;
>  int Field1;
>#if VERSION > 1234
>  int Field2;
>#endif
>};
>=20
>I think it should be more like:
>=20
>struct FOO {  size_t Size;
>  int Field1;
>#if VERSION > 1234
>  int Field2;
>#endif
>};
>=20
>struct FOO_V1{  size_t Size;
>  int Field1;
>};
>=20
>struct FOO_V2 {  size_t Size;
>  int Field1;
>  int Field2;
>};
>=20
>#if VERSION > 1234
>typedef FOO_V2 FOO;
>#else
>typedef FOO_V1 FOO;
>#endif
>=20
>I understand that binaries built on the older platform will continue to wor=
>k on the newer platform.
>That is one thing.
>But it is also useful to be able to build binaries on the newer platform th=
>at will on the older platform.
>Apple also invests a bunch here.
>=20
>Well, ok, if it was really "bad", there'd be FreeBSD5, 6, 7.
>I guess maybe they broke this stuff sometimes but haven't in a while?
>That you can build FreeBSD4 binaries on FreeBSD7 and the run down to 4?
>=20
>And then, same questions about OpenBSD and NetBSD.
>I understand -- I could/must go and install a bajillion operating systems a=
>nd test and find out, but I don't expect to spend the time that way and pus=
>h comes to shove, any BSD (and Linux, Solaris, NT, CE, etc.) variants I int=
>roduce will have no version number in them, will be built on whatever I hav=
>e, and it will be unknown if they work on older. And maybe something will m=
>aterialize to be more portable, like interfacing to the Posix via C instead=
> of cloned headers.
>=20
> - Jay
>
>
>
>> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel=
>] which platforms? > Date: Thu, 15 May 2008 14:30:36 -0700> From: mika at asyn=
>c.caltech.edu> > here it is:> > FreeBSD4> PPC_DARWIN> NT386GNU> LINUXLIBC6>=
> > I386_DARWIN coming soon> > Tony Hosking writes:> >> >--Apple-Mail-4-6310=
>28010> >Content-Type: text/plain;> > charset=3DUS-ASCII;> > format=3Dflowed=
>;> > delsp=3Dyes> >Content-Transfer-Encoding: 7bit> >> >SOLgnu> >PPC_DARWIN=
>> >I386_DARWIN> >AMD64_DARWIN> >LINUXLIBC6> >I'd like AMD64_LINUX, SPARC64_=
>SOLARISN but no time right now to devote > >to them.> >> >On May 14, 2008, =
>at 1:25 PM, Jay wrote:> >> >> What do people run?> >> In particular: NetBSD=
>? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN? > >> I386_SOLARIS? AMD64_SOLARIS=
>? SPARC64_SOLARIS? ARM_WINCE? AMD64_NT?> >>> >> Just curious, I'll probably=
> bring up whatever I can, it's fun, and > >> yes, get back and fix AMD64_LI=
>NUX to have> >> garbage collection, NT386GNU and NT386 tests, cross-platfor=
>m sets, > >> setup some Tinderboxes, etc...> >>> >> (AMD64_NT: the gcc avai=
>lable for this includes a bunch of patches, > >> so I'm inclined to either =
>wait for them to go upstream,> >> or seek an alternate route such as "port"=
> the in-proc backend, llvm, > >> generate C, or maybe write an interpreter =
>for the IL;> >> and "porting" the backend is probably best preceded by a) x=
>86 > >> LONGINT support b) other x86 targets "for practise", at least one,>=
> >> though regarding .obj file formats, that would be tangential.)> >>> >> =
>- Jay> >>> >>> >>> >>> >> >> >--Apple-Mail-4-631028010> >Content-Type: text=
>/html;> > charset=3DUS-ASCII> >Content-Transfer-Encoding: quoted-printable>=
> >> >; =3D> >-webkit-line-break: after-white-space; ">
 >apple-content-e=
>dited=3D3D"true"> >style=3D3D"border=
>-collapse: separate; border-spacing: 0px 0px; color: =3D> >rgb(0, 0, 0); fo=
>nt-family: Helvetica; font-size: 12px; font-style: =3D> >normal; font-varia=
>nt: normal; font-weight: normal; letter-spacing: =3D> >normal; line-height:=
> normal; text-align: auto; =3D> >-khtml-text-decorations-in-effect: none; t=
>ext-indent: 0px; =3D> >-apple-text-size-adjust: auto; text-transform: none;=
> orphans: 2; =3D> >white-space: normal; widows: 2; word-spacing: 0px; ">v =3D> >style=3D3D"word-wrap: break-word; -khtml-nbsp-mode: space; =3D> >-k=
>html-line-break: after-white-space; ">=3D> >style=3D3D"border-collapse: separate; border-spacing: 0px 0px; color:=
> =3D> >rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
>=3D> >normal; font-variant: normal; font-weight: normal; letter-spacing: =
>=3D> >normal; line-height: normal; text-align: auto; =3D> >-khtml-text-deco=
>rations-in-effect: none; text-indent: 0px; =3D> >-apple-text-size-adjust: a=
>uto; text-transform: none; orphans: 2; =3D> >white-space: normal; widows: 2=
>; word-spacing: 0px; =3D> >">SOLgnu
break-word; =3D> >-khtml-nbsp-mode: space; -khtml-line-break: after-white-s=
>pace; =3D> >">PPC_DARWIN
-nbsp-mode: =3D> >space; -khtml-line-break: after-white-space; ">I386_DARWI=
>N
 >style=3D3D"word-wrap: break-word; -khtml-nbsp-mode: space=
>; =3D> >-khtml-line-break: after-white-space; ">AMD64_DARWIN
=
> >style=3D3D"word-wrap: break-word; -khtml-nbsp-mode: space; =3D> >-khtml-l=
>ine-break: after-white-space; ">LINUXLIBC6
 >style=3D3D"word-=
>wrap: break-word; -khtml-nbsp-mode: space; =3D> >-khtml-line-break: after-w=
>hite-space; ">I'd like AMD64_LINUX,  >class=3D3D"Apple-style=
>-span" style=3D3D"font-family: Tahoma; font-size: =3D> >13px; ">SPARC64_SOL=
>ARISN but no time right now to devote to =3D> >them.
iv>
On May 14, 2008, at 1:25 =3D> >PM, Jay wrote:

ss=3D3D"Apple-interchange-newline">
 >type=3D3D"cite">class=3D3D"Apple-style-span" style=3D3D"border-collapse: =3D> >separate; co=
>lor: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =3D> >font-styl=
>e: normal; font-variant: normal; font-weight: normal; =3D> >letter-spacing:=
> normal; line-height: normal; orphans: 2; text-align: =3D> >auto; text-inde=
>nt: 0px; text-transform: none; white-space: normal; =3D> >widows: 2; word-s=
>pacing: 0px; -webkit-border-horizontal-spacing: 0px; =3D> >-webkit-border-v=
>ertical-spacing: 0px; =3D> >-webkit-text-decorations-in-effect: none; -webk=
>it-text-size-adjust: =3D> >auto; -webkit-text-stroke-width: 0; ">
=3D3D"hmmessage" =3D> >style=3D3D"font-size: 10pt; font-family: Tahoma; ">W=
>hat do people =3D> >run?
In particular: NetBSD? OpenBSD? Sparc32? Sparc6=
>4? PPC64_DARWIN? =3D> >I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM_WI=
>NCE? =3D> >AMD64_NT?
 
Just curious, I'll probably bring up what=
>ever I =3D> >can, it's fun, and yes, get back and fix AMD64_LINUX to haver>garbage =3D> >collection, NT386GNU and NT386 tests, cross-platform s=
>ets, setup =3D> >some Tinderboxes, etc...
 
(AMD64_NT: the gcc a=
>vailable for =3D> >this includes a bunch of patches, so I'm inclined to eit=
>her wait for =3D> >them to go upstream,
or seek an alternate route such =
>as "port" the =3D> >in-proc backend, llvm, generate C, or maybe write an in=
>terpreter for the =3D> >IL;
and "porting" the backend is probably best p=
>receded by a) x86 =3D> >LONGINT support b) other x86 targets "for practise"=
>, at least =3D> >one,
though regarding .obj file formats, that would be =
>=3D> >tangential.)
 
 - =3D> >Jay




=
>

=3D> >> >--Apple-Mail-4-6310280=
>10--=
>
>--_14c076c4-fb7c-48b0-b705-2e38d4b4a333_
>Content-Type: text/html; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>
>
>
>
>Mika, ok, this is tangential: Have you =
>tried the current NT386GNU cm3?

> 

>I meant, more about what "operating systems" that Modula-3 does not support=
> do people here use, would like to see Modula-3 on. Or maybe I meant both.<=
>BR>
> 

>Speaking of the "4" in FreeBSD4:

> 

>Has FreeBSD, and the other BSDs, really broken backward compat?

>They really change interfaces a lot such that binaries built with current h=
>eaders/libs won't run on older versions?

>And there isn't an easy way on current platforms to build something using o=
>lder tools to run on older and newer platforms?

>Look at Windows for example. If you call a "new" function directly, you wil=
>l fail to load on older platforms. So either don't call them, or use LoadLi=
>brary/GetProcAddress. Structures almost never change size, though there is =
>some screwiness there, stuff like:

> 

>struct FOO {
  size_t Size;

>  int Field1;

>#if VERSION > 1234

>  int Field2;

>#endif

>};

> 

>I think it should be more like:

> 

>struct FOO {
  size_t Size;

>  int Field1;

>#if VERSION > 1234

>  int Field2;

>#endif

>};

> 

>struct FOO_V1{
  size_t Size;

>  int Field1;

>};

> 

>struct FOO_V2 {
  size_t Size;

>  int Field1;

>  int Field2;

>};

> 

>#if VERSION > 1234

>typedef FOO_V2 FOO;

>#else

>typedef FOO_V1 FOO;

>#endif

> 

>I understand that binaries built on the older platform will continue to wor=
>k on the newer platform.

>That is one thing.

>But it is also useful to be able to build binaries on the newer platform th=
>at will on the older platform.

>Apple also invests a bunch here.

> 

>Well, ok, if it was really "bad", there'd be FreeBSD5, 6, 7.

>I guess maybe they broke this stuff sometimes but haven't in a while?

>That you can build FreeBSD4 binaries on FreeBSD7 and the run down to 4?

> 

>And then, same questions about OpenBSD and NetBSD.

>I understand -- I could/must go and install a bajillion operating systems a=
>nd test and find out, but I don't expect to spend the time that way and pus=
>h comes to shove, any BSD (and Linux, Solaris, NT, CE, etc.) variants I int=
>roduce will have no version number in them, will be built on whatever I hav=
>e, and it will be unknown if they work on older. And maybe something will m=
>aterialize to be more portable, like interfacing to the Posix via C instead=
> of cloned headers.

> 

> - Jay



>
>

>

>> To: jayk123 at hotmail.com
> CC: m3devel at elegosoft.com
> Subj=
>ect: Re: [M3devel] which platforms? 
> Date: Thu, 15 May 2008 14:30:3=
>6 -0700
> From: mika at async.caltech.edu
> 
> here it is:R>> 
> FreeBSD4
> PPC_DARWIN
> NT386GNU
> LINUXL=
>IBC6
> 
> I386_DARWIN coming soon
> 
> Tony Hosking=
> writes:
> >
> >--Apple-Mail-4-631028010
> >Cont=
>ent-Type: text/plain;
> > charset=3DUS-ASCII;
> > format=
>=3Dflowed;
> > delsp=3Dyes
> >Content-Transfer-Encoding: =
>7bit
> >
> >SOLgnu
> >PPC_DARWIN
> >I38=
>6_DARWIN
> >AMD64_DARWIN
> >LINUXLIBC6
> >I'd li=
>ke AMD64_LINUX, SPARC64_SOLARISN but no time right now to devote 
> &=
>gt;to them.
> >
> >On May 14, 2008, at 1:25 PM, Jay wrote=
>:
> >
> >> What do people run?
> >> In par=
>ticular: NetBSD? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN? 
> >>=
> I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM_WINCE? AMD64_NT?
>=
> >>
> >> Just curious, I'll probably bring up whatever I =
>can, it's fun, and 
> >> yes, get back and fix AMD64_LINUX to h=
>ave
> >> garbage collection, NT386GNU and NT386 tests, cross-pl=
>atform sets, 
> >> setup some Tinderboxes, etc...
> >&=
>gt;
> >> (AMD64_NT: the gcc available for this includes a bunch=
> of patches, 
> >> so I'm inclined to either wait for them to g=
>o upstream,
> >> or seek an alternate route such as "port" the =
>in-proc backend, llvm, 
> >> generate C, or maybe write an inte=
>rpreter for the IL;
> >> and "porting" the backend is probably =
>best preceded by a) x86 
> >> LONGINT support b) other x86 targ=
>ets "for practise", at least one,
> >> though regarding .obj fi=
>le formats, that would be tangential.)
> >>
> >> - =
>Jay
> >>
> >>
> >>
> >>
=
>> >
> >
> >--Apple-Mail-4-631028010
> >Con=
>tent-Type: text/html;
> > charset=3DUS-ASCII
> >Content-T=
>ransfer-Encoding: quoted-printable
> >
> ><html><=
>;body style=3D3D"word-wrap: break-word; -webkit-nbsp-mode: space; =3D
&g=
>t; >-webkit-line-break: after-white-space; "><div =3D
> >=
>apple-content-edited=3D3D"true"><span class=3D3D"Apple-style-span" =
>=3D
> >style=3D3D"border-collapse: separate; border-spacing: 0px 0=
>px; color: =3D
> >rgb(0, 0, 0); font-family: Helvetica; font-size:=
> 12px; font-style: =3D
> >normal; font-variant: normal; font-weigh=
>t: normal; letter-spacing: =3D
> >normal; line-height: normal; tex=
>t-align: auto; =3D
> >-khtml-text-decorations-in-effect: none; tex=
>t-indent: 0px; =3D
> >-apple-text-size-adjust: auto; text-transfor=
>m: none; orphans: 2; =3D
> >white-space: normal; widows: 2; word-s=
>pacing: 0px; "><div =3D
> >style=3D3D"word-wrap: break-word;=
> -khtml-nbsp-mode: space; =3D
> >-khtml-line-break: after-white-sp=
>ace; "><span class=3D3D"Apple-style-span" =3D
> >style=3D3D"=
>border-collapse: separate; border-spacing: 0px 0px; color: =3D
> >=
>rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =3D
&=
>gt; >normal; font-variant: normal; font-weight: normal; letter-spacing: =
>=3D
> >normal; line-height: normal; text-align: auto; =3D
> =
>>-khtml-text-decorations-in-effect: none; text-indent: 0px; =3D
> =
>>-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =3D>> >white-space: normal; widows: 2; word-spacing: 0px; =3D
> &g=
>t;">SOLgnu</span></div><div style=3D3D"word-wrap: break-w=
>ord; =3D
> >-khtml-nbsp-mode: space; -khtml-line-break: after-whit=
>e-space; =3D
> >">PPC_DARWIN</div><div style=3D3D"word=
>-wrap: break-word; -khtml-nbsp-mode: =3D
> >space; -khtml-line-bre=
>ak: after-white-space; ">I386_DARWIN</div><div =3D
> >=
>style=3D3D"word-wrap: break-word; -khtml-nbsp-mode: space; =3D
> >=
>-khtml-line-break: after-white-space; ">AMD64_DARWIN</div><div =
>=3D
> >style=3D3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
>=3D
> >-khtml-line-break: after-white-space; ">LINUXLIBC6</d=
>iv><div =3D
> >style=3D3D"word-wrap: break-word; -khtml-nbsp=
>-mode: space; =3D
> >-khtml-line-break: after-white-space; ">I'=
>d like AMD64_LINUX,&nbsp;<span =3D
> >class=3D3D"Apple-styl=
>e-span" style=3D3D"font-family: Tahoma; font-size: =3D
> >13px; "&=
>gt;SPARC64_SOLARISN but no time right now to devote to =3D
> >them=
>.</span></div></span></div><br><div><=
>;div>On May 14, 2008, at 1:25 =3D
> >PM, Jay wrote:</div>=
><br class=3D3D"Apple-interchange-newline"><blockquote =3D
> =
>>type=3D3D"cite"><span class=3D3D"Apple-style-span" style=3D3D"bor=
>der-collapse: =3D
> >separate; color: rgb(0, 0, 0); font-family: H=
>elvetica; font-size: 12px; =3D
> >font-style: normal; font-variant=
>: normal; font-weight: normal; =3D
> >letter-spacing: normal; line=
>-height: normal; orphans: 2; text-align: =3D
> >auto; text-indent:=
> 0px; text-transform: none; white-space: normal; =3D
> >widows: 2;=
> word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =3D
> >=
>;-webkit-border-vertical-spacing: 0px; =3D
> >-webkit-text-decorat=
>ions-in-effect: none; -webkit-text-size-adjust: =3D
> >auto; -webk=
>it-text-stroke-width: 0; "><div class=3D3D"hmmessage" =3D
> >=
>;style=3D3D"font-size: 10pt; font-family: Tahoma; ">What do people =3DR>> >run?<br>In particular: NetBSD? OpenBSD? Sparc32? Sparc64? =
>PPC64_DARWIN? =3D
> >I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS?=
> ARM_WINCE? =3D
> >AMD64_NT?<br>&nbsp;<br>Just cur=
>ious, I'll probably bring up whatever I =3D
> >can, it's fun, and =
>yes, get back and fix AMD64_LINUX to have<br>garbage =3D
> >=
>collection, NT386GNU and NT386 tests,&nbsp;cross-platform sets, setup =
>=3D
> >some Tinderboxes, etc...<br>&nbsp;<br>(AMD6=
>4_NT: the gcc available for =3D
> >this includes a bunch of patche=
>s, so I'm inclined to either wait for =3D
> >them to go upstream,&=
>lt;br>or seek an alternate route such as "port" the =3D
> >in-p=
>roc backend, llvm, generate C, or maybe write an interpreter for the =3D>> >IL;<br>and "porting" the backend is probably best preceded =
>by a) x86 =3D
> >LONGINT support b) other x86 targets "for practis=
>e", at least =3D
> >one,<br>though regarding .obj file forma=
>ts, that would be =3D
> >tangential.)<br>&nbsp;<br>=
>;&nbsp;- =3D
> >Jay<br><br><br><br><=
>;br></div></span></blockquote></div><br>&l=
>t;/body></html>=3D
> >
> >--Apple-Mail-4-6310280=
>10--


>=
>
>--_14c076c4-fb7c-48b0-b705-2e38d4b4a333_--


From jayk123 at hotmail.com  Fri May 16 08:40:49 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 16 May 2008 06:40:49 +0000
Subject: [M3devel] which platforms? and questions about FreeBSD
 versioning
In-Reply-To: <200805160554.m4G5sShX067480@camembert.async.caltech.edu>
References: Your message of "Thu, 15 May 2008 22:43:30 -0000."
	  
	<200805160554.m4G5sShX067480@camembert.async.caltech.edu>
Message-ID: 

Wow that is crazy.
The "OS" is backwards compatible.
The tools -- or at least the headers/libs -- are not backwards compatible.
They apparently don't produce binaries that run on older systems.
 
Hm, so I did some diffing amongm3-libs\m3core\src\unix\freebsd-*
they are all amost identical.and almost all compatible.Freebsd-1 to -2 is the least compatible.otherwise the only actual difference I see is in Usignal sa_flags and sa_mask getting reversed. and sigcontext changed.
Otherwise it's mostly things like long vs. unsigned_long,int64_t vs. quad_t, short vs. int16_t.
The DIR record grew, but as long as it is not implementedin Modula-3 and the new fields not access, no matter.
Oh one errno value changed.
Sometimes some types or functions got added, but that is ok.
 
Maybe more research at a might later date...
 
 - Jay



> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] which platforms? and questions about FreeBSD versioning > Date: Thu, 15 May 2008 22:54:28 -0700> From: mika at async.caltech.edu> > > No, sorry, haven't gotten around to testing the current NT386GNU> cm3... I have a lot of version synchronizing to do, unfortunately :(> > Yes, FreeBSD is backwards-compatible, *not* forwards-compatible.> That is, you can build even fairly complex software packages on an old> FreeBSD system and expect it to run on the latest release. You cannot,> as a general rule, build anything on a newer system and expect it to work> on an older one. There must be "some" way of doing it that way, but> I don't know what it is, and I don't know if it's very well supported.> I keep FreeBSD 4.x systems around for precisely this reason: the binaries> compiled there work fine on 5.x and 6.x (as far as I have tested). Not> the other way around! In fact it has never worked the other way, as > long as I can remember, with FreeBSD.> > This is also why I suggest that a "FreeBSD4" bootstrap should actually> be built on FreeBSD 4.x and not 5.x, 6.x, or 7.x!> > Mika> > Jay writes:> >--_14c076c4-fb7c-48b0-b705-2e38d4b4a333_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >Mika, ok, this is tangential: Have you tried the current NT386GNU cm3?> >=20> >I meant, more about what "operating systems" that Modula-3 does not support=> > do people here use, would like to see Modula-3 on. Or maybe I meant both.> >=20> >Speaking of the "4" in FreeBSD4:> >=20> >Has FreeBSD, and the other BSDs, really broken backward compat?> >They really change interfaces a lot such that binaries built with current h=> >eaders/libs won't run on older versions?> >And there isn't an easy way on current platforms to build something using o=> >lder tools to run on older and newer platforms?> >Look at Windows for example. If you call a "new" function directly, you wil=> >l fail to load on older platforms. So either don't call them, or use LoadLi=> >brary/GetProcAddress. Structures almost never change size, though there is => >some screwiness there, stuff like:> >=20> >struct FOO { size_t Size;> > int Field1;> >#if VERSION > 1234> > int Field2;> >#endif> >};> >=20> >I think it should be more like:> >=20> >struct FOO { size_t Size;> > int Field1;> >#if VERSION > 1234> > int Field2;> >#endif> >};> >=20> >struct FOO_V1{ size_t Size;> > int Field1;> >};> >=20> >struct FOO_V2 { size_t Size;> > int Field1;> > int Field2;> >};> >=20> >#if VERSION > 1234> >typedef FOO_V2 FOO;> >#else> >typedef FOO_V1 FOO;> >#endif> >=20> >I understand that binaries built on the older platform will continue to wor=> >k on the newer platform.> >That is one thing.> >But it is also useful to be able to build binaries on the newer platform th=> >at will on the older platform.> >Apple also invests a bunch here.> >=20> >Well, ok, if it was really "bad", there'd be FreeBSD5, 6, 7.> >I guess maybe they broke this stuff sometimes but haven't in a while?> >That you can build FreeBSD4 binaries on FreeBSD7 and the run down to 4?> >=20> >And then, same questions about OpenBSD and NetBSD.> >I understand -- I could/must go and install a bajillion operating systems a=> >nd test and find out, but I don't expect to spend the time that way and pus=> >h comes to shove, any BSD (and Linux, Solaris, NT, CE, etc.) variants I int=> >roduce will have no version number in them, will be built on whatever I hav=> >e, and it will be unknown if they work on older. And maybe something will m=> >aterialize to be more portable, like interfacing to the Posix via C instead=> > of cloned headers.> >=20> > - Jay> >> >> >> >> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel=> >] which platforms? > Date: Thu, 15 May 2008 14:30:36 -0700> From: mika at asyn=> >c.caltech.edu> > here it is:> > FreeBSD4> PPC_DARWIN> NT386GNU> LINUXLIBC6>=> > > I386_DARWIN coming soon> > Tony Hosking writes:> >> >--Apple-Mail-4-6310=> >28010> >Content-Type: text/plain;> > charset=3DUS-ASCII;> > format=3Dflowed=> >;> > delsp=3Dyes> >Content-Transfer-Encoding: 7bit> >> >SOLgnu> >PPC_DARWIN=> >> >I386_DARWIN> >AMD64_DARWIN> >LINUXLIBC6> >I'd like AMD64_LINUX, SPARC64_=> >SOLARISN but no time right now to devote > >to them.> >> >On May 14, 2008, => >at 1:25 PM, Jay wrote:> >> >> What do people run?> >> In particular: NetBSD=> >? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN? > >> I386_SOLARIS? AMD64_SOLARIS=> >? SPARC64_SOLARIS? ARM_WINCE? AMD64_NT?> >>> >> Just curious, I'll probably=> > bring up whatever I can, it's fun, and > >> yes, get back and fix AMD64_LI=> >NUX to have> >> garbage collection, NT386GNU and NT386 tests, cross-platfor=> >m sets, > >> setup some Tinderboxes, etc...> >>> >> (AMD64_NT: the gcc avai=> >lable for this includes a bunch of patches, > >> so I'm inclined to either => >wait for them to go upstream,> >> or seek an alternate route such as "port"=> > the in-proc backend, llvm, > >> generate C, or maybe write an interpreter => >for the IL;> >> and "porting" the backend is probably best preceded by a) x=> >86 > >> LONGINT support b) other x86 targets "for practise", at least one,>=> > >> though regarding .obj file formats, that would be tangential.)> >>> >> => >- Jay> >>> >>> >>> >>> >> >> >--Apple-Mail-4-631028010> >Content-Type: text=> >/html;> > charset=3DUS-ASCII> >Content-Transfer-Encoding: quoted-printable>=> > >> > >; =3D> >-webkit-line-break: after-white-space; ">
 >apple-content-e=> >dited=3D3D"true"> >style=3D3D"border=> >-collapse: separate; border-spacing: 0px 0px; color: =3D> >rgb(0, 0, 0); fo=> >nt-family: Helvetica; font-size: 12px; font-style: =3D> >normal; font-varia=> >nt: normal; font-weight: normal; letter-spacing: =3D> >normal; line-height:=> > normal; text-align: auto; =3D> >-khtml-text-decorations-in-effect: none; t=> >ext-indent: 0px; =3D> >-apple-text-size-adjust: auto; text-transform: none;=> > orphans: 2; =3D> >white-space: normal; widows: 2; word-spacing: 0px; "> >v =3D> >style=3D3D"word-wrap: break-word; -khtml-nbsp-mode: space; =3D> >-k=> >html-line-break: after-white-space; "> >=3D> >style=3D3D"border-collapse: separate; border-spacing: 0px 0px; color:=> > =3D> >rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: => >=3D> >normal; font-variant: normal; font-weight: normal; letter-spacing: => >=3D> >normal; line-height: normal; text-align: auto; =3D> >-khtml-text-deco=> >rations-in-effect: none; text-indent: 0px; =3D> >-apple-text-size-adjust: a=> >uto; text-transform: none; orphans: 2; =3D> >white-space: normal; widows: 2=> >; word-spacing: 0px; =3D> >">SOLgnu
 >break-word; =3D> >-khtml-nbsp-mode: space; -khtml-line-break: after-white-s=> >pace; =3D> >">PPC_DARWIN
 >-nbsp-mode: =3D> >space; -khtml-line-break: after-white-space; ">I386_DARWI=> >N
 >style=3D3D"word-wrap: break-word; -khtml-nbsp-mode: space=> >; =3D> >-khtml-line-break: after-white-space; ">AMD64_DARWIN
=> > >style=3D3D"word-wrap: break-word; -khtml-nbsp-mode: space; =3D> >-khtml-l=> >ine-break: after-white-space; ">LINUXLIBC6
 >style=3D3D"word-=> >wrap: break-word; -khtml-nbsp-mode: space; =3D> >-khtml-line-break: after-w=> >hite-space; ">I'd like AMD64_LINUX,  >class=3D3D"Apple-style=> >-span" style=3D3D"font-family: Tahoma; font-size: =3D> >13px; ">SPARC64_SOL=> >ARISN but no time right now to devote to =3D> >them.
 >iv>
On May 14, 2008, at 1:25 =3D> >PM, Jay wrote:

 >ss=3D3D"Apple-interchange-newline">
 >type=3D3D"cite"> >class=3D3D"Apple-style-span" style=3D3D"border-collapse: =3D> >separate; co=> >lor: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =3D> >font-styl=> >e: normal; font-variant: normal; font-weight: normal; =3D> >letter-spacing:=> > normal; line-height: normal; orphans: 2; text-align: =3D> >auto; text-inde=> >nt: 0px; text-transform: none; white-space: normal; =3D> >widows: 2; word-s=> >pacing: 0px; -webkit-border-horizontal-spacing: 0px; =3D> >-webkit-border-v=> >ertical-spacing: 0px; =3D> >-webkit-text-decorations-in-effect: none; -webk=> >it-text-size-adjust: =3D> >auto; -webkit-text-stroke-width: 0; ">
 >=3D3D"hmmessage" =3D> >style=3D3D"font-size: 10pt; font-family: Tahoma; ">W=> >hat do people =3D> >run?
In particular: NetBSD? OpenBSD? Sparc32? Sparc6=> >4? PPC64_DARWIN? =3D> >I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM_WI=> >NCE? =3D> >AMD64_NT?
 
Just curious, I'll probably bring up what=> >ever I =3D> >can, it's fun, and yes, get back and fix AMD64_LINUX to have >r>garbage =3D> >collection, NT386GNU and NT386 tests, cross-platform s=> >ets, setup =3D> >some Tinderboxes, etc...
 
(AMD64_NT: the gcc a=> >vailable for =3D> >this includes a bunch of patches, so I'm inclined to eit=> >her wait for =3D> >them to go upstream,
or seek an alternate route such => >as "port" the =3D> >in-proc backend, llvm, generate C, or maybe write an in=> >terpreter for the =3D> >IL;
and "porting" the backend is probably best p=> >receded by a) x86 =3D> >LONGINT support b) other x86 targets "for practise"=> >, at least =3D> >one,
though regarding .obj file formats, that would be => >=3D> >tangential.)
 
 - =3D> >Jay




=> >

=3D> >> >--Apple-Mail-4-6310280=> >10--=> >> >--_14c076c4-fb7c-48b0-b705-2e38d4b4a333_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >> >> >> >Mika, ok, this is tangential: Have you => >tried the current NT386GNU cm3?
> > 
> >I meant, more about what "operating systems" that Modula-3 does not support=> > do people here use, would like to see Modula-3 on. Or maybe I meant both.<=> >BR>> > 
> >Speaking of the "4" in FreeBSD4:
> > 
> >Has FreeBSD, and the other BSDs, really broken backward compat?
> >They really change interfaces a lot such that binaries built with current h=> >eaders/libs won't run on older versions?
> >And there isn't an easy way on current platforms to build something using o=> >lder tools to run on older and newer platforms?
> >Look at Windows for example. If you call a "new" function directly, you wil=> >l fail to load on older platforms. So either don't call them, or use LoadLi=> >brary/GetProcAddress. Structures almost never change size, though there is => >some screwiness there, stuff like:
> > 
> >struct FOO {
  size_t Size;
> >  int Field1;
> >#if VERSION > 1234
> >  int Field2;
> >#endif
> >};
> > 
> >I think it should be more like:
> > 
> >struct FOO {
  size_t Size;
> >  int Field1;
> >#if VERSION > 1234
> >  int Field2;
> >#endif
> >};
> > 
> >struct FOO_V1{
  size_t Size;
> >  int Field1;
> >};
> > 
> >struct FOO_V2 {
  size_t Size;
> >  int Field1;
> >  int Field2;
> >};
> > 
> >#if VERSION > 1234
> >typedef FOO_V2 FOO;
> >#else
> >typedef FOO_V1 FOO;
> >#endif
> > 
> >I understand that binaries built on the older platform will continue to wor=> >k on the newer platform.
> >That is one thing.
> >But it is also useful to be able to build binaries on the newer platform th=> >at will on the older platform.
> >Apple also invests a bunch here.
> > 
> >Well, ok, if it was really "bad", there'd be FreeBSD5, 6, 7.
> >I guess maybe they broke this stuff sometimes but haven't in a while?
> >That you can build FreeBSD4 binaries on FreeBSD7 and the run down to 4?
> > 
> >And then, same questions about OpenBSD and NetBSD.
> >I understand -- I could/must go and install a bajillion operating systems a=> >nd test and find out, but I don't expect to spend the time that way and pus=> >h comes to shove, any BSD (and Linux, Solaris, NT, CE, etc.) variants I int=> >roduce will have no version number in them, will be built on whatever I hav=> >e, and it will be unknown if they work on older. And maybe something will m=> >aterialize to be more portable, like interfacing to the Posix via C instead=> > of cloned headers.
> > 
> > - Jay


> >> >
> >
> >> To: jayk123 at hotmail.com
> CC: m3devel at elegosoft.com
> Subj=> >ect: Re: [M3devel] which platforms? 
> Date: Thu, 15 May 2008 14:30:3=> >6 -0700
> From: mika at async.caltech.edu
> 
> here it is: >R>> 
> FreeBSD4
> PPC_DARWIN
> NT386GNU
> LINUXL=> >IBC6
> 
> I386_DARWIN coming soon
> 
> Tony Hosking=> > writes:
> >
> >--Apple-Mail-4-631028010
> >Cont=> >ent-Type: text/plain;
> > charset=3DUS-ASCII;
> > format=> >=3Dflowed;
> > delsp=3Dyes
> >Content-Transfer-Encoding: => >7bit
> >
> >SOLgnu
> >PPC_DARWIN
> >I38=> >6_DARWIN
> >AMD64_DARWIN
> >LINUXLIBC6
> >I'd li=> >ke AMD64_LINUX, SPARC64_SOLARISN but no time right now to devote 
> &=> >gt;to them.
> >
> >On May 14, 2008, at 1:25 PM, Jay wrote=> >:
> >
> >> What do people run?
> >> In par=> >ticular: NetBSD? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN? 
> >>=> > I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM_WINCE? AMD64_NT?
>=> > >>
> >> Just curious, I'll probably bring up whatever I => >can, it's fun, and 
> >> yes, get back and fix AMD64_LINUX to h=> >ave
> >> garbage collection, NT386GNU and NT386 tests, cross-pl=> >atform sets, 
> >> setup some Tinderboxes, etc...
> >&=> >gt;
> >> (AMD64_NT: the gcc available for this includes a bunch=> > of patches, 
> >> so I'm inclined to either wait for them to g=> >o upstream,
> >> or seek an alternate route such as "port" the => >in-proc backend, llvm, 
> >> generate C, or maybe write an inte=> >rpreter for the IL;
> >> and "porting" the backend is probably => >best preceded by a) x86 
> >> LONGINT support b) other x86 targ=> >ets "for practise", at least one,
> >> though regarding .obj fi=> >le formats, that would be tangential.)
> >>
> >> - => >Jay
> >>
> >>
> >>
> >>
=> >> >
> >
> >--Apple-Mail-4-631028010
> >Con=> >tent-Type: text/html;
> > charset=3DUS-ASCII
> >Content-T=> >ransfer-Encoding: quoted-printable
> >
> ><html><=> >;body style=3D3D"word-wrap: break-word; -webkit-nbsp-mode: space; =3D
&g=> >t; >-webkit-line-break: after-white-space; "><div =3D
> >=> >apple-content-edited=3D3D"true"><span class=3D3D"Apple-style-span" => >=3D
> >style=3D3D"border-collapse: separate; border-spacing: 0px 0=> >px; color: =3D
> >rgb(0, 0, 0); font-family: Helvetica; font-size:=> > 12px; font-style: =3D
> >normal; font-variant: normal; font-weigh=> >t: normal; letter-spacing: =3D
> >normal; line-height: normal; tex=> >t-align: auto; =3D
> >-khtml-text-decorations-in-effect: none; tex=> >t-indent: 0px; =3D
> >-apple-text-size-adjust: auto; text-transfor=> >m: none; orphans: 2; =3D
> >white-space: normal; widows: 2; word-s=> >pacing: 0px; "><div =3D
> >style=3D3D"word-wrap: break-word;=> > -khtml-nbsp-mode: space; =3D
> >-khtml-line-break: after-white-sp=> >ace; "><span class=3D3D"Apple-style-span" =3D
> >style=3D3D"=> >border-collapse: separate; border-spacing: 0px 0px; color: =3D
> >=> >rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =3D
&=> >gt; >normal; font-variant: normal; font-weight: normal; letter-spacing: => >=3D
> >normal; line-height: normal; text-align: auto; =3D
> => >>-khtml-text-decorations-in-effect: none; text-indent: 0px; =3D
> => >>-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =3D >>> >white-space: normal; widows: 2; word-spacing: 0px; =3D
> &g=> >t;">SOLgnu</span></div><div style=3D3D"word-wrap: break-w=> >ord; =3D
> >-khtml-nbsp-mode: space; -khtml-line-break: after-whit=> >e-space; =3D
> >">PPC_DARWIN</div><div style=3D3D"word=> >-wrap: break-word; -khtml-nbsp-mode: =3D
> >space; -khtml-line-bre=> >ak: after-white-space; ">I386_DARWIN</div><div =3D
> >=> >style=3D3D"word-wrap: break-word; -khtml-nbsp-mode: space; =3D
> >=> >-khtml-line-break: after-white-space; ">AMD64_DARWIN</div><div => >=3D
> >style=3D3D"word-wrap: break-word; -khtml-nbsp-mode: space; => >=3D
> >-khtml-line-break: after-white-space; ">LINUXLIBC6</d=> >iv><div =3D
> >style=3D3D"word-wrap: break-word; -khtml-nbsp=> >-mode: space; =3D
> >-khtml-line-break: after-white-space; ">I'=> >d like AMD64_LINUX,&nbsp;<span =3D
> >class=3D3D"Apple-styl=> >e-span" style=3D3D"font-family: Tahoma; font-size: =3D
> >13px; "&=> >gt;SPARC64_SOLARISN but no time right now to devote to =3D
> >them=> >.</span></div></span></div><br><div><=> >;div>On May 14, 2008, at 1:25 =3D
> >PM, Jay wrote:</div>=> ><br class=3D3D"Apple-interchange-newline"><blockquote =3D
> => >>type=3D3D"cite"><span class=3D3D"Apple-style-span" style=3D3D"bor=> >der-collapse: =3D
> >separate; color: rgb(0, 0, 0); font-family: H=> >elvetica; font-size: 12px; =3D
> >font-style: normal; font-variant=> >: normal; font-weight: normal; =3D
> >letter-spacing: normal; line=> >-height: normal; orphans: 2; text-align: =3D
> >auto; text-indent:=> > 0px; text-transform: none; white-space: normal; =3D
> >widows: 2;=> > word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =3D
> >=> >;-webkit-border-vertical-spacing: 0px; =3D
> >-webkit-text-decorat=> >ions-in-effect: none; -webkit-text-size-adjust: =3D
> >auto; -webk=> >it-text-stroke-width: 0; "><div class=3D3D"hmmessage" =3D
> >=> >;style=3D3D"font-size: 10pt; font-family: Tahoma; ">What do people =3D >R>> >run?<br>In particular: NetBSD? OpenBSD? Sparc32? Sparc64? => >PPC64_DARWIN? =3D
> >I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS?=> > ARM_WINCE? =3D
> >AMD64_NT?<br>&nbsp;<br>Just cur=> >ious, I'll probably bring up whatever I =3D
> >can, it's fun, and => >yes, get back and fix AMD64_LINUX to have<br>garbage =3D
> >=> >collection, NT386GNU and NT386 tests,&nbsp;cross-platform sets, setup => >=3D
> >some Tinderboxes, etc...<br>&nbsp;<br>(AMD6=> >4_NT: the gcc available for =3D
> >this includes a bunch of patche=> >s, so I'm inclined to either wait for =3D
> >them to go upstream,&=> >lt;br>or seek an alternate route such as "port" the =3D
> >in-p=> >roc backend, llvm, generate C, or maybe write an interpreter for the =3D >>> >IL;<br>and "porting" the backend is probably best preceded => >by a) x86 =3D
> >LONGINT support b) other x86 targets "for practis=> >e", at least =3D
> >one,<br>though regarding .obj file forma=> >ts, that would be =3D
> >tangential.)<br>&nbsp;<br>=> >;&nbsp;- =3D
> >Jay<br><br><br><br><=> >;br></div></span></blockquote></div><br>&l=> >t;/body></html>=3D
> >
> >--Apple-Mail-4-6310280=> >10--

> >=> >> >--_14c076c4-fb7c-48b0-b705-2e38d4b4a333_--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mika at async.caltech.edu  Fri May 16 08:46:35 2008
From: mika at async.caltech.edu (Mika Nystrom)
Date: Thu, 15 May 2008 23:46:35 -0700
Subject: [M3devel] which platforms? and questions about FreeBSD
	versioning
In-Reply-To: Your message of "Fri, 16 May 2008 06:40:49 -0000."
	 
Message-ID: <200805160646.m4G6kZTb068480@camembert.async.caltech.edu>


Did you check the system call numbers?  I often get ... "unknown
system call", I think, when I try to do what you are describing.

By the way I have had far less trouble using binaries across versions
of FreeBSD than trying the same trick on Linux... maybe I just know
better what I am doing on FreeBSD?  I have some very very old programs
that still work fine.  Even the compiler tends to keep working when
upgrading from one major version to the next.  (But yes you do need
to have the compatibility libraries installed on the new system.)

     Mika

Jay writes:
>--_a9d87328-63f1-414c-abcb-03c34a9cee30_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>Wow that is crazy.
>The "OS" is backwards compatible.
>The tools -- or at least the headers/libs -- are not backwards compatible.
>They apparently don't produce binaries that run on older systems.
>=20
>Hm, so I did some diffing amongm3-libs\m3core\src\unix\freebsd-*
>they are all amost identical.and almost all compatible.Freebsd-1 to -2 is t=
>he least compatible.otherwise the only actual difference I see is in Usigna=
>l sa_flags and sa_mask getting reversed. and sigcontext changed.
>Otherwise it's mostly things like long vs. unsigned_long,int64_t vs. quad_t=
>, short vs. int16_t.
>The DIR record grew, but as long as it is not implementedin Modula-3 and th=
>e new fields not access, no matter.
>Oh one errno value changed.
>Sometimes some types or functions got added, but that is ok.
>=20
>Maybe more research at a might later date...
>=20
> - Jay
>
>
>
>> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel=
>] which platforms? and questions about FreeBSD versioning > Date: Thu, 15 M=
>ay 2008 22:54:28 -0700> From: mika at async.caltech.edu> > > No, sorry, haven'=
>t gotten around to testing the current NT386GNU> cm3... I have a lot of ver=
>sion synchronizing to do, unfortunately :(> > Yes, FreeBSD is backwards-com=
>patible, *not* forwards-compatible.> That is, you can build even fairly com=
>plex software packages on an old> FreeBSD system and expect it to run on th=
>e latest release. You cannot,> as a general rule, build anything on a newer=
> system and expect it to work> on an older one. There must be "some" way of=
> doing it that way, but> I don't know what it is, and I don't know if it's =
>very well supported.> I keep FreeBSD 4.x systems around for precisely this =
>reason: the binaries> compiled there work fine on 5.x and 6.x (as far as I =
>have tested). Not> the other way around! In fact it has never worked the ot=
>her way, as > long as I can remember, with FreeBSD.> > This is also why I s=
>uggest that a "FreeBSD4" bootstrap should actually> be built on FreeBSD 4.x=
> and not 5.x, 6.x, or 7.x!> > Mika> > Jay writes:> >--_14c076c4-fb7c-48b0-b=
>705-2e38d4b4a333_> >Content-Type: text/plain; charset=3D"iso-8859-1"> >Cont=
>ent-Transfer-Encoding: quoted-printable> >> >Mika, ok, this is tangential: =
>Have you tried the current NT386GNU cm3?> >=3D20> >I meant, more about what=
> "operating systems" that Modula-3 does not support=3D> > do people here us=
>e, would like to see Modula-3 on. Or maybe I meant both.> >=3D20> >Speaking=
> of the "4" in FreeBSD4:> >=3D20> >Has FreeBSD, and the other BSDs, really =
>broken backward compat?> >They really change interfaces a lot such that bin=
>aries built with current h=3D> >eaders/libs won't run on older versions?> >=
>And there isn't an easy way on current platforms to build something using o=
>=3D> >lder tools to run on older and newer platforms?> >Look at Windows for=
> example. If you call a "new" function directly, you wil=3D> >l fail to loa=
>d on older platforms. So either don't call them, or use LoadLi=3D> >brary/G=
>etProcAddress. Structures almost never change size, though there is =3D> >s=
>ome screwiness there, stuff like:> >=3D20> >struct FOO { size_t Size;> > in=
>t Field1;> >#if VERSION > 1234> > int Field2;> >#endif> >};> >=3D20> >I thi=
>nk it should be more like:> >=3D20> >struct FOO { size_t Size;> > int Field=
>1;> >#if VERSION > 1234> > int Field2;> >#endif> >};> >=3D20> >struct FOO_V=
>1{ size_t Size;> > int Field1;> >};> >=3D20> >struct FOO_V2 { size_t Size;>=
> > int Field1;> > int Field2;> >};> >=3D20> >#if VERSION > 1234> >typedef F=
>OO_V2 FOO;> >#else> >typedef FOO_V1 FOO;> >#endif> >=3D20> >I understand th=
>at binaries built on the older platform will continue to wor=3D> >k on the =
>newer platform.> >That is one thing.> >But it is also useful to be able to =
>build binaries on the newer platform th=3D> >at will on the older platform.=
>> >Apple also invests a bunch here.> >=3D20> >Well, ok, if it was really "b=
>ad", there'd be FreeBSD5, 6, 7.> >I guess maybe they broke this stuff somet=
>imes but haven't in a while?> >That you can build FreeBSD4 binaries on Free=
>BSD7 and the run down to 4?> >=3D20> >And then, same questions about OpenBS=
>D and NetBSD.> >I understand -- I could/must go and install a bajillion ope=
>rating systems a=3D> >nd test and find out, but I don't expect to spend the=
> time that way and pus=3D> >h comes to shove, any BSD (and Linux, Solaris, =
>NT, CE, etc.) variants I int=3D> >roduce will have no version number in the=
>m, will be built on whatever I hav=3D> >e, and it will be unknown if they w=
>ork on older. And maybe something will m=3D> >aterialize to be more portabl=
>e, like interfacing to the Posix via C instead=3D> > of cloned headers.> >=
>=3D20> > - Jay> >> >> >> >> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.=
>com> Subject: Re: [M3devel=3D> >] which platforms? > Date: Thu, 15 May 2008=
> 14:30:36 -0700> From: mika at asyn=3D> >c.caltech.edu> > here it is:> > FreeB=
>SD4> PPC_DARWIN> NT386GNU> LINUXLIBC6>=3D> > > I386_DARWIN coming soon> > T=
>ony Hosking writes:> >> >--Apple-Mail-4-6310=3D> >28010> >Content-Type: tex=
>t/plain;> > charset=3D3DUS-ASCII;> > format=3D3Dflowed=3D> >;> > delsp=3D3D=
>yes> >Content-Transfer-Encoding: 7bit> >> >SOLgnu> >PPC_DARWIN=3D> >> >I386=
>_DARWIN> >AMD64_DARWIN> >LINUXLIBC6> >I'd like AMD64_LINUX, SPARC64_=3D> >S=
>OLARISN but no time right now to devote > >to them.> >> >On May 14, 2008, =
>=3D> >at 1:25 PM, Jay wrote:> >> >> What do people run?> >> In particular: =
>NetBSD=3D> >? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN? > >> I386_SOLARIS? A=
>MD64_SOLARIS=3D> >? SPARC64_SOLARIS? ARM_WINCE? AMD64_NT?> >>> >> Just curi=
>ous, I'll probably=3D> > bring up whatever I can, it's fun, and > >> yes, g=
>et back and fix AMD64_LI=3D> >NUX to have> >> garbage collection, NT386GNU =
>and NT386 tests, cross-platfor=3D> >m sets, > >> setup some Tinderboxes, et=
>c...> >>> >> (AMD64_NT: the gcc avai=3D> >lable for this includes a bunch o=
>f patches, > >> so I'm inclined to either =3D> >wait for them to go upstrea=
>m,> >> or seek an alternate route such as "port"=3D> > the in-proc backend,=
> llvm, > >> generate C, or maybe write an interpreter =3D> >for the IL;> >>=
> and "porting" the backend is probably best preceded by a) x=3D> >86 > >> L=
>ONGINT support b) other x86 targets "for practise", at least one,>=3D> > >>=
> though regarding .obj file formats, that would be tangential.)> >>> >> =3D=
>> >- Jay> >>> >>> >>> >>> >> >> >--Apple-Mail-4-631028010> >Content-Type: t=
>ext=3D> >/html;> > charset=3D3DUS-ASCII> >Content-Transfer-Encoding: quoted=
-printable>=3D> > >> >it-nbsp-mode: space=3D> >; =3D3D> >-webkit-line-break: after-white-space; "=
>>
 >apple-content-e=3D> >dited=3D3D3D"true">ple-style-span" =3D3D> >style=3D3D3D"border=3D> >-collapse: separate; borde=
>r-spacing: 0px 0px; color: =3D3D> >rgb(0, 0, 0); fo=3D> >nt-family: Helveti=
>ca; font-size: 12px; font-style: =3D3D> >normal; font-varia=3D> >nt: normal=
>; font-weight: normal; letter-spacing: =3D3D> >normal; line-height:=3D> > n=
>ormal; text-align: auto; =3D3D> >-khtml-text-decorations-in-effect: none; t=
>=3D> >ext-indent: 0px; =3D3D> >-apple-text-size-adjust: auto; text-transfor=
>m: none;=3D> > orphans: 2; =3D3D> >white-space: normal; widows: 2; word-spa=
>cing: 0px; "> >v =3D3D> >style=3D3D3D"word-wrap: break-word; -khtml-=
>nbsp-mode: space; =3D3D> >-k=3D> >html-line-break: after-white-space; ">an class=3D3D3D"Apple-style-span" =3D> >=3D3D> >style=3D3D3D"border-collaps=
>e: separate; border-spacing: 0px 0px; color:=3D> > =3D3D> >rgb(0, 0, 0); fo=
>nt-family: Helvetica; font-size: 12px; font-style: =3D> >=3D3D> >normal; fo=
>nt-variant: normal; font-weight: normal; letter-spacing: =3D> >=3D3D> >norm=
>al; line-height: normal; text-align: auto; =3D3D> >-khtml-text-deco=3D> >ra=
>tions-in-effect: none; text-indent: 0px; =3D3D> >-apple-text-size-adjust: a=
>=3D> >uto; text-transform: none; orphans: 2; =3D3D> >white-space: normal; w=
>idows: 2=3D> >; word-spacing: 0px; =3D3D> >">SOLgnu
=3D3D3D"word-wrap: =3D> >break-word; =3D3D> >-khtml-nbsp-mode: space; -khtm=
>l-line-break: after-white-s=3D> >pace; =3D3D> >">PPC_DARWIN
=3D3D3D"word-wrap: break-word; -khtml=3D> >-nbsp-mode: =3D3D> >space; -khtm=
>l-line-break: after-white-space; ">I386_DARWI=3D> >N
 >styl=
>e=3D3D3D"word-wrap: break-word; -khtml-nbsp-mode: space=3D> >; =3D3D> >-kht=
>ml-line-break: after-white-space; ">AMD64_DARWIN
=3D> > >st=
>yle=3D3D3D"word-wrap: break-word; -khtml-nbsp-mode: space; =3D3D> >-khtml-l=
>=3D> >ine-break: after-white-space; ">LINUXLIBC6
 >style=3D=
>3D3D"word-=3D> >wrap: break-word; -khtml-nbsp-mode: space; =3D3D> >-khtml-l=
>ine-break: after-w=3D> >hite-space; ">I'd like AMD64_LINUX, D> >class=3D3D3D"Apple-style=3D> >-span" style=3D3D3D"font-family: Tahoma; =
>font-size: =3D3D> >13px; ">SPARC64_SOL=3D> >ARISN but no time right now to =
>devote to =3D3D> >them.
 >iv>
On May=
> 14, 2008, at 1:25 =3D3D> >PM, Jay wrote:

 >ss=3D3D3D"Apple=
>-interchange-newline">
 >type=3D3D3D"cite"> >cla=
>ss=3D3D3D"Apple-style-span" style=3D3D3D"border-collapse: =3D3D> >separate;=
> co=3D> >lor: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =3D3D>=
> >font-styl=3D> >e: normal; font-variant: normal; font-weight: normal; =3D3=
>D> >letter-spacing:=3D> > normal; line-height: normal; orphans: 2; text-ali=
>gn: =3D3D> >auto; text-inde=3D> >nt: 0px; text-transform: none; white-space=
>: normal; =3D3D> >widows: 2; word-s=3D> >pacing: 0px; -webkit-border-horizo=
>ntal-spacing: 0px; =3D3D> >-webkit-border-v=3D> >ertical-spacing: 0px; =3D3=
>D> >-webkit-text-decorations-in-effect: none; -webk=3D> >it-text-size-adjus=
>t: =3D3D> >auto; -webkit-text-stroke-width: 0; ">
 >=3D3D3D"hm=
>message" =3D3D> >style=3D3D3D"font-size: 10pt; font-family: Tahoma; ">W=3D>=
> >hat do people =3D3D> >run?
In particular: NetBSD? OpenBSD? Sparc32? Sp=
>arc6=3D> >4? PPC64_DARWIN? =3D3D> >I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOL=
>ARIS? ARM_WI=3D> >NCE? =3D3D> >AMD64_NT?
 
Just curious, I'll pr=
>obably bring up what=3D> >ever I =3D3D> >can, it's fun, and yes, get back a=
>nd fix AMD64_LINUX to have >r>garbage =3D3D> >collection, NT386GNU an=
>d NT386 tests, cross-platform s=3D> >ets, setup =3D3D> >some Tinderbox=
>es, etc...
 
(AMD64_NT: the gcc a=3D> >vailable for =3D3D> >this=
> includes a bunch of patches, so I'm inclined to eit=3D> >her wait for =3D3=
>D> >them to go upstream,
or seek an alternate route such =3D> >as "port"=
> the =3D3D> >in-proc backend, llvm, generate C, or maybe write an in=3D> >t=
>erpreter for the =3D3D> >IL;
and "porting" the backend is probably best =
>p=3D> >receded by a) x86 =3D3D> >LONGINT support b) other x86 targets "for =
>practise"=3D> >, at least =3D3D> >one,
though regarding .obj file format=
>s, that would be =3D> >=3D3D> >tangential.)
 
 - =3D3D> >Ja=
>y




=3D> >

l>=3D3D> >> >--Apple-Mail-4-6310280=3D> >10--=3D> >> >--_14c076c4-fb7c-48b0=
>-b705-2e38d4b4a333_> >Content-Type: text/html; charset=3D"iso-8859-1"> >Con=
>tent-Transfer-Encoding: quoted-printable> >> >> >> >> >> >3D'hmmessage'>Mika, ok, this is tangential: Have you =3D> >tried =
>the current NT386GNU cm3?
> > 
> >I meant, more about what "oper=
>ating systems" that Modula-3 does not support=3D> > do people here use, wou=
>ld like to see Modula-3 on. Or maybe I meant both.<=3D> >BR>> > 
> =
>>Speaking of the "4" in FreeBSD4:
> > 
> >Has FreeBSD, and the o=
>ther BSDs, really broken backward compat?
> >They really change int=
>erfaces a lot such that binaries built with current h=3D> >eaders/libs won'=
>t run on older versions?
> >And there isn't an easy way on current platf=
>orms to build something using o=3D> >lder tools to run on older and newer p=
>latforms?
> >Look at Windows for example. If you call a "new" function d=
>irectly, you wil=3D> >l fail to load on older platforms. So either don't ca=
>ll them, or use LoadLi=3D> >brary/GetProcAddress. Structures almost never c=
>hange size, though there is =3D> >some screwiness there, stuff like:
> >=
> 
> >struct FOO {
  size_t Size;
> >  int Field1;R>> >#if VERSION > 1234
> >  int Field2;
> >#endif
> >};R>> > 
> >I think it should be more like:
> > 
> >struct=
> FOO {
  size_t Size;
> >  int Field1;
> >#if VERSION &g=
>t; 1234
> >  int Field2;
> >#endif
> >};
> > 
> >s=
>truct FOO_V1{
  size_t Size;
> >  int Field1;
> >};
>=
> > 
> >struct FOO_V2 {
  size_t Size;
> >  int Fiel=
>d1;
> >  int Field2;
> >};
> > 
> >#if VERSION > 1=
>234
> >typedef FOO_V2 FOO;
> >#else
> >typedef FOO_V1 FOO;
> >#=
>endif
> > 
> >I understand that binaries built on the older plat=
>form will continue to wor=3D> >k on the newer platform.
> >That is one t=
>hing.
> >But it is also useful to be able to build binaries on the newer=
> platform th=3D> >at will on the older platform.
> >Apple also invests a=
> bunch here.
> > 
> >Well, ok, if it was really "bad", there'd b=
>e FreeBSD5, 6, 7.
> >I guess maybe they broke this stuff sometimes but h=
>aven't in a while?
> >That you can build FreeBSD4 binaries on FreeBSD7 a=
>nd the run down to 4?
> > 
> >And then, same questions about Ope=
>nBSD and NetBSD.
> >I understand -- I could/must go and install a bajill=
>ion operating systems a=3D> >nd test and find out, but I don't expect to sp=
>end the time that way and pus=3D> >h comes to shove, any BSD (and Linux, So=
>laris, NT, CE, etc.) variants I int=3D> >roduce will have no version number=
> in them, will be built on whatever I hav=3D> >e, and it will be unknown if=
> they work on older. And maybe something will m=3D> >aterialize to be more =
>portable, like interfacing to the Posix via C instead=3D> > of cloned heade=
>rs.
> > 
> > - Jay


> >> >
>> >
> >> To: jayk123 at hotmail.com
> CC: m3devel at elegosoft.comR>> Subj=3D> >ect: Re: [M3devel] which platforms? 
> Date: Thu, 15=
> May 2008 14:30:3=3D> >6 -0700
> From: mika at async.caltech.edu
>=
> 
> here it is: >R>> 
> FreeBSD4
> PPC_DARWIN>> NT386GNU
> LINUXL=3D> >IBC6
> 
> I386_DARWIN coming=
> soon
> 
> Tony Hosking=3D> > writes:
> >
> >=
>--Apple-Mail-4-631028010
> >Cont=3D> >ent-Type: text/plain;
>=
>; > charset=3D3DUS-ASCII;
> > format=3D> >=3D3Dflowed;
> =
>> delsp=3D3Dyes
> >Content-Transfer-Encoding: =3D> >7bit
>=
>; >
> >SOLgnu
> >PPC_DARWIN
> >I38=3D> >6_DAR=
>WIN
> >AMD64_DARWIN
> >LINUXLIBC6
> >I'd li=3D> =
>>ke AMD64_LINUX, SPARC64_SOLARISN but no time right now to devote 
> =
>&=3D> >gt;to them.
> >
> >On May 14, 2008, at 1:25 PM, Ja=
>y wrote=3D> >:
> >
> >> What do people run?
> &g=
>t;> In par=3D> >ticular: NetBSD? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN=
>? 
> >>=3D> > I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM=
>_WINCE? AMD64_NT?
>=3D> > >>
> >> Just curious, I'l=
>l probably bring up whatever I =3D> >can, it's fun, and 
> >> y=
>es, get back and fix AMD64_LINUX to h=3D> >ave
> >> garbage col=
>lection, NT386GNU and NT386 tests, cross-pl=3D> >atform sets, 
> >=
>> setup some Tinderboxes, etc...
> >&=3D> >gt;
> >>=
> (AMD64_NT: the gcc available for this includes a bunch=3D> > of patches, <=
>BR>> >> so I'm inclined to either wait for them to g=3D> >o upstre=
>am,
> >> or seek an alternate route such as "port" the =3D> >in=
>-proc backend, llvm, 
> >> generate C, or maybe write an inte=
>=3D> >rpreter for the IL;
> >> and "porting" the backend is pro=
>bably =3D> >best preceded by a) x86 
> >> LONGINT support b) ot=
>her x86 targ=3D> >ets "for practise", at least one,
> >> though=
> regarding .obj fi=3D> >le formats, that would be tangential.)
> >=
>>
> >> - =3D> >Jay
> >>
> >>
>=
> >>
> >>
=3D> >> >
> >
> >--Ap=
>ple-Mail-4-631028010
> >Con=3D> >tent-Type: text/html;
> >=
>; charset=3D3DUS-ASCII
> >Content-T=3D> >ransfer-Encoding: quoted-=
>printable
> >
> ><html><=3D> >;body style=3D3D3D"=
>word-wrap: break-word; -webkit-nbsp-mode: space; =3D3D
&g=3D> >t; >-w=
>ebkit-line-break: after-white-space; "><div =3D3D
> >=3D> >a=
>pple-content-edited=3D3D3D"true"><span class=3D3D3D"Apple-style-span"=
> =3D> >=3D3D
> >style=3D3D3D"border-collapse: separate; border-spa=
>cing: 0px 0=3D> >px; color: =3D3D
> >rgb(0, 0, 0); font-family: He=
>lvetica; font-size:=3D> > 12px; font-style: =3D3D
> >normal; font-=
>variant: normal; font-weigh=3D> >t: normal; letter-spacing: =3D3D
> &=
>gt;normal; line-height: normal; tex=3D> >t-align: auto; =3D3D
> >-=
>khtml-text-decorations-in-effect: none; tex=3D> >t-indent: 0px; =3D3D
&g=
>t; >-apple-text-size-adjust: auto; text-transfor=3D> >m: none; orphans: =
>2; =3D3D
> >white-space: normal; widows: 2; word-s=3D> >pacing: 0p=
>x; "><div =3D3D
> >style=3D3D3D"word-wrap: break-word;=3D> >=
> -khtml-nbsp-mode: space; =3D3D
> >-khtml-line-break: after-white-=
>sp=3D> >ace; "><span class=3D3D3D"Apple-style-span" =3D3D
> >=
>;style=3D3D3D"=3D> >border-collapse: separate; border-spacing: 0px 0px; col=
>or: =3D3D
> >=3D> >rgb(0, 0, 0); font-family: Helvetica; font-size=
>: 12px; font-style: =3D3D
&=3D> >gt; >normal; font-variant: normal; f=
>ont-weight: normal; letter-spacing: =3D> >=3D3D
> >normal; line-he=
>ight: normal; text-align: auto; =3D3D
> =3D> >>-khtml-text-decorat=
>ions-in-effect: none; text-indent: 0px; =3D3D
> =3D> >>-apple-text=
>-size-adjust: auto; text-transform: none; orphans: 2; =3D3D >>> &=
>gt;white-space: normal; widows: 2; word-spacing: 0px; =3D3D
> &g=3D> =
>>t;">SOLgnu</span></div><div style=3D3D3D"word-wrap: brea=
>k-w=3D> >ord; =3D3D
> >-khtml-nbsp-mode: space; -khtml-line-break:=
> after-whit=3D> >e-space; =3D3D
> >">PPC_DARWIN</div><=
>div style=3D3D3D"word=3D> >-wrap: break-word; -khtml-nbsp-mode: =3D3D
&g=
>t; >space; -khtml-line-bre=3D> >ak: after-white-space; ">I386_DARWIN&=
>lt;/div><div =3D3D
> >=3D> >style=3D3D3D"word-wrap: break-wo=
>rd; -khtml-nbsp-mode: space; =3D3D
> >=3D> >-khtml-line-break: aft=
>er-white-space; ">AMD64_DARWIN</div><div =3D> >=3D3D
> &g=
>t;style=3D3D3D"word-wrap: break-word; -khtml-nbsp-mode: space; =3D> >=3D3D<=
>BR>> >-khtml-line-break: after-white-space; ">LINUXLIBC6</d=3D>=
> >iv><div =3D3D
> >style=3D3D3D"word-wrap: break-word; -khtm=
>l-nbsp=3D> >-mode: space; =3D3D
> >-khtml-line-break: after-white-=
>space; ">I'=3D> >d like AMD64_LINUX,&nbsp;<span =3D3D
> >=
>;class=3D3D3D"Apple-styl=3D> >e-span" style=3D3D3D"font-family: Tahoma; fon=
>t-size: =3D3D
> >13px; "&=3D> >gt;SPARC64_SOLARISN but no time rig=
>ht now to devote to =3D3D
> >them=3D> >.</span></div>&=
>lt;/span></div><br><div><=3D> >;div>On May 14, 20=
>08, at 1:25 =3D3D
> >PM, Jay wrote:</div>=3D> ><br class=
>=3D3D3D"Apple-interchange-newline"><blockquote =3D3D
> =3D> >&g=
>t;type=3D3D3D"cite"><span class=3D3D3D"Apple-style-span" style=3D3D3D=
>"bor=3D> >der-collapse: =3D3D
> >separate; color: rgb(0, 0, 0); fo=
>nt-family: H=3D> >elvetica; font-size: 12px; =3D3D
> >font-style: =
>normal; font-variant=3D> >: normal; font-weight: normal; =3D3D
> >=
>letter-spacing: normal; line=3D> >-height: normal; orphans: 2; text-align: =
>=3D3D
> >auto; text-indent:=3D> > 0px; text-transform: none; white=
>-space: normal; =3D3D
> >widows: 2;=3D> > word-spacing: 0px; -webk=
>it-border-horizontal-spacing: 0px; =3D3D
> >=3D> >;-webkit-border-v=
>ertical-spacing: 0px; =3D3D
> >-webkit-text-decorat=3D> >ions-in-e=
>ffect: none; -webkit-text-size-adjust: =3D3D
> >auto; -webk=3D> >i=
>t-text-stroke-width: 0; "><div class=3D3D3D"hmmessage" =3D3D
> =
>>=3D> >;style=3D3D3D"font-size: 10pt; font-family: Tahoma; ">What do p=
>eople =3D3D >R>> >run?<br>In particular: NetBSD? OpenBSD?=
> Sparc32? Sparc64? =3D> >PPC64_DARWIN? =3D3D
> >I386_SOLARIS? AMD6=
>4_SOLARIS? SPARC64_SOLARIS?=3D> > ARM_WINCE? =3D3D
> >AMD64_NT?<=
>;br>&nbsp;<br>Just cur=3D> >ious, I'll probably bring up whate=
>ver I =3D3D
> >can, it's fun, and =3D> >yes, get back and fix AMD6=
>4_LINUX to have<br>garbage =3D3D
> >=3D> >collection, NT386G=
>NU and NT386 tests,&nbsp;cross-platform sets, setup =3D> >=3D3D
>=
> >some Tinderboxes, etc...<br>&nbsp;<br>(AMD6=3D> >4_NT:=
> the gcc available for =3D3D
> >this includes a bunch of patche=3D=
>> >s, so I'm inclined to either wait for =3D3D
> >them to go upstr=
>eam,&=3D> >lt;br>or seek an alternate route such as "port" the =3D3D
=
>> >in-p=3D> >roc backend, llvm, generate C, or maybe write an interpr=
>eter for the =3D3D >>> >IL;<br>and "porting" the backend=
> is probably best preceded =3D> >by a) x86 =3D3D
> >LONGINT suppor=
>t b) other x86 targets "for practis=3D> >e", at least =3D3D
> >one=
>,<br>though regarding .obj file forma=3D> >ts, that would be =3D3D>> >tangential.)<br>&nbsp;<br>=3D> >;&nbsp;- =3D3D=
>
> >Jay<br><br><br><br><=3D> >;br><=
>;/div></span></blockquote></div><br>&l=3D> >t;/b=
>ody></html>=3D3D
> >
> >--Apple-Mail-4-6310280=
>=3D> >10--

> >=3D> >> >--_14c076c4-fb7c-48b0-b705-2e38=
>d4b4a333_--=
>
>--_a9d87328-63f1-414c-abcb-03c34a9cee30_
>Content-Type: text/html; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>
>
>
>
>Wow that is crazy.

>The "OS" is backwards compatible.

>The tools -- or at least the headers/libs -- are not backwards compati=
>ble.

>They apparently don't produce binaries that run on older systems.

> 

>Hm, so I did some diffing among
m3-libs\m3core\src\unix\freebsd-*

>they are all amost identical.
and almost all compatible.
Freebsd-1 to=
> -2 is the least compatible.
otherwise the only actual difference I see =
>is
 in Usignal sa_flags and sa_mask getting reversed.
 and =
>sigcontext changed.

>
Otherwise it's mostly things like long vs. unsigned_long,
int64_t vs=
>. quad_t, short vs. int16_t.

>
The DIR record grew, but as long as it is not implemented
in Modula-=
>3 and the new fields not access, no matter.

>Oh one errno value changed.

>Sometimes some types or functions got added, but
 that is ok.

> 

>Maybe more research at a might later date...

> 

> - Jay



>
>

>

>> To: jayk123 at hotmail.com
> CC: m3devel at elegosoft.com
> Subj=
>ect: Re: [M3devel] which platforms? and questions about FreeBSD versioning =
>
> Date: Thu, 15 May 2008 22:54:28 -0700
> From: mika at async.cal=
>tech.edu
> 
> 
> No, sorry, haven't gotten around to test=
>ing the current NT386GNU
> cm3... I have a lot of version synchronizi=
>ng to do, unfortunately :(
> 
> Yes, FreeBSD is backwards-compa=
>tible, *not* forwards-compatible.
> That is, you can build even fairl=
>y complex software packages on an old
> FreeBSD system and expect it =
>to run on the latest release. You cannot,
> as a general rule, build =
>anything on a newer system and expect it to work
> on an older one. T=
>here must be "some" way of doing it that way, but
> I don't know what=
> it is, and I don't know if it's very well supported.
> I keep FreeBS=
>D 4.x systems around for precisely this reason: the binaries
> compil=
>ed there work fine on 5.x and 6.x (as far as I have tested). Not
> th=
>e other way around! In fact it has never worked the other way, as 
> =
>long as I can remember, with FreeBSD.
> 
> This is also why I s=
>uggest that a "FreeBSD4" bootstrap should actually
> be built on Free=
>BSD 4.x and not 5.x, 6.x, or 7.x!
> 
> Mika
> 
> Ja=
>y writes:
> >--_14c076c4-fb7c-48b0-b705-2e38d4b4a333_
> >=
>Content-Type: text/plain; charset=3D"iso-8859-1"
> >Content-Transf=
>er-Encoding: quoted-printable
> >
> >Mika, ok, this is ta=
>ngential: Have you tried the current NT386GNU cm3?
> >=3D20
>=
>; >I meant, more about what "operating systems" that Modula-3 does not s=
>upport=3D
> > do people here use, would like to see Modula-3 on. O=
>r maybe I meant both.
> >=3D20
> >Speaking of the "4" in =
>FreeBSD4:
> >=3D20
> >Has FreeBSD, and the other BSDs, re=
>ally broken backward compat?
> >They really change interfaces a lo=
>t such that binaries built with current h=3D
> >eaders/libs won't =
>run on older versions?
> >And there isn't an easy way on current p=
>latforms to build something using o=3D
> >lder tools to run on old=
>er and newer platforms?
> >Look at Windows for example. If you cal=
>l a "new" function directly, you wil=3D
> >l fail to load on older=
> platforms. So either don't call them, or use LoadLi=3D
> >brary/G=
>etProcAddress. Structures almost never change size, though there is =3D
=
>> >some screwiness there, stuff like:
> >=3D20
> >s=
>truct FOO { size_t Size;
> > int Field1;
> >#if VERSION &=
>gt; 1234
> > int Field2;
> >#endif
> >};
>=
> >=3D20
> >I think it should be more like:
> >=3D20>> >struct FOO { size_t Size;
> > int Field1;
> >#i=
>f VERSION > 1234
> > int Field2;
> >#endif
> >=
>;};
> >=3D20
> >struct FOO_V1{ size_t Size;
> > =
>int Field1;
> >};
> >=3D20
> >struct FOO_V2 { si=
>ze_t Size;
> > int Field1;
> > int Field2;
> >};=
>
> >=3D20
> >#if VERSION > 1234
> >typedef FO=
>O_V2 FOO;
> >#else
> >typedef FOO_V1 FOO;
> >#en=
>dif
> >=3D20
> >I understand that binaries built on the o=
>lder platform will continue to wor=3D
> >k on the newer platform.<=
>BR>> >That is one thing.
> >But it is also useful to be able=
> to build binaries on the newer platform th=3D
> >at will on the o=
>lder platform.
> >Apple also invests a bunch here.
> >=3D=
>20
> >Well, ok, if it was really "bad", there'd be FreeBSD5, 6, 7.=
>
> >I guess maybe they broke this stuff sometimes but haven't in a=
> while?
> >That you can build FreeBSD4 binaries on FreeBSD7 and th=
>e run down to 4?
> >=3D20
> >And then, same questions abo=
>ut OpenBSD and NetBSD.
> >I understand -- I could/must go and inst=
>all a bajillion operating systems a=3D
> >nd test and find out, bu=
>t I don't expect to spend the time that way and pus=3D
> >h comes =
>to shove, any BSD (and Linux, Solaris, NT, CE, etc.) variants I int=3D
&=
>gt; >roduce will have no version number in them, will be built on whatev=
>er I hav=3D
> >e, and it will be unknown if they work on older. An=
>d maybe something will m=3D
> >aterialize to be more portable, lik=
>e interfacing to the Posix via C instead=3D
> > of cloned headers.=
>
> >=3D20
> > - Jay
> >
> >
> >=
>;
> >> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com>=
>; Subject: Re: [M3devel=3D
> >] which platforms? > Date: Thu, 1=
>5 May 2008 14:30:36 -0700> From: mika at asyn=3D
> >c.caltech.edu&=
>gt; > here it is:> > FreeBSD4> PPC_DARWIN> NT386GNU> LINU=
>XLIBC6>=3D
> > > I386_DARWIN coming soon> > Tony Hoski=
>ng writes:> >> >--Apple-Mail-4-6310=3D
> >28010> &g=
>t;Content-Type: text/plain;> > charset=3D3DUS-ASCII;> > format=
>=3D3Dflowed=3D
> >;> > delsp=3D3Dyes> >Content-Transfe=
>r-Encoding: 7bit> >> >SOLgnu> >PPC_DARWIN=3D
> >=
>> >I386_DARWIN> >AMD64_DARWIN> >LINUXLIBC6> >I'd li=
>ke AMD64_LINUX, SPARC64_=3D
> >SOLARISN but no time right now to d=
>evote > >to them.> >> >On May 14, 2008, =3D
> >a=
>t 1:25 PM, Jay wrote:> >> >> What do people run?> >>=
>; In particular: NetBSD=3D
> >? OpenBSD? Sparc32? Sparc64? PPC64_D=
>ARWIN? > >> I386_SOLARIS? AMD64_SOLARIS=3D
> >? SPARC64_S=
>OLARIS? ARM_WINCE? AMD64_NT?> >>> >> Just curious, I'll p=
>robably=3D
> > bring up whatever I can, it's fun, and > >>=
>; yes, get back and fix AMD64_LI=3D
> >NUX to have> >> ga=
>rbage collection, NT386GNU and NT386 tests, cross-platfor=3D
> >m =
>sets, > >> setup some Tinderboxes, etc...> >>> >>=
>; (AMD64_NT: the gcc avai=3D
> >lable for this includes a bunch of=
> patches, > >> so I'm inclined to either =3D
> >wait for =
>them to go upstream,> >> or seek an alternate route such as "port"=
>=3D
> > the in-proc backend, llvm, > >> generate C, or ma=
>ybe write an interpreter =3D
> >for the IL;> >> and "port=
>ing" the backend is probably best preceded by a) x=3D
> >86 > &=
>gt;> LONGINT support b) other x86 targets "for practise", at least one,&=
>gt;=3D
> > >> though regarding .obj file formats, that would=
> be tangential.)> >>> >> =3D
> >- Jay> >&g=
>t;> >>> >>> >>> >> >> >--Apple=
>-Mail-4-631028010> >Content-Type: text=3D
> >/html;> >=
> charset=3D3DUS-ASCII> >Content-Transfer-Encoding: quoted-printable&g=
>t;=3D
> > >> ><html><body style=3D3D3D"word-wrap=
>: break-word; -webkit-nbsp-mode: space=3D
> >; =3D3D> >-webk=
>it-line-break: after-white-space; "><div =3D3D> >apple-content-=
>e=3D
> >dited=3D3D3D"true"><span class=3D3D3D"Apple-style-sp=
>an" =3D3D> >style=3D3D3D"border=3D
> >-collapse: separate; b=
>order-spacing: 0px 0px; color: =3D3D> >rgb(0, 0, 0); fo=3D
> &g=
>t;nt-family: Helvetica; font-size: 12px; font-style: =3D3D> >normal; =
>font-varia=3D
> >nt: normal; font-weight: normal; letter-spacing: =
>=3D3D> >normal; line-height:=3D
> > normal; text-align: auto=
>; =3D3D> >-khtml-text-decorations-in-effect: none; t=3D
> >e=
>xt-indent: 0px; =3D3D> >-apple-text-size-adjust: auto; text-transform=
>: none;=3D
> > orphans: 2; =3D3D> >white-space: normal; wido=
>ws: 2; word-spacing: 0px; "><di=3D
> >v =3D3D> >style=
>=3D3D3D"word-wrap: break-word; -khtml-nbsp-mode: space; =3D3D> >-k=3D=
>
> >html-line-break: after-white-space; "><span class=3D3D3D=
>"Apple-style-span" =3D
> >=3D3D> >style=3D3D3D"border-collap=
>se: separate; border-spacing: 0px 0px; color:=3D
> > =3D3D> >=
>;rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =3D
=
>> >=3D3D> >normal; font-variant: normal; font-weight: normal; l=
>etter-spacing: =3D
> >=3D3D> >normal; line-height: normal; t=
>ext-align: auto; =3D3D> >-khtml-text-deco=3D
> >rations-in-e=
>ffect: none; text-indent: 0px; =3D3D> >-apple-text-size-adjust: a=3D<=
>BR>> >uto; text-transform: none; orphans: 2; =3D3D> >white-spac=
>e: normal; widows: 2=3D
> >; word-spacing: 0px; =3D3D> >">=
>;SOLgnu</span></div><div style=3D3D3D"word-wrap: =3D
>=
> >break-word; =3D3D> >-khtml-nbsp-mode: space; -khtml-line-break: =
>after-white-s=3D
> >pace; =3D3D> >">PPC_DARWIN</div>=
>;<div style=3D3D3D"word-wrap: break-word; -khtml=3D
> >-nbsp-mo=
>de: =3D3D> >space; -khtml-line-break: after-white-space; ">I386_DA=
>RWI=3D
> >N</div><div =3D3D> >style=3D3D3D"word-wra=
>p: break-word; -khtml-nbsp-mode: space=3D
> >; =3D3D> >-khtm=
>l-line-break: after-white-space; ">AMD64_DARWIN</div><div =3D3D=
>>=3D
> > >style=3D3D3D"word-wrap: break-word; -khtml-nbsp-mo=
>de: space; =3D3D> >-khtml-l=3D
> >ine-break: after-white-spa=
>ce; ">LINUXLIBC6</div><div =3D3D> >style=3D3D3D"word-=3D<=
>BR>> >wrap: break-word; -khtml-nbsp-mode: space; =3D3D> >-khtml=
>-line-break: after-w=3D
> >hite-space; ">I'd like AMD64_LINUX,&=
>amp;nbsp;<span =3D3D> >class=3D3D3D"Apple-style=3D
> >-sp=
>an" style=3D3D3D"font-family: Tahoma; font-size: =3D3D> >13px; ">S=
>PARC64_SOL=3D
> >ARISN but no time right now to devote to =3D3D>=
>; >them.</span></div></span></d=3D
> >iv&g=
>t;<br><div><div>On May 14, 2008, at 1:25 =3D3D> >PM=
>, Jay wrote:</div><br cla=3D
> >ss=3D3D3D"Apple-interchan=
>ge-newline"><blockquote =3D3D> >type=3D3D3D"cite"><span =
>=3D
> >class=3D3D3D"Apple-style-span" style=3D3D3D"border-collapse=
>: =3D3D> >separate; co=3D
> >lor: rgb(0, 0, 0); font-family:=
> Helvetica; font-size: 12px; =3D3D> >font-styl=3D
> >e: norm=
>al; font-variant: normal; font-weight: normal; =3D3D> >letter-spacing=
>:=3D
> > normal; line-height: normal; orphans: 2; text-align: =3D3=
>D> >auto; text-inde=3D
> >nt: 0px; text-transform: none; whi=
>te-space: normal; =3D3D> >widows: 2; word-s=3D
> >pacing: 0p=
>x; -webkit-border-horizontal-spacing: 0px; =3D3D> >-webkit-border-v=
>=3D
> >ertical-spacing: 0px; =3D3D> >-webkit-text-decoration=
>s-in-effect: none; -webk=3D
> >it-text-size-adjust: =3D3D> >=
>auto; -webkit-text-stroke-width: 0; "><div class=3D
> >=3D3D=
>3D"hmmessage" =3D3D> >style=3D3D3D"font-size: 10pt; font-family: Taho=
>ma; ">W=3D
> >hat do people =3D3D> >run?<br>In part=
>icular: NetBSD? OpenBSD? Sparc32? Sparc6=3D
> >4? PPC64_DARWIN? =
>=3D3D> >I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM_WI=3D
&g=
>t; >NCE? =3D3D> >AMD64_NT?<br>&nbsp;<br>Just curio=
>us, I'll probably bring up what=3D
> >ever I =3D3D> >can, it=
>'s fun, and yes, get back and fix AMD64_LINUX to have<b=3D
> >r=
>>garbage =3D3D> >collection, NT386GNU and NT386 tests,&nbsp;cr=
>oss-platform s=3D
> >ets, setup =3D3D> >some Tinderboxes, et=
>c...<br>&nbsp;<br>(AMD64_NT: the gcc a=3D
> >vaila=
>ble for =3D3D> >this includes a bunch of patches, so I'm inclined to =
>eit=3D
> >her wait for =3D3D> >them to go upstream,<br>=
>;or seek an alternate route such =3D
> >as "port" the =3D3D> &g=
>t;in-proc backend, llvm, generate C, or maybe write an in=3D
> >te=
>rpreter for the =3D3D> >IL;<br>and "porting" the backend is pro=
>bably best p=3D
> >receded by a) x86 =3D3D> >LONGINT support=
> b) other x86 targets "for practise"=3D
> >, at least =3D3D> &g=
>t;one,<br>though regarding .obj file formats, that would be =3D
&g=
>t; >=3D3D> >tangential.)<br>&nbsp;<br>&nbsp;- =
>=3D3D> >Jay<br><br><br><br><br></div=
>>=3D
> ></span></blockquote></div><br>&=
>lt;/body></html>=3D3D> >> >--Apple-Mail-4-6310280=3DR>> >10--=3D
> >
> >--_14c076c4-fb7c-48b0-b705-2e38=
>d4b4a333_
> >Content-Type: text/html; charset=3D"iso-8859-1"
&g=
>t; >Content-Transfer-Encoding: quoted-printable
> >
> >=
>;<html>
> ><head>
> ><style>
> &g=
>t;.hmmessage P
> >{
> >margin:0px;
> >padding:0p=
>x
> >}
> >body.hmmessage
> >{
> >FONT-S=
>IZE: 10pt;
> >FONT-FAMILY:Tahoma
> >}
> ></st=
>yle>
> ></head>
> ><body class=3D3D'hmmessage=
>'>Mika, ok, this is&nbsp;tangential:&nbsp;Have you =3D
> &=
>gt;tried the current NT386GNU cm3?<BR>
> >&nbsp;<BR&g=
>t;
> >I meant, more about what "operating systems" that Modula-3 d=
>oes not support=3D
> > do people here use, would like to see Modul=
>a-3 on. Or maybe I meant both.<=3D
> >BR>
> >&n=
>bsp;<BR>
> >Speaking of the "4" in FreeBSD4:<BR>
&g=
>t; >&nbsp;<BR>
> >Has FreeBSD, and the other BSDs, re=
>ally broken&nbsp;backward compat?<BR>
> >They really cha=
>nge interfaces a lot such that binaries built with current h=3D
> >=
>;eaders/libs won't run on older versions?<BR>
> >And there i=
>sn't an easy way on current platforms to build something using o=3D
>=
> >lder tools to run on older and newer platforms?<BR>
> >=
>Look at Windows for example. If you call a "new" function directly, you wil=
>=3D
> >l fail to load on older platforms. So either don't call the=
>m, or use LoadLi=3D
> >brary/GetProcAddress. Structures almost nev=
>er change size, though there is =3D
> >some screwiness there, stuf=
>f like:<BR>
> >&nbsp;<BR>
> >struct FOO {=
><BR>&nbsp; size_t Size;<BR>
> >&nbsp; int Fiel=
>d1;<BR>
> >#if VERSION &gt; 1234<BR>
> >&=
>amp;nbsp; int Field2;<BR>
> >#endif<BR>
> >};=
><BR>
> >&nbsp;<BR>
> >I think it should b=
>e more like:<BR>
> >&nbsp;<BR>
> >struct =
>FOO {<BR>&nbsp; size_t Size;<BR>
> >&nbsp; int=
> Field1;<BR>
> >#if VERSION &gt; 1234<BR>
> =
>>&nbsp; int Field2;<BR>
> >#endif<BR>
> &=
>gt;};<BR>
> >&nbsp;<BR>
> >struct FOO_V1{=
><BR>&nbsp; size_t Size;<BR>
> >&nbsp; int Fiel=
>d1;<BR>
> >};<BR>
> >&nbsp;<BR>
=
>> >struct FOO_V2 {<BR>&nbsp; size_t Size;<BR>
>=
> >&nbsp; int Field1;<BR>
> >&nbsp; int Field2;<=
>;BR>
> >};<BR>
> >&nbsp;<BR>
> &=
>gt;#if VERSION &gt; 1234<BR>
> >typedef FOO_V2 FOO;<B=
>R>
> >#else<BR>
> >typedef FOO_V1 FOO;<BR>=
>
> >#endif<BR>
> >&nbsp;<BR>
> >=
>I understand that binaries built on the older platform will continue to wor=
>=3D
> >k on the newer platform.<BR>
> >That is one =
>thing.<BR>
> >But it is also useful to be able to build bina=
>ries on the newer platform th=3D
> >at will on the older platform.=
><BR>
> >Apple also invests a bunch here.<BR>
> &=
>gt;&nbsp;<BR>
> >Well, ok, if it was really "bad", there=
>'d be FreeBSD5, 6, 7.<BR>
> >I guess maybe they broke this s=
>tuff sometimes but haven't in a while?<BR>
> >That you can b=
>uild FreeBSD4 binaries on FreeBSD7 and the run down to 4?<BR>
>=
> >&nbsp;<BR>
> >And then, same questions about OpenBS=
>D and NetBSD.<BR>
> >I understand -- I could/must go and ins=
>tall a bajillion operating systems a=3D
> >nd test and find out, b=
>ut I don't expect to spend the time that way and pus=3D
> >h comes=
> to shove, any BSD (and Linux, Solaris, NT, CE, etc.) variants I int=3D
=
>> >roduce will have no version number in them, will be built on whate=
>ver I hav=3D
> >e, and it will be unknown if they work on older. A=
>nd maybe something will m=3D
> >aterialize to be more portable, li=
>ke interfacing to the Posix via C instead=3D
> > of cloned headers=
>.<BR>
> >&nbsp;<BR>
> >&nbsp;- Jay<=
>;BR><BR><BR>
> >
> ><HR id=3D3DstopSpel=
>ling>
> ><BR>
> >&gt; To: jayk123 at hotmail.co=
>m<BR>&gt; CC: m3devel at elegosoft.com<BR>&gt; Subj=3D
=
>> >ect: Re: [M3devel] which platforms? <BR>&gt; Date: Thu, =
>15 May 2008 14:30:3=3D
> >6 -0700<BR>&gt; From: mika at asy=
>nc.caltech.edu<BR>&gt; <BR>&gt; here it is:<B=3D
=
>> >R>&gt; <BR>&gt; FreeBSD4<BR>&gt; PPC_DA=
>RWIN<BR>&gt; NT386GNU<BR>&gt; LINUXL=3D
> >IBC=
>6<BR>&gt; <BR>&gt; I386_DARWIN coming soon<BR>&am=
>p;gt; <BR>&gt; Tony Hosking=3D
> > writes:<BR>&=
>;gt; &gt;<BR>&gt; &gt;--Apple-Mail-4-631028010<BR>&=
>amp;gt; &gt;Cont=3D
> >ent-Type: text/plain;<BR>&gt;=
> &gt; charset=3D3DUS-ASCII;<BR>&gt; &gt; format=3D
>=
>; >=3D3Dflowed;<BR>&gt; &gt; delsp=3D3Dyes<BR>&g=
>t; &gt;Content-Transfer-Encoding: =3D
> >7bit<BR>&gt=
>; &gt;<BR>&gt; &gt;SOLgnu<BR>&gt; &gt;PPC_D=
>ARWIN<BR>&gt; &gt;I38=3D
> >6_DARWIN<BR>&g=
>t; &gt;AMD64_DARWIN<BR>&gt; &gt;LINUXLIBC6<BR>&=
>gt; &gt;I'd li=3D
> >ke AMD64_LINUX, SPARC64_SOLARISN but no t=
>ime right now to devote <BR>&gt; &=3D
> >gt;to them.=
><BR>&gt; &gt;<BR>&gt; &gt;On May 14, 2008, at 1=
>:25 PM, Jay wrote=3D
> >:<BR>&gt; &gt;<BR>&=
>;gt; &gt;&gt; What do people run?<BR>&gt; &gt;&gt=
>; In par=3D
> >ticular: NetBSD? OpenBSD? Sparc32? Sparc64? PPC64_D=
>ARWIN? <BR>&gt; &gt;&gt;=3D
> > I386_SOLARIS? AM=
>D64_SOLARIS? SPARC64_SOLARIS? ARM_WINCE? AMD64_NT?<BR>&gt;=3D
=
>> > &gt;&gt;<BR>&gt; &gt;&gt; Just curious,=
> I'll probably bring up whatever I =3D
> >can, it's fun, and <B=
>R>&gt; &gt;&gt; yes, get back and fix AMD64_LINUX to h=3D>> >ave<BR>&gt; &gt;&gt; garbage collection, NT386G=
>NU and NT386 tests, cross-pl=3D
> >atform sets, <BR>&gt;=
> &gt;&gt; setup some Tinderboxes, etc...<BR>&gt; &gt;=
>&=3D
> >gt;<BR>&gt; &gt;&gt; (AMD64_NT: the =
>gcc available for this includes a bunch=3D
> > of patches, <BR&=
>gt;&gt; &gt;&gt; so I'm inclined to either wait for them to g=
>=3D
> >o upstream,<BR>&gt; &gt;&gt; or seek an a=
>lternate route such as "port" the =3D
> >in-proc backend, llvm, &l=
>t;BR>&gt; &gt;&gt; generate C, or maybe write an inte=3D
=
>> >rpreter for the IL;<BR>&gt; &gt;&gt; and "portin=
>g" the backend is probably =3D
> >best preceded by a) x86 <BR&g=
>t;&gt; &gt;&gt; LONGINT support b) other x86 targ=3D
> &g=
>t;ets "for practise", at least one,<BR>&gt; &gt;&gt; thou=
>gh regarding .obj fi=3D
> >le formats, that would be tangential.)&=
>lt;BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt; - =3D=
>
> >Jay<BR>&gt; &gt;&gt;<BR>&gt; &=
>gt;&gt;<BR>&gt; &gt;&gt;<BR>&gt; &gt;&a=
>mp;gt;<BR>=3D
> >&gt; &gt;<BR>&gt; &gt=
>;<BR>&gt; &gt;--Apple-Mail-4-631028010<BR>&gt; &=
>;gt;Con=3D
> >tent-Type: text/html;<BR>&gt; &gt; cha=
>rset=3D3DUS-ASCII<BR>&gt; &gt;Content-T=3D
> >ransfe=
>r-Encoding: quoted-printable<BR>&gt; &gt;<BR>&gt; &=
>amp;gt;&lt;html&gt;&lt=3D
> >;body style=3D3D3D"word-w=
>rap: break-word; -webkit-nbsp-mode: space; =3D3D<BR>&g=3D
>=
> >t; &gt;-webkit-line-break: after-white-space; "&gt;&lt;div=
> =3D3D<BR>&gt; &gt;=3D
> >apple-content-edited=3D3D3=
>D"true"&gt;&lt;span class=3D3D3D"Apple-style-span" =3D
> >=
>=3D3D<BR>&gt; &gt;style=3D3D3D"border-collapse: separate; bor=
>der-spacing: 0px 0=3D
> >px; color: =3D3D<BR>&gt; &g=
>t;rgb(0, 0, 0); font-family: Helvetica; font-size:=3D
> > 12px; fo=
>nt-style: =3D3D<BR>&gt; &gt;normal; font-variant: normal; fon=
>t-weigh=3D
> >t: normal; letter-spacing: =3D3D<BR>&gt; &=
>amp;gt;normal; line-height: normal; tex=3D
> >t-align: auto; =3D3D=
><BR>&gt; &gt;-khtml-text-decorations-in-effect: none; tex=3D<=
>BR>> >t-indent: 0px; =3D3D<BR>&gt; &gt;-apple-text-size=
>-adjust: auto; text-transfor=3D
> >m: none; orphans: 2; =3D3D<B=
>R>&gt; &gt;white-space: normal; widows: 2; word-s=3D
> >=
>;pacing: 0px; "&gt;&lt;div =3D3D<BR>&gt; &gt;style=3D=
>3D3D"word-wrap: break-word;=3D
> > -khtml-nbsp-mode: space; =3D3D&=
>lt;BR>&gt; &gt;-khtml-line-break: after-white-sp=3D
> >=
>ace; "&gt;&lt;span class=3D3D3D"Apple-style-span" =3D3D<BR>&a=
>mp;gt; &gt;style=3D3D3D"=3D
> >border-collapse: separate; bord=
>er-spacing: 0px 0px; color: =3D3D<BR>&gt; &gt;=3D
> >=
>;rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =3D3D&l=
>t;BR>&=3D
> >gt; &gt;normal; font-variant: normal; font=
>-weight: normal; letter-spacing: =3D
> >=3D3D<BR>&gt; &a=
>mp;gt;normal; line-height: normal; text-align: auto; =3D3D<BR>&gt=
>; =3D
> >&gt;-khtml-text-decorations-in-effect: none; text-ind=
>ent: 0px; =3D3D<BR>&gt; =3D
> >&gt;-apple-text-size-=
>adjust: auto; text-transform: none; orphans: 2; =3D3D<BR=3D
> >=
>>&gt; &gt;white-space: normal; widows: 2; word-spacing: 0px; =3D=
>3D<BR>&gt; &g=3D
> >t;"&gt;SOLgnu&lt;/span&a=
>mp;gt;&lt;/div&gt;&lt;div style=3D3D3D"word-wrap: break-w=3D>> >ord; =3D3D<BR>&gt; &gt;-khtml-nbsp-mode: space; -kh=
>tml-line-break: after-whit=3D
> >e-space; =3D3D<BR>&gt; =
>&gt;"&gt;PPC_DARWIN&lt;/div&gt;&lt;div style=3D3D3D"wor=
>d=3D
> >-wrap: break-word; -khtml-nbsp-mode: =3D3D<BR>&g=
>t; &gt;space; -khtml-line-bre=3D
> >ak: after-white-space; "&a=
>mp;gt;I386_DARWIN&lt;/div&gt;&lt;div =3D3D<BR>&gt; &a=
>mp;gt;=3D
> >style=3D3D3D"word-wrap: break-word; -khtml-nbsp-mode:=
> space; =3D3D<BR>&gt; &gt;=3D
> >-khtml-line-break: =
>after-white-space; "&gt;AMD64_DARWIN&lt;/div&gt;&lt;div =3D=
>
> >=3D3D<BR>&gt; &gt;style=3D3D3D"word-wrap: break-=
>word; -khtml-nbsp-mode: space; =3D
> >=3D3D<BR>&gt; &=
>;gt;-khtml-line-break: after-white-space; "&gt;LINUXLIBC6&lt;/d=3D<=
>BR>> >iv&gt;&lt;div =3D3D<BR>&gt; &gt;style=3D3=
>D3D"word-wrap: break-word; -khtml-nbsp=3D
> >-mode: space; =3D3D&l=
>t;BR>&gt; &gt;-khtml-line-break: after-white-space; "&gt;I'=
>=3D
> >d like AMD64_LINUX,&amp;nbsp;&lt;span =3D3D<BR&g=
>t;&gt; &gt;class=3D3D3D"Apple-styl=3D
> >e-span" style=3D3=
>D3D"font-family: Tahoma; font-size: =3D3D<BR>&gt; &gt;13px; "=
>&=3D
> >gt;SPARC64_SOLARISN but no time right now to devote to=
> =3D3D<BR>&gt; &gt;them=3D
> >.&lt;/span&gt;=
>&lt;/div&gt;&lt;/span&gt;&lt;/div&gt;&lt;br&=
>;gt;&lt;div&gt;&lt=3D
> >;div&gt;On May 14, 2008, =
>at 1:25 =3D3D<BR>&gt; &gt;PM, Jay wrote:&lt;/div&gt;=
>=3D
> >&lt;br class=3D3D3D"Apple-interchange-newline"&gt;&=
>amp;lt;blockquote =3D3D<BR>&gt; =3D
> >&gt;type=3D3D=
>3D"cite"&gt;&lt;span class=3D3D3D"Apple-style-span" style=3D3D3D"bo=
>r=3D
> >der-collapse: =3D3D<BR>&gt; &gt;separate; co=
>lor: rgb(0, 0, 0); font-family: H=3D
> >elvetica; font-size: 12px;=
> =3D3D<BR>&gt; &gt;font-style: normal; font-variant=3D
>=
>; >: normal; font-weight: normal; =3D3D<BR>&gt; &gt;letter=
>-spacing: normal; line=3D
> >-height: normal; orphans: 2; text-ali=
>gn: =3D3D<BR>&gt; &gt;auto; text-indent:=3D
> > 0px;=
> text-transform: none; white-space: normal; =3D3D<BR>&gt; &gt=
>;widows: 2;=3D
> > word-spacing: 0px; -webkit-border-horizontal-sp=
>acing: 0px; =3D3D<BR>&gt; &gt=3D
> >;-webkit-border-=
>vertical-spacing: 0px; =3D3D<BR>&gt; &gt;-webkit-text-decorat=
>=3D
> >ions-in-effect: none; -webkit-text-size-adjust: =3D3D<BR=
>>&gt; &gt;auto; -webk=3D
> >it-text-stroke-width: 0; "&=
>amp;gt;&lt;div class=3D3D3D"hmmessage" =3D3D<BR>&gt; &gt=
>=3D
> >;style=3D3D3D"font-size: 10pt; font-family: Tahoma; "&g=
>t;What do people =3D3D<B=3D
> >R>&gt; &gt;run?&l=
>t;br&gt;In particular: NetBSD? OpenBSD? Sparc32? Sparc64? =3D
> &=
>gt;PPC64_DARWIN? =3D3D<BR>&gt; &gt;I386_SOLARIS? AMD64_SOLARI=
>S? SPARC64_SOLARIS?=3D
> > ARM_WINCE? =3D3D<BR>&gt; &=
>;gt;AMD64_NT?&lt;br&gt;&amp;nbsp;&lt;br&gt;Just cur=3D<=
>BR>> >ious, I'll probably bring up whatever I =3D3D<BR>&gt;=
> &gt;can, it's fun, and =3D
> >yes, get back and fix AMD64_LIN=
>UX to have&lt;br&gt;garbage =3D3D<BR>&gt; &gt;=3D
=
>> >collection, NT386GNU and NT386 tests,&amp;nbsp;cross-platform =
>sets, setup =3D
> >=3D3D<BR>&gt; &gt;some Tinderboxe=
>s, etc...&lt;br&gt;&amp;nbsp;&lt;br&gt;(AMD6=3D
>=
> >4_NT: the gcc available for =3D3D<BR>&gt; &gt;this inclu=
>des a bunch of patche=3D
> >s, so I'm inclined to either wait for =
>=3D3D<BR>&gt; &gt;them to go upstream,&=3D
> >lt=
>;br&gt;or seek an alternate route such as "port" the =3D3D<BR>&am=
>p;gt; &gt;in-p=3D
> >roc backend, llvm, generate C, or maybe w=
>rite an interpreter for the =3D3D<BR=3D
> >>&gt; &gt=
>;IL;&lt;br&gt;and "porting" the backend is probably best preceded =
>=3D
> >by a) x86 =3D3D<BR>&gt; &gt;LONGINT support b=
>) other x86 targets "for practis=3D
> >e", at least =3D3D<BR>=
>;&gt; &gt;one,&lt;br&gt;though regarding .obj file forma=3D=
>
> >ts, that would be =3D3D<BR>&gt; &gt;tangential.)=
>&lt;br&gt;&amp;nbsp;&lt;br&gt=3D
> >;&amp;=
>nbsp;- =3D3D<BR>&gt; &gt;Jay&lt;br&gt;&lt;br&=
>gt;&lt;br&gt;&lt;br&gt;&lt=3D
> >;br&gt;&a=
>mp;lt;/div&gt;&lt;/span&gt;&lt;/blockquote&gt;&lt;/=
>div&gt;&lt;br&gt;&l=3D
> >t;/body&gt;&lt;/=
>html&gt;=3D3D<BR>&gt; &gt;<BR>&gt; &gt;--Ap=
>ple-Mail-4-6310280=3D
> >10--<BR><BR></body>
=
>> ></html>=3D
> >
> >--_14c076c4-fb7c-48b0-b7=
>05-2e38d4b4a333_--


>=
>
>--_a9d87328-63f1-414c-abcb-03c34a9cee30_--


From jayk123 at hotmail.com  Sun May 18 20:54:41 2008
From: jayk123 at hotmail.com (Jay)
Date: Sun, 18 May 2008 18:54:41 +0000
Subject: [M3devel] modula-3/pthreads
In-Reply-To: <20080518162217.GA27882@schlund.de>
References: 
	<20080518162217.GA27882@schlund.de>
Message-ID: 

Given that pthreads has all of mutex, rwlock, and most importantly condition variables, couldn't ThreadPThread.m3 be very much thinner?
Like, not do any of its own scheduling?
Also, shouldn;t the attr for stack size be destroyed? Else leak on some platforms? Is it even needed at all?
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From ndantam at purdue.edu  Sun May 18 22:08:20 2008
From: ndantam at purdue.edu (Neil T. Dantam)
Date: Sun, 18 May 2008 16:08:20 -0400
Subject: [M3devel] modula-3/pthreads
In-Reply-To: 
References: 	<20080518162217.GA27882@schlund.de>
	
Message-ID: <48308CB4.1050902@purdue.edu>

Jay wrote:
> Given that pthreads has all of mutex, rwlock, and most importantly
> condition variables, couldn't ThreadPThread.m3 be very much thinner?

Much of that is Object wrappers around the pthread primitives.
This is necessary so that we can garbage collect these types.

Also, RWLocks aren't really standard pthreads, but they seem to be
implemented on the platforms we currently care about.

> Like, not do any of its own scheduling?

The condition variable implementation does seem to do more than
necessary.  Perhaps this is so that it will do the right thing on
pthreads implementations that don't?

We also need to wrap pthread_create to maintain some thread local state
used for GC and probably other things as well.  It may be possible to
achieve this another way (ie using gcc's thread-local builtins), but
that would be a nontrivial change.

> Also, shouldn;t the attr for stack size be destroyed? Else leak on
> some platforms?

Probably.

> Is it even needed at all?

Not on linux, at least.

--
Neil


From dabenavidesd at yahoo.es  Mon May 19 00:39:58 2008
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sun, 18 May 2008 22:39:58 +0000 (GMT)
Subject: [M3devel] garbage collection problem on LINUXLIBC6?
Message-ID: <509246.28438.qm@web27102.mail.ukl.yahoo.com>

An HTML attachment was scrubbed...
URL: 

From hosking at cs.purdue.edu  Mon May 19 13:16:23 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 19 May 2008 07:16:23 -0400
Subject: [M3devel] modula-3/pthreads
In-Reply-To: 
References: 
	<20080518162217.GA27882@schlund.de>
	
Message-ID: 

Jay,

Indeed, I originally tried something slightly thinner (see the logs  
for the gory evolution...) but it only happened to work with Linux  
threads.  What we have now is about as thin as it can be, given the  
constraints imposed by the need to schedule thread alerts, etc.  For  
example, on some systems one cannot reliably wake up a specific thread  
from among many that are waiting on a condition.  Hence the need for  
every M3 thread too have its own private condition variable on which  
it will park itself pending alerts and conditions.


-- Tony

On May 18, 2008, at 2:54 PM, Jay wrote:

> Given that pthreads has all of mutex, rwlock, and most importantly  
> condition variables, couldn't ThreadPThread.m3 be very much thinner?
> Like, not do any of its own scheduling?
>
> Also, shouldn;t the attr for stack size be destroyed? Else leak on  
> some platforms? Is it even needed at all?
>
>  - Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Mon May 19 14:04:10 2008
From: jayk123 at hotmail.com (Jay)
Date: Mon, 19 May 2008 12:04:10 +0000
Subject: [M3devel] modula-3/pthreads
In-Reply-To: 
References: 
	<20080518162217.GA27882@schlund.de>
	
	
Message-ID: 

Tony, does Posix say that? Or testing? Esp. if this behavior is "substandard", should we have GoodPThread.m3 and BadPThread.m3?
And the "attr" is leaked, and perhaps unnecessary?
I'll be running a loop "soon" to see if the attr is leaked, but can't yet.
 
 - Jay


CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] modula-3/pthreadsDate: Mon, 19 May 2008 07:16:23 -0400


Jay,

Indeed, I originally tried something slightly thinner (see the logs for the gory evolution...) but it only happened to work with Linux threads.  What we have now is about as thin as it can be, given the constraints imposed by the need to schedule thread alerts, etc.  For example, on some systems one cannot reliably wake up a specific thread from among many that are waiting on a condition.  Hence the need for every M3 thread too have its own private condition variable on which it will park itself pending alerts and conditions.


-- Tony

On May 18, 2008, at 2:54 PM, Jay wrote:

Given that pthreads has all of mutex, rwlock, and most importantly condition variables, couldn't ThreadPThread.m3 be very much thinner?Like, not do any of its own scheduling?Also, shouldn;t the attr for stack size be destroyed? Else leak on some platforms? Is it even needed at all? - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From hosking at cs.purdue.edu  Mon May 19 14:31:56 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 19 May 2008 08:31:56 -0400
Subject: [M3devel] modula-3/pthreads
In-Reply-To: 
References: 
	<20080518162217.GA27882@schlund.de>
	
	
	
Message-ID: <54B5F97D-35EC-4902-804D-158F3FDE1650@cs.purdue.edu>

POSIX is *very* liberal in what behaviors it allows.  I don't think it  
makes any sense to further divide thread subsystems into good/bad  
based on behaviors that are undefined by the SPEC.

On May 19, 2008, at 8:04 AM, Jay wrote:

> Tony, does Posix say that? Or testing? Esp. if this behavior is  
> "substandard", should we have GoodPThread.m3 and BadPThread.m3?
> And the "attr" is leaked, and perhaps unnecessary?
> I'll be running a loop "soon" to see if the attr is leaked, but  
> can't yet.
>
>  - Jay
>
> CC: m3devel at elegosoft.com
> From: hosking at cs.purdue.edu
> To: jayk123 at hotmail.com
> Subject: Re: [M3devel] modula-3/pthreads
> Date: Mon, 19 May 2008 07:16:23 -0400
>
> Jay,
>
> Indeed, I originally tried something slightly thinner (see the logs  
> for the gory evolution...) but it only happened to work with Linux  
> threads.  What we have now is about as thin as it can be, given the  
> constraints imposed by the need to schedule thread alerts, etc.  For  
> example, on some systems one cannot reliably wake up a specific  
> thread from among many that are waiting on a condition.  Hence the  
> need for every M3 thread too have its own private condition variable  
> on which it will park itself pending alerts and conditions.
>
>
> -- Tony
>
> On May 18, 2008, at 2:54 PM, Jay wrote:
>
> Given that pthreads has all of mutex, rwlock, and most importantly  
> condition variables, couldn't ThreadPThread.m3 be very much thinner?
> Like, not do any of its own scheduling?
>
> Also, shouldn;t the attr for stack size be destroyed? Else leak on  
> some platforms? Is it even needed at all?
>
>  - Jay
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Mon May 19 14:47:46 2008
From: jayk123 at hotmail.com (Jay)
Date: Mon, 19 May 2008 12:47:46 +0000
Subject: [M3devel] gcc/m3cc/cm3c for OpenBSD?
Message-ID: 

What is the right way to handle these: http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/gcc/4.3/patches/
I imagine: 1) import them m3-sys/m3cc/src/patches/openbsd 2) perhaps use a vendor branch for the import   however they haven't changed in 14 months   and HOPEFULLY they get ported upstream 3) apply patches at build time
Seems kind of bad, but I figure also too much to manage to checkin the patch results?I realize it stinks largely due to the risk of accidentally doing what is avoided.Maybe there is like "VPATH" and the to-be-patched files can be copied in the outputdirectory and patched there?
 They aren't all needed, by far, but definitely some of them are needed.
 
 not needed, roughly:    *objc*, *ada*, *lib*
 needed, roughly:   *config* 
 unclear:  all the NULL to (void*) 0 diffs, which are a lot of it
 I kinda'thunk:  #ifdef __cplusplus  #define NULL 0 /* would perhaps need patch, depending on what calling conventions
  do with parameters and return values smaller than a word */   #else  #define NULL ((void*) 0) /* no need for patch */   #endif
in particular because in C++ a cast from void* to another* is needed, but not in C.
In fact I see this on OpenBSD:
 #ifndef NULL #ifdef  __GNUG__ #define NULL    __null #else #define NULL    0L #endif
Similar question for the AMD64_NT gcc patches, though these are newer, apparentlystill need testing, and since they are new, more hope they will go upstream.I don't know why the OpenBSD patches linger, I didn't ask.
I'll proceed as my suggest takes but presumably won't be read to commit  till after broader judgement/consensus rendered.
  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Mon May 19 17:08:05 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Mon, 19 May 2008 11:08:05 -0400
Subject: [M3devel] garbage collection problem on LINUXLIBC6?
In-Reply-To: <509246.28438.qm@web27102.mail.ukl.yahoo.com>
References: <509246.28438.qm@web27102.mail.ukl.yahoo.com>
Message-ID: <48315F96.1E75.00D7.1@scires.com>

Daniel, I have this same problem on GUI applications created on cm3
v4.1.  If I don't put "@M3novm" on the command line, the programs crash
during startup.  It has something to do with the garbage collector.  In
my testing of cm3 d5.7.0 on Windows XP, I have not run into the problem
yet, so I think Tony has fixed it with his new garbage collector, at
least on Windows.
Regards,
Randy

>>> "Daniel Alejandro Benavides D."  5/18/2008
6:39 PM >>>

Dear developers:
I'm running a new installed cm3 on an ubuntu 8.04 32 bits, and I can't
run anything with gui if I don't use @M3nogc
The rest of the applications, the compiler, and m3browser seem to work
without problems *?
I'm debugging mentor but I just got this until now:
Breakpoint 5, Init () at ../src/color/ColorName.m3:207
207           IF table.put (NormalizeName (Basic [i].name), i) THEN
(m3gdb) where
#0  Init () at ../src/color/ColorName.m3:207
#1  0xb7c7b7ff in ColorName (mode=1) at ../src/color/ColorName.m3:214
#2  0xb70e2389 in RunMainBody (m=16_b7ca2fa0) at
../src/runtime/common/RTLinker.m3:399
#3  0xb70e2055 in RunMainBody (m=16_b7d38100) at
../src/runtime/common/RTLinker.m3:379
#4  0xb70e2055 in RunMainBody (m=16_b7d2fe20) at
../src/runtime/common/RTLinker.m3:379
#5  0xb70e2055 in RunMainBody (m=16_b7d34480) at
../src/runtime/common/RTLinker.m3:379
#6  0xb70e2055 in RunMainBody (m=16_b7d30d60) at
../src/runtime/common/RTLinker.m3:379
#7  0xb70e2055 in RunMainBody (m=16_b7d4d620) at
../src/runtime/common/RTLinker.m3:379
#8  0xb70e2055 in RunMainBody (m=16_b7e31d80) at
../src/runtime/common/RTLinker.m3:379
#9  0xb70e2055 in RunMainBody (m=16_b7e33220) at
../src/runtime/common/RTLinker.m3:379
#10 0xb70e2055 in RunMainBody (m=16_b7e36d40) at
../src/runtime/common/RTLinker.m3:379
#11 0xb70e2055 in RunMainBody (m=16_b7e364e0) at
../src/runtime/common/RTLinker.m3:379
#12 0xb70e2055 in RunMainBody (m=16_b7e36ba0) at
../src/runtime/common/RTLinker.m3:379
#13 0xb70e2055 in RunMainBody (m=16_b7e32cc0) at
../src/runtime/common/RTLinker.m3:379
#14 0xb70e2055 in RunMainBody (m=16_b7e32900) at
../src/runtime/common/RTLinker.m3:379
#15 0xb70e2055 in RunMainBody (m=16_08255600) at
../src/runtime/common/RTLinker.m3:379
#16 0xb70e2055 in RunMainBody (m=16_08256040) at
../src/runtime/common/RTLinker.m3:379
#17 0xb70e2055 in RunMainBody (m=16_08312aa0) at
../src/runtime/common/RTLinker.m3:379
#18 0xb70e0dff in AddUnitI (m=16_08312aa0) at
../src/runtime/common/RTLinker.m3:113
#19 0xb70e0e8d in AddUnit (b={"Main_M3", Declared at:
../src/Main.m3:164}) at ../src/runtime/common/RTLinker.m3:122
#20 0x0806df1e in main (argc=3, argv=0xbfa03774, envp=0xbfa03784) at
_m3main.mc:4
#21 0xb6d44450 in __libc_start_main () from
/lib/tls/i686/cmov/libc.so.6
#22 0x0806de71 in _start ()
(m3gdb) cont
Continuando.

Breakpoint 5, Init () at ../src/color/ColorName.m3:207
207           IF table.put (NormalizeName (Basic [i].name), i) THEN
(m3gdb) cont
and the process hangs there when debugging mentor.

I have checked  Juno under m3gdb after have killed it and got:

(m3gdb) where
#0  0xb7fb0410 in __kernel_vsyscall ()
#1  0xb7018ae7 in pthread_kill () from
/lib/tls/i686/cmov/libpthread.so.0
#2  0xb728c397 in SignalThread (act=16_0813c120, state=Stopping) at
../src/thread/PTHREAD/ThreadPThread.m3:1058
#3  0xb728c55e in StopWorld () at
../src/thread/PTHREAD/ThreadPThread.m3:1116
#4  0xb728b9e7 in SuspendOthers () at
../src/thread/PTHREAD/ThreadPThread.m3:905
#5  0xb7265244 in CollectSomeInStateZero () at
../src/runtime/common/RTCollector.m3:755
#6  0xb7265203 in CollectSome () at
../src/runtime/common/RTCollector.m3:729
#7  0xb7264c24 in CollectEnough () at
../src/runtime/common/RTCollector.m3:656
#8  0xb72686c1 in AllocTraced (def=16_b7be1400, dataSize=12,
dataAlignment=4, initProc=NIL)
    at ../src/runtime/common/RTCollector.m3:1462
#9  0xb725ad8f in GetTracedRef (def=16_b7be1400) at
../src/runtime/common/RTAllocator.m3:191
#10 0xb725a987 in AllocateTracedRef (defn=16_b7be1400) at
../src/runtime/common/RTAllocator.m3:126
#11 0xb7b5d8fb in Put (tbl=16_b6e50438, key=8047, val=244) at
../LINUXLIBC6/IntIntTbl.m3 => ../src/table/Table.mg:127
#12 0xb7dd4e2c in Set (a='>', b='o', c=244, bothCases=FALSE,
reversed=TRUE) at ../src/etext/KeyFilter.m3:288
#13 0xb7dd521c in Set (a='o', b='>', c=244, bothCases=FALSE,
reversed=FALSE) at ../src/etext/KeyFilter.m3:304
#14 0xb7dd5882 in KeyFilter (mode=1) at ../src/etext/KeyFilter.m3:437
#15 0xb7273389 in RunMainBody (m=16_b7e51da0) at
../src/runtime/common/RTLinker.m3:399
#16 0xb7273055 in RunMainBody (m=16_b7e547e0) at
../src/runtime/common/RTLinker.m3:379
#17 0xb7273055 in RunMainBody (m=16_b7e56c00) at
../src/runtime/common/RTLinker.m3:379
#18 0xb7273055 in RunMainBody (m=16_b7e54240) at
../src/runtime/common/RTLinker.m3:379
#19 0xb7273055 in RunMainBody (m=16_b7e537e0) at
../src/runtime/common/RTLinker.m3:379
#20 0xb7273055 in RunMainBody (m=16_080b85a0) at
../src/runtime/common/RTLinker.m3:379
#21 0xb7271dff in AddUnitI (m=16_080b85a0) at
../src/runtime/common/RTLinker.m3:113
#22 0xb7271e8d in AddUnit (b={"Juno_M3", Declared at:
../src/Juno.m3:1974}) at ../src/runtime/common/RTLinker.m3:122
#23 0x0805120e in main (argc=1, argv=0xbf96ff14, envp=0xbf96ff1c) at
_m3main.mc:4
#24 0xb6ed5450 in __libc_start_main () from
/lib/tls/i686/cmov/libc.so.6
#25 0x08051161 in _start ()


When killing mentor under m3gdb it shows like the same back trace:
(m3gdb) where
#0  0xb70fb39a in SignalThread (act=16_0834ff08, state=Stopping) at
../src/thread/PTHREAD/ThreadPThread.m3:1058
#1  0xb70fb6dc in StopWorld () at
../src/thread/PTHREAD/ThreadPThread.m3:1142
#2  0xb70fa9e7 in SuspendOthers () at
../src/thread/PTHREAD/ThreadPThread.m3:905
#3  0xb70d4244 in CollectSomeInStateZero () at
../src/runtime/common/RTCollector.m3:755
#4  0xb70d4203 in CollectSome () at
../src/runtime/common/RTCollector.m3:729
#5  0xb70d3c24 in CollectEnough () at
../src/runtime/common/RTCollector.m3:656
#6  0xb70d76c1 in AllocTraced (def=16_b712d934, dataSize=24,
dataAlignment=4, initProc=Static link does not lead to a valid frame.
)
    at ../src/runtime/common/RTCollector.m3:1462
#7  0xb70c9f25 in GetTracedObj (def=16_b712d934) at
../src/runtime/common/RTAllocator.m3:206
#8  0xb70c99b0 in AllocateTracedObj (defn=16_b712d934) at
../src/runtime/common/RTAllocator.m3:131
#9  0xb710d586 in New (a={'a','z','u','r','e','4'}) at
../src/text/Text8Short.m3:16
#10 0xb710ce87 in New (a={'a','z','u','r','e','4'}) at
../src/text/Text8.m3:18
#11 0xb710ba9d in FromChars (a={'a','z','u','r','e','4'}) at
../src/text/Text.m3:206
#12 0xb7c7a62f in NormalizeName (a=16_b7ca378c) at
../src/color/ColorName.m3:83
#13 0xb7c7b789 in Init () at ../src/color/ColorName.m3:207
#14 0xb7c7b7ff in ColorName (mode=1) at ../src/color/ColorName.m3:214
#15 0xb70e2389 in RunMainBody (m=16_b7ca2fa0) at
../src/runtime/common/RTLinker.m3:399
#16 0xb70e2055 in RunMainBody (m=16_b7d38100) at
../src/runtime/common/RTLinker.m3:379
#17 0xb70e2055 in RunMainBody (m=16_b7d2fe20) at
../src/runtime/common/RTLinker.m3:379
#18 0xb70e2055 in RunMainBody (m=16_b7d34480) at
../src/runtime/common/RTLinker.m3:379
#19 0xb70e2055 in RunMainBody (m=16_b7d30d60) at
../src/runtime/common/RTLinker.m3:379
#20 0xb70e2055 in RunMainBody (m=16_b7d4d620) at
../src/runtime/common/RTLinker.m3:379
#21 0xb70e2055 in RunMainBody (m=16_b7e31d80) at
../src/runtime/common/RTLinker.m3:379
#22 0xb70e2055 in RunMainBody (m=16_b7e33220) at
../src/runtime/common/RTLinker.m3:379
#23 0xb70e2055 in RunMainBody (m=16_b7e36d40) at
../src/runtime/common/RTLinker.m3:379
#24 0xb70e2055 in RunMainBody (m=16_b7e364e0) at
../src/runtime/common/RTLinker.m3:379
#25 0xb70e2055 in RunMainBody (m=16_b7e36ba0) at
../src/runtime/common/RTLinker.m3:379
#26 0xb70e2055 in RunMainBody (m=16_b7e32cc0) at
../src/runtime/common/RTLinker.m3:379
#27 0xb70e2055 in RunMainBody (m=16_b7e32900) at
../src/runtime/common/RTLinker.m3:379
#28 0xb70e2055 in RunMainBody (m=16_08255600) at
../src/runtime/common/RTLinker.m3:379
#29 0xb70e2055 in RunMainBody (m=16_08256040) at
../src/runtime/common/RTLinker.m3:379
#30 0xb70e2055 in RunMainBody (m=16_08312aa0) at
../src/runtime/common/RTLinker.m3:379
#31 0xb70e0dff in AddUnitI (m=16_08312aa0) at
../src/runtime/common/RTLinker.m3:113
#32 0xb70e0e8d in AddUnit (b={"Main_M3", Declared at:
../src/Main.m3:164}) at ../src/runtime/common/RTLinker.m3:122
#33 0x0806df1e in main (argc=3, argv=0xbfa03774, envp=0xbfa03784) at
_m3main.mc:4
#34 0xb6d44450 in __libc_start_main () from
/lib/tls/i686/cmov/libc.so.6
#35 0x0806de71 in _start ()

Thanks in advance


Enviado desde Correo Yahoo! (
http://us.rd.yahoo.com/mailuk/taglines/isp/control/*http://us.rd.yahoo.com/evt=52431/*http://es.docs.yahoo.com/mail/overview/index.html
)
La bandeja de entrada m?s inteligente.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From dabenavidesd at yahoo.es  Mon May 19 18:52:09 2008
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 19 May 2008 16:52:09 +0000 (GMT)
Subject: [M3devel] garbage collection problem on LINUXLIBC6?
In-Reply-To: <48315F96.1E75.00D7.1@scires.com>
Message-ID: <735107.82429.qm@web27103.mail.ukl.yahoo.com>

An HTML attachment was scrubbed...
URL: 

From dabenavidesd at yahoo.es  Mon May 19 19:02:00 2008
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 19 May 2008 17:02:00 +0000 (GMT)
Subject: [M3devel] garbage collection problem on LINUXLIBC6?
In-Reply-To: <735107.82429.qm@web27103.mail.ukl.yahoo.com>
Message-ID: <163131.36279.qm@web27101.mail.ukl.yahoo.com>

An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sat May 24 07:11:50 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 24 May 2008 05:11:50 +0000
Subject: [M3devel] new platform names (for actual new platforms)
Message-ID: 

Do people object to new platform names like:
  PPC32_OPENBSD    SPARC32_OPENBSD    SPARC32_LINUX  
 
?
For that matter, anyone consider spelling out POWERPC32_OPENBSD?
?
Seriously I am far along on PPC32_OPENBSD and SPARC64_OPENBSDand once those work, I figure I'll try to flesh out Linux, NetBSD,FreeBSD on ppc32/sparc/sparc64. So this isn't just hypothetical
debate about platform names.
 
At some point it almost seems like there's a 2 dimensional matrixand the support should be processor and OS, somewhat independent..well, it is kind of like in parts already.
 
Should I really stick more like:  PPC_OPENBSD   SPARC_LINUX   SPARC64_LINUX    etc.?
64bits isn't so unusual now, that 32bits isn't so automatically implied???
That's kind of my point. Not putting in "32" or "64" used to imply "32" but
now seems almost ambiguous. ?
(Linux doesn't really still support 32 bit SPARC kernels, butdefinitely 32 bit userland; in fact it looks like SPARC Linuxis mostly 32 bit userland, and SPARC64 OpenBSD is purely 64 bit,not even gcc -m32)
I'd still kind of like to rename stuff like to  I386_NT, I386_LINUX, I386_CYGWIN, I386_MINGWIN, SPARC_SOLARIS_SUN,  SPARC_SOLARIS_GNU, alas...  
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sat May 24 11:49:57 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 24 May 2008 09:49:57 +0000
Subject: [M3devel] stat file types?
In-Reply-To: 
References: 
Message-ID: 

It SEEMS:
 
S_IFPIPE appears to be made up by Modula-3.S_IFPORT appears to be made up by Modula-3 as a synonym for S_IFIFO.
 
PROPOSED:
This code:
D:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX\FilePosix.i3(36):   error if "fd" is not "S_IFPIPE", "S_IFPORT", or "S_IFSOCK". *)D:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX\FilePosix.m3(47):    | Ustat.S_IFPIPE, Ustat.S_IFPORT, Ustat.S_IFSOCK =>
 
should check for S_IFSOCK and S_IFIFO.
all references to and definitions of S_IFPORT and S_IFPIPE should go away.
 
Or did some actual systems actually define either of these?
 
Most of the *.i3 files set S_IFPORT = S_IFIFO and S_IFPIPE = 0.
Many of them say that there is no S_IFPIPE in their .h file.
Irix has them reversed but the same result: S_IFPORT = 0 and S_IFPIPE = S_IFIFO.
 
Any objections?
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sat May 24 11:50:50 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 24 May 2008 09:50:50 +0000
Subject: [M3devel] stat file types?
In-Reply-To: 
References: 
Message-ID: 

It SEEMS:
 
S_IFPIPE appears to be made up by Modula-3.S_IFPORT appears to be made up by Modula-3 as a synonym for S_IFIFO.
 
PROPOSED:
This code:
D:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX\FilePosix.i3(36):   error if "fd" is not "S_IFPIPE", "S_IFPORT", or "S_IFSOCK". *)D:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX\FilePosix.m3(47):    | Ustat.S_IFPIPE, Ustat.S_IFPORT, Ustat.S_IFSOCK =>
 
should check for S_IFSOCK and S_IFIFO.
all references to and definitions of S_IFPORT and S_IFPIPE should go away.
 
Or did some actual systems actually define either of these?
 
Most of the *.i3 files set S_IFPORT = S_IFIFO and S_IFPIPE = 0.
Many of them say that there is no S_IFPIPE in their .h file.
Irix has them reversed but the same result: S_IFPORT = 0 and S_IFPIPE = S_IFIFO.
 
Any objections?
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From dabenavidesd at yahoo.es  Sat May 24 19:29:27 2008
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sat, 24 May 2008 17:29:27 +0000 (GMT)
Subject: [M3devel] garbage collection problem on LINUXLIBC6?
In-Reply-To: <163131.36279.qm@web27101.mail.ukl.yahoo.com>
Message-ID: <406663.93255.qm@web27103.mail.ukl.yahoo.com>

Hi:
I recently have compiled the cm3 system with good results on a 2-core machine on LINUXLIBC6, kubuntu of 32 bits. It runs gui applications of cm3 with no problems at all.
I think maybe the issue is related with something about the operating system, or at least the machine, I didn't check this until now.

Thanks

--- 19/5/08, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> wrote:
De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] garbage collection problem on LINUXLIBC6?
Para: m3devel at elegosoft.com, "Randy Coleburn" <rcoleburn at scires.com>
Fecha: lunes, 19 mayo, 2008 12:02

Hi again:
and the process is using the cpu very much (using top command)

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 9758 daniel    20   0 33644 3836 2684 R 60.0  0.7   1:05.17 draw

Thanks in advance.


--- 19/5/08, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> wrote:
De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] garbage collection problem on LINUXLIBC6?
Para: m3devel at elegosoft.com, "Randy Coleburn" <rcoleburn at scires.com>
Fecha: lunes, 19 mayo, 2008 11:52

Hi Randy:
In my case, the program just doesn't start, maybe after some minutes yes, but obviously this is abnormal.
When I start mentor @M3tracelinker, I got after a lot of output the following lines and it just doesn't start after it:
  ../src/color/Color.i3(3)
  ../src/runtime/common/RTHooks.i3(3)
RunMainBody: exec: ../src/color/ColorNameTable.i3(3)
RunMainBody: exec: ../src/color/ColorNameF.i3(3)
RunMainBody: exec: ../src/color/ColorNa

But if I put @M3nogc @M3tracelinker the program starts and the output is:
RunMainBody: ../LINUXLIBC6/MentorBundle.m3(2)
  ../LINUXLIBC6/MentorBundle.i3(5)
  ../src/rw/TextWr.i3(3)
  ../src/rw/Wr.i3(3)
 
 ../src/thread/Common/Thread.i3(3)
  ../src/text/Text.i3(3)
  ../src/bundleintf/BundleRep.i3(3)
  ../src/bundleintf/Bundle.i3(3)
 
 ../src/runtime/common/RTHooks.i3(3)
RunMainBody: exec: ../LINUXLIBC6/MentorBundle.m3(3)
RunMainBody: exec: ../LINUXLIBC6/MentorBundle.i3(3)
RunMainBody: exec: ../src/Main.m3(3)

However when examining a simple gui program, the stdout shows the same  out for @M3tracelinker with or without garbage collection

  ../src/split/TextVBT.i3(5)
  ../src/runtime/common/RTHooks.i3(3)
RunMainBody: exec: ../src/split/TextVBTClass.i3(3)
RunMainBody: exec: ../src/split/TextVBT.m3(3)
RunMainBody: exec: ../src/split/TextVBT.i3(3)
RunMainBody: exec: ../src/Draw.m3(3)

If I run the program under m3gdb without parametres, breaking on RTLinker.RunMainBody, I got:
Breakpoint 3, RunMainBody (m=16_b7e108c0)
    at ../src/runtime/common/RTLinker.m3:349
349       VAR desc, desc2: InitPtr;  imp: RT0.ImportPtr;  m2:
 RT0.ModulePtr;
(m3gdb)
Continuando.

Breakpoint 3, RunMainBody (m=16_b7e10ba0)
    at ../src/runtime/common/RTLinker.m3:349
349       VAR desc, desc2: InitPtr;  imp: RT0.ImportPtr;  m2: RT0.ModulePtr;
(m3gdb)
Continuando.

Breakpoint 3, RunMainBody (m=16_b7e0b660)
    at ../src/runtime/common/RTLinker.m3:349
349       VAR desc, desc2: InitPtr;  imp: RT0.ImportPtr;  m2: RT0.ModulePtr;
(m3gdb)
Continuando.


[Nuevo Thread -1234015344 (LWP 9706)]
[Thread -1234015344 (LWP 9706) exited]

And the program hangs there.
And again the same situation on the stack trace when killing the process inside m3gdb (also got a segment violation on m3gdb):

(m3gdb) where
#0  0xb7fbf410 in __kernel_vsyscall ()
#1  0xb7108ae7 in pthread_kill () from
 /lib/tls/i686/cmov/libpthread.so.0
#2  0xb737c397 in SignalThread (act=16_08055d88, state=Stopping)
    at ../src/thread/PTHREAD/ThreadPThread.m3:1058
#3  0xb737c6dc in StopWorld () at ../src/thread/PTHREAD/ThreadPThread.m3:1142
#4  0xb737b9e7 in SuspendOthers ()
    at ../src/thread/PTHREAD/ThreadPThread.m3:905
#5  0xb7355244 in CollectSomeInStateZero ()
    at ../src/runtime/common/RTCollector.m3:755
#6  0xb7355203 in CollectSome () at ../src/runtime/common/RTCollector.m3:729
#7  0xb7354c24 in CollectEnough () at ../src/runtime/common/RTCollector.m3:656
#8  0xb73586c1 in AllocTraced (def=16_b7dfbfb4, dataSize=456, dataAlignment=4,
    initProc=Static link does not lead to a valid frame.
) at ../src/runtime/common/RTCollector.m3:1462
#9  0xb734af25 in GetTracedObj (def=16_b7dfbfb4)
    at
 ../src/runtime/common/RTAllocator.m3:206
#10 0xb734a9b0 in AllocateTracedObj (defn=16_b7dfbfb4)
    at ../src/runtime/common/RTAllocator.m3:131
#11 0xb7d63df5 in Connect (inst=NIL, trsl=NIL) at ../src/xvbt/XClientF.m3:495
#12 0xb7d66717 in DoConnect (self=16_b6f41d5c, inst=NIL, localOnly=FALSE,
    t=NIL) at ../src/xvbt/XClientF.m3:637
#13 0xb7d46c23 in DoConnect (self=16_b6f41d5c, inst=NIL, localOnly=FALSE,
    t=NIL) at ../src/xvbt/XClient.m3:1495
#14 0xb7d9962c in Connect (inst=NIL, localOnly=FALSE)
---Type <return> to continue, or q <return> to quit---
    at ../src/vbt/TrestleClass.m3:30
#15 0xb7df2117 in Default () at ../src/trestle/Trestle.m3:838
#16 0xb7ded789 in PreAttach (v=16_b6f41cf8, trsl=NIL)
    at ../src/trestle/Trestle.m3:264
#17 0xb7deb95b in Install (v=16_b6f41cf8, applName=NIL, inst=NIL,
Fallo de
 segmentaci?n


Maybe could be some gcc backend issue?
I would like to know if others have the same problem.
Thanks.
  
--- 19/5/08, Randy Coleburn <rcoleburn at scires.com> wrote:
De: Randy Coleburn <rcoleburn at scires.com>
Asunto: Re: [M3devel] garbage collection problem on LINUXLIBC6?
Para: m3devel at elegosoft.com
Fecha: lunes, 19 mayo, 2008 10:08


 
Daniel, I have this same problem on GUI applications created on cm3 v4.1.  If I don't put "@M3novm" on the command line, the programs crash during startup.  It has something to do with the garbage collector.  In my testing of cm3 d5.7.0 on Windows XP, I have not run into the problem yet, so I think Tony has fixed it with his new garbage collector, at least on Windows.
Regards,
Randy

>>> "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> 5/18/2008 6:39 PM >>>




Dear developers:
I'm running a new installed cm3 on an ubuntu 8.04 32 bits, and I can't run anything with gui if I don't use @M3nogc
The rest of the applications, the compiler, and m3browser seem to work without problems ??
I'm debugging mentor but I just got this until now:
Breakpoint 5, Init () at ../src/color/ColorName.m3:207
207           IF table.put (NormalizeName (Basic [i].name), i) THEN
(m3gdb) where
#0  Init () at ../src/color/ColorName.m3:207
#1  0xb7c7b7ff in ColorName (mode=1) at ../src/color/ColorName.m3:214
#2  0xb70e2389 in RunMainBody (m=16_b7ca2fa0) at ../src/runtime/common/RTLinker.m3:399
#3  0xb70e2055 in RunMainBody (m=16_b7d38100) at ../src/runtime/common/RTLinker.m3:379
#4  0xb70e2055 in RunMainBody (m=16_b7d2fe20) at ../src/runtime/common/RTLinker.m3:379
#5  0xb70e2055 in RunMainBody (m=16_b7d34480) at
 ../src/runtime/common/RTLinker.m3:379
#6  0xb70e2055 in RunMainBody (m=16_b7d30d60) at ../src/runtime/common/RTLinker.m3:379
#7  0xb70e2055 in RunMainBody (m=16_b7d4d620) at ../src/runtime/common/RTLinker.m3:379
#8  0xb70e2055 in RunMainBody (m=16_b7e31d80) at ../src/runtime/common/RTLinker.m3:379
#9  0xb70e2055 in RunMainBody (m=16_b7e33220) at ../src/runtime/common/RTLinker.m3:379
#10 0xb70e2055 in RunMainBody (m=16_b7e36d40) at ../src/runtime/common/RTLinker.m3:379
#11 0xb70e2055 in RunMainBody (m=16_b7e364e0) at ../src/runtime/common/RTLinker.m3:379
#12 0xb70e2055 in RunMainBody (m=16_b7e36ba0) at ../src/runtime/common/RTLinker.m3:379
#13 0xb70e2055 in RunMainBody (m=16_b7e32cc0) at ../src/runtime/common/RTLinker.m3:379
#14 0xb70e2055 in RunMainBody (m=16_b7e32900) at ../src/runtime/common/RTLinker.m3:379
#15 0xb70e2055 in RunMainBody (m=16_08255600) at ../src/runtime/common/RTLinker.m3:379
#16
 0xb70e2055 in RunMainBody (m=16_08256040) at ../src/runtime/common/RTLinker.m3:379
#17 0xb70e2055 in RunMainBody (m=16_08312aa0) at ../src/runtime/common/RTLinker.m3:379
#18 0xb70e0dff in AddUnitI (m=16_08312aa0) at ../src/runtime/common/RTLinker.m3:113
#19 0xb70e0e8d in AddUnit (b={"Main_M3", Declared at: ../src/Main.m3:164}) at ../src/runtime/common/RTLinker.m3:122
#20 0x0806df1e in main (argc=3, argv=0xbfa03774, envp=0xbfa03784) at _m3main.mc:4
#21 0xb6d44450 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#22 0x0806de71 in _start ()
(m3gdb) cont
Continuando.

Breakpoint 5, Init () at ../src/color/ColorName.m3:207
207           IF table.put (NormalizeName (Basic [i].name), i) THEN
(m3gdb) cont
and the process hangs there when debugging mentor.

I have checked  Juno under m3gdb after have killed it and got:

(m3gdb) where
#0 
 0xb7fb0410 in __kernel_vsyscall ()
#1  0xb7018ae7 in pthread_kill () from /lib/tls/i686/cmov/libpthread.so.0
#2  0xb728c397 in SignalThread (act=16_0813c120, state=Stopping) at ../src/thread/PTHREAD/ThreadPThread.m3:1058
#3  0xb728c55e in StopWorld () at ../src/thread/PTHREAD/ThreadPThread.m3:1116
#4  0xb728b9e7 in SuspendOthers () at ../src/thread/PTHREAD/ThreadPThread.m3:905
#5  0xb7265244 in CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:755
#6  0xb7265203 in CollectSome () at ../src/runtime/common/RTCollector.m3:729
#7  0xb7264c24 in CollectEnough () at ../src/runtime/common/RTCollector.m3:656
#8  0xb72686c1 in AllocTraced (def=16_b7be1400, dataSize=12, dataAlignment=4, initProc=NIL)
    at ../src/runtime/common/RTCollector.m3:1462
#9  0xb725ad8f in GetTracedRef (def=16_b7be1400) at ../src/runtime/common/RTAllocator.m3:191
#10 0xb725a987
 in AllocateTracedRef (defn=16_b7be1400) at ../src/runtime/common/RTAllocator.m3:126
#11 0xb7b5d8fb in Put (tbl=16_b6e50438, key=8047, val=244) at ../LINUXLIBC6/IntIntTbl.m3 => ../src/table/Table.mg:127
#12 0xb7dd4e2c in Set (a='>', b='o', c=244, bothCases=FALSE, reversed=TRUE) at ../src/etext/KeyFilter.m3:288
#13 0xb7dd521c in Set (a='o', b='>', c=244, bothCases=FALSE, reversed=FALSE) at ../src/etext/KeyFilter.m3:304
#14 0xb7dd5882 in KeyFilter (mode=1) at ../src/etext/KeyFilter.m3:437
#15 0xb7273389 in RunMainBody (m=16_b7e51da0) at ../src/runtime/common/RTLinker.m3:399
#16 0xb7273055 in RunMainBody (m=16_b7e547e0) at ../src/runtime/common/RTLinker.m3:379
#17 0xb7273055 in RunMainBody (m=16_b7e56c00) at ../src/runtime/common/RTLinker.m3:379
#18 0xb7273055 in RunMainBody (m=16_b7e54240) at ../src/runtime/common/RTLinker.m3:379
#19 0xb7273055 in RunMainBody (m=16_b7e537e0) at
 ../src/runtime/common/RTLinker.m3:379
#20 0xb7273055 in RunMainBody (m=16_080b85a0) at ../src/runtime/common/RTLinker.m3:379
#21 0xb7271dff in AddUnitI (m=16_080b85a0) at ../src/runtime/common/RTLinker.m3:113
#22 0xb7271e8d in AddUnit (b={"Juno_M3", Declared at: ../src/Juno.m3:1974}) at ../src/runtime/common/RTLinker.m3:122
#23 0x0805120e in main (argc=1, argv=0xbf96ff14, envp=0xbf96ff1c) at _m3main.mc:4
#24 0xb6ed5450 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#25 0x08051161 in _start ()


When killing mentor under m3gdb it shows like the same back trace:
(m3gdb) where
#0  0xb70fb39a in SignalThread (act=16_0834ff08, state=Stopping) at ../src/thread/PTHREAD/ThreadPThread.m3:1058
#1  0xb70fb6dc in StopWorld () at ../src/thread/PTHREAD/ThreadPThread.m3:1142
#2  0xb70fa9e7 in SuspendOthers () at ../src/thread/PTHREAD/ThreadPThread.m3:905
#3  0xb70d4244 in CollectSomeInStateZero
 () at ../src/runtime/common/RTCollector.m3:755
#4  0xb70d4203 in CollectSome () at ../src/runtime/common/RTCollector.m3:729
#5  0xb70d3c24 in CollectEnough () at ../src/runtime/common/RTCollector.m3:656
#6  0xb70d76c1 in AllocTraced (def=16_b712d934, dataSize=24, dataAlignment=4, initProc=Static link does not lead to a valid frame.
)
    at ../src/runtime/common/RTCollector.m3:1462
#7  0xb70c9f25 in GetTracedObj (def=16_b712d934) at ../src/runtime/common/RTAllocator.m3:206
#8  0xb70c99b0 in AllocateTracedObj (defn=16_b712d934) at ../src/runtime/common/RTAllocator.m3:131
#9  0xb710d586 in New (a={'a','z','u','r','e','4'}) at ../src/text/Text8Short.m3:16
#10 0xb710ce87 in New (a={'a','z','u','r','e','4'}) at ../src/text/Text8.m3:18
#11 0xb710ba9d in FromChars (a={'a','z','u','r','e','4'}) at ../src/text/Text.m3:206
#12 0xb7c7a62f in NormalizeName (a=16_b7ca378c) at
 ../src/color/ColorName.m3:83
#13 0xb7c7b789 in Init () at ../src/color/ColorName.m3:207
#14 0xb7c7b7ff in ColorName (mode=1) at ../src/color/ColorName.m3:214
#15 0xb70e2389 in RunMainBody (m=16_b7ca2fa0) at ../src/runtime/common/RTLinker.m3:399
#16 0xb70e2055 in RunMainBody (m=16_b7d38100) at ../src/runtime/common/RTLinker.m3:379
#17 0xb70e2055 in RunMainBody (m=16_b7d2fe20) at ../src/runtime/common/RTLinker.m3:379
#18 0xb70e2055 in RunMainBody (m=16_b7d34480) at ../src/runtime/common/RTLinker.m3:379
#19 0xb70e2055 in RunMainBody (m=16_b7d30d60) at ../src/runtime/common/RTLinker.m3:379
#20 0xb70e2055 in RunMainBody (m=16_b7d4d620) at ../src/runtime/common/RTLinker.m3:379
#21 0xb70e2055 in RunMainBody (m=16_b7e31d80) at ../src/runtime/common/RTLinker.m3:379
#22 0xb70e2055 in RunMainBody (m=16_b7e33220) at ../src/runtime/common/RTLinker.m3:379
#23 0xb70e2055 in RunMainBody (m=16_b7e36d40) at
 ../src/runtime/common/RTLinker.m3:379
#24 0xb70e2055 in RunMainBody (m=16_b7e364e0) at ../src/runtime/common/RTLinker.m3:379
#25 0xb70e2055 in RunMainBody (m=16_b7e36ba0) at ../src/runtime/common/RTLinker.m3:379
#26 0xb70e2055 in RunMainBody (m=16_b7e32cc0) at ../src/runtime/common/RTLinker.m3:379
#27 0xb70e2055 in RunMainBody (m=16_b7e32900) at ../src/runtime/common/RTLinker.m3:379
#28 0xb70e2055 in RunMainBody (m=16_08255600) at ../src/runtime/common/RTLinker.m3:379
#29 0xb70e2055 in RunMainBody (m=16_08256040) at ../src/runtime/common/RTLinker.m3:379
#30 0xb70e2055 in RunMainBody (m=16_08312aa0) at ../src/runtime/common/RTLinker.m3:379
#31 0xb70e0dff in AddUnitI (m=16_08312aa0) at ../src/runtime/common/RTLinker.m3:113
#32 0xb70e0e8d in AddUnit (b={"Main_M3", Declared at: ../src/Main.m3:164}) at ../src/runtime/common/RTLinker.m3:122
#33 0x0806df1e in main (argc=3, argv=0xbfa03774, envp=0xbfa03784) at _m3main.mc:4
#34
 0xb6d44450 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#35 0x0806de71 in _start ()

Thanks in advance




Enviado desde Correo Yahoo!
La bandeja de entrada m?s inteligente.








      
Enviado desde Correo Yahoo!
La bandeja de entrada m?s inteligente.









      
Enviado desde Correo Yahoo!
La bandeja de entrada m?s inteligente.




      ______________________________________________ 
Enviado desde Correo Yahoo! La bandeja de entrada m?s inteligente.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Sun May 25 00:48:25 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Sat, 24 May 2008 18:48:25 -0400
Subject: [M3devel] new problems
Message-ID: <483862F4.1E75.00D7.1@scires.com>

I'm having some new problems crop up with the cm3ide program.
 
Have there been any recent changes to quake or the QMachine that have not been thoroughly checked out?  That is where I suspect the problems are coming from.
 
Regards,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sun May 25 01:33:14 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 24 May 2008 23:33:14 +0000
Subject: [M3devel] new problems
In-Reply-To: <483862F4.1E75.00D7.1@scires.com>
References: <483862F4.1E75.00D7.1@scires.com>
Message-ID: 

Randy, can you describe the problems more?
 
"Something is wrong."?
 
Can the problems be made debuggable by others?
 
When did the problems start?
 
 - Jay


Date: Sat, 24 May 2008 18:48:25 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: [M3devel] new problems

I'm having some new problems crop up with the cm3ide program.
 
Have there been any recent changes to quake or the QMachine that have not been thoroughly checked out?  That is where I suspect the problems are coming from.
 
Regards,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sun May 25 02:16:01 2008
From: jayk123 at hotmail.com (Jay)
Date: Sun, 25 May 2008 00:16:01 +0000
Subject: [M3devel] function pointers and comparison to nil? mis-typed
 function pointers?
In-Reply-To: <483862F4.1E75.00D7.1@scires.com>
References: <483862F4.1E75.00D7.1@scires.com>
Message-ID: 

I'm being lazy...
Tony can you explain this stuff?
Comparison of function pointers..What are the various representations and rules?
What does it mean to compare nested functions?
What does it mean to compare a function to NIL?
I'll poke around more.
What I am seeing is that comparison of function pointers to NIL is surprisinglyexpensive, and probably somewhat buggy. Or at least some of the runtimegenerated "metadata-ish" stuff is produced or typed incorrectly.
In particular, RTLinker.m3:
PROCEDURE AddUnit (b: RT0.Binder) =  VAR m: RT0.ModulePtr;  BEGIN    IF (b = NIL) THEN RETURN END;   line 119    m := b(0);                      line 120    IF (m = NIL) THEN RETURN END;   line 121    AddUnitI(m);                    line 122   END AddUnit;
generates a lot of code, just for the first line:
  (556) set_source_line      source line  119    (557) load      m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb    (558) load_nil    (559) if_eq    (560) load      m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb    (561) load_indirect      load address offset 0x0 src_t 0x5 dst_t 0x5    (562) load_integer      integer n_bytes 0x0 hi 0x0 low 0x1 sign -1    (563) if_eq    (564) set_label    (565) load_nil    (566) load      m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb    (567) if_ne    (568) set_label    (569) exit_proc    (570) set_label    (571) set_source_line      source line  120  
The details on the load_integer trace might not be completely correct. I will test a fix shortly.Esp. that n_bytes gets decremented to zero before the trace.
Ok, I see now why some of the bloat -- because the "then return end" is on the same line.If it were written as:  if (b = NIL THEN      return   end   
It probably wouldn't look so bad. That took me a while to realize.
The following is generated for SPARC64_OPENBSD:
 
 line 119 
 .stabn 68,0,119,.LLM61-.LLFBB4 .LLM61: ldx [%fp+2175], %g1 brz %g1, .LL26  nop ldx [%fp+2175], %g1 ldx [%g1], %g1            bus error here? yes, probably this one cmp %g1, -1 be %xcc, .LL27  nop.LL26: ldx [%fp+2175], %g1 brz %g1, .LL33  nop.LL27:
 line 120 
 .stabn 68,0,120,.LLM62-.LLFBB4.LLM62:
 ldx [%fp+2175], %g1 stx %g1, [%fp+2007] ldx [%fp+2007], %g1 brz %g1, .LL30  nop ldx [%fp+2007], %g1 ldx [%g1], %g1            or here ? cmp %g1, -1 bne %xcc, .LL30  nop ldx [%fp+2007], %g1 add %g1, 16, %g1 ldx [%g1], %g1           or here?  stx %g1, [%fp+2015] ldx [%fp+2007], %g1 add %g1, 8, %g1 ldx [%g1], %g1 stx %g1, [%fp+2007].LL30: ldx [%fp+2007], %g1 ldx [%fp+2015], %g5 mov 0, %o0 call %g1, 0  nop mov %o0, %g1 stx %g1, [%fp+2023] ldx [%fp+2023], %g1 stx %g1, [%fp+1999]   line 121 
 .stabn 68,0,121,.LLM63-.LLFBB4.LLM63: ldx [%fp+1999], %g1 brz %g1, .LL33  nop.LL32: .stabn 68,0,122,.LLM64-.LLFBB4.LLM64:
g1 points to RTSignal_I3
(gdb) x/i $pc0x3ff0a8 :        ldx  [ %g1 ], %g1
(gdb) x/i $g10x4021f4 : save  %sp, -208, %sp
I am willing to accept that a "function pointer" is a pair of pointers, or even three pointers.A pointer to code, a pointer to globals for position independent code, a frame pointer to locals.That equality comparison of function pointers requires comparing two (or three) pointers.
  (Though the global pointer shouldn't need comparing.)At least for nested functions. Less so for non-nested. ?Much less for comparison to NIL. ?
And either way, this code is reading bogus data.There isn't a pointer at the function address, there is code.
Something doesn't add up.
I'm going to try setting "aligned procedures" but that's quite bogus I think.
EqualExpr.m3 says
       Note: procedures pointers are always aligned!
but maybe not?
Yeah yeah I'm being lazy. I'll read more code..
I also wonder if a "function pointer" can be optimized for the case of not being to a nested function.It looks like calling a function pointer is very inefficient.It looks like..am I reading that correctly?.. that if the pointer points to -1, then it is nested anda pair of pointers, and not otherwise. That -1 is treated specially as the first bytes of a function?
Is that a Modula-3-ism or a SPARC-ism?It looks like a Modula-3-ism. And it seems dubious.But I'll have to read more..
 
NT386GNU does the same sort of wrong looking thing:
 
LFBB4: pushl %ebp movl %esp, %ebp subl $24, %espLBB5: .stabn 68,0,117,LM60-LFBB4LM60: movl $0, -16(%ebp) .stabn 68,0,119,LM61-LFBB4LM61: movl 8(%ebp), %eax testl %eax, %eax je L26 movl 8(%ebp), %eax movl (%eax), %eax                  BAD  cmpl $-1, %eax                       BAD  je L27L26: movl 8(%ebp), %eax testl %eax, %eax je L33L27: .stabn 68,0,120,LM62-LFBB4LM62:
 
and NT386:
 
0:000> ucm3!RTLinker__AddUnit:00607864 55              push    ebp00607865 8bec            mov     ebp,esp00607867 81ec0c000000    sub     esp,0Ch0060786d 53              push    ebx0060786e 56              push    esi0060786f 57              push    edi00607870 c745fc00000000  mov     dword ptr [ebp-4],000607877 837d0800        cmp     dword ptr [ebp+8],00:000> ucm3!RTLinker__AddUnit+0x17:0060787b 0f840f000000    je      cm3!RTLinker__AddUnit+0x2c (00607890)00607881 8b7508          mov     esi,dword ptr [ebp+8]00607884 8b5e00          mov     ebx,dword ptr [esi]                            BAD  00607887 83fbff          cmp     ebx,0FFFFFFFFh                                  BAD 0060788a 0f840f000000    je      cm3!RTLinker__AddUnit+0x3b (0060789f)00607890 837d0800        cmp     dword ptr [ebp+8],000607894 0f8505000000    jne     cm3!RTLinker__AddUnit+0x3b (0060789f)0060789a e969000000      jmp     cm3!RTLinker__AddUnit+0xa4 (00607908)
 
cm3!RTLinker__AddUnit+0x20:00607884 8b5e00          mov     ebx,dword ptr [esi]  ds:002b:0062c950=81ec8b550:000> u @esicm3!RTLinker_I3:0062c950 55              push    ebp0062c951 8bec            mov     ebp,esp0062c953 81ec00000000    sub     esp,00062c959 53              push    ebx0062c95a 56              push    esi0062c95b 57              push    edi0062c95c 837d0800        cmp     dword ptr [ebp+8],00062c960 0f8400000000    je      cm3!RTLinker_I3+0x16 (0062c966)
 
This is just wrong.
Comparing bytes of code to -1.
 
I think the likely fix is for the "I3" code to be laid out as a "constant function pointer", a pointer to a pair of pointers where one points to the code and one is to -1. Something like that. That can't be quite correct given that the existing data is callable.
  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sun May 25 02:48:32 2008
From: jayk123 at hotmail.com (Jay)
Date: Sun, 25 May 2008 00:48:32 +0000
Subject: [M3devel] function pointers and comparison to nil? mis-typed
 function pointers?
In-Reply-To: 
References: <483862F4.1E75.00D7.1@scires.com>
	
Message-ID: 

I see somewhat.
It's stuff around "closure".
The comparison of code bytes to -1 comes from If_closure for example.
 
The problem is presumably to come up with a unified representation of pointers to functions that may or may not be nested, while avoiding runtime codegen, even just a little bit, and for Modula-3 and C function pointers to use the same representation.
I don't think the present solution is really valid, and I am skeptical that there is a solution.
One of the requirements has to be dropped.
Sniffing code bytes and trying to decide if they are code or not as appears to currently happen is bogus.
 
I think the solution is to remove the requirement that a Modula-3 function pointer and a C function pointer are the same.
Except, well, that probably doesn't work -- it means you need two types of function pointers.
 
Darn this is a hard problem.
 
The runtime codegen required can be exceedingly simple, fast, and small IF it were allowed to be on the stack. But that's a killer these days.
 
I think you have to give up unification of "closures" and "function pointers".
If you take the address of a nested function and call it, you cannot access the locals of the enclosing scopes.
So in affect, you end up with "two types of function pointers".
Regular stateless ones and "closures" with some captured state.
 
Thoughts?
 
I'm kind of stumped. It's a desirable problem to solve, and there is a purported solution in place, but the solution that is there is completely bogus, despite appearing to work for a long time, and there is no solution. That is my understanding. I could be wrong on any number of points but I'm pretty sure.
 
I think you have to separate out function pointers and closures.
Sniffing what it pointed to is dubous esp. as currently implemented.
If this is really the way to go, then signature bytes need to be worked out for all architectures that are guaranteed to not look like code.
Or vice versa -- signature bytes worked out that all functions start with, which is viable for Modula-3 but not for interop with C.
Currently -1 is used, of pointer-size.
That appears to be reasonable for x86:
 
0:000> eb . ff ff ff ff0:000> u .ntdll32!DbgBreakPoint:7d61002d ff              ???7d61002e ff              ???7d61002f ff              ???7d610030 ffc3            inc     ebx
 
but the instruction encodings or disassembly on other architectures would have to be checked.
 
 - Jay


From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Sun, 25 May 2008 00:16:01 +0000Subject: [M3devel] function pointers and comparison to nil? mis-typed function pointers?


I'm being lazy...Tony can you explain this stuff?Comparison of function pointers..What are the various representations and rules?What does it mean to compare nested functions?What does it mean to compare a function to NIL?I'll poke around more.What I am seeing is that comparison of function pointers to NIL is surprisinglyexpensive, and probably somewhat buggy. Or at least some of the runtimegenerated "metadata-ish" stuff is produced or typed incorrectly.In particular, RTLinker.m3:PROCEDURE AddUnit (b: RT0.Binder) =  VAR m: RT0.ModulePtr;  BEGIN    IF (b = NIL) THEN RETURN END;   line 119    m := b(0);                      line 120    IF (m = NIL) THEN RETURN END;   line 121    AddUnitI(m);                    line 122   END AddUnit;generates a lot of code, just for the first line:  (556) set_source_line      source line  119    (557) load      m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb    (558) load_nil    (559) if_eq    (560) load      m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb    (561) load_indirect      load address offset 0x0 src_t 0x5 dst_t 0x5    (562) load_integer      integer n_bytes 0x0 hi 0x0 low 0x1 sign -1    (563) if_eq    (564) set_label    (565) load_nil    (566) load      m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb    (567) if_ne    (568) set_label    (569) exit_proc    (570) set_label    (571) set_source_line      source line  120  The details on the load_integer trace might not be completely correct. I will test a fix shortly.Esp. that n_bytes gets decremented to zero before the trace.Ok, I see now why some of the bloat -- because the "then return end" is on the same line.If it were written as:  if (b = NIL THEN      return   end   It probably wouldn't look so bad. That took me a while to realize.The following is generated for SPARC64_OPENBSD:  line 119  .stabn 68,0,119,.LLM61-.LLFBB4 .LLM61: ldx [%fp+2175], %g1 brz %g1, .LL26  nop ldx [%fp+2175], %g1 ldx [%g1], %g1            bus error here? yes, probably this one cmp %g1, -1 be %xcc, .LL27  nop.LL26: ldx [%fp+2175], %g1 brz %g1, .LL33  nop.LL27: line 120  .stabn 68,0,120,.LLM62-.LLFBB4.LLM62: ldx [%fp+2175], %g1 stx %g1, [%fp+2007] ldx [%fp+2007], %g1 brz %g1, .LL30  nop ldx [%fp+2007], %g1 ldx [%g1], %g1            or here ? cmp %g1, -1 bne %xcc, .LL30  nop ldx [%fp+2007], %g1 add %g1, 16, %g1 ldx [%g1], %g1           or here?  stx %g1, [%fp+2015] ldx [%fp+2007], %g1 add %g1, 8, %g1 ldx [%g1], %g1 stx %g1, [%fp+2007].LL30: ldx [%fp+2007], %g1 ldx [%fp+2015], %g5 mov 0, %o0 call %g1, 0  nop mov %o0, %g1 stx %g1, [%fp+2023] ldx [%fp+2023], %g1 stx %g1, [%fp+1999]   line 121  .stabn 68,0,121,.LLM63-.LLFBB4.LLM63: ldx [%fp+1999], %g1 brz %g1, .LL33  nop.LL32: .stabn 68,0,122,.LLM64-.LLFBB4.LLM64:g1 points to RTSignal_I3(gdb) x/i $pc0x3ff0a8 :        ldx  [ %g1 ], %g1(gdb) x/i $g10x4021f4 : save  %sp, -208, %spI am willing to accept that a "function pointer" is a pair of pointers, or even three pointers.A pointer to code, a pointer to globals for position independent code, a frame pointer to locals.That equality comparison of function pointers requires comparing two (or three) pointers.  (Though the global pointer shouldn't need comparing.)At least for nested functions. Less so for non-nested. ?Much less for comparison to NIL. ?And either way, this code is reading bogus data.There isn't a pointer at the function address, there is code.Something doesn't add up.I'm going to try setting "aligned procedures" but that's quite bogus I think.EqualExpr.m3 says       Note: procedures pointers are always aligned!but maybe not?Yeah yeah I'm being lazy. I'll read more code..I also wonder if a "function pointer" can be optimized for the case of not being to a nested function.It looks like calling a function pointer is very inefficient.It looks like..am I reading that correctly?.. that if the pointer points to -1, then it is nested anda pair of pointers, and not otherwise. That -1 is treated specially as the first bytes of a function?Is that a Modula-3-ism or a SPARC-ism?It looks like a Modula-3-ism. And it seems dubious.But I'll have to read more.. NT386GNU does the same sort of wrong looking thing: LFBB4: pushl %ebp movl %esp, %ebp subl $24, %espLBB5: .stabn 68,0,117,LM60-LFBB4LM60: movl $0, -16(%ebp) .stabn 68,0,119,LM61-LFBB4LM61: movl 8(%ebp), %eax testl %eax, %eax je L26 movl 8(%ebp), %eax movl (%eax), %eax                  BAD  cmpl $-1, %eax                       BAD  je L27L26: movl 8(%ebp), %eax testl %eax, %eax je L33L27: .stabn 68,0,120,LM62-LFBB4LM62: and NT386: 0:000> ucm3!RTLinker__AddUnit:00607864 55              push    ebp00607865 8bec            mov     ebp,esp00607867 81ec0c000000    sub     esp,0Ch0060786d 53              push    ebx0060786e 56              push    esi0060786f 57              push    edi00607870 c745fc00000000  mov     dword ptr [ebp-4],000607877 837d0800        cmp     dword ptr [ebp+8],00:000> ucm3!RTLinker__AddUnit+0x17:0060787b 0f840f000000    je      cm3!RTLinker__AddUnit+0x2c (00607890)00607881 8b7508          mov     esi,dword ptr [ebp+8]00607884 8b5e00          mov     ebx,dword ptr [esi]                            BAD  00607887 83fbff          cmp     ebx,0FFFFFFFFh                                  BAD 0060788a 0f840f000000    je      cm3!RTLinker__AddUnit+0x3b (0060789f)00607890 837d0800        cmp     dword ptr [ebp+8],000607894 0f8505000000    jne     cm3!RTLinker__AddUnit+0x3b (0060789f)0060789a e969000000      jmp     cm3!RTLinker__AddUnit+0xa4 (00607908) cm3!RTLinker__AddUnit+0x20:00607884 8b5e00          mov     ebx,dword ptr [esi]  ds:002b:0062c950=81ec8b550:000> u @esicm3!RTLinker_I3:0062c950 55              push    ebp0062c951 8bec            mov     ebp,esp0062c953 81ec00000000    sub     esp,00062c959 53              push    ebx0062c95a 56              push    esi0062c95b 57              push    edi0062c95c 837d0800        cmp     dword ptr [ebp+8],00062c960 0f8400000000    je      cm3!RTLinker_I3+0x16 (0062c966) This is just wrong.Comparing bytes of code to -1. I think the likely fix is for the "I3" code to be laid out as a "constant function pointer", a pointer to a pair of pointers where one points to the code and one is to -1. Something like that. That can't be quite correct given that the existing data is callable.  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sun May 25 08:42:35 2008
From: jayk123 at hotmail.com (Jay)
Date: Sun, 25 May 2008 06:42:35 +0000
Subject: [M3devel] cstdio.i3?
In-Reply-To: 
References: <483862F4.1E75.00D7.1@scires.com>
	
Message-ID: 

I'm wondering about Cstdio.i3..
 
It bugs me to see duplicated code/declarations, code I can't easily verify the correctness of, code that duplicates internal details either that aren't necessary and/or are subject to change (ie: it *might* be useful to know the size of a FILE, but knowing the internal makeup is not generally useful, as well the size can be abstracted away behind a tiny bit of portable C), etc.
 
interface Cstdio seems
 
- almost not used at all within the "std" packages
I realize folks out there with other code could be using it.
The only use I see is related to the next:
 
 - to offer little in the way of a portable interface
About the main portable thing is presents is that there is a type FILE_star, though even that isn't quite universial across them all; conceptually it is of course
However, a medium sized very portable interface is easy to expose, though it isn't necessarily easy to make much use of.
 
So:
 - do nothing?
 - reduce it all down to just a common two-liner TYPE FILE = RECORD END; FILE_star = UNTRACED REF FILE ?
 - bulk it up slightly to a very portable (target-independent) interface?
   NT386/Cstdio.i3 is close to what that would be.
 
And no, I'm not forgetful. I know I brought this up a few months ago when I introduced NT386/Cstdio.i3.
 
Does anyone find the knowledge built up in the myriad Cstdio.i3 files useful?
One thing to do is leave all the per-platform files but not put them in the m3makefile, only actually compile the two line or medium sized portable version.
 
 ?
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rodney.bates at wichita.edu  Mon May 26 05:50:15 2008
From: rodney.bates at wichita.edu (Rodney M. Bates)
Date: Sun, 25 May 2008 22:50:15 -0500
Subject: [M3devel] function pointers and comparison to nil? mis-typed
 function pointers?
In-Reply-To: 
References: <483862F4.1E75.00D7.1@scires.com>
	
	
Message-ID: <483A3377.7070801@wichita.edu>

I think I can shed some light on this, having spent some time making
m3gdb handle the various operations on nested procedures.  As for code
that mixes M3 and C, I believe the following are true:

- Within M3 code only, the closure system works correctly in all cases.
   This answers one of Jay's worries.

- For values of M3 procedure/C function pointer that are top-level
   (nonnested) procedures/functions, M3 and C code (generated by gcc,
   at least) are interchangeable.  This answers another of Jay's worries.
   This will cover that great majority of cases.

- Standard C has no nested functions.  Gcc adds them as a language
   extension.  Thus, only in gcc-compiled C code do we need to worry
   about nested procedures/functions between languages.  (Do any other
   C compilers exist that also have nested functions?)

- M3 code should be able to call the value of a procedure variable
   that was originally produced by C code as a pointer to a nested
   function, and get the environment set up right, so its nonlocal
   variable references will work, _if_ the nested function's
   environment has not disappeared.  This partially answers another
   of Jay's worries.  But:

- M3's normal runtime check that precludes assigning a nonlocal
   procedure value will not detect a C-code-produced nonlocal value,
   thus the environment could indeed have disappeared if the programmer
   was not careful.  However, gcc-extended C's nested functions have
   no protection against this bug when only C code is involved, so
   perhaps not detecting it in mixed M3/C is to be expected.

- C code that attempts to call a function pointer value that was
   originally produced by M3 code as a nested procedure value will
   almost certainly crash at the time of the call.  This is the only
   case that presents a significant problem.  M3 code will not be
   able to give a nested procedure as a callback to a C library.

M3's mechanism:  A value of procedure type is a pointer to either
1) the first byte of the procedure's machine code, if it is top level, or
2) A closure.

A closure is a block of 3 words.  The first word contains -1.  Assuming
a word of all one bits is not valid machine code on any target machine
(or at least doesn't occur as the first code of any procedure), this can
be used at runtime to detect that this is indeed a closure and not code.
The remaining two words hold the code address and the environment address.

So, an assignment of a procedure value has to check that it is not a closure,
and raise a runtime error if it is.  A call on a procedure value has to check,
and if it is a closure, load/copy its environment pointer value into wherever
the calling convention expects it, then branch to the code address.  Passing
a nested procedure constant as a parameter involves constructing a closure for
it and passing its address.

gcc-C's mechanism:  A value of type pointer to function is a pointer to either
1) the first byte of the function's machine code, if it is top level,
    (the same as with M3), or
2) A trampoline.

A trampoline is a bit of code that loads/copies an environment pointer (hard
coded into the trampoline) and then branches to the function code.

Trampolines probably have a small constant-time speed advantage for _calls_,
but would be slower for some of the other operations, and the runtime check
could be tricky.  Probably it could be fooled into failing when it shouldn't.
Moreover, trampolines are highly target-machine-dependent.  Switching to them
would create a really big problem for m3gdb, which would have to have
different code for each target for each of the nested procedure operations.

Jay wrote:
> I see somewhat.
> It's stuff around "closure".
> The comparison of code bytes to -1 comes from If_closure for example.
>  
> The problem is presumably to come up with a unified representation of 
> pointers to functions that may or may not be nested, while avoiding 
> runtime codegen, even just a little bit, and for Modula-3 and C function 
> pointers to use the same representation.
> I don't think the present solution is really valid, and I am skeptical 
> that there is a solution.
> One of the requirements has to be dropped.
> Sniffing code bytes and trying to decide if they are code or not as 
> appears to currently happen is bogus.
>  
> I think the solution is to remove the requirement that a Modula-3 
> function pointer and a C function pointer are the same.
> Except, well, that probably doesn't work -- it means you need two types 
> of function pointers.
>  
> Darn this is a hard problem.
>  
> The runtime codegen required can be exceedingly simple, fast, and small 
> IF it were allowed to be on the stack. But that's a killer these days.
>  
> I think you have to give up unification of "closures" and "function 
> pointers".
> If you take the address of a nested function and call it, you cannot 
> access the locals of the enclosing scopes.
> So in affect, you end up with "two types of function pointers".
> Regular stateless ones and "closures" with some captured state.
>  
> Thoughts?
>  
> I'm kind of stumped. It's a desirable problem to solve, and there is a 
> purported solution in place, but the solution that is there is 
> completely bogus, despite appearing to work for a long time, and there 
> is no solution. That is my understanding. I could be wrong on any number 
> of points but I'm pretty sure.
>  
> I think you have to separate out function pointers and closures.
> Sniffing what it pointed to is dubous esp. as currently implemented.
> If this is really the way to go, then signature bytes need to be worked 
> out for all architectures that are guaranteed to not look like code.
> Or vice versa -- signature bytes worked out that all functions start 
> with, which is viable for Modula-3 but not for interop with C.
> Currently -1 is used, of pointer-size.
> That appears to be reasonable for x86:
>  
> 0:000> eb . ff ff ff ff
> 0:000> u .
> ntdll32!DbgBreakPoint:
> 7d61002d ff              ???
> 7d61002e ff              ???
> 7d61002f ff              ???
> 7d610030 ffc3            inc     ebx
>  
> but the instruction encodings or disassembly on other architectures 
> would have to be checked.
>  
>  - Jay
> 
>     ------------------------------------------------------------------------
>     From: jayk123 at hotmail.com
>     To: m3devel at elegosoft.com
>     Date: Sun, 25 May 2008 00:16:01 +0000
>     Subject: [M3devel] function pointers and comparison to nil?
>     mis-typed function pointers?
> 
>     I'm being lazy...
> 
>     Tony can you explain this stuff?
> 
>     Comparison of function pointers..
>     What are the various representations and rules?
> 
>     What does it mean to compare nested functions?
> 
>     What does it mean to compare a function to NIL?
> 
>     I'll poke around more.
> 
>     What I am seeing is that comparison of function pointers to NIL is
>     surprisingly
>     expensive, and probably somewhat buggy. Or at least some of the runtime
>     generated "metadata-ish" stuff is produced or typed incorrectly.
> 
>     In particular, RTLinker.m3:
> 
>     PROCEDURE AddUnit (b: RT0.Binder) =
>       VAR m: RT0.ModulePtr;
>       BEGIN
>         IF (b = NIL) THEN RETURN END;   line 119
>         m := b(0);                      line 120
>         IF (m = NIL) THEN RETURN END;   line 121
>         AddUnitI(m);                    line 122
>       END AddUnit;
> 
>     generates a lot of code, just for the first line:
>       (556) set_source_line 
>         source line  119 
>       (557) load 
>         m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb 
>       (558) load_nil 
>       (559) if_eq 
>       (560) load 
>         m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb 
>       (561) load_indirect 
>         load address offset 0x0 src_t 0x5 dst_t 0x5 
>       (562) load_integer 
>         integer n_bytes 0x0 hi 0x0 low 0x1 sign -1 
>       (563) if_eq 
>       (564) set_label 
>       (565) load_nil 
>       (566) load 
>         m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb 
>       (567) if_ne 
>       (568) set_label 
>       (569) exit_proc 
>       (570) set_label 
>       (571) set_source_line 
>         source line  120 
> 
>     The details on the load_integer trace might not be completely
>     correct. I will test a fix shortly.
>     Esp. that n_bytes gets decremented to zero before the trace.
> 
>     Ok, I see now why some of the bloat -- because the "then return end"
>     is on the same line.
>     If it were written as:
>       if (b = NIL THEN 
>         return
>       end  
>     It probably wouldn't look so bad. That took me a while to realize.
> 
>     The following is generated for SPARC64_OPENBSD:
>      
>      line 119
>      .stabn 68,0,119,.LLM61-.LLFBB4
>     .LLM61:
>      ldx [%fp+2175], %g1
>      brz %g1, .LL26
>       nop
>      ldx [%fp+2175], %g1
>      ldx [%g1], %g1            bus error here? yes, probably this one
>      cmp %g1, -1
>      be %xcc, .LL27
>       nop
>     .LL26:
>      ldx [%fp+2175], %g1
>      brz %g1, .LL33
>       nop
>     .LL27:
>      line 120
>      .stabn 68,0,120,.LLM62-.LLFBB4
>     .LLM62:
>      ldx [%fp+2175], %g1
>      stx %g1, [%fp+2007]
>      ldx [%fp+2007], %g1
>      brz %g1, .LL30
>       nop
>      ldx [%fp+2007], %g1
>      ldx [%g1], %g1            or here ?
>      cmp %g1, -1
>      bne %xcc, .LL30
>       nop
>      ldx [%fp+2007], %g1
>      add %g1, 16, %g1
>      ldx [%g1], %g1           or here?
>      stx %g1, [%fp+2015]
>      ldx [%fp+2007], %g1
>      add %g1, 8, %g1
>      ldx [%g1], %g1
>      stx %g1, [%fp+2007]
>     .LL30:
>      ldx [%fp+2007], %g1
>      ldx [%fp+2015], %g5
>      mov 0, %o0
>      call %g1, 0
>       nop
>      mov %o0, %g1
>      stx %g1, [%fp+2023]
>      ldx [%fp+2023], %g1
>      stx %g1, [%fp+1999]
>      
>      line 121
> 
>      .stabn 68,0,121,.LLM63-.LLFBB4
>     .LLM63:
>      ldx [%fp+1999], %g1
>      brz %g1, .LL33
>       nop
>     .LL32:
>      .stabn 68,0,122,.LLM64-.LLFBB4
>     .LLM64:
> 
>     g1 points to RTSignal_I3
> 
>     (gdb) x/i $pc
>     0x3ff0a8 :        ldx  [ %g1 ], %g1
>     (gdb) x/i $g1
>     0x4021f4 : save  %sp, -208, %sp
> 
>     I am willing to accept that a "function pointer" is a pair of
>     pointers, or even three pointers.
>     A pointer to code, a pointer to globals for position independent
>     code, a frame pointer to locals.
>     That equality comparison of function pointers requires comparing two
>     (or three) pointers.
>       (Though the global pointer shouldn't need comparing.)
>     At least for nested functions. Less so for non-nested. ?
>     Much less for comparison to NIL. ?
> 
>     And either way, this code is reading bogus data.
>     There isn't a pointer at the function address, there is code.
> 
>     Something doesn't add up.
> 
>     I'm going to try setting "aligned procedures" but that's quite bogus
>     I think.
> 
>     EqualExpr.m3 says
> 
>            Note: procedures pointers are always aligned!
> 
>     but maybe not?
> 
>     Yeah yeah I'm being lazy. I'll read more code..
> 
>     I also wonder if a "function pointer" can be optimized for the case
>     of not being to a nested function.
>     It looks like calling a function pointer is very inefficient.
>     It looks like..am I reading that correctly?.. that if the pointer
>     points to -1, then it is nested and
>     a pair of pointers, and not otherwise. That -1 is treated specially
>     as the first bytes of a function?
>     Is that a Modula-3-ism or a SPARC-ism?
>     It looks like a Modula-3-ism. And it seems dubious.
>     But I'll have to read more..
>      
>     NT386GNU does the same sort of wrong looking thing:
>      
>     LFBB4:
>      pushl %ebp
>      movl %esp, %ebp
>      subl $24, %esp
>     LBB5:
>      .stabn 68,0,117,LM60-LFBB4
>     LM60:
>      movl $0, -16(%ebp)
>      .stabn 68,0,119,LM61-LFBB4
>     LM61:
>      movl 8(%ebp), %eax
>      testl %eax, %eax
>      je L26
>      movl 8(%ebp), %eax
>      movl (%eax), %eax                  BAD
>      cmpl $-1, %eax                       BAD
>      je L27
>     L26:
>      movl 8(%ebp), %eax
>      testl %eax, %eax
>      je L33
>     L27:
>      .stabn 68,0,120,LM62-LFBB4
>     LM62:
> 
>      
>     and NT386:
>      
>     0:000> u
>     cm3!RTLinker__AddUnit:
>     00607864 55              push    ebp
>     00607865 8bec            mov     ebp,esp
>     00607867 81ec0c000000    sub     esp,0Ch
>     0060786d 53              push    ebx
>     0060786e 56              push    esi
>     0060786f 57              push    edi
>     00607870 c745fc00000000  mov     dword ptr [ebp-4],0
>     00607877 837d0800        cmp     dword ptr [ebp+8],0
>     0:000> u
>     cm3!RTLinker__AddUnit+0x17:
>     0060787b 0f840f000000    je      cm3!RTLinker__AddUnit+0x2c (00607890)
>     00607881 8b7508          mov     esi,dword ptr [ebp+8]
>     00607884 8b5e00          mov     ebx,dword ptr
>     [esi]                            BAD 
>     00607887 83fbff          cmp    
>     ebx,0FFFFFFFFh                                  BAD
>     0060788a 0f840f000000    je      cm3!RTLinker__AddUnit+0x3b (0060789f)
>     00607890 837d0800        cmp     dword ptr [ebp+8],0
>     00607894 0f8505000000    jne     cm3!RTLinker__AddUnit+0x3b (0060789f)
>     0060789a e969000000      jmp     cm3!RTLinker__AddUnit+0xa4 (00607908)
>      
>     cm3!RTLinker__AddUnit+0x20:
>     00607884 8b5e00          mov     ebx,dword ptr [esi] 
>     ds:002b:0062c950=81ec8b55
>     0:000> u @esi
>     cm3!RTLinker_I3:
>     0062c950 55              push    ebp
>     0062c951 8bec            mov     ebp,esp
>     0062c953 81ec00000000    sub     esp,0
>     0062c959 53              push    ebx
>     0062c95a 56              push    esi
>     0062c95b 57              push    edi
>     0062c95c 837d0800        cmp     dword ptr [ebp+8],0
>     0062c960 0f8400000000    je      cm3!RTLinker_I3+0x16 (0062c966)
>      
>     This is just wrong.
>     Comparing bytes of code to -1.
>      
>     I think the likely fix is for the "I3" code to be laid out as a
>     "constant function pointer", a pointer to a pair of pointers where
>     one points to the code and one is to -1. Something like that. That
>     can't be quite correct given that the existing data is callable.
> 
>       - Jay

-- 
-------------------------------------------------------------
Rodney M. Bates, retired assistant professor
Dept. of Computer Science, Wichita State University
Wichita, KS 67260-0083
316-978-3922
rodney.bates at wichita.edu


From jayk123 at hotmail.com  Mon May 26 07:26:41 2008
From: jayk123 at hotmail.com (Jay)
Date: Mon, 26 May 2008 05:26:41 +0000
Subject: [M3devel] function pointers and comparison to nil? mis-typed
 function pointers?
In-Reply-To: <483A3377.7070801@wichita.edu>
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
Message-ID: 

Rodney, this agrees with much of what I figured out and guessed. I did not think of or look into some of what you point out though:
  - what gcc's nested functions look like, and if you can take the address, and what that does 
  - calling Modula-3 nested functions as callbacks from C 
 
Now, regarding trampolines.
I alluded to them. It should be easy enough to generate them, and this would solve a few problems, but I believe also bring up a new big problem.
Generating trampolines solves at least two problems: 
 - it allows Modula-3 nested function pointers ("closures") to be called from C 
 - it enables removing the check for -1 
 
I contend that the check for -1 is not good. It is a somewhat risky assumption, that "-1" is not valid code.
You do bring up a nice mitigation -- the assumption that it doesn't begin any functions, which is much narrower than it being valid code anywhere.
 
For SPARC64_OPENBSD I figured out what the original authors meant to be the fix.
You declare functions as not aligned, leading to the check for -1 first checking alignment (bigger code).
Any pointer not aligned on an integer-sized address is presumed not a closure and not checked for the -1.
This lets SPARC64_OPENBSD get further. Both it and PPC32_OPENBSD now for some reason suffer from an inability to heap allocate anything, failing around the attempt to create a new thread like in RTAllocator_M or so. I'll look into this more later.
Now, the problem of trampolines..I consider the platform-dependent-ness to be surmountable.
But where do you put the generated code? Putting it on the stack is counter to modern (and possibly old) "security" mechanisms.
The stack is not generally executable, and even when it is, best just not do use that imho.
 
That means, potentially/obviously, the need to heap allocate executable memory, for very small short lived data, quite inefficient.
 
Is there some other way/place to produce trampolines, efficiently?
 
In the absence of any good solution, I have to resign myself to assuming that -1 isn't the valid start of a function, and perhaps moving the marker into Target.i3, Target.m3 so that "more obvious" values get chosen. Like a breakpoint. Or "an epilogue", or "a trap instruction". I realize this needs details and is easily seen as "wrong". In particular, a function that does nothing could be termed as only having an "an epilogue".
 
I know that other systems are "forced" to create "trampolines" so I should look into how they do that.
I know that ATL, a Windows-specific library, is forced to heap allocate small executable chunks of memory and uses an efficient cache to optimize it.
 
I do find this dependence on -1 not being the valid start of a function rather sleazy and at risk of being wrong.
 
 - Jay



> Date: Sun, 25 May 2008 22:50:15 -0500> From: rodney.bates at wichita.edu> To: m3devel at elegosoft.com> Subject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?> > I think I can shed some light on this, having spent some time making> m3gdb handle the various operations on nested procedures. As for code> that mixes M3 and C, I believe the following are true:> > - Within M3 code only, the closure system works correctly in all cases.> This answers one of Jay's worries.> > - For values of M3 procedure/C function pointer that are top-level> (nonnested) procedures/functions, M3 and C code (generated by gcc,> at least) are interchangeable. This answers another of Jay's worries.> This will cover that great majority of cases.> > - Standard C has no nested functions. Gcc adds them as a language> extension. Thus, only in gcc-compiled C code do we need to worry> about nested procedures/functions between languages. (Do any other> C compilers exist that also have nested functions?)> > - M3 code should be able to call the value of a procedure variable> that was originally produced by C code as a pointer to a nested> function, and get the environment set up right, so its nonlocal> variable references will work, _if_ the nested function's> environment has not disappeared. This partially answers another> of Jay's worries. But:> > - M3's normal runtime check that precludes assigning a nonlocal> procedure value will not detect a C-code-produced nonlocal value,> thus the environment could indeed have disappeared if the programmer> was not careful. However, gcc-extended C's nested functions have> no protection against this bug when only C code is involved, so> perhaps not detecting it in mixed M3/C is to be expected.> > - C code that attempts to call a function pointer value that was> originally produced by M3 code as a nested procedure value will> almost certainly crash at the time of the call. This is the only> case that presents a significant problem. M3 code will not be> able to give a nested procedure as a callback to a C library.> > M3's mechanism: A value of procedure type is a pointer to either> 1) the first byte of the procedure's machine code, if it is top level, or> 2) A closure.> > A closure is a block of 3 words. The first word contains -1. Assuming> a word of all one bits is not valid machine code on any target machine> (or at least doesn't occur as the first code of any procedure), this can> be used at runtime to detect that this is indeed a closure and not code.> The remaining two words hold the code address and the environment address.> > So, an assignment of a procedure value has to check that it is not a closure,> and raise a runtime error if it is. A call on a procedure value has to check,> and if it is a closure, load/copy its environment pointer value into wherever> the calling convention expects it, then branch to the code address. Passing> a nested procedure constant as a parameter involves constructing a closure for> it and passing its address.> > gcc-C's mechanism: A value of type pointer to function is a pointer to either> 1) the first byte of the function's machine code, if it is top level,> (the same as with M3), or> 2) A trampoline.> > A trampoline is a bit of code that loads/copies an environment pointer (hard> coded into the trampoline) and then branches to the function code.> > Trampolines probably have a small constant-time speed advantage for _calls_,> but would be slower for some of the other operations, and the runtime check> could be tricky. Probably it could be fooled into failing when it shouldn't.> Moreover, trampolines are highly target-machine-dependent. Switching to them> would create a really big problem for m3gdb, which would have to have> different code for each target for each of the nested procedure operations.> > Jay wrote:> > I see somewhat.> > It's stuff around "closure".> > The comparison of code bytes to -1 comes from If_closure for example.> > > > The problem is presumably to come up with a unified representation of > > pointers to functions that may or may not be nested, while avoiding > > runtime codegen, even just a little bit, and for Modula-3 and C function > > pointers to use the same representation.> > I don't think the present solution is really valid, and I am skeptical > > that there is a solution.> > One of the requirements has to be dropped.> > Sniffing code bytes and trying to decide if they are code or not as > > appears to currently happen is bogus.> > > > I think the solution is to remove the requirement that a Modula-3 > > function pointer and a C function pointer are the same.> > Except, well, that probably doesn't work -- it means you need two types > > of function pointers.> > > > Darn this is a hard problem.> > > > The runtime codegen required can be exceedingly simple, fast, and small > > IF it were allowed to be on the stack. But that's a killer these days.> > > > I think you have to give up unification of "closures" and "function > > pointers".> > If you take the address of a nested function and call it, you cannot > > access the locals of the enclosing scopes.> > So in affect, you end up with "two types of function pointers".> > Regular stateless ones and "closures" with some captured state.> > > > Thoughts?> > > > I'm kind of stumped. It's a desirable problem to solve, and there is a > > purported solution in place, but the solution that is there is > > completely bogus, despite appearing to work for a long time, and there > > is no solution. That is my understanding. I could be wrong on any number > > of points but I'm pretty sure.> > > > I think you have to separate out function pointers and closures.> > Sniffing what it pointed to is dubous esp. as currently implemented.> > If this is really the way to go, then signature bytes need to be worked > > out for all architectures that are guaranteed to not look like code.> > Or vice versa -- signature bytes worked out that all functions start > > with, which is viable for Modula-3 but not for interop with C.> > Currently -1 is used, of pointer-size.> > That appears to be reasonable for x86:> > > > 0:000> eb . ff ff ff ff> > 0:000> u .> > ntdll32!DbgBreakPoint:> > 7d61002d ff ???> > 7d61002e ff ???> > 7d61002f ff ???> > 7d610030 ffc3 inc ebx> > > > but the instruction encodings or disassembly on other architectures > > would have to be checked.> > > > - Jay> > > > ------------------------------------------------------------------------> > From: jayk123 at hotmail.com> > To: m3devel at elegosoft.com> > Date: Sun, 25 May 2008 00:16:01 +0000> > Subject: [M3devel] function pointers and comparison to nil?> > mis-typed function pointers?> > > > I'm being lazy...> > > > Tony can you explain this stuff?> > > > Comparison of function pointers..> > What are the various representations and rules?> > > > What does it mean to compare nested functions?> > > > What does it mean to compare a function to NIL?> > > > I'll poke around more.> > > > What I am seeing is that comparison of function pointers to NIL is> > surprisingly> > expensive, and probably somewhat buggy. Or at least some of the runtime> > generated "metadata-ish" stuff is produced or typed incorrectly.> > > > In particular, RTLinker.m3:> > > > PROCEDURE AddUnit (b: RT0.Binder) => > VAR m: RT0.ModulePtr;> > BEGIN> > IF (b = NIL) THEN RETURN END; line 119> > m := b(0); line 120> > IF (m = NIL) THEN RETURN END; line 121> > AddUnitI(m); line 122> > END AddUnit;> > > > generates a lot of code, just for the first line:> > (556) set_source_line > > source line 119 > > (557) load > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb > > (558) load_nil > > (559) if_eq > > (560) load > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb > > (561) load_indirect > > load address offset 0x0 src_t 0x5 dst_t 0x5 > > (562) load_integer > > integer n_bytes 0x0 hi 0x0 low 0x1 sign -1 > > (563) if_eq > > (564) set_label > > (565) load_nil > > (566) load > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb > > (567) if_ne > > (568) set_label > > (569) exit_proc > > (570) set_label > > (571) set_source_line > > source line 120 > > > > The details on the load_integer trace might not be completely> > correct. I will test a fix shortly.> > Esp. that n_bytes gets decremented to zero before the trace.> > > > Ok, I see now why some of the bloat -- because the "then return end"> > is on the same line.> > If it were written as:> > if (b = NIL THEN > > return> > end > > It probably wouldn't look so bad. That took me a while to realize.> > > > The following is generated for SPARC64_OPENBSD:> > > > line 119> > .stabn 68,0,119,.LLM61-.LLFBB4> > .LLM61:> > ldx [%fp+2175], %g1> > brz %g1, .LL26> > nop> > ldx [%fp+2175], %g1> > ldx [%g1], %g1 bus error here? yes, probably this one> > cmp %g1, -1> > be %xcc, .LL27> > nop> > .LL26:> > ldx [%fp+2175], %g1> > brz %g1, .LL33> > nop> > .LL27:> > line 120> > .stabn 68,0,120,.LLM62-.LLFBB4> > .LLM62:> > ldx [%fp+2175], %g1> > stx %g1, [%fp+2007]> > ldx [%fp+2007], %g1> > brz %g1, .LL30> > nop> > ldx [%fp+2007], %g1> > ldx [%g1], %g1 or here ?> > cmp %g1, -1> > bne %xcc, .LL30> > nop> > ldx [%fp+2007], %g1> > add %g1, 16, %g1> > ldx [%g1], %g1 or here?> > stx %g1, [%fp+2015]> > ldx [%fp+2007], %g1> > add %g1, 8, %g1> > ldx [%g1], %g1> > stx %g1, [%fp+2007]> > .LL30:> > ldx [%fp+2007], %g1> > ldx [%fp+2015], %g5> > mov 0, %o0> > call %g1, 0> > nop> > mov %o0, %g1> > stx %g1, [%fp+2023]> > ldx [%fp+2023], %g1> > stx %g1, [%fp+1999]> > > > line 121> > > > .stabn 68,0,121,.LLM63-.LLFBB4> > .LLM63:> > ldx [%fp+1999], %g1> > brz %g1, .LL33> > nop> > .LL32:> > .stabn 68,0,122,.LLM64-.LLFBB4> > .LLM64:> > > > g1 points to RTSignal_I3> > > > (gdb) x/i $pc> > 0x3ff0a8 : ldx [ %g1 ], %g1> > (gdb) x/i $g1> > 0x4021f4 : save %sp, -208, %sp> > > > I am willing to accept that a "function pointer" is a pair of> > pointers, or even three pointers.> > A pointer to code, a pointer to globals for position independent> > code, a frame pointer to locals.> > That equality comparison of function pointers requires comparing two> > (or three) pointers.> > (Though the global pointer shouldn't need comparing.)> > At least for nested functions. Less so for non-nested. ?> > Much less for comparison to NIL. ?> > > > And either way, this code is reading bogus data.> > There isn't a pointer at the function address, there is code.> > > > Something doesn't add up.> > > > I'm going to try setting "aligned procedures" but that's quite bogus> > I think.> > > > EqualExpr.m3 says> > > > Note: procedures pointers are always aligned!> > > > but maybe not?> > > > Yeah yeah I'm being lazy. I'll read more code..> > > > I also wonder if a "function pointer" can be optimized for the case> > of not being to a nested function.> > It looks like calling a function pointer is very inefficient.> > It looks like..am I reading that correctly?.. that if the pointer> > points to -1, then it is nested and> > a pair of pointers, and not otherwise. That -1 is treated specially> > as the first bytes of a function?> > Is that a Modula-3-ism or a SPARC-ism?> > It looks like a Modula-3-ism. And it seems dubious.> > But I'll have to read more..> > > > NT386GNU does the same sort of wrong looking thing:> > > > LFBB4:> > pushl %ebp> > movl %esp, %ebp> > subl $24, %esp> > LBB5:> > .stabn 68,0,117,LM60-LFBB4> > LM60:> > movl $0, -16(%ebp)> > .stabn 68,0,119,LM61-LFBB4> > LM61:> > movl 8(%ebp), %eax> > testl %eax, %eax> > je L26> > movl 8(%ebp), %eax> > movl (%eax), %eax BAD> > cmpl $-1, %eax BAD> > je L27> > L26:> > movl 8(%ebp), %eax> > testl %eax, %eax> > je L33> > L27:> > .stabn 68,0,120,LM62-LFBB4> > LM62:> > > > > > and NT386:> > > > 0:000> u> > cm3!RTLinker__AddUnit:> > 00607864 55 push ebp> > 00607865 8bec mov ebp,esp> > 00607867 81ec0c000000 sub esp,0Ch> > 0060786d 53 push ebx> > 0060786e 56 push esi> > 0060786f 57 push edi> > 00607870 c745fc00000000 mov dword ptr [ebp-4],0> > 00607877 837d0800 cmp dword ptr [ebp+8],0> > 0:000> u> > cm3!RTLinker__AddUnit+0x17:> > 0060787b 0f840f000000 je cm3!RTLinker__AddUnit+0x2c (00607890)> > 00607881 8b7508 mov esi,dword ptr [ebp+8]> > 00607884 8b5e00 mov ebx,dword ptr> > [esi] BAD > > 00607887 83fbff cmp > > ebx,0FFFFFFFFh BAD> > 0060788a 0f840f000000 je cm3!RTLinker__AddUnit+0x3b (0060789f)> > 00607890 837d0800 cmp dword ptr [ebp+8],0> > 00607894 0f8505000000 jne cm3!RTLinker__AddUnit+0x3b (0060789f)> > 0060789a e969000000 jmp cm3!RTLinker__AddUnit+0xa4 (00607908)> > > > cm3!RTLinker__AddUnit+0x20:> > 00607884 8b5e00 mov ebx,dword ptr [esi] > > ds:002b:0062c950=81ec8b55> > 0:000> u @esi> > cm3!RTLinker_I3:> > 0062c950 55 push ebp> > 0062c951 8bec mov ebp,esp> > 0062c953 81ec00000000 sub esp,0> > 0062c959 53 push ebx> > 0062c95a 56 push esi> > 0062c95b 57 push edi> > 0062c95c 837d0800 cmp dword ptr [ebp+8],0> > 0062c960 0f8400000000 je cm3!RTLinker_I3+0x16 (0062c966)> > > > This is just wrong.> > Comparing bytes of code to -1.> > > > I think the likely fix is for the "I3" code to be laid out as a> > "constant function pointer", a pointer to a pair of pointers where> > one points to the code and one is to -1. Something like that. That> > can't be quite correct given that the existing data is callable.> > > > - Jay> > -- > -------------------------------------------------------------> Rodney M. Bates, retired assistant professor> Dept. of Computer Science, Wichita State University> Wichita, KS 67260-0083> 316-978-3922> rodney.bates at wichita.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Mon May 26 12:04:56 2008
From: jayk123 at hotmail.com (Jay)
Date: Mon, 26 May 2008 10:04:56 +0000
Subject: [M3devel] function pointers and comparison to nil? mis-typed
 function pointers?
In-Reply-To: 
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
	
Message-ID: 

Cygwin gcc clearly generates code on the stack for nested functions.
And then search the web..that's how it works in general.
Nested functions have been deprecated on Mac OS X, in anticipation of possibly making the stack not executable.
 
OpenBSD doesn't allow execution on the stack.
They use mprotect to let trampolines run:
  http://gcc.gnu.org/ml/gcc/2004-01/msg00742.html 
and
  http://resin.csoft.net/cgi-bin/man.cgi?section=1&topic=gcc-local 
 
Even though nested functions are a gcc extension to the C language, email threads out there discuss Ada, Pascal, and even ! Modula-3 as having nested functions, and that therefore deprecating the C language feature doesn't "solve" the "problem".
 
I remain uncertain what, if anything, to do here.
 - keep the -1 hack, do nothing 
    generalize it slightly to let targets pick "better" markers 
 - use gcc's supported for nested functions 
   (plus the integrated backend, not difficult) 
 
Clearly this is a dilemna to more than just me. :)
 
 - Jay


From: jayk123 at hotmail.comTo: rodney.bates at wichita.edu; m3devel at elegosoft.comDate: Mon, 26 May 2008 05:26:41 +0000Subject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?


Rodney, this agrees with much of what I figured out and guessed. I did not think of or look into some of what you point out though:  - what gcc's nested functions look like, and if you can take the address, and what that does   - calling Modula-3 nested functions as callbacks from C  Now, regarding trampolines.I alluded to them. It should be easy enough to generate them, and this would solve a few problems, but I believe also bring up a new big problem.Generating trampolines solves at least two problems:  - it allows Modula-3 nested function pointers ("closures") to be called from C  - it enables removing the check for -1  I contend that the check for -1 is not good. It is a somewhat risky assumption, that "-1" is not valid code.You do bring up a nice mitigation -- the assumption that it doesn't begin any functions, which is much narrower than it being valid code anywhere. For SPARC64_OPENBSD I figured out what the original authors meant to be the fix.You declare functions as not aligned, leading to the check for -1 first checking alignment (bigger code).Any pointer not aligned on an integer-sized address is presumed not a closure and not checked for the -1.This lets SPARC64_OPENBSD get further. Both it and PPC32_OPENBSD now for some reason suffer from an inability to heap allocate anything, failing around the attempt to create a new thread like in RTAllocator_M or so. I'll look into this more later.Now, the problem of trampolines..I consider the platform-dependent-ness to be surmountable.But where do you put the generated code? Putting it on the stack is counter to modern (and possibly old) "security" mechanisms.The stack is not generally executable, and even when it is, best just not do use that imho. That means, potentially/obviously, the need to heap allocate executable memory, for very small short lived data, quite inefficient. Is there some other way/place to produce trampolines, efficiently? In the absence of any good solution, I have to resign myself to assuming that -1 isn't the valid start of a function, and perhaps moving the marker into Target.i3, Target.m3 so that "more obvious" values get chosen. Like a breakpoint. Or "an epilogue", or "a trap instruction". I realize this needs details and is easily seen as "wrong". In particular, a function that does nothing could be termed as only having an "an epilogue". I know that other systems are "forced" to create "trampolines" so I should look into how they do that.I know that ATL, a Windows-specific library, is forced to heap allocate small executable chunks of memory and uses an efficient cache to optimize it. I do find this dependence on -1 not being the valid start of a function rather sleazy and at risk of being wrong.  - Jay

> Date: Sun, 25 May 2008 22:50:15 -0500> From: rodney.bates at wichita.edu> To: m3devel at elegosoft.com> Subject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?> > I think I can shed some light on this, having spent some time making> m3gdb handle the various operations on nested procedures. As for code> that mixes M3 and C, I believe the following are true:> > - Within M3 code only, the closure system works correctly in all cases.> This answers one of Jay's worries.> > - For values of M3 procedure/C function pointer that are top-level> (nonnested) procedures/functions, M3 and C code (generated by gcc,> at least) are interchangeable. This answers another of Jay's worries.> This will cover that great majority of cases.> > - Standard C has no nested functions. Gcc adds them as a language> extension. Thus, only in gcc-compiled C code do we need to worry> about nested procedures/functions between languages. (Do any other> C compilers exist that also have nested functions?)> > - M3 code should be able to call the value of a procedure variable> that was originally produced by C code as a pointer to a nested> function, and get the environment set up right, so its nonlocal> variable references will work, _if_ the nested function's> environment has not disappeared. This partially answers another> of Jay's worries. But:> > - M3's normal runtime check that precludes assigning a nonlocal> procedure value will not detect a C-code-produced nonlocal value,> thus the environment could indeed have disappeared if the programmer> was not careful. However, gcc-extended C's nested functions have> no protection against this bug when only C code is involved, so> perhaps not detecting it in mixed M3/C is to be expected.> > - C code that attempts to call a function pointer value that was> originally produced by M3 code as a nested procedure value will> almost certainly crash at the time of the call. This is the only> case that presents a significant problem. M3 code will not be> able to give a nested procedure as a callback to a C library.> > M3's mechanism: A value of procedure type is a pointer to either> 1) the first byte of the procedure's machine code, if it is top level, or> 2) A closure.> > A closure is a block of 3 words. The first word contains -1. Assuming> a word of all one bits is not valid machine code on any target machine> (or at least doesn't occur as the first code of any procedure), this can> be used at runtime to detect that this is indeed a closure and not code.> The remaining two words hold the code address and the environment address.> > So, an assignment of a procedure value has to check that it is not a closure,> and raise a runtime error if it is. A call on a procedure value has to check,> and if it is a closure, load/copy its environment pointer value into wherever> the calling convention expects it, then branch to the code address. Passing> a nested procedure constant as a parameter involves constructing a closure for> it and passing its address.> > gcc-C's mechanism: A value of type pointer to function is a pointer to either> 1) the first byte of the function's machine code, if it is top level,> (the same as with M3), or> 2) A trampoline.> > A trampoline is a bit of code that loads/copies an environment pointer (hard> coded into the trampoline) and then branches to the function code.> > Trampolines probably have a small constant-time speed advantage for _calls_,> but would be slower for some of the other operations, and the runtime check> could be tricky. Probably it could be fooled into failing when it shouldn't.> Moreover, trampolines are highly target-machine-dependent. Switching to them> would create a really big problem for m3gdb, which would have to have> different code for each target for each of the nested procedure operations.> > Jay wrote:> > I see somewhat.> > It's stuff around "closure".> > The comparison of code bytes to -1 comes from If_closure for example.> > > > The problem is presumably to come up with a unified representation of > > pointers to functions that may or may not be nested, while avoiding > > runtime codegen, even just a little bit, and for Modula-3 and C function > > pointers to use the same representation.> > I don't think the present solution is really valid, and I am skeptical > > that there is a solution.> > One of the requirements has to be dropped.> > Sniffing code bytes and trying to decide if they are code or not as > > appears to currently happen is bogus.> > > > I think the solution is to remove the requirement that a Modula-3 > > function pointer and a C function pointer are the same.> > Except, well, that probably doesn't work -- it means you need two types > > of function pointers.> > > > Darn this is a hard problem.> > > > The runtime codegen required can be exceedingly simple, fast, and small > > IF it were allowed to be on the stack. But that's a killer these days.> > > > I think you have to give up unification of "closures" and "function > > pointers".> > If you take the address of a nested function and call it, you cannot > > access the locals of the enclosing scopes.> > So in affect, you end up with "two types of function pointers".> > Regular stateless ones and "closures" with some captured state.> > > > Thoughts?> > > > I'm kind of stumped. It's a desirable problem to solve, and there is a > > purported solution in place, but the solution that is there is > > completely bogus, despite appearing to work for a long time, and there > > is no solution. That is my understanding. I could be wrong on any number > > of points but I'm pretty sure.> > > > I think you have to separate out function pointers and closures.> > Sniffing what it pointed to is dubous esp. as currently implemented.> > If this is really the way to go, then signature bytes need to be worked > > out for all architectures that are guaranteed to not look like code.> > Or vice versa -- signature bytes worked out that all functions start > > with, which is viable for Modula-3 but not for interop with C.> > Currently -1 is used, of pointer-size.> > That appears to be reasonable for x86:> > > > 0:000> eb . ff ff ff ff> > 0:000> u .> > ntdll32!DbgBreakPoint:> > 7d61002d ff ???> > 7d61002e ff ???> > 7d61002f ff ???> > 7d610030 ffc3 inc ebx> > > > but the instruction encodings or disassembly on other architectures > > would have to be checked.> > > > - Jay> > > > ------------------------------------------------------------------------> > From: jayk123 at hotmail.com> > To: m3devel at elegosoft.com> > Date: Sun, 25 May 2008 00:16:01 +0000> > Subject: [M3devel] function pointers and comparison to nil?> > mis-typed function pointers?> > > > I'm being lazy...> > > > Tony can you explain this stuff?> > > > Comparison of function pointers..> > What are the various representations and rules?> > > > What does it mean to compare nested functions?> > > > What does it mean to compare a function to NIL?> > > > I'll poke around more.> > > > What I am seeing is that comparison of function pointers to NIL is> > surprisingly> > expensive, and probably somewhat buggy. Or at least some of the runtime> > generated "metadata-ish" stuff is produced or typed incorrectly.> > > > In particular, RTLinker.m3:> > > > PROCEDURE AddUnit (b: RT0.Binder) => > VAR m: RT0.ModulePtr;> > BEGIN> > IF (b = NIL) THEN RETURN END; line 119> > m := b(0); line 120> > IF (m = NIL) THEN RETURN END; line 121> > AddUnitI(m); line 122> > END AddUnit;> > > > generates a lot of code, just for the first line:> > (556) set_source_line > > source line 119 > > (557) load > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb > > (558) load_nil > > (559) if_eq > > (560) load > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb > > (561) load_indirect > > load address offset 0x0 src_t 0x5 dst_t 0x5 > > (562) load_integer > > integer n_bytes 0x0 hi 0x0 low 0x1 sign -1 > > (563) if_eq > > (564) set_label > > (565) load_nil > > (566) load > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb > > (567) if_ne > > (568) set_label > > (569) exit_proc > > (570) set_label > > (571) set_source_line > > source line 120 > > > > The details on the load_integer trace might not be completely> > correct. I will test a fix shortly.> > Esp. that n_bytes gets decremented to zero before the trace.> > > > Ok, I see now why some of the bloat -- because the "then return end"> > is on the same line.> > If it were written as:> > if (b = NIL THEN > > return> > end > > It probably wouldn't look so bad. That took me a while to realize.> > > > The following is generated for SPARC64_OPENBSD:> > > > line 119> > .stabn 68,0,119,.LLM61-.LLFBB4> > .LLM61:> > ldx [%fp+2175], %g1> > brz %g1, .LL26> > nop> > ldx [%fp+2175], %g1> > ldx [%g1], %g1 bus error here? yes, probably this one> > cmp %g1, -1> > be %xcc, .LL27> > nop> > .LL26:> > ldx [%fp+2175], %g1> > brz %g1, .LL33> > nop> > .LL27:> > line 120> > .stabn 68,0,120,.LLM62-.LLFBB4> > .LLM62:> > ldx [%fp+2175], %g1> > stx %g1, [%fp+2007]> > ldx [%fp+2007], %g1> > brz %g1, .LL30> > nop> > ldx [%fp+2007], %g1> > ldx [%g1], %g1 or here ?> > cmp %g1, -1> > bne %xcc, .LL30> > nop> > ldx [%fp+2007], %g1> > add %g1, 16, %g1> > ldx [%g1], %g1 or here?> > stx %g1, [%fp+2015]> > ldx [%fp+2007], %g1> > add %g1, 8, %g1> > ldx [%g1], %g1> > stx %g1, [%fp+2007]> > .LL30:> > ldx [%fp+2007], %g1> > ldx [%fp+2015], %g5> > mov 0, %o0> > call %g1, 0> > nop> > mov %o0, %g1> > stx %g1, [%fp+2023]> > ldx [%fp+2023], %g1> > stx %g1, [%fp+1999]> > > > line 121> > > > .stabn 68,0,121,.LLM63-.LLFBB4> > .LLM63:> > ldx [%fp+1999], %g1> > brz %g1, .LL33> > nop> > .LL32:> > .stabn 68,0,122,.LLM64-.LLFBB4> > .LLM64:> > > > g1 points to RTSignal_I3> > > > (gdb) x/i $pc> > 0x3ff0a8 : ldx [ %g1 ], %g1> > (gdb) x/i $g1> > 0x4021f4 : save %sp, -208, %sp> > > > I am willing to accept that a "function pointer" is a pair of> > pointers, or even three pointers.> > A pointer to code, a pointer to globals for position independent> > code, a frame pointer to locals.> > That equality comparison of function pointers requires comparing two> > (or three) pointers.> > (Though the global pointer shouldn't need comparing.)> > At least for nested functions. Less so for non-nested. ?> > Much less for comparison to NIL. ?> > > > And either way, this code is reading bogus data.> > There isn't a pointer at the function address, there is code.> > > > Something doesn't add up.> > > > I'm going to try setting "aligned procedures" but that's quite bogus> > I think.> > > > EqualExpr.m3 says> > > > Note: procedures pointers are always aligned!> > > > but maybe not?> > > > Yeah yeah I'm being lazy. I'll read more code..> > > > I also wonder if a "function pointer" can be optimized for the case> > of not being to a nested function.> > It looks like calling a function pointer is very inefficient.> > It looks like..am I reading that correctly?.. that if the pointer> > points to -1, then it is nested and> > a pair of pointers, and not otherwise. That -1 is treated specially> > as the first bytes of a function?> > Is that a Modula-3-ism or a SPARC-ism?> > It looks like a Modula-3-ism. And it seems dubious.> > But I'll have to read more..> > > > NT386GNU does the same sort of wrong looking thing:> > > > LFBB4:> > pushl %ebp> > movl %esp, %ebp> > subl $24, %esp> > LBB5:> > .stabn 68,0,117,LM60-LFBB4> > LM60:> > movl $0, -16(%ebp)> > .stabn 68,0,119,LM61-LFBB4> > LM61:> > movl 8(%ebp), %eax> > testl %eax, %eax> > je L26> > movl 8(%ebp), %eax> > movl (%eax), %eax BAD> > cmpl $-1, %eax BAD> > je L27> > L26:> > movl 8(%ebp), %eax> > testl %eax, %eax> > je L33> > L27:> > .stabn 68,0,120,LM62-LFBB4> > LM62:> > > > > > and NT386:> > > > 0:000> u> > cm3!RTLinker__AddUnit:> > 00607864 55 push ebp> > 00607865 8bec mov ebp,esp> > 00607867 81ec0c000000 sub esp,0Ch> > 0060786d 53 push ebx> > 0060786e 56 push esi> > 0060786f 57 push edi> > 00607870 c745fc00000000 mov dword ptr [ebp-4],0> > 00607877 837d0800 cmp dword ptr [ebp+8],0> > 0:000> u> > cm3!RTLinker__AddUnit+0x17:> > 0060787b 0f840f000000 je cm3!RTLinker__AddUnit+0x2c (00607890)> > 00607881 8b7508 mov esi,dword ptr [ebp+8]> > 00607884 8b5e00 mov ebx,dword ptr> > [esi] BAD > > 00607887 83fbff cmp > > ebx,0FFFFFFFFh BAD> > 0060788a 0f840f000000 je cm3!RTLinker__AddUnit+0x3b (0060789f)> > 00607890 837d0800 cmp dword ptr [ebp+8],0> > 00607894 0f8505000000 jne cm3!RTLinker__AddUnit+0x3b (0060789f)> > 0060789a e969000000 jmp cm3!RTLinker__AddUnit+0xa4 (00607908)> > > > cm3!RTLinker__AddUnit+0x20:> > 00607884 8b5e00 mov ebx,dword ptr [esi] > > ds:002b:0062c950=81ec8b55> > 0:000> u @esi> > cm3!RTLinker_I3:> > 0062c950 55 push ebp> > 0062c951 8bec mov ebp,esp> > 0062c953 81ec00000000 sub esp,0> > 0062c959 53 push ebx> > 0062c95a 56 push esi> > 0062c95b 57 push edi> > 0062c95c 837d0800 cmp dword ptr [ebp+8],0> > 0062c960 0f8400000000 je cm3!RTLinker_I3+0x16 (0062c966)> > > > This is just wrong.> > Comparing bytes of code to -1.> > > > I think the likely fix is for the "I3" code to be laid out as a> > "constant function pointer", a pointer to a pair of pointers where> > one points to the code and one is to -1. Something like that. That> > can't be quite correct given that the existing data is callable.> > > > - Jay> > -- > -------------------------------------------------------------> Rodney M. Bates, retired assistant professor> Dept. of Computer Science, Wichita State University> Wichita, KS 67260-0083> 316-978-3922> rodney.bates at wichita.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From hosking at cs.purdue.edu  Mon May 26 15:35:17 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 26 May 2008 14:35:17 +0100
Subject: [M3devel] function pointers and comparison to nil? mis-typed
	function pointers?
In-Reply-To: <483A3377.7070801@wichita.edu>
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
Message-ID: <3A6D6696-338C-4DB3-80B0-1F6EE2021E49@cs.purdue.edu>

Great summary Rodney.

Plus, trampolines typically require executable code on the stack which  
is disallowed by some OSs.

On May 26, 2008, at 4:50 AM, Rodney M. Bates wrote:

> I think I can shed some light on this, having spent some time making
> m3gdb handle the various operations on nested procedures.  As for code
> that mixes M3 and C, I believe the following are true:
>
> - Within M3 code only, the closure system works correctly in all  
> cases.
>  This answers one of Jay's worries.
>
> - For values of M3 procedure/C function pointer that are top-level
>  (nonnested) procedures/functions, M3 and C code (generated by gcc,
>  at least) are interchangeable.  This answers another of Jay's  
> worries.
>  This will cover that great majority of cases.
>
> - Standard C has no nested functions.  Gcc adds them as a language
>  extension.  Thus, only in gcc-compiled C code do we need to worry
>  about nested procedures/functions between languages.  (Do any other
>  C compilers exist that also have nested functions?)
>
> - M3 code should be able to call the value of a procedure variable
>  that was originally produced by C code as a pointer to a nested
>  function, and get the environment set up right, so its nonlocal
>  variable references will work, _if_ the nested function's
>  environment has not disappeared.  This partially answers another
>  of Jay's worries.  But:
>
> - M3's normal runtime check that precludes assigning a nonlocal
>  procedure value will not detect a C-code-produced nonlocal value,
>  thus the environment could indeed have disappeared if the programmer
>  was not careful.  However, gcc-extended C's nested functions have
>  no protection against this bug when only C code is involved, so
>  perhaps not detecting it in mixed M3/C is to be expected.
>
> - C code that attempts to call a function pointer value that was
>  originally produced by M3 code as a nested procedure value will
>  almost certainly crash at the time of the call.  This is the only
>  case that presents a significant problem.  M3 code will not be
>  able to give a nested procedure as a callback to a C library.
>
> M3's mechanism:  A value of procedure type is a pointer to either
> 1) the first byte of the procedure's machine code, if it is top  
> level, or
> 2) A closure.
>
> A closure is a block of 3 words.  The first word contains -1.   
> Assuming
> a word of all one bits is not valid machine code on any target machine
> (or at least doesn't occur as the first code of any procedure), this  
> can
> be used at runtime to detect that this is indeed a closure and not  
> code.
> The remaining two words hold the code address and the environment  
> address.
>
> So, an assignment of a procedure value has to check that it is not a  
> closure,
> and raise a runtime error if it is.  A call on a procedure value has  
> to check,
> and if it is a closure, load/copy its environment pointer value into  
> wherever
> the calling convention expects it, then branch to the code address.   
> Passing
> a nested procedure constant as a parameter involves constructing a  
> closure for
> it and passing its address.
>
> gcc-C's mechanism:  A value of type pointer to function is a pointer  
> to either
> 1) the first byte of the function's machine code, if it is top level,
>   (the same as with M3), or
> 2) A trampoline.
>
> A trampoline is a bit of code that loads/copies an environment  
> pointer (hard
> coded into the trampoline) and then branches to the function code.
>
> Trampolines probably have a small constant-time speed advantage for  
> _calls_,
> but would be slower for some of the other operations, and the  
> runtime check
> could be tricky.  Probably it could be fooled into failing when it  
> shouldn't.
> Moreover, trampolines are highly target-machine-dependent.   
> Switching to them
> would create a really big problem for m3gdb, which would have to have
> different code for each target for each of the nested procedure  
> operations.
>
> Jay wrote:
>> I see somewhat.
>> It's stuff around "closure".
>> The comparison of code bytes to -1 comes from If_closure for example.
>> The problem is presumably to come up with a unified representation  
>> of pointers to functions that may or may not be nested, while  
>> avoiding runtime codegen, even just a little bit, and for Modula-3  
>> and C function pointers to use the same representation.
>> I don't think the present solution is really valid, and I am  
>> skeptical that there is a solution.
>> One of the requirements has to be dropped.
>> Sniffing code bytes and trying to decide if they are code or not as  
>> appears to currently happen is bogus.
>> I think the solution is to remove the requirement that a Modula-3  
>> function pointer and a C function pointer are the same.
>> Except, well, that probably doesn't work -- it means you need two  
>> types of function pointers.
>> Darn this is a hard problem.
>> The runtime codegen required can be exceedingly simple, fast, and  
>> small IF it were allowed to be on the stack. But that's a killer  
>> these days.
>> I think you have to give up unification of "closures" and "function  
>> pointers".
>> If you take the address of a nested function and call it, you  
>> cannot access the locals of the enclosing scopes.
>> So in affect, you end up with "two types of function pointers".
>> Regular stateless ones and "closures" with some captured state.
>> Thoughts?
>> I'm kind of stumped. It's a desirable problem to solve, and there  
>> is a purported solution in place, but the solution that is there is  
>> completely bogus, despite appearing to work for a long time, and  
>> there is no solution. That is my understanding. I could be wrong on  
>> any number of points but I'm pretty sure.
>> I think you have to separate out function pointers and closures.
>> Sniffing what it pointed to is dubous esp. as currently implemented.
>> If this is really the way to go, then signature bytes need to be  
>> worked out for all architectures that are guaranteed to not look  
>> like code.
>> Or vice versa -- signature bytes worked out that all functions  
>> start with, which is viable for Modula-3 but not for interop with C.
>> Currently -1 is used, of pointer-size.
>> That appears to be reasonable for x86:
>> 0:000> eb . ff ff ff ff
>> 0:000> u .
>> ntdll32!DbgBreakPoint:
>> 7d61002d ff              ???
>> 7d61002e ff              ???
>> 7d61002f ff              ???
>> 7d610030 ffc3            inc     ebx
>> but the instruction encodings or disassembly on other architectures  
>> would have to be checked.
>>  - Jay
>>     
>> ------------------------------------------------------------------------
>>    From: jayk123 at hotmail.com
>>    To: m3devel at elegosoft.com
>>    Date: Sun, 25 May 2008 00:16:01 +0000
>>    Subject: [M3devel] function pointers and comparison to nil?
>>    mis-typed function pointers?
>>    I'm being lazy...
>>    Tony can you explain this stuff?
>>    Comparison of function pointers..
>>    What are the various representations and rules?
>>    What does it mean to compare nested functions?
>>    What does it mean to compare a function to NIL?
>>    I'll poke around more.
>>    What I am seeing is that comparison of function pointers to NIL is
>>    surprisingly
>>    expensive, and probably somewhat buggy. Or at least some of the  
>> runtime
>>    generated "metadata-ish" stuff is produced or typed incorrectly.
>>    In particular, RTLinker.m3:
>>    PROCEDURE AddUnit (b: RT0.Binder) =
>>      VAR m: RT0.ModulePtr;
>>      BEGIN
>>        IF (b = NIL) THEN RETURN END;   line 119
>>        m := b(0);                      line 120
>>        IF (m = NIL) THEN RETURN END;   line 121
>>        AddUnitI(m);                    line 122
>>      END AddUnit;
>>    generates a lot of code, just for the first line:
>>      (556) set_source_line         source line  119       (557)  
>> load         m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb ->  
>> 0xb       (558) load_nil       (559) if_eq       (560) load          
>> m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb       (561)  
>> load_indirect         load address offset 0x0 src_t 0x5 dst_t  
>> 0x5       (562) load_integer         integer n_bytes 0x0 hi 0x0 low  
>> 0x1 sign -1       (563) if_eq       (564) set_label       (565)  
>> load_nil       (566) load         m3cg_load (M3_DjPxE5_b): offset  
>> 0x0, convert 0xb -> 0xb       (567) if_ne       (568)  
>> set_label       (569) exit_proc       (570) set_label       (571)  
>> set_source_line         source line  120     The details on the  
>> load_integer trace might not be completely
>>    correct. I will test a fix shortly.
>>    Esp. that n_bytes gets decremented to zero before the trace.
>>    Ok, I see now why some of the bloat -- because the "then return  
>> end"
>>    is on the same line.
>>    If it were written as:
>>      if (b = NIL THEN         return
>>      end      It probably wouldn't look so bad. That took me a  
>> while to realize.
>>    The following is generated for SPARC64_OPENBSD:
>>          line 119
>>     .stabn 68,0,119,.LLM61-.LLFBB4
>>    .LLM61:
>>     ldx [%fp+2175], %g1
>>     brz %g1, .LL26
>>      nop
>>     ldx [%fp+2175], %g1
>>     ldx [%g1], %g1            bus error here? yes, probably this one
>>     cmp %g1, -1
>>     be %xcc, .LL27
>>      nop
>>    .LL26:
>>     ldx [%fp+2175], %g1
>>     brz %g1, .LL33
>>      nop
>>    .LL27:
>>     line 120
>>     .stabn 68,0,120,.LLM62-.LLFBB4
>>    .LLM62:
>>     ldx [%fp+2175], %g1
>>     stx %g1, [%fp+2007]
>>     ldx [%fp+2007], %g1
>>     brz %g1, .LL30
>>      nop
>>     ldx [%fp+2007], %g1
>>     ldx [%g1], %g1            or here ?
>>     cmp %g1, -1
>>     bne %xcc, .LL30
>>      nop
>>     ldx [%fp+2007], %g1
>>     add %g1, 16, %g1
>>     ldx [%g1], %g1           or here?
>>     stx %g1, [%fp+2015]
>>     ldx [%fp+2007], %g1
>>     add %g1, 8, %g1
>>     ldx [%g1], %g1
>>     stx %g1, [%fp+2007]
>>    .LL30:
>>     ldx [%fp+2007], %g1
>>     ldx [%fp+2015], %g5
>>     mov 0, %o0
>>     call %g1, 0
>>      nop
>>     mov %o0, %g1
>>     stx %g1, [%fp+2023]
>>     ldx [%fp+2023], %g1
>>     stx %g1, [%fp+1999]
>>          line 121
>>     .stabn 68,0,121,.LLM63-.LLFBB4
>>    .LLM63:
>>     ldx [%fp+1999], %g1
>>     brz %g1, .LL33
>>      nop
>>    .LL32:
>>     .stabn 68,0,122,.LLM64-.LLFBB4
>>    .LLM64:
>>    g1 points to RTSignal_I3
>>    (gdb) x/i $pc
>>    0x3ff0a8 :        ldx  [ %g1 ], %g1
>>    (gdb) x/i $g1
>>    0x4021f4 : save  %sp, -208, %sp
>>    I am willing to accept that a "function pointer" is a pair of
>>    pointers, or even three pointers.
>>    A pointer to code, a pointer to globals for position independent
>>    code, a frame pointer to locals.
>>    That equality comparison of function pointers requires comparing  
>> two
>>    (or three) pointers.
>>      (Though the global pointer shouldn't need comparing.)
>>    At least for nested functions. Less so for non-nested. ?
>>    Much less for comparison to NIL. ?
>>    And either way, this code is reading bogus data.
>>    There isn't a pointer at the function address, there is code.
>>    Something doesn't add up.
>>    I'm going to try setting "aligned procedures" but that's quite  
>> bogus
>>    I think.
>>    EqualExpr.m3 says
>>           Note: procedures pointers are always aligned!
>>    but maybe not?
>>    Yeah yeah I'm being lazy. I'll read more code..
>>    I also wonder if a "function pointer" can be optimized for the  
>> case
>>    of not being to a nested function.
>>    It looks like calling a function pointer is very inefficient.
>>    It looks like..am I reading that correctly?.. that if the pointer
>>    points to -1, then it is nested and
>>    a pair of pointers, and not otherwise. That -1 is treated  
>> specially
>>    as the first bytes of a function?
>>    Is that a Modula-3-ism or a SPARC-ism?
>>    It looks like a Modula-3-ism. And it seems dubious.
>>    But I'll have to read more..
>>         NT386GNU does the same sort of wrong looking thing:
>>         LFBB4:
>>     pushl %ebp
>>     movl %esp, %ebp
>>     subl $24, %esp
>>    LBB5:
>>     .stabn 68,0,117,LM60-LFBB4
>>    LM60:
>>     movl $0, -16(%ebp)
>>     .stabn 68,0,119,LM61-LFBB4
>>    LM61:
>>     movl 8(%ebp), %eax
>>     testl %eax, %eax
>>     je L26
>>     movl 8(%ebp), %eax
>>     movl (%eax), %eax                  BAD
>>     cmpl $-1, %eax                       BAD
>>     je L27
>>    L26:
>>     movl 8(%ebp), %eax
>>     testl %eax, %eax
>>     je L33
>>    L27:
>>     .stabn 68,0,120,LM62-LFBB4
>>    LM62:
>>         and NT386:
>>         0:000> u
>>    cm3!RTLinker__AddUnit:
>>    00607864 55              push    ebp
>>    00607865 8bec            mov     ebp,esp
>>    00607867 81ec0c000000    sub     esp,0Ch
>>    0060786d 53              push    ebx
>>    0060786e 56              push    esi
>>    0060786f 57              push    edi
>>    00607870 c745fc00000000  mov     dword ptr [ebp-4],0
>>    00607877 837d0800        cmp     dword ptr [ebp+8],0
>>    0:000> u
>>    cm3!RTLinker__AddUnit+0x17:
>>    0060787b 0f840f000000    je      cm3!RTLinker__AddUnit+0x2c  
>> (00607890)
>>    00607881 8b7508          mov     esi,dword ptr [ebp+8]
>>    00607884 8b5e00          mov     ebx,dword ptr
>>    [esi]                            BAD     00607887  
>> 83fbff          cmp        ebx, 
>> 0FFFFFFFFh                                  BAD
>>    0060788a 0f840f000000    je      cm3!RTLinker__AddUnit+0x3b  
>> (0060789f)
>>    00607890 837d0800        cmp     dword ptr [ebp+8],0
>>    00607894 0f8505000000    jne     cm3!RTLinker__AddUnit+0x3b  
>> (0060789f)
>>    0060789a e969000000      jmp     cm3!RTLinker__AddUnit+0xa4  
>> (00607908)
>>         cm3!RTLinker__AddUnit+0x20:
>>    00607884 8b5e00          mov     ebx,dword ptr [esi]     ds:002b: 
>> 0062c950=81ec8b55
>>    0:000> u @esi
>>    cm3!RTLinker_I3:
>>    0062c950 55              push    ebp
>>    0062c951 8bec            mov     ebp,esp
>>    0062c953 81ec00000000    sub     esp,0
>>    0062c959 53              push    ebx
>>    0062c95a 56              push    esi
>>    0062c95b 57              push    edi
>>    0062c95c 837d0800        cmp     dword ptr [ebp+8],0
>>    0062c960 0f8400000000    je      cm3!RTLinker_I3+0x16 (0062c966)
>>         This is just wrong.
>>    Comparing bytes of code to -1.
>>         I think the likely fix is for the "I3" code to be laid out  
>> as a
>>    "constant function pointer", a pointer to a pair of pointers where
>>    one points to the code and one is to -1. Something like that. That
>>    can't be quite correct given that the existing data is callable.
>>      - Jay
>
> -- 
> -------------------------------------------------------------
> Rodney M. Bates, retired assistant professor
> Dept. of Computer Science, Wichita State University
> Wichita, KS 67260-0083
> 316-978-3922
> rodney.bates at wichita.edu



From hosking at cs.purdue.edu  Mon May 26 15:38:53 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 26 May 2008 14:38:53 +0100
Subject: [M3devel] function pointers and comparison to nil? mis-typed
	function pointers?
In-Reply-To: 
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
	
	
Message-ID: 

Moving away from the current implementation would be a portability  
disaster because of the fact that gcc requires an executable stack for  
its nested function implementation which is non-portable.

On May 26, 2008, at 11:04 AM, Jay wrote:

> Cygwin gcc clearly generates code on the stack for nested functions.
> And then search the web..that's how it works in general.
> Nested functions have been deprecated on Mac OS X, in anticipation  
> of possibly making the stack not executable.
>
> OpenBSD doesn't allow execution on the stack.
> They use mprotect to let trampolines run:
>   http://gcc.gnu.org/ml/gcc/2004-01/msg00742.html
> and
>   http://resin.csoft.net/cgi-bin/man.cgi?section=1&topic=gcc-local
>
> Even though nested functions are a gcc extension to the C language,  
> email threads out there discuss Ada, Pascal, and even ! Modula-3 as  
> having nested functions, and that therefore deprecating the C  
> language feature doesn't "solve" the "problem".
>
> I remain uncertain what, if anything, to do here.
>  - keep the -1 hack, do nothing
>     generalize it slightly to let targets pick "better" markers
>  - use gcc's supported for nested functions
>    (plus the integrated backend, not difficult)
>
> Clearly this is a dilemna to more than just me. :)
>
>  - Jay
> From: jayk123 at hotmail.com
> To: rodney.bates at wichita.edu; m3devel at elegosoft.com
> Date: Mon, 26 May 2008 05:26:41 +0000
> Subject: Re: [M3devel] function pointers and comparison to nil? mis- 
> typed function pointers?
>
> Rodney, this agrees with much of what I figured out and guessed. I  
> did not think of or look into some of what you point out though:
>   - what gcc's nested functions look like, and if you can take the  
> address, and what that does
>   - calling Modula-3 nested functions as callbacks from C
>
> Now, regarding trampolines.
> I alluded to them. It should be easy enough to generate them, and  
> this would solve a few problems, but I believe also bring up a new  
> big problem.
> Generating trampolines solves at least two problems:
>  - it allows Modula-3 nested function pointers ("closures") to be  
> called from C
>  - it enables removing the check for -1
>
> I contend that the check for -1 is not good. It is a somewhat risky  
> assumption, that "-1" is not valid code.
> You do bring up a nice mitigation -- the assumption that it doesn't  
> begin any functions, which is much narrower than it being valid code  
> anywhere.
>
> For SPARC64_OPENBSD I figured out what the original authors meant to  
> be the fix.
> You declare functions as not aligned, leading to the check for -1  
> first checking alignment (bigger code).
> Any pointer not aligned on an integer-sized address is presumed not  
> a closure and not checked for the -1.
> This lets SPARC64_OPENBSD get further. Both it and PPC32_OPENBSD now  
> for some reason suffer from an inability to heap allocate anything,  
> failing around the attempt to create a new thread like in  
> RTAllocator_M or so. I'll look into this more later.
>
> Now, the problem of trampolines..I consider the platform-dependent- 
> ness to be surmountable.
> But where do you put the generated code? Putting it on the stack is  
> counter to modern (and possibly old) "security" mechanisms.
> The stack is not generally executable, and even when it is, best  
> just not do use that imho.
>
> That means, potentially/obviously, the need to heap allocate  
> executable memory, for very small short lived data, quite inefficient.
>
> Is there some other way/place to produce trampolines, efficiently?
>
> In the absence of any good solution, I have to resign myself to  
> assuming that -1 isn't the valid start of a function, and perhaps  
> moving the marker into Target.i3, Target.m3 so that "more obvious"  
> values get chosen. Like a breakpoint. Or "an epilogue", or "a trap  
> instruction". I realize this needs details and is easily seen as  
> "wrong". In particular, a function that does nothing could be termed  
> as only having an "an epilogue".
>
> I know that other systems are "forced" to create "trampolines" so I  
> should look into how they do that.
> I know that ATL, a Windows-specific library, is forced to heap  
> allocate small executable chunks of memory and uses an efficient  
> cache to optimize it.
>
> I do find this dependence on -1 not being the valid start of a  
> function rather sleazy and at risk of being wrong.
>
>  - Jay
>
>
>
>
> > Date: Sun, 25 May 2008 22:50:15 -0500
> > From: rodney.bates at wichita.edu
> > To: m3devel at elegosoft.com
> > Subject: Re: [M3devel] function pointers and comparison to nil?  
> mis-typed function pointers?
> >
> > I think I can shed some light on this, having spent some time making
> > m3gdb handle the various operations on nested procedures. As for  
> code
> > that mixes M3 and C, I believe the following are true:
> >
> > - Within M3 code only, the closure system works correctly in all  
> cases.
> > This answers one of Jay's worries.
> >
> > - For values of M3 procedure/C function pointer that are top-level
> > (nonnested) procedures/functions, M3 and C code (generated by gcc,
> > at least) are interchangeable. This answers another of Jay's  
> worries.
> > This will cover that great majority of cases.
> >
> > - Standard C has no nested functions. Gcc adds them as a language
> > extension. Thus, only in gcc-compiled C code do we need to worry
> > about nested procedures/functions between languages. (Do any other
> > C compilers exist that also have nested functions?)
> >
> > - M3 code should be able to call the value of a procedure variable
> > that was originally produced by C code as a pointer to a nested
> > function, and get the environment set up right, so its nonlocal
> > variable references will work, _if_ the nested function's
> > environment has not disappeared. This partially answers another
> > of Jay's worries. But:
> >
> > - M3's normal runtime check that precludes assigning a nonlocal
> > procedure value will not detect a C-code-produced nonlocal value,
> > thus the environment could indeed have disappeared if the programmer
> > was not careful. However, gcc-extended C's nested functions have
> > no protection against this bug when only C code is involved, so
> > perhaps not detecting it in mixed M3/C is to be expected.
> >
> > - C code that attempts to call a function pointer value that was
> > originally produced by M3 code as a nested procedure value will
> > almost certainly crash at the time of the call. This is the only
> > case that presents a significant problem. M3 code will not be
> > able to give a nested procedure as a callback to a C library.
> >
> > M3's mechanism: A value of procedure type is a pointer to either
> > 1) the first byte of the procedure's machine code, if it is top  
> level, or
> > 2) A closure.
> >
> > A closure is a block of 3 words. The first word contains -1.  
> Assuming
> > a word of all one bits is not valid machine code on any target  
> machine
> > (or at least doesn't occur as the first code of any procedure),  
> this can
> > be used at runtime to detect that this is indeed a closure and not  
> code.
> > The remaining two words hold the code address and the environment  
> address.
> >
> > So, an assignment of a procedure value has to check that it is not  
> a closure,
> > and raise a runtime error if it is. A call on a procedure value  
> has to check,
> > and if it is a closure, load/copy its environment pointer value  
> into wherever
> > the calling convention expects it, then branch to the code  
> address. Passing
> > a nested procedure constant as a parameter involves constructing a  
> closure for
> > it and passing its address.
> >
> > gcc-C's mechanism: A value of type pointer to function is a  
> pointer to either
> > 1) the first byte of the function's machine code, if it is top  
> level,
> > (the same as with M3), or
> > 2) A trampoline.
> >
> > A trampoline is a bit of code that loads/copies an environment  
> pointer (hard
> > coded into the trampoline) and then branches to the function code.
> >
> > Trampolines probably have a small constant-time speed advantage  
> for _calls_,
> > but would be slower for some of the other operations, and the  
> runtime check
> > could be tricky. Probably it could be fooled into failing when it  
> shouldn't.
> > Moreover, trampolines are highly target-machine-dependent.  
> Switching to them
> > would create a really big problem for m3gdb, which would have to  
> have
> > different code for each target for each of the nested procedure  
> operations.
> >
> > Jay wrote:
> > > I see somewhat.
> > > It's stuff around "closure".
> > > The comparison of code bytes to -1 comes from If_closure for  
> example.
> > >
> > > The problem is presumably to come up with a unified  
> representation of
> > > pointers to functions that may or may not be nested, while  
> avoiding
> > > runtime codegen, even just a little bit, and for Modula-3 and C  
> function
> > > pointers to use the same representation.
> > > I don't think the present solution is really valid, and I am  
> skeptical
> > > that there is a solution.
> > > One of the requirements has to be dropped.
> > > Sniffing code bytes and trying to decide if they are code or not  
> as
> > > appears to currently happen is bogus.
> > >
> > > I think the solution is to remove the requirement that a Modula-3
> > > function pointer and a C function pointer are the same.
> > > Except, well, that probably doesn't work -- it means you need  
> two types
> > > of function pointers.
> > >
> > > Darn this is a hard problem.
> > >
> > > The runtime codegen required can be exceedingly simple, fast,  
> and small
> > > IF it were allowed to be on the stack. But that's a killer these  
> days.
> > >
> > > I think you have to give up unification of "closures" and  
> "function
> > > pointers".
> > > If you take the address of a nested function and call it, you  
> cannot
> > > access the locals of the enclosing scopes.
> > > So in affect, you end up with "two types of function pointers".
> > > Regular stateless ones and "closures" with some captured state.
> > >
> > > Thoughts?
> > >
> > > I'm kind of stumped. It's a desirable problem to solve, and  
> there is a
> > > purported solution in place, but the solution that is there is
> > > completely bogus, despite appearing to work for a long time, and  
> there
> > > is no solution. That is my understanding. I could be wrong on  
> any number
> > > of points but I'm pretty sure.
> > >
> > > I think you have to separate out function pointers and closures.
> > > Sniffing what it pointed to is dubous esp. as currently  
> implemented.
> > > If this is really the way to go, then signature bytes need to be  
> worked
> > > out for all architectures that are guaranteed to not look like  
> code.
> > > Or vice versa -- signature bytes worked out that all functions  
> start
> > > with, which is viable for Modula-3 but not for interop with C.
> > > Currently -1 is used, of pointer-size.
> > > That appears to be reasonable for x86:
> > >
> > > 0:000> eb . ff ff ff ff
> > > 0:000> u .
> > > ntdll32!DbgBreakPoint:
> > > 7d61002d ff ???
> > > 7d61002e ff ???
> > > 7d61002f ff ???
> > > 7d610030 ffc3 inc ebx
> > >
> > > but the instruction encodings or disassembly on other  
> architectures
> > > would have to be checked.
> > >
> > > - Jay
> > >
> > >  
> ------------------------------------------------------------------------
> > > From: jayk123 at hotmail.com
> > > To: m3devel at elegosoft.com
> > > Date: Sun, 25 May 2008 00:16:01 +0000
> > > Subject: [M3devel] function pointers and comparison to nil?
> > > mis-typed function pointers?
> > >
> > > I'm being lazy...
> > >
> > > Tony can you explain this stuff?
> > >
> > > Comparison of function pointers..
> > > What are the various representations and rules?
> > >
> > > What does it mean to compare nested functions?
> > >
> > > What does it mean to compare a function to NIL?
> > >
> > > I'll poke around more.
> > >
> > > What I am seeing is that comparison of function pointers to NIL is
> > > surprisingly
> > > expensive, and probably somewhat buggy. Or at least some of the  
> runtime
> > > generated "metadata-ish" stuff is produced or typed incorrectly.
> > >
> > > In particular, RTLinker.m3:
> > >
> > > PROCEDURE AddUnit (b: RT0.Binder) =
> > > VAR m: RT0.ModulePtr;
> > > BEGIN
> > > IF (b = NIL) THEN RETURN END; line 119
> > > m := b(0); line 120
> > > IF (m = NIL) THEN RETURN END; line 121
> > > AddUnitI(m); line 122
> > > END AddUnit;
> > >
> > > generates a lot of code, just for the first line:
> > > (556) set_source_line
> > > source line 119
> > > (557) load
> > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb
> > > (558) load_nil
> > > (559) if_eq
> > > (560) load
> > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb
> > > (561) load_indirect
> > > load address offset 0x0 src_t 0x5 dst_t 0x5
> > > (562) load_integer
> > > integer n_bytes 0x0 hi 0x0 low 0x1 sign -1
> > > (563) if_eq
> > > (564) set_label
> > > (565) load_nil
> > > (566) load
> > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb
> > > (567) if_ne
> > > (568) set_label
> > > (569) exit_proc
> > > (570) set_label
> > > (571) set_source_line
> > > source line 120
> > >
> > > The details on the load_integer trace might not be completely
> > > correct. I will test a fix shortly.
> > > Esp. that n_bytes gets decremented to zero before the trace.
> > >
> > > Ok, I see now why some of the bloat -- because the "then return  
> end"
> > > is on the same line.
> > > If it were written as:
> > > if (b = NIL THEN
> > > return
> > > end
> > > It probably wouldn't look so bad. That took me a while to realize.
> > >
> > > The following is generated for SPARC64_OPENBSD:
> > >
> > > line 119
> > > .stabn 68,0,119,.LLM61-.LLFBB4
> > > .LLM61:
> > > ldx [%fp+2175], %g1
> > > brz %g1, .LL26
> > > nop
> > > ldx [%fp+2175], %g1
> > > ldx [%g1], %g1 bus error here? yes, probably this one
> > > cmp %g1, -1
> > > be %xcc, .LL27
> > > nop
> > > .LL26:
> > > ldx [%fp+2175], %g1
> > > brz %g1, .LL33
> > > nop
> > > .LL27:
> > > line 120
> > > .stabn 68,0,120,.LLM62-.LLFBB4
> > > .LLM62:
> > > ldx [%fp+2175], %g1
> > > stx %g1, [%fp+2007]
> > > ldx [%fp+2007], %g1
> > > brz %g1, .LL30
> > > nop
> > > ldx [%fp+2007], %g1
> > > ldx [%g1], %g1 or here ?
> > > cmp %g1, -1
> > > bne %xcc, .LL30
> > > nop
> > > ldx [%fp+2007], %g1
> > > add %g1, 16, %g1
> > > ldx [%g1], %g1 or here?
> > > stx %g1, [%fp+2015]
> > > ldx [%fp+2007], %g1
> > > add %g1, 8, %g1
> > > ldx [%g1], %g1
> > > stx %g1, [%fp+2007]
> > > .LL30:
> > > ldx [%fp+2007], %g1
> > > ldx [%fp+2015], %g5
> > > mov 0, %o0
> > > call %g1, 0
> > > nop
> > > mov %o0, %g1
> > > stx %g1, [%fp+2023]
> > > ldx [%fp+2023], %g1
> > > stx %g1, [%fp+1999]
> > >
> > > line 121
> > >
> > > .stabn 68,0,121,.LLM63-.LLFBB4
> > > .LLM63:
> > > ldx [%fp+1999], %g1
> > > brz %g1, .LL33
> > > nop
> > > .LL32:
> > > .stabn 68,0,122,.LLM64-.LLFBB4
> > > .LLM64:
> > >
> > > g1 points to RTSignal_I3
> > >
> > > (gdb) x/i $pc
> > > 0x3ff0a8 : ldx [ %g1 ], %g1
> > > (gdb) x/i $g1
> > > 0x4021f4 : save %sp, -208, %sp
> > >
> > > I am willing to accept that a "function pointer" is a pair of
> > > pointers, or even three pointers.
> > > A pointer to code, a pointer to globals for position independent
> > > code, a frame pointer to locals.
> > > That equality comparison of function pointers requires comparing  
> two
> > > (or three) pointers.
> > > (Though the global pointer shouldn't need comparing.)
> > > At least for nested functions. Less so for non-nested. ?
> > > Much less for comparison to NIL. ?
> > >
> > > And either way, this code is reading bogus data.
> > > There isn't a pointer at the function address, there is code.
> > >
> > > Something doesn't add up.
> > >
> > > I'm going to try setting "aligned procedures" but that's quite  
> bogus
> > > I think.
> > >
> > > EqualExpr.m3 says
> > >
> > > Note: procedures pointers are always aligned!
> > >
> > > but maybe not?
> > >
> > > Yeah yeah I'm being lazy. I'll read more code..
> > >
> > > I also wonder if a "function pointer" can be optimized for the  
> case
> > > of not being to a nested function.
> > > It looks like calling a function pointer is very inefficient.
> > > It looks like..am I reading that correctly?.. that if the pointer
> > > points to -1, then it is nested and
> > > a pair of pointers, and not otherwise. That -1 is treated  
> specially
> > > as the first bytes of a function?
> > > Is that a Modula-3-ism or a SPARC-ism?
> > > It looks like a Modula-3-ism. And it seems dubious.
> > > But I'll have to read more..
> > >
> > > NT386GNU does the same sort of wrong looking thing:
> > >
> > > LFBB4:
> > > pushl %ebp
> > > movl %esp, %ebp
> > > subl $24, %esp
> > > LBB5:
> > > .stabn 68,0,117,LM60-LFBB4
> > > LM60:
> > > movl $0, -16(%ebp)
> > > .stabn 68,0,119,LM61-LFBB4
> > > LM61:
> > > movl 8(%ebp), %eax
> > > testl %eax, %eax
> > > je L26
> > > movl 8(%ebp), %eax
> > > movl (%eax), %eax BAD
> > > cmpl $-1, %eax BAD
> > > je L27
> > > L26:
> > > movl 8(%ebp), %eax
> > > testl %eax, %eax
> > > je L33
> > > L27:
> > > .stabn 68,0,120,LM62-LFBB4
> > > LM62:
> > >
> > >
> > > and NT386:
> > >
> > > 0:000> u
> > > cm3!RTLinker__AddUnit:
> > > 00607864 55 push ebp
> > > 00607865 8bec mov ebp,esp
> > > 00607867 81ec0c000000 sub esp,0Ch
> > > 0060786d 53 push ebx
> > > 0060786e 56 push esi
> > > 0060786f 57 push edi
> > > 00607870 c745fc00000000 mov dword ptr [ebp-4],0
> > > 00607877 837d0800 cmp dword ptr [ebp+8],0
> > > 0:000> u
> > > cm3!RTLinker__AddUnit+0x17:
> > > 0060787b 0f840f000000 je cm3!RTLinker__AddUnit+0x2c (00607890)
> > > 00607881 8b7508 mov esi,dword ptr [ebp+8]
> > > 00607884 8b5e00 mov ebx,dword ptr
> > > [esi] BAD
> > > 00607887 83fbff cmp
> > > ebx,0FFFFFFFFh BAD
> > > 0060788a 0f840f000000 je cm3!RTLinker__AddUnit+0x3b (0060789f)
> > > 00607890 837d0800 cmp dword ptr [ebp+8],0
> > > 00607894 0f8505000000 jne cm3!RTLinker__AddUnit+0x3b (0060789f)
> > > 0060789a e969000000 jmp cm3!RTLinker__AddUnit+0xa4 (00607908)
> > >
> > > cm3!RTLinker__AddUnit+0x20:
> > > 00607884 8b5e00 mov ebx,dword ptr [esi]
> > > ds:002b:0062c950=81ec8b55
> > > 0:000> u @esi
> > > cm3!RTLinker_I3:
> > > 0062c950 55 push ebp
> > > 0062c951 8bec mov ebp,esp
> > > 0062c953 81ec00000000 sub esp,0
> > > 0062c959 53 push ebx
> > > 0062c95a 56 push esi
> > > 0062c95b 57 push edi
> > > 0062c95c 837d0800 cmp dword ptr [ebp+8],0
> > > 0062c960 0f8400000000 je cm3!RTLinker_I3+0x16 (0062c966)
> > >
> > > This is just wrong.
> > > Comparing bytes of code to -1.
> > >
> > > I think the likely fix is for the "I3" code to be laid out as a
> > > "constant function pointer", a pointer to a pair of pointers where
> > > one points to the code and one is to -1. Something like that. That
> > > can't be quite correct given that the existing data is callable.
> > >
> > > - Jay
> >
> > --
> > -------------------------------------------------------------
> > Rodney M. Bates, retired assistant professor
> > Dept. of Computer Science, Wichita State University
> > Wichita, KS 67260-0083
> > 316-978-3922
> > rodney.bates at wichita.edu
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Mon May 26 15:54:18 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Mon, 26 May 2008 09:54:18 -0400
Subject: [M3devel] function pointers and comparison to nil?	mis-typed
	function pointers?
In-Reply-To: <483A3377.7070801@wichita.edu>
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
Message-ID: <483A88C5.1E75.00D7.1@scires.com>

I'm just "listening" here, but it would seem that much of what Rodney has stated would make for an excellent set of comments to be added to the code source file so that folks reading the code will better understand the reasoning behind what is going on.
--Randy

>>> "Rodney M. Bates"  5/25/2008 11:50 PM >>>
I think I can shed some light on this, having spent some time making
m3gdb handle the various operations on nested procedures.  As for code
that mixes M3 and C, I believe the following are true:

- Within M3 code only, the closure system works correctly in all cases.
   This answers one of Jay's worries.

- For values of M3 procedure/C function pointer that are top-level
   (nonnested) procedures/functions, M3 and C code (generated by gcc,
   at least) are interchangeable.  This answers another of Jay's worries.
   This will cover that great majority of cases.

- Standard C has no nested functions.  Gcc adds them as a language
   extension.  Thus, only in gcc-compiled C code do we need to worry
   about nested procedures/functions between languages.  (Do any other
   C compilers exist that also have nested functions?)

- M3 code should be able to call the value of a procedure variable
   that was originally produced by C code as a pointer to a nested
   function, and get the environment set up right, so its nonlocal
   variable references will work, _if_ the nested function's
   environment has not disappeared.  This partially answers another
   of Jay's worries.  But:

- M3's normal runtime check that precludes assigning a nonlocal
   procedure value will not detect a C-code-produced nonlocal value,
   thus the environment could indeed have disappeared if the programmer
   was not careful.  However, gcc-extended C's nested functions have
   no protection against this bug when only C code is involved, so
   perhaps not detecting it in mixed M3/C is to be expected.

- C code that attempts to call a function pointer value that was
   originally produced by M3 code as a nested procedure value will
   almost certainly crash at the time of the call.  This is the only
   case that presents a significant problem.  M3 code will not be
   able to give a nested procedure as a callback to a C library.

M3's mechanism:  A value of procedure type is a pointer to either
1) the first byte of the procedure's machine code, if it is top level, or
2) A closure.

A closure is a block of 3 words.  The first word contains -1.  Assuming
a word of all one bits is not valid machine code on any target machine
(or at least doesn't occur as the first code of any procedure), this can
be used at runtime to detect that this is indeed a closure and not code.
The remaining two words hold the code address and the environment address.

So, an assignment of a procedure value has to check that it is not a closure,
and raise a runtime error if it is.  A call on a procedure value has to check,
and if it is a closure, load/copy its environment pointer value into wherever
the calling convention expects it, then branch to the code address.  Passing
a nested procedure constant as a parameter involves constructing a closure for
it and passing its address.

gcc-C's mechanism:  A value of type pointer to function is a pointer to either
1) the first byte of the function's machine code, if it is top level,
    (the same as with M3), or
2) A trampoline.

A trampoline is a bit of code that loads/copies an environment pointer (hard
coded into the trampoline) and then branches to the function code.

Trampolines probably have a small constant-time speed advantage for _calls_,
but would be slower for some of the other operations, and the runtime check
could be tricky.  Probably it could be fooled into failing when it shouldn't.
Moreover, trampolines are highly target-machine-dependent.  Switching to them
would create a really big problem for m3gdb, which would have to have
different code for each target for each of the nested procedure operations.

Jay wrote:
> I see somewhat.
> It's stuff around "closure".
> The comparison of code bytes to -1 comes from If_closure for example.
>  
> The problem is presumably to come up with a unified representation of 
> pointers to functions that may or may not be nested, while avoiding 
> runtime codegen, even just a little bit, and for Modula-3 and C function 
> pointers to use the same representation.
> I don't think the present solution is really valid, and I am skeptical 
> that there is a solution.
> One of the requirements has to be dropped.
> Sniffing code bytes and trying to decide if they are code or not as 
> appears to currently happen is bogus.
>  
> I think the solution is to remove the requirement that a Modula-3 
> function pointer and a C function pointer are the same.
> Except, well, that probably doesn't work -- it means you need two types 
> of function pointers.
>  
> Darn this is a hard problem.
>  
> The runtime codegen required can be exceedingly simple, fast, and small 
> IF it were allowed to be on the stack. But that's a killer these days.
>  
> I think you have to give up unification of "closures" and "function 
> pointers".
> If you take the address of a nested function and call it, you cannot 
> access the locals of the enclosing scopes.
> So in affect, you end up with "two types of function pointers".
> Regular stateless ones and "closures" with some captured state.
>  
> Thoughts?
>  
> I'm kind of stumped. It's a desirable problem to solve, and there is a 
> purported solution in place, but the solution that is there is 
> completely bogus, despite appearing to work for a long time, and there 
> is no solution. That is my understanding. I could be wrong on any number 
> of points but I'm pretty sure.
>  
> I think you have to separate out function pointers and closures.
> Sniffing what it pointed to is dubous esp. as currently implemented.
> If this is really the way to go, then signature bytes need to be worked 
> out for all architectures that are guaranteed to not look like code.
> Or vice versa -- signature bytes worked out that all functions start 
> with, which is viable for Modula-3 but not for interop with C.
> Currently -1 is used, of pointer-size.
> That appears to be reasonable for x86:
>  
> 0:000> eb . ff ff ff ff
> 0:000> u .
> ntdll32!DbgBreakPoint:
> 7d61002d ff              ???
> 7d61002e ff              ???
> 7d61002f ff              ???
> 7d610030 ffc3            inc     ebx
>  
> but the instruction encodings or disassembly on other architectures 
> would have to be checked.
>  
>  - Jay
> 
>     ------------------------------------------------------------------------
>     From: jayk123 at hotmail.com 
>     To: m3devel at elegosoft.com 
>     Date: Sun, 25 May 2008 00:16:01 +0000
>     Subject: [M3devel] function pointers and comparison to nil?
>     mis-typed function pointers?
> 
>     I'm being lazy...
> 
>     Tony can you explain this stuff?
> 
>     Comparison of function pointers..
>     What are the various representations and rules?
> 
>     What does it mean to compare nested functions?
> 
>     What does it mean to compare a function to NIL?
> 
>     I'll poke around more.
> 
>     What I am seeing is that comparison of function pointers to NIL is
>     surprisingly
>     expensive, and probably somewhat buggy. Or at least some of the runtime
>     generated "metadata-ish" stuff is produced or typed incorrectly.
> 
>     In particular, RTLinker.m3:
> 
>     PROCEDURE AddUnit (b: RT0.Binder) =
>       VAR m: RT0.ModulePtr;
>       BEGIN
>         IF (b = NIL) THEN RETURN END;   line 119
>         m := b(0);                      line 120
>         IF (m = NIL) THEN RETURN END;   line 121
>         AddUnitI(m);                    line 122
>       END AddUnit;
> 
>     generates a lot of code, just for the first line:
>       (556) set_source_line 
>         source line  119 
>       (557) load 
>         m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb 
>       (558) load_nil 
>       (559) if_eq 
>       (560) load 
>         m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb 
>       (561) load_indirect 
>         load address offset 0x0 src_t 0x5 dst_t 0x5 
>       (562) load_integer 
>         integer n_bytes 0x0 hi 0x0 low 0x1 sign -1 
>       (563) if_eq 
>       (564) set_label 
>       (565) load_nil 
>       (566) load 
>         m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb 
>       (567) if_ne 
>       (568) set_label 
>       (569) exit_proc 
>       (570) set_label 
>       (571) set_source_line 
>         source line  120 
> 
>     The details on the load_integer trace might not be completely
>     correct. I will test a fix shortly.
>     Esp. that n_bytes gets decremented to zero before the trace.
> 
>     Ok, I see now why some of the bloat -- because the "then return end"
>     is on the same line.
>     If it were written as:
>       if (b = NIL THEN 
>         return
>       end  
>     It probably wouldn't look so bad. That took me a while to realize.
> 
>     The following is generated for SPARC64_OPENBSD:
>      
>      line 119
>      .stabn 68,0,119,.LLM61-.LLFBB4
>     .LLM61:
>      ldx [%fp+2175], %g1
>      brz %g1, .LL26
>       nop
>      ldx [%fp+2175], %g1
>      ldx [%g1], %g1            bus error here? yes, probably this one
>      cmp %g1, -1
>      be %xcc, .LL27
>       nop
>     .LL26:
>      ldx [%fp+2175], %g1
>      brz %g1, .LL33
>       nop
>     .LL27:
>      line 120
>      .stabn 68,0,120,.LLM62-.LLFBB4
>     .LLM62:
>      ldx [%fp+2175], %g1
>      stx %g1, [%fp+2007]
>      ldx [%fp+2007], %g1
>      brz %g1, .LL30
>       nop
>      ldx [%fp+2007], %g1
>      ldx [%g1], %g1            or here ?
>      cmp %g1, -1
>      bne %xcc, .LL30
>       nop
>      ldx [%fp+2007], %g1
>      add %g1, 16, %g1
>      ldx [%g1], %g1           or here?
>      stx %g1, [%fp+2015]
>      ldx [%fp+2007], %g1
>      add %g1, 8, %g1
>      ldx [%g1], %g1
>      stx %g1, [%fp+2007]
>     .LL30:
>      ldx [%fp+2007], %g1
>      ldx [%fp+2015], %g5
>      mov 0, %o0
>      call %g1, 0
>       nop
>      mov %o0, %g1
>      stx %g1, [%fp+2023]
>      ldx [%fp+2023], %g1
>      stx %g1, [%fp+1999]
>      
>      line 121
> 
>      .stabn 68,0,121,.LLM63-.LLFBB4
>     .LLM63:
>      ldx [%fp+1999], %g1
>      brz %g1, .LL33
>       nop
>     .LL32:
>      .stabn 68,0,122,.LLM64-.LLFBB4
>     .LLM64:
> 
>     g1 points to RTSignal_I3
> 
>     (gdb) x/i $pc
>     0x3ff0a8 :        ldx  [ %g1 ], %g1
>     (gdb) x/i $g1
>     0x4021f4 : save  %sp, -208, %sp
> 
>     I am willing to accept that a "function pointer" is a pair of
>     pointers, or even three pointers.
>     A pointer to code, a pointer to globals for position independent
>     code, a frame pointer to locals.
>     That equality comparison of function pointers requires comparing two
>     (or three) pointers.
>       (Though the global pointer shouldn't need comparing.)
>     At least for nested functions. Less so for non-nested. ?
>     Much less for comparison to NIL. ?
> 
>     And either way, this code is reading bogus data.
>     There isn't a pointer at the function address, there is code.
> 
>     Something doesn't add up.
> 
>     I'm going to try setting "aligned procedures" but that's quite bogus
>     I think.
> 
>     EqualExpr.m3 says
> 
>            Note: procedures pointers are always aligned!
> 
>     but maybe not?
> 
>     Yeah yeah I'm being lazy. I'll read more code..
> 
>     I also wonder if a "function pointer" can be optimized for the case
>     of not being to a nested function.
>     It looks like calling a function pointer is very inefficient.
>     It looks like..am I reading that correctly?.. that if the pointer
>     points to -1, then it is nested and
>     a pair of pointers, and not otherwise. That -1 is treated specially
>     as the first bytes of a function?
>     Is that a Modula-3-ism or a SPARC-ism?
>     It looks like a Modula-3-ism. And it seems dubious.
>     But I'll have to read more..
>      
>     NT386GNU does the same sort of wrong looking thing:
>      
>     LFBB4:
>      pushl %ebp
>      movl %esp, %ebp
>      subl $24, %esp
>     LBB5:
>      .stabn 68,0,117,LM60-LFBB4
>     LM60:
>      movl $0, -16(%ebp)
>      .stabn 68,0,119,LM61-LFBB4
>     LM61:
>      movl 8(%ebp), %eax
>      testl %eax, %eax
>      je L26
>      movl 8(%ebp), %eax
>      movl (%eax), %eax                  BAD
>      cmpl $-1, %eax                       BAD
>      je L27
>     L26:
>      movl 8(%ebp), %eax
>      testl %eax, %eax
>      je L33
>     L27:
>      .stabn 68,0,120,LM62-LFBB4
>     LM62:
> 
>      
>     and NT386:
>      
>     0:000> u
>     cm3!RTLinker__AddUnit:
>     00607864 55              push    ebp
>     00607865 8bec            mov     ebp,esp
>     00607867 81ec0c000000    sub     esp,0Ch
>     0060786d 53              push    ebx
>     0060786e 56              push    esi
>     0060786f 57              push    edi
>     00607870 c745fc00000000  mov     dword ptr [ebp-4],0
>     00607877 837d0800        cmp     dword ptr [ebp+8],0
>     0:000> u
>     cm3!RTLinker__AddUnit+0x17:
>     0060787b 0f840f000000    je      cm3!RTLinker__AddUnit+0x2c (00607890)
>     00607881 8b7508          mov     esi,dword ptr [ebp+8]
>     00607884 8b5e00          mov     ebx,dword ptr
>     [esi]                            BAD 
>     00607887 83fbff          cmp    
>     ebx,0FFFFFFFFh                                  BAD
>     0060788a 0f840f000000    je      cm3!RTLinker__AddUnit+0x3b (0060789f)
>     00607890 837d0800        cmp     dword ptr [ebp+8],0
>     00607894 0f8505000000    jne     cm3!RTLinker__AddUnit+0x3b (0060789f)
>     0060789a e969000000      jmp     cm3!RTLinker__AddUnit+0xa4 (00607908)
>      
>     cm3!RTLinker__AddUnit+0x20:
>     00607884 8b5e00          mov     ebx,dword ptr [esi] 
>     ds:002b:0062c950=81ec8b55
>     0:000> u @esi
>     cm3!RTLinker_I3:
>     0062c950 55              push    ebp
>     0062c951 8bec            mov     ebp,esp
>     0062c953 81ec00000000    sub     esp,0
>     0062c959 53              push    ebx
>     0062c95a 56              push    esi
>     0062c95b 57              push    edi
>     0062c95c 837d0800        cmp     dword ptr [ebp+8],0
>     0062c960 0f8400000000    je      cm3!RTLinker_I3+0x16 (0062c966)
>      
>     This is just wrong.
>     Comparing bytes of code to -1.
>      
>     I think the likely fix is for the "I3" code to be laid out as a
>     "constant function pointer", a pointer to a pair of pointers where
>     one points to the code and one is to -1. Something like that. That
>     can't be quite correct given that the existing data is callable.
> 
>       - Jay

-- 
-------------------------------------------------------------
Rodney M. Bates, retired assistant professor
Dept. of Computer Science, Wichita State University
Wichita, KS 67260-0083
316-978-3922
rodney.bates at wichita.edu 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Mon May 26 21:45:37 2008
From: jayk123 at hotmail.com (Jay)
Date: Mon, 26 May 2008 19:45:37 +0000
Subject: [M3devel] function pointers and comparison to nil? mis-typed
 function pointers?
In-Reply-To: 
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
	
	
	
Message-ID: 

It stinks either way imho.
The portability is handled, somehow or another, by gcc's support for nested functions.
For example on OpenBSD, they call mprotect to make the trampoline executable -- expensive! and leaves a bit of a security hole.
On Linux you can sometimes mark the .exe as needing an executable stack or not. Similarly on Windows, linker has /nxcompat, /nxcompat:no switch.
ATL on Windows puts trampolines in the heap and specifically makes them executable -- since the heap isn't necessarily executable either.
The -1 marker is also a bit of a portability problem but I guess in practise it works out.
I'd be curious to see how it decodes on various processors.
 
 - Jay


CC: rodney.bates at wichita.edu; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?Date: Mon, 26 May 2008 14:38:53 +0100

Moving away from the current implementation would be a portability disaster because of the fact that gcc requires an executable stack for its nested function implementation which is non-portable.

On May 26, 2008, at 11:04 AM, Jay wrote:

Cygwin gcc clearly generates code on the stack for nested functions.And then search the web..that's how it works in general.Nested functions have been deprecated on Mac OS X, in anticipation of possibly making the stack not executable. OpenBSD doesn't allow execution on the stack.They use mprotect to let trampolines run:  http://gcc.gnu.org/ml/gcc/2004-01/msg00742.html and  http://resin.csoft.net/cgi-bin/man.cgi?section=1&topic=gcc-local  Even though nested functions are a gcc extension to the C language, email threads out there discuss Ada, Pascal, and even ! Modula-3 as having nested functions, and that therefore deprecating the C language feature doesn't "solve" the "problem". I remain uncertain what, if anything, to do here. - keep the -1 hack, do nothing     generalize it slightly to let targets pick "better" markers  - use gcc's supported for nested functions    (plus the integrated backend, not difficult)  Clearly this is a dilemna to more than just me. :)  - Jay


From: jayk123 at hotmail.comTo: rodney.bates at wichita.edu; m3devel at elegosoft.comDate: Mon, 26 May 2008 05:26:41 +0000Subject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?Rodney, this agrees with much of what I figured out and guessed. I did not think of or look into some of what you point out though:  - what gcc's nested functions look like, and if you can take the address, and what that does   - calling Modula-3 nested functions as callbacks from C  Now, regarding trampolines.I alluded to them. It should be easy enough to generate them, and this would solve a few problems, but I believe also bring up a new big problem.Generating trampolines solves at least two problems:  - it allows Modula-3 nested function pointers ("closures") to be called from C  - it enables removing the check for -1  I contend that the check for -1 is not good. It is a somewhat risky assumption, that "-1" is not valid code.You do bring up a nice mitigation -- the assumption that it doesn't begin any functions, which is much narrower than it being valid code anywhere. For SPARC64_OPENBSD I figured out what the original authors meant to be the fix.You declare functions as not aligned, leading to the check for -1 first checking alignment (bigger code).Any pointer not aligned on an integer-sized address is presumed not a closure and not checked for the -1.This lets SPARC64_OPENBSD get further. Both it and PPC32_OPENBSD now for some reason suffer from an inability to heap allocate anything, failing around the attempt to create a new thread like in RTAllocator_M or so. I'll look into this more later.Now, the problem of trampolines..I consider the platform-dependent-ness to be surmountable.But where do you put the generated code? Putting it on the stack is counter to modern (and possibly old) "security" mechanisms.The stack is not generally executable, and even when it is, best just not do use that imho. That means, potentially/obviously, the need to heap allocate executable memory, for very small short lived data, quite inefficient. Is there some other way/place to produce trampolines, efficiently? In the absence of any good solution, I have to resign myself to assuming that -1 isn't the valid start of a function, and perhaps moving the marker into Target.i3, Target.m3 so that "more obvious" values get chosen. Like a breakpoint. Or "an epilogue", or "a trap instruction". I realize this needs details and is easily seen as "wrong". In particular, a function that does nothing could be termed as only having an "an epilogue". I know that other systems are "forced" to create "trampolines" so I should look into how they do that.I know that ATL, a Windows-specific library, is forced to heap allocate small executable chunks of memory and uses an efficient cache to optimize it. I do find this dependence on -1 not being the valid start of a function rather sleazy and at risk of being wrong.  - Jay

> Date: Sun, 25 May 2008 22:50:15 -0500> From: rodney.bates at wichita.edu> To: m3devel at elegosoft.com> Subject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?> > I think I can shed some light on this, having spent some time making> m3gdb handle the various operations on nested procedures. As for code> that mixes M3 and C, I believe the following are true:> > - Within M3 code only, the closure system works correctly in all cases.> This answers one of Jay's worries.> > - For values of M3 procedure/C function pointer that are top-level> (nonnested) procedures/functions, M3 and C code (generated by gcc,> at least) are interchangeable. This answers another of Jay's worries.> This will cover that great majority of cases.> > - Standard C has no nested functions. Gcc adds them as a language> extension. Thus, only in gcc-compiled C code do we need to worry> about nested procedures/functions between languages. (Do any other> C compilers exist that also have nested functions?)> > - M3 code should be able to call the value of a procedure variable> that was originally produced by C code as a pointer to a nested> function, and get the environment set up right, so its nonlocal> variable references will work, _if_ the nested function's> environment has not disappeared. This partially answers another> of Jay's worries. But:> > - M3's normal runtime check that precludes assigning a nonlocal> procedure value will not detect a C-code-produced nonlocal value,> thus the environment could indeed have disappeared if the programmer> was not careful. However, gcc-extended C's nested functions have> no protection against this bug when only C code is involved, so> perhaps not detecting it in mixed M3/C is to be expected.> > - C code that attempts to call a function pointer value that was> originally produced by M3 code as a nested procedure value will> almost certainly crash at the time of the call. This is the only> case that presents a significant problem. M3 code will not be> able to give a nested procedure as a callback to a C library.> > M3's mechanism: A value of procedure type is a pointer to either> 1) the first byte of the procedure's machine code, if it is top level, or> 2) A closure.> > A closure is a block of 3 words. The first word contains -1. Assuming> a word of all one bits is not valid machine code on any target machine> (or at least doesn't occur as the first code of any procedure), this can> be used at runtime to detect that this is indeed a closure and not code.> The remaining two words hold the code address and the environment address.> > So, an assignment of a procedure value has to check that it is not a closure,> and raise a runtime error if it is. A call on a procedure value has to check,> and if it is a closure, load/copy its environment pointer value into wherever> the calling convention expects it, then branch to the code address. Passing> a nested procedure constant as a parameter involves constructing a closure for> it and passing its address.> > gcc-C's mechanism: A value of type pointer to function is a pointer to either> 1) the first byte of the function's machine code, if it is top level,> (the same as with M3), or> 2) A trampoline.> > A trampoline is a bit of code that loads/copies an environment pointer (hard> coded into the trampoline) and then branches to the function code.> > Trampolines probably have a small constant-time speed advantage for _calls_,> but would be slower for some of the other operations, and the runtime check> could be tricky. Probably it could be fooled into failing when it shouldn't.> Moreover, trampolines are highly target-machine-dependent. Switching to them> would create a really big problem for m3gdb, which would have to have> different code for each target for each of the nested procedure operations.> > Jay wrote:> > I see somewhat.> > It's stuff around "closure".> > The comparison of code bytes to -1 comes from If_closure for example.> > > > The problem is presumably to come up with a unified representation of > > pointers to functions that may or may not be nested, while avoiding > > runtime codegen, even just a little bit, and for Modula-3 and C function > > pointers to use the same representation.> > I don't think the present solution is really valid, and I am skeptical > > that there is a solution.> > One of the requirements has to be dropped.> > Sniffing code bytes and trying to decide if they are code or not as > > appears to currently happen is bogus.> > > > I think the solution is to remove the requirement that a Modula-3 > > function pointer and a C function pointer are the same.> > Except, well, that probably doesn't work -- it means you need two types > > of function pointers.> > > > Darn this is a hard problem.> > > > The runtime codegen required can be exceedingly simple, fast, and small > > IF it were allowed to be on the stack. But that's a killer these days.> > > > I think you have to give up unification of "closures" and "function > > pointers".> > If you take the address of a nested function and call it, you cannot > > access the locals of the enclosing scopes.> > So in affect, you end up with "two types of function pointers".> > Regular stateless ones and "closures" with some captured state.> > > > Thoughts?> > > > I'm kind of stumped. It's a desirable problem to solve, and there is a > > purported solution in place, but the solution that is there is > > completely bogus, despite appearing to work for a long time, and there > > is no solution. That is my understanding. I could be wrong on any number > > of points but I'm pretty sure.> > > > I think you have to separate out function pointers and closures.> > Sniffing what it pointed to is dubous esp. as currently implemented.> > If this is really the way to go, then signature bytes need to be worked > > out for all architectures that are guaranteed to not look like code.> > Or vice versa -- signature bytes worked out that all functions start > > with, which is viable for Modula-3 but not for interop with C.> > Currently -1 is used, of pointer-size.> > That appears to be reasonable for x86:> > > > 0:000> eb . ff ff ff ff> > 0:000> u .> > ntdll32!DbgBreakPoint:> > 7d61002d ff ???> > 7d61002e ff ???> > 7d61002f ff ???> > 7d610030 ffc3 inc ebx> > > > but the instruction encodings or disassembly on other architectures > > would have to be checked.> > > > - Jay> > > > ------------------------------------------------------------------------> > From: jayk123 at hotmail.com> > To: m3devel at elegosoft.com> > Date: Sun, 25 May 2008 00:16:01 +0000> > Subject: [M3devel] function pointers and comparison to nil?> > mis-typed function pointers?> > > > I'm being lazy...> > > > Tony can you explain this stuff?> > > > Comparison of function pointers..> > What are the various representations and rules?> > > > What does it mean to compare nested functions?> > > > What does it mean to compare a function to NIL?> > > > I'll poke around more.> > > > What I am seeing is that comparison of function pointers to NIL is> > surprisingly> > expensive, and probably somewhat buggy. Or at least some of the runtime> > generated "metadata-ish" stuff is produced or typed incorrectly.> > > > In particular, RTLinker.m3:> > > > PROCEDURE AddUnit (b: RT0.Binder) => > VAR m: RT0.ModulePtr;> > BEGIN> > IF (b = NIL) THEN RETURN END; line 119> > m := b(0); line 120> > IF (m = NIL) THEN RETURN END; line 121> > AddUnitI(m); line 122> > END AddUnit;> > > > generates a lot of code, just for the first line:> > (556) set_source_line > > source line 119 > > (557) load > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb > > (558) load_nil > > (559) if_eq > > (560) load > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb > > (561) load_indirect > > load address offset 0x0 src_t 0x5 dst_t 0x5 > > (562) load_integer > > integer n_bytes 0x0 hi 0x0 low 0x1 sign -1 > > (563) if_eq > > (564) set_label > > (565) load_nil > > (566) load > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb > > (567) if_ne > > (568) set_label > > (569) exit_proc > > (570) set_label > > (571) set_source_line > > source line 120 > > > > The details on the load_integer trace might not be completely> > correct. I will test a fix shortly.> > Esp. that n_bytes gets decremented to zero before the trace.> > > > Ok, I see now why some of the bloat -- because the "then return end"> > is on the same line.> > If it were written as:> > if (b = NIL THEN > > return> > end > > It probably wouldn't look so bad. That took me a while to realize.> > > > The following is generated for SPARC64_OPENBSD:> > > > line 119> > .stabn 68,0,119,.LLM61-.LLFBB4> > .LLM61:> > ldx [%fp+2175], %g1> > brz %g1, .LL26> > nop> > ldx [%fp+2175], %g1> > ldx [%g1], %g1 bus error here? yes, probably this one> > cmp %g1, -1> > be %xcc, .LL27> > nop> > .LL26:> > ldx [%fp+2175], %g1> > brz %g1, .LL33> > nop> > .LL27:> > line 120> > .stabn 68,0,120,.LLM62-.LLFBB4> > .LLM62:> > ldx [%fp+2175], %g1> > stx %g1, [%fp+2007]> > ldx [%fp+2007], %g1> > brz %g1, .LL30> > nop> > ldx [%fp+2007], %g1> > ldx [%g1], %g1 or here ?> > cmp %g1, -1> > bne %xcc, .LL30> > nop> > ldx [%fp+2007], %g1> > add %g1, 16, %g1> > ldx [%g1], %g1 or here?> > stx %g1, [%fp+2015]> > ldx [%fp+2007], %g1> > add %g1, 8, %g1> > ldx [%g1], %g1> > stx %g1, [%fp+2007]> > .LL30:> > ldx [%fp+2007], %g1> > ldx [%fp+2015], %g5> > mov 0, %o0> > call %g1, 0> > nop> > mov %o0, %g1> > stx %g1, [%fp+2023]> > ldx [%fp+2023], %g1> > stx %g1, [%fp+1999]> > > > line 121> > > > .stabn 68,0,121,.LLM63-.LLFBB4> > .LLM63:> > ldx [%fp+1999], %g1> > brz %g1, .LL33> > nop> > .LL32:> > .stabn 68,0,122,.LLM64-.LLFBB4> > .LLM64:> > > > g1 points to RTSignal_I3> > > > (gdb) x/i $pc> > 0x3ff0a8 : ldx [ %g1 ], %g1> > (gdb) x/i $g1> > 0x4021f4 : save %sp, -208, %sp> > > > I am willing to accept that a "function pointer" is a pair of> > pointers, or even three pointers.> > A pointer to code, a pointer to globals for position independent> > code, a frame pointer to locals.> > That equality comparison of function pointers requires comparing two> > (or three) pointers.> > (Though the global pointer shouldn't need comparing.)> > At least for nested functions. Less so for non-nested. ?> > Much less for comparison to NIL. ?> > > > And either way, this code is reading bogus data.> > There isn't a pointer at the function address, there is code.> > > > Something doesn't add up.> > > > I'm going to try setting "aligned procedures" but that's quite bogus> > I think.> > > > EqualExpr.m3 says> > > > Note: procedures pointers are always aligned!> > > > but maybe not?> > > > Yeah yeah I'm being lazy. I'll read more code..> > > > I also wonder if a "function pointer" can be optimized for the case> > of not being to a nested function.> > It looks like calling a function pointer is very inefficient.> > It looks like..am I reading that correctly?.. that if the pointer> > points to -1, then it is nested and> > a pair of pointers, and not otherwise. That -1 is treated specially> > as the first bytes of a function?> > Is that a Modula-3-ism or a SPARC-ism?> > It looks like a Modula-3-ism. And it seems dubious.> > But I'll have to read more..> > > > NT386GNU does the same sort of wrong looking thing:> > > > LFBB4:> > pushl %ebp> > movl %esp, %ebp> > subl $24, %esp> > LBB5:> > .stabn 68,0,117,LM60-LFBB4> > LM60:> > movl $0, -16(%ebp)> > .stabn 68,0,119,LM61-LFBB4> > LM61:> > movl 8(%ebp), %eax> > testl %eax, %eax> > je L26> > movl 8(%ebp), %eax> > movl (%eax), %eax BAD> > cmpl $-1, %eax BAD> > je L27> > L26:> > movl 8(%ebp), %eax> > testl %eax, %eax> > je L33> > L27:> > .stabn 68,0,120,LM62-LFBB4> > LM62:> > > > > > and NT386:> > > > 0:000> u> > cm3!RTLinker__AddUnit:> > 00607864 55 push ebp> > 00607865 8bec mov ebp,esp> > 00607867 81ec0c000000 sub esp,0Ch> > 0060786d 53 push ebx> > 0060786e 56 push esi> > 0060786f 57 push edi> > 00607870 c745fc00000000 mov dword ptr [ebp-4],0> > 00607877 837d0800 cmp dword ptr [ebp+8],0> > 0:000> u> > cm3!RTLinker__AddUnit+0x17:> > 0060787b 0f840f000000 je cm3!RTLinker__AddUnit+0x2c (00607890)> > 00607881 8b7508 mov esi,dword ptr [ebp+8]> > 00607884 8b5e00 mov ebx,dword ptr> > [esi] BAD > > 00607887 83fbff cmp > > ebx,0FFFFFFFFh BAD> > 0060788a 0f840f000000 je cm3!RTLinker__AddUnit+0x3b (0060789f)> > 00607890 837d0800 cmp dword ptr [ebp+8],0> > 00607894 0f8505000000 jne cm3!RTLinker__AddUnit+0x3b (0060789f)> > 0060789a e969000000 jmp cm3!RTLinker__AddUnit+0xa4 (00607908)> > > > cm3!RTLinker__AddUnit+0x20:> > 00607884 8b5e00 mov ebx,dword ptr [esi] > > ds:002b:0062c950=81ec8b55> > 0:000> u @esi> > cm3!RTLinker_I3:> > 0062c950 55 push ebp> > 0062c951 8bec mov ebp,esp> > 0062c953 81ec00000000 sub esp,0> > 0062c959 53 push ebx> > 0062c95a 56 push esi> > 0062c95b 57 push edi> > 0062c95c 837d0800 cmp dword ptr [ebp+8],0> > 0062c960 0f8400000000 je cm3!RTLinker_I3+0x16 (0062c966)> > > > This is just wrong.> > Comparing bytes of code to -1.> > > > I think the likely fix is for the "I3" code to be laid out as a> > "constant function pointer", a pointer to a pair of pointers where> > one points to the code and one is to -1. Something like that. That> > can't be quite correct given that the existing data is callable.> > > > - Jay> > -- > -------------------------------------------------------------> Rodney M. Bates, retired assistant professor> Dept. of Computer Science, Wichita State University> Wichita, KS 67260-0083> 316-978-3922> rodney.bates at wichita.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rodney.bates at wichita.edu  Mon May 26 22:47:53 2008
From: rodney.bates at wichita.edu (Rodney M. Bates)
Date: Mon, 26 May 2008 15:47:53 -0500
Subject: [M3devel] function pointers and comparison to nil? mis-typed
 function pointers?
In-Reply-To: 
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
	
	
	
	
Message-ID: <483B21F9.6070205@wichita.edu>



Jay wrote:
> It stinks either way imho.
> The portability is handled, somehow or another, by gcc's support for 
> nested functions.
> For example on OpenBSD, they call mprotect to make the trampoline 
> executable -- expensive! and leaves a bit of a security hole.
> On Linux you can sometimes mark the .exe as needing an executable stack 
> or not. Similarly on Windows, linker has /nxcompat, /nxcompat:no switch.
> ATL on Windows puts trampolines in the heap and specifically makes them 
> executable -- since the heap isn't necessarily executable either.
> The -1 marker is also a bit of a portability problem but I guess in 
> practise it works out.

Using trampolines would make this problem worse, perhaps much worse.
Mistaking the function's real code for a closure is a lot less likely
than mistaking the function's real code for a trampoline.  A trampoline
is, after all, always valid machine code on the executing processor.
Not necessarily so for -1.

> I'd be curious to see how it decodes on various processors.
>  
>  - Jay
>
-- 
-------------------------------------------------------------
Rodney M. Bates, retired assistant professor
Dept. of Computer Science, Wichita State University
Wichita, KS 67260-0083
316-978-3922
rodney.bates at wichita.edu


From jayk123 at hotmail.com  Mon May 26 23:33:21 2008
From: jayk123 at hotmail.com (Jay)
Date: Mon, 26 May 2008 21:33:21 +0000
Subject: [M3devel] function pointers and comparison to nil? mis-typed
 function pointers?
In-Reply-To: <483B21F9.6070205@wichita.edu>
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
	
	
	
	 
	<483B21F9.6070205@wichita.edu>
Message-ID: 

 > Mistaking the function's real code for a closure is a lot less likely  > than mistaking the function's real code for a trampoline. A trampoline 
What is the danger in "mistaking" "real code" for a "trampoline"?
They are both "real code".
The differences are:
  - trampoline has limited lifetime -- unless it is heap allocated and garbage collected 
    ("real code" also has "limited lifetime", but relatively much longer, if code can be unloaded, which it can be in many environments) 
  - the "real code" of nested functions has a different calling convention than "real code" for non nested functions; it has an extra parameter "somewhere", for the "static link"; in gcc C nested functions on Cygwin/x86, this is in ecx 
 
What do folks think about putting trampolines in executable garbage collected heap?
I think that's inefficient but I'm usually in the minority here regarding the heap being inefficient.
 
One way or another, gcc makes C nested functions fairly portable, except Apple's gcc on Darwin.
Portability of -1 as a marker denoting "not code" is also dubious.
 
I think it stinks either way.
 
Anyone think coming up with "better" per-architecture markers is reasonable?
 
 - Jay



> Date: Mon, 26 May 2008 15:47:53 -0500> From: rodney.bates at wichita.edu> To: m3devel at elegosoft.com> Subject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?> > > > Jay wrote:> > It stinks either way imho.> > The portability is handled, somehow or another, by gcc's support for > > nested functions.> > For example on OpenBSD, they call mprotect to make the trampoline > > executable -- expensive! and leaves a bit of a security hole.> > On Linux you can sometimes mark the .exe as needing an executable stack > > or not. Similarly on Windows, linker has /nxcompat, /nxcompat:no switch.> > ATL on Windows puts trampolines in the heap and specifically makes them > > executable -- since the heap isn't necessarily executable either.> > The -1 marker is also a bit of a portability problem but I guess in > > practise it works out.> > Using trampolines would make this problem worse, perhaps much worse.> Mistaking the function's real code for a closure is a lot less likely> than mistaking the function's real code for a trampoline. A trampoline> is, after all, always valid machine code on the executing processor.> Not necessarily so for -1.> > > I'd be curious to see how it decodes on various processors.> > > > - Jay> >> -- > -------------------------------------------------------------> Rodney M. Bates, retired assistant professor> Dept. of Computer Science, Wichita State University> Wichita, KS 67260-0083> 316-978-3922> rodney.bates at wichita.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Tue May 27 07:14:11 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 27 May 2008 05:14:11 +0000
Subject: [M3devel] stat file types?
In-Reply-To: 
References: 
Message-ID: 

Hm. I was about to commit this and then I found:
 
 http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/sys/stat.h  http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libbc/inc/include/sys/stat.h 
 
One of these defines S_IFPORT, and it isn't equal to S_IFIFO.
The Modula-3 implementation is *perhaps* incorrect.
 
I don't yet have a Solaris install to see which of these is /usr/include/sys/stat.h and/or to determine what "the other" is.
 
I still haven't found any systems that define S_IFPIPE.
 
 - Jay


From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: stat file types?Date: Sat, 24 May 2008 09:50:50 +0000


It SEEMS: S_IFPIPE appears to be made up by Modula-3.S_IFPORT appears to be made up by Modula-3 as a synonym for S_IFIFO. PROPOSED:This code:D:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX\FilePosix.i3(36):   error if "fd" is not "S_IFPIPE", "S_IFPORT", or "S_IFSOCK". *)D:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX\FilePosix.m3(47):    | Ustat.S_IFPIPE, Ustat.S_IFPORT, Ustat.S_IFSOCK => should check for S_IFSOCK and S_IFIFO.all references to and definitions of S_IFPORT and S_IFPIPE should go away. Or did some actual systems actually define either of these? Most of the *.i3 files set S_IFPORT = S_IFIFO and S_IFPIPE = 0.Many of them say that there is no S_IFPIPE in their .h file.Irix has them reversed but the same result: S_IFPORT = 0 and S_IFPIPE = S_IFIFO. Any objections? - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From hosking at cs.purdue.edu  Tue May 27 10:48:37 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 27 May 2008 09:48:37 +0100
Subject: [M3devel] function pointers and comparison to nil? mis-typed
	function pointers?
In-Reply-To: 
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
	
	
	
	
Message-ID: <7F087A94-FCF4-487C-8744-530F82B95F95@cs.purdue.edu>

gcc just allows computation of the static link.

I think there is an alternate compilation mode supported by the front- 
end for other platforms (like the integrated back end) but I have not  
looked at that closely.



On May 26, 2008, at 8:45 PM, Jay wrote:

> It stinks either way imho.
> The portability is handled, somehow or another, by gcc's support for  
> nested functions.
> For example on OpenBSD, they call mprotect to make the trampoline  
> executable -- expensive! and leaves a bit of a security hole.
> On Linux you can sometimes mark the .exe as needing an executable  
> stack or not. Similarly on Windows, linker has /nxcompat, / 
> nxcompat:no switch.
> ATL on Windows puts trampolines in the heap and specifically makes  
> them executable -- since the heap isn't necessarily executable either.
> The -1 marker is also a bit of a portability problem but I guess in  
> practise it works out.
> I'd be curious to see how it decodes on various processors.
>
>  - Jay
>
> CC: rodney.bates at wichita.edu; m3devel at elegosoft.com
> From: hosking at cs.purdue.edu
> To: jayk123 at hotmail.com
> Subject: Re: [M3devel] function pointers and comparison to nil? mis- 
> typed function pointers?
> Date: Mon, 26 May 2008 14:38:53 +0100
>
> Moving away from the current implementation would be a portability  
> disaster because of the fact that gcc requires an executable stack  
> for its nested function implementation which is non-portable.
>
> On May 26, 2008, at 11:04 AM, Jay wrote:
>
> Cygwin gcc clearly generates code on the stack for nested functions.
> And then search the web..that's how it works in general.
> Nested functions have been deprecated on Mac OS X, in anticipation  
> of possibly making the stack not executable.
>
> OpenBSD doesn't allow execution on the stack.
> They use mprotect to let trampolines run:
>   http://gcc.gnu.org/ml/gcc/2004-01/msg00742.html
> and
>   http://resin.csoft.net/cgi-bin/man.cgi?section=1&topic=gcc-local
>
> Even though nested functions are a gcc extension to the C language,  
> email threads out there discuss Ada, Pascal, and even ! Modula-3 as  
> having nested functions, and that therefore deprecating the C  
> language feature doesn't "solve" the "problem".
>
> I remain uncertain what, if anything, to do here.
>  - keep the -1 hack, do nothing
>     generalize it slightly to let targets pick "better" markers
>  - use gcc's supported for nested functions
>    (plus the integrated backend, not difficult)
>
> Clearly this is a dilemna to more than just me. :)
>
>  - Jay
> From: jayk123 at hotmail.com
> To: rodney.bates at wichita.edu; m3devel at elegosoft.com
> Date: Mon, 26 May 2008 05:26:41 +0000
> Subject: Re: [M3devel] function pointers and comparison to nil? mis- 
> typed function pointers?
>
> Rodney, this agrees with much of what I figured out and guessed. I  
> did not think of or look into some of what you point out though:
>   - what gcc's nested functions look like, and if you can take the  
> address, and what that does
>   - calling Modula-3 nested functions as callbacks from C
>
> Now, regarding trampolines.
> I alluded to them. It should be easy enough to generate them, and  
> this would solve a few problems, but I believe also bring up a new  
> big problem.
> Generating trampolines solves at least two problems:
>  - it allows Modula-3 nested function pointers ("closures") to be  
> called from C
>  - it enables removing the check for -1
>
> I contend that the check for -1 is not good. It is a somewhat risky  
> assumption, that "-1" is not valid code.
> You do bring up a nice mitigation -- the assumption that it doesn't  
> begin any functions, which is much narrower than it being valid code  
> anywhere.
>
> For SPARC64_OPENBSD I figured out what the original authors meant to  
> be the fix.
> You declare functions as not aligned, leading to the check for -1  
> first checking alignment (bigger code).
> Any pointer not aligned on an integer-sized address is presumed not  
> a closure and not checked for the -1.
> This lets SPARC64_OPENBSD get further. Both it and PPC32_OPENBSD now  
> for some reason suffer from an inability to heap allocate anything,  
> failing around the attempt to create a new thread like in  
> RTAllocator_M or so. I'll look into this more later.
>
> Now, the problem of trampolines..I consider the platform-dependent- 
> ness to be surmountable.
> But where do you put the generated code? Putting it on the stack is  
> counter to modern (and possibly old) "security" mechanisms.
> The stack is not generally executable, and even when it is, best  
> just not do use that imho.
>
> That means, potentially/obviously, the need to heap allocate  
> executable memory, for very small short lived data, quite inefficient.
>
> Is there some other way/place to produce trampolines, efficiently?
>
> In the absence of any good solution, I have to resign myself to  
> assuming that -1 isn't the valid start of a function, and perhaps  
> moving the marker into Target.i3, Target.m3 so that "more obvious"  
> values get chosen. Like a breakpoint. Or "an epilogue", or "a trap  
> instruction". I realize this needs details and is easily seen as  
> "wrong". In particular, a function that does nothing could be termed  
> as only having an "an epilogue".
>
> I know that other systems are "forced" to create "trampolines" so I  
> should look into how they do that.
> I know that ATL, a Windows-specific library, is forced to heap  
> allocate small executable chunks of memory and uses an efficient  
> cache to optimize it.
>
> I do find this dependence on -1 not being the valid start of a  
> function rather sleazy and at risk of being wrong.
>
>  - Jay
>
>
>
>
> > Date: Sun, 25 May 2008 22:50:15 -0500
> > From: rodney.bates at wichita.edu
> > To: m3devel at elegosoft.com
> > Subject: Re: [M3devel] function pointers and comparison to nil?  
> mis-typed function pointers?
> >
> > I think I can shed some light on this, having spent some time making
> > m3gdb handle the various operations on nested procedures. As for  
> code
> > that mixes M3 and C, I believe the following are true:
> >
> > - Within M3 code only, the closure system works correctly in all  
> cases.
> > This answers one of Jay's worries.
> >
> > - For values of M3 procedure/C function pointer that are top-level
> > (nonnested) procedures/functions, M3 and C code (generated by gcc,
> > at least) are interchangeable. This answers another of Jay's  
> worries.
> > This will cover that great majority of cases.
> >
> > - Standard C has no nested functions. Gcc adds them as a language
> > extension. Thus, only in gcc-compiled C code do we need to worry
> > about nested procedures/functions between languages. (Do any other
> > C compilers exist that also have nested functions?)
> >
> > - M3 code should be able to call the value of a procedure variable
> > that was originally produced by C code as a pointer to a nested
> > function, and get the environment set up right, so its nonlocal
> > variable references will work, _if_ the nested function's
> > environment has not disappeared. This partially answers another
> > of Jay's worries. But:
> >
> > - M3's normal runtime check that precludes assigning a nonlocal
> > procedure value will not detect a C-code-produced nonlocal value,
> > thus the environment could indeed have disappeared if the programmer
> > was not careful. However, gcc-extended C's nested functions have
> > no protection against this bug when only C code is involved, so
> > perhaps not detecting it in mixed M3/C is to be expected.
> >
> > - C code that attempts to call a function pointer value that was
> > originally produced by M3 code as a nested procedure value will
> > almost certainly crash at the time of the call. This is the only
> > case that presents a significant problem. M3 code will not be
> > able to give a nested procedure as a callback to a C library.
> >
> > M3's mechanism: A value of procedure type is a pointer to either
> > 1) the first byte of the procedure's machine code, if it is top  
> level, or
> > 2) A closure.
> >
> > A closure is a block of 3 words. The first word contains -1.  
> Assuming
> > a word of all one bits is not valid machine code on any target  
> machine
> > (or at least doesn't occur as the first code of any procedure),  
> this can
> > be used at runtime to detect that this is indeed a closure and not  
> code.
> > The remaining two words hold the code address and the environment  
> address.
> >
> > So, an assignment of a procedure value has to check that it is not  
> a closure,
> > and raise a runtime error if it is. A call on a procedure value  
> has to check,
> > and if it is a closure, load/copy its environment pointer value  
> into wherever
> > the calling convention expects it, then branch to the code  
> address. Passing
> > a nested procedure constant as a parameter involves constructing a  
> closure for
> > it and passing its address.
> >
> > gcc-C's mechanism: A value of type pointer to function is a  
> pointer to either
> > 1) the first byte of the function's machine code, if it is top  
> level,
> > (the same as with M3), or
> > 2) A trampoline.
> >
> > A trampoline is a bit of code that loads/copies an environment  
> pointer (hard
> > coded into the trampoline) and then branches to the function code.
> >
> > Trampolines probably have a small constant-time speed advantage  
> for _calls_,
> > but would be slower for some of the other operations, and the  
> runtime check
> > could be tricky. Probably it could be fooled into failing when it  
> shouldn't.
> > Moreover, trampolines are highly target-machine-dependent.  
> Switching to them
> > would create a really big problem for m3gdb, which would have to  
> have
> > different code for each target for each of the nested procedure  
> operations.
> >
> > Jay wrote:
> > > I see somewhat.
> > > It's stuff around "closure".
> > > The comparison of code bytes to -1 comes from If_closure for  
> example.
> > >
> > > The problem is presumably to come up with a unified  
> representation of
> > > pointers to functions that may or may not be nested, while  
> avoiding
> > > runtime codegen, even just a little bit, and for Modula-3 and C  
> function
> > > pointers to use the same representation.
> > > I don't think the present solution is really valid, and I am  
> skeptical
> > > that there is a solution.
> > > One of the requirements has to be dropped.
> > > Sniffing code bytes and trying to decide if they are code or not  
> as
> > > appears to currently happen is bogus.
> > >
> > > I think the solution is to remove the requirement that a Modula-3
> > > function pointer and a C function pointer are the same.
> > > Except, well, that probably doesn't work -- it means you need  
> two types
> > > of function pointers.
> > >
> > > Darn this is a hard problem.
> > >
> > > The runtime codegen required can be exceedingly simple, fast,  
> and small
> > > IF it were allowed to be on the stack. But that's a killer these  
> days.
> > >
> > > I think you have to give up unification of "closures" and  
> "function
> > > pointers".
> > > If you take the address of a nested function and call it, you  
> cannot
> > > access the locals of the enclosing scopes.
> > > So in affect, you end up with "two types of function pointers".
> > > Regular stateless ones and "closures" with some captured state.
> > >
> > > Thoughts?
> > >
> > > I'm kind of stumped. It's a desirable problem to solve, and  
> there is a
> > > purported solution in place, but the solution that is there is
> > > completely bogus, despite appearing to work for a long time, and  
> there
> > > is no solution. That is my understanding. I could be wrong on  
> any number
> > > of points but I'm pretty sure.
> > >
> > > I think you have to separate out function pointers and closures.
> > > Sniffing what it pointed to is dubous esp. as currently  
> implemented.
> > > If this is really the way to go, then signature bytes need to be  
> worked
> > > out for all architectures that are guaranteed to not look like  
> code.
> > > Or vice versa -- signature bytes worked out that all functions  
> start
> > > with, which is viable for Modula-3 but not for interop with C.
> > > Currently -1 is used, of pointer-size.
> > > That appears to be reasonable for x86:
> > >
> > > 0:000> eb . ff ff ff ff
> > > 0:000> u .
> > > ntdll32!DbgBreakPoint:
> > > 7d61002d ff ???
> > > 7d61002e ff ???
> > > 7d61002f ff ???
> > > 7d610030 ffc3 inc ebx
> > >
> > > but the instruction encodings or disassembly on other  
> architectures
> > > would have to be checked.
> > >
> > > - Jay
> > >
> > >  
> ------------------------------------------------------------------------
> > > From: jayk123 at hotmail.com
> > > To: m3devel at elegosoft.com
> > > Date: Sun, 25 May 2008 00:16:01 +0000
> > > Subject: [M3devel] function pointers and comparison to nil?
> > > mis-typed function pointers?
> > >
> > > I'm being lazy...
> > >
> > > Tony can you explain this stuff?
> > >
> > > Comparison of function pointers..
> > > What are the various representations and rules?
> > >
> > > What does it mean to compare nested functions?
> > >
> > > What does it mean to compare a function to NIL?
> > >
> > > I'll poke around more.
> > >
> > > What I am seeing is that comparison of function pointers to NIL is
> > > surprisingly
> > > expensive, and probably somewhat buggy. Or at least some of the  
> runtime
> > > generated "metadata-ish" stuff is produced or typed incorrectly.
> > >
> > > In particular, RTLinker.m3:
> > >
> > > PROCEDURE AddUnit (b: RT0.Binder) =
> > > VAR m: RT0.ModulePtr;
> > > BEGIN
> > > IF (b = NIL) THEN RETURN END; line 119
> > > m := b(0); line 120
> > > IF (m = NIL) THEN RETURN END; line 121
> > > AddUnitI(m); line 122
> > > END AddUnit;
> > >
> > > generates a lot of code, just for the first line:
> > > (556) set_source_line
> > > source line 119
> > > (557) load
> > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb
> > > (558) load_nil
> > > (559) if_eq
> > > (560) load
> > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb
> > > (561) load_indirect
> > > load address offset 0x0 src_t 0x5 dst_t 0x5
> > > (562) load_integer
> > > integer n_bytes 0x0 hi 0x0 low 0x1 sign -1
> > > (563) if_eq
> > > (564) set_label
> > > (565) load_nil
> > > (566) load
> > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb
> > > (567) if_ne
> > > (568) set_label
> > > (569) exit_proc
> > > (570) set_label
> > > (571) set_source_line
> > > source line 120
> > >
> > > The details on the load_integer trace might not be completely
> > > correct. I will test a fix shortly.
> > > Esp. that n_bytes gets decremented to zero before the trace.
> > >
> > > Ok, I see now why some of the bloat -- because the "then return  
> end"
> > > is on the same line.
> > > If it were written as:
> > > if (b = NIL THEN
> > > return
> > > end
> > > It probably wouldn't look so bad. That took me a while to realize.
> > >
> > > The following is generated for SPARC64_OPENBSD:
> > >
> > > line 119
> > > .stabn 68,0,119,.LLM61-.LLFBB4
> > > .LLM61:
> > > ldx [%fp+2175], %g1
> > > brz %g1, .LL26
> > > nop
> > > ldx [%fp+2175], %g1
> > > ldx [%g1], %g1 bus error here? yes, probably this one
> > > cmp %g1, -1
> > > be %xcc, .LL27
> > > nop
> > > .LL26:
> > > ldx [%fp+2175], %g1
> > > brz %g1, .LL33
> > > nop
> > > .LL27:
> > > line 120
> > > .stabn 68,0,120,.LLM62-.LLFBB4
> > > .LLM62:
> > > ldx [%fp+2175], %g1
> > > stx %g1, [%fp+2007]
> > > ldx [%fp+2007], %g1
> > > brz %g1, .LL30
> > > nop
> > > ldx [%fp+2007], %g1
> > > ldx [%g1], %g1 or here ?
> > > cmp %g1, -1
> > > bne %xcc, .LL30
> > > nop
> > > ldx [%fp+2007], %g1
> > > add %g1, 16, %g1
> > > ldx [%g1], %g1 or here?
> > > stx %g1, [%fp+2015]
> > > ldx [%fp+2007], %g1
> > > add %g1, 8, %g1
> > > ldx [%g1], %g1
> > > stx %g1, [%fp+2007]
> > > .LL30:
> > > ldx [%fp+2007], %g1
> > > ldx [%fp+2015], %g5
> > > mov 0, %o0
> > > call %g1, 0
> > > nop
> > > mov %o0, %g1
> > > stx %g1, [%fp+2023]
> > > ldx [%fp+2023], %g1
> > > stx %g1, [%fp+1999]
> > >
> > > line 121
> > >
> > > .stabn 68,0,121,.LLM63-.LLFBB4
> > > .LLM63:
> > > ldx [%fp+1999], %g1
> > > brz %g1, .LL33
> > > nop
> > > .LL32:
> > > .stabn 68,0,122,.LLM64-.LLFBB4
> > > .LLM64:
> > >
> > > g1 points to RTSignal_I3
> > >
> > > (gdb) x/i $pc
> > > 0x3ff0a8 : ldx [ %g1 ], %g1
> > > (gdb) x/i $g1
> > > 0x4021f4 : save %sp, -208, %sp
> > >
> > > I am willing to accept that a "function pointer" is a pair of
> > > pointers, or even three pointers.
> > > A pointer to code, a pointer to globals for position independent
> > > code, a frame pointer to locals.
> > > That equality comparison of function pointers requires comparing  
> two
> > > (or three) pointers.
> > > (Though the global pointer shouldn't need comparing.)
> > > At least for nested functions. Less so for non-nested. ?
> > > Much less for comparison to NIL. ?
> > >
> > > And either way, this code is reading bogus data.
> > > There isn't a pointer at the function address, there is code.
> > >
> > > Something doesn't add up.
> > >
> > > I'm going to try setting "aligned procedures" but that's quite  
> bogus
> > > I think.
> > >
> > > EqualExpr.m3 says
> > >
> > > Note: procedures pointers are always aligned!
> > >
> > > but maybe not?
> > >
> > > Yeah yeah I'm being lazy. I'll read more code..
> > >
> > > I also wonder if a "function pointer" can be optimized for the  
> case
> > > of not being to a nested function.
> > > It looks like calling a function pointer is very inefficient.
> > > It looks like..am I reading that correctly?.. that if the pointer
> > > points to -1, then it is nested and
> > > a pair of pointers, and not otherwise. That -1 is treated  
> specially
> > > as the first bytes of a function?
> > > Is that a Modula-3-ism or a SPARC-ism?
> > > It looks like a Modula-3-ism. And it seems dubious.
> > > But I'll have to read more..
> > >
> > > NT386GNU does the same sort of wrong looking thing:
> > >
> > > LFBB4:
> > > pushl %ebp
> > > movl %esp, %ebp
> > > subl $24, %esp
> > > LBB5:
> > > .stabn 68,0,117,LM60-LFBB4
> > > LM60:
> > > movl $0, -16(%ebp)
> > > .stabn 68,0,119,LM61-LFBB4
> > > LM61:
> > > movl 8(%ebp), %eax
> > > testl %eax, %eax
> > > je L26
> > > movl 8(%ebp), %eax
> > > movl (%eax), %eax BAD
> > > cmpl $-1, %eax BAD
> > > je L27
> > > L26:
> > > movl 8(%ebp), %eax
> > > testl %eax, %eax
> > > je L33
> > > L27:
> > > .stabn 68,0,120,LM62-LFBB4
> > > LM62:
> > >
> > >
> > > and NT386:
> > >
> > > 0:000> u
> > > cm3!RTLinker__AddUnit:
> > > 00607864 55 push ebp
> > > 00607865 8bec mov ebp,esp
> > > 00607867 81ec0c000000 sub esp,0Ch
> > > 0060786d 53 push ebx
> > > 0060786e 56 push esi
> > > 0060786f 57 push edi
> > > 00607870 c745fc00000000 mov dword ptr [ebp-4],0
> > > 00607877 837d0800 cmp dword ptr [ebp+8],0
> > > 0:000> u
> > > cm3!RTLinker__AddUnit+0x17:
> > > 0060787b 0f840f000000 je cm3!RTLinker__AddUnit+0x2c (00607890)
> > > 00607881 8b7508 mov esi,dword ptr [ebp+8]
> > > 00607884 8b5e00 mov ebx,dword ptr
> > > [esi] BAD
> > > 00607887 83fbff cmp
> > > ebx,0FFFFFFFFh BAD
> > > 0060788a 0f840f000000 je cm3!RTLinker__AddUnit+0x3b (0060789f)
> > > 00607890 837d0800 cmp dword ptr [ebp+8],0
> > > 00607894 0f8505000000 jne cm3!RTLinker__AddUnit+0x3b (0060789f)
> > > 0060789a e969000000 jmp cm3!RTLinker__AddUnit+0xa4 (00607908)
> > >
> > > cm3!RTLinker__AddUnit+0x20:
> > > 00607884 8b5e00 mov ebx,dword ptr [esi]
> > > ds:002b:0062c950=81ec8b55
> > > 0:000> u @esi
> > > cm3!RTLinker_I3:
> > > 0062c950 55 push ebp
> > > 0062c951 8bec mov ebp,esp
> > > 0062c953 81ec00000000 sub esp,0
> > > 0062c959 53 push ebx
> > > 0062c95a 56 push esi
> > > 0062c95b 57 push edi
> > > 0062c95c 837d0800 cmp dword ptr [ebp+8],0
> > > 0062c960 0f8400000000 je cm3!RTLinker_I3+0x16 (0062c966)
> > >
> > > This is just wrong.
> > > Comparing bytes of code to -1.
> > >
> > > I think the likely fix is for the "I3" code to be laid out as a
> > > "constant function pointer", a pointer to a pair of pointers where
> > > one points to the code and one is to -1. Something like that. That
> > > can't be quite correct given that the existing data is callable.
> > >
> > > - Jay
> >
> > --
> > -------------------------------------------------------------
> > Rodney M. Bates, retired assistant professor
> > Dept. of Computer Science, Wichita State University
> > Wichita, KS 67260-0083
> > 316-978-3922
> > rodney.bates at wichita.edu
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From hosking at cs.purdue.edu  Tue May 27 11:37:31 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 27 May 2008 10:37:31 +0100
Subject: [M3devel] gcc/m3cc/cm3c for OpenBSD?
In-Reply-To: 
References: 
Message-ID: <9B55DC75-DDBB-46F8-929F-2216922E39BE@cs.purdue.edu>



On May 19, 2008, at 1:47 PM, Jay wrote:

> What is the right way to handle these:
>  http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/gcc/4.3/patches/
> I imagine:
>  1) import them m3-sys/m3cc/src/patches/openbsd
>  2) perhaps use a vendor branch for the import
>    however they haven't changed in 14 months
>    and HOPEFULLY they get ported upstream

Best this so later vendor upgrades don't confuse them with M3-related  
changes.

>
>  3) apply patches at build time
>
> Seems kind of bad, but I figure also too much to manage to checkin  
> the patch results?
> I realize it stinks largely due to the risk of accidentally doing  
> what is avoided.
> Maybe there is like "VPATH" and the to-be-patched files can be  
> copied in the output
> directory and patched there?
>
>  They aren't all needed, by far, but definitely some of them are  
> needed.
>
>  not needed, roughly:
>     *objc*, *ada*, *lib*
>
>  needed, roughly:
>   *config*
>
>  unclear:
>   all the NULL to (void*) 0 diffs, which are a lot of it
>
>  I kinda'thunk:
>   #ifdef __cplusplus
>   #define NULL 0 /* would perhaps need patch, depending on what  
> calling conventions
>   do with parameters and return values smaller than a word */
>   #else
>   #define NULL ((void*) 0) /* no need for patch */
>   #endif
>
> in particular because in C++ a cast from void* to another* is  
> needed, but not in C.
>
> In fact I see this on OpenBSD:
>
>  #ifndef NULL
>  #ifdef  __GNUG__
>  #define NULL    __null
>  #else
>  #define NULL    0L
>  #endif
>
> Similar question for the AMD64_NT gcc patches, though these are  
> newer, apparently
> still need testing, and since they are new, more hope they will go  
> upstream.
> I don't know why the OpenBSD patches linger, I didn't ask.
>
> I'll proceed as my suggest takes but presumably won't be read to  
> commit
>   till after broader judgement/consensus rendered.
>
>   - Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Tue May 27 13:15:12 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 27 May 2008 11:15:12 +0000
Subject: [M3devel] gcc/m3cc/cm3c for OpenBSD?
In-Reply-To: <9B55DC75-DDBB-46F8-929F-2216922E39BE@cs.purdue.edu>
References: 
	<9B55DC75-DDBB-46F8-929F-2216922E39BE@cs.purdue.edu>
Message-ID: 

Tony, I'm not sure what your answer is below, but I commited #1  +#3.
 
 >> 1) import them m3-sys/m3cc/src/patches/openbsd >> 3) apply patches at build time
Obvious major danger with the current code is of accidentally commiting the patched files.
Perhaps something like copying files into the output and using VPATH can remove that danger.
Or perhaps if the accident occurs, it is easily undone? I don't know.
 
 >> 2) perhaps use a vendor branch for the import 
 
Could there be a vendor branch for "OpenBSD gcc" and then "mainline" is the merge of the various branches?
 
 
 - Jay


CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] gcc/m3cc/cm3c for OpenBSD?Date: Tue, 27 May 2008 10:37:31 +0100



On May 19, 2008, at 1:47 PM, Jay wrote:

What is the right way to handle these: http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/gcc/4.3/patches/I imagine: 1) import them m3-sys/m3cc/src/patches/openbsd 2) perhaps use a vendor branch for the import   however they haven't changed in 14 months   and HOPEFULLY they get ported upstream

Best this so later vendor upgrades don't confuse them with M3-related changes.

 3) apply patches at build timeSeems kind of bad, but I figure also too much to manage to checkin the patch results?I realize it stinks largely due to the risk of accidentally doing what is avoided.Maybe there is like "VPATH" and the to-be-patched files can be copied in the outputdirectory and patched there? They aren't all needed, by far, but definitely some of them are needed.  not needed, roughly:    *objc*, *ada*, *lib* needed, roughly:   *config*  unclear:  all the NULL to (void*) 0 diffs, which are a lot of it I kinda'thunk:  #ifdef __cplusplus  #define NULL 0 /* would perhaps need patch, depending on what calling conventions  do with parameters and return values smaller than a word */   #else  #define NULL ((void*) 0) /* no need for patch */   #endifin particular because in C++ a cast from void* to another* is needed, but not in C.In fact I see this on OpenBSD: #ifndef NULL #ifdef  __GNUG__ #define NULL    __null #else #define NULL    0L #endifSimilar question for the AMD64_NT gcc patches, though these are newer, apparentlystill need testing, and since they are new, more hope they will go upstream.I don't know why the OpenBSD patches linger, I didn't ask.I'll proceed as my suggest takes but presumably won't be read to commit  till after broader judgement/consensus rendered.  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Tue May 27 13:34:39 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 27 May 2008 11:34:39 +0000
Subject: [M3devel] function pointers and comparison to nil? mis-typed
 function pointers?
In-Reply-To: <7F087A94-FCF4-487C-8744-530F82B95F95@cs.purdue.edu>
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
	
	
	
	
	<7F087A94-FCF4-487C-8744-530F82B95F95@cs.purdue.edu>
Message-ID: 

gcc via the C front end does more -- it allows taking the address of a nested function, which generates code on the stack.
I have NOT looked at where the line is here between the C front end and the back end.
..but Ada and Pascal reportedly need this, and it is quite target-dependent, so presumably this is a back end feature.
Still, gcc's vaunted portability here is not clearly adequate consolation and merely shifting the work to it is not clearly a good move.
(besides the integrated backend and any hypothetical LLVM backend or C backend)
 
I was looking into this stuff because calling the module binders in RTLinker.m3 on SPARC64_OPENBSD hit an alignment fault, because SPARC64 instructions are 32bits and 32bit aligned (I guess) but SPARC64 integers are 64bits (definitely) and 64bit aligned (guess), and therefore the code to sniffs for the -1 faults. I'm well past this. The fix is simply to mark in Target.m3 procedures as not aligned and then the check for the -1 marker is preceded by a check of the alignment of the pointer, and unaligned pointers are presumed to not be closures.
 
I'd love to be able to say "This area is obviously messed up and it should be done such and such a way.", but the first is true and the second doesn't exist. Oh well.
My perfectionist and fixy/churny streak can only muster "I wonder how -1 decodes on various architectures and if more reliable per-target markers can be formulated.." esp. something that doesn't depend on invalid encodings, which could be reclaimed in the future for some new instrutions, but perhaps instead relies on valid encodings that would "never" be at the start of a function..though it is pretty hard to rule out anything -- maybe a jmp to 0? I realize that load/store instruction sets can't even necessarily encode that.
Nope -- x86 encodes jmps as PC-relative.
Ok -- indirect call:
 
7c901230 ff1500000000    call    dword ptr ds:[0]7c901236 0f84c4ed6f83    je      00000000
 
so ff 15 00 00 00 00 may be a better marker of "not code" than ff ff ff ff, on x86, maybe.
 
You know -1 may not be legal today, but it could be become legal in the future..
Whereas *arguably* call indirect 0 is "legal" today, so would not change meaning, but "never" occurs, so could be a marker, for some definition of "legal", "never", etc....
 
 - Jay


CC: rodney.bates at wichita.edu; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?Date: Tue, 27 May 2008 09:48:37 +0100gcc just allows computation of the static link.

I think there is an alternate compilation mode supported by the front-end for other platforms (like the integrated back end) but I have not looked at that closely.





On May 26, 2008, at 8:45 PM, Jay wrote:

It stinks either way imho.The portability is handled, somehow or another, by gcc's support for nested functions.For example on OpenBSD, they call mprotect to make the trampoline executable -- expensive! and leaves a bit of a security hole.On Linux you can sometimes mark the .exe as needing an executable stack or not. Similarly on Windows, linker has /nxcompat, /nxcompat:no switch.ATL on Windows puts trampolines in the heap and specifically makes them executable -- since the heap isn't necessarily executable either.The -1 marker is also a bit of a portability problem but I guess in practise it works out.I'd be curious to see how it decodes on various processors.  - Jay


CC: rodney.bates at wichita.edu; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?Date: Mon, 26 May 2008 14:38:53 +0100

Moving away from the current implementation would be a portability disaster because of the fact that gcc requires an executable stack for its nested function implementation which is non-portable.

On May 26, 2008, at 11:04 AM, Jay wrote:

Cygwin gcc clearly generates code on the stack for nested functions.And then search the web..that's how it works in general.Nested functions have been deprecated on Mac OS X, in anticipation of possibly making the stack not executable. OpenBSD doesn't allow execution on the stack.They use mprotect to let trampolines run:  http://gcc.gnu.org/ml/gcc/2004-01/msg00742.html and  http://resin.csoft.net/cgi-bin/man.cgi?section=1&topic=gcc-local  Even though nested functions are a gcc extension to the C language, email threads out there discuss Ada, Pascal, and even ! Modula-3 as having nested functions, and that therefore deprecating the C language feature doesn't "solve" the "problem". I remain uncertain what, if anything, to do here. - keep the -1 hack, do nothing     generalize it slightly to let targets pick "better" markers  - use gcc's supported for nested functions    (plus the integrated backend, not difficult)  Clearly this is a dilemna to more than just me. :)  - Jay


From: jayk123 at hotmail.comTo: rodney.bates at wichita.edu; m3devel at elegosoft.comDate: Mon, 26 May 2008 05:26:41 +0000Subject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?Rodney, this agrees with much of what I figured out and guessed. I did not think of or look into some of what you point out though:  - what gcc's nested functions look like, and if you can take the address, and what that does   - calling Modula-3 nested functions as callbacks from C  Now, regarding trampolines.I alluded to them. It should be easy enough to generate them, and this would solve a few problems, but I believe also bring up a new big problem.Generating trampolines solves at least two problems:  - it allows Modula-3 nested function pointers ("closures") to be called from C  - it enables removing the check for -1  I contend that the check for -1 is not good. It is a somewhat risky assumption, that "-1" is not valid code.You do bring up a nice mitigation -- the assumption that it doesn't begin any functions, which is much narrower than it being valid code anywhere. For SPARC64_OPENBSD I figured out what the original authors meant to be the fix.You declare functions as not aligned, leading to the check for -1 first checking alignment (bigger code).Any pointer not aligned on an integer-sized address is presumed not a closure and not checked for the -1.This lets SPARC64_OPENBSD get further. Both it and PPC32_OPENBSD now for some reason suffer from an inability to heap allocate anything, failing around the attempt to create a new thread like in RTAllocator_M or so. I'll look into this more later.Now, the problem of trampolines..I consider the platform-dependent-ness to be surmountable.But where do you put the generated code? Putting it on the stack is counter to modern (and possibly old) "security" mechanisms.The stack is not generally executable, and even when it is, best just not do use that imho. That means, potentially/obviously, the need to heap allocate executable memory, for very small short lived data, quite inefficient. Is there some other way/place to produce trampolines, efficiently? In the absence of any good solution, I have to resign myself to assuming that -1 isn't the valid start of a function, and perhaps moving the marker into Target.i3, Target.m3 so that "more obvious" values get chosen. Like a breakpoint. Or "an epilogue", or "a trap instruction". I realize this needs details and is easily seen as "wrong". In particular, a function that does nothing could be termed as only having an "an epilogue". I know that other systems are "forced" to create "trampolines" so I should look into how they do that.I know that ATL, a Windows-specific library, is forced to heap allocate small executable chunks of memory and uses an efficient cache to optimize it. I do find this dependence on -1 not being the valid start of a function rather sleazy and at risk of being wrong.  - Jay

> Date: Sun, 25 May 2008 22:50:15 -0500> From: rodney.bates at wichita.edu> To: m3devel at elegosoft.com> Subject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?> > I think I can shed some light on this, having spent some time making> m3gdb handle the various operations on nested procedures. As for code> that mixes M3 and C, I believe the following are true:> > - Within M3 code only, the closure system works correctly in all cases.> This answers one of Jay's worries.> > - For values of M3 procedure/C function pointer that are top-level> (nonnested) procedures/functions, M3 and C code (generated by gcc,> at least) are interchangeable. This answers another of Jay's worries.> This will cover that great majority of cases.> > - Standard C has no nested functions. Gcc adds them as a language> extension. Thus, only in gcc-compiled C code do we need to worry> about nested procedures/functions between languages. (Do any other> C compilers exist that also have nested functions?)> > - M3 code should be able to call the value of a procedure variable> that was originally produced by C code as a pointer to a nested> function, and get the environment set up right, so its nonlocal> variable references will work, _if_ the nested function's> environment has not disappeared. This partially answers another> of Jay's worries. But:> > - M3's normal runtime check that precludes assigning a nonlocal> procedure value will not detect a C-code-produced nonlocal value,> thus the environment could indeed have disappeared if the programmer> was not careful. However, gcc-extended C's nested functions have> no protection against this bug when only C code is involved, so> perhaps not detecting it in mixed M3/C is to be expected.> > - C code that attempts to call a function pointer value that was> originally produced by M3 code as a nested procedure value will> almost certainly crash at the time of the call. This is the only> case that presents a significant problem. M3 code will not be> able to give a nested procedure as a callback to a C library.> > M3's mechanism: A value of procedure type is a pointer to either> 1) the first byte of the procedure's machine code, if it is top level, or> 2) A closure.> > A closure is a block of 3 words. The first word contains -1. Assuming> a word of all one bits is not valid machine code on any target machine> (or at least doesn't occur as the first code of any procedure), this can> be used at runtime to detect that this is indeed a closure and not code.> The remaining two words hold the code address and the environment address.> > So, an assignment of a procedure value has to check that it is not a closure,> and raise a runtime error if it is. A call on a procedure value has to check,> and if it is a closure, load/copy its environment pointer value into wherever> the calling convention expects it, then branch to the code address. Passing> a nested procedure constant as a parameter involves constructing a closure for> it and passing its address.> > gcc-C's mechanism: A value of type pointer to function is a pointer to either> 1) the first byte of the function's machine code, if it is top level,> (the same as with M3), or> 2) A trampoline.> > A trampoline is a bit of code that loads/copies an environment pointer (hard> coded into the trampoline) and then branches to the function code.> > Trampolines probably have a small constant-time speed advantage for _calls_,> but would be slower for some of the other operations, and the runtime check> could be tricky. Probably it could be fooled into failing when it shouldn't.> Moreover, trampolines are highly target-machine-dependent. Switching to them> would create a really big problem for m3gdb, which would have to have> different code for each target for each of the nested procedure operations.> > Jay wrote:> > I see somewhat.> > It's stuff around "closure".> > The comparison of code bytes to -1 comes from If_closure for example.> > > > The problem is presumably to come up with a unified representation of > > pointers to functions that may or may not be nested, while avoiding > > runtime codegen, even just a little bit, and for Modula-3 and C function > > pointers to use the same representation.> > I don't think the present solution is really valid, and I am skeptical > > that there is a solution.> > One of the requirements has to be dropped.> > Sniffing code bytes and trying to decide if they are code or not as > > appears to currently happen is bogus.> > > > I think the solution is to remove the requirement that a Modula-3 > > function pointer and a C function pointer are the same.> > Except, well, that probably doesn't work -- it means you need two types > > of function pointers.> > > > Darn this is a hard problem.> > > > The runtime codegen required can be exceedingly simple, fast, and small > > IF it were allowed to be on the stack. But that's a killer these days.> > > > I think you have to give up unification of "closures" and "function > > pointers".> > If you take the address of a nested function and call it, you cannot > > access the locals of the enclosing scopes.> > So in affect, you end up with "two types of function pointers".> > Regular stateless ones and "closures" with some captured state.> > > > Thoughts?> > > > I'm kind of stumped. It's a desirable problem to solve, and there is a > > purported solution in place, but the solution that is there is > > completely bogus, despite appearing to work for a long time, and there > > is no solution. That is my understanding. I could be wrong on any number > > of points but I'm pretty sure.> > > > I think you have to separate out function pointers and closures.> > Sniffing what it pointed to is dubous esp. as currently implemented.> > If this is really the way to go, then signature bytes need to be worked > > out for all architectures that are guaranteed to not look like code.> > Or vice versa -- signature bytes worked out that all functions start > > with, which is viable for Modula-3 but not for interop with C.> > Currently -1 is used, of pointer-size.> > That appears to be reasonable for x86:> > > > 0:000> eb . ff ff ff ff> > 0:000> u .> > ntdll32!DbgBreakPoint:> > 7d61002d ff ???> > 7d61002e ff ???> > 7d61002f ff ???> > 7d610030 ffc3 inc ebx> > > > but the instruction encodings or disassembly on other architectures > > would have to be checked.> > > > - Jay> > > > ------------------------------------------------------------------------> > From: jayk123 at hotmail.com> > To: m3devel at elegosoft.com> > Date: Sun, 25 May 2008 00:16:01 +0000> > Subject: [M3devel] function pointers and comparison to nil?> > mis-typed function pointers?> > > > I'm being lazy...> > > > Tony can you explain this stuff?> > > > Comparison of function pointers..> > What are the various representations and rules?> > > > What does it mean to compare nested functions?> > > > What does it mean to compare a function to NIL?> > > > I'll poke around more.> > > > What I am seeing is that comparison of function pointers to NIL is> > surprisingly> > expensive, and probably somewhat buggy. Or at least some of the runtime> > generated "metadata-ish" stuff is produced or typed incorrectly.> > > > In particular, RTLinker.m3:> > > > PROCEDURE AddUnit (b: RT0.Binder) => > VAR m: RT0.ModulePtr;> > BEGIN> > IF (b = NIL) THEN RETURN END; line 119> > m := b(0); line 120> > IF (m = NIL) THEN RETURN END; line 121> > AddUnitI(m); line 122> > END AddUnit;> > > > generates a lot of code, just for the first line:> > (556) set_source_line > > source line 119 > > (557) load > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb > > (558) load_nil > > (559) if_eq > > (560) load > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb > > (561) load_indirect > > load address offset 0x0 src_t 0x5 dst_t 0x5 > > (562) load_integer > > integer n_bytes 0x0 hi 0x0 low 0x1 sign -1 > > (563) if_eq > > (564) set_label > > (565) load_nil > > (566) load > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb > > (567) if_ne > > (568) set_label > > (569) exit_proc > > (570) set_label > > (571) set_source_line > > source line 120 > > > > The details on the load_integer trace might not be completely> > correct. I will test a fix shortly.> > Esp. that n_bytes gets decremented to zero before the trace.> > > > Ok, I see now why some of the bloat -- because the "then return end"> > is on the same line.> > If it were written as:> > if (b = NIL THEN > > return> > end > > It probably wouldn't look so bad. That took me a while to realize.> > > > The following is generated for SPARC64_OPENBSD:> > > > line 119> > .stabn 68,0,119,.LLM61-.LLFBB4> > .LLM61:> > ldx [%fp+2175], %g1> > brz %g1, .LL26> > nop> > ldx [%fp+2175], %g1> > ldx [%g1], %g1 bus error here? yes, probably this one> > cmp %g1, -1> > be %xcc, .LL27> > nop> > .LL26:> > ldx [%fp+2175], %g1> > brz %g1, .LL33> > nop> > .LL27:> > line 120> > .stabn 68,0,120,.LLM62-.LLFBB4> > .LLM62:> > ldx [%fp+2175], %g1> > stx %g1, [%fp+2007]> > ldx [%fp+2007], %g1> > brz %g1, .LL30> > nop> > ldx [%fp+2007], %g1> > ldx [%g1], %g1 or here ?> > cmp %g1, -1> > bne %xcc, .LL30> > nop> > ldx [%fp+2007], %g1> > add %g1, 16, %g1> > ldx [%g1], %g1 or here?> > stx %g1, [%fp+2015]> > ldx [%fp+2007], %g1> > add %g1, 8, %g1> > ldx [%g1], %g1> > stx %g1, [%fp+2007]> > .LL30:> > ldx [%fp+2007], %g1> > ldx [%fp+2015], %g5> > mov 0, %o0> > call %g1, 0> > nop> > mov %o0, %g1> > stx %g1, [%fp+2023]> > ldx [%fp+2023], %g1> > stx %g1, [%fp+1999]> > > > line 121> > > > .stabn 68,0,121,.LLM63-.LLFBB4> > .LLM63:> > ldx [%fp+1999], %g1> > brz %g1, .LL33> > nop> > .LL32:> > .stabn 68,0,122,.LLM64-.LLFBB4> > .LLM64:> > > > g1 points to RTSignal_I3> > > > (gdb) x/i $pc> > 0x3ff0a8 : ldx [ %g1 ], %g1> > (gdb) x/i $g1> > 0x4021f4 : save %sp, -208, %sp> > > > I am willing to accept that a "function pointer" is a pair of> > pointers, or even three pointers.> > A pointer to code, a pointer to globals for position independent> > code, a frame pointer to locals.> > That equality comparison of function pointers requires comparing two> > (or three) pointers.> > (Though the global pointer shouldn't need comparing.)> > At least for nested functions. Less so for non-nested. ?> > Much less for comparison to NIL. ?> > > > And either way, this code is reading bogus data.> > There isn't a pointer at the function address, there is code.> > > > Something doesn't add up.> > > > I'm going to try setting "aligned procedures" but that's quite bogus> > I think.> > > > EqualExpr.m3 says> > > > Note: procedures pointers are always aligned!> > > > but maybe not?> > > > Yeah yeah I'm being lazy. I'll read more code..> > > > I also wonder if a "function pointer" can be optimized for the case> > of not being to a nested function.> > It looks like calling a function pointer is very inefficient.> > It looks like..am I reading that correctly?.. that if the pointer> > points to -1, then it is nested and> > a pair of pointers, and not otherwise. That -1 is treated specially> > as the first bytes of a function?> > Is that a Modula-3-ism or a SPARC-ism?> > It looks like a Modula-3-ism. And it seems dubious.> > But I'll have to read more..> > > > NT386GNU does the same sort of wrong looking thing:> > > > LFBB4:> > pushl %ebp> > movl %esp, %ebp> > subl $24, %esp> > LBB5:> > .stabn 68,0,117,LM60-LFBB4> > LM60:> > movl $0, -16(%ebp)> > .stabn 68,0,119,LM61-LFBB4> > LM61:> > movl 8(%ebp), %eax> > testl %eax, %eax> > je L26> > movl 8(%ebp), %eax> > movl (%eax), %eax BAD> > cmpl $-1, %eax BAD> > je L27> > L26:> > movl 8(%ebp), %eax> > testl %eax, %eax> > je L33> > L27:> > .stabn 68,0,120,LM62-LFBB4> > LM62:> > > > > > and NT386:> > > > 0:000> u> > cm3!RTLinker__AddUnit:> > 00607864 55 push ebp> > 00607865 8bec mov ebp,esp> > 00607867 81ec0c000000 sub esp,0Ch> > 0060786d 53 push ebx> > 0060786e 56 push esi> > 0060786f 57 push edi> > 00607870 c745fc00000000 mov dword ptr [ebp-4],0> > 00607877 837d0800 cmp dword ptr [ebp+8],0> > 0:000> u> > cm3!RTLinker__AddUnit+0x17:> > 0060787b 0f840f000000 je cm3!RTLinker__AddUnit+0x2c (00607890)> > 00607881 8b7508 mov esi,dword ptr [ebp+8]> > 00607884 8b5e00 mov ebx,dword ptr> > [esi] BAD > > 00607887 83fbff cmp > > ebx,0FFFFFFFFh BAD> > 0060788a 0f840f000000 je cm3!RTLinker__AddUnit+0x3b (0060789f)> > 00607890 837d0800 cmp dword ptr [ebp+8],0> > 00607894 0f8505000000 jne cm3!RTLinker__AddUnit+0x3b (0060789f)> > 0060789a e969000000 jmp cm3!RTLinker__AddUnit+0xa4 (00607908)> > > > cm3!RTLinker__AddUnit+0x20:> > 00607884 8b5e00 mov ebx,dword ptr [esi] > > ds:002b:0062c950=81ec8b55> > 0:000> u @esi> > cm3!RTLinker_I3:> > 0062c950 55 push ebp> > 0062c951 8bec mov ebp,esp> > 0062c953 81ec00000000 sub esp,0> > 0062c959 53 push ebx> > 0062c95a 56 push esi> > 0062c95b 57 push edi> > 0062c95c 837d0800 cmp dword ptr [ebp+8],0> > 0062c960 0f8400000000 je cm3!RTLinker_I3+0x16 (0062c966)> > > > This is just wrong.> > Comparing bytes of code to -1.> > > > I think the likely fix is for the "I3" code to be laid out as a> > "constant function pointer", a pointer to a pair of pointers where> > one points to the code and one is to -1. Something like that. That> > can't be quite correct given that the existing data is callable.> > > > - Jay> > -- > -------------------------------------------------------------> Rodney M. Bates, retired assistant professor> Dept. of Computer Science, Wichita State University> Wichita, KS 67260-0083> 316-978-3922> rodney.bates at wichita.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From wagner at elegosoft.com  Tue May 27 14:44:52 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 27 May 2008 14:44:52 +0200
Subject: [M3devel] gcc/m3cc/cm3c for OpenBSD?
In-Reply-To: 
References: 
	<9B55DC75-DDBB-46F8-929F-2216922E39BE@cs.purdue.edu>
	
Message-ID: <20080527144452.f6j8bolwgksw0wsc@mail.elegosoft.com>

Quoting Jay :

> Tony, I'm not sure what your answer is below, but I commited #1  +#3.
>
>  >> 1) import them m3-sys/m3cc/src/patches/openbsd >> 3) apply   
> patches at build time
> Obvious major danger with the current code is of accidentally   
> commiting the patched files.
> Perhaps something like copying files into the output and using VPATH  
>  can remove that danger.
> Or perhaps if the accident occurs, it is easily undone? I don't know.
>
>  >> 2) perhaps use a vendor branch for the import
>
> Could there be a vendor branch for "OpenBSD gcc" and then "mainline"  
>  is the merge of the various branches?

CVS does only really support _one_ vendor branch, even if some
docs say otherwise. So if the original gcc sources are on a vendor
branch, openbsd changes for examples should be imported on another
branch, and then explicitly merged (vendor branch is merged implicitly,
which is arguably a feature or a bug ;-)

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  Tue May 27 15:59:26 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 27 May 2008 15:59:26 +0200
Subject: [M3devel] FW: NT386 environment variables (new NT386	snapshots)
In-Reply-To: 
References: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
	
	<4823279D.1E75.00D7.1@scires.com>
	
Message-ID: <20080527155926.203bam89w4w0kgko@mail.elegosoft.com>

Quoting Jay :

> truncated again...
> m3support -- nothing interesting in any logs regarding my mail?
> And nobody else uses hotmail, right?

@Ronny, can you please check if our mail logs reveal any reason
for Jay's mails to be truncated now and then?

>> I will apply an easy fix.
> done

I'm not sure if this means that the issues concerning evnironment
variable access (both via Env and RTArgs) are now fixed for NT386(GNU)...
Can we forget about this issue?

Olaf

> From: jayk123 at hotmail.comTo: rcoleburn at scires.com;   
> m3devel at elegosoft.comSubject: RE: [M3devel] NT386 environment   
> variables (new NT386 snapshots)Date: Fri, 9 May 2008 07:44:09 +0000
>
>
>  > these problems (pixmaps, buildstandalone, environ vars, serial   
> i/o, etc...  Ok, here is the story with environment variables.I   
> tested 3.6 and current, gui and console.This is the   
> program:C:\dev2\j\m3\3>type src\m3makefileimport ("m3core")import   
> ("libm3")m3_option ("-gui")     twiddle this line in and out with a   
> commentimplementation ("Main")program ("pgm") C:\dev2\j\m3\3>type   
> src\Main.m3MODULE Main;IMPORT IO;IMPORT RTArgs; BEGIN(* IO.Put just   
> crashes in 3.6 gui apps *)  IO.Put(RTArgs.GetArg(2));    
> IO.Put(RTArgs.GetEnv(2)); (* use this for gui apps *)  EVAL   
> RTArgs.GetArg(2);  EVAL RTArgs.GetEnv(2);END Main.In 3.6 console   
> apps, RTArgs.GetEnv returns garbage. That makes sense from the   
> code.In current console apps, GetEnv works.In current gui apps,   
> GetEnv access violates, or returns an invalid pointer.  This also   
> makes sense from the code.Randy, does this actually work for you?I'd  
>  be quite surprised.I haven't tried 4.1 yet, just 3.6 and current.I   
> will apply an easy fix. - Jay
>
>
> Date: Thu, 8 May 2008 16:17:37 -0400From: rcoleburn at scires.comTo:   
> m3devel at elegosoft.comSubject: Re: [M3devel] new NT386 snapshots
> Jay:
>
> I have both console and gui programs built using 4.1 that do pull   
> stuff out of the environment.  I've not noticed any problems with   
> either mode.
>
> From my perspective, the old 4.1 seems more reliable than the   
> current system in a number of respects.  I have a new project with a  
>  hard deadline that I would like to use the new cm3 system for, but   
> until these problems (pixmaps, buildstandalone, environ vars, serial  
>  i/o, etc.) can be resolved, I'm going to keep using 4.1 for my   
> production work.
>
> Regards,
> Randy>>> Jay  5/8/2008 2:46 PM   
> >>>http://modula3.elegosoft.com/cm3/uploaded-archives/   
> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0.ziphttp://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-WIN32-NT386-d5.7.0.ziphttp://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0-symbols.zip These should have:  latest quake extensions   set relation fixes   other set fixes revealed through dynamic linking of one regression test   hypothetical ability to cross-build to AMD64_LINUX, AMD64_DARWIN    one jmpbuf size for all NT386 configurations (NT386, NT386GNU, NT386MINGNU)  Built with Visual C++ 9.0 Express, so you'll want:http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en  Still more work to do though, e.g. assertion failures in unit tests, pixmap.. Fuller disclosure:Something is leaking memory on my system such that "everything" starts "failing" and I have to reboot.This isn't Modula-3 related.Hopefully these files aren't damaged as a result.Must be some buggy driver or something.. Aside: The environment variable thingy has been bugging me a long time and I finally looked deeper at it.It appears broken in CM3 4.x. I didn't check 3.x yet.I'm still mulling a fix, and haven't run a repro of the break, but it's not a big deal either way.Basically console apps use main that takes char** and gui apps use WinMain that doesn't get environment variables but the generated code calls GetEvironmentStrings() which returns null separated strings.Must be that hardly anyone uses environment variables in Modula-3 on Win32 for this to have lingered so long, at least gui apps.  -   
> 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 hosking at cs.purdue.edu  Tue May 27 15:56:51 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 27 May 2008 14:56:51 +0100
Subject: [M3devel] function pointers and comparison to nil? mis-typed
	function pointers?
In-Reply-To: 
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
	
	
	
	
	<7F087A94-FCF4-487C-8744-530F82B95F95@cs.purdue.edu>
	
Message-ID: <551F22B1-0098-4828-A91B-3FD4E368231A@cs.purdue.edu>

On May 27, 2008, at 12:34 PM, Jay wrote:

> gcc via the C front end does more -- it allows taking the address of  
> a nested function, which generates code on the stack.
> I have NOT looked at where the line is here between the C front end  
> and the back end.
> ..but Ada and Pascal reportedly need this, and it is quite target- 
> dependent, so presumably this is a back end feature.
> Still, gcc's vaunted portability here is not clearly adequate  
> consolation and merely shifting the work to it is not clearly a good  
> move.
> (besides the integrated backend and any hypothetical LLVM backend or  
> C backend)

True, but it is deprecated and doesn't work on all platforms because  
of stack non-executability.  We compute the static chain using gcc's  
support as it is (with hacks to avoid computation of a function  
pointer via trampoline).

> I was looking into this stuff because calling the module binders in  
> RTLinker.m3 on SPARC64_OPENBSD hit an alignment fault, because  
> SPARC64 instructions are 32bits and 32bit aligned (I guess) but  
> SPARC64 integers are 64bits (definitely) and 64bit aligned (guess),  
> and therefore the code to sniffs for the -1 faults. I'm well past  
> this. The fix is simply to mark in Target.m3 procedures as not  
> aligned and then the check for the -1 marker is preceded by a check  
> of the alignment of the pointer, and unaligned pointers are presumed  
> to not be closures.

OK.

> I'd love to be able to say "This area is obviously messed up and it  
> should be done such and such a way.", but the first is true and the  
> second doesn't exist. Oh well.
> My perfectionist and fixy/churny streak can only muster "I wonder  
> how -1 decodes on various architectures and if more reliable per- 
> target markers can be formulated.." esp. something that doesn't  
> depend on invalid encodings, which could be reclaimed in the future  
> for some new instrutions, but perhaps instead relies on valid  
> encodings that would "never" be at the start of a function..though  
> it is pretty hard to rule out anything -- maybe a jmp to 0? I  
> realize that load/store instruction sets can't even necessarily  
> encode that.
> Nope -- x86 encodes jmps as PC-relative.
> Ok -- indirect call:
>
> 7c901230 ff1500000000    call    dword ptr ds:[0]
> 7c901236 0f84c4ed6f83    je      00000000
>
> so ff 15 00 00 00 00 may be a better marker of "not code" than ff ff  
> ff ff, on x86, maybe.
>
> You know -1 may not be legal today, but it could be become legal in  
> the future..
> Whereas *arguably* call indirect 0 is "legal" today, so would not  
> change meaning, but "never" occurs, so could be a marker, for some  
> definition of "legal", "never", etc....
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From hendrik at topoi.pooq.com  Tue May 27 17:45:51 2008
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Tue, 27 May 2008 11:45:51 -0400
Subject: [M3devel] function pointers and comparison to nil? mis-typed
	function pointers?
In-Reply-To: <483A3377.7070801@wichita.edu>
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
Message-ID: <20080527154551.GA24415@topoi.pooq.com>

On Sun, May 25, 2008 at 10:50:15PM -0500, Rodney M. Bates wrote:
> I think I can shed some light on this, having spent some time making
> m3gdb handle the various operations on nested procedures.  As for code
> that mixes M3 and C, I believe the following are true:
> 
> - Within M3 code only, the closure system works correctly in all cases.
>   This answers one of Jay's worries.

As long as procedure-entry code can be guaranteed never to start wit a 
word of one-bits.  We do have some influence on this code, though, and 
if necessary might be able to choose a different bit pattern on a 
specific platform.

> 
> - For values of M3 procedure/C function pointer that are top-level
>   (nonnested) procedures/functions, M3 and C code (generated by gcc,
>   at least) are interchangeable.  This answers another of Jay's worries.
>   This will cover that great majority of cases.

Yes.  And in many cases, we will know statically that this is the case.

> 
> - Standard C has no nested functions.  Gcc adds them as a language
>   extension.  Thus, only in gcc-compiled C code do we need to worry
>   about nested procedures/functions between languages.  (Do any other
>   C compilers exist that also have nested functions?)

Standard C has no nested function, and does not need closures.  As a 
result, Standard C can use simple pointers to represent function 
addresses.  The language extension retrofits closures using run-time 
code generation.  The way this is done (on the satck) is nonportable, 
and we'd like to avoid that nonportability.

The problem with seems to be just that you seem to want to use an 
address of a function as a function pointer, and that just doesn't have 
enough space in it to represent a closure.

But why do it that way?  Why not just let *all* Modula 3 functions be 
represented by closures?  Then you never have to test whether something 
is a closure, it just always is.  Top-level functions with no 
environment just use a null pointer as environment -- and never use it.

The only arguments for not doing this would seem to be 
(a) the waste of space, making functions a little larger than necessary, 
(b) and C compatibility.

Now (a) is probably a nonissue, since the vast majority of functions 
never have their addresses taken, are never passes as parameters to 
other procedures, and so forth.  So for the vast majority of functions, 
you simply never have to build the closure.

(b) might be a problem. The obvious trick is just to forbid passing to C 
a non-top-level function.  Since even the C programmers who devise 
interfaces with callbacks realise that just a functino pointer isn't 
enough, they usually provide a machanism for passing a void pointer to 
additional information the callback might need.  Nothing here puts 
Modula 3 at a disadvantage relative to C.  You can just use a top-level 
function and let the programmer provide it with whatever it needs.

But if it is deemed essential to provide actual single-pointer callback 
addresses, this can be done by using a built-in function to convert a 
procedure to a single-pointer callback.  This functin will have to be 
rewritten for each platform, and can allocate the necessary 
dynamically-genereated code on the heap (or, of course, on the stack, if 
possible on that platform).  As for portability, it's certianly no 
big deal to do this;  compared with writing a platform-dependent code 
generator (itself a requirement), this is not huge.

> - M3's normal runtime check that precludes assigning a nonlocal
>   procedure value will not detect a C-code-produced nonlocal value,
>   thus the environment could indeed have disappeared if the programmer
>   was not careful.  However, gcc-extended C's nested functions have
>   no protection against this bug when only C code is involved, so
>   perhaps not detecting it in mixed M3/C is to be expected.

We really can't protect against bugs in C code.  If we could prevent 
bugs in C, the market for it would be huge, and we'd be well advised to 
consider that our main business.

> 
> - C code that attempts to call a function pointer value that was
>   originally produced by M3 code as a nested procedure value will
>   almost certainly crash at the time of the call.  This is the only
>   case that presents a significant problem.  M3 code will not be
>   able to give a nested procedure as a callback to a C library.

Wherefor only in this case should we do run-time code generation.

It has been argued that we don't need to protect against C programmers 
going hog-wild and breaking their own code.  Such is the nature of C.

But, we can chack for some of it, it we are willing to go to the effort.  
The technique used in the CDC Algol 68 compiler long ago might even 
enable us to restrict the constraint on assigning nested procedures to 
variables by a suitable run-time check.

The CDC Algol 68 compiler had a trick for recognising expired scopes 
using the garbage collector.  Let's see if I can remember the details.  
It involved special treatment for procedures whose addresses are taken, 
and for the blocks that contain them.  When entering such a block at 
run-time, a word is allocated on the heap representing that scope.   It 
is filled with something relevant, such as the address if the stack 
frame for the block, and the stack frame also pointed to that scope-cell 
(as I'll describe it).  Taking the  address of a procedure involved 
building a closure that points to that scope-cell.  When leaving the 
block, the contents of the scope-cell is wiped to some recognisable 
invalid value.  When entering the procedure the scope-cell will 
still be around even if the scope is not.  The procedure (this is inside 
the procedure itself, not at the call) checks that the scope-cell has 
not been wiped, and therefore is still valid.  If valid, it contains the 
necessary environment information.  If not, break off execution.

-- hendrik


From dabenavidesd at yahoo.es  Wed May 28 04:10:05 2008
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 28 May 2008 02:10:05 +0000 (GMT)
Subject: [M3devel] garbage collection problem on LINUXLIBC6?
In-Reply-To: <406663.93255.qm@web27103.mail.ukl.yahoo.com>
Message-ID: <540006.79045.qm@web27102.mail.ukl.yahoo.com>

Dear developers:
I have finally understood that the issue was related with the terminal emulator from which I launched the M3 executables. All M3 executables are fine and working well.
Thanks for your attention.

--- 24/5/08, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> wrote:
De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] garbage collection problem on LINUXLIBC6?
Para: m3devel at elegosoft.com
Fecha: s?bado, 24 mayo, 2008 12:29

Hi:
I recently have compiled the cm3 system with good results on a 2-core machine on LINUXLIBC6, kubuntu of 32 bits. It runs gui applications of cm3 with no problems at all.
I think maybe the issue is related with something about the operating system, or at least the machine, I didn't check this until now.

Thanks

--- 19/5/08, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> wrote:
De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] garbage collection problem on LINUXLIBC6?
Para: m3devel at elegosoft.com, "Randy Coleburn"
 <rcoleburn at scires.com>
Fecha: lunes, 19 mayo, 2008 12:02

Hi again:
and the process is using the cpu very much (using top command)

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 9758 daniel    20   0 33644 3836 2684 R 60.0  0.7   1:05.17 draw

Thanks in advance.


--- 19/5/08, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> wrote:
De: Daniel Alejandro
 Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] garbage collection problem on LINUXLIBC6?
Para: m3devel at elegosoft.com, "Randy Coleburn" <rcoleburn at scires.com>
Fecha: lunes, 19 mayo, 2008 11:52

Hi Randy:
In my case, the program just doesn't start, maybe after some minutes yes, but obviously this is abnormal.
When I start mentor @M3tracelinker, I got after a lot of output the following lines and it just doesn't start after it:
  ../src/color/Color.i3(3)
  ../src/runtime/common/RTHooks.i3(3)
RunMainBody: exec: ../src/color/ColorNameTable.i3(3)
RunMainBody: exec: ../src/color/ColorNameF.i3(3)
RunMainBody: exec:
 ../src/color/ColorNa

But if I put @M3nogc @M3tracelinker the program starts and the output is:
RunMainBody: ../LINUXLIBC6/MentorBundle.m3(2)
  ../LINUXLIBC6/MentorBundle.i3(5)
  ../src/rw/TextWr.i3(3)
  ../src/rw/Wr.i3(3)
 
 ../src/thread/Common/Thread.i3(3)
  ../src/text/Text.i3(3)
  ../src/bundleintf/BundleRep.i3(3)
  ../src/bundleintf/Bundle.i3(3)
 
 ../src/runtime/common/RTHooks.i3(3)
RunMainBody: exec: ../LINUXLIBC6/MentorBundle.m3(3)
RunMainBody: exec: ../LINUXLIBC6/MentorBundle.i3(3)
RunMainBody: exec: ../src/Main.m3(3)

However when examining a simple gui program, the stdout shows the same  out for @M3tracelinker with or without garbage collection

  ../src/split/TextVBT.i3(5)
  ../src/runtime/common/RTHooks.i3(3)
RunMainBody: exec: ../src/split/TextVBTClass.i3(3)
RunMainBody: exec: ../src/split/TextVBT.m3(3)
RunMainBody: exec: ../src/split/TextVBT.i3(3)
RunMainBody: exec: ../src/Draw.m3(3)

If I run the program under m3gdb without parametres, breaking on RTLinker.RunMainBody, I got:
Breakpoint 3, RunMainBody (m=16_b7e108c0)
    at ../src/runtime/common/RTLinker.m3:349
349       VAR desc, desc2: InitPtr;  imp: RT0.ImportPtr;  m2:
 RT0.ModulePtr;
(m3gdb)
Continuando.

Breakpoint 3, RunMainBody (m=16_b7e10ba0)
    at ../src/runtime/common/RTLinker.m3:349
349       VAR desc, desc2: InitPtr;  imp: RT0.ImportPtr;  m2: RT0.ModulePtr;
(m3gdb)
Continuando.

Breakpoint 3, RunMainBody (m=16_b7e0b660)
    at ../src/runtime/common/RTLinker.m3:349
349       VAR desc, desc2: InitPtr;  imp: RT0.ImportPtr;  m2: RT0.ModulePtr;
(m3gdb)
Continuando.


[Nuevo Thread -1234015344 (LWP 9706)]
[Thread -1234015344 (LWP 9706) exited]

And the program hangs there.
And again the same situation on the stack trace when killing the process inside m3gdb (also got a segment violation on m3gdb):

(m3gdb) where
#0  0xb7fbf410 in __kernel_vsyscall ()
#1  0xb7108ae7 in pthread_kill () from
 /lib/tls/i686/cmov/libpthread.so.0
#2  0xb737c397 in SignalThread (act=16_08055d88, state=Stopping)
    at ../src/thread/PTHREAD/ThreadPThread.m3:1058
#3  0xb737c6dc in StopWorld () at ../src/thread/PTHREAD/ThreadPThread.m3:1142
#4  0xb737b9e7 in SuspendOthers ()
    at ../src/thread/PTHREAD/ThreadPThread.m3:905
#5  0xb7355244 in CollectSomeInStateZero ()
    at ../src/runtime/common/RTCollector.m3:755
#6  0xb7355203 in CollectSome () at ../src/runtime/common/RTCollector.m3:729
#7  0xb7354c24 in CollectEnough () at ../src/runtime/common/RTCollector.m3:656
#8  0xb73586c1 in AllocTraced (def=16_b7dfbfb4, dataSize=456, dataAlignment=4,
    initProc=Static link does not lead to a valid frame.
) at ../src/runtime/common/RTCollector.m3:1462
#9  0xb734af25 in GetTracedObj (def=16_b7dfbfb4)
    at
 ../src/runtime/common/RTAllocator.m3:206
#10 0xb734a9b0 in AllocateTracedObj (defn=16_b7dfbfb4)
    at ../src/runtime/common/RTAllocator.m3:131
#11 0xb7d63df5 in Connect (inst=NIL, trsl=NIL) at ../src/xvbt/XClientF.m3:495
#12 0xb7d66717 in DoConnect (self=16_b6f41d5c, inst=NIL, localOnly=FALSE,
    t=NIL) at ../src/xvbt/XClientF.m3:637
#13 0xb7d46c23 in DoConnect (self=16_b6f41d5c, inst=NIL, localOnly=FALSE,
    t=NIL) at ../src/xvbt/XClient.m3:1495
#14 0xb7d9962c in Connect (inst=NIL, localOnly=FALSE)
---Type <return> to continue, or q <return> to quit---
    at ../src/vbt/TrestleClass.m3:30
#15 0xb7df2117 in Default () at ../src/trestle/Trestle.m3:838
#16 0xb7ded789 in PreAttach (v=16_b6f41cf8, trsl=NIL)
    at ../src/trestle/Trestle.m3:264
#17 0xb7deb95b in Install (v=16_b6f41cf8, applName=NIL, inst=NIL,
Fallo de
 segmentaci?n


Maybe could be some gcc backend issue?
I would like to know if others have the same problem.
Thanks.
  
--- 19/5/08, Randy Coleburn <rcoleburn at scires.com> wrote:
De: Randy Coleburn <rcoleburn at scires.com>
Asunto: Re: [M3devel] garbage collection problem on LINUXLIBC6?
Para: m3devel at elegosoft.com
Fecha: lunes, 19 mayo, 2008 10:08


 
Daniel, I have this same problem on GUI applications created on cm3 v4.1.  If I don't put "@M3novm" on the command line, the programs crash during startup.  It has something to do with the garbage collector.  In my testing of cm3 d5.7.0 on Windows XP, I have not run into the problem yet, so I think Tony has fixed it with his new garbage collector, at least on Windows.
Regards,
Randy

>>> "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> 5/18/2008 6:39 PM >>>




Dear developers:
I'm running a new installed cm3 on an ubuntu 8.04 32 bits, and I can't run anything with gui if I don't use @M3nogc
The rest of the applications, the compiler, and m3browser seem to work without problems ??
I'm debugging mentor but I just got this until now:
Breakpoint 5, Init () at ../src/color/ColorName.m3:207
207           IF table.put (NormalizeName (Basic [i].name), i) THEN
(m3gdb) where
#0  Init () at ../src/color/ColorName.m3:207
#1  0xb7c7b7ff in ColorName (mode=1) at ../src/color/ColorName.m3:214
#2  0xb70e2389 in RunMainBody (m=16_b7ca2fa0) at ../src/runtime/common/RTLinker.m3:399
#3  0xb70e2055 in RunMainBody (m=16_b7d38100) at ../src/runtime/common/RTLinker.m3:379
#4  0xb70e2055 in RunMainBody (m=16_b7d2fe20) at ../src/runtime/common/RTLinker.m3:379
#5  0xb70e2055 in RunMainBody (m=16_b7d34480) at
 ../src/runtime/common/RTLinker.m3:379
#6  0xb70e2055 in RunMainBody (m=16_b7d30d60) at ../src/runtime/common/RTLinker.m3:379
#7  0xb70e2055 in RunMainBody (m=16_b7d4d620) at ../src/runtime/common/RTLinker.m3:379
#8  0xb70e2055 in RunMainBody (m=16_b7e31d80) at ../src/runtime/common/RTLinker.m3:379
#9  0xb70e2055 in RunMainBody (m=16_b7e33220) at ../src/runtime/common/RTLinker.m3:379
#10 0xb70e2055 in RunMainBody (m=16_b7e36d40) at ../src/runtime/common/RTLinker.m3:379
#11 0xb70e2055 in RunMainBody (m=16_b7e364e0) at ../src/runtime/common/RTLinker.m3:379
#12 0xb70e2055 in RunMainBody (m=16_b7e36ba0) at ../src/runtime/common/RTLinker.m3:379
#13 0xb70e2055 in RunMainBody (m=16_b7e32cc0) at ../src/runtime/common/RTLinker.m3:379
#14 0xb70e2055 in RunMainBody (m=16_b7e32900) at ../src/runtime/common/RTLinker.m3:379
#15 0xb70e2055 in RunMainBody (m=16_08255600) at ../src/runtime/common/RTLinker.m3:379
#16
 0xb70e2055 in RunMainBody (m=16_08256040) at ../src/runtime/common/RTLinker.m3:379
#17 0xb70e2055 in RunMainBody (m=16_08312aa0) at ../src/runtime/common/RTLinker.m3:379
#18 0xb70e0dff in AddUnitI (m=16_08312aa0) at ../src/runtime/common/RTLinker.m3:113
#19 0xb70e0e8d in AddUnit (b={"Main_M3", Declared at: ../src/Main.m3:164}) at ../src/runtime/common/RTLinker.m3:122
#20 0x0806df1e in main (argc=3, argv=0xbfa03774, envp=0xbfa03784) at _m3main.mc:4
#21 0xb6d44450 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#22 0x0806de71 in _start ()
(m3gdb) cont
Continuando.

Breakpoint 5, Init () at ../src/color/ColorName.m3:207
207           IF table.put (NormalizeName (Basic [i].name), i) THEN
(m3gdb) cont
and the process hangs there when debugging mentor.

I have checked  Juno under m3gdb after have killed it and got:

(m3gdb) where
#0 
 0xb7fb0410 in __kernel_vsyscall ()
#1  0xb7018ae7 in pthread_kill () from /lib/tls/i686/cmov/libpthread.so.0
#2  0xb728c397 in SignalThread (act=16_0813c120, state=Stopping) at ../src/thread/PTHREAD/ThreadPThread.m3:1058
#3  0xb728c55e in StopWorld () at ../src/thread/PTHREAD/ThreadPThread.m3:1116
#4  0xb728b9e7 in SuspendOthers () at ../src/thread/PTHREAD/ThreadPThread.m3:905
#5  0xb7265244 in CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:755
#6  0xb7265203 in CollectSome () at ../src/runtime/common/RTCollector.m3:729
#7  0xb7264c24 in CollectEnough () at ../src/runtime/common/RTCollector.m3:656
#8  0xb72686c1 in AllocTraced (def=16_b7be1400, dataSize=12, dataAlignment=4, initProc=NIL)
    at ../src/runtime/common/RTCollector.m3:1462
#9  0xb725ad8f in GetTracedRef (def=16_b7be1400) at ../src/runtime/common/RTAllocator.m3:191
#10 0xb725a987
 in AllocateTracedRef (defn=16_b7be1400) at ../src/runtime/common/RTAllocator.m3:126
#11 0xb7b5d8fb in Put (tbl=16_b6e50438, key=8047, val=244) at ../LINUXLIBC6/IntIntTbl.m3 => ../src/table/Table.mg:127
#12 0xb7dd4e2c in Set (a='>', b='o', c=244, bothCases=FALSE, reversed=TRUE) at ../src/etext/KeyFilter.m3:288
#13 0xb7dd521c in Set (a='o', b='>', c=244, bothCases=FALSE, reversed=FALSE) at ../src/etext/KeyFilter.m3:304
#14 0xb7dd5882 in KeyFilter (mode=1) at ../src/etext/KeyFilter.m3:437
#15 0xb7273389 in RunMainBody (m=16_b7e51da0) at ../src/runtime/common/RTLinker.m3:399
#16 0xb7273055 in RunMainBody (m=16_b7e547e0) at ../src/runtime/common/RTLinker.m3:379
#17 0xb7273055 in RunMainBody (m=16_b7e56c00) at ../src/runtime/common/RTLinker.m3:379
#18 0xb7273055 in RunMainBody (m=16_b7e54240) at ../src/runtime/common/RTLinker.m3:379
#19 0xb7273055 in RunMainBody (m=16_b7e537e0) at
 ../src/runtime/common/RTLinker.m3:379
#20 0xb7273055 in RunMainBody (m=16_080b85a0) at ../src/runtime/common/RTLinker.m3:379
#21 0xb7271dff in AddUnitI (m=16_080b85a0) at ../src/runtime/common/RTLinker.m3:113
#22 0xb7271e8d in AddUnit (b={"Juno_M3", Declared at: ../src/Juno.m3:1974}) at ../src/runtime/common/RTLinker.m3:122
#23 0x0805120e in main (argc=1, argv=0xbf96ff14, envp=0xbf96ff1c) at _m3main.mc:4
#24 0xb6ed5450 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#25 0x08051161 in _start ()


When killing mentor under m3gdb it shows like the same back trace:
(m3gdb) where
#0  0xb70fb39a in SignalThread (act=16_0834ff08, state=Stopping) at ../src/thread/PTHREAD/ThreadPThread.m3:1058
#1  0xb70fb6dc in StopWorld () at ../src/thread/PTHREAD/ThreadPThread.m3:1142
#2  0xb70fa9e7 in SuspendOthers () at ../src/thread/PTHREAD/ThreadPThread.m3:905
#3  0xb70d4244 in CollectSomeInStateZero
 () at ../src/runtime/common/RTCollector.m3:755
#4  0xb70d4203 in CollectSome () at ../src/runtime/common/RTCollector.m3:729
#5  0xb70d3c24 in CollectEnough () at ../src/runtime/common/RTCollector.m3:656
#6  0xb70d76c1 in AllocTraced (def=16_b712d934, dataSize=24, dataAlignment=4, initProc=Static link does not lead to a valid frame.
)
    at ../src/runtime/common/RTCollector.m3:1462
#7  0xb70c9f25 in GetTracedObj (def=16_b712d934) at ../src/runtime/common/RTAllocator.m3:206
#8  0xb70c99b0 in AllocateTracedObj (defn=16_b712d934) at ../src/runtime/common/RTAllocator.m3:131
#9  0xb710d586 in New (a={'a','z','u','r','e','4'}) at ../src/text/Text8Short.m3:16
#10 0xb710ce87 in New (a={'a','z','u','r','e','4'}) at ../src/text/Text8.m3:18
#11 0xb710ba9d in FromChars (a={'a','z','u','r','e','4'}) at ../src/text/Text.m3:206
#12 0xb7c7a62f in NormalizeName (a=16_b7ca378c) at
 ../src/color/ColorName.m3:83
#13 0xb7c7b789 in Init () at ../src/color/ColorName.m3:207
#14 0xb7c7b7ff in ColorName (mode=1) at ../src/color/ColorName.m3:214
#15 0xb70e2389 in RunMainBody (m=16_b7ca2fa0) at ../src/runtime/common/RTLinker.m3:399
#16 0xb70e2055 in RunMainBody (m=16_b7d38100) at ../src/runtime/common/RTLinker.m3:379
#17 0xb70e2055 in RunMainBody (m=16_b7d2fe20) at ../src/runtime/common/RTLinker.m3:379
#18 0xb70e2055 in RunMainBody (m=16_b7d34480) at ../src/runtime/common/RTLinker.m3:379
#19 0xb70e2055 in RunMainBody (m=16_b7d30d60) at ../src/runtime/common/RTLinker.m3:379
#20 0xb70e2055 in RunMainBody (m=16_b7d4d620) at ../src/runtime/common/RTLinker.m3:379
#21 0xb70e2055 in RunMainBody (m=16_b7e31d80) at ../src/runtime/common/RTLinker.m3:379
#22 0xb70e2055 in RunMainBody (m=16_b7e33220) at ../src/runtime/common/RTLinker.m3:379
#23 0xb70e2055 in RunMainBody (m=16_b7e36d40) at
 ../src/runtime/common/RTLinker.m3:379
#24 0xb70e2055 in RunMainBody (m=16_b7e364e0) at ../src/runtime/common/RTLinker.m3:379
#25 0xb70e2055 in RunMainBody (m=16_b7e36ba0) at ../src/runtime/common/RTLinker.m3:379
#26 0xb70e2055 in RunMainBody (m=16_b7e32cc0) at ../src/runtime/common/RTLinker.m3:379
#27 0xb70e2055 in RunMainBody (m=16_b7e32900) at ../src/runtime/common/RTLinker.m3:379
#28 0xb70e2055 in RunMainBody (m=16_08255600) at ../src/runtime/common/RTLinker.m3:379
#29 0xb70e2055 in RunMainBody (m=16_08256040) at ../src/runtime/common/RTLinker.m3:379
#30 0xb70e2055 in RunMainBody (m=16_08312aa0) at ../src/runtime/common/RTLinker.m3:379
#31 0xb70e0dff in AddUnitI (m=16_08312aa0) at ../src/runtime/common/RTLinker.m3:113
#32 0xb70e0e8d in AddUnit (b={"Main_M3", Declared at: ../src/Main.m3:164}) at ../src/runtime/common/RTLinker.m3:122
#33 0x0806df1e in main (argc=3, argv=0xbfa03774, envp=0xbfa03784) at _m3main.mc:4
#34
 0xb6d44450 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#35 0x0806de71 in _start ()

Thanks in advance




Enviado desde Correo Yahoo!
La bandeja de entrada m?s inteligente.








      
Enviado desde Correo Yahoo!
La bandeja de entrada m?s inteligente.









      
Enviado desde Correo Yahoo!
La bandeja de entrada m?s inteligente.









      
Enviado desde Correo Yahoo!
La bandeja de entrada m?s inteligente.



      ______________________________________________ 
Enviado desde Correo Yahoo! La bandeja de entrada m?s inteligente.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Wed May 28 06:26:10 2008
From: jayk123 at hotmail.com (Jay)
Date: Wed, 28 May 2008 04:26:10 +0000
Subject: [M3devel] function pointers and comparison to nil?
	mis-typed	function pointers?
In-Reply-To: <20080527154551.GA24415@topoi.pooq.com>
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
	<20080527154551.GA24415@topoi.pooq.com>
Message-ID: 

> The CDC Algol 68 compiler had a trick for recognising expired scopes 
Hendrik -- but then again there is that heap allocation cost..
 
This is also a step toward, like, heap allocated stack frames, except the garbage collected heap is only being used for its "lifetime features" and not its ability to store anything (other than lifetime/liveness).
 
As I understand..and this is maybe crazy...a straightforward Scheme implementation -- with no static analysis -- and "Stackless Python" take that next step -- all frames are heap allocated and garbage collected, and therefore a pointer to a nested function can outlive its original context. Neat but seems expensive. Perhaps can be fast enough.
I like the canonical Scheme example:
 
  (define make-adder (x) (lamba (y) (+ x y)))  
  (define add5 (make-adder 5))  
  (add5 3)  
 
  => 8  
 
implies make-adder's frame that contains "5" is heap allocated and then "add5" is a heap allocated chunk that contains merely that pointer and a pointer to the nexted function.
 
 > procedure to a single-pointer callback. This functin will have to be   > rewritten for each platform, and can allocate the necessary   > dynamically-genereated code on the heap (or, of course, on the stack, if   > possible on that platform). As for portability, it's certianly no  
I think it's easy enough to generate the code, the problem is where to put it.
Stack is not necessarily executable, heap is more expensive to allocate.
But in this forum I'm always contradicted on that last point, so it could just be in the heap.
Note that the heap isn't necessarily executable either.
 
I don't think breaking the existing compatibility with C function pointers is good.
In fact, I dare suggest that C interop should be aided by the Modula-3 compiler generating "headers" for C.
Really just a possible part of any "C backend". :)
 
If the type system is strong enough..having two separate types for C function pointers and Modula-3 function pointers might be viable. But you'd have to review all the "loopholes". Again probably a losing effort.
 
As I've said a few times, I'm fairly content to leave this all alone. Maybe just to research "reliable" markers that cannot now or ever be confused for "real code". It's hard to make such a guarantee what with processors always evolving and gaining new instructions. If the constant could be dynamic, it could be an absolute reference to a particular reserved symbol. If you manage to call it incorrectly, that symbol would be a real function and raise an exception. This a) depends on their being a suitable addressing mode, ie: not PC-relative and allowing for large enough constants (possibly multiple instructions..big, wasteful) b) makes the check for the signature much more expensive since it'd have to read memory another time c) likewise for the formation of the closures. Could be that part of the signature is constant and part dynamic.
 
Another idea would be to have a static check post-link run through all the code and verify the marker doesn't appear at the start of any function, if there is sufficient ability to read the code that way.
 
Anyway, it's probably all fairly moot.
Just need to disassemble -1 on every platform now and every so often, to "lazily" "ensure" it is not valid code.
 
Had I not hit the alignment fault I never would have discovered this stuff and we wouldn't be talking too much about it... :)
 
 - Jay



> Date: Tue, 27 May 2008 11:45:51 -0400> From: hendrik at topoi.pooq.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?> > On Sun, May 25, 2008 at 10:50:15PM -0500, Rodney M. Bates wrote:> > I think I can shed some light on this, having spent some time making> > m3gdb handle the various operations on nested procedures. As for code> > that mixes M3 and C, I believe the following are true:> > > > - Within M3 code only, the closure system works correctly in all cases.> > This answers one of Jay's worries.> > As long as procedure-entry code can be guaranteed never to start wit a > word of one-bits. We do have some influence on this code, though, and > if necessary might be able to choose a different bit pattern on a > specific platform.> > > > > - For values of M3 procedure/C function pointer that are top-level> > (nonnested) procedures/functions, M3 and C code (generated by gcc,> > at least) are interchangeable. This answers another of Jay's worries.> > This will cover that great majority of cases.> > Yes. And in many cases, we will know statically that this is the case.> > > > > - Standard C has no nested functions. Gcc adds them as a language> > extension. Thus, only in gcc-compiled C code do we need to worry> > about nested procedures/functions between languages. (Do any other> > C compilers exist that also have nested functions?)> > Standard C has no nested function, and does not need closures. As a > result, Standard C can use simple pointers to represent function > addresses. The language extension retrofits closures using run-time > code generation. The way this is done (on the satck) is nonportable, > and we'd like to avoid that nonportability.> > The problem with seems to be just that you seem to want to use an > address of a function as a function pointer, and that just doesn't have > enough space in it to represent a closure.> > But why do it that way? Why not just let *all* Modula 3 functions be > represented by closures? Then you never have to test whether something > is a closure, it just always is. Top-level functions with no > environment just use a null pointer as environment -- and never use it.> > The only arguments for not doing this would seem to be > (a) the waste of space, making functions a little larger than necessary, > (b) and C compatibility.> > Now (a) is probably a nonissue, since the vast majority of functions > never have their addresses taken, are never passes as parameters to > other procedures, and so forth. So for the vast majority of functions, > you simply never have to build the closure.> > (b) might be a problem. The obvious trick is just to forbid passing to C > a non-top-level function. Since even the C programmers who devise > interfaces with callbacks realise that just a functino pointer isn't > enough, they usually provide a machanism for passing a void pointer to > additional information the callback might need. Nothing here puts > Modula 3 at a disadvantage relative to C. You can just use a top-level > function and let the programmer provide it with whatever it needs.> > But if it is deemed essential to provide actual single-pointer callback > addresses, this can be done by using a built-in function to convert a > procedure to a single-pointer callback. This functin will have to be > rewritten for each platform, and can allocate the necessary > dynamically-genereated code on the heap (or, of course, on the stack, if > possible on that platform). As for portability, it's certianly no > big deal to do this; compared with writing a platform-dependent code > generator (itself a requirement), this is not huge.> > > - M3's normal runtime check that precludes assigning a nonlocal> > procedure value will not detect a C-code-produced nonlocal value,> > thus the environment could indeed have disappeared if the programmer> > was not careful. However, gcc-extended C's nested functions have> > no protection against this bug when only C code is involved, so> > perhaps not detecting it in mixed M3/C is to be expected.> > We really can't protect against bugs in C code. If we could prevent > bugs in C, the market for it would be huge, and we'd be well advised to > consider that our main business.> > > > > - C code that attempts to call a function pointer value that was> > originally produced by M3 code as a nested procedure value will> > almost certainly crash at the time of the call. This is the only> > case that presents a significant problem. M3 code will not be> > able to give a nested procedure as a callback to a C library.> > Wherefor only in this case should we do run-time code generation.> > It has been argued that we don't need to protect against C programmers > going hog-wild and breaking their own code. Such is the nature of C.> > But, we can chack for some of it, it we are willing to go to the effort. > The technique used in the CDC Algol 68 compiler long ago might even > enable us to restrict the constraint on assigning nested procedures to > variables by a suitable run-time check.> > The CDC Algol 68 compiler had a trick for recognising expired scopes > using the garbage collector. Let's see if I can remember the details. > It involved special treatment for procedures whose addresses are taken, > and for the blocks that contain them. When entering such a block at > run-time, a word is allocated on the heap representing that scope. It > is filled with something relevant, such as the address if the stack > frame for the block, and the stack frame also pointed to that scope-cell > (as I'll describe it). Taking the address of a procedure involved > building a closure that points to that scope-cell. When leaving the > block, the contents of the scope-cell is wiped to some recognisable > invalid value. When entering the procedure the scope-cell will > still be around even if the scope is not. The procedure (this is inside > the procedure itself, not at the call) checks that the scope-cell has > not been wiped, and therefore is still valid. If valid, it contains the > necessary environment information. If not, break off execution.> > -- hendrik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From hendrik at topoi.pooq.com  Wed May 28 08:14:24 2008
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Wed, 28 May 2008 02:14:24 -0400
Subject: [M3devel] function pointers and comparison to nil?
	mis-typed	function pointers?
In-Reply-To: 
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
	<20080527154551.GA24415@topoi.pooq.com>
	
Message-ID: <20080528061424.GA25708@topoi.pooq.com>

On Wed, May 28, 2008 at 04:26:10AM +0000, Jay wrote:
> > The CDC Algol 68 compiler had a trick for recognising expired scopes 
> Hendrik -- but then again there is that heap allocation cost..

But only for the blocks closest-containing procedures whose addresses 
are taken.  That is relatively rare, and it will not cause heap allocation 
for anyone that does not take addresses of nested procedures.
>  
> This is also a step toward, like, heap allocated stack frames, except 
> the garbage collected heap is only being used for its "lifetime 
> features" and not its ability to store anything (other than 
> lifetime/liveness).
>  
> As I understand..and this is maybe crazy...a straightforward Scheme implementation -- with no static analysis -- and "Stackless Python" take that next step -- all frames are heap allocated and garbage collected, and therefore a pointer to a nested function can outlive its original context. Neat but seems expensive. Perhaps can be fast enough.
> I like the canonical Scheme example:
>  
>   (define make-adder (x) (lamba (y) (+ x y)))  
>   (define add5 (make-adder 5))  
>   (add5 3)  
>  
>   => 8  
>  
> implies make-adder's frame that contains "5" is heap allocated and then "add5" is a heap allocated chunk that contains merely that pointer and a pointer to the nexted function.
>  
>  > procedure to a single-pointer callback. This functin will have to be   > rewritten for each platform, and can allocate the necessary   > dynamically-genereated code on the heap (or, of course, on the stack, if   > possible on that platform). As for portability, it's certianly no  

> I think it's easy enough to generate the code, the problem is where to put it.
> Stack is not necessarily executable, heap is more expensive to allocate.
> But in this forum I'm always contradicted on that last point, so it could just be in the heap.
> Note that the heap isn't necessarily executable either.

Id you can't write into dynamically-allocated code space, you may as 
well forget about JIT compilers.  Well, I suppose there could be 
machines that can't have JIT compilers.
 
Actually, if you're talking to C, you should be able to follow the 
same restrictions that C uses.

>  
> I don't think breaking the existing compatibility with C function 
> pointers is good.

Until this discussion started, I never dreamed there was any 
compatibility with C functino pointers except for non-nested procedures.  
This all came as a surprise to me.

> In fact, I dare suggest that C interop should be aided by the Modula-3 
> compiler generating "headers" for C.
> Really just a possible part of any "C backend". :)
>  
> If the type system is strong enough..having two separate types for C 
> function pointers and Modula-3 function pointers might be viable. But 
> you'd have to review all the "loopholes". Again probably a losing 
> effort.

Just like C strings and Modula 3 strings?

>  
> As I've said a few times, I'm fairly content to leave this all alone. 

I, too.  But I thought it ws worth pointing out that there is a 
conceptually clean solution, especially since conceptually clean 
practicality is one of Modula 3's hallmarks.

-- hendrik


From jayk123 at hotmail.com  Wed May 28 09:04:58 2008
From: jayk123 at hotmail.com (Jay)
Date: Wed, 28 May 2008 07:04:58 +0000
Subject: [M3devel] function pointers and comparison to
	nil?	mis-typed	function pointers?
In-Reply-To: <20080528061424.GA25708@topoi.pooq.com>
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
	<20080527154551.GA24415@topoi.pooq.com>
	 
	<20080528061424.GA25708@topoi.pooq.com>
Message-ID: 

> Id you can't write into dynamically-allocated code space, you may as > well forget about JIT compilers. Well, I suppose there could be > machines that can't have JIT compilers.
Those systems are slow.....AND this "proposal" (exaggeration!) as I understand equates to a heap alloc per function call for CERTAIN RARE function calls, or perhaps more fine grained, per taking-address-of-nested functions.
 
These slow systems with JITs don't usually JIT "that often".
They JIT like at one of:
   module load 
   first time a function is called  
   first time a block is entered 
 
but not for subsequent loads/runs, at least not with the same process or "app domain".
 
> Until this discussion started, I never dreamed there was any > compatibility with C functino pointers except for non-nested procedures. > This all came as a surprise to me.
That is all there is. You cannot pass a closure pointer off to C code as a function pointer.
You CAN pass gcc nested C functions off as such however.
Opposing forces -- closures as dynamically sniffed pair of pointers vs. closures as dynamically generated code.
Ok, also nested functions that don't happen to use their parent frames' locals probably interop.
 
Ok, probably I should go and implement the *option* cm3cg -trampolines and m3 -trampolines or somesuch.
 
I guess a pragma <* trampoline *> or <* c function pointer *> to let source ask for it, but that's getting ahead of things, it's "experimental" and probably just not desirable, but maybe just interesting to get working...
 
 - Jay



> Date: Wed, 28 May 2008 02:14:24 -0400> From: hendrik at topoi.pooq.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?> > On Wed, May 28, 2008 at 04:26:10AM +0000, Jay wrote:> > > The CDC Algol 68 compiler had a trick for recognising expired scopes > > Hendrik -- but then again there is that heap allocation cost..> > But only for the blocks closest-containing procedures whose addresses > are taken. That is relatively rare, and it will not cause heap allocation > for anyone that does not take addresses of nested procedures.> > > > This is also a step toward, like, heap allocated stack frames, except > > the garbage collected heap is only being used for its "lifetime > > features" and not its ability to store anything (other than > > lifetime/liveness).> > > > As I understand..and this is maybe crazy...a straightforward Scheme implementation -- with no static analysis -- and "Stackless Python" take that next step -- all frames are heap allocated and garbage collected, and therefore a pointer to a nested function can outlive its original context. Neat but seems expensive. Perhaps can be fast enough.> > I like the canonical Scheme example:> > > > (define make-adder (x) (lamba (y) (+ x y))) > > (define add5 (make-adder 5)) > > (add5 3) > > > > => 8 > > > > implies make-adder's frame that contains "5" is heap allocated and then "add5" is a heap allocated chunk that contains merely that pointer and a pointer to the nexted function.> > > > > procedure to a single-pointer callback. This functin will have to be > rewritten for each platform, and can allocate the necessary > dynamically-genereated code on the heap (or, of course, on the stack, if > possible on that platform). As for portability, it's certianly no > > > I think it's easy enough to generate the code, the problem is where to put it.> > Stack is not necessarily executable, heap is more expensive to allocate.> > But in this forum I'm always contradicted on that last point, so it could just be in the heap.> > Note that the heap isn't necessarily executable either.> > Id you can't write into dynamically-allocated code space, you may as > well forget about JIT compilers. Well, I suppose there could be > machines that can't have JIT compilers.> > Actually, if you're talking to C, you should be able to follow the > same restrictions that C uses.> > > > > I don't think breaking the existing compatibility with C function > > pointers is good.> > Until this discussion started, I never dreamed there was any > compatibility with C functino pointers except for non-nested procedures. > This all came as a surprise to me.> > > In fact, I dare suggest that C interop should be aided by the Modula-3 > > compiler generating "headers" for C.> > Really just a possible part of any "C backend". :)> > > > If the type system is strong enough..having two separate types for C > > function pointers and Modula-3 function pointers might be viable. But > > you'd have to review all the "loopholes". Again probably a losing > > effort.> > Just like C strings and Modula 3 strings?> > > > > As I've said a few times, I'm fairly content to leave this all alone. > > I, too. But I thought it ws worth pointing out that there is a > conceptually clean solution, especially since conceptually clean > practicality is one of Modula 3's hallmarks.> > -- hendrik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From ronny.forberger at elegosoft.com  Wed May 28 11:52:29 2008
From: ronny.forberger at elegosoft.com (Ronny Forberger)
Date: Wed, 28 May 2008 11:52:29 +0200
Subject: [M3devel] FW: NT386 environment variables (new NT386	snapshots)
In-Reply-To: <20080527155926.203bam89w4w0kgko@mail.elegosoft.com>
References: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
	
	<4823279D.1E75.00D7.1@scires.com>
	
	<20080527155926.203bam89w4w0kgko@mail.elegosoft.com>
Message-ID: <20080528115229.yjpegnw34ow4g0o8@mail.elegosoft.com>

--
Message from: Olaf Wagner 
Date: Di 27 Mai 2008 15:59:26 CEST
Subject: Re: [M3devel] FW: NT386 environment variables (new NT386 snapshots)


> Quoting Jay :
>
>> truncated again...
>> m3support -- nothing interesting in any logs regarding my mail?
>> And nobody else uses hotmail, right?
>
> @Ronny, can you please check if our mail logs reveal any reason
> for Jay's mails to be truncated now and then?

The logs don't say anything about it. But it might be that this  
happens when mailman converts HTML-only messages to plain text, which  
is common behavior on mailing lists.

Jay, if your messages are HTML-only, you perhaps could try sending  
plain text only messages to the lists and check again.

[...]

Regards,

Ronny

-- 
Ronny Forberger
IT Services & Support

elego Software Solutions GmbH
Gustav-Meyer-Allee 25
Building 12.3 (BIG) room 227
13355 Berlin, Germany

phone +49 30 23 45 86 96      ronny.forberger at elegosoft.com
fax   +49 30 23 45 86 95      http://www.elegosoft.com

Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin
Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194



From hendrik at topoi.pooq.com  Wed May 28 14:00:30 2008
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Wed, 28 May 2008 08:00:30 -0400
Subject: [M3devel] function pointers and comparison to
	nil?	mis-typed	function pointers?
In-Reply-To: 
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
	<20080527154551.GA24415@topoi.pooq.com>
	
	<20080528061424.GA25708@topoi.pooq.com>
	
Message-ID: <20080528120030.GA26129@topoi.pooq.com>

On Wed, May 28, 2008 at 07:04:58AM +0000, Jay wrote:
> > Id you can't write into dynamically-allocated code space, you may as > well forget about JIT compilers. Well, I suppose there could be > machines that can't have JIT compilers.
> Those systems are slow.....AND this "proposal" (exaggeration!) as I understand equates to a heap alloc per function call for CERTAIN RARE function calls, or perhaps more fine grained, per taking-address-of-nested functions.
>  
> These slow systems with JITs don't usually JIT "that often".
> They JIT like at one of:
>    module load 
>    first time a function is called  
>    first time a block is entered 
>  
> but not for subsequent loads/runs, at least not with the same process or "app domain".
>  
> > Until this discussion started, I never dreamed there was any
> > compatibility with C functino pointers except for non-nested 
> > procedures.
> > This all came as a surprise to me.

> That is all there is. You cannot pass a closure pointer off to C code 
> as a function pointer.

So the only programs that will be affected by the heap allocation to 
convert Modula 3 closures to C closures are programs which are currently 
illegal.  This makes it effectively have zero cost for existing code.

> You CAN pass gcc nested C functions off as such however.

Thus eventually we can expect to have to interface with libraries that 
expect nested C functino closures and don't pass an extra void pointer 
for environment.

> Opposing forces -- closures as dynamically sniffed pair of pointers 
> vs. closures as dynamically generated code.
> Ok, also nested functions that don't happen to use their parent 
> frames' locals probably interop.

I fact, everywhere we talk about the syntactically enclosing block, we 
should be talking about the most local enclosing block that declares 
names used in the function.

>  
> Ok, probably I should go and implement the *option* cm3cg -trampolines 
> and m3 -trampolines or somesuch.
>  
> I guess a pragma <* trampoline *> or <* c function pointer *> to let 
> source ask for it, but that's getting ahead of things, it's 
> "experimental" and probably just not desirable, but maybe just 
> interesting to get working...
>  
>  - Jay


From wagner at elegosoft.com  Thu May 29 15:02:09 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Thu, 29 May 2008 15:02:09 +0200
Subject: [M3devel] _lowbits / _highbits (Pixmap bug-- 4.1 vs. buggy	5.x)
In-Reply-To: 
References: 
	
Message-ID: <20080529150209.vnhlgwbjcog4wc04@mail.elegosoft.com>

Quoting Jay :

> 1) Just fyi, NT386GNU didn't build with my fix, so it is disabled   
> there only, and the bug could very well be present there.
> Er, then again, this stuff works differently for the gcc backend, so  
>  I don't know, I'll have to look, and run the tests, not today.
> Which reminds me also, these symbols should be static hand.c, except  
>  for NT386 -- the source can't tell, so it'll have to be a define   
> from the m3makefile.
>
> 2) Can anyone confirm my history and the missing source?
> ie: Confirm that what is marked as 4.1 and 5.1 in CVS really is 4.1   
> and 5.1? I don't think 4.1 is accurately marked.
> In particular, I don't think the 4.1 Stackx86.m3  is what 4.1   
> actually shipped.
>
> 3) Or confirm my analysis that leads to the "accusation"? It was tedious.

I don't think that a complete 4.1 code set was ever imported into
the CVS CM3 repository; at least I don't remember we got the complete
4.1 code from Farshad Nayeri. What we got was 5.1 and it wasn't even
compilable by any existing M3 compiler. The gcc backend was so old
that it wasn't usable on any system we had. I think we extensively used
PM3 for booting and even incorporated some of PM3's code where
necessary.

I remember that I had several evaluation CDs from CM3 some years before
the open source release, so it may be that contents from one of these
CDs were imported as 4.1. I'm afraid it is not really traceable now.
We never got any versioned code from Critical Mass (I don't know what
they used for version control), only the bare source code.

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 rcoleburn at scires.com  Thu May 29 18:31:14 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Thu, 29 May 2008 12:31:14 -0400
Subject: [M3devel] _lowbits / _highbits (Pixmap bug-- 4.1 vs.	buggy	5.x)
In-Reply-To: <20080529150209.vnhlgwbjcog4wc04@mail.elegosoft.com>
References: 
	
	<20080529150209.vnhlgwbjcog4wc04@mail.elegosoft.com>
Message-ID: <483EA20A.1E75.00D7.1@scires.com>

Olaf / Jay:
 
My Reactor v4.1 CD has a source directory, but this folder does not
contain the sources for the compiler or Reactor, just the libraries et
al.
 
Here is a list of the archives in that folder:
 
BINUTILS.TGZ
m3-comm.TGZ
m3-db.TGZ
M3-DEMO.TGZ
M3-GAMES.TGZ
M3-LCTRN.TGZ
m3-libs.TGZ
M3-MAIL.TGZ
M3-OBLIQ.TGZ
M3-PKGTL.TGZ
M3-TOOLS.TGZ
m3-ui.TGZ
m3-www.TGZ
M3CC.TGZ
M3GDB.TGZ
 
There is also a CONTRIB folder with the following:
 
CVSUP
IDLM3
M2TOM3
M3DDD
M3PC
M3TOMIF
SRC-M3
 
If Farshad is ok with it, I can send you these files, but I would need
his approval because we licensed this product from Critical Mass.
 
On a side note, I just built a new laptop computer from a fresh install
of XP Pro.  I got the latest cm3 from the repository and rebuilt
everything.  On this platform, my pixmaps show up with a "yellow" color
everywhere "white" would normally show.  This is strange behavior.  I
checked the .lst file and it is showing as a GUI program and the
"hand.obj" is included.  Any ideas?
 
Since Jay has made good progress on fixing some of my major gripes, I
am trying to use the new (current) cm3 for my project that is due for
delivery at the end of July.  The new garbage collector seems to work
much better on Windows than the one from 4.1.  Since we don't have an
official stable release right now, I am going to have to draw a line in
the sand at some point soon and take a snapshot of the cm3 source tree
as the "official" development environment for future support of my
project deliverables.
 
This latest problem with pixmaps on one platform and with CM3IDE on all
XP platforms I've tested so far is disturbing.  As soon as I can get a
handle on these problems, I think I am going to freeze my development
environment for this project unless someone comes up with a major
fix/change.
 
Regards,
Randy

>>> Olaf Wagner  5/29/2008 9:02 AM >>>
Quoting Jay :

> 1) Just fyi, NT386GNU didn't build with my fix, so it is disabled   
> there only, and the bug could very well be present there.
> Er, then again, this stuff works differently for the gcc backend, so 

>  I don't know, I'll have to look, and run the tests, not today.
> Which reminds me also, these symbols should be static hand.c, except 

>  for NT386 -- the source can't tell, so it'll have to be a define   
> from the m3makefile.
>
> 2) Can anyone confirm my history and the missing source?
> ie: Confirm that what is marked as 4.1 and 5.1 in CVS really is 4.1  

> and 5.1? I don't think 4.1 is accurately marked.
> In particular, I don't think the 4.1 Stackx86.m3  is what 4.1   
> actually shipped.
>
> 3) Or confirm my analysis that leads to the "accusation"? It was
tedious.

I don't think that a complete 4.1 code set was ever imported into
the CVS CM3 repository; at least I don't remember we got the complete
4.1 code from Farshad Nayeri. What we got was 5.1 and it wasn't even
compilable by any existing M3 compiler. The gcc backend was so old
that it wasn't usable on any system we had. I think we extensively
used
PM3 for booting and even incorporated some of PM3's code where
necessary.

I remember that I had several evaluation CDs from CM3 some years
before
the open source release, so it may be that contents from one of these
CDs were imported as 4.1. I'm afraid it is not really traceable now.
We never got any versioned code from Critical Mass (I don't know what
they used for version control), only the bare source code.

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 mika at async.caltech.edu  Thu May 29 20:53:01 2008
From: mika at async.caltech.edu (Mika Nystrom)
Date: Thu, 29 May 2008 11:53:01 -0700
Subject: [M3devel] _lowbits / _highbits (Pixmap bug-- 4.1 vs. buggy 5.x)
In-Reply-To: Your message of "Thu, 29 May 2008 12:31:14 EDT."
	<483EA20A.1E75.00D7.1@scires.com> 
Message-ID: <200805291853.m4TIr1FF079831@camembert.async.caltech.edu>

"Randy Coleburn" writes:
...
>On a side note, I just built a new laptop computer from a fresh install
>of XP Pro.  I got the latest cm3 from the repository and rebuilt
>everything.  On this platform, my pixmaps show up with a "yellow" color
>everywhere "white" would normally show.  This is strange behavior.  I
>checked the .lst file and it is showing as a GUI program and the
>"hand.obj" is included.  Any ideas?
...

Not sure if this is related, but "xv" does exactly this for me when
running under VNC, at least with certain combinations of color depths.
No Modula-3 involved.  This is when I am accessing a FreeBSD VNC server
remotely from RealVNC on win2k as well as win XP.  Never quite figured
out why it happens.

    Mika


From jayk123 at hotmail.com  Thu May 29 21:07:40 2008
From: jayk123 at hotmail.com (Jay)
Date: Thu, 29 May 2008 19:07:40 +0000
Subject: [M3devel] _lowbits / _highbits (Pixmap bug-- 4.1 vs.	buggy	5.x)
In-Reply-To: <483EA20A.1E75.00D7.1@scires.com>
References: 
	
	<20080529150209.vnhlgwbjcog4wc04@mail.elegosoft.com> 
	<483EA20A.1E75.00D7.1@scires.com>
Message-ID: 

I have the 4.1 CD. I bought it from Critical Mass the normal legitimate way. I hacked my cm3.exe the other day to skip the license check since I can't find my key, it's very easy to do.
My observations agree with yours -- no source on the CD to the compiler, contrib includes the DEC 3.6 code.
 
What are the CM3IDE problems?
 
What is the pixmap behavior with build_standalone()?
I'm inclined to think this is not a Modula-3 problem but hard to debug remotely like this..
 
 - Jay


Date: Thu, 29 May 2008 12:31:14 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] _lowbits / _highbits (Pixmap bug-- 4.1 vs. buggy 5.x)

Olaf / Jay:
 
My Reactor v4.1 CD has a source directory, but this folder does not contain the sources for the compiler or Reactor, just the libraries et al.
 
Here is a list of the archives in that folder:
 
BINUTILS.TGZm3-comm.TGZm3-db.TGZM3-DEMO.TGZM3-GAMES.TGZM3-LCTRN.TGZm3-libs.TGZM3-MAIL.TGZM3-OBLIQ.TGZM3-PKGTL.TGZM3-TOOLS.TGZm3-ui.TGZm3-www.TGZM3CC.TGZM3GDB.TGZ
 
There is also a CONTRIB folder with the following:
 
CVSUPIDLM3M2TOM3M3DDDM3PCM3TOMIFSRC-M3
 
If Farshad is ok with it, I can send you these files, but I would need his approval because we licensed this product from Critical Mass.
 
On a side note, I just built a new laptop computer from a fresh install of XP Pro.  I got the latest cm3 from the repository and rebuilt everything.  On this platform, my pixmaps show up with a "yellow" color everywhere "white" would normally show.  This is strange behavior.  I checked the .lst file and it is showing as a GUI program and the "hand.obj" is included.  Any ideas?
 
Since Jay has made good progress on fixing some of my major gripes, I am trying to use the new (current) cm3 for my project that is due for delivery at the end of July.  The new garbage collector seems to work much better on Windows than the one from 4.1.  Since we don't have an official stable release right now, I am going to have to draw a line in the sand at some point soon and take a snapshot of the cm3 source tree as the "official" development environment for future support of my project deliverables.
 
This latest problem with pixmaps on one platform and with CM3IDE on all XP platforms I've tested so far is disturbing.  As soon as I can get a handle on these problems, I think I am going to freeze my development environment for this project unless someone comes up with a major fix/change.
 
Regards,
Randy>>> Olaf Wagner  5/29/2008 9:02 AM >>>Quoting Jay :> 1) Just fyi, NT386GNU didn't build with my fix, so it is disabled   > there only, and the bug could very well be present there.> Er, then again, this stuff works differently for the gcc backend, so  >  I don't know, I'll have to look, and run the tests, not today.> Which reminds me also, these symbols should be static hand.c, except  >  for NT386 -- the source can't tell, so it'll have to be a define   > from the m3makefile.>> 2) Can anyone confirm my history and the missing source?> ie: Confirm that what is marked as 4.1 and 5.1 in CVS really is 4.1   > and 5.1? I don't think 4.1 is accurately marked.> In particular, I don't think the 4.1 Stackx86.m3  is what 4.1   > actually shipped.>> 3) Or confirm my analysis that leads to the "accusation"? It was tedious.I don't think that a complete 4.1 code set was ever imported intothe CVS CM3 repository; at least I don't remember we got the complete4.1 code from Farshad Nayeri. What we got was 5.1 and it wasn't evencompilable by any existing M3 compiler. The gcc backend was so oldthat it wasn't usable on any system we had. I think we extensively usedPM3 for booting and even incorporated some of PM3's code wherenecessary.I remember that I had several evaluation CDs from CM3 some years beforethe open source release, so it may be that contents from one of theseCDs were imported as 4.1. I'm afraid it is not really traceable now.We never got any versioned code from Critical Mass (I don't know whatthey used for version control), only the bare source code.Olaf-- Olaf Wagner -- elego Software Solutions GmbH                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germanyphone: +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: BerlinHandelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Thu May 29 21:41:45 2008
From: jayk123 at hotmail.com (Jay)
Date: Thu, 29 May 2008 19:41:45 +0000
Subject: [M3devel] _lowbits / _highbits (Pixmap bug-- 4.1 vs. buggy	5.x)
In-Reply-To: <20080529150209.vnhlgwbjcog4wc04@mail.elegosoft.com>
References: 
	 
	<20080529150209.vnhlgwbjcog4wc04@mail.elegosoft.com>
Message-ID: 

Ok, I stand by my earlier analysis, though I forget what it was. :)
Partly that the "4.1" source in CVS is not 4.1, so understanding how it worked can't be done from source. Though I guess I could read the assembly if we really need to know..
 
Thanks,
 - Jay



> Date: Thu, 29 May 2008 15:02:09 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] _lowbits / _highbits (Pixmap bug-- 4.1 vs. buggy 5.x)> > Quoting Jay :> > > 1) Just fyi, NT386GNU didn't build with my fix, so it is disabled > > there only, and the bug could very well be present there.> > Er, then again, this stuff works differently for the gcc backend, so > > I don't know, I'll have to look, and run the tests, not today.> > Which reminds me also, these symbols should be static hand.c, except > > for NT386 -- the source can't tell, so it'll have to be a define > > from the m3makefile.> >> > 2) Can anyone confirm my history and the missing source?> > ie: Confirm that what is marked as 4.1 and 5.1 in CVS really is 4.1 > > and 5.1? I don't think 4.1 is accurately marked.> > In particular, I don't think the 4.1 Stackx86.m3 is what 4.1 > > actually shipped.> >> > 3) Or confirm my analysis that leads to the "accusation"? It was tedious.> > I don't think that a complete 4.1 code set was ever imported into> the CVS CM3 repository; at least I don't remember we got the complete> 4.1 code from Farshad Nayeri. What we got was 5.1 and it wasn't even> compilable by any existing M3 compiler. The gcc backend was so old> that it wasn't usable on any system we had. I think we extensively used> PM3 for booting and even incorporated some of PM3's code where> necessary.> > I remember that I had several evaluation CDs from CM3 some years before> the open source release, so it may be that contents from one of these> CDs were imported as 4.1. I'm afraid it is not really traceable now.> We never got any versioned code from Critical Mass (I don't know what> they used for version control), only the bare source code.> > 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 jayk123 at hotmail.com  Fri May 30 08:31:19 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 30 May 2008 06:31:19 +0000
Subject: [M3devel] _lowbits / _highbits (Pixmap bug-- 4.1 vs.	buggy	5.x)
In-Reply-To: 
References: 
	
	<20080529150209.vnhlgwbjcog4wc04@mail.elegosoft.com> 
	<483EA20A.1E75.00D7.1@scires.com> 
	
Message-ID: 



Also if you can send me a test case I can build and run for the current pixmap problem, please do.


 - Jay



________________________________

From: jayk123 at hotmail.com
To: rcoleburn at scires.com; m3devel at elegosoft.com
Date: Thu, 29 May 2008 19:07:40 +0000
Subject: Re: [M3devel] _lowbits / _highbits (Pixmap bug-- 4.1 vs. buggy 5.x)




I have the 4.1 CD. I bought it from Critical Mass the normal legitimate way. I hacked my cm3.exe the other day to skip the license check since I can't find my key, it's very easy to do.
My observations agree with yours -- no source on the CD to the compiler, contrib includes the DEC 3.6 code.

What are the CM3IDE problems?

What is the pixmap behavior with build_standalone()?
I'm inclined to think this is not a Modula-3 problem but hard to debug remotely like this..

 - Jay



________________________________

Date: Thu, 29 May 2008 12:31:14 -0400
From: rcoleburn at scires.com
To: m3devel at elegosoft.com
Subject: Re: [M3devel] _lowbits / _highbits (Pixmap bug-- 4.1 vs. buggy 5.x)


Olaf / Jay:



My Reactor v4.1 CD has a source directory, but this folder does not contain the sources for the compiler or Reactor, just the libraries et al.



Here is a list of the archives in that folder:



BINUTILS.TGZ
m3-comm.TGZ
m3-db.TGZ
M3-DEMO.TGZ
M3-GAMES.TGZ
M3-LCTRN.TGZ
m3-libs.TGZ
M3-MAIL.TGZ
M3-OBLIQ.TGZ
M3-PKGTL.TGZ
M3-TOOLS.TGZ
m3-ui.TGZ
m3-www.TGZ
M3CC.TGZ
M3GDB.TGZ



There is also a CONTRIB folder with the following:



CVSUP
IDLM3
M2TOM3
M3DDD
M3PC
M3TOMIF
SRC-M3



If Farshad is ok with it, I can send you these files, but I would need his approval because we licensed this product from Critical Mass.



On a side note, I just built a new laptop computer from a fresh install of XP Pro.  I got the latest cm3 from the repository and rebuilt everything.  On this platform, my pixmaps show up with a "yellow" color everywhere "white" would normally show.  This is strange behavior.  I checked the .lst file and it is showing as a GUI program and the "hand.obj" is included.  Any ideas?



Since Jay has made good progress on fixing some of my major gripes, I am trying to use the new (current) cm3 for my project that is due for delivery at the end of July.  The new garbage collector seems to work much better on Windows than the one from 4.1.  Since we don't have an official stable release right now, I am going to have to draw a line in the sand at some point soon and take a snapshot of the cm3 source tree as the "official" development environment for future support of my project deliverables.



This latest problem with pixmaps on one platform and with CM3IDE on all XP platforms I've tested so far is disturbing.  As soon as I can get a handle on these problems, I think I am going to freeze my development environment for this project unless someone comes up with a major fix/change.



Regards,

Randy

>>> Olaf Wagner  5/29/2008 9:02 AM>>>
Quoting Jay :

> 1) Just fyi, NT386GNU didn't build with my fix, so it is disabled
> there only, and the bug could very well be present there.
> Er, then again, this stuff works differently for the gcc backend, so
>  I don't know, I'll have to look, and run the tests, not today.
> Which reminds me also, these symbols should be static hand.c, except
>  for NT386 -- the source can't tell, so it'll have to be a define
> from the m3makefile.
>
> 2) Can anyone confirm my history and the missing source?
> ie: Confirm that what is marked as 4.1 and 5.1 in CVS really is 4.1
> and 5.1? I don't think 4.1 is accurately marked.
> In particular, I don't think the 4.1 Stackx86.m3  is what 4.1
> actually shipped.
>
> 3) Or confirm my analysis that leads to the "accusation"? It was tedious.

I don't think that a complete 4.1 code set was ever imported into
the CVS CM3 repository; at least I don't remember we got the complete
4.1 code from Farshad Nayeri. What we got was 5.1 and it wasn't even
compilable by any existing M3 compiler. The gcc backend was so old
that it wasn't usable on any system we had. I think we extensively used
PM3 for booting and even incorporated some of PM3's code where
necessary.

I remember that I had several evaluation CDs from CM3 some years before
the open source release, so it may be that contents from one of these
CDs were imported as 4.1. I'm afraid it is not really traceable now.
We never got any versioned code from Critical Mass (I don't know what
they used for version control), only the bare source code.

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 jayk123 at hotmail.com  Fri May 30 08:45:03 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 30 May 2008 06:45:03 +0000
Subject: [M3devel] FW: NT386 environment variables (new NT386	snapshots)
In-Reply-To: <20080527155926.203bam89w4w0kgko@mail.elegosoft.com>
References: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
	
	<4823279D.1E75.00D7.1@scires.com>
	 
	<20080527155926.203bam89w4w0kgko@mail.elegosoft.com>
Message-ID: 


Yes, RTArgs and Env should work now on NT386.

NT386GNU actually probably doesn't yet implement "gui" apps, and NT386GNU console apps I expect work.
I should finish and test that, very small feature. More interesting for NT386MINGNU probably, but the same code to implement it and trivial.

The fix could be better/smaller, but probably ok.
In particular, the compiler generates a main that passes data to the runtime.
Sometimes main is right, sometimes wrong.
I left the compiler/main alone, but changed the NT386 runtime to always just fetch the data itself and always ignore the data it got from main. This might let some hypothetical bootstrapping scenarios keep working, using a new compiler to target an old runtime..

I'll switch to plain text and see how it goes.
Apparently that requires switching to "classic" Hotmail and I haven't seen if I can make it "sticky" or not.
We'll see. jay.krell at cornell.edu will work again shortly too but that won't help. :)
I have ONE other report of truncated mail.

 - Jay


> Date: Tue, 27 May 2008 15:59:26 +0200
> From: wagner
> To: m3devel; rforb
> Subject: Re: [M3devel] FW: NT386 environment variables (new NT386 snapshots)
>
> Quoting Jay 
>
>> truncated again...
>> m3support -- nothing interesting in any logs regarding my mail?
>> And nobody else uses hotmail, right?
>
> @Ronny, can you please check if our mail logs reveal any reason
> for Jay's mails to be truncated now and then?
>
>>> I will apply an easy fix.
>> done
>
> I'm not sure if this means that the issues concerning evnironment
> variable access (both via Env and RTArgs) are now fixed for NT386(GNU)...
> Can we forget about this issue?
>
> Olaf
>
....snip snip snip....


From rodney.bates at wichita.edu  Sat May 31 00:14:36 2008
From: rodney.bates at wichita.edu (Rodney M. Bates)
Date: Fri, 30 May 2008 17:14:36 -0500
Subject: [M3devel] function pointers and comparison to nil? mis-typed
 function pointers?
In-Reply-To: 
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
	
	
	
	
	<483B21F9.6070205@wichita.edu>
	
Message-ID: <48407C4C.5020407@wichita.edu>



Jay wrote:
>  > Mistaking the function's real code for a closure is a lot less likely
>  > than mistaking the function's real code for a trampoline. A trampoline
> 
> What is the danger in "mistaking" "real code" for a "trampoline"?
> They are both "real code".

This mistake would break correct implementation of the language.  It
would mean a runtime error, called for by the language semantics,
would go undetected.

(2.3.1: Since there is no way to determine statically whether the
value of a procedure parameter is local or global, assigning a local
procedure is a runtime rather than a static error.)

> The differences are:
>   - trampoline has limited lifetime -- unless it is heap allocated and

Not sure if this is what you meant, but the needed lifetime of either a
M3 closure or a trampoline are the same.  Either way, it is created on
the stack during a call to which a nested procedure is passed as parameter.
In Modula-3, the only reason to heap allocate would be if it is a trampoline,
to get around the possible non-executable state of the stack on some targets.
There is no need for heap lifetime semantics.

> garbage collected
>     ("real code" also has "limited lifetime", but relatively much 
> longer, if code can be unloaded, which it can be in many environments)
>   - the "real code" of nested functions has a different calling 
> convention than "real code" for non nested functions; it has an extra 
> parameter "somewhere", for the "static link"; in gcc C nested functions 
> on Cygwin/x86, this is in ecx

Again, this difference in calling convention is entirely independent of
whether M3 closures or trampolines are used.  They are different ways of
getting the environment pointer (ecx, on x86) loaded, before actually
transferring to the callee's code.

>  
> What do folks think about putting trampolines in executable garbage 
> collected heap?
> I think that's inefficient but I'm usually in the minority here 
> regarding the heap being inefficient.
>  
> One way or another, gcc makes C nested functions fairly portable, except 
> Apple's gcc on Darwin.
> Portability of -1 as a marker denoting "not code" is also dubious.
>  
> I think it stinks either way.
>  
> Anyone think coming up with "better" per-architecture markers is reasonable?

If we keep M3-style closures, the only architecture dependence is the value of
the marker word, that would be a dependence I could live with.  Trampolines,
in contrast, would have target opcodes in them, the bit layout of the trampoline
would vary, and the two pointers would almost surely be unaligned on many targets,
making m3gdb's job a lot harder.

>  
>  - Jay
> 
> ------------------------------------------------------------------------
> 
>  > Date: Mon, 26 May 2008 15:47:53 -0500
>  > From: rodney.bates at wichita.edu
>  > To: m3devel at elegosoft.com
>  > Subject: Re: [M3devel] function pointers and comparison to nil? 
> mis-typed function pointers?
>  >
>  >
>  >
>  > Jay wrote:
>  > > It stinks either way imho.
>  > > The portability is handled, somehow or another, by gcc's support for
>  > > nested functions.
>  > > For example on OpenBSD, they call mprotect to make the trampoline
>  > > executable -- expensive! and leaves a bit of a security hole.
>  > > On Linux you can sometimes mark the .exe as needing an executable 
> stack
>  > > or not. Similarly on Windows, linker has /nxcompat, /nxcompat:no 
> switch.
>  > > ATL on Windows puts trampolines in the heap and specifically makes 
> them
>  > > executable -- since the heap isn't necessarily executable either.
>  > > The -1 marker is also a bit of a portability problem but I guess in
>  > > practise it works out.
>  >
>  > Using trampolines would make this problem worse, perhaps much worse.
>  > Mistaking the function's real code for a closure is a lot less likely
>  > than mistaking the function's real code for a trampoline. A trampoline
>  > is, after all, always valid machine code on the executing processor.
>  > Not necessarily so for -1.
>  >
>  > > I'd be curious to see how it decodes on various processors.
>  > >
>  > > - Jay
>  > >
>  > --
>  > -------------------------------------------------------------
>  > Rodney M. Bates, retired assistant professor
>  > Dept. of Computer Science, Wichita State University
>  > Wichita, KS 67260-0083
>  > 316-978-3922
>  > rodney.bates at wichita.edu
> 

-- 
-------------------------------------------------------------
Rodney M. Bates, retired assistant professor
Dept. of Computer Science, Wichita State University
Wichita, KS 67260-0083
316-978-3922
rodney.bates at wichita.edu


From rodney.bates at wichita.edu  Sat May 31 01:17:02 2008
From: rodney.bates at wichita.edu (Rodney M. Bates)
Date: Fri, 30 May 2008 18:17:02 -0500
Subject: [M3devel] function pointers and comparison to nil? mis-typed
 function pointers?
In-Reply-To: 
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
	
	
Message-ID: <48408AEE.8090405@wichita.edu>

I still want to obsess on variables of type procedure/pointer-to-function,
because some of the discussion appears to me to maybe forgetting that each
language has a definition, and language implementors should adhere to it.
These are not the bad old days of the 1960s, when the only authority on the
semantics of a language was "whatever our particular compiler does".

The various languages have different rules for dealing with the problem of
dangling environment pointers in procedure variables, and these affect the
implementation choices.

In Pascal, procedures can be passed as parameters but never assigned,
regardless of whether nested or not.  It is a consequence of normal
lifetime rules that dangling environments can't happen.  The most obvious
implementation is to always use a traditional, two-word closure, nested or
not, so no marker is needed   This has an environment pointer and a code
pointer.

In Modula-2, procedures can be both passed and assigned, but only global
procedure values are allowed.  This can be checked statically and prevents
dangling environment pointers in a different way.  No environment pointer
is needed, so one-word pointers to code can be used as the implementation.

In Modula-3, you can pass any procedure but only assign a top-level procedure.
This precludes dangling environments in yet another way, that is more liberal
than either Pascal or Modula-2,, but requires a runtime check on procedure
assignments.  Modula-3 could be implemented using always two-word closures
with no marker, or the way it is.

In C, as extended by gcc, dangling environment pointers can happen and the
language makes no attempt to prevent them.  In the words of the gcc manual,
if you use one, "all hell will break loose".  Trampolines implement this
fine, while keeping pointers to global functions having the expected,
one-word representation.

My one handy Algol68 book has the usual tutorial language book problem: it
omits the cases you really need to look up.  It only states that there will
be problems if you use a dangling environment, but not whether the language
specifies this should be detected by the language, or whether "all hell will
break loose."  I'm guessing it's the latter. The implementation technique
Hendrik describes makes it a detected runtime error, but not unless/until
you try to use the lost environment.  This is more generous than Modula-3's rule.

And, of course, if your language is really dynamic, it could just say an
environment is always accessible, requiring many or all activation records
to be heap allocated.

Though it's obviously desirable,  Supporting all this for mixtures of
languages is, IMO, highly unrealistic without a lot of cooperation among
the developers of all the compilers of all the languages involved.  And this
involves both defining semantics and coming up with compatible implementations.
The horse is already long gone from the barn on other language definitions
and their compilers.

The system we now have is actually a quite good after-the-fact compromise.
It correctly implements Modula-3, and allows free intermixing of C and Modula-3
procedure/pointer-to-function values, as long as the values are not nested.
It also doesn't require an executable stack.  Not bad, considering we have
no influence on any other language definers or compiler writers.

Jay wrote:
>  
> Even though nested functions are a gcc extension to the C language, 
> email threads out there discuss Ada, Pascal, and even ! Modula-3 as 
> having nested functions, and that therefore deprecating the C language 
> feature doesn't "solve" the "problem".
>  
> I remain uncertain what, if anything, to do here.
>  - keep the -1 hack, do nothing
>     generalize it slightly to let targets pick "better" markers
>  - use gcc's supported for nested functions
>    (plus the integrated backend, not difficult)
>  
> Clearly this is a dilemna to more than just me. :)
>  
>  - Jay
>
-- 
-------------------------------------------------------------
Rodney M. Bates, retired assistant professor
Dept. of Computer Science, Wichita State University
Wichita, KS 67260-0083
316-978-3922
rodney.bates at wichita.edu


From hendrik at topoi.pooq.com  Sat May 31 15:29:24 2008
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sat, 31 May 2008 09:29:24 -0400
Subject: [M3devel] function pointers and comparison to nil? mis-typed
	function pointers?
In-Reply-To: <48408AEE.8090405@wichita.edu>
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
	
	
	<48408AEE.8090405@wichita.edu>
Message-ID: <20080531132924.GA30413@topoi.pooq.com>

On Fri, May 30, 2008 at 06:17:02PM -0500, Rodney M. Bates wrote:
> 
> My one handy Algol68 book has the usual tutorial language book problem: it
> omits the cases you really need to look up.  It only states that there will
> be problems if you use a dangling environment, but not whether the language
> specifies this should be detected by the language, or whether "all hell will
> break loose."  I'm guessing it's the latter. The implementation technique
> Hendrik describes makes it a detected runtime error, but not unless/until
> you try to use the lost environment.  This is more generous than Modula-3's 
> rule.

The actual Algol 68 definition does pronounce on this.  The CDC 
implementation was much more liberal than the language definition.

Every reference/variable and every procedure has a scope.  The scope of 
a variable is the level on the run-time stack at which it is allocated.  
Variables can be on the heap; this is global scope.  The scope of a 
procedure is the stack elvel at which its most local global identifier 
is bound.  Even if the identifier refers to an object on the heap, it is 
the level at which it is bound that counts.

There is a universal scope restriction:  No object can refer to a more 
local object.  The constraint in the language definition is applied on 
assignment.

I know of no Algol 68 implementation that I can say for sure implements 
this restriction with a run-time check.  Of course it can be done, 
either by tagging each pointer with an explicit mention of its stack 
level (which takes space) or by comparing its value and comparing it to 
various stack locations in a kind of search.

The first release of the CDC algol 68 compiler just allocated all 
variables on the heap, making the check unnecessary for safety.  
Programmers almost never wrote code that passed procedures out-of-scope.

Later releases performed static analysis to determine where it was safe 
to allocate in the stack (almost all the time), and used the mechanism I 
described earlier to check procedures when they were called if the 
static check didn't suffice..
> 
> And, of course, if your language is really dynamic, it could just say an
> environment is always accessible, requiring many or all activation records
> to be heap allocated.

Which was a proposal made for the original Algol 68, but was turned 
down.  I think it should have been accepted.  We would have had a 
strongly-typed Scheme ahead of its time.

-- hendrik



From jayk123 at hotmail.com  Thu May  1 04:00:30 2008
From: jayk123 at hotmail.com (Jay)
Date: Thu, 1 May 2008 02:00:30 +0000
Subject: [M3devel] tinderbox
Message-ID: 

PPC_DARWIN:
 
6551           -> archiving libpatternmatching.a6552          Undefined symbols:6553            "_GlobTree__MatchTest", referenced from:6554                _L_1 in GlobTree.mo6555                _L_1 in GlobTree.moPerhaps fallout from my parse.c change?
I'll look -- later.
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From hosking at cs.purdue.edu  Thu May  1 06:29:13 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 1 May 2008 00:29:13 -0400
Subject: [M3devel] tinderbox
In-Reply-To: 
References: 
Message-ID: 

I wonder if we need TREE_USED(p) for proc_addr(p)?

On Apr 30, 2008, at 10:00 PM, Jay wrote:

> PPC_DARWIN:
>
> 6551           -> archiving libpatternmatching.a
> 6552          Undefined symbols:
> 6553            "_GlobTree__MatchTest", referenced from:
> 6554                _L_1 in GlobTree.mo
> 6555                _L_1 in GlobTree.mo
>
>
> Perhaps fallout from my parse.c change?
> I'll look -- later.
>
>  - Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Thu May  1 12:36:53 2008
From: jayk123 at hotmail.com (Jay)
Date: Thu, 1 May 2008 10:36:53 +0000
Subject: [M3devel] tinderbox
In-Reply-To: 
References: 
	
Message-ID: 


so far I can confirm:
1) "no" other solution known for AMD64_LINUX
er, actually, public = (level != 0) should work
but a few other solutions didn't work -- e.g. -fvisibility=hidden has no affect as expected

2) DECL_PRESERVE_P and TREE_USED both sound promising
really, gcc is just a mess of hard to understand flags all over the place..

3) I can reproduce the problem on PPC_DARWIN
The "actual" uses of the functions have the names replaced by generated names -- ok, but bad for debugging
The references are then from the module information...so much for dead stripping?
I don't think those should be there.
I don't know why the names end up generated, maybe because of static = 1?
Not clear if static means "C file scope" or something else.

I'll keep poking -- waiting for my PPC_DARWIN build of m3cg (hm, I must have cleaned out the previous).

There is a nice optimization to my larger fix here, and it doesn't even go far enough, but for now checking (level != 0) will probably suffice.

 - Jay

CC: m3devel at elegosoft.com
From: hosking at cs.purdue.edu
To: jayk123 at hotmail.com
Subject: Re: [M3devel] tinderbox
Date: Thu, 1 May 2008 00:29:13 -0400

I wonder if we need TREE_USED(p) for proc_addr(p)?
 On Apr 30, 2008, at 10:00 PM, Jay wrote:PPC_DARWIN:
 
6551           -> archiving libpatternmatching.a
6552          Undefined symbols:
6553            "_GlobTree__MatchTest", referenced from:
6554                _L_1 in GlobTree.mo
6555                _L_1 in GlobTree.mo


Perhaps fallout from my parse.c change?
I'll look -- later.
 
 - Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From wagner at elegosoft.com  Thu May  1 22:55:06 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Thu, 01 May 2008 22:55:06 +0200
Subject: [M3devel] Popup Windows stalling regression tests on WinXP
In-Reply-To: <495318.48565.qm@web27105.mail.ukl.yahoo.com>
References: <495318.48565.qm@web27105.mail.ukl.yahoo.com>
Message-ID: <20080501225506.7gxpp2zh34w8ccgs@mail.elegosoft.com>

Quoting "Daniel Alejandro Benavides D." :

> Hi all:
> Olaf, I don't have the Win box here (just a Kubuntu one). But even   
> if you  don't want to send the file,  one can see the report file in  
>  a window. Should be  with two steps: The first click on the blue   
> label "Click here " in the first pop up window. That throws another   
> window with a label that you can click-on and actually see it
> Well I found with google the instruction to disable that error pop up:
> http://pcsupport.about.com/od/windowsxp/ht/disableerror.htm
> I hope this helps to you.

I now tried that, within a new VM (Win4BSD), and the tests ran
until p204, and then crashed (without popup window, which is good).
When I got home though, and had a look at the state of things, I had
about ten seconds before the VM rebootet :-(

So there's no more information right now; it seems that I'll have to run
this test within a debugger.

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 jayk123 at hotmail.com  Thu May  1 23:57:30 2008
From: jayk123 at hotmail.com (Jay)
Date: Thu, 1 May 2008 21:57:30 +0000
Subject: [M3devel] Popup Windows stalling regression tests on WinXP
In-Reply-To: <20080501225506.7gxpp2zh34w8ccgs@mail.elegosoft.com>
References: <495318.48565.qm@web27105.mail.ukl.yahoo.com>
	<20080501225506.7gxpp2zh34w8ccgs@mail.elegosoft.com>
Message-ID: 

Watch m3commit more closely :) -- the popup should be gone. You shouldn't have to twiddle any settings.
Admittedly, my testing was on AMD64 XP, which is really Server 2003, therefore could vary much from x86 XP.
I can try on x86 XP later (as in a day or two).
But really, based on the code before and after, I think it is gone everywhere.

 - Jay

> Date: Thu, 1 May 2008 22:55:06 +0200
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] Popup Windows stalling regression tests on WinXP
> 
> Quoting "Daniel Alejandro Benavides D." :
> 
> > Hi all:
> > Olaf, I don't have the Win box here (just a Kubuntu one). But even   
> > if you  don't want to send the file,  one can see the report file in  
> >  a window. Should be  with two steps: The first click on the blue   
> > label "Click here " in the first pop up window. That throws another   
> > window with a label that you can click-on and actually see it
> > Well I found with google the instruction to disable that error pop up:
> > http://pcsupport.about.com/od/windowsxp/ht/disableerror.htm
> > I hope this helps to you.
> 
> I now tried that, within a new VM (Win4BSD), and the tests ran
> until p204, and then crashed (without popup window, which is good).
> When I got home though, and had a look at the state of things, I had
> about ten seconds before the VM rebootet :-(
> 
> So there's no more information right now; it seems that I'll have to run
> this test within a debugger.
> 
> 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 jayk123 at hotmail.com  Fri May  2 11:33:50 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 2 May 2008 09:33:50 +0000
Subject: [M3devel] in search of decent editor for Mac/Linux?
In-Reply-To: <20080502090445.4496E10D495A@birch.elegosoft.com>
References: <20080502090445.4496E10D495A@birch.elegosoft.com>
Message-ID: 

Does anyone know of an IDE or editor on Linux or Mac OS Xwith a find-in-files feature anywhere nearly as goodas Visual C++ 5.0?
I have tried a bunch and they have all been disappointing.
It is very frustrating.
Monodevelop comes close, but it won't open .m3 files as text.
KDevelop -- can't navigate the results with the keyboard. I would prefer file path on every line, but ok I guess.
X Code -- no find-in-files feature at all that I could find!
NetBeans -- I forget, will have to try again, but I believe I was disappointed.
Eclipse -- ditto
Komodo -- promising, will have to try some more  I think maybe only forward nav through results, but ok  will have to see what the cost is 
JEdit -- I think it was this one, showed no results  until done. Results should appear as they are found.
Mac TextWrangler -- way too hard to specify directories to search in  as I recall, I forget if has keyboard nav.
 
MPW -- never seemed much good at all, despite avid following;
  doesn't run on current processors or operating systems, but it
  still works on mine
 
I'll have to again try:  NetBeans, Eclipse, Komodo, CodeWarrior, SlickEdit, search for other commercial ones.
  Though commercial ones won't tend to run on PPC_LINUX.
vi and emacs are not under consideration.I have tried them each many times and they are alwaysvery disappointing.
A really good file.open dialog would be nice too.
KDevelop is annoying in that it often beeps an error if I type a directory -- to go to it. It is case sensitive.
All the file.open dialogs I have seen on the Mac stink.
What do people use to actually be productive?Everything I've tried hasn't come close to Visual C++ 5.0.
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From wagner at elegosoft.com  Fri May  2 15:28:24 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Fri, 02 May 2008 15:28:24 +0200
Subject: [M3devel] Popup Windows stalling regression tests on WinXP
In-Reply-To: 
References: <495318.48565.qm@web27105.mail.ukl.yahoo.com>
	<20080501225506.7gxpp2zh34w8ccgs@mail.elegosoft.com>
	
Message-ID: <20080502152824.ltfkpvoy88cg0gc0@mail.elegosoft.com>

Quoting Jay :

> Watch m3commit more closely :) -- the popup should be gone. You   
> shouldn't have to twiddle any settings.
> Admittedly, my testing was on AMD64 XP, which is really Server 2003,  
>  therefore could vary much from x86 XP.
> I can try on x86 XP later (as in a day or two).
> But really, based on the code before and after, I think it is gone   
> everywhere.

Attached are my current results from NT386 m3tests. The popup is gone,
but the tests terminate at p204:

--- p204 --- IP address initializers
cd ..\src\p2\p204 && cm3 -build   -silent >NT386\stdout.build  
2>NT386\stderr.build
"h:\work\cm3\m3-sys\m3tests\src\m3makefile", line 248: quake runtime  
error: exit 1: cd ..\src\p2\p204 && cm3 -build   -silent  
 >NT386\stdout.build 2>NT386\stderr.build

--procedure--  -line-  -file---
exec               --  
run_test          248  h:\work\cm3\m3-sys\m3tests\src\m3makefile
p_test            292  h:\work\cm3\m3-sys\m3tests\src\m3makefile
include_dir       506  h:\work\cm3\m3-sys\m3tests\src\m3makefile
                     6  h:\work\cm3\m3-sys\m3tests\NT386\m3make.args

Fatal Error: package build failed

Not all tests in red are actually errors, as paths have changed
and expected results need to be adapted.

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 jayk123 at hotmail.com  Fri May  2 20:57:56 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 2 May 2008 18:57:56 +0000
Subject: [M3devel] Popup Windows stalling regression tests on WinXP
In-Reply-To: <20080502152824.ltfkpvoy88cg0gc0@mail.elegosoft.com>
References: <495318.48565.qm@web27105.mail.ukl.yahoo.com>
	<20080501225506.7gxpp2zh34w8ccgs@mail.elegosoft.com>
	 
	<20080502152824.ltfkpvoy88cg0gc0@mail.elegosoft.com>
Message-ID: 

 >but the tests terminate at p204:
fixed< exec("cm3")
> try_exec("cm3")
 
oh, maybe there had a minus sign before? I'll check..
 
-Jay



> Date: Fri, 2 May 2008 15:28:24 +0200> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: RE: [M3devel] Popup Windows stalling regression tests on WinXP> > Quoting Jay :> > > Watch m3commit more closely :) -- the popup should be gone. You > > shouldn't have to twiddle any settings.> > Admittedly, my testing was on AMD64 XP, which is really Server 2003, > > therefore could vary much from x86 XP.> > I can try on x86 XP later (as in a day or two).> > But really, based on the code before and after, I think it is gone > > everywhere.> > Attached are my current results from NT386 m3tests. The popup is gone,> but the tests terminate at p204:> > --- p204 --- IP address initializers> cd ..\src\p2\p204 && cm3 -build -silent >NT386\stdout.build > 2>NT386\stderr.build> "h:\work\cm3\m3-sys\m3tests\src\m3makefile", line 248: quake runtime > error: exit 1: cd ..\src\p2\p204 && cm3 -build -silent > >NT386\stdout.build 2>NT386\stderr.build> > --procedure-- -line- -file---> exec -- > run_test 248 h:\work\cm3\m3-sys\m3tests\src\m3makefile> p_test 292 h:\work\cm3\m3-sys\m3tests\src\m3makefile> include_dir 506 h:\work\cm3\m3-sys\m3tests\src\m3makefile> 6 h:\work\cm3\m3-sys\m3tests\NT386\m3make.args> > Fatal Error: package build failed> > Not all tests in red are actually errors, as paths have changed> and expected results need to be adapted.> > 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 jayk123 at hotmail.com  Sat May  3 10:11:35 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 3 May 2008 08:11:35 +0000
Subject: [M3devel] initializing with subarray(constant)
In-Reply-To: <20080503080455.80F4D70DA16@birch.elegosoft.com>
References: <20080503080455.80F4D70DA16@birch.elegosoft.com>
Message-ID: 

Anyone understand this and know how to fix?
 
Maybe the test passes with older/forked tools?
I'll try it with 3.6 and maybe 4.1.
 
It's very confusing that some of the "LV" and "LValue" functions take a parameter rhs : BOOLEAN.
We end up with
Variable.LoadLValue(p.obj) where p.obj is of type Constant.T
 
The fix reveals understanding of the problem and makes the specific case work, but I think a better fix must exist.
 
I think it'd be quite excellent for NARROW() failures to print the two types involved.
Currently there isn't "room" for the data -- we call abort("narrow failed").
I put in some RTIO calls in IsSubtype to get a better handle on what is happening.
Maybe m3gdb shows types well?
I'm too impatient to build it so I make do with cdb and gdb..
 
 - Jay



> Date: Sat, 3 May 2008 10:04:55 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/05/03 10:04:55> > Modified files:> cm3/m3-sys/m3front/src/exprs/: QualifyExpr.m3 > cm3/m3-sys/m3front/src/values/: Constant.i3 Constant.m3 > cm3/m3-sys/m3tests/src/: m3makefile > > Log message:> enough to fix test p2/p205, but needs more attention as the fix> seems to be at the wrong abstraction level and not cover every case> > in particular, confusion around lvalues vs. non-lvalues> in particular, read the comments in QualifyExpr.m3> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sat May  3 10:20:45 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 3 May 2008 08:20:45 +0000
Subject: [M3devel] FW: initializing with subarray(constant)
In-Reply-To: <20080503080455.80F4D70DA16@birch.elegosoft.com>
References: <20080503080455.80F4D70DA16@birch.elegosoft.com>
Message-ID: 

truncated again..


From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: initializing with subarray(constant)Date: Sat, 3 May 2008 08:11:35 +0000


Anyone understand this and know how to fix? Maybe the test passes with older/forked tools?I'll try it with 3.6 and maybe 4.1. It's very confusing that some of the "LV" and "LValue" functions take a parameter rhs : BOOLEAN.We end up withVariable.LoadLValue(p.obj) where p.obj is of type Constant.T The fix reveals understanding of the problem and makes the specific case work, but I think a better fix must exist. I think it'd be quite excellent for NARROW() failures to print the two types involved.Currently there isn't "room" for the data -- we call abort("narrow failed").I put in some RTIO calls in IsSubtype to get a better handle on what is happening.Maybe m3gdb shows types well?I'm too impatient to build it so I make do with cdb and gdb..  - Jay

> Date: Sat, 3 May 2008 10:04:55 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/05/03 10:04:55> > Modified files:> cm3/m3-sys/m3front/src/exprs/: QualifyExpr.m3 > cm3/m3-sys/m3front/src/values/: Constant.i3 Constant.m3 > cm3/m3-sys/m3tests/src/: m3makefile > > Log message:> enough to fix test p2/p205, but needs more attention as the fix> seems to be at the wrong abstraction level and not cover every case> > in particular, confusion around lvalues vs. non-lvalues> in particular, read the comments in QualifyExpr.m3> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sat May  3 10:47:31 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 3 May 2008 08:47:31 +0000
Subject: [M3devel] FW: tests vs. long-ago language change?
In-Reply-To: <20080503080455.80F4D70DA16@birch.elegosoft.com>
References: <20080503080455.80F4D70DA16@birch.elegosoft.com>
Message-ID: 






From: jayk123 at hotmail.comTo: jayk123 at hotmail.comSubject: tests vs. language changes?Date: Sat, 3 May 2008 08:45:59 +0000


Looking at tests p205, p206, p130p205 -- initialization involving subarray(constant open array)p206 -- initialization involving open arrayp130 -- use of type "UNSIGNED"I am led to believe that the language used to have an UNSIGNED type,but it was dropped long ago. p130 can just be thrown out.?Constant array constructors without index types couldarguably be considered fixed size with indices 0..n-1, butthey are in fact considered open, and this should remain asis.p206 is at least partly invalid.
The language definition and, barely, tutorial point to this.
I didn't check the green book.
 p205 suggests the same as p206 perhaps, perhaps thecompiler has this in mind, since there's a bunch of casesfor "types" of arrays -- open, fixed -- and the test goesdown an open path.Subarray.PrepLV is what I'm referring to in particular.The right fix for p205 might be for the case of "constant open"arrays to be implemented more like fixed arrays.In particular, avoid the call to CompileAddress.In particular, end up in case 3 instead of, I think 7.?
I'll maybe look into Subarray.PrepLV later, after some other tests..
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sat May  3 13:24:24 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 3 May 2008 11:24:24 +0000
Subject: [M3devel] FW: NT386 jmpbuf size?
In-Reply-To: <20080503111742.D803370DA16@birch.elegosoft.com>
References: <20080503111742.D803370DA16@birch.elegosoft.com>
Message-ID: 

Does anyone mind wasting an extra 32 bytes of stack in functions with a "try" on NT386?
jmpbuf is declared to be 64 bytes, but if you read the assembly, _setjmp doesn't use it all, and _setjmp3 might.
 
The difference is whether not a situation in which Modula-3 calls longjmp "past" C or C++ code, does the C __finally and C++ destructors run.
Presently I think with Modula-3, not.
Like, if Modula-3 passes some C/C++ a callback and the callback raises an exception and the C/C++ wanted to do some cleanup as the exception "goes by".
 
I think it's always been this and I guess nobody noticed, so maybe leave it alone and shrink the jmpbuf back to 32 bytes from 64?
 
Inflating from 8 to 13 also does get you some possible interop between NT386 and NT386GNU.
 
 - Jay



> Date: Sat, 3 May 2008 13:17:42 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/05/03 13:17:42> > Modified files:> cm3/m3-sys/m3middle/src/: Target.m3 > > Log message:> fix and unify NT386 jmpbuf/setjmp> > it APPEARS jmpbuf was understated for Visual C++> though it was probably ok> it appears if you compile C/C++, the compiler generates a call> to _setjmp3, which indeed uses more of the declared-16 jmpbuf> but that if we call _setjmp directly, it only uses 8> > Cygwin was overstated because their setjmp.h> appears to confuse bytes and ints, it only uses 13.> > So unify the former 8 and 13 to 16.> > As well, Cygwin provides aliased setjmp and _setjmp, so> unify on _setjmp> > NOTE that using _setjmp3 for Visual C++ is probably desirable> but cross that bridge another time, perhaps we'll just stop> using setjmp entirely> > therefore making the three NT386 flavors much more similar> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sat May  3 13:25:07 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 3 May 2008 11:25:07 +0000
Subject: [M3devel] FW: NT386 jmpbuf size?
In-Reply-To: <20080503111742.D803370DA16@birch.elegosoft.com>
References: <20080503111742.D803370DA16@birch.elegosoft.com>
Message-ID: 

truncated again...


From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: FW: NT386 jmpbuf size?Date: Sat, 3 May 2008 11:24:24 +0000


Does anyone mind wasting an extra 32 bytes of stack in functions with a "try" on NT386?jmpbuf is declared to be 64 bytes, but if you read the assembly, _setjmp doesn't use it all, and _setjmp3 might. The difference is whether not a situation in which Modula-3 calls longjmp "past" C or C++ code, does the C __finally and C++ destructors run.Presently I think with Modula-3, not.Like, if Modula-3 passes some C/C++ a callback and the callback raises an exception and the C/C++ wanted to do some cleanup as the exception "goes by". I think it's always been this and I guess nobody noticed, so maybe leave it alone and shrink the jmpbuf back to 32 bytes from 64? Inflating from 8 to 13 also does get you some possible interop between NT386 and NT386GNU.  - Jay

> Date: Sat, 3 May 2008 13:17:42 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/05/03 13:17:42> > Modified files:> cm3/m3-sys/m3middle/src/: Target.m3 > > Log message:> fix and unify NT386 jmpbuf/setjmp> > it APPEARS jmpbuf was understated for Visual C++> though it was probably ok> it appears if you compile C/C++, the compiler generates a call> to _setjmp3, which indeed uses more of the declared-16 jmpbuf> but that if we call _setjmp directly, it only uses 8> > Cygwin was overstated because their setjmp.h> appears to confuse bytes and ints, it only uses 13.> > So unify the former 8 and 13 to 16.> > As well, Cygwin provides aliased setjmp and _setjmp, so> unify on _setjmp> > NOTE that using _setjmp3 for Visual C++ is probably desirable> but cross that bridge another time, perhaps we'll just stop> using setjmp entirely> > therefore making the three NT386 flavors much more similar> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From hosking at cs.purdue.edu  Sat May  3 15:33:12 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 3 May 2008 09:33:12 -0400
Subject: [M3devel] FW: initializing with subarray(constant)
In-Reply-To: 
References: <20080503080455.80F4D70DA16@birch.elegosoft.com>
	
Message-ID: 

This is on my list of things to do.  I have some idea what the fix is  
and just need to go in and do it.  Not enough time unfortunately.

On May 3, 2008, at 4:20 AM, Jay wrote:

> truncated again..
>
>
>
>
> From: jayk123 at hotmail.com
> To: m3devel at elegosoft.com
> Subject: initializing with subarray(constant)
> Date: Sat, 3 May 2008 08:11:35 +0000
>
> Anyone understand this and know how to fix?
>
> Maybe the test passes with older/forked tools?
> I'll try it with 3.6 and maybe 4.1.
>
> It's very confusing that some of the "LV" and "LValue" functions  
> take a parameter rhs : BOOLEAN.
> We end up with
> Variable.LoadLValue(p.obj) where p.obj is of type Constant.T
>
> The fix reveals understanding of the problem and makes the specific  
> case work, but I think a better fix must exist.
>
> I think it'd be quite excellent for NARROW() failures to print the  
> two types involved.
> Currently there isn't "room" for the data -- we call abort("narrow  
> failed").
> I put in some RTIO calls in IsSubtype to get a better handle on what  
> is happening.
> Maybe m3gdb shows types well?
> I'm too impatient to build it so I make do with cdb and gdb..
>
>  - Jay
>
>
>
> > Date: Sat, 3 May 2008 10:04:55 +0000
> > To: m3commit at elegosoft.com
> > From: jkrell at elego.de
> > Subject: [M3commit] CVS Update: cm3
> >
> > CVSROOT: /usr/cvs
> > Changes by: jkrell at birch. 08/05/03 10:04:55
> >
> > Modified files:
> > cm3/m3-sys/m3front/src/exprs/: QualifyExpr.m3
> > cm3/m3-sys/m3front/src/values/: Constant.i3 Constant.m3
> > cm3/m3-sys/m3tests/src/: m3makefile
> >
> > Log message:
> > enough to fix test p2/p205, but needs more attention as the fix
> > seems to be at the wrong abstraction level and not cover every case
> >
> > in particular, confusion around lvalues vs. non-lvalues
> > in particular, read the comments in QualifyExpr.m3
> >
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From wagner at elegosoft.com  Sat May  3 16:13:00 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Sat, 03 May 2008 16:13:00 +0200
Subject: [M3devel] m3tests reporting broken? was: Re: more m3tests changes
In-Reply-To: 
References: <20080502185151.B3DC110D4959@birch.elegosoft.com>
	
Message-ID: <20080503161300.3krg8bcfv0oo8w4k@mail.elegosoft.com>

Quoting Jay :

> Olaf, disable these for nt386?

Without having had a close look what the tests are about, I'd
say no; I'd rather have target-specific overrides for
expected values. I'd thought about it at least, but didn't get
round to implement it. Something like if sdtdout.build.TARGET
exists use that on TARGET.

BTW, almost all tests have turned to green in the tinderbox;
as I don't think somebody has fixed the underlying issues,
one of us must have broken the reporting :-/

Olaf

> - Jay
>
>> Date: Fri, 2 May 2008 20:51:51 +0000> To: m3commit at elegosoft.com>   
>> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> >   
>> CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/05/02 20:51:51> >   
>> Modified files:> cm3/m3-sys/m3tests/src/e0/e029/: stderr.build   
>> stdout.build > cm3/m3-sys/m3tests/src/p0/p004/: stdout.build >   
>> cm3/m3-sys/m3tests/src/p0/p051/: stdout.build >   
>> cm3/m3-sys/m3tests/src/p2/p204/: stderr.build stdout.build >   
>> cm3/m3-sys/m3tests/src/p2/p205/: stderr.build >   
>> cm3/m3-sys/m3tests/src/p2/p207/: stdout.build > > Log message:>   
>> where posix and win32 vary for now, take posix, from ppc_darwin>
-- 
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 jayk123 at hotmail.com  Sat May  3 16:37:04 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 3 May 2008 14:37:04 +0000
Subject: [M3devel] m3tests reporting broken? was: Re: more m3tests
	changes
In-Reply-To: <20080503161300.3krg8bcfv0oo8w4k@mail.elegosoft.com>
References: <20080502185151.B3DC110D4959@birch.elegosoft.com>
	 
	<20080503161300.3krg8bcfv0oo8w4k@mail.elegosoft.com>
Message-ID: 

Which is all green? Tinderbox and test status are both mixed.
I have to go for a bit. Maybe more later, but currently I don't know what's recently broken, only longer term problems with a small number of tests.
 
 - Jay



> Date: Sat, 3 May 2008 16:13:00 +0200> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: m3tests reporting broken? was: Re: more m3tests changes> > Quoting Jay :> > > Olaf, disable these for nt386?> > Without having had a close look what the tests are about, I'd> say no; I'd rather have target-specific overrides for> expected values. I'd thought about it at least, but didn't get> round to implement it. Something like if sdtdout.build.TARGET> exists use that on TARGET.> > BTW, almost all tests have turned to green in the tinderbox;> as I don't think somebody has fixed the underlying issues,> one of us must have broken the reporting :-/> > Olaf> > > - Jay> >> >> Date: Fri, 2 May 2008 20:51:51 +0000> To: m3commit at elegosoft.com> > >> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > > >> CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/05/02 20:51:51> > > >> Modified files:> cm3/m3-sys/m3tests/src/e0/e029/: stderr.build > >> stdout.build > cm3/m3-sys/m3tests/src/p0/p004/: stdout.build > > >> cm3/m3-sys/m3tests/src/p0/p051/: stdout.build > > >> cm3/m3-sys/m3tests/src/p2/p204/: stderr.build stdout.build > > >> cm3/m3-sys/m3tests/src/p2/p205/: stderr.build > > >> cm3/m3-sys/m3tests/src/p2/p207/: stdout.build > > Log message:> > >> where posix and win32 vary for now, take posix, from ppc_darwin>> -- > 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  Sat May  3 16:55:51 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Sat, 03 May 2008 16:55:51 +0200
Subject: [M3devel] m3tests reporting broken? was: Re: more m3tests
	changes
In-Reply-To: 
References: <20080502185151.B3DC110D4959@birch.elegosoft.com>
	
	<20080503161300.3krg8bcfv0oo8w4k@mail.elegosoft.com>
	
Message-ID: <20080503165551.3qh7w25etcwkgk8c@mail.elegosoft.com>

Quoting Jay :

> Which is all green? Tinderbox and test status are both mixed.
> I have to go for a bit. Maybe more later, but currently I don't know  
>  what's recently broken, only longer term problems with a small   
> number of tests.

All the release builds should be orange (and were until yesterday)
as some of the tests fail. See one of

http://tinderbox.elegosoft.com/tinderbox/cm3/status.html
http://tinderbox.elegosoft.com/tinderbox/all_trees.panel.html
http://tinderbox.elegosoft.com/tinderbox/all_trees.express.html
http://tinderbox.elegosoft.com/tinderbox/all_trees.quickparse.html

The lastok columns are more or less standalone, they are usually green
and turn to red in case of an incompatible runtime change (which is
intended and OK).

The release-build columns combine bulding of cm3 from the last release
and running all available tests; as some of those usually fail, they
are really not expected to be green, but orange, which means: build
OK, tests failed.

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 May  3 17:00:47 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Sat, 03 May 2008 17:00:47 +0200
Subject: [M3devel] FW: NT386 jmpbuf size?
In-Reply-To: 
References: <20080503111742.D803370DA16@birch.elegosoft.com>
	
Message-ID: <20080503170047.ocn9oj5li8gscg88@mail.elegosoft.com>

If there is a chance that more bytes are actually used under
special circumstances, I'd vote to make the jmp_buf large enough
to avoid memory corruption. I'm not sure if the extra bytes
will have performance impacts on thread switching, but I think
a special instruction could be used for copying them so that
it should be not much difference. I'm no expert on the Intel
processors though...

Quoting Jay :

> truncated again...
>
> From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: FW: NT386  
>  jmpbuf size?Date: Sat, 3 May 2008 11:24:24 +0000
>
>
> Does anyone mind wasting an extra 32 bytes of stack in functions   
> with a "try" on NT386?jmpbuf is declared to be 64 bytes, but if you   
> read the assembly, _setjmp doesn't use it all, and _setjmp3 might.   
> The difference is whether not a situation in which Modula-3 calls   
> longjmp "past" C or C++ code, does the C __finally and C++   
> destructors run.Presently I think with Modula-3, not.Like, if   
> Modula-3 passes some C/C++ a callback and the callback raises an   
> exception and the C/C++ wanted to do some cleanup as the exception   
> "goes by". I think it's always been this and I guess nobody noticed,  
>  so maybe leave it alone and shrink the jmpbuf back to 32 bytes from  
>  64? Inflating from 8 to 13 also does get you some possible interop   
> between NT386 and NT386GNU.  - 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 jayk123 at hotmail.com  Sun May  4 06:02:25 2008
From: jayk123 at hotmail.com (Jay)
Date: Sun, 4 May 2008 04:02:25 +0000
Subject: [M3devel] test e020?
Message-ID: 

This is half just a sanity check that I am restoring my damage properly.
These can't both be right, right?
http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3tests/src/e0/e020/stdout.build?rev=1.2;content-type=text%2Fplain
Fatal Error: package build failed
http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3tests/src/e0/e020/stderr.pgm?rev=1.1;content-type=text%2Fplain
 
****** illegal cycle in super types:***    child  = [0x10000294  _t0xd6319321  typecode=   0  Main.W]***    parent = [0x1000022c  _t0x5a31ef26  typecode=   0  Main.V]***    parent = [0x10000294  _t0xd6319321  typecode=   0  Main.W]***
****** runtime error:***    unable to initialize runtime types***
 
Presumably neither is ideal, it should fail to build, with a better error message, but the currentbehavior is worse than both, it fails at runtime with what I suspect is stack overflow frominfinite recursion.
C:\dev2\cm3\m3-sys\m3tests\src\e0\e020>NT386\pgm.exe
****** runtime error:***    A runtime error occurred.***    pc = 0x1002050b = FindSlot + 0xb in ..\src\runtime\common\RTType.m3***
Stack trace:   FP         PC      Procedure---------  ---------  -------------------------------  0x32fec  0x1002679e  SystemError + 0x66 in ..\src\runtime\NT386\RTSignal.m3  0x3301c  0x1002050b  FindSlot + 0xb in ..\src\runtime\common\RTType.m3  0x3304c  0x1001f430  FindType + 0x28 in ..\src\runtime\common\RTType.m3  0x33088  0x1001f901  FinishTypecell + 0x67 in ..\src\runtime\common\RTType.m3  0x330b4  0x1001f489  FindType + 0x81 in ..\src\runtime\common\RTType.m3  0x330f0  0x1001f901  FinishTypecell + 0x67 in ..\src\runtime\common\RTType.m3  0x3311c  0x1001f489  FindType + 0x81 in ..\src\runtime\common\RTType.m3  0x33158  0x1001f901  FinishTypecell + 0x67 in ..\src\runtime\common\RTType.m3  0x33184  0x1001f489  FindType + 0x81 in ..\src\runtime\common\RTType.m3  0x331c0  0x1001f901  FinishTypecell + 0x67 in ..\src\runtime\common\RTType.m3.........  .........  ... more frames ...
 
agreed?
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sun May  4 08:27:00 2008
From: jayk123 at hotmail.com (Jay)
Date: Sun, 4 May 2008 06:27:00 +0000
Subject: [M3devel] FW: NT386 jmpbuf size?
In-Reply-To: <20080503170047.ocn9oj5li8gscg88@mail.elegosoft.com>
References: <20080503111742.D803370DA16@birch.elegosoft.com>
	 
	<20080503170047.ocn9oj5li8gscg88@mail.elegosoft.com>
Message-ID: 

I BELIEVE:
  It is statically knowable:
    msvcrt _setjmp uses 8 words
    msvcrt _setjmp3 uses 16 
    cygwin uses I think 13 -- their header is just wrong by a factor of 4 
   You can tell from a mix of disassembly and source -- disassembly for msvcrt, disassembly and source for cygwin.
 
It isn't runtime variables that make the difference.
(well, the 16 case might sometimes shrink, it appears)
 
What is less clear is if _setjmp or _setjmp3 should be used.
It appears that any use of setjmp in C or C++ uses _setjmp3.
 
The difference appears to be whether or not the generally expected interaction with C __finally and C++ destructors and exception handling occurs.
"generally expected' but also "generally unknown".
 
One might argue that if C/C++ can afford the extra 32 bytes, then so can Modula-3 BUT C/C++ have MUCH more efficient exception handling mechanisms available and so setjmp is much less used there. They get by with around 3 words for a frame with exception handling on x86, and with zero overheard everywhere else.
 
The C/C++ behavior might also be affected by command line options. I'd have to experiment more..
 
To clarify, imagine Modula-3 gave a callback function to some C++ and that C++ has a local with a destructor, and the Modula-3 raises an exception.
Does the C++ destructor run or not?
With _setjmp probably not, with _setjmp3 probably.
 
Similarly, imagine some C++ gives some Modula-3 a callback and the C++ raises an exception.
Do the Modula-3 FINALLY blocks run?
 
Similar dilemna really on all platforms.
There relatively recently an ABI for C++ exception handling that maybe Modula-3 should use.
 
 - Jay



> Date: Sat, 3 May 2008 17:00:47 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] FW: NT386 jmpbuf size?> > If there is a chance that more bytes are actually used under> special circumstances, I'd vote to make the jmp_buf large enough> to avoid memory corruption. I'm not sure if the extra bytes> will have performance impacts on thread switching, but I think> a special instruction could be used for copying them so that> it should be not much difference. I'm no expert on the Intel> processors though...> > Quoting Jay :> > > truncated again...> >> > From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: FW: NT386 > > jmpbuf size?Date: Sat, 3 May 2008 11:24:24 +0000> >> >> > Does anyone mind wasting an extra 32 bytes of stack in functions > > with a "try" on NT386?jmpbuf is declared to be 64 bytes, but if you > > read the assembly, _setjmp doesn't use it all, and _setjmp3 might. > > The difference is whether not a situation in which Modula-3 calls > > longjmp "past" C or C++ code, does the C __finally and C++ > > destructors run.Presently I think with Modula-3, not.Like, if > > Modula-3 passes some C/C++ a callback and the callback raises an > > exception and the C/C++ wanted to do some cleanup as the exception > > "goes by". I think it's always been this and I guess nobody noticed, > > so maybe leave it alone and shrink the jmpbuf back to 32 bytes from > > 64? Inflating from 8 to 13 also does get you some possible interop > > between NT386 and NT386GNU. - 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 jayk123 at hotmail.com  Sun May  4 13:17:23 2008
From: jayk123 at hotmail.com (Jay)
Date: Sun, 4 May 2008 11:17:23 +0000
Subject: [M3devel] order of warnings, or even to have any?
In-Reply-To: <20080503170047.ocn9oj5li8gscg88@mail.elegosoft.com>
References: <20080503111742.D803370DA16@birch.elegosoft.com>
	 
	<20080503170047.ocn9oj5li8gscg88@mail.elegosoft.com>
Message-ID: 

C:\dev2\cm3\m3-sys\m3tests\src\p0\p004>cm3--- building in NT386 ---
new source -> compiling Main.m3"..\Main.m3", line 35: warning: exception is never raised: Main.e"..\Main.m3", line 9: warning: exception is never raised: "..\Main.m3", line 59: warning: unreachable statement"..\Main.m3", line 68: warning: unreachable statement"..\Main.m3", line 71: warning: unreachable statement"..\Main.m3", line 82: warning: unreachable statement"..\Main.m3", line 86: warning: unreachable statement"..\Main.m3", line 64: warning: unreachable statement8 warnings encountered -> linking pgm.exelink @_m3responsefile0.txt 2>&1 > pgm.lstmt /nologo /manifest pgm.exe.manifest /outputresource:pgm.exe;1.\pgm.exe >stdout.pgm.raw 2>stderr.pgm.raw
 
 
Does the order of the warnings matter?
Does the test even care if they are printed?
The expected output and the actual output are in a different order.
Neither are in order by line number, though the expected output is closer.
The order is consistent on all platforms?
No. LINUXLIBC6 and NT386 output in a different order.
This doesn't seem all that important..
 
  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From wagner at elegosoft.com  Sun May  4 13:46:25 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Sun, 04 May 2008 13:46:25 +0200
Subject: [M3devel] FW: NT386 jmpbuf size?
In-Reply-To: 
References: <20080503111742.D803370DA16@birch.elegosoft.com>
	
	<20080503170047.ocn9oj5li8gscg88@mail.elegosoft.com>
	
Message-ID: <20080504134625.az0c3vdkgs8gwsgk@mail.elegosoft.com>

Quoting Jay :

> I BELIEVE:
>   It is statically knowable:
>     msvcrt _setjmp uses 8 words
>     msvcrt _setjmp3 uses 16
>     cygwin uses I think 13 -- their header is just wrong by a factor of 4
>    You can tell from a mix of disassembly and source -- disassembly   
> for msvcrt, disassembly and source for cygwin.
>
> It isn't runtime variables that make the difference.
> (well, the 16 case might sometimes shrink, it appears)
>
> What is less clear is if _setjmp or _setjmp3 should be used.
> It appears that any use of setjmp in C or C++ uses _setjmp3.
>
> The difference appears to be whether or not the generally expected   
> interaction with C __finally and C++ destructors and exception   
> handling occurs.
> "generally expected' but also "generally unknown".
>
> One might argue that if C/C++ can afford the extra 32 bytes, then so  
>  can Modula-3 BUT C/C++ have MUCH more efficient exception handling   
> mechanisms available and so setjmp is much less used there. They get  
>  by with around 3 words for a frame with exception handling on x86,   
> and with zero overheard everywhere else.
>
> The C/C++ behavior might also be affected by command line options.   
> I'd have to experiment more..
>
> To clarify, imagine Modula-3 gave a callback function to some C++   
> and that C++ has a local with a destructor, and the Modula-3 raises   
> an exception.
> Does the C++ destructor run or not?
> With _setjmp probably not, with _setjmp3 probably.

IMO it should.

> Similarly, imagine some C++ gives some Modula-3 a callback and the   
> C++ raises an exception.
> Do the Modula-3 FINALLY blocks run?

Dito.

> Similar dilemna really on all platforms.
> There relatively recently an ABI for C++ exception handling that   
> maybe Modula-3 should use.

I think we should start on the safe side and try to optimize later
if needed. So I'd vote for 16 bytes and use of _setjmp3.

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 May  4 13:49:37 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Sun, 04 May 2008 13:49:37 +0200
Subject: [M3devel] order of warnings, or even to have any?
In-Reply-To: 
References: <20080503111742.D803370DA16@birch.elegosoft.com>
	
	<20080503170047.ocn9oj5li8gscg88@mail.elegosoft.com>
	
Message-ID: <20080504134937.ejznr1mcqo0sw0ck@mail.elegosoft.com>

Quoting Jay :

> C:\dev2\cm3\m3-sys\m3tests\src\p0\p004>cm3--- building in NT386 ---
> new source -> compiling Main.m3"..\Main.m3", line 35: warning:   
> exception is never raised: Main.e"..\Main.m3", line 9: warning:   
> exception is never raised: "..\Main.m3", line 59: warning:   
> unreachable statement"..\Main.m3", line 68: warning: unreachable   
> statement"..\Main.m3", line 71: warning: unreachable   
> statement"..\Main.m3", line 82: warning: unreachable   
> statement"..\Main.m3", line 86: warning: unreachable   
> statement"..\Main.m3", line 64: warning: unreachable statement8   
> warnings encountered -> linking pgm.exelink @_m3responsefile0.txt   
> 2>&1 > pgm.lstmt /nologo /manifest pgm.exe.manifest   
> /outputresource:pgm.exe;1.\pgm.exe >stdout.pgm.raw 2>stderr.pgm.raw
>
> Does the order of the warnings matter?
> Does the test even care if they are printed?
> The expected output and the actual output are in a different order.
> Neither are in order by line number, though the expected output is closer.
> The order is consistent on all platforms?
> No. LINUXLIBC6 and NT386 output in a different order.
> This doesn't seem all that important..

I had noticed that, too, and postponed it at not important (enough)
now to look into, though it would be interesting _why_ the error
output is different between platforms.

If there is a reason for it and it cannot be fixed easily within the
compiler, this would be one case for a target-specific expect file.

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 jayk123 at hotmail.com  Sun May  4 15:06:29 2008
From: jayk123 at hotmail.com (Jay)
Date: Sun, 4 May 2008 13:06:29 +0000
Subject: [M3devel] tinderbox diff direction reversed
Message-ID: 

fyi, I reversed the diff direction in m3tests.
It seems more natural to me to
diff expected actual
and see what changed.
Obviously it's not a huge difference (!), it works either way and no diff is the goal, but in case anyone was used to the other way or insists on it.
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From wagner at elegosoft.com  Sun May  4 15:19:30 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Sun, 04 May 2008 15:19:30 +0200
Subject: [M3devel] tinderbox diff direction reversed
In-Reply-To: 
References: 
Message-ID: <20080504151930.mwlopiv400s4c8ok@mail.elegosoft.com>

Quoting Jay :

> fyi, I reversed the diff direction in m3tests.
> It seems more natural to me to
> diff expected actual
> and see what changed.
> Obviously it's not a huge difference (!), it works either way and no  
>  diff is the goal, but in case anyone was used to the other way or   
> insists on it.

That's OK.

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



From hosking at cs.purdue.edu  Sun May  4 15:19:48 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 4 May 2008 09:19:48 -0400
Subject: [M3devel] order of warnings, or even to have any?
In-Reply-To: 
References: <20080503111742.D803370DA16@birch.elegosoft.com>
	
	<20080503170047.ocn9oj5li8gscg88@mail.elegosoft.com>
	
Message-ID: 

Why the difference on different targets?

Antony Hosking | Associate 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 May 4, 2008, at 7:17 AM, Jay wrote:

> C:\dev2\cm3\m3-sys\m3tests\src\p0\p004>cm3
> --- building in NT386 ---
> new source -> compiling Main.m3
> "..\Main.m3", line 35: warning: exception is never raised: Main.e
> "..\Main.m3", line 9: warning: exception is never raised: 
> "..\Main.m3", line 59: warning: unreachable statement
> "..\Main.m3", line 68: warning: unreachable statement
> "..\Main.m3", line 71: warning: unreachable statement
> "..\Main.m3", line 82: warning: unreachable statement
> "..\Main.m3", line 86: warning: unreachable statement
> "..\Main.m3", line 64: warning: unreachable statement
> 8 warnings encountered
>  -> linking pgm.exe
> link @_m3responsefile0.txt 2>&1 > pgm.lst
> mt /nologo /manifest pgm.exe.manifest /outputresource:pgm.exe;1
> .\pgm.exe >stdout.pgm.raw 2>stderr.pgm.raw
>
>
> Does the order of the warnings matter?
> Does the test even care if they are printed?
> The expected output and the actual output are in a different order.
> Neither are in order by line number, though the expected output is  
> closer.
> The order is consistent on all platforms?
> No. LINUXLIBC6 and NT386 output in a different order.
> This doesn't seem all that important..
>
>   - Jay
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sun May  4 15:24:58 2008
From: jayk123 at hotmail.com (Jay)
Date: Sun, 4 May 2008 13:24:58 +0000
Subject: [M3devel] order of warnings, or even to have any?
In-Reply-To: 
References: <20080503111742.D803370DA16@birch.elegosoft.com>
	
	<20080503170047.ocn9oj5li8gscg88@mail.elegosoft.com>
	
	
Message-ID: 

not yet known..


CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] order of warnings, or even to have any?Date: Sun, 4 May 2008 09:19:48 -0400Why the difference on different targets?



Antony Hosking | Associate 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 May 4, 2008, at 7:17 AM, Jay wrote:

C:\dev2\cm3\m3-sys\m3tests\src\p0\p004>cm3--- building in NT386 ---new source -> compiling Main.m3"..\Main.m3", line 35: warning: exception is never raised: Main.e"..\Main.m3", line 9: warning: exception is never raised: "..\Main.m3", line 59: warning: unreachable statement"..\Main.m3", line 68: warning: unreachable statement"..\Main.m3", line 71: warning: unreachable statement"..\Main.m3", line 82: warning: unreachable statement"..\Main.m3", line 86: warning: unreachable statement"..\Main.m3", line 64: warning: unreachable statement8 warnings encountered -> linking pgm.exelink @_m3responsefile0.txt 2>&1 > pgm.lstmt /nologo /manifest pgm.exe.manifest /outputresource:pgm.exe;1.\pgm.exe >stdout.pgm.raw 2>stderr.pgm.raw  Does the order of the warnings matter?Does the test even care if they are printed?The expected output and the actual output are in a different order.Neither are in order by line number, though the expected output is closer.The order is consistent on all platforms?No. LINUXLIBC6 and NT386 output in a different order.This doesn't seem all that important..   - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From wagner at elegosoft.com  Sun May  4 15:30:40 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Sun, 04 May 2008 15:30:40 +0200
Subject: [M3devel] Tinderbox tests on NT386
Message-ID: <20080504153040.6jvrkwlkms80c8wc@mail.elegosoft.com>

In case anybody wonders about

http://www.opencm3.net/m3tests/m3tests-NT386-2008-05-03-22-37-30.html

and following reports, I'm currently trying to run the m3tests on
NT386 in an older version to get a usable reference for the current
problems. There have been so many changes that I'm unable to keep
up with them, and some things seem to be broken.

Except for the problems in m3tests, the rest of the tinderbox
regression test framework seems to be working now for regular
regression tests on Windows XP with Cygwin. Some initialization
scripts are needed for running them, but that was to be expected.

The m3tests reports for the last two days for all target platforms
in the tinderbox are not correct (at least, if they show no errors);
there have been some structural changes and more things need to be
adapted. Jay Krell is working on it.

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 jayk123 at hotmail.com  Sun May  4 16:17:28 2008
From: jayk123 at hotmail.com (Jay)
Date: Sun, 4 May 2008 14:17:28 +0000
Subject: [M3devel] Tinderbox tests on NT386
In-Reply-To: <20080504153040.6jvrkwlkms80c8wc@mail.elegosoft.com>
References: <20080504153040.6jvrkwlkms80c8wc@mail.elegosoft.com>
Message-ID: 

Here is a QUICK rundown.
p004 I /assume/ this is the same on all platforms     but didn't check
p051 extra print out when building specific to NT386,     fixed, but at great loss of diagnosability IF     there are errors in compiling C code
Specifically, given  cl -nologo -c foo.c bar.cthe compiler printsfoo.cbar.c
to the same channel as errors (stderr or stdout)So when running the tests, NT386.common has a hack to throwout all C compiler output.
p116b floating point issue, probably same on all platformsp126 dittop172 dittop186 ditto
p204 compiler bug I think this also fails on other platforms but obviously differently; needs investigation
p205 was failing but I put in a fix and then Tony put in a better fix
 p206 I think this fails the same on all platforms, but I      I think it behaves correctly and just update the     std{out,err}.{pgm,build} files; since it is a compilation     failure, it should be an 'e' instead of 'p', not     a big deal I think
p207 probably fall out from longint not being 64 bits     probably should disable just for this platform 
r001 This test works in general but is a problem for the     Tinderbox in general. LINUXLIBC6 and NT386 should be     passing, but I think probably it should be turned off.     In particular, the way programs exit when they     fail an assertion and/or have an unhandled exception     varies by platform, in terms of what they actually print.
r002 needs investigation; I think it's an infinite recursion     or just uses a lot of stack, and I THINK I saw it fail     on other platforms 
r003 I hadn't looked at this AT ALL but probably the same as r001,     except more interesting?     There is a test that catches an assertion failure, maybe     do that here?     As well, there is the annoying idea of making per-platform      std* files. Hard to maintain.
 
r004 ditto -- since there are four of these, and potentially more,     maybe worth coming up with something
Something I considered, but rejected, back when I thought r001was the only one, is a runtime switch M3 at consistentAbort orsomesuch that will just cleanly exit(0) or exit(1) in these cases,and not print a callstack. I don't want to foul up thesystem TOO much for the sake of testing, but testabilityis an expected design goal...
Again, this is an issue across platforms. LINUXLIBC6 seems to print something slightly differently every time you run these. Test.common has a gross workaround.
 The checked in std* files are from FreeBSD.
e020 unknown so far
e026 was a problem on all platforms and should be ok now;     was a compiler bug, I fixed
e029 unknown so far
I think p209 and p210 are the most important currently.And then maybe e020, e029.
I expect to be "out" all of Sunday.
The Tinderbox SHOULD be OK now.Sorry...
 
 - Jay



> Date: Sun, 4 May 2008 15:30:40 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] Tinderbox tests on NT386> > In case anybody wonders about> > http://www.opencm3.net/m3tests/m3tests-NT386-2008-05-03-22-37-30.html> > and following reports, I'm currently trying to run the m3tests on> NT386 in an older version to get a usable reference for the current> problems. There have been so many changes that I'm unable to keep> up with them, and some things seem to be broken.> > Except for the problems in m3tests, the rest of the tinderbox> regression test framework seems to be working now for regular> regression tests on Windows XP with Cygwin. Some initialization> scripts are needed for running them, but that was to be expected.> > The m3tests reports for the last two days for all target platforms> in the tinderbox are not correct (at least, if they show no errors);> there have been some structural changes and more things need to be> adapted. Jay Krell is working on it.> > 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 jayk123 at hotmail.com  Sun May  4 16:22:57 2008
From: jayk123 at hotmail.com (Jay)
Date: Sun, 4 May 2008 14:22:57 +0000
Subject: [M3devel] Tinderbox tests on NT386
In-Reply-To: 
References: <20080504153040.6jvrkwlkms80c8wc@mail.elegosoft.com>
	
Message-ID: 

I'm also seeing lots of failures in p137
 
--- p137 --- bit insert and extract
--- ../src/p1/p137/stderr.pgm 2008-05-04 00:10:01.925067200 -0700+++ ../src/p1/p137/NT386/stderr.pgm 2008-05-04 03:59:42.382247900 -0700@@ -1,3 +1,418 @@+************************ ERROR: 282863103 instead of 819734015+************************ ERROR: 14427647 instead of 819734015...
lotsYou never saw that Olaf?
I should have printed the test names below, it's too hard to read with just numbers..
Anyway, just looking busy I guess, no matter, we'll get around to them..
(And sorry about the Win32 bitmap stuff, I haven't forgotten...)
 
Hm..maybe related? Older version of m3tests statically links to libm3/m3core but current version dynamically links.
That'd be cool if it correlates -- if p137 and the bitmap stuff are the same problem.
I'll go try p137 again both ways.
 - Jay


From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Sun, 4 May 2008 14:17:28 +0000Subject: Re: [M3devel] Tinderbox tests on NT386


Here is a QUICK rundown.p004 I /assume/ this is the same on all platforms     but didn't checkp051 extra print out when building specific to NT386,     fixed, but at great loss of diagnosability IF     there are errors in compiling C codeSpecifically, given  cl -nologo -c foo.c bar.cthe compiler printsfoo.cbar.cto the same channel as errors (stderr or stdout)So when running the tests, NT386.common has a hack to throwout all C compiler output.p116b floating point issue, probably same on all platformsp126 dittop172 dittop186 dittop204 compiler bug I think this also fails on other platforms but obviously differently; needs investigationp205 was failing but I put in a fix and then Tony put in a better fix p206 I think this fails the same on all platforms, but I      I think it behaves correctly and just update the     std{out,err}.{pgm,build} files; since it is a compilation     failure, it should be an 'e' instead of 'p', not     a big deal I thinkp207 probably fall out from longint not being 64 bits     probably should disable just for this platform r001 This test works in general but is a problem for the     Tinderbox in general. LINUXLIBC6 and NT386 should be     passing, but I think probably it should be turned off.     In particular, the way programs exit when they     fail an assertion and/or have an unhandled exception     varies by platform, in terms of what they actually print.r002 needs investigation; I think it's an infinite recursion     or just uses a lot of stack, and I THINK I saw it fail     on other platforms r003 I hadn't looked at this AT ALL but probably the same as r001,     except more interesting?     There is a test that catches an assertion failure, maybe     do that here?     As well, there is the annoying idea of making per-platform      std* files. Hard to maintain. r004 ditto -- since there are four of these, and potentially more,     maybe worth coming up with somethingSomething I considered, but rejected, back when I thought r001was the only one, is a runtime switch M3 at consistentAbort orsomesuch that will just cleanly exit(0) or exit(1) in these cases,and not print a callstack. I don't want to foul up thesystem TOO much for the sake of testing, but testabilityis an expected design goal...Again, this is an issue across platforms. LINUXLIBC6 seems to print something slightly differently every time you run these. Test.common has a gross workaround. The checked in std* files are from FreeBSD.e020 unknown so fare026 was a problem on all platforms and should be ok now;     was a compiler bug, I fixede029 unknown so farI think p209 and p210 are the most important currently.And then maybe e020, e029.I expect to be "out" all of Sunday.The Tinderbox SHOULD be OK now.Sorry...  - Jay

> Date: Sun, 4 May 2008 15:30:40 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] Tinderbox tests on NT386> > In case anybody wonders about> > http://www.opencm3.net/m3tests/m3tests-NT386-2008-05-03-22-37-30.html> > and following reports, I'm currently trying to run the m3tests on> NT386 in an older version to get a usable reference for the current> problems. There have been so many changes that I'm unable to keep> up with them, and some things seem to be broken.> > Except for the problems in m3tests, the rest of the tinderbox> regression test framework seems to be working now for regular> regression tests on Windows XP with Cygwin. Some initialization> scripts are needed for running them, but that was to be expected.> > The m3tests reports for the last two days for all target platforms> in the tinderbox are not correct (at least, if they show no errors);> there have been some structural changes and more things need to be> adapted. Jay Krell is working on it.> > 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 jayk123 at hotmail.com  Sun May  4 16:25:26 2008
From: jayk123 at hotmail.com (Jay)
Date: Sun, 4 May 2008 14:25:26 +0000
Subject: [M3devel] Tinderbox tests on NT386
In-Reply-To: 
References: <20080504153040.6jvrkwlkms80c8wc@mail.elegosoft.com>
	 
Message-ID: 

 > That'd be cool if it correlates. 
 > I'll go try p137 again both ways.  It does!
Standalone p137 and dynamic p137 have very different results.
 
 - Jay


From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comSubject: RE: [M3devel] Tinderbox tests on NT386Date: Sun, 4 May 2008 14:22:57 +0000


I'm also seeing lots of failures in p137 --- p137 --- bit insert and extract--- ../src/p1/p137/stderr.pgm 2008-05-04 00:10:01.925067200 -0700+++ ../src/p1/p137/NT386/stderr.pgm 2008-05-04 03:59:42.382247900 -0700@@ -1,3 +1,418 @@+************************ ERROR: 282863103 instead of 819734015+************************ ERROR: 14427647 instead of 819734015...lotsYou never saw that Olaf?I should have printed the test names below, it's too hard to read with just numbers..Anyway, just looking busy I guess, no matter, we'll get around to them..(And sorry about the Win32 bitmap stuff, I haven't forgotten...) Hm..maybe related? Older version of m3tests statically links to libm3/m3core but current version dynamically links.That'd be cool if it correlates -- if p137 and the bitmap stuff are the same problem.I'll go try p137 again both ways. - Jay


From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Sun, 4 May 2008 14:17:28 +0000Subject: Re: [M3devel] Tinderbox tests on NT386

Here is a QUICK rundown.p004 I /assume/ this is the same on all platforms     but didn't checkp051 extra print out when building specific to NT386,     fixed, but at great loss of diagnosability IF     there are errors in compiling C codeSpecifically, given  cl -nologo -c foo.c bar.cthe compiler printsfoo.cbar.cto the same channel as errors (stderr or stdout)So when running the tests, NT386.common has a hack to throwout all C compiler output.p116b floating point issue, probably same on all platformsp126 dittop172 dittop186 dittop204 compiler bug I think this also fails on other platforms but obviously differently; needs investigationp205 was failing but I put in a fix and then Tony put in a better fix p206 I think this fails the same on all platforms, but I      I think it behaves correctly and just update the     std{out,err}.{pgm,build} files; since it is a compilation     failure, it should be an 'e' instead of 'p', not     a big deal I thinkp207 probably fall out from longint not being 64 bits     probably should disable just for this platform r001 This test works in general but is a problem for the     Tinderbox in general. LINUXLIBC6 and NT386 should be     passing, but I think probably it should be turned off.     In particular, the way programs exit when they     fail an assertion and/or have an unhandled exception     varies by platform, in terms of what they actually print.r002 needs investigation; I think it's an infinite recursion     or just uses a lot of stack, and I THINK I saw it fail     on other platforms r003 I hadn't looked at this AT ALL but probably the same as r001,     except more interesting?     There is a test that catches an assertion failure, maybe     do that here?     As well, there is the annoying idea of making per-platform      std* files. Hard to maintain. r004 ditto -- since there are four of these, and potentially more,     maybe worth coming up with somethingSomething I considered, but rejected, back when I thought r001was the only one, is a runtime switch M3 at consistentAbort orsomesuch that will just cleanly exit(0) or exit(1) in these cases,and not print a callstack. I don't want to foul up thesystem TOO much for the sake of testing, but testabilityis an expected design goal...Again, this is an issue across platforms. LINUXLIBC6 seems to print something slightly differently every time you run these. Test.common has a gross workaround. The checked in std* files are from FreeBSD.e020 unknown so fare026 was a problem on all platforms and should be ok now;     was a compiler bug, I fixede029 unknown so farI think p209 and p210 are the most important currently.And then maybe e020, e029.I expect to be "out" all of Sunday.The Tinderbox SHOULD be OK now.Sorry...  - Jay

> Date: Sun, 4 May 2008 15:30:40 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] Tinderbox tests on NT386> > In case anybody wonders about> > http://www.opencm3.net/m3tests/m3tests-NT386-2008-05-03-22-37-30.html> > and following reports, I'm currently trying to run the m3tests on> NT386 in an older version to get a usable reference for the current> problems. There have been so many changes that I'm unable to keep> up with them, and some things seem to be broken.> > Except for the problems in m3tests, the rest of the tinderbox> regression test framework seems to be working now for regular> regression tests on Windows XP with Cygwin. Some initialization> scripts are needed for running them, but that was to be expected.> > The m3tests reports for the last two days for all target platforms> in the tinderbox are not correct (at least, if they show no errors);> there have been some structural changes and more things need to be> adapted. Jay Krell is working on it.> > 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 jayk123 at hotmail.com  Sun May  4 16:38:03 2008
From: jayk123 at hotmail.com (Jay)
Date: Sun, 4 May 2008 14:38:03 +0000
Subject: [M3devel] Tinderbox tests on NT386
In-Reply-To: 
References: <20080504153040.6jvrkwlkms80c8wc@mail.elegosoft.com>
	  
	
Message-ID: 

I bet this is related to importing (dynamically linking) data -- _lowbits. _highbits and such.
Dynamically linking data is a bad idea -- the codegen pretty much must vary depending on if you are going to statically link or dynamically link, whereas with functions you can just pretend you always statically link and it works out well enough, just with small lost optimization.
I don't see getting to this today but should be within a few days.
 
There is a compromise in that you can make all data that might be dynamically linked pointers to what the data otherwise would have been.
And then static linking is what loses efficiency -- unnecessary pointer deref.
Replace all foo with *pfoo, essentially.
 
The next step would be to change foo to *GetFoo(), even slower, but normal for dynamic linking.
 
So, anyway, I'll change __lowbits and such to pointers, on NT386.
I think somehow dynamic linking on other systems copes with this, but I bet it is not pretty if so.
Dynamic linking on NT writes to generally one page for .so to update one copy of a pointer to all the relevant addresses.
No writing walk through the code is needed.
If you are willing to walk through the code and patch it up, then you can dynamically link data without varying the code.
Or maybe just with -fPIC, all data references are slowed down, in case they are dynamically linked.
 
I wouldn't be surprised if this has been broken since 4.1..anytime m3core was dynamically linked on NT. Anyone want to try that?
I should have noticed this earlier, as I did go hunting around for how some of this works.
 
Anyway, I could be wrong.
We'll known soon enough now.
 
 - Jay


From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Sun, 4 May 2008 14:25:26 +0000Subject: Re: [M3devel] Tinderbox tests on NT386


 > That'd be cool if it correlates.  > I'll go try p137 again both ways.  It does!Standalone p137 and dynamic p137 have very different results.  - Jay


From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comSubject: RE: [M3devel] Tinderbox tests on NT386Date: Sun, 4 May 2008 14:22:57 +0000

I'm also seeing lots of failures in p137 --- p137 --- bit insert and extract--- ../src/p1/p137/stderr.pgm 2008-05-04 00:10:01.925067200 -0700+++ ../src/p1/p137/NT386/stderr.pgm 2008-05-04 03:59:42.382247900 -0700@@ -1,3 +1,418 @@+************************ ERROR: 282863103 instead of 819734015+************************ ERROR: 14427647 instead of 819734015...lotsYou never saw that Olaf?I should have printed the test names below, it's too hard to read with just numbers..Anyway, just looking busy I guess, no matter, we'll get around to them..(And sorry about the Win32 bitmap stuff, I haven't forgotten...) Hm..maybe related? Older version of m3tests statically links to libm3/m3core but current version dynamically links.That'd be cool if it correlates -- if p137 and the bitmap stuff are the same problem.I'll go try p137 again both ways. - Jay


From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Sun, 4 May 2008 14:17:28 +0000Subject: Re: [M3devel] Tinderbox tests on NT386

Here is a QUICK rundown.p004 I /assume/ this is the same on all platforms     but didn't checkp051 extra print out when building specific to NT386,     fixed, but at great loss of diagnosability IF     there are errors in compiling C codeSpecifically, given  cl -nologo -c foo.c bar.cthe compiler printsfoo.cbar.cto the same channel as errors (stderr or stdout)So when running the tests, NT386.common has a hack to throwout all C compiler output.p116b floating point issue, probably same on all platformsp126 dittop172 dittop186 dittop204 compiler bug I think this also fails on other platforms but obviously differently; needs investigationp205 was failing but I put in a fix and then Tony put in a better fix p206 I think this fails the same on all platforms, but I      I think it behaves correctly and just update the     std{out,err}.{pgm,build} files; since it is a compilation     failure, it should be an 'e' instead of 'p', not     a big deal I thinkp207 probably fall out from longint not being 64 bits     probably should disable just for this platform r001 This test works in general but is a problem for the     Tinderbox in general. LINUXLIBC6 and NT386 should be     passing, but I think probably it should be turned off.     In particular, the way programs exit when they     fail an assertion and/or have an unhandled exception     varies by platform, in terms of what they actually print.r002 needs investigation; I think it's an infinite recursion     or just uses a lot of stack, and I THINK I saw it fail     on other platforms r003 I hadn't looked at this AT ALL but probably the same as r001,     except more interesting?     There is a test that catches an assertion failure, maybe     do that here?     As well, there is the annoying idea of making per-platform      std* files. Hard to maintain. r004 ditto -- since there are four of these, and potentially more,     maybe worth coming up with somethingSomething I considered, but rejected, back when I thought r001was the only one, is a runtime switch M3 at consistentAbort orsomesuch that will just cleanly exit(0) or exit(1) in these cases,and not print a callstack. I don't want to foul up thesystem TOO much for the sake of testing, but testabilityis an expected design goal...Again, this is an issue across platforms. LINUXLIBC6 seems to print something slightly differently every time you run these. Test.common has a gross workaround. The checked in std* files are from FreeBSD.e020 unknown so fare026 was a problem on all platforms and should be ok now;     was a compiler bug, I fixede029 unknown so farI think p209 and p210 are the most important currently.And then maybe e020, e029.I expect to be "out" all of Sunday.The Tinderbox SHOULD be OK now.Sorry...  - Jay

> Date: Sun, 4 May 2008 15:30:40 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] Tinderbox tests on NT386> > In case anybody wonders about> > http://www.opencm3.net/m3tests/m3tests-NT386-2008-05-03-22-37-30.html> > and following reports, I'm currently trying to run the m3tests on> NT386 in an older version to get a usable reference for the current> problems. There have been so many changes that I'm unable to keep> up with them, and some things seem to be broken.> > Except for the problems in m3tests, the rest of the tinderbox> regression test framework seems to be working now for regular> regression tests on Windows XP with Cygwin. Some initialization> scripts are needed for running them, but that was to be expected.> > The m3tests reports for the last two days for all target platforms> in the tinderbox are not correct (at least, if they show no errors);> there have been some structural changes and more things need to be> adapted. Jay Krell is working on it.> > 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  Sun May  4 16:49:26 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Sun, 04 May 2008 16:49:26 +0200
Subject: [M3devel] Tinderbox tests on NT386
In-Reply-To: 
References: <20080504153040.6jvrkwlkms80c8wc@mail.elegosoft.com>
	
	
Message-ID: <20080504164926.ufqus5lpcg0o84gg@mail.elegosoft.com>

Quoting Jay :

> I'm also seeing lots of failures in p137
>
> --- p137 --- bit insert and extract
> --- ../src/p1/p137/stderr.pgm 2008-05-04 00:10:01.925067200 -0700+++  
>  ../src/p1/p137/NT386/stderr.pgm 2008-05-04 03:59:42.382247900   
> -0700@@ -1,3 +1,418 @@+************************ ERROR: 282863103   
> instead of 819734015+************************ ERROR: 14427647   
> instead of 819734015...
> lotsYou never saw that Olaf?

p137 was OK on 2008-05-01. Use

   http://www.opencm3.net/m3tests/m3tests-NT386-2008-05-03-22-37-30.html

as a reference; I won't overwrite that anymore now.
Current results of m3tests will be reported to

   http://www.opencm3.net/m3tests/m3tests-NT386-2008-05-03-22-37-31.html

soon (sorry for the wrong dates, I'm re-using existing workspaces
here; it would take too long otherwise).

I'll be out soon, but will have another look later this evening how
things develop.

Olaf


> I should have printed the test names below, it's too hard to read   
> with just numbers..
> Anyway, just looking busy I guess, no matter, we'll get around to them..
> (And sorry about the Win32 bitmap stuff, I haven't forgotten...)
>
> Hm..maybe related? Older version of m3tests statically links to   
> libm3/m3core but current version dynamically links.
> That'd be cool if it correlates -- if p137 and the bitmap stuff are   
> the same problem.
> I'll go try p137 again both ways.
>  - Jay
>
>
> From: jayk123 at hotmail.comTo: wagner at elegosoft.com;   
> m3devel at elegosoft.comDate: Sun, 4 May 2008 14:17:28 +0000Subject:   
> Re: [M3devel] Tinderbox tests on NT386
>
>
> Here is a QUICK rundown.p004 I /assume/ this is the same on all   
> platforms     but didn't checkp051 extra print out when building   
> specific to NT386,     fixed, but at great loss of diagnosability IF  
>      there are errors in compiling C codeSpecifically, given  cl   
> -nologo -c foo.c bar.cthe compiler printsfoo.cbar.cto the same   
> channel as errors (stderr or stdout)So when running the tests,   
> NT386.common has a hack to throwout all C compiler output.p116b   
> floating point issue, probably same on all platformsp126 dittop172   
> dittop186 dittop204 compiler bug I think this also fails on other   
> platforms but obviously differently; needs investigationp205 was   
> failing but I put in a fix and then Tony put in a better fix p206 I   
> think this fails the same on all platforms, but I      I think it   
> behaves correctly and just update the     std{out,err}.{pgm,build}   
> files; since it is a compilation     failure, it should be an 'e'   
> instead of 'p', not     a big deal I thinkp207 probably fall out   
> from longint not being 64 bits     probably should disable just for   
> this platform r001 This test works in general but is a problem for   
> the     Tinderbox in general. LINUXLIBC6 and NT386 should be       
> passing, but I think probably it should be turned off.     In   
> particular, the way programs exit when they     fail an assertion   
> and/or have an unhandled exception     varies by platform, in terms   
> of what they actually print.r002 needs investigation; I think it's   
> an infinite recursion     or just uses a lot of stack, and I THINK I  
>  saw it fail     on other platforms r003 I hadn't looked at this AT   
> ALL but probably the same as r001,     except more interesting?       
> There is a test that catches an assertion failure, maybe     do that  
>  here?     As well, there is the annoying idea of making  
> per-platform       std* files. Hard to maintain. r004 ditto -- since  
> there are  four of these, and potentially more,     maybe worth  
> coming up with  somethingSomething I considered, but rejected, back  
> when I thought  r001was the only one, is a runtime switch  
> M3 at consistentAbort  orsomesuch that will just cleanly exit(0) or  
> exit(1) in these  cases,and not print a callstack. I don't want to  
> foul up thesystem  TOO much for the sake of testing, but  
> testabilityis an expected  design goal...Again, this is an issue  
> across platforms. LINUXLIBC6  seems to print something slightly  
> differently every time you run  these. Test.common has a gross  
> workaround. The checked in std* files  are from FreeBSD.e020 unknown  
> so fare026 was a problem on all  platforms and should be ok now;      
> was a compiler bug, I fixede029  unknown so farI think p209 and p210  
> are the most important  currently.And then maybe e020, e029.I expect  
> to be "out" all of  Sunday.The Tinderbox SHOULD be OK now.Sorry...   
> - Jay
>
>> Date: Sun, 4 May 2008 15:30:40 +0200> From: wagner at elegosoft.com>   
>> To: m3devel at elegosoft.com> Subject: [M3devel] Tinderbox tests on   
>> NT386> > In case anybody wonders about> >   
>> http://www.opencm3.net/m3tests/m3tests-NT386-2008-05-03-22-37-30.html> >   
>> and following reports, I'm currently trying to run the m3tests on>   
>> NT386 in an older version to get a usable reference for the   
>> current> problems. There have been so many changes that I'm unable   
>> to keep> up with them, and some things seem to be broken.> > Except  
>>  for the problems in m3tests, the rest of the tinderbox> regression  
>>  test framework seems to be working now for regular> regression   
>> tests on Windows XP with Cygwin. Some initialization> scripts are   
>> needed for running them, but that was to be expected.> > The   
>> m3tests reports for the last two days for all target platforms> in   
>> the tinderbox are not correct (at least, if they show no errors);>   
>> there have been some structural changes and more things need to be>  
>>  adapted. Jay Krell is working on it.> > Olaf> -- > Olaf Wagner --   
>> elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12,   
>> 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177   
>> 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com |   
>> Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister:   
>> Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194>



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



From jayk123 at hotmail.com  Sun May  4 17:46:57 2008
From: jayk123 at hotmail.com (Jay)
Date: Sun, 4 May 2008 15:46:57 +0000
Subject: [M3devel] pixmap problem
In-Reply-To: 
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu> 
	
Message-ID: 

Randy, Please try with /current/ source, as of this morning Sunday May 4 -- the changes are ALL in NT386.common, so you MUST use MY config files, which are checked in verbatim, or you should be able edit whatever config files you are using.
 
(It's not really a config file issue, don't blame the general confusion people have with them.)
 
I'll try to try later, but I don't have the source right now, gotta look on other machines, and I think it's on a machine on loan.
  Or send it to me again.
I'd also like to know if this worked with 4.1, or with any release that offered dynamic linking to m3core.dll, on Windows.
  I recall a claim that it did. If today's change fixes it, I should be able to investigate 4.1.
3.6 did not have such linking.
If today's change does not help, well, I still plan on debugging it at some point..
 
If you aren't current and getting so is difficult, just send the attachment again, it's easy for me to test.
 
Thanks,
 - Jay


From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rcoleburn at scires.comDate: Sat, 19 Jan 2008 08:52:08 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem


I can repro the two different behaviors on XP.I was going to try on PPC_DARWIN but I guess Tony's info suffices. I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. Debugging here is a big humungous pain.NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)And bundles look pretty simple, a bundle is just a generated source file with a constant in it.Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something. The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for? I have to say this is very surprising. I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so.The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: pointer to msvcrt!fopenpointer to msvcrt!fclosenullpointer to kernel32!Sleep But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo.But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo.That doesn't work for data though. There's no ability to intervenve like that.So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it.And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.However that would suck perf in order to make an uncommon case work.I hope Modula-3 doesn't do that either. :)Though I guess since this global data in question...maybe it is rare??? Later, - Jay

> From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 03:09:47 -0500> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] pixmap problem> > Looks fine to me on I386_DARWIN.> > On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:> > > > 

Need to know the score, the latest news, or you need your Hotmail?-get your "fix" Check it out. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sun May  4 18:06:25 2008
From: jayk123 at hotmail.com (Jay)
Date: Sun, 4 May 2008 16:06:25 +0000
Subject: [M3devel] Tinderbox tests on NT386
In-Reply-To: <20080504164926.ufqus5lpcg0o84gg@mail.elegosoft.com>
References: <20080504153040.6jvrkwlkms80c8wc@mail.elegosoft.com>
	
	 
	<20080504164926.ufqus5lpcg0o84gg@mail.elegosoft.com>
Message-ID: 

Olaf, You have p137 failing now, which is/was consistent with me.And still p051 failing for you. I fixed that, but  the fix is half in NT386.common, and half in m3tests. You take that  for each build? The situation there is/was kind of  unfortunate -- all compiler output is quashed, errors and all.
  If we could have per-platform std* files,  this would be one to do that for. You know,  if stdout.pgm.PLATFORM exists, use it, otherwise stdout.pgm.  Problem is whenever the output changes, updating them all.
 
 - Jay



> Date: Sun, 4 May 2008 16:49:26 +0200> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: RE: [M3devel] Tinderbox tests on NT386> > Quoting Jay :> > > I'm also seeing lots of failures in p137> >> > --- p137 --- bit insert and extract> > --- ../src/p1/p137/stderr.pgm 2008-05-04 00:10:01.925067200 -0700+++ > > ../src/p1/p137/NT386/stderr.pgm 2008-05-04 03:59:42.382247900 > > -0700@@ -1,3 +1,418 @@+************************ ERROR: 282863103 > > instead of 819734015+************************ ERROR: 14427647 > > instead of 819734015...> > lotsYou never saw that Olaf?> > p137 was OK on 2008-05-01. Use> > http://www.opencm3.net/m3tests/m3tests-NT386-2008-05-03-22-37-30.html> > as a reference; I won't overwrite that anymore now.> Current results of m3tests will be reported to> > http://www.opencm3.net/m3tests/m3tests-NT386-2008-05-03-22-37-31.html> > soon (sorry for the wrong dates, I'm re-using existing workspaces> here; it would take too long otherwise).> > I'll be out soon, but will have another look later this evening how> things develop.> > Olaf> > > > I should have printed the test names below, it's too hard to read > > with just numbers..> > Anyway, just looking busy I guess, no matter, we'll get around to them..> > (And sorry about the Win32 bitmap stuff, I haven't forgotten...)> >> > Hm..maybe related? Older version of m3tests statically links to > > libm3/m3core but current version dynamically links.> > That'd be cool if it correlates -- if p137 and the bitmap stuff are > > the same problem.> > I'll go try p137 again both ways.> > - Jay> >> >> > From: jayk123 at hotmail.comTo: wagner at elegosoft.com; > > m3devel at elegosoft.comDate: Sun, 4 May 2008 14:17:28 +0000Subject: > > Re: [M3devel] Tinderbox tests on NT386> >> >> > Here is a QUICK rundown.p004 I /assume/ this is the same on all > > platforms but didn't checkp051 extra print out when building > > specific to NT386, fixed, but at great loss of diagnosability IF > > there are errors in compiling C codeSpecifically, given cl > > -nologo -c foo.c bar.cthe compiler printsfoo.cbar.cto the same > > channel as errors (stderr or stdout)So when running the tests, > > NT386.common has a hack to throwout all C compiler output.p116b > > floating point issue, probably same on all platformsp126 dittop172 > > dittop186 dittop204 compiler bug I think this also fails on other > > platforms but obviously differently; needs investigationp205 was > > failing but I put in a fix and then Tony put in a better fix p206 I > > think this fails the same on all platforms, but I I think it > > behaves correctly and just update the std{out,err}.{pgm,build} > > files; since it is a compilation failure, it should be an 'e' > > instead of 'p', not a big deal I thinkp207 probably fall out > > from longint not being 64 bits probably should disable just for > > this platform r001 This test works in general but is a problem for > > the Tinderbox in general. LINUXLIBC6 and NT386 should be > > passing, but I think probably it should be turned off. In > > particular, the way programs exit when they fail an assertion > > and/or have an unhandled exception varies by platform, in terms > > of what they actually print.r002 needs investigation; I think it's > > an infinite recursion or just uses a lot of stack, and I THINK I > > saw it fail on other platforms r003 I hadn't looked at this AT > > ALL but probably the same as r001, except more interesting? > > There is a test that catches an assertion failure, maybe do that > > here? As well, there is the annoying idea of making > > per-platform std* files. Hard to maintain. r004 ditto -- since > > there are four of these, and potentially more, maybe worth > > coming up with somethingSomething I considered, but rejected, back > > when I thought r001was the only one, is a runtime switch > > M3 at consistentAbort orsomesuch that will just cleanly exit(0) or > > exit(1) in these cases,and not print a callstack. I don't want to > > foul up thesystem TOO much for the sake of testing, but > > testabilityis an expected design goal...Again, this is an issue > > across platforms. LINUXLIBC6 seems to print something slightly > > differently every time you run these. Test.common has a gross > > workaround. The checked in std* files are from FreeBSD.e020 unknown > > so fare026 was a problem on all platforms and should be ok now; > > was a compiler bug, I fixede029 unknown so farI think p209 and p210 > > are the most important currently.And then maybe e020, e029.I expect > > to be "out" all of Sunday.The Tinderbox SHOULD be OK now.Sorry... > > - Jay> >> >> Date: Sun, 4 May 2008 15:30:40 +0200> From: wagner at elegosoft.com> > >> To: m3devel at elegosoft.com> Subject: [M3devel] Tinderbox tests on > >> NT386> > In case anybody wonders about> > > >> http://www.opencm3.net/m3tests/m3tests-NT386-2008-05-03-22-37-30.html> > > >> and following reports, I'm currently trying to run the m3tests on> > >> NT386 in an older version to get a usable reference for the > >> current> problems. There have been so many changes that I'm unable > >> to keep> up with them, and some things seem to be broken.> > Except > >> for the problems in m3tests, the rest of the tinderbox> regression > >> test framework seems to be working now for regular> regression > >> tests on Windows XP with Cygwin. Some initialization> scripts are > >> needed for running them, but that was to be expected.> > The > >> m3tests reports for the last two days for all target platforms> in > >> the tinderbox are not correct (at least, if they show no errors);> > >> there have been some structural changes and more things need to be> > >> adapted. Jay Krell is working on it.> > Olaf> -- > Olaf Wagner -- > >> elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, > >> 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 > >> 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | > >> Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: > >> Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194>> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Mon May  5 16:59:27 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Mon, 05 May 2008 10:59:27 -0400
Subject: [M3devel] pixmap problem
In-Reply-To: 
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
Message-ID: <481EE888.1E75.00D7.1@scires.com>

Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files
or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy

>>> Jay  5/4/2008 11:46 AM >>>
Randy, Please try with /current/ source, as of this morning Sunday May
4 -- the changes are ALL in NT386.common, so you MUST use MY config
files, which are checked in verbatim, or you should be able edit
whatever config files you are using.
 
(It's not really a config file issue, don't blame the general confusion
people have with them.)
 
I'll try to try later, but I don't have the source right now, gotta
look on other machines, and I think it's on a machine on loan.
  Or send it to me again.
I'd also like to know if this worked with 4.1, or with any release that
offered dynamic linking to m3core.dll, on Windows.
  I recall a claim that it did. If today's change fixes it, I should be
able to investigate 4.1.
3.6 did not have such linking.
If today's change does not help, well, I still plan on debugging it at
some point..
 
If you aren't current and getting so is difficult, just send the
attachment again, it's easy for me to test.
 
Thanks,
 - Jay

From: jayk123 at hotmail.com 
To: hosking at cs.purdue.edu; rcoleburn at scires.com 
Date: Sat, 19 Jan 2008 08:52:08 +0000
CC: m3devel at elegosoft.com 
Subject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.
I was going to try on PPC_DARWIN but I guess Tony's info suffices.
 
I tried rolling hand.c back to before I changed (months/year ago),
since it is involved in bit twiddling, no change, phew.
 
Debugging here is a big humungous pain.
NT386 has good stacks and line numbers, but no locals or type info, I'd
really sometime like to get Codeview info into those .objs...I think it
is documented well enough, but still not necessarily easy, or maybe have
a C generating backend partly for this reason (and to bring up more
targets, using native tools), and function calls in disassembly I think
don't resolve; NT386GNU can't yet build this, though it will soon, but
I'm not familiar with gdb and there appears to be no type info. I'm
building m3gdb right now, I don't know if it will work, I hope it has
type info, and I'm not familiar with the relevant code. In gdb I
struggle just to view bytes in memory, add numbers to addresses and see
those, etc. I think for MY problem, I'm going to link in C code to dump
the structs. There is tracing code and I enabled it, but even it crashes
in Text_Length. At least MY problem crashes, hopefully near the problem,
whereas your problem goes all the way through to completion with no
stopping to hint where the problem is. Darn it. :) on the mock rudeness
and :( on the lack of a crash.
 
You write the bundle out and it matches, so that doesn't rule out
bundles as being the problem? (darn)
And bundles look pretty simple, a bundle is just a generated source
file with a constant in it.
Maybe newline problems? That wouldn't make sense. I just downloaded
some program that might let me separately view the ppm, maybe it'll
reveal something.
 
The bad behavior has like regularly spaced solid color veritical bars a
few pixels side across the whole picture, and regularly spaced vertical
stripes from the correct picture alternating with that. Perhaps someone
with ppm/bitmap/graphics experience has seen this behavior and it
results from some common pixmap mismanagement we could look for?
 
I have to say this is very surprising.
 
I always wondered, and now I pretty much assume -- Modula-3 never
imports/exports data in its dynamic linking, right? It alway
imports/exports functions, right?
On Windows, functions have an optional optimization, but data must be
handled differently at compile time if it is going to be dynamically
imported.
For functions, if you don't apply the optimization at compile time, the
linker will just generate a single instruction thunk instead.
 
That is, given a symbol Foo, there is a symbol __imp__Foo that is a
pointer to the actual foo in another .dll/.so.
The loader only patches pointers, one per import if you build your .dll
correctly, it doesn't patch instructions or code strewn throughout a
.dll, just one contiguous array of pointers. MAYBE they don't have to be
contiguous for each .dl you import from.
 
That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my
.dll/.exe typically has an array:
 
pointer to msvcrt!fopen
pointer to msvcrt!fclose
null
pointer to kernel32!Sleep
 
But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not
be adjacent.
 
So, going back, my point/question is that, if the compiler knows the
function is imported, it can call through __imp__Foo instead of calling
Foo.
But if it calls Foo and you import Foo, the linker will create the
function Foo that just jmps through __imp__Foo.
That doesn't work for data though. There's no ability to intervenve
like that.
So for imported data, the compiler must generated a read and
dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to
be imported.
Data imports may be faster when appropriate, but for this reason, I'd
say they aren't worth it.
And for this reason, I HOPE Modula-3 never imports/exports data.
 
Oh, you could, for data, always reference the pointer __imp_Foo, and if
non materializes, create one.
However that would suck perf in order to make an uncommon case work.
I hope Modula-3 doesn't do that either. :)
Though I guess since this global data in question...maybe it is
rare???
 
Later,
 - Jay



> From: hosking at cs.purdue.edu 
> Date: Sat, 19 Jan 2008 03:09:47 -0500
> To: rcoleburn at scires.com 
> CC: m3devel at elegosoft.com 
> Subject: Re: [M3devel] pixmap problem
> 
> Looks fine to me on I386_DARWIN.
> 
> On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:
> 
> > 
> 


Need to know the score, the latest news, or you need your Hotmail*-get
your "fix" Check it out. ( http://www.msnmobilefix.com/Default.aspx ) 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TestPixmap.zip
Type: application/x-zip-compressed
Size: 4870 bytes
Desc: not available
URL: 

From rcoleburn at scires.com  Mon May  5 21:10:33 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Mon, 05 May 2008 15:10:33 -0400
Subject: [M3devel] build fails on NT386
References: <481EFC54.1E75.00D7.1@scires.com>
Message-ID: <481F2363.1E75.00D7.1@scires.com>

I have done a CVS update and decided to rebuild everything.
 
I used the script in scripts\win\upgrade.cmd
 
Here is a snippet of the output where it fails:
 
..\src\values => c:\cm3\pkg\m3front\src\values
  Module.i3         Module.m3         Value.i3          Value.m3
  ValueRep.i3       Constant.i3       Constant.m3       Decl.m3
  Decl.i3           EnumElt.i3        EnumElt.m3        Exceptionz.i3
  Exceptionz.m3     External.i3       External.m3       Field.i3
  Field.m3          Formal.i3         Formal.m3         Ident.i3
  Ident.m3          Method.m3         Method.i3         Procedure.i3
  Procedure.m3      Revelation.m3     Revelation.i3     Tipe.i3
  Tipe.m3           Variable.i3       Variable.m3
=== package C:\CM3_Sandbox\cm3\m3-sys\m3quake ===
+++ "cm3 -build  -DROOT=C:\\CM3_Sandbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_VER
SION_NUMBER=050700 -DCM3_LAST_CHANGED=2008-03-16 && cm3 -ship -DROOT=C:\\CM3_San
dbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_VERSION_NUMBER=050700 -DCM3_LAST_CHANG
ED=2008-03-16" +++
--- building in NT386 ---
 
ignoring ..\src\m3overrides
 
"C:\CM3_Sandbox\cm3\m3-sys\m3quake\src\m3makefile", line 14: quake runtime error
: unable to open "c:\cm3\pkg\sysutils\NT386\.M3EXPORTS" for reading
 
--procedure--  -line-  -file---
import             --  
include_dir        14  C:\CM3_Sandbox\cm3\m3-sys\m3quake\src\m3makefile
                    8  C:\CM3_Sandbox\cm3\m3-sys\m3quake\NT386\m3make.args
 
Fatal Error: package build failed
ERROR: "cm3 -build  -DROOT=C:\\CM3_Sandbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_
VERSION_NUMBER=050700 -DCM3_LAST_CHANGED=2008-03-16 && cm3 -ship -DROOT=C:\\CM3_
Sandbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_VERSION_NUMBER=050700 -DCM3_LAST_CH
ANGED=2008-03-16"
ERROR: cd C:\CM3_Sandbox\cm3\m3-sys\m3quake
ERROR: set INSTALLROOT=C:\cm3
 
C:\CM3_Sandbox\cm3\scripts\win>
 
Please advise.
 
Regards,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Mon May  5 21:21:36 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Mon, 05 May 2008 15:21:36 -0400
Subject: [M3devel] build fails on NT386
In-Reply-To: <481F2363.1E75.00D7.1@scires.com>
References: <481EFC54.1E75.00D7.1@scires.com> <481F2363.1E75.00D7.1@scires.com>
Message-ID: <481F25FA.1E75.00D7.1@scires.com>

Update:
 
I tried to get around the problem by manually building & shipping the sysutils package, then running scripts\win\upgrade.cmd again.
 
Now the build fails as shown below:
 
=== package C:\CM3_Sandbox\cm3\m3-sys\m3quake ===
+++ "cm3 -build  -DROOT=C:\\CM3_Sandbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_VER
SION_NUMBER=050700 -DCM3_LAST_CHANGED=2008-03-16 && cm3 -ship -DROOT=C:\\CM3_San
dbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_VERSION_NUMBER=050700 -DCM3_LAST_CHANG
ED=2008-03-16" +++
--- building in NT386 ---
 
ignoring ..\src\m3overrides
 
new source -> compiling Quake.i3
new source -> compiling QCompiler.i3
new source -> compiling QCode.i3
new source -> compiling QValue.i3
new source -> compiling QVSeq.i3
new source -> compiling QVTbl.i3
new source -> compiling QVal.i3
new source -> compiling QMachine.i3
new source -> compiling QToken.i3
new source -> compiling QIdent.i3
new source -> compiling Quake.m3
new source -> compiling QToken.m3
new source -> compiling QIdent.m3
new source -> compiling QScanner.i3
new source -> compiling QScanner.m3
new source -> compiling QCode.m3
new source -> compiling QCompiler.m3
new source -> compiling QValue.m3
new source -> compiling QVTbl.m3
new source -> compiling QVSeqRep.i3
new source -> compiling QVSeq.m3
 
Fatal Error: bad version stamps: SystemWin32.m3
 
version stamp mismatch: WinSock.gethostname
  <4ccceffe6a8d6438> => SystemWin32.m3
  <0e719d1414b51c34> => WinSock.i3
SystemWin32.m3: missing imported type: _te9593bef
ERROR: "cm3 -build  -DROOT=C:\\CM3_Sandbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_
VERSION_NUMBER=050700 -DCM3_LAST_CHANGED=2008-03-16 && cm3 -ship -DROOT=C:\\CM3_
Sandbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_VERSION_NUMBER=050700 -DCM3_LAST_CH
ANGED=2008-03-16"
ERROR: cd C:\CM3_Sandbox\cm3\m3-sys\m3quake
ERROR: set INSTALLROOT=C:\cm3
 
C:\CM3_Sandbox\cm3\scripts\win>
 
Please advise.
 
Regards,
Randy

>>> "Randy Coleburn"  5/5/2008 3:10 PM >>>
I have done a CVS update and decided to rebuild everything.
 
I used the script in scripts\win\upgrade.cmd
 
Here is a snippet of the output where it fails:
 
..\src\values => c:\cm3\pkg\m3front\src\values
  Module.i3         Module.m3         Value.i3          Value.m3
  ValueRep.i3       Constant.i3       Constant.m3       Decl.m3
  Decl.i3           EnumElt.i3        EnumElt.m3        Exceptionz.i3
  Exceptionz.m3     External.i3       External.m3       Field.i3
  Field.m3          Formal.i3         Formal.m3         Ident.i3
  Ident.m3          Method.m3         Method.i3         Procedure.i3
  Procedure.m3      Revelation.m3     Revelation.i3     Tipe.i3
  Tipe.m3           Variable.i3       Variable.m3
=== package C:\CM3_Sandbox\cm3\m3-sys\m3quake ===
+++ "cm3 -build  -DROOT=C:\\CM3_Sandbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_VER
SION_NUMBER=050700 -DCM3_LAST_CHANGED=2008-03-16 && cm3 -ship -DROOT=C:\\CM3_San
dbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_VERSION_NUMBER=050700 -DCM3_LAST_CHANG
ED=2008-03-16" +++
--- building in NT386 ---
 
ignoring ..\src\m3overrides
 
"C:\CM3_Sandbox\cm3\m3-sys\m3quake\src\m3makefile", line 14: quake runtime error
: unable to open "c:\cm3\pkg\sysutils\NT386\.M3EXPORTS" for reading
 
--procedure--  -line-  -file---
import             --  
include_dir        14  C:\CM3_Sandbox\cm3\m3-sys\m3quake\src\m3makefile
                    8  C:\CM3_Sandbox\cm3\m3-sys\m3quake\NT386\m3make.args
 
Fatal Error: package build failed
ERROR: "cm3 -build  -DROOT=C:\\CM3_Sandbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_
VERSION_NUMBER=050700 -DCM3_LAST_CHANGED=2008-03-16 && cm3 -ship -DROOT=C:\\CM3_
Sandbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_VERSION_NUMBER=050700 -DCM3_LAST_CH
ANGED=2008-03-16"
ERROR: cd C:\CM3_Sandbox\cm3\m3-sys\m3quake
ERROR: set INSTALLROOT=C:\cm3
 
C:\CM3_Sandbox\cm3\scripts\win>
 
Please advise.
 
Regards,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Mon May  5 23:13:15 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Mon, 05 May 2008 17:13:15 -0400
Subject: [M3devel] problems rebuilding everything
Message-ID: <481F4025.1E75.00D7.1@scires.com>

I think I've traced the problem rebuilding everything on WindowsXP to the sysutils package.
 
I don't think this package is getting built in the correct order when running the scripts in the scripts\win folder.
 
Can someone tell me the purpose and format of the scripts\pkginfo.txt file?  It would appear that this file has something to do with defining the build order.  In this file the sysutils entry is defined as:  sysutils core std
 
In looking at the m3makefile for this package, it appears to depend on:  libm3
 
When I run the scripts\win\upgrade.cmd file, I get to a point where an error occurs because sysutils has not been built.  If you then build sysutils and run the upgrade.cmd script again, you later get a version stamp mismatch problem.
 
Please advise on how to repair this problem.
 
Regards,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From wagner at elegosoft.com  Tue May  6 00:48:15 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 06 May 2008 00:48:15 +0200
Subject: [M3devel] pixmap problem
In-Reply-To: <481EE888.1E75.00D7.1@scires.com>
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
Message-ID: <20080506004815.p4vfoausgkcggsk0@mail.elegosoft.com>

Quoting Randy Coleburn :

> Jay:
>
> The TestPixmap.zip is attached.
>
> I will attempt to update all my sources and try again.
>
> Not sure what you mean when you say that I must use your config files
> or edit what I am using.  Please elaborate.

I think he simply means that the fix is in the config files,
and you must use his latest commits (cminstall/src/config/NT386*).

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 jayk123 at hotmail.com  Tue May  6 01:01:22 2008
From: jayk123 at hotmail.com (Jay)
Date: Mon, 5 May 2008 23:01:22 +0000
Subject: [M3devel] problems rebuilding everything
In-Reply-To: <481F4025.1E75.00D7.1@scires.com>
References: <481F4025.1E75.00D7.1@scires.com>
Message-ID: 


This is all normal stuff, not indicative of any real problem.
Please try scripts/python/upgrade.py.
I don't use scripts/win any longer.
The format of pkginfo.txt is incredibly simple:
  1) it is in a particular order 
  2) package name followed by groups it is in 
  almost everything is in "std".

The order of the file isn't necessarily correct for "upgrade", since you have to skip building anything that uses LONGINT and first build a compiler that understands LONGINT. (I'm working on a small change with the opposite requirement, but will instead avoid it, else cause too painful bootstrapping; the change is to provide HOST and HOST_OSTYPE in quake, but that's a dependency from m3quake to m3core, if done the expected way; I'll clone Compiler.tmpl instead, and rename the interfade).

  - Jay


Date: Mon, 5 May 2008 17:13:15 -0400
From: rcoleburn at scires.com
To: m3-support at elego.de; m3devel at elegosoft.com
Subject: [M3devel] problems rebuilding everything







I think I've traced the problem rebuilding everything on WindowsXP to the sysutils package.
 
I don't think this package is getting built in the correct order when running the scripts in the scripts\win folder.
 
Can someone tell me the purpose and format of the scripts\pkginfo.txt file?  It would appear that this file has something to do with defining the build order.  In this file the sysutils entry is defined as:  sysutils core std
 
In looking at the m3makefile for this package, it appears to depend on:  libm3
 
When I run the scripts\win\upgrade.cmd file, I get to a point where an error occurs because sysutils has not been built.  If you then build sysutils and run the upgrade.cmd script again, you later get a version stamp mismatch problem.
 
Please advise on how to repair this problem.
 
Regards,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Tue May  6 01:04:33 2008
From: jayk123 at hotmail.com (Jay)
Date: Mon, 5 May 2008 23:04:33 +0000
Subject: [M3devel] pixmap problem
In-Reply-To: <481EE888.1E75.00D7.1@scires.com>
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	 
	<481EE888.1E75.00D7.1@scires.com>
Message-ID: 


Thanks. I'll look into this tonight probably, as well as with 4.1 assuming I can find my binaries and source for it (probably).

COULD BE the pixmap problem is something else and 4.1 also has the problem I fixed. We'll see. No need to speculate (unless I can't find my 4.1).

 - Jay


Date: Mon, 5 May 2008 10:59:27 -0400
From: rcoleburn at scires.com
To: jayk123 at hotmail.com
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] pixmap problem







Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy

>>> Jay  5/4/2008 11:46 AM >>>
Randy, Please try with /current/ source, as of this morning Sunday May 4 -- the changes are ALL in NT386.common, so you MUST use MY config files, which are checked in verbatim, or you should be able edit whatever config files you are using.
 
(It's not really a config file issue, don't blame the general confusion people have with them.)
 
I'll try to try later, but I don't have the source right now, gotta look on other machines, and I think it's on a machine on loan.
  Or send it to me again.
I'd also like to know if this worked with 4.1, or with any release that offered dynamic linking to m3core.dll, on Windows.
  I recall a claim that it did. If today's change fixes it, I should be able to investigate 4.1.
3.6 did not have such linking.
If today's change does not help, well, I still plan on debugging it at some point..
 
If you aren't current and getting so is difficult, just send the attachment again, it's easy for me to test.
 
Thanks,
 - Jay




From: jayk123 at hotmail.com
To: hosking at cs.purdue.edu; rcoleburn at scires.com
Date: Sat, 19 Jan 2008 08:52:08 +0000
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] pixmap problem




I can repro the two different behaviors on XP.
I was going to try on PPC_DARWIN but I guess Tony's info suffices.
 
I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew.
 
Debugging here is a big humungous pain.
NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash.
 
You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)
And bundles look pretty simple, a bundle is just a generated source file with a constant in it.
Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something.
 
The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for?
 
I have to say this is very surprising.
 
I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?
On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.
For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead.
 
That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so.
The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from.
 
That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array:
 
pointer to msvcrt!fopen
pointer to msvcrt!fclose
null
pointer to kernel32!Sleep
 
But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent.
 
So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo.
But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo.
That doesn't work for data though. There's no ability to intervenve like that.
So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.
Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it.
And for this reason, I HOPE Modula-3 never imports/exports data.
 
Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.
However that would suck perf in order to make an uncommon case work.
I hope Modula-3 doesn't do that either. :)
Though I guess since this global data in question...maybe it is rare???
 
Later,
 - Jay





> From: hosking at cs.purdue.edu
> Date: Sat, 19 Jan 2008 03:09:47 -0500
> To: rcoleburn at scires.com
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] pixmap problem
> 
> Looks fine to me on I386_DARWIN.
> 
> On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:
> 
> > 
> 




Need to know the score, the latest news, or you need your Hotmail?-get your "fix" Check it out. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Tue May  6 03:01:10 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Mon, 05 May 2008 21:01:10 -0400
Subject: [M3devel] new problem linking on NT386
Message-ID: <481F7590.1E75.00D7.1@scires.com>

I've rebuild my cm3 system using the latest sources.
 
I am now having a failure linking certain programs that used to build without problems.
 
I've listed the linker output from one of the programs below.  The issue seems to be an unresolved external symbol _WinMain at 16 .
 
Any ideas on what has changed and how to get this working again?
 
Microsoft (R) Incremental Linker Version 9.00.21022.08
Copyright (C) Microsoft Corporation.  All rights reserved.
 
/out:CV_MessageTool.exe 
/subsystem:windows 
/entry:WinMainCRTStartup 
/nodefaultlib 
/debug 
/incremental:no 
/opt:ref 
/delayload:wsock32.dll 
/delayload:advapi32.dll 
/delayload:gdi32.dll 
/delayload:netapi32.dll 
/delayload:user32.dll 
/delayload:comctl32.dll 
delayimp.lib 
_m3main.obj 
iconRes.obj 
Resources.io 
Resources.mo 
Main.mo 
C:\cm3\pkg\windowsResources\NT386\windowsResources.lib 
C:\cm3\pkg\libSciRes3\NT386\libSciRes3.lib 
C:\cm3\pkg\stable\NT386\stable.lib 
C:\cm3\pkg\serial2\NT386\serial2.lib 
C:\cm3\pkg\netobj\NT386\m3netobj.lib 
C:\cm3\pkg\parseparams\NT386\m3parseparams.lib 
C:\cm3\pkg\formsvbt\NT386\m3formsvbt.lib 
C:\cm3\pkg\videovbt\NT386\videovbt.lib 
C:\cm3\pkg\jvideo\NT386\jvideo.lib 
C:\cm3\pkg\web\NT386\web.lib 
C:\cm3\pkg\tcp\NT386\m3tcp.lib 
C:\cm3\pkg\formsvbtpixmaps\NT386\m3formsvbtpixmaps.lib 
C:\cm3\pkg\vbtkit\NT386\m3vbtkit.lib 
C:\cm3\pkg\ui\NT386\m3ui.lib 
C:\cm3\pkg\libm3\NT386\m3.lib 
C:\cm3\pkg\m3core\NT386\m3core.lib 
winspool.lib 
comctl32.lib 
wsock32.lib 
comdlg32.lib 
netapi32.lib 
gdi32.lib 
user32.lib 
advapi32.lib 
kernel32.lib 
msvcrt.lib 
LINK : warning LNK4199: /DELAYLOAD:wsock32.dll ignored; no imports found from wsock32.dll
LINK : warning LNK4199: /DELAYLOAD:advapi32.dll ignored; no imports found from advapi32.dll
LINK : warning LNK4199: /DELAYLOAD:gdi32.dll ignored; no imports found from gdi32.dll
LINK : warning LNK4199: /DELAYLOAD:netapi32.dll ignored; no imports found from netapi32.dll
LINK : warning LNK4199: /DELAYLOAD:user32.dll ignored; no imports found from user32.dll
LINK : warning LNK4199: /DELAYLOAD:comctl32.dll ignored; no imports found from comctl32.dll
msvcrt.lib(crtexew.obj) : error LNK2019: unresolved external symbol _WinMain at 16 referenced in function ___tmainCRTStartup
CV_MessageTool.exe : fatal error LNK1120: 1 unresolved externals
Regards,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Tue May  6 03:18:12 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Mon, 05 May 2008 21:18:12 -0400
Subject: [M3devel] pixmap problem
In-Reply-To: 
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
Message-ID: <481F798E.1E75.00D7.1@scires.com>

Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly
when the buildstandalone() directive is used.
 
Regards,
Randy

>>> Jay  5/5/2008 7:04 PM >>>
Thanks. I'll look into this tonight probably, as well as with 4.1
assuming I can find my binaries and source for it (probably).

COULD BE the pixmap problem is something else and 4.1 also has the
problem I fixed. We'll see. No need to speculate (unless I can't find my
4.1).

 - Jay


Date: Mon, 5 May 2008 10:59:27 -0400
From: rcoleburn at scires.com 
To: jayk123 at hotmail.com 
CC: m3devel at elegosoft.com 
Subject: RE: [M3devel] pixmap problem

Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files
or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy

>>> Jay  5/4/2008 11:46 AM >>>
Randy, Please try with /current/ source, as of this morning Sunday May
4 -- the changes are ALL in NT386.common, so you MUST use MY config
files, which are checked in verbatim, or you should be able edit
whatever config files you are using.
 
(It's not really a config file issue, don't blame the general confusion
people have with them.)
 
I'll try to try later, but I don't have the source right now, gotta
look on other machines, and I think it's on a machine on loan.
  Or send it to me again.
I'd also like to know if this worked with 4.1, or with any release that
offered dynamic linking to m3core.dll, on Windows.
  I recall a claim that it did. If today's change fixes it, I should be
able to investigate 4.1.
3.6 did not have such linking.
If today's change does not help, well, I still plan on debugging it at
some point..
 
If you aren't current and getting so is difficult, just send the
attachment again, it's easy for me to test.
 
Thanks,
 - Jay

From: jayk123 at hotmail.com 
To: hosking at cs.purdue.edu; rcoleburn at scires.com 
Date: Sat, 19 Jan 2008 08:52:08 +0000
CC: m3devel at elegosoft.com 
Subject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.
I was going to try on PPC_DARWIN but I guess Tony's info suffices.
 
I tried rolling hand.c back to before I changed (months/year ago),
since it is involved in bit twiddling, no change, phew.
 
Debugging here is a big humungous pain.
NT386 has good stacks and line numbers, but no locals or type info, I'd
really sometime like to get Codeview info into those .objs...I think it
is documented well enough, but still not necessarily easy, or maybe have
a C generating backend partly for this reason (and to bring up more
targets, using native tools), and function calls in disassembly I think
don't resolve; NT386GNU can't yet build this, though it will soon, but
I'm not familiar with gdb and there appears to be no type info. I'm
building m3gdb right now, I don't know if it will work, I hope it has
type info, and I'm not familiar with the relevant code. In gdb I
struggle just to view bytes in memory, add numbers to addresses and see
those, etc. I think for MY problem, I'm going to link in C code to dump
the structs. There is tracing code and I enabled it, but even it crashes
in Text_Length. At least MY problem crashes, hopefully near the problem,
whereas your problem goes all the way through to completion with no
stopping to hint where the problem is. Darn it. :) on the mock rudeness
and :( on the lack of a crash.
 
You write the bundle out and it matches, so that doesn't rule out
bundles as being the problem? (darn)
And bundles look pretty simple, a bundle is just a generated source
file with a constant in it.
Maybe newline problems? That wouldn't make sense. I just downloaded
some program that might let me separately view the ppm, maybe it'll
reveal something.
 
The bad behavior has like regularly spaced solid color veritical bars a
few pixels side across the whole picture, and regularly spaced vertical
stripes from the correct picture alternating with that. Perhaps someone
with ppm/bitmap/graphics experience has seen this behavior and it
results from some common pixmap mismanagement we could look for?
 
I have to say this is very surprising.
 
I always wondered, and now I pretty much assume -- Modula-3 never
imports/exports data in its dynamic linking, right? It alway
imports/exports functions, right?
On Windows, functions have an optional optimization, but data must be
handled differently at compile time if it is going to be dynamically
imported.
For functions, if you don't apply the optimization at compile time, the
linker will just generate a single instruction thunk instead.
 
That is, given a symbol Foo, there is a symbol __imp__Foo that is a
pointer to the actual foo in another .dll/.so.
The loader only patches pointers, one per import if you build your .dll
correctly, it doesn't patch instructions or code strewn throughout a
.dll, just one contiguous array of pointers. MAYBE they don't have to be
contiguous for each .dl you import from.
 
That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my
.dll/.exe typically has an array:
 
pointer to msvcrt!fopen
pointer to msvcrt!fclose
null
pointer to kernel32!Sleep
 
But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not
be adjacent.
 
So, going back, my point/question is that, if the compiler knows the
function is imported, it can call through __imp__Foo instead of calling
Foo.
But if it calls Foo and you import Foo, the linker will create the
function Foo that just jmps through __imp__Foo.
That doesn't work for data though. There's no ability to intervenve
like that.
So for imported data, the compiler must generated a read and
dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to
be imported.
Data imports may be faster when appropriate, but for this reason, I'd
say they aren't worth it.
And for this reason, I HOPE Modula-3 never imports/exports data.
 
Oh, you could, for data, always reference the pointer __imp_Foo, and if
non materializes, create one.
However that would suck perf in order to make an uncommon case work.
I hope Modula-3 doesn't do that either. :)
Though I guess since this global data in question...maybe it is
rare???
 
Later,
 - Jay



> From: hosking at cs.purdue.edu 
> Date: Sat, 19 Jan 2008 03:09:47 -0500
> To: rcoleburn at scires.com 
> CC: m3devel at elegosoft.com 
> Subject: Re: [M3devel] pixmap problem
> 
> Looks fine to me on I386_DARWIN.
> 
> On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:
> 
> > 
> 


Need to know the score, the latest news, or you need your Hotmail*-get
your "fix" Check it out. ( http://www.msnmobilefix.com/Default.aspx ) 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From dabenavidesd at yahoo.es  Tue May  6 03:46:27 2008
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 6 May 2008 03:46:27 +0200 (CEST)
Subject: [M3devel] www.opencm3.net/m3tests
Message-ID: <313767.59466.qm@web27115.mail.ukl.yahoo.com>

Dear developers:
Does the recent tests on NT386 seem broken because a recent change on the m3-sys tree, or is the HTML bad generated, I mean can you check the last tests Sunday, May 4th (p001 to p042) has a red background 
http://www.opencm3.net/m3tests/m3tests-NT386-2008-04-23-13-30-57.html
p002 Text
Comparing files P0\P002\stdout.build and ..\SRC\P0\P002\STDOUT.BUILD
***** P0\P002\stdout.build
link @_m3responsefile0.txt 2>&1 > pgm.lst
mt /nologo /manifest pgm.exe.manifest /outputresource:pgm.exe;1
***** ..\SRC\P0\P002\STDOUT.BUILD
*****

Comparing files P0\P002\stderr.build and ..\SRC\P0\P002\STDERR.BUILD
FC: no differences encountered

Comparing files P0\P002\stdout.pgm and ..\SRC\P0\P002\STDOUT.PGM
FC: no differences encountered

Comparing files P0\P002\stderr.pgm and ..\SRC\P0\P002\STDERR.PGM
FC: no differences encountered
and almost the same pattern in the above tests.

I would suggest if it is thinkable using NT386 variant with a complete dedicated machine/system, I can try to set up one this week and send the data back (the machine is behind a proxy), but I don't remember the mail explaining the set up, and also want to know if there is a chance of run the tests with one run script.
Also what is the best natural way to put a new tests, and the standard name it should have?


Thanks

       
---------------------------------

Enviado desde Correo Yahoo!
La bandeja de entrada m?s inteligente.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Tue May  6 03:47:17 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 6 May 2008 01:47:17 +0000
Subject: [M3devel] new problem linking on NT386
In-Reply-To: <481F7590.1E75.00D7.1@scires.com>
References: <481F7590.1E75.00D7.1@scires.com>
Message-ID: 

Sounds like you missed the "gui" switch on the cm3 command lineor in the m3makefile -- in the m3makefile really.Putting it on the command line imho is only reasonable for thosesimple cases that don't have an m3makefile
 link -dump -symbols NT386\_m3main.obj | findstr /i main 
?I expect you will have main or wmain, but not WinMain or wWinMain.
 
Is this meant to be a gui app or a command line app?
If it is meant to be a command line, then the problem is something else.
  And I don't even want to explain..
Can you send me the source?
 
Also you are missing hand.obj here, so you don't have the potential pixmap fix.
 - Jay


Date: Mon, 5 May 2008 21:01:10 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: [M3devel] new problem linking on NT386

I've rebuild my cm3 system using the latest sources.
 
I am now having a failure linking certain programs that used to build without problems.
 
I've listed the linker output from one of the programs below.  The issue seems to be an unresolved external symbol _WinMain at 16 .
 
Any ideas on what has changed and how to get this working again?
 
Microsoft (R) Incremental Linker Version 9.00.21022.08Copyright (C) Microsoft Corporation.  All rights reserved.
 
/out:CV_MessageTool.exe /subsystem:windows /entry:WinMainCRTStartup /nodefaultlib /debug /incremental:no /opt:ref /delayload:wsock32.dll /delayload:advapi32.dll /delayload:gdi32.dll /delayload:netapi32.dll /delayload:user32.dll /delayload:comctl32.dll delayimp.lib _m3main.obj iconRes.obj Resources.io Resources.mo Main.mo C:\cm3\pkg\windowsResources\NT386\windowsResources.lib C:\cm3\pkg\libSciRes3\NT386\libSciRes3.lib C:\cm3\pkg\stable\NT386\stable.lib C:\cm3\pkg\serial2\NT386\serial2.lib C:\cm3\pkg\netobj\NT386\m3netobj.lib C:\cm3\pkg\parseparams\NT386\m3parseparams.lib C:\cm3\pkg\formsvbt\NT386\m3formsvbt.lib C:\cm3\pkg\videovbt\NT386\videovbt.lib C:\cm3\pkg\jvideo\NT386\jvideo.lib C:\cm3\pkg\web\NT386\web.lib C:\cm3\pkg\tcp\NT386\m3tcp.lib C:\cm3\pkg\formsvbtpixmaps\NT386\m3formsvbtpixmaps.lib C:\cm3\pkg\vbtkit\NT386\m3vbtkit.lib C:\cm3\pkg\ui\NT386\m3ui.lib C:\cm3\pkg\libm3\NT386\m3.lib C:\cm3\pkg\m3core\NT386\m3core.lib winspool.lib comctl32.lib wsock32.lib comdlg32.lib netapi32.lib gdi32.lib user32.lib advapi32.lib kernel32.lib msvcrt.lib LINK : warning LNK4199: /DELAYLOAD:wsock32.dll ignored; no imports found from wsock32.dllLINK : warning LNK4199: /DELAYLOAD:advapi32.dll ignored; no imports found from advapi32.dllLINK : warning LNK4199: /DELAYLOAD:gdi32.dll ignored; no imports found from gdi32.dllLINK : warning LNK4199: /DELAYLOAD:netapi32.dll ignored; no imports found from netapi32.dllLINK : warning LNK4199: /DELAYLOAD:user32.dll ignored; no imports found from user32.dllLINK : warning LNK4199: /DELAYLOAD:comctl32.dll ignored; no imports found from comctl32.dllmsvcrt.lib(crtexew.obj) : error LNK2019: unresolved external symbol _WinMain at 16 referenced in function ___tmainCRTStartupCV_MessageTool.exe : fatal error LNK1120: 1 unresolved externals
Regards,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Tue May  6 03:54:52 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 6 May 2008 01:54:52 +0000
Subject: [M3devel] pixmap problem
In-Reply-To: <481F798E.1E75.00D7.1@scires.com>
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	 
	<481F798E.1E75.00D7.1@scires.com>
Message-ID: 

And you took the updated config file?
The way you can tell is that, roughly speaking, hand.obj should be in NT386\_m3responsefile0.txt.
Or _m3responsefile1.txt, or, well, somewhere.
Anyway, I think I saw the attachment, I can check later..and with 4.1 as I said..
 
I can see about making the fix not depend on config file changes...but it's not terrible asis, and I'd really like to merge more of the quake code into cm3.exe..
 
 - Jay


Date: Mon, 5 May 2008 21:18:12 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem

Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly when the buildstandalone() directive is used.
 
Regards,
Randy>>> Jay  5/5/2008 7:04 PM >>>Thanks. I'll look into this tonight probably, as well as with 4.1 assuming I can find my binaries and source for it (probably).COULD BE the pixmap problem is something else and 4.1 also has the problem I fixed. We'll see. No need to speculate (unless I can't find my 4.1). - Jay


Date: Mon, 5 May 2008 10:59:27 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problem
Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy>>> Jay  5/4/2008 11:46 AM >>>Randy, Please try with /current/ source, as of this morning Sunday May 4 -- the changes are ALL in NT386.common, so you MUST use MY config files, which are checked in verbatim, or you should be able edit whatever config files you are using. (It's not really a config file issue, don't blame the general confusion people have with them.) I'll try to try later, but I don't have the source right now, gotta look on other machines, and I think it's on a machine on loan.  Or send it to me again.I'd also like to know if this worked with 4.1, or with any release that offered dynamic linking to m3core.dll, on Windows.  I recall a claim that it did. If today's change fixes it, I should be able to investigate 4.1.3.6 did not have such linking.If today's change does not help, well, I still plan on debugging it at some point.. If you aren't current and getting so is difficult, just send the attachment again, it's easy for me to test. Thanks, - Jay


From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rcoleburn at scires.comDate: Sat, 19 Jan 2008 08:52:08 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.I was going to try on PPC_DARWIN but I guess Tony's info suffices. I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. Debugging here is a big humungous pain.NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)And bundles look pretty simple, a bundle is just a generated source file with a constant in it.Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something. The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for? I have to say this is very surprising. I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so.The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: pointer to msvcrt!fopenpointer to msvcrt!fclosenullpointer to kernel32!Sleep But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo.But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo.That doesn't work for data though. There's no ability to intervenve like that.So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it.And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.However that would suck perf in order to make an uncommon case work.I hope Modula-3 doesn't do that either. :)Though I guess since this global data in question...maybe it is rare??? Later, - Jay

> From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 03:09:47 -0500> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] pixmap problem> > Looks fine to me on I386_DARWIN.> > On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:> > > > 

Need to know the score, the latest news, or you need your Hotmail?-get your "fix" Check it out. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Tue May  6 04:01:17 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 6 May 2008 02:01:17 +0000
Subject: [M3devel] www.opencm3.net/m3tests
In-Reply-To: <313767.59466.qm@web27115.mail.ukl.yahoo.com>
References: <313767.59466.qm@web27115.mail.ukl.yahoo.com>
Message-ID: 

The "problem" here, a really really small one, is just that the link and mt commands got echoed.
Olaf made them not echoed. I then made them conditionally echoed.
  I made m3-sys\m3tests define M3TESTS so that NT386.common doesn't echo.
It's not a big deal either way.
Aha -- tests in other directories would have a problem, and I think there are some.
 
I like more echoing usually, so the system explains what is going on,
instead of the vaguer "linking foo" sort of message.
Granted, nobody bothers watching gcc run assembler commands, so I guess it is just quite gray.
 
I don't know how to run the Tinderbox either yet, sorry.
I tried.
 
For adding tests, well, there is m3-sys\m3tests.
That is where a lot of the tests are, but not all.
I am not sure where tests belong. I added a small number there.
They are named with just a letter and a number.
The letters have some meaning, explained in the m3makefile.
"p" is programs that are run and their stdout/stderr compared against expected
"e" is programs build and the errors from the compiler checked to be reasonable.
  I don't think in general they are expected to successfully compile or run, though the case of "warnings" may be unclear.
"c" is programs built so a human can look at the generated code.
There is another case I think for human checking.
The numbers are just 001, 002, 003, etc.
Each hundred tests are in a separate directory, like p0\p001, p0\p002, p1\p100, p1\101, etc. 
 
Something like this.
Wherever I have details wrong, just look in m3-sys\m3tests. It's pretty simple, obvious, and well commented.
 
The output is a little clearer if you have a working diff.exe on the path.
Then what you do is search for "@@" in the output.
 
 - Jay


Date: Tue, 6 May 2008 03:46:27 +0200From: dabenavidesd at yahoo.esTo: m3devel at elegosoft.comSubject: [M3devel] www.opencm3.net/m3testsDear developers:Does the recent tests on NT386 seem broken because a recent change on the m3-sys tree, or is the HTML bad generated, I mean can you check the last tests Sunday, May 4th (p001 to p042) has a red background http://www.opencm3.net/m3tests/m3tests-NT386-2008-04-23-13-30-57.html
p002 Text
Comparing files P0\P002\stdout.build and ..\SRC\P0\P002\STDOUT.BUILD***** P0\P002\stdout.buildlink @_m3responsefile0.txt 2>&1 > pgm.lstmt /nologo /manifest pgm.exe.manifest /outputresource:pgm.exe;1***** ..\SRC\P0\P002\STDOUT.BUILD*****Comparing files P0\P002\stderr.build and ..\SRC\P0\P002\STDERR.BUILDFC: no differences encounteredComparing files P0\P002\stdout.pgm and ..\SRC\P0\P002\STDOUT.PGMFC: no differences encounteredComparing files P0\P002\stderr.pgm and ..\SRC\P0\P002\STDERR.PGMFC: no differences encounteredand almost the same pattern in the above tests.I would suggest if it is thinkable using NT386 variant with a complete dedicated machine/system, I can try to set up one this week and send the data back (the machine is behind a proxy), but I don't remember the mail explaining the set up, and also want to know if there is a chance of run the tests with one run script.Also what is the best natural way to put a new tests, and the standard name it should have?Thanks


Enviado desde Correo Yahoo!La bandeja de entrada m?s inteligente.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Tue May  6 04:08:29 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Mon, 05 May 2008 22:08:29 -0400
Subject: [M3devel] new problem linking on NT386
In-Reply-To: 
References: <481F7590.1E75.00D7.1@scires.com>
	
Message-ID: <481F8557.1E75.00D7.1@scires.com>

Jay:
 
No, I am using the -gui option in the m3makefile.  It is a windows gui application.
 
Here is the output of the command you suggested:
 
Microsoft (R) COFF/PE Dumper Version 9.00.21022.08
Copyright (C) Microsoft Corporation.  All rights reserved.
 

Dump of file NT386\_m3main.obj
 
File Type: COFF OBJECT
 
COFF SYMBOL TABLE
000 00000000 DEBUG  notype       Filename     | .file
    _m3main.mc
002 00000000 SECT1  notype       Static       | .text
    Section length   50, #relocs    4, #linenums    7, checksum        0
004 00000000 SECT2  notype       Static       | .data
    Section length   10, #relocs    3, #linenums    0, checksum        0
006 00000000 SECT3  notype       Static       | .bss
    Section length    0, #relocs    0, #linenums    0, checksum        0
008 00000000 SECT1  notype ()    External     | _main
    tag index 0000000A size 00000050 lines 00000104 next function 00000000
00A 00000000 SECT1  notype       BeginFunction | .bf
    line# 0000 end 00000000
00C 00000007 SECT1  notype       .bf or.ef    | .lf
00D 00000050 SECT1  notype       EndFunction  | .ef
    line# 0006
00F 00000000 SECT1  notype       Static       | TextSegment
010 00000000 UNDEF  notype       External     | _Main_M3
011 00000000 UNDEF  notype       External     | _RTLinker__InitRuntime
012 00000000 UNDEF  notype       External     | _RTLinker__AddUnit
013 00000000 UNDEF  notype       External     | _RTProcess__Exit
014 00000004 SECT2  notype       Static       | T$14
 
String Table Size = 0x4B bytes
 
  Summary
 
           0 .bss
          10 .data
          50 .text
As you can see, I have an
   _main  and a
   _Main_M3
 
Not sure what you mean by saying I am missing hand.obj.  I have rebuilt everything using latest CVS update.  Please elaborate.
 
Regards,
Randy

>>> Jay  5/5/2008 9:47 PM >>>
Sounds like you missed the "gui" switch on the cm3 command line
or in the m3makefile -- in the m3makefile really.
Putting it on the command line imho is only reasonable for those
simple cases that don't have an m3makefile

 link -dump -symbols NT386\_m3main.obj | findstr /i main 

?
I expect you will have main or wmain, but not WinMain or wWinMain.
 
Is this meant to be a gui app or a command line app?
If it is meant to be a command line, then the problem is something else.
  And I don't even want to explain..
Can you send me the source?
 
Also you are missing hand.obj here, so you don't have the potential pixmap fix.

 - Jay

Date: Mon, 5 May 2008 21:01:10 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com 
Subject: [M3devel] new problem linking on NT386

I've rebuild my cm3 system using the latest sources.
 
I am now having a failure linking certain programs that used to build without problems.
 
I've listed the linker output from one of the programs below.  The issue seems to be an unresolved external symbol _WinMain at 16 .
 
Any ideas on what has changed and how to get this working again?
 
Microsoft (R) Incremental Linker Version 9.00.21022.08
Copyright (C) Microsoft Corporation.  All rights reserved.
 
/out:CV_MessageTool.exe 
/subsystem:windows 
/entry:WinMainCRTStartup 
/nodefaultlib 
/debug 
/incremental:no 
/opt:ref 
/delayload:wsock32.dll 
/delayload:advapi32.dll 
/delayload:gdi32.dll 
/delayload:netapi32.dll 
/delayload:user32.dll 
/delayload:comctl32.dll 
delayimp.lib 
_m3main.obj 
iconRes.obj 
Resources.io 
Resources.mo 
Main.mo 
C:\cm3\pkg\windowsResources\NT386\windowsResources.lib 
C:\cm3\pkg\libSciRes3\NT386\libSciRes3.lib 
C:\cm3\pkg\stable\NT386\stable.lib 
C:\cm3\pkg\serial2\NT386\serial2.lib 
C:\cm3\pkg\netobj\NT386\m3netobj.lib 
C:\cm3\pkg\parseparams\NT386\m3parseparams.lib 
C:\cm3\pkg\formsvbt\NT386\m3formsvbt.lib 
C:\cm3\pkg\videovbt\NT386\videovbt.lib 
C:\cm3\pkg\jvideo\NT386\jvideo.lib 
C:\cm3\pkg\web\NT386\web.lib 
C:\cm3\pkg\tcp\NT386\m3tcp.lib 
C:\cm3\pkg\formsvbtpixmaps\NT386\m3formsvbtpixmaps.lib 
C:\cm3\pkg\vbtkit\NT386\m3vbtkit.lib 
C:\cm3\pkg\ui\NT386\m3ui.lib 
C:\cm3\pkg\libm3\NT386\m3.lib 
C:\cm3\pkg\m3core\NT386\m3core.lib 
winspool.lib 
comctl32.lib 
wsock32.lib 
comdlg32.lib 
netapi32.lib 
gdi32.lib 
user32.lib 
advapi32.lib 
kernel32.lib 
msvcrt.lib 
LINK : warning LNK4199: /DELAYLOAD:wsock32.dll ignored; no imports found from wsock32.dll
LINK : warning LNK4199: /DELAYLOAD:advapi32.dll ignored; no imports found from advapi32.dll
LINK : warning LNK4199: /DELAYLOAD:gdi32.dll ignored; no imports found from gdi32.dll
LINK : warning LNK4199: /DELAYLOAD:netapi32.dll ignored; no imports found from netapi32.dll
LINK : warning LNK4199: /DELAYLOAD:user32.dll ignored; no imports found from user32.dll
LINK : warning LNK4199: /DELAYLOAD:comctl32.dll ignored; no imports found from comctl32.dll
msvcrt.lib(crtexew.obj) : error LNK2019: unresolved external symbol _WinMain at 16 referenced in function ___tmainCRTStartup
CV_MessageTool.exe : fatal error LNK1120: 1 unresolved externals
Regards,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Tue May  6 04:26:46 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 6 May 2008 02:26:46 +0000
Subject: [M3devel] new problem linking on NT386
In-Reply-To: <481F8557.1E75.00D7.1@scires.com>
References: <481F7590.1E75.00D7.1@scires.com>
	 
	<481F8557.1E75.00D7.1@scires.com>
Message-ID: 

-gui isn't quite working for you, for reasons I can't fully tell from here.
 
If -entry:WinMainCRTStartup, as you show, then link -dump -symbols _m3main.obj | findstr /i main should find WinMain, and not main. These two things must be altered together. Subsystem usually changes with them as well, but that's optional. WinMainCRTStartup calls WinMain, mainCRTStartup calls main, etc. (also with "w" prepended for Unicode/wide)
This is up to cm3 and cm3.cfg to cooperate on.
 
I can check tonight if it works for me. Could be some config file content missing.
It should generate WinMain instead of main.
 
You don't have the latest config because if you did, the link command you show below would list "hand.obj" among the list of files.
 
e.g.
 copy /y %cvsroot%\m3-sys\cminstall\src\config\nt386* \cm3\bin 
 copy /y \cm3\bin\NT386 \cm3\bin\cm3.cfg  
 
or:
 copy /y %cvsroot%\m3-sys\cminstall\src\config\* \cm3\bin 
 copy /y %cvsroot%\m3-sys\cminstall\src\config-no-install\* \cm3\bin 
 
The second form requires %cvsroot% to stick around and be findable by \cm3\bin\cm3.cfg, such as by setting CM3_ROOT.
The first form does not have such a requirement.
 
I'm really not super keen on supporting any config files other than the exact ones checked in.
Not even necessarily the ones produced by cminstall; I never use it.
I realize there are multiple reasonable modes of operation -- either using %PATH%, %INCLUDE%, and %LIB%, or using full paths in cm3.cfg. I use the first, so I can switch between toolsets more easily, and have no problem with spaces (which I don't have anyway), cminstall uses the second so that the result doesn't depend on the environment but it also has problems with spaces. Depending on short names like "progra~1" is just not the way imho.
 
 - Jay


Date: Mon, 5 May 2008 22:08:29 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] new problem linking on NT386

Jay:
 
No, I am using the -gui option in the m3makefile.  It is a windows gui application.
 
Here is the output of the command you suggested:
 
Microsoft (R) COFF/PE Dumper Version 9.00.21022.08Copyright (C) Microsoft Corporation.  All rights reserved.
 
Dump of file NT386\_m3main.obj
 
File Type: COFF OBJECT
 
COFF SYMBOL TABLE000 00000000 DEBUG  notype       Filename     | .file    _m3main.mc002 00000000 SECT1  notype       Static       | .text    Section length   50, #relocs    4, #linenums    7, checksum        0004 00000000 SECT2  notype       Static       | .data    Section length   10, #relocs    3, #linenums    0, checksum        0006 00000000 SECT3  notype       Static       | .bss    Section length    0, #relocs    0, #linenums    0, checksum        0008 00000000 SECT1  notype ()    External     | _main    tag index 0000000A size 00000050 lines 00000104 next function 0000000000A 00000000 SECT1  notype       BeginFunction | .bf    line# 0000 end 0000000000C 00000007 SECT1  notype       .bf or.ef    | .lf00D 00000050 SECT1  notype       EndFunction  | .ef    line# 000600F 00000000 SECT1  notype       Static       | TextSegment010 00000000 UNDEF  notype       External     | _Main_M3011 00000000 UNDEF  notype       External     | _RTLinker__InitRuntime012 00000000 UNDEF  notype       External     | _RTLinker__AddUnit013 00000000 UNDEF  notype       External     | _RTProcess__Exit014 00000004 SECT2  notype       Static       | T$14
 
String Table Size = 0x4B bytes
 
  Summary
 
           0 .bss          10 .data          50 .text
As you can see, I have an
   _main  and a
   _Main_M3
 
Not sure what you mean by saying I am missing hand.obj.  I have rebuilt everything using latest CVS update.  Please elaborate.
 
Regards,
Randy>>> Jay  5/5/2008 9:47 PM >>>Sounds like you missed the "gui" switch on the cm3 command lineor in the m3makefile -- in the m3makefile really.Putting it on the command line imho is only reasonable for thosesimple cases that don't have an m3makefile link -dump -symbols NT386\_m3main.obj | findstr /i main ?I expect you will have main or wmain, but not WinMain or wWinMain. Is this meant to be a gui app or a command line app?If it is meant to be a command line, then the problem is something else.  And I don't even want to explain..Can you send me the source? Also you are missing hand.obj here, so you don't have the potential pixmap fix. - Jay


Date: Mon, 5 May 2008 21:01:10 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: [M3devel] new problem linking on NT386
I've rebuild my cm3 system using the latest sources.
 
I am now having a failure linking certain programs that used to build without problems.
 
I've listed the linker output from one of the programs below.  The issue seems to be an unresolved external symbol _WinMain at 16 .
 
Any ideas on what has changed and how to get this working again?
 
Microsoft (R) Incremental Linker Version 9.00.21022.08Copyright (C) Microsoft Corporation.  All rights reserved.
 
/out:CV_MessageTool.exe /subsystem:windows /entry:WinMainCRTStartup /nodefaultlib /debug /incremental:no /opt:ref /delayload:wsock32.dll /delayload:advapi32.dll /delayload:gdi32.dll /delayload:netapi32.dll /delayload:user32.dll /delayload:comctl32.dll delayimp.lib _m3main.obj iconRes.obj Resources.io Resources.mo Main.mo C:\cm3\pkg\windowsResources\NT386\windowsResources.lib C:\cm3\pkg\libSciRes3\NT386\libSciRes3.lib C:\cm3\pkg\stable\NT386\stable.lib C:\cm3\pkg\serial2\NT386\serial2.lib C:\cm3\pkg\netobj\NT386\m3netobj.lib C:\cm3\pkg\parseparams\NT386\m3parseparams.lib C:\cm3\pkg\formsvbt\NT386\m3formsvbt.lib C:\cm3\pkg\videovbt\NT386\videovbt.lib C:\cm3\pkg\jvideo\NT386\jvideo.lib C:\cm3\pkg\web\NT386\web.lib C:\cm3\pkg\tcp\NT386\m3tcp.lib C:\cm3\pkg\formsvbtpixmaps\NT386\m3formsvbtpixmaps.lib C:\cm3\pkg\vbtkit\NT386\m3vbtkit.lib C:\cm3\pkg\ui\NT386\m3ui.lib C:\cm3\pkg\libm3\NT386\m3.lib C:\cm3\pkg\m3core\NT386\m3core.lib winspool.lib comctl32.lib wsock32.lib comdlg32.lib netapi32.lib gdi32.lib user32.lib advapi32.lib kernel32.lib msvcrt.lib LINK : warning LNK4199: /DELAYLOAD:wsock32.dll ignored; no imports found from wsock32.dllLINK : warning LNK4199: /DELAYLOAD:advapi32.dll ignored; no imports found from advapi32.dllLINK : warning LNK4199: /DELAYLOAD:gdi32.dll ignored; no imports found from gdi32.dllLINK : warning LNK4199: /DELAYLOAD:netapi32.dll ignored; no imports found from netapi32.dllLINK : warning LNK4199: /DELAYLOAD:user32.dll ignored; no imports found from user32.dllLINK : warning LNK4199: /DELAYLOAD:comctl32.dll ignored; no imports found from comctl32.dllmsvcrt.lib(crtexew.obj) : error LNK2019: unresolved external symbol _WinMain at 16 referenced in function ___tmainCRTStartupCV_MessageTool.exe : fatal error LNK1120: 1 unresolved externals
Regards,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Tue May  6 05:28:10 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Mon, 05 May 2008 23:28:10 -0400
Subject: [M3devel] pixmap problem
In-Reply-To: 
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	
Message-ID: <481F9804.1E75.00D7.1@scires.com>

Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've
copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad
news is that now I am getting a command window opening up in addition to
the GUI window when the program runs.  This behavior does not occur on
v4.1.  The command window seems to be the stdout/stderr of the GUI
program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which
needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy

>>> Jay  5/5/2008 10:47 PM >>>
Randy, Yes.
The NT386 config files are all checked in.
You can use them verbatim. You don't need cminstall, I never use it,
and you shouldn't need to edit the config files at all, any edits I
make, I check in, and should be usable on all machines.
As long as you set %PATH%/%INCLUDE%/%LIB%.
If I'm wrong, I'd like to know why and try to fix.
 
Consider the config files just part of cm3.exe.
Not generally to be changed locally. Unless, well, unless you intend
to, and you should strive to make one form that is usable by all.
 
 - Jay


Date: Mon, 5 May 2008 22:42:30 -0400
From: rcoleburn at scires.com 
To: jayk123 at hotmail.com 
Subject: RE: [M3devel] pixmap problem

Jay,
When you say "took the updated config file", what do you mean?  Are you
saying I need a different cm3.cfg file?
Regards,
Randy

>>> Jay  5/5/2008 9:54 PM >>>
And you took the updated config file?
The way you can tell is that, roughly speaking, hand.obj should be in
NT386\_m3responsefile0.txt.
Or _m3responsefile1.txt, or, well, somewhere.
Anyway, I think I saw the attachment, I can check later..and with 4.1
as I said..
 
I can see about making the fix not depend on config file changes...but
it's not terrible asis, and I'd really like to merge more of the quake
code into cm3.exe..
 
 - Jay

Date: Mon, 5 May 2008 21:18:12 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com 
Subject: Re: [M3devel] pixmap problem

Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly
when the buildstandalone() directive is used.
 
Regards,
Randy

>>> Jay  5/5/2008 7:04 PM >>>
Thanks. I'll look into this tonight probably, as well as with 4.1
assuming I can find my binaries and source for it (probably).

COULD BE the pixmap problem is something else and 4.1 also has the
problem I fixed. We'll see. No need to speculate (unless I can't find my
4.1).

 - Jay


Date: Mon, 5 May 2008 10:59:27 -0400
From: rcoleburn at scires.com 
To: jayk123 at hotmail.com 
CC: m3devel at elegosoft.com 
Subject: RE: [M3devel] pixmap problem

Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files
or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy

>>> Jay  5/4/2008 11:46 AM >>>
Randy, Please try with /current/ source, as of this morning Sunday May
4 -- the changes are ALL in NT386.common, so you MUST use MY config
files, which are checked in verbatim, or you should be able edit
whatever config files you are using.
 
(It's not really a config file issue, don't blame the general confusion
people have with them.)
 
I'll try to try later, but I don't have the source right now, gotta
look on other machines, and I think it's on a machine on loan.
  Or send it to me again.
I'd also like to know if this worked with 4.1, or with any release that
offered dynamic linking to m3core.dll, on Windows.
  I recall a claim that it did. If today's change fixes it, I should be
able to investigate 4.1.
3.6 did not have such linking.
If today's change does not help, well, I still plan on debugging it at
some point..
 
If you aren't current and getting so is difficult, just send the
attachment again, it's easy for me to test.
 
Thanks,
 - Jay

From: jayk123 at hotmail.com 
To: hosking at cs.purdue.edu; rcoleburn at scires.com 
Date: Sat, 19 Jan 2008 08:52:08 +0000
CC: m3devel at elegosoft.com 
Subject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.
I was going to try on PPC_DARWIN but I guess Tony's info suffices.
 
I tried rolling hand.c back to before I changed (months/year ago),
since it is involved in bit twiddling, no change, phew.
 
Debugging here is a big humungous pain.
NT386 has good stacks and line numbers, but no locals or type info, I'd
really sometime like to get Codeview info into those .objs...I think it
is documented well enough, but still not necessarily easy, or maybe have
a C generating backend partly for this reason (and to bring up more
targets, using native tools), and function calls in disassembly I think
don't resolve; NT386GNU can't yet build this, though it will soon, but
I'm not familiar with gdb and there appears to be no type info. I'm
building m3gdb right now, I don't know if it will work, I hope it has
type info, and I'm not familiar with the relevant code. In gdb I
struggle just to view bytes in memory, add numbers to addresses and see
those, etc. I think for MY problem, I'm going to link in C code to dump
the structs. There is tracing code and I enabled it, but even it crashes
in Text_Length. At least MY problem crashes, hopefully near the problem,
whereas your problem goes all the way through to completion with no
stopping to hint where the problem is. Darn it. :) on the mock rudeness
and :( on the lack of a crash.
 
You write the bundle out and it matches, so that doesn't rule out
bundles as being the problem? (darn)
And bundles look pretty simple, a bundle is just a generated source
file with a constant in it.
Maybe newline problems? That wouldn't make sense. I just downloaded
some program that might let me separately view the ppm, maybe it'll
reveal something.
 
The bad behavior has like regularly spaced solid color veritical bars a
few pixels side across the whole picture, and regularly spaced vertical
stripes from the correct picture alternating with that. Perhaps someone
with ppm/bitmap/graphics experience has seen this behavior and it
results from some common pixmap mismanagement we could look for?
 
I have to say this is very surprising.
 
I always wondered, and now I pretty much assume -- Modula-3 never
imports/exports data in its dynamic linking, right? It alway
imports/exports functions, right?
On Windows, functions have an optional optimization, but data must be
handled differently at compile time if it is going to be dynamically
imported.
For functions, if you don't apply the optimization at compile time, the
linker will just generate a single instruction thunk instead.
 
That is, given a symbol Foo, there is a symbol __imp__Foo that is a
pointer to the actual foo in another .dll/.so.
The loader only patches pointers, one per import if you build your .dll
correctly, it doesn't patch instructions or code strewn throughout a
.dll, just one contiguous array of pointers. MAYBE they don't have to be
contiguous for each .dl you import from.
 
That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my
.dll/.exe typically has an array:
 
pointer to msvcrt!fopen
pointer to msvcrt!fclose
null
pointer to kernel32!Sleep
 
But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not
be adjacent.
 
So, going back, my point/question is that, if the compiler knows the
function is imported, it can call through __imp__Foo instead of calling
Foo.
But if it calls Foo and you import Foo, the linker will create the
function Foo that just jmps through __imp__Foo.
That doesn't work for data though. There's no ability to intervenve
like that.
So for imported data, the compiler must generated a read and
dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to
be imported.
Data imports may be faster when appropriate, but for this reason, I'd
say they aren't worth it.
And for this reason, I HOPE Modula-3 never imports/exports data.
 
Oh, you could, for data, always reference the pointer __imp_Foo, and if
non materializes, create one.
However that would suck perf in order to make an uncommon case work.
I hope Modula-3 doesn't do that either. :)
Though I guess since this global data in question...maybe it is
rare???
 
Later,
 - Jay



> From: hosking at cs.purdue.edu 
> Date: Sat, 19 Jan 2008 03:09:47 -0500
> To: rcoleburn at scires.com 
> CC: m3devel at elegosoft.com 
> Subject: Re: [M3devel] pixmap problem
> 
> Looks fine to me on I386_DARWIN.
> 
> On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:
> 
> > 
> 


Need to know the score, the latest news, or you need your Hotmail*-get
your "fix" Check it out. ( http://www.msnmobilefix.com/Default.aspx ) 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Tue May  6 05:38:03 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 6 May 2008 03:38:03 +0000
Subject: [M3devel] pixmap problem
In-Reply-To: <481F9804.1E75.00D7.1@scires.com>
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	 
	<481F9804.1E75.00D7.1@scires.com>
Message-ID: 

Randy, don't worry.
Two of these problems are trivial to fix -- PKG_USE and popups.
The pixmap one will need debugging.
 
 - Jay


Date: Mon, 5 May 2008 23:28:10 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem

Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad news is that now I am getting a command window opening up in addition to the GUI window when the program runs.  This behavior does not occur on v4.1.  The command window seems to be the stdout/stderr of the GUI program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy>>> Jay  5/5/2008 10:47 PM >>>Randy, Yes.The NT386 config files are all checked in.You can use them verbatim. You don't need cminstall, I never use it, and you shouldn't need to edit the config files at all, any edits I make, I check in, and should be usable on all machines.As long as you set %PATH%/%INCLUDE%/%LIB%.If I'm wrong, I'd like to know why and try to fix. Consider the config files just part of cm3.exe.Not generally to be changed locally. Unless, well, unless you intend to, and you should strive to make one form that is usable by all.  - Jay


Date: Mon, 5 May 2008 22:42:30 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay,
When you say "took the updated config file", what do you mean?  Are you saying I need a different cm3.cfg file?
Regards,
Randy>>> Jay  5/5/2008 9:54 PM >>>And you took the updated config file?The way you can tell is that, roughly speaking, hand.obj should be in NT386\_m3responsefile0.txt.Or _m3responsefile1.txt, or, well, somewhere.Anyway, I think I saw the attachment, I can check later..and with 4.1 as I said.. I can see about making the fix not depend on config file changes...but it's not terrible asis, and I'd really like to merge more of the quake code into cm3.exe..  - Jay


Date: Mon, 5 May 2008 21:18:12 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem
Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly when the buildstandalone() directive is used.
 
Regards,
Randy>>> Jay  5/5/2008 7:04 PM >>>Thanks. I'll look into this tonight probably, as well as with 4.1 assuming I can find my binaries and source for it (probably).COULD BE the pixmap problem is something else and 4.1 also has the problem I fixed. We'll see. No need to speculate (unless I can't find my 4.1). - Jay


Date: Mon, 5 May 2008 10:59:27 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problem
Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy>>> Jay  5/4/2008 11:46 AM >>>Randy, Please try with /current/ source, as of this morning Sunday May 4 -- the changes are ALL in NT386.common, so you MUST use MY config files, which are checked in verbatim, or you should be able edit whatever config files you are using. (It's not really a config file issue, don't blame the general confusion people have with them.) I'll try to try later, but I don't have the source right now, gotta look on other machines, and I think it's on a machine on loan.  Or send it to me again.I'd also like to know if this worked with 4.1, or with any release that offered dynamic linking to m3core.dll, on Windows.  I recall a claim that it did. If today's change fixes it, I should be able to investigate 4.1.3.6 did not have such linking.If today's change does not help, well, I still plan on debugging it at some point.. If you aren't current and getting so is difficult, just send the attachment again, it's easy for me to test. Thanks, - Jay


From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rcoleburn at scires.comDate: Sat, 19 Jan 2008 08:52:08 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.I was going to try on PPC_DARWIN but I guess Tony's info suffices. I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. Debugging here is a big humungous pain.NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)And bundles look pretty simple, a bundle is just a generated source file with a constant in it.Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something. The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for? I have to say this is very surprising. I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so.The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: pointer to msvcrt!fopenpointer to msvcrt!fclosenullpointer to kernel32!Sleep But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo.But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo.That doesn't work for data though. There's no ability to intervenve like that.So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it.And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.However that would suck perf in order to make an uncommon case work.I hope Modula-3 doesn't do that either. :)Though I guess since this global data in question...maybe it is rare??? Later, - Jay

> From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 03:09:47 -0500> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] pixmap problem> > Looks fine to me on I386_DARWIN.> > On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:> > > > 

Need to know the score, the latest news, or you need your Hotmail?-get your "fix" Check it out. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From wagner at elegosoft.com  Tue May  6 07:57:54 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 06 May 2008 07:57:54 +0200
Subject: [M3devel] m3cc build fails on older MacOS X
Message-ID: <20080506075754.o24j7xhx4wgokwwo@mail.elegosoft.com>

On % uname -a
Darwin apple.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30  
20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC  Power  
Macintosh powerpc:

echo ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./alloca.o  
./argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./dyn-string.o  
./fdmatch.o ./fibheap.o ./filename_cmp.o ./floatformat.o ./fnmatch.o  
./fopen_unlocked.o ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o  
./hashtab.o ./hex.o ./lbasename.o ./lrealpath.o  
./make-relative-prefix.o ./make-temp-file.o ./objalloc.o ./obstack.o  
./partition.o ./pexecute.o ./physmem.o ./pex-common.o ./pex-one.o  
./pex-unix.o ./safe-ctype.o ./sort.o ./spaces.o ./splay-tree.o  
./strerror.o ./strsignal.o ./unlink-if-ordinary.o ./xatexit.o  
./xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o  
./xstrndup.o > required-list
make[2]: Nothing to be done for `all'.
Makefile:191: *** Insufficient number of arguments (2) to function  
`patsubst'.  Stop.
make: *** [all-libcpp] Error 2
/bin/sh: line 1: cd: gcc: No such file or directory
make: *** No rule to make target `s-modes'.  Stop.
"/Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile", line 314: quake  
runtime error: unable to copy "./gcc/m3cgc1" to "./cm3cg": errno=2

--procedure--  -line-  -file---
cp_if              --  
postcp            314  /Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile
include_dir       360  /Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile
                     9   
/Users/wagner/work/cm3/m3-sys/m3cc/PPC_DARWIN/m3make.args

Fatal Error: package build failed
  ==> m3-sys/m3cc done

Any ideas?

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  Tue May  6 08:16:13 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 06 May 2008 08:16:13 +0200
Subject: [M3devel] m3tests again
Message-ID: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>

Hi Jay,

after several small fixes to the regression scripts, the nightrun
now shows for me

  >>> test_m3tests error extract:
  >>> failed tests: p116b p172 p185 p204 p206 p207 p209 p210 r001 e020  
e026 e029
  >>> 12 in test_m3tests 2008-05-06-01-30-23  
/home/wagner/work/cm3-ws/luthien-2008-05-06-01-30-23

One week ago there were only 6. Could you have a closer look at this?
I'm still busy with other projects.

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  Tue May  6 09:48:30 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 06 May 2008 09:48:30 +0200
Subject: [M3devel] build fails on NT386
In-Reply-To: <481F25FA.1E75.00D7.1@scires.com>
References: <481EFC54.1E75.00D7.1@scires.com>
	<481F2363.1E75.00D7.1@scires.com> <481F25FA.1E75.00D7.1@scires.com>
Message-ID: <20080506094830.lsbh8osejkgcs0cg@mail.elegosoft.com>

Quoting Randy Coleburn :

> Update:
>
> I tried to get around the problem by manually building & shipping   
> the sysutils package, then running scripts\win\upgrade.cmd again.

Randy, this is a new package needed for several quake extensions.
It has been added some months ago. Obviously nobody has updated
the cmd scripts. Could you add sysutils as prerequisite to all
scripts building cm3?

Olaf

> Now the build fails as shown below:
>
> === package C:\CM3_Sandbox\cm3\m3-sys\m3quake ===
> +++ "cm3 -build  -DROOT=C:\\CM3_Sandbox\\cm3   
> -DCM3_VERSION_TEXT=d5.7.0 -DCM3_VER
> SION_NUMBER=050700 -DCM3_LAST_CHANGED=2008-03-16 && cm3 -ship   
> -DROOT=C:\\CM3_San
> dbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_VERSION_NUMBER=050700   
> -DCM3_LAST_CHANG
> ED=2008-03-16" +++
> --- building in NT386 ---
>
> ignoring ..\src\m3overrides
>
> new source -> compiling Quake.i3
> new source -> compiling QCompiler.i3
> new source -> compiling QCode.i3
> new source -> compiling QValue.i3
> new source -> compiling QVSeq.i3
> new source -> compiling QVTbl.i3
> new source -> compiling QVal.i3
> new source -> compiling QMachine.i3
> new source -> compiling QToken.i3
> new source -> compiling QIdent.i3
> new source -> compiling Quake.m3
> new source -> compiling QToken.m3
> new source -> compiling QIdent.m3
> new source -> compiling QScanner.i3
> new source -> compiling QScanner.m3
> new source -> compiling QCode.m3
> new source -> compiling QCompiler.m3
> new source -> compiling QValue.m3
> new source -> compiling QVTbl.m3
> new source -> compiling QVSeqRep.i3
> new source -> compiling QVSeq.m3
>
> Fatal Error: bad version stamps: SystemWin32.m3
>
> version stamp mismatch: WinSock.gethostname
>   <4ccceffe6a8d6438> => SystemWin32.m3
>   <0e719d1414b51c34> => WinSock.i3
> SystemWin32.m3: missing imported type: _te9593bef
> ERROR: "cm3 -build  -DROOT=C:\\CM3_Sandbox\\cm3   
> -DCM3_VERSION_TEXT=d5.7.0 -DCM3_
> VERSION_NUMBER=050700 -DCM3_LAST_CHANGED=2008-03-16 && cm3 -ship   
> -DROOT=C:\\CM3_
> Sandbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_VERSION_NUMBER=050700   
> -DCM3_LAST_CH
> ANGED=2008-03-16"
> ERROR: cd C:\CM3_Sandbox\cm3\m3-sys\m3quake
> ERROR: set INSTALLROOT=C:\cm3
>
> C:\CM3_Sandbox\cm3\scripts\win>
>
> Please advise.
>
> Regards,
> Randy
>
>>>> "Randy Coleburn"  5/5/2008 3:10 PM >>>
> I have done a CVS update and decided to rebuild everything.
>
> I used the script in scripts\win\upgrade.cmd
>
> Here is a snippet of the output where it fails:
>
> ..\src\values => c:\cm3\pkg\m3front\src\values
>   Module.i3         Module.m3         Value.i3          Value.m3
>   ValueRep.i3       Constant.i3       Constant.m3       Decl.m3
>   Decl.i3           EnumElt.i3        EnumElt.m3        Exceptionz.i3
>   Exceptionz.m3     External.i3       External.m3       Field.i3
>   Field.m3          Formal.i3         Formal.m3         Ident.i3
>   Ident.m3          Method.m3         Method.i3         Procedure.i3
>   Procedure.m3      Revelation.m3     Revelation.i3     Tipe.i3
>   Tipe.m3           Variable.i3       Variable.m3
> === package C:\CM3_Sandbox\cm3\m3-sys\m3quake ===
> +++ "cm3 -build  -DROOT=C:\\CM3_Sandbox\\cm3   
> -DCM3_VERSION_TEXT=d5.7.0 -DCM3_VER
> SION_NUMBER=050700 -DCM3_LAST_CHANGED=2008-03-16 && cm3 -ship   
> -DROOT=C:\\CM3_San
> dbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_VERSION_NUMBER=050700   
> -DCM3_LAST_CHANG
> ED=2008-03-16" +++
> --- building in NT386 ---
>
> ignoring ..\src\m3overrides
>
> "C:\CM3_Sandbox\cm3\m3-sys\m3quake\src\m3makefile", line 14: quake   
> runtime error
> : unable to open "c:\cm3\pkg\sysutils\NT386\.M3EXPORTS" for reading
>
> --procedure--  -line-  -file---
> import             --  
> include_dir        14  C:\CM3_Sandbox\cm3\m3-sys\m3quake\src\m3makefile
>                     8  C:\CM3_Sandbox\cm3\m3-sys\m3quake\NT386\m3make.args
>
> Fatal Error: package build failed
> ERROR: "cm3 -build  -DROOT=C:\\CM3_Sandbox\\cm3   
> -DCM3_VERSION_TEXT=d5.7.0 -DCM3_
> VERSION_NUMBER=050700 -DCM3_LAST_CHANGED=2008-03-16 && cm3 -ship   
> -DROOT=C:\\CM3_
> Sandbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_VERSION_NUMBER=050700   
> -DCM3_LAST_CH
> ANGED=2008-03-16"
> ERROR: cd C:\CM3_Sandbox\cm3\m3-sys\m3quake
> ERROR: set INSTALLROOT=C:\cm3
>
> C:\CM3_Sandbox\cm3\scripts\win>
>
> Please advise.
>
> Regards,
> Randy
>



-- 
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  Tue May  6 10:07:11 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 06 May 2008 10:07:11 +0200
Subject: [M3devel] www.opencm3.net/m3tests
In-Reply-To: 
References: <313767.59466.qm@web27115.mail.ukl.yahoo.com>
	
Message-ID: <20080506100711.d2rzqie6ow08csgs@mail.elegosoft.com>

Quoting Jay :

> The "problem" here, a really really small one, is just that the link  
>  and mt commands got echoed.
> Olaf made them not echoed. I then made them conditionally echoed.
>   I made m3-sys\m3tests define M3TESTS so that NT386.common doesn't echo.
> It's not a big deal either way.
> Aha -- tests in other directories would have a problem, and I think   
> there are some.
>
> I like more echoing usually, so the system explains what is going on,
> instead of the vaguer "linking foo" sort of message.
> Granted, nobody bothers watching gcc run assembler commands, so I   
> guess it is just quite gray.

Jay, cm3 needs to behave the same on all platforms. By default
commands should _not_ be echoed to stdout or stderr; that's what the
-commands switch is for: this gives you exactly the commands the
compiler issues to invoke other tools.

For more verbose output, you may also depend on the -verbose or the
-debug switches.

Please adapt the configuration files that bey default all echoing
of commands is off.

Olaf

> I don't know how to run the Tinderbox either yet, sorry.
> I tried.
>
> For adding tests, well, there is m3-sys\m3tests.
> That is where a lot of the tests are, but not all.
> I am not sure where tests belong. I added a small number there.
> They are named with just a letter and a number.
> The letters have some meaning, explained in the m3makefile.
> "p" is programs that are run and their stdout/stderr compared   
> against expected
> "e" is programs build and the errors from the compiler checked to be  
>  reasonable.
>   I don't think in general they are expected to successfully compile  
>  or run, though the case of "warnings" may be unclear.
> "c" is programs built so a human can look at the generated code.
> There is another case I think for human checking.
> The numbers are just 001, 002, 003, etc.
> Each hundred tests are in a separate directory, like p0\p001,   
> p0\p002, p1\p100, p1\101, etc.
>
> Something like this.
> Wherever I have details wrong, just look in m3-sys\m3tests. It's   
> pretty simple, obvious, and well commented.
>
> The output is a little clearer if you have a working diff.exe on the path.
> Then what you do is search for "@@" in the output.
>
>  - Jay
>
>
> Date: Tue, 6 May 2008 03:46:27 +0200From: dabenavidesd at yahoo.esTo:   
> m3devel at elegosoft.comSubject: [M3devel] www.opencm3.net/m3testsDear   
> developers:Does the recent tests on NT386 seem broken because a   
> recent change on the m3-sys tree, or is the HTML bad generated, I   
> mean can you check the last tests Sunday, May 4th (p001 to p042) has  
>  a red background   
> http://www.opencm3.net/m3tests/m3tests-NT386-2008-04-23-13-30-57.html
p002 Text
Comparing files P0\P002\stdout.build and ..\SRC\P0\P002\STDOUT.BUILD***** P0\P002\stdout.buildlink @_m3responsefile0.txt 2>&1 > pgm.lstmt /nologo /manifest pgm.exe.manifest /outputresource:pgm.exe;1***** ..\SRC\P0\P002\STDOUT.BUILD*****Comparing files P0\P002\stderr.build and ..\SRC\P0\P002\STDERR.BUILDFC: no differences encounteredComparing files P0\P002\stdout.pgm and ..\SRC\P0\P002\STDOUT.PGMFC: no differences encounteredComparing files P0\P002\stderr.pgm and ..\SRC\P0\P002\STDERR.PGMFC: no differences encounteredand almost the same pattern in the above tests.I would suggest if it is thinkable using NT386 variant with a complete dedicated machine/system, I can try to set up one this week and send the data back (the machine is behind a proxy), but I don't remember the mail explaining the set up, and also want to know if there is a chance of run the tests with one run script.Also what is the best natural way to put a new tests, and the standard name it should   
> have?Thanks
>
>
> Enviado desde Correo Yahoo!La bandeja de entrada m?s inteligente.



-- 
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 jayk123 at hotmail.com  Tue May  6 12:49:11 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 6 May 2008 10:49:11 +0000
Subject: [M3devel] m3cc build fails on older MacOS X
In-Reply-To: <20080506075754.o24j7xhx4wgokwwo@mail.elegosoft.com>
References: <20080506075754.o24j7xhx4wgokwwo@mail.elegosoft.com>
Message-ID: 

I don't know what these Darwin versions are.
Mac OSX 10.0? 10.1? 10.2? 10.3? 10.4? 10.5?
I used to run 10.2 and could perhaps bring it back (though I'd hate to lose my PPC_LINUX install.. :( )
 
> make[2]: Nothing to be done for `all'.> Makefile:191: *** Insufficient number of arguments (2) to function > `patsubst'. Stop.
Hopefully that's enough context though.
 
The rest is a cascade.
What happens if you remove all my m3makefile wierdness (which works everywhere else..) and just configure and make?
 
Can I ssh into this?
 
 - Jay



> Date: Tue, 6 May 2008 07:57:54 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] m3cc build fails on older MacOS X> > On % uname -a> Darwin apple.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 > 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power > Macintosh powerpc:> > echo ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./alloca.o > ./argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./dyn-string.o > ./fdmatch.o ./fibheap.o ./filename_cmp.o ./floatformat.o ./fnmatch.o > ./fopen_unlocked.o ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o > ./hashtab.o ./hex.o ./lbasename.o ./lrealpath.o > ./make-relative-prefix.o ./make-temp-file.o ./objalloc.o ./obstack.o > ./partition.o ./pexecute.o ./physmem.o ./pex-common.o ./pex-one.o > ./pex-unix.o ./safe-ctype.o ./sort.o ./spaces.o ./splay-tree.o > ./strerror.o ./strsignal.o ./unlink-if-ordinary.o ./xatexit.o > ./xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o > ./xstrndup.o > required-list> make[2]: Nothing to be done for `all'.> Makefile:191: *** Insufficient number of arguments (2) to function > `patsubst'. Stop.> make: *** [all-libcpp] Error 2> /bin/sh: line 1: cd: gcc: No such file or directory> make: *** No rule to make target `s-modes'. Stop.> "/Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile", line 314: quake > runtime error: unable to copy "./gcc/m3cgc1" to "./cm3cg": errno=2> > --procedure-- -line- -file---> cp_if -- > postcp 314 /Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile> include_dir 360 /Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile> 9 > /Users/wagner/work/cm3/m3-sys/m3cc/PPC_DARWIN/m3make.args> > Fatal Error: package build failed> ==> m3-sys/m3cc done> > Any ideas?> > 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 jayk123 at hotmail.com  Tue May  6 12:57:01 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 6 May 2008 10:57:01 +0000
Subject: [M3devel] www.opencm3.net/m3tests
In-Reply-To: <20080506100711.d2rzqie6ow08csgs@mail.elegosoft.com>
References: <313767.59466.qm@web27115.mail.ukl.yahoo.com>
	 
	<20080506100711.d2rzqie6ow08csgs@mail.elegosoft.com>
Message-ID: 

Olaf, I don't entirely agree.
The logs should be fairly informative without intervention.
Just not too verbose. I'd would rather remove the lines that say "compiling" and show the cm3cg invocations.
But more than one line per source file is too much.
-commands doesn't really work. Lots of bogus extra commands are echoed (rm .tmp), and not all the commands that are run are echoed.
 
I understand that stability for tests is also a goal, but information for the interactive user and for post mortem debugging via a log is also valuable, and these are contrary to stability-for-tests. Somehow contradictory goals need to be met.
 
How about a compromise?
How about we always log more stuff to TARGET/cm3.log?
 And then exactly what you want to stdout/stderr?
While, as I said, more than one line per file is overkill, as part of this compromise I'd be willing to include the cm3cg and as invocation.
 
Have folks used build.exe in the Windows NT DDK?
It's model is close to what you get here.
It has three sets of information:
  to the console/stdout 
  build.log, build.exe is a wrapper over make, and this includes all the make output -- all the command lines run 
  build.err, a small subset of console/stdout output
 
My "design" here has been to avoid over-verbosity. Link and mt run on the order of once, or a small number of times, per directory, so showing the full command line (response files...) isn't so verbose -- vs. say something shown once per compiled file.
 
There's another "problem" here that I have partly fixed.
Underlying errors are not shown on console/stdout/stderr.
They are often in like TARGET/m3core.lst.
 
I changed stuff to refer to that file, after having hunted the errors down myself slowly the first time.
 
We could change things to alway says "see TARGET/cm3.log" for more information, or somesuch.
 
 - Jay



> Date: Tue, 6 May 2008 10:07:11 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] www.opencm3.net/m3tests> > Quoting Jay :> > > The "problem" here, a really really small one, is just that the link > > and mt commands got echoed.> > Olaf made them not echoed. I then made them conditionally echoed.> > I made m3-sys\m3tests define M3TESTS so that NT386.common doesn't echo.> > It's not a big deal either way.> > Aha -- tests in other directories would have a problem, and I think > > there are some.> >> > I like more echoing usually, so the system explains what is going on,> > instead of the vaguer "linking foo" sort of message.> > Granted, nobody bothers watching gcc run assembler commands, so I > > guess it is just quite gray.> > Jay, cm3 needs to behave the same on all platforms. By default> commands should _not_ be echoed to stdout or stderr; that's what the> -commands switch is for: this gives you exactly the commands the> compiler issues to invoke other tools.> > For more verbose output, you may also depend on the -verbose or the> -debug switches.> > Please adapt the configuration files that bey default all echoing> of commands is off.> > Olaf> > > I don't know how to run the Tinderbox either yet, sorry.> > I tried.> >> > For adding tests, well, there is m3-sys\m3tests.> > That is where a lot of the tests are, but not all.> > I am not sure where tests belong. I added a small number there.> > They are named with just a letter and a number.> > The letters have some meaning, explained in the m3makefile.> > "p" is programs that are run and their stdout/stderr compared > > against expected> > "e" is programs build and the errors from the compiler checked to be > > reasonable.> > I don't think in general they are expected to successfully compile > > or run, though the case of "warnings" may be unclear.> > "c" is programs built so a human can look at the generated code.> > There is another case I think for human checking.> > The numbers are just 001, 002, 003, etc.> > Each hundred tests are in a separate directory, like p0\p001, > > p0\p002, p1\p100, p1\101, etc.> >> > Something like this.> > Wherever I have details wrong, just look in m3-sys\m3tests. It's > > pretty simple, obvious, and well commented.> >> > The output is a little clearer if you have a working diff.exe on the path.> > Then what you do is search for "@@" in the output.> >> > - Jay> >> >> > Date: Tue, 6 May 2008 03:46:27 +0200From: dabenavidesd at yahoo.esTo: > > m3devel at elegosoft.comSubject: [M3devel] www.opencm3.net/m3testsDear > > developers:Does the recent tests on NT386 seem broken because a > > recent change on the m3-sys tree, or is the HTML bad generated, I > > mean can you check the last tests Sunday, May 4th (p001 to p042) has > > a red background > > http://www.opencm3.net/m3tests/m3tests-NT386-2008-04-23-13-30-57.html
p002 Text
Comparing files P0\P002\stdout.build and ..\SRC\P0\P002\STDOUT.BUILD***** P0\P002\stdout.buildlink @_m3responsefile0.txt 2>&1 > pgm.lstmt /nologo /manifest pgm.exe.manifest /outputresource:pgm.exe;1***** ..\SRC\P0\P002\STDOUT.BUILD*****Comparing files P0\P002\stderr.build and ..\SRC\P0\P002\STDERR.BUILDFC: no differences encounteredComparing files P0\P002\stdout.pgm and ..\SRC\P0\P002\STDOUT.PGMFC: no differences encounteredComparing files P0\P002\stderr.pgm and ..\SRC\P0\P002\STDERR.PGMFC: no differences encounteredand almost the same pattern in the above tests.I would suggest if it is thinkable using NT386 variant with a complete dedicated machine/system, I can try to set up one this week and send the data back (the machine is behind a proxy), but I don't remember the mail explaining the set up, and also want to know if there is a chance of run the tests with one run script.Also what is the best natural way to put a new tests, and the standard name it should > > have?Thanks> >> >> > Enviado desde Correo Yahoo!La bandeja de entrada m?s inteligente.> > > > -- > 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  Tue May  6 13:02:47 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 06 May 2008 13:02:47 +0200
Subject: [M3devel] m3cc build fails on older MacOS X
In-Reply-To: 
References: <20080506075754.o24j7xhx4wgokwwo@mail.elegosoft.com>
	
Message-ID: <20080506130247.50uj68o11twcgkog@mail.elegosoft.com>

Quoting Jay :

> I don't know what these Darwin versions are.
> Mac OSX 10.0? 10.1? 10.2? 10.3? 10.4? 10.5?
> I used to run 10.2 and could perhaps bring it back (though I'd hate   
> to lose my PPC_LINUX install.. :( )
>
>> make[2]: Nothing to be done for `all'.> Makefile:191: ***   
>> Insufficient number of arguments (2) to function > `patsubst'. Stop.
> Hopefully that's enough context though.
>
> The rest is a cascade.
> What happens if you remove all my m3makefile wierdness (which works   
> everywhere else..) and just configure and make?
>
> Can I ssh into this?

Not currently, but I could arrange that sometime this evening (19:00-
24:00 CEST), if that suits you. I'll take this computer with me on
holidays in two days, so it will probably not be available then.
But you can peek into it today if you want.

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 jayk123 at hotmail.com  Tue May  6 13:17:53 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 6 May 2008 11:17:53 +0000
Subject: [M3devel] www.opencm3.net/m3tests
In-Reply-To: 
References: <313767.59466.qm@web27115.mail.ukl.yahoo.com>
	 
	<20080506100711.d2rzqie6ow08csgs@mail.elegosoft.com> 
	
Message-ID: 

When I say show cm3cg/as invocations, I mean in this new TARGET/cm3.log.
As I said, I propose exactly the stdout/stderr you want, but then some other output always, a log file.
Also, about -commands, I have also claimed that it does work -- talking out of both sides of my mouth. The extra commands it prints are obviously harmless. I forget what doesn't print, maybe exec vs. q_exec? Also the '@' character wasn't working with q_exec, but that isn't necessarily relevant here..I forgot where I use exec vs. q_exec..
And there plenty of other ways to debug than -commands and it is "just" a debugging facility..
 
 - Jay


From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Tue, 6 May 2008 10:57:01 +0000Subject: Re: [M3devel] www.opencm3.net/m3tests


Olaf, I don't entirely agree.The logs should be fairly informative without intervention.Just not too verbose. I'd would rather remove the lines that say "compiling" and show the cm3cg invocations.But more than one line per source file is too much.-commands doesn't really work. Lots of bogus extra commands are echoed (rm .tmp), and not all the commands that are run are echoed. I understand that stability for tests is also a goal, but information for the interactive user and for post mortem debugging via a log is also valuable, and these are contrary to stability-for-tests. Somehow contradictory goals need to be met. How about a compromise?How about we always log more stuff to TARGET/cm3.log? And then exactly what you want to stdout/stderr?While, as I said, more than one line per file is overkill, as part of this compromise I'd be willing to include the cm3cg and as invocation. Have folks used build.exe in the Windows NT DDK?It's model is close to what you get here.It has three sets of information:  to the console/stdout   build.log, build.exe is a wrapper over make, and this includes all the make output -- all the command lines run   build.err, a small subset of console/stdout output My "design" here has been to avoid over-verbosity. Link and mt run on the order of once, or a small number of times, per directory, so showing the full command line (response files...) isn't so verbose -- vs. say something shown once per compiled file. There's another "problem" here that I have partly fixed.Underlying errors are not shown on console/stdout/stderr.They are often in like TARGET/m3core.lst. I changed stuff to refer to that file, after having hunted the errors down myself slowly the first time. We could change things to alway says "see TARGET/cm3.log" for more information, or somesuch.  - Jay

> Date: Tue, 6 May 2008 10:07:11 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] www.opencm3.net/m3tests> > Quoting Jay :> > > The "problem" here, a really really small one, is just that the link > > and mt commands got echoed.> > Olaf made them not echoed. I then made them conditionally echoed.> > I made m3-sys\m3tests define M3TESTS so that NT386.common doesn't echo.> > It's not a big deal either way.> > Aha -- tests in other directories would have a problem, and I think > > there are some.> >> > I like more echoing usually, so the system explains what is going on,> > instead of the vaguer "linking foo" sort of message.> > Granted, nobody bothers watching gcc run assembler commands, so I > > guess it is just quite gray.> > Jay, cm3 needs to behave the same on all platforms. By default> commands should _not_ be echoed to stdout or stderr; that's what the> -commands switch is for: this gives you exactly the commands the> compiler issues to invoke other tools.> > For more verbose output, you may also depend on the -verbose or the> -debug switches.> > Please adapt the configuration files that bey default all echoing> of commands is off.> > Olaf> > > I don't know how to run the Tinderbox either yet, sorry.> > I tried.> >> > For adding tests, well, there is m3-sys\m3tests.> > That is where a lot of the tests are, but not all.> > I am not sure where tests belong. I added a small number there.> > They are named with just a letter and a number.> > The letters have some meaning, explained in the m3makefile.> > "p" is programs that are run and their stdout/stderr compared > > against expected> > "e" is programs build and the errors from the compiler checked to be > > reasonable.> > I don't think in general they are expected to successfully compile > > or run, though the case of "warnings" may be unclear.> > "c" is programs built so a human can look at the generated code.> > There is another case I think for human checking.> > The numbers are just 001, 002, 003, etc.> > Each hundred tests are in a separate directory, like p0\p001, > > p0\p002, p1\p100, p1\101, etc.> >> > Something like this.> > Wherever I have details wrong, just look in m3-sys\m3tests. It's > > pretty simple, obvious, and well commented.> >> > The output is a little clearer if you have a working diff.exe on the path.> > Then what you do is search for "@@" in the output.> >> > - Jay> >> >> > Date: Tue, 6 May 2008 03:46:27 +0200From: dabenavidesd at yahoo.esTo: > > m3devel at elegosoft.comSubject: [M3devel] www.opencm3.net/m3testsDear > > developers:Does the recent tests on NT386 seem broken because a > > recent change on the m3-sys tree, or is the HTML bad generated, I > > mean can you check the last tests Sunday, May 4th (p001 to p042) has > > a red background > > http://www.opencm3.net/m3tests/m3tests-NT386-2008-04-23-13-30-57.html
p002 Text
Comparing files P0\P002\stdout.build and ..\SRC\P0\P002\STDOUT.BUILD***** P0\P002\stdout.buildlink @_m3responsefile0.txt 2>&1 > pgm.lstmt /nologo /manifest pgm.exe.manifest /outputresource:pgm.exe;1***** ..\SRC\P0\P002\STDOUT.BUILD*****Comparing files P0\P002\stderr.build and ..\SRC\P0\P002\STDERR.BUILDFC: no differences encounteredComparing files P0\P002\stdout.pgm and ..\SRC\P0\P002\STDOUT.PGMFC: no differences encounteredComparing files P0\P002\stderr.pgm and ..\SRC\P0\P002\STDERR.PGMFC: no differences encounteredand almost the same pattern in the above tests.I would suggest if it is thinkable using NT386 variant with a complete dedicated machine/system, I can try to set up one this week and send the data back (the machine is behind a proxy), but I don't remember the mail explaining the set up, and also want to know if there is a chance of run the tests with one run script.Also what is the best natural way to put a new tests, and the standard name it should > > have?Thanks> >> >> > Enviado desde Correo Yahoo!La bandeja de entrada m?s inteligente.> > > > -- > 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 jayk123 at hotmail.com  Tue May  6 13:25:21 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 6 May 2008 11:25:21 +0000
Subject: [M3devel] m3cc build fails on older MacOS X
In-Reply-To: <20080506130247.50uj68o11twcgkog@mail.elegosoft.com>
References: <20080506075754.o24j7xhx4wgokwwo@mail.elegosoft.com>
	 
	<20080506130247.50uj68o11twcgkog@mail.elegosoft.com>
Message-ID: 

Olaf, can you try without my m3makefile wierdness, that works elsewhere?
 
  cd %CVSROOT%/m3-sys/m3cc    mkdir obj1     cd obj1   ../gcc/configure --disable-bootstrap --enable-languages=c,cm3cg    make 
 I'm not sure of "cm3cg", it might be "m3cg".  And you can just omit that anyway, I doubt the error is m3 related. 
(Tony: I don't believe --srcdir is needed. configure figures it out; granted, maybe not trivially.) 
?
 I expect you will get the same error.  Which isn't the final answer, just some relevant data.   And if I'm wrong, well, that suggests some fix. 
 
 
 - Jay



> Date: Tue, 6 May 2008 13:02:47 +0200> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: RE: [M3devel] m3cc build fails on older MacOS X> > Quoting Jay :> > > I don't know what these Darwin versions are.> > Mac OSX 10.0? 10.1? 10.2? 10.3? 10.4? 10.5?> > I used to run 10.2 and could perhaps bring it back (though I'd hate > > to lose my PPC_LINUX install.. :( )> >> >> make[2]: Nothing to be done for `all'.> Makefile:191: *** > >> Insufficient number of arguments (2) to function > `patsubst'. Stop.> > Hopefully that's enough context though.> >> > The rest is a cascade.> > What happens if you remove all my m3makefile wierdness (which works > > everywhere else..) and just configure and make?> >> > Can I ssh into this?> > Not currently, but I could arrange that sometime this evening (19:00-> 24:00 CEST), if that suits you. I'll take this computer with me on> holidays in two days, so it will probably not be available then.> But you can peek into it today if you want.> > 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  Tue May  6 15:33:18 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 06 May 2008 15:33:18 +0200
Subject: [M3devel] cm3 command line interface and output;
	was: RE: 	www.opencm3.net/m3tests
In-Reply-To: 
References: <313767.59466.qm@web27115.mail.ukl.yahoo.com>
	
	<20080506100711.d2rzqie6ow08csgs@mail.elegosoft.com>
	
	
Message-ID: <20080506153318.a50ttk23488ksk00@mail.elegosoft.com>

Quoting Jay :

> When I say show cm3cg/as invocations, I mean in this new TARGET/cm3.log.
> As I said, I propose exactly the stdout/stderr you want, but then   
> some other output always, a log file.
> Also, about -commands, I have also claimed that it does work --   
> talking out of both sides of my mouth. The extra commands it prints   
> are obviously harmless. I forget what doesn't print, maybe exec vs.   
> q_exec? Also the '@' character wasn't working with q_exec, but that   
> isn't necessarily relevant here..I forgot where I use exec vs.   
> q_exec..
> And there plenty of other ways to debug than -commands and it is   
> "just" a debugging facility..

I've got a rather definite opinion about the output behaviour of
cm3. It's like this, and I would like others to comment, too:

  o cm3 without any switches (-commands, -debug, -verbose) should
    not output any called commands, neither to stdout nor stderr.
    It may print what it is doing in an abstract, target independent
    (short) way. This output may refer to compilation units, interfaces,
    modules, and compilation phases, but not to target specific commands
    and files (unless there are errors, of course) Even then I'd like
    to abstract from differences.

  o cm3 -silent should suppress the normal output, except for warnings
    and error messages.

  o cm3 -commands should output exactly all invokations of externals
    commands so that they can be re-executed from the command line
    if necessary.

I realize that it might not be this way in every aspect, so that
we may need to adapt the code here and there. But in my experience
it has worked this way quite well. Here are some points to consider:

  o We need consistent behaviour and output across all target platforms.
    This is not just a requirement of regression testing, but also of
    a consistent user interface. I don't want different behaviour on
    different platforms.

  o If -commands does not work as expected for some use case,
    we need to fix it.

  o If q_exec or whatever quake function is still deficient in this
    respect, we need to fix/adapt it. It should not be much effort.

  o I find the options -commands, -verbose, -debug, -silent a very
    good categorization of information types, intuitively understandable
    and usable in practive (as I've never had any problems with it, but
    have used them efficiently for years). So I don't see the point
    in changing anything, unless there is a better concept.

  o I don't think it is a good idea to write any log files by default
    (apart from the stdout and stderr streams).

This is of course just my opinion, but unless there are others in
favour of changes (and I'd like some motivation for them) I'd insist
that we keep the existing design.

Olaf

> From: jayk123 at hotmail.comTo: wagner at elegosoft.com;   
> m3devel at elegosoft.comDate: Tue, 6 May 2008 10:57:01 +0000Subject:   
> Re: [M3devel] www.opencm3.net/m3tests
>
>
> Olaf, I don't entirely agree.The logs should be fairly informative   
> without intervention.Just not too verbose. I'd would rather remove   
> the lines that say "compiling" and show the cm3cg invocations.But   
> more than one line per source file is too much.-commands doesn't   
> really work. Lots of bogus extra commands are echoed (rm .tmp), and   
> not all the commands that are run are echoed. I understand that   
> stability for tests is also a goal, but information for the   
> interactive user and for post mortem debugging via a log is also   
> valuable, and these are contrary to stability-for-tests. Somehow   
> contradictory goals need to be met. How about a compromise?How about  
>  we always log more stuff to TARGET/cm3.log? And then exactly what   
> you want to stdout/stderr?While, as I said, more than one line per   
> file is overkill, as part of this compromise I'd be willing to   
> include the cm3cg and as invocation. Have folks used build.exe in   
> the Windows NT DDK?It's model is close to what you get here.It has   
> three sets of information:  to the console/stdout   build.log,   
> build.exe is a wrapper over make, and this includes all the make   
> output -- all the command lines run   build.err, a small subset of   
> console/stdout output My "design" here has been to avoid   
> over-verbosity. Link and mt run on the order of once, or a small   
> number of times, per directory, so showing the full command line   
> (response files...) isn't so verbose -- vs. say something shown once  
>  per compiled file. There's another "problem" here that I have  
> partly  fixed.Underlying errors are not shown on  
> console/stdout/stderr.They  are often in like TARGET/m3core.lst. I  
> changed stuff to refer to  that file, after having hunted the errors  
> down myself slowly the  first time. We could change things to alway  
> says "see  TARGET/cm3.log" for more information, or somesuch.  - Jay
>
>> Date: Tue, 6 May 2008 10:07:11 +0200> From: wagner at elegosoft.com>   
>> To: m3devel at elegosoft.com> Subject: Re: [M3devel]   
>> www.opencm3.net/m3tests> > Quoting Jay :> > >   
>> The "problem" here, a really really small one, is just that the   
>> link > > and mt commands got echoed.> > Olaf made them not echoed.   
>> I then made them conditionally echoed.> > I made m3-sys\m3tests   
>> define M3TESTS so that NT386.common doesn't echo.> > It's not a big  
>>  deal either way.> > Aha -- tests in other directories would have a  
>>  problem, and I think > > there are some.> >> > I like more echoing  
>>  usually, so the system explains what is going on,> > instead of  
>> the  vaguer "linking foo" sort of message.> > Granted, nobody  
>> bothers  watching gcc run assembler commands, so I > > guess it is  
>> just  quite gray.> > Jay, cm3 needs to behave the same on all  
>> platforms.  By default> commands should _not_ be echoed to stdout  
>> or stderr;  that's what the> -commands switch is for: this gives  
>> you exactly  the commands the> compiler issues to invoke other  
>> tools.> > For  more verbose output, you may also depend on the  
>> -verbose or the>  -debug switches.> > Please adapt the  
>> configuration files that bey  default all echoing> of commands is  
>> off.> > Olaf> > > I don't know  how to run the Tinderbox either  
>> yet, sorry.> > I tried.> >> > For  adding tests, well, there is  
>> m3-sys\m3tests.> > That is where a lot  of the tests are, but not  
>> all.> > I am not sure where tests belong.  I added a small number  
>> there.> > They are named with just a letter  and a number.> > The  
>> letters have some meaning, explained in the  m3makefile.> > "p" is  
>> programs that are run and their stdout/stderr  compared > > against  
>> expected> > "e" is programs build and the  errors from the compiler  
>> checked to be > > reasonable.> > I don't  think in general they are  
>> expected to successfully compile > > or  run, though the case of  
>> "warnings" may be unclear.> > "c" is  programs built so a human can  
>> look at the generated code.> > There  is another case I think for  
>> human checking.> > The numbers are just  001, 002, 003, etc.> >  
>> Each hundred tests are in a separate  directory, like p0\p001, > >  
>> p0\p002, p1\p100, p1\101, etc.> >> >  Something like this.> >  
>> Wherever I have details wrong, just look in  m3-sys\m3tests. It's >  
>> > pretty simple, obvious, and well  commented.> >> > The output is  
>> a little clearer if you have a  working diff.exe on the path.> >  
>> Then what you do is search for  "@@" in the output.> >> > - Jay> >>  
>> >> > Date: Tue, 6 May 2008  03:46:27 +0200From:  
>> dabenavidesd at yahoo.esTo: > >  m3devel at elegosoft.comSubject:  
>> [M3devel] www.opencm3.net/m3testsDear  > > developers:Does the  
>> recent tests on NT386 seem broken because a  > > recent change on  
>> the m3-sys tree, or is the HTML bad generated,  I > > mean can you  
>> check the last tests Sunday, May 4th (p001 to  p042) has > > a red  
>> background > >   
>> http://www.opencm3.net/m3tests/m3tests-NT386-2008-04-23-13-30-57.html
p002 Text
Comparing files P0\P002\stdout.build and ..\SRC\P0\P002\STDOUT.BUILD***** P0\P002\stdout.buildlink @_m3responsefile0.txt 2>&1 > pgm.lstmt /nologo /manifest pgm.exe.manifest /outputresource:pgm.exe;1***** ..\SRC\P0\P002\STDOUT.BUILD*****Comparing files P0\P002\stderr.build and ..\SRC\P0\P002\STDERR.BUILDFC: no differences encounteredComparing files P0\P002\stdout.pgm and ..\SRC\P0\P002\STDOUT.PGMFC: no differences encounteredComparing files P0\P002\stderr.pgm and ..\SRC\P0\P002\STDERR.PGMFC: no differences encounteredand almost the same pattern in the above tests.I would suggest if it is thinkable using NT386 variant with a complete dedicated machine/system, I can try to set up one this week and send the data back (the machine is behind a proxy), but I don't remember the mail explaining the set up, and also want to know if there is a chance of run the tests with one run script.Also what is the best natural way to put a new tests, and the standard name it should > > have?Thanks> >> >> > Enviado desde Correo Yahoo!La bandeja de entrada m?s inteligente.> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:   
>> DE163214194>



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



From hosking at cs.purdue.edu  Tue May  6 15:56:40 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 6 May 2008 09:56:40 -0400
Subject: [M3devel] m3cc build fails on older MacOS X
In-Reply-To: 
References: <20080506075754.o24j7xhx4wgokwwo@mail.elegosoft.com>
	
	<20080506130247.50uj68o11twcgkog@mail.elegosoft.com>
	
Message-ID: 

yes,  it should be m m3cg.  --srcdir is not needed.

On May 6, 2008, at 7:25 AM, Jay wrote:

> Olaf, can you try without my m3makefile wierdness, that works  
> elsewhere?
>
>   cd %CVSROOT%/m3-sys/m3cc
>   mkdir obj1
>   cd obj1
>   ../gcc/configure --disable-bootstrap --enable-languages=c,cm3cg
>   make
>  I'm not sure of "cm3cg", it might be "m3cg".
>  And you can just omit that anyway, I doubt the error is m3 related.
> (Tony: I don't believe --srcdir is needed. configure figures it out;  
> granted, maybe not trivially.)
>
> ?
>  I expect you will get the same error.
>  Which isn't the final answer, just some relevant data.
>  And if I'm wrong, well, that suggests some fix.
>
>
>  - Jay
>
>
>
> > Date: Tue, 6 May 2008 13:02:47 +0200
> > From: wagner at elegosoft.com
> > To: jayk123 at hotmail.com
> > CC: m3devel at elegosoft.com
> > Subject: RE: [M3devel] m3cc build fails on older MacOS X
> >
> > Quoting Jay :
> >
> > > I don't know what these Darwin versions are.
> > > Mac OSX 10.0? 10.1? 10.2? 10.3? 10.4? 10.5?
> > > I used to run 10.2 and could perhaps bring it back (though I'd  
> hate
> > > to lose my PPC_LINUX install.. :( )
> > >
> > >> make[2]: Nothing to be done for `all'.> Makefile:191: ***
> > >> Insufficient number of arguments (2) to function > `patsubst'.  
> Stop.
> > > Hopefully that's enough context though.
> > >
> > > The rest is a cascade.
> > > What happens if you remove all my m3makefile wierdness (which  
> works
> > > everywhere else..) and just configure and make?
> > >
> > > Can I ssh into this?
> >
> > Not currently, but I could arrange that sometime this evening  
> (19:00-
> > 24:00 CEST), if that suits you. I'll take this computer with me on
> > holidays in two days, so it will probably not be available then.
> > But you can peek into it today if you want.
> >
> > 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 jayk123 at hotmail.com  Tue May  6 16:02:48 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 6 May 2008 14:02:48 +0000
Subject: [M3devel] cm3 command line interface and output;
	was: RE: 	www.opencm3.net/m3tests
In-Reply-To: <20080506153318.a50ttk23488ksk00@mail.elegosoft.com>
References: <313767.59466.qm@web27115.mail.ukl.yahoo.com>
	
	<20080506100711.d2rzqie6ow08csgs@mail.elegosoft.com>
	
	 
	<20080506153318.a50ttk23488ksk00@mail.elegosoft.com>
Message-ID: 

Well, Olaf, I see your point, but I don't entirely agree.
I believe there are contradictory goals.
Which is partly to say, there will always be "problems" here, though I think producing a more detailed log file is a good compromise.
 
In particular, consider the role of "remote debugging", or even local debugging.
Wouldn't it be great if many situations could be debugged from merely looking at "m3.log" from the first and only run that failed? What if the problem is intermittent? You can't always rely on running again with different switches. I have to post-mortem debug lots of stuff and logs are indispensible. They don't always work, and they can't always work, but they can be extremely helpful.
 
To a large extent, you need to plan for failure. There will be errors. When there is an error, what is the design that allows quickest easiest diagnosis, some large percentage of the time? A nice friendly abstract stdout that hides details, or something with more information? Or somethin in between like a friendly stdout and a verbose log file?
 
The need for a cross-platform user experience is unclear -- I want file names printed in a form my editor understands, and my editors unfortunately are not consistent. Perhaps, as you allude, the "success" ui should be cross platform, and in the face of an error, the experience can devolve and contain platform specific details. Here you can see the tests already having problems, as the paths have forward or backward slashes, and "crashes" have different appearances. So far this has been mostly papered over (which reminds me, I need to get the darwin and bsd variants; currently only NT and Linux are handled).
 
For regression tests, yes I understand.
However, stdout/stderr is a very crude thing.
It'd be nice if the code could make, uh, like, "function calls" to indicate what happened instead of random text that is meant to be both human and machine consumable.
But I know that's just too high tech to happen any time soon..
 
(Similarly, "function calls" to drive a compiler are a good idea to. "Command lines" are also very crude and type-unsafe..the whole problem with spaces....)
 
A good example I think of something that doesn't work well today is what happens when there are link errors.
The problem here isn't so much the echoing of commands, but the appearance of the linker output.
All you get is cm3 checks the exit code and/or the existance of the output file and stdout indicates a boolean success/faliure. User has to dig into another file to find the actual error. Now, again, I am talking out of both sides. I argue for a log for the verbose information, and now complain about having to dig into that log. I would at least like to have there be one such log, not one for the link output and nothing else. That would be a little better. The inconvenience of having to dig into a log is a more difficult problem, I know very well, related again to the crudeness of stdout. Because the linker has no structured way to report errors, other than an exit code, whatever wraps it is left to some crude device like attempting to "parse" the stdout. This is a well traveled path, and it can work quite well, but it is also frought with peril, as different linkers and different versions of linkers output errors differently...
 
As well, on the other end of things, you know, if you assume success, you really want less output.
make-dist.cmd is really good this way, though make-dist.py is not yet.
In there I suppress a LOT of output, but I do keep it in logs in case of failure..
 
I don't have a conclusion.
I understand the goals.
I also believe logging, to stdout or to a file, greatly aids debugging.
I think producing a log file in the output directory is a good compromise, and one I have seen successfully used.
  Though you don't want the easy out of having a log file to lead to the log file becoming too verbose. I have seen log files that take a while for some editors to open..and people throwing in "verbose" switches and not realize the damage they are doing. I did it myself once. I threw in /verbose on the Visual C++ linker and the output of that is so voluminous that it slows things down. It's great for debugging certain problems, but too expensive to put in all the time "just in case".
 
 - Jay


> Date: Tue, 6 May 2008 15:33:18 +0200> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: cm3 command line interface and output; was: RE: [M3devel] www.opencm3.net/m3tests> > Quoting Jay :> > > When I say show cm3cg/as invocations, I mean in this new TARGET/cm3.log.> > As I said, I propose exactly the stdout/stderr you want, but then > > some other output always, a log file.> > Also, about -commands, I have also claimed that it does work -- > > talking out of both sides of my mouth. The extra commands it prints > > are obviously harmless. I forget what doesn't print, maybe exec vs. > > q_exec? Also the '@' character wasn't working with q_exec, but that > > isn't necessarily relevant here..I forgot where I use exec vs. > > q_exec..> > And there plenty of other ways to debug than -commands and it is > > "just" a debugging facility..> > I've got a rather definite opinion about the output behaviour of> cm3. It's like this, and I would like others to comment, too:> > o cm3 without any switches (-commands, -debug, -verbose) should> not output any called commands, neither to stdout nor stderr.> It may print what it is doing in an abstract, target independent> (short) way. This output may refer to compilation units, interfaces,> modules, and compilation phases, but not to target specific commands> and files (unless there are errors, of course) Even then I'd like> to abstract from differences.> > o cm3 -silent should suppress the normal output, except for warnings> and error messages.> > o cm3 -commands should output exactly all invokations of externals> commands so that they can be re-executed from the command line> if necessary.> > I realize that it might not be this way in every aspect, so that> we may need to adapt the code here and there. But in my experience> it has worked this way quite well. Here are some points to consider:> > o We need consistent behaviour and output across all target platforms.> This is not just a requirement of regression testing, but also of> a consistent user interface. I don't want different behaviour on> different platforms.> > o If -commands does not work as expected for some use case,> we need to fix it.> > o If q_exec or whatever quake function is still deficient in this> respect, we need to fix/adapt it. It should not be much effort.> > o I find the options -commands, -verbose, -debug, -silent a very> good categorization of information types, intuitively understandable> and usable in practive (as I've never had any problems with it, but> have used them efficiently for years). So I don't see the point> in changing anything, unless there is a better concept.> > o I don't think it is a good idea to write any log files by default> (apart from the stdout and stderr streams).> > This is of course just my opinion, but unless there are others in> favour of changes (and I'd like some motivation for them) I'd insist> that we keep the existing design.> > Olaf> > > From: jayk123 at hotmail.comTo: wagner at elegosoft.com; > > m3devel at elegosoft.comDate: Tue, 6 May 2008 10:57:01 +0000Subject: > > Re: [M3devel] www.opencm3.net/m3tests> >> >> > Olaf, I don't entirely agree.The logs should be fairly informative > > without intervention.Just not too verbose. I'd would rather remove > > the lines that say "compiling" and show the cm3cg invocations.But > > more than one line per source file is too much.-commands doesn't > > really work. Lots of bogus extra commands are echoed (rm .tmp), and > > not all the commands that are run are echoed. I understand that > > stability for tests is also a goal, but information for the > > interactive user and for post mortem debugging via a log is also > > valuable, and these are contrary to stability-for-tests. Somehow > > contradictory goals need to be met. How about a compromise?How about > > we always log more stuff to TARGET/cm3.log? And then exactly what > > you want to stdout/stderr?While, as I said, more than one line per > > file is overkill, as part of this compromise I'd be willing to > > include the cm3cg and as invocation. Have folks used build.exe in > > the Windows NT DDK?It's model is close to what you get here.It has > > three sets of information: to the console/stdout build.log, > > build.exe is a wrapper over make, and this includes all the make > > output -- all the command lines run build.err, a small subset of > > console/stdout output My "design" here has been to avoid > > over-verbosity. Link and mt run on the order of once, or a small > > number of times, per directory, so showing the full command line > > (response files...) isn't so verbose -- vs. say something shown once > > per compiled file. There's another "problem" here that I have > > partly fixed.Underlying errors are not shown on > > console/stdout/stderr.They are often in like TARGET/m3core.lst. I > > changed stuff to refer to that file, after having hunted the errors > > down myself slowly the first time. We could change things to alway > > says "see TARGET/cm3.log" for more information, or somesuch. - Jay> >> >> Date: Tue, 6 May 2008 10:07:11 +0200> From: wagner at elegosoft.com> > >> To: m3devel at elegosoft.com> Subject: Re: [M3devel] > >> www.opencm3.net/m3tests> > Quoting Jay :> > > > >> The "problem" here, a really really small one, is just that the > >> link > > and mt commands got echoed.> > Olaf made them not echoed. > >> I then made them conditionally echoed.> > I made m3-sys\m3tests > >> define M3TESTS so that NT386.common doesn't echo.> > It's not a big > >> deal either way.> > Aha -- tests in other directories would have a > >> problem, and I think > > there are some.> >> > I like more echoing > >> usually, so the system explains what is going on,> > instead of > >> the vaguer "linking foo" sort of message.> > Granted, nobody > >> bothers watching gcc run assembler commands, so I > > guess it is > >> just quite gray.> > Jay, cm3 needs to behave the same on all > >> platforms. By default> commands should _not_ be echoed to stdout > >> or stderr; that's what the> -commands switch is for: this gives > >> you exactly the commands the> compiler issues to invoke other > >> tools.> > For more verbose output, you may also depend on the > >> -verbose or the> -debug switches.> > Please adapt the > >> configuration files that bey default all echoing> of commands is > >> off.> > Olaf> > > I don't know how to run the Tinderbox either > >> yet, sorry.> > I tried.> >> > For adding tests, well, there is > >> m3-sys\m3tests.> > That is where a lot of the tests are, but not > >> all.> > I am not sure where tests belong. I added a small number > >> there.> > They are named with just a letter and a number.> > The > >> letters have some meaning, explained in the m3makefile.> > "p" is > >> programs that are run and their stdout/stderr compared > > against > >> expected> > "e" is programs build and the errors from the compiler > >> checked to be > > reasonable.> > I don't think in general they are > >> expected to successfully compile > > or run, though the case of > >> "warnings" may be unclear.> > "c" is programs built so a human can > >> look at the generated code.> > There is another case I think for > >> human checking.> > The numbers are just 001, 002, 003, etc.> > > >> Each hundred tests are in a separate directory, like p0\p001, > > > >> p0\p002, p1\p100, p1\101, etc.> >> > Something like this.> > > >> Wherever I have details wrong, just look in m3-sys\m3tests. It's > > >> > pretty simple, obvious, and well commented.> >> > The output is > >> a little clearer if you have a working diff.exe on the path.> > > >> Then what you do is search for "@@" in the output.> >> > - Jay> >> > >> >> > Date: Tue, 6 May 2008 03:46:27 +0200From: > >> dabenavidesd at yahoo.esTo: > > m3devel at elegosoft.comSubject: > >> [M3devel] www.opencm3.net/m3testsDear > > developers:Does the > >> recent tests on NT386 seem broken because a > > recent change on > >> the m3-sys tree, or is the HTML bad generated, I > > mean can you > >> check the last tests Sunday, May 4th (p001 to p042) has > > a red > >> background > > > >> http://www.opencm3.net/m3tests/m3tests-NT386-2008-04-23-13-30-57.html
p002 Text
Comparing files P0\P002\stdout.build and ..\SRC\P0\P002\STDOUT.BUILD***** P0\P002\stdout.buildlink @_m3responsefile0.txt 2>&1 > pgm.lstmt /nologo /manifest pgm.exe.manifest /outputresource:pgm.exe;1***** ..\SRC\P0\P002\STDOUT.BUILD*****Comparing files P0\P002\stderr.build and ..\SRC\P0\P002\STDERR.BUILDFC: no differences encounteredComparing files P0\P002\stdout.pgm and ..\SRC\P0\P002\STDOUT.PGMFC: no differences encounteredComparing files P0\P002\stderr.pgm and ..\SRC\P0\P002\STDERR.PGMFC: no differences encounteredand almost the same pattern in the above tests.I would suggest if it is thinkable using NT386 variant with a complete dedicated machine/system, I can try to set up one this week and send the data back (the machine is behind a proxy), but I don't remember the mail explaining the set up, and also want to know if there is a chance of run the tests with one run script.Also what is the best natural way to put a new tests, and the standard name it should > > have?Thanks> >> >> > Enviado desde Correo Yahoo!La bandeja de entrada m?s inteligente.> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > >> DE163214194>> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From hosking at cs.purdue.edu  Tue May  6 16:05:25 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 6 May 2008 10:05:25 -0400
Subject: [M3devel] www.opencm3.net/m3tests
In-Reply-To: 
References: <313767.59466.qm@web27115.mail.ukl.yahoo.com>
	
	<20080506100711.d2rzqie6ow08csgs@mail.elegosoft.com>
	
Message-ID: <48A1BCA0-B727-4777-A16C-BD0673AC4D28@cs.purdue.edu>

On May 6, 2008, at 6:57 AM, Jay wrote:

> Olaf, I don't entirely agree.
> The logs should be fairly informative without intervention.
> Just not too verbose. I'd would rather remove the lines that say  
> "compiling" and show the cm3cg invocations.
> But more than one line per source file is too much.
> -commands doesn't really work. Lots of bogus extra commands are  
> echoed (rm .tmp), and not all the commands that are run are echoed.

Not bogus - it does exactly what one would expect - showing all  
commands executed.   I'm  with  Olaf on this one.

> I understand that stability for tests is also a goal, but  
> information for the interactive user and for post mortem debugging  
> via a log is also valuable, and these are contrary to stability-for- 
> tests. Somehow contradictory goals need to be met.

I prefer terse output for tests  that complete normally.  On detailed   
investigation l can always turn on a verbose flag.

> How about a compromise?
> How about we always log more stuff to TARGET/cm3.log?
>  And then exactly what you want to stdout/stderr?
> While, as I said, more than one line per file is overkill, as part  
> of this compromise I'd be willing to include the cm3cg and as  
> invocation.
>
> Have folks used build.exe in the Windows NT DDK?
> It's model is close to what you get here.
> It has three sets of information:
>   to the console/stdout
>   build.log, build.exe is a wrapper over make, and this includes all  
> the make output -- all the command lines run
>   build.err, a small subset of console/stdout output
>
> My "design" here has been to avoid over-verbosity. Link and mt run  
> on the order of once, or a small number of times, per directory, so  
> showing the full command line (response files...) isn't so verbose  
> -- vs. say something shown once per compiled file.
>
> There's another "problem" here that I have partly fixed.
> Underlying errors are not shown on console/stdout/stderr.
> They are often in like TARGET/m3core.lst.
>
> I changed stuff to refer to that file, after having hunted the  
> errors down myself slowly the first time.
>
> We could change things to alway says "see TARGET/cm3.log" for more  
> information, or somesuch.
>
>  - Jay
>
>
>
> > Date: Tue, 6 May 2008 10:07:11 +0200
> > From: wagner at elegosoft.com
> > To: m3devel at elegosoft.com
> > Subject: Re: [M3devel] www.opencm3.net/m3tests
> >
> > Quoting Jay :
> >
> > > The "problem" here, a really really small one, is just that the  
> link
> > > and mt commands got echoed.
> > > Olaf made them not echoed. I then made them conditionally echoed.
> > > I made m3-sys\m3tests define M3TESTS so that NT386.common  
> doesn't echo.
> > > It's not a big deal either way.
> > > Aha -- tests in other directories would have a problem, and I  
> think
> > > there are some.
> > >
> > > I like more echoing usually, so the system explains what is  
> going on,
> > > instead of the vaguer "linking foo" sort of message.
> > > Granted, nobody bothers watching gcc run assembler commands, so I
> > > guess it is just quite gray.
> >
> > Jay, cm3 needs to behave the same on all platforms. By default
> > commands should _not_ be echoed to stdout or stderr; that's what the
> > -commands switch is for: this gives you exactly the commands the
> > compiler issues to invoke other tools.
> >
> > For more verbose output, you may also depend on the -verbose or the
> > -debug switches.
> >
> > Please adapt the configuration files that bey default all echoing
> > of commands is off.
> >
> > Olaf
> >
> > > I don't know how to run the Tinderbox either yet, sorry.
> > > I tried.
> > >
> > > For adding tests, well, there is m3-sys\m3tests.
> > > That is where a lot of the tests are, but not all.
> > > I am not sure where tests belong. I added a small number there.
> > > They are named with just a letter and a number.
> > > The letters have some meaning, explained in the m3makefile.
> > > "p" is programs that are run and their stdout/stderr compared
> > > against expected
> > > "e" is programs build and the errors from the compiler checked  
> to be
> > > reasonable.
> > > I don't think in general they are expected to successfully compile
> > > or run, though the case of "warnings" may be unclear.
> > > "c" is programs built so a human can look at the generated code.
> > > There is another case I think for human checking.
> > > The numbers are just 001, 002, 003, etc.
> > > Each hundred tests are in a separate directory, like p0\p001,
> > > p0\p002, p1\p100, p1\101, etc.
> > >
> > > Something like this.
> > > Wherever I have details wrong, just look in m3-sys\m3tests. It's
> > > pretty simple, obvious, and well commented.
> > >
> > > The output is a little clearer if you have a working diff.exe on  
> the path.
> > > Then what you do is search for "@@" in the output.
> > >
> > > - Jay
> > >
> > >
> > > Date: Tue, 6 May 2008 03:46:27 +0200From: dabenavidesd at yahoo.esTo:
> > > m3devel at elegosoft.comSubject: [M3devel] www.opencm3.net/ 
> m3testsDear
> > > developers:Does the recent tests on NT386 seem broken because a
> > > recent change on the m3-sys tree, or is the HTML bad generated, I
> > > mean can you check the last tests Sunday, May 4th (p001 to p042)  
> has
> > > a red background
> > > http://www.opencm3.net/m3tests/m3tests-NT386-2008-04-23-13-30-57.html 
>
p002 class="small" width="45%"> Text
Comparing  
> files P0\P002\stdout.build and ..\SRC\P0\P002\STDOUT.BUILD*****  
> P0\P002\stdout.buildlink @_m3responsefile0.txt 2>&1 > pgm.lstmt / 
> nologo /manifest pgm.exe.manifest /outputresource:pgm.exe;1***** .. 
> \SRC\P0\P002\STDOUT.BUILD*****Comparing files P0\P002\stderr.build  
> and ..\SRC\P0\P002\STDERR.BUILDFC: no differences  
> encounteredComparing files P0\P002\stdout.pgm and ..\SRC 
> \P0\P002\STDOUT.PGMFC: no differences encounteredComparing files  
> P0\P002\stderr.pgm and ..\SRC\P0\P002\STDERR.PGMFC: no differences  
> encounteredand almost the same pattern in the above tests.I would  
> suggest if it is thinkable using NT386 variant with a complete  
> dedicated machine/system, I can try to set up one this week and send  
> the data back (the machine is behind a proxy), but I don't remember  
> the mail explaining the set up, and also want to know if there is a  
> chance of run the tests with one run script.Also what is the best  
> natural way to put a new tests, and the standard name it should
> > > have?Thanks
> > >
> > >
> > > Enviado desde Correo Yahoo!La bandeja de entrada m?s inteligente.
> >
> >
> >
> > --
> > 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 hosking at cs.purdue.edu  Tue May  6 16:06:57 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 6 May 2008 10:06:57 -0400
Subject: [M3devel] cm3 command line interface and output;
	was: RE: 	www.opencm3.net/m3tests
In-Reply-To: <20080506153318.a50ttk23488ksk00@mail.elegosoft.com>
References: <313767.59466.qm@web27115.mail.ukl.yahoo.com>
	
	<20080506100711.d2rzqie6ow08csgs@mail.elegosoft.com>
	
	
	<20080506153318.a50ttk23488ksk00@mail.elegosoft.com>
Message-ID: <2D3BBD73-E273-4E9B-AC2D-DCF9A2CCBCAB@cs.purdue.edu>

I'm am strongly with Jay on this one.

On May 6, 2008, at 9:33 AM, Olaf Wagner wrote:

> Quoting Jay :
>
>> When I say show cm3cg/as invocations, I mean in this new TARGET/ 
>> cm3.log.
>> As I said, I propose exactly the stdout/stderr you want, but then   
>> some other output always, a log file.
>> Also, about -commands, I have also claimed that it does work --   
>> talking out of both sides of my mouth. The extra commands it  
>> prints  are obviously harmless. I forget what doesn't print, maybe  
>> exec vs.  q_exec? Also the '@' character wasn't working with  
>> q_exec, but that  isn't necessarily relevant here..I forgot where I  
>> use exec vs.  q_exec..
>> And there plenty of other ways to debug than -commands and it is   
>> "just" a debugging facility..
>
> I've got a rather definite opinion about the output behaviour of
> cm3. It's like this, and I would like others to comment, too:
>
> o cm3 without any switches (-commands, -debug, -verbose) should
>   not output any called commands, neither to stdout nor stderr.
>   It may print what it is doing in an abstract, target independent
>   (short) way. This output may refer to compilation units, interfaces,
>   modules, and compilation phases, but not to target specific commands
>   and files (unless there are errors, of course) Even then I'd like
>   to abstract from differences.
>
> o cm3 -silent should suppress the normal output, except for warnings
>   and error messages.
>
> o cm3 -commands should output exactly all invokations of externals
>   commands so that they can be re-executed from the command line
>   if necessary.
>
> I realize that it might not be this way in every aspect, so that
> we may need to adapt the code here and there. But in my experience
> it has worked this way quite well. Here are some points to consider:
>
> o We need consistent behaviour and output across all target platforms.
>   This is not just a requirement of regression testing, but also of
>   a consistent user interface. I don't want different behaviour on
>   different platforms.
>
> o If -commands does not work as expected for some use case,
>   we need to fix it.
>
> o If q_exec or whatever quake function is still deficient in this
>   respect, we need to fix/adapt it. It should not be much effort.
>
> o I find the options -commands, -verbose, -debug, -silent a very
>   good categorization of information types, intuitively understandable
>   and usable in practive (as I've never had any problems with it, but
>   have used them efficiently for years). So I don't see the point
>   in changing anything, unless there is a better concept.
>
> o I don't think it is a good idea to write any log files by default
>   (apart from the stdout and stderr streams).
>
> This is of course just my opinion, but unless there are others in
> favour of changes (and I'd like some motivation for them) I'd insist
> that we keep the existing design.
>
> Olaf
>
>> From: jayk123 at hotmail.comTo: wagner at elegosoft.com;  m3devel at elegosoft.comDate 
>> : Tue, 6 May 2008 10:57:01 +0000Subject:  Re: [M3devel] www.opencm3.net/m3tests
>>
>>
>> Olaf, I don't entirely agree.The logs should be fairly informative   
>> without intervention.Just not too verbose. I'd would rather remove   
>> the lines that say "compiling" and show the cm3cg invocations.But   
>> more than one line per source file is too much.-commands doesn't   
>> really work. Lots of bogus extra commands are echoed (rm .tmp),  
>> and  not all the commands that are run are echoed. I understand  
>> that  stability for tests is also a goal, but information for the   
>> interactive user and for post mortem debugging via a log is also   
>> valuable, and these are contrary to stability-for-tests. Somehow   
>> contradictory goals need to be met. How about a compromise?How  
>> about  we always log more stuff to TARGET/cm3.log? And then exactly  
>> what  you want to stdout/stderr?While, as I said, more than one  
>> line per  file is overkill, as part of this compromise I'd be  
>> willing to  include the cm3cg and as invocation. Have folks used  
>> build.exe in  the Windows NT DDK?It's model is close to what you  
>> get here.It has  three sets of information:  to the console/ 
>> stdout   build.log,  build.exe is a wrapper over make, and this  
>> includes all the make  output -- all the command lines run    
>> build.err, a small subset of  console/stdout output My "design"  
>> here has been to avoid  over-verbosity. Link and mt run on the  
>> order of once, or a small  number of times, per directory, so  
>> showing the full command line  (response files...) isn't so verbose  
>> -- vs. say something shown once  per compiled file. There's another  
>> "problem" here that I have partly  fixed.Underlying errors are not  
>> shown on console/stdout/stderr.They  are often in like TARGET/ 
>> m3core.lst. I changed stuff to refer to  that file, after having  
>> hunted the errors down myself slowly the  first time. We could  
>> change things to alway says "see  TARGET/cm3.log" for more  
>> information, or somesuch.  - Jay
>>
>>> Date: Tue, 6 May 2008 10:07:11 +0200> From: wagner at elegosoft.com>   
>>> To: m3devel at elegosoft.com> Subject: Re: [M3devel]  www.opencm3.net/m3tests 
>>> > > Quoting Jay :> > >  The "problem" here, a  
>>> really really small one, is just that the  link > > and mt  
>>> commands got echoed.> > Olaf made them not echoed.  I then made  
>>> them conditionally echoed.> > I made m3-sys\m3tests  define  
>>> M3TESTS so that NT386.common doesn't echo.> > It's not a big  deal  
>>> either way.> > Aha -- tests in other directories would have a   
>>> problem, and I think > > there are some.> >> > I like more  
>>> echoing  usually, so the system explains what is going on,> >  
>>> instead of the  vaguer "linking foo" sort of message.> > Granted,  
>>> nobody bothers  watching gcc run assembler commands, so I > >  
>>> guess it is just  quite gray.> > Jay, cm3 needs to behave the same  
>>> on all platforms.  By default> commands should _not_ be echoed to  
>>> stdout or stderr;  that's what the> -commands switch is for: this  
>>> gives you exactly  the commands the> compiler issues to invoke  
>>> other tools.> > For  more verbose output, you may also depend on  
>>> the -verbose or the>  -debug switches.> > Please adapt the  
>>> configuration files that bey  default all echoing> of commands is  
>>> off.> > Olaf> > > I don't know  how to run the Tinderbox either  
>>> yet, sorry.> > I tried.> >> > For  adding tests, well, there is m3- 
>>> sys\m3tests.> > That is where a lot  of the tests are, but not  
>>> all.> > I am not sure where tests belong.  I added a small number  
>>> there.> > They are named with just a letter  and a number.> > The  
>>> letters have some meaning, explained in the  m3makefile.> > "p" is  
>>> programs that are run and their stdout/stderr  compared > >  
>>> against expected> > "e" is programs build and the  errors from the  
>>> compiler checked to be > > reasonable.> > I don't  think in  
>>> general they are expected to successfully compile > > or  run,  
>>> though the case of "warnings" may be unclear.> > "c" is  programs  
>>> built so a human can look at the generated code.> > There  is  
>>> another case I think for human checking.> > The numbers are just   
>>> 001, 002, 003, etc.> > Each hundred tests are in a separate   
>>> directory, like p0\p001, > > p0\p002, p1\p100, p1\101, etc.> >> >   
>>> Something like this.> > Wherever I have details wrong, just look  
>>> in  m3-sys\m3tests. It's > > pretty simple, obvious, and well   
>>> commented.> >> > The output is a little clearer if you have a   
>>> working diff.exe on the path.> > Then what you do is search for   
>>> "@@" in the output.> >> > - Jay> >> >> > Date: Tue, 6 May 2008   
>>> 03:46:27 +0200From: dabenavidesd at yahoo.esTo: > >  m3devel at elegosoft.comSubject 
>>> : [M3devel] www.opencm3.net/m3testsDear  > > developers:Does the  
>>> recent tests on NT386 seem broken because a  > > recent change on  
>>> the m3-sys tree, or is the HTML bad generated,  I > > mean can you  
>>> check the last tests Sunday, May 4th (p001 to  p042) has > > a red  
>>> background > >  http://www.opencm3.net/m3tests/m3tests-NT386-2008-04-23-13-30-57.html 
>>>
p002 >> class="small" width="45%"> Text>> class="small">
Comparing files P0\P002\stdout.build and ..\SRC 
>>> \P0\P002\STDOUT.BUILD***** P0\P002\stdout.buildlink  
>>> @_m3responsefile0.txt 2>&1 > pgm.lstmt /nologo /manifest  
>>> pgm.exe.manifest /outputresource:pgm.exe;1***** ..\SRC 
>>> \P0\P002\STDOUT.BUILD*****Comparing files P0\P002\stderr.build  
>>> and ..\SRC\P0\P002\STDERR.BUILDFC: no differences  
>>> encounteredComparing files P0\P002\stdout.pgm and ..\SRC 
>>> \P0\P002\STDOUT.PGMFC: no differences encounteredComparing files  
>>> P0\P002\stderr.pgm and ..\SRC\P0\P002\STDERR.PGMFC: no differences  
>>> encounteredand almost the same pattern in the above tests.I would  
>>> suggest if it is thinkable using NT386 variant with a complete  
>>> dedicated machine/system, I can try to set up one this week and  
>>> send the data back (the machine is behind a proxy), but I don't  
>>> remember the mail explaining the set up, and also want to know if  
>>> there is a chance of run the tests with one run script.Also what  
>>> is the best natural way to put a new tests, and the standard name  
>>> it should > > have?Thanks> >> >> > Enviado desde Correo Yahoo!La  
>>> bandeja de entrada m?s inteligente.> > > > -- > Olaf Wagner --  
>>> elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12,  
>>> 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177  
>>> 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com |  
>>> Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister:  
>>> Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:  DE163214194>
>
>
>
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin,  
> Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23  
> 45 86 95
>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz:  
> Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:  
> DE163214194
>



From hosking at cs.purdue.edu  Tue May  6 16:07:56 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 6 May 2008 10:07:56 -0400
Subject: [M3devel] cm3 command line interface and output;
	was: RE: 	www.opencm3.net/m3tests
In-Reply-To: <2D3BBD73-E273-4E9B-AC2D-DCF9A2CCBCAB@cs.purdue.edu>
References: <313767.59466.qm@web27115.mail.ukl.yahoo.com>
	
	<20080506100711.d2rzqie6ow08csgs@mail.elegosoft.com>
	
	
	<20080506153318.a50ttk23488ksk00@mail.elegosoft.com>
	<2D3BBD73-E273-4E9B-AC2D-DCF9A2CCBCAB@cs.purdue.edu>
Message-ID: <5F69E624-4EFD-43D6-A852-6938AE62C9BC@cs.purdue.edu>

Oops I meant *Olaf* !

On May 6, 2008, at 10:06 AM, Tony Hosking wrote:

> I'm am strongly with Jay on this one.
>
> On May 6, 2008, at 9:33 AM, Olaf Wagner wrote:
>
>> Quoting Jay :
>>
>>> When I say show cm3cg/as invocations, I mean in this new TARGET/ 
>>> cm3.log.
>>> As I said, I propose exactly the stdout/stderr you want, but then   
>>> some other output always, a log file.
>>> Also, about -commands, I have also claimed that it does work --   
>>> talking out of both sides of my mouth. The extra commands it  
>>> prints  are obviously harmless. I forget what doesn't print, maybe  
>>> exec vs.  q_exec? Also the '@' character wasn't working with  
>>> q_exec, but that  isn't necessarily relevant here..I forgot where  
>>> I use exec vs.  q_exec..
>>> And there plenty of other ways to debug than -commands and it is   
>>> "just" a debugging facility..
>>
>> I've got a rather definite opinion about the output behaviour of
>> cm3. It's like this, and I would like others to comment, too:
>>
>> o cm3 without any switches (-commands, -debug, -verbose) should
>>  not output any called commands, neither to stdout nor stderr.
>>  It may print what it is doing in an abstract, target independent
>>  (short) way. This output may refer to compilation units, interfaces,
>>  modules, and compilation phases, but not to target specific commands
>>  and files (unless there are errors, of course) Even then I'd like
>>  to abstract from differences.
>>
>> o cm3 -silent should suppress the normal output, except for warnings
>>  and error messages.
>>
>> o cm3 -commands should output exactly all invokations of externals
>>  commands so that they can be re-executed from the command line
>>  if necessary.
>>
>> I realize that it might not be this way in every aspect, so that
>> we may need to adapt the code here and there. But in my experience
>> it has worked this way quite well. Here are some points to consider:
>>
>> o We need consistent behaviour and output across all target  
>> platforms.
>>  This is not just a requirement of regression testing, but also of
>>  a consistent user interface. I don't want different behaviour on
>>  different platforms.
>>
>> o If -commands does not work as expected for some use case,
>>  we need to fix it.
>>
>> o If q_exec or whatever quake function is still deficient in this
>>  respect, we need to fix/adapt it. It should not be much effort.
>>
>> o I find the options -commands, -verbose, -debug, -silent a very
>>  good categorization of information types, intuitively understandable
>>  and usable in practive (as I've never had any problems with it, but
>>  have used them efficiently for years). So I don't see the point
>>  in changing anything, unless there is a better concept.
>>
>> o I don't think it is a good idea to write any log files by default
>>  (apart from the stdout and stderr streams).
>>
>> This is of course just my opinion, but unless there are others in
>> favour of changes (and I'd like some motivation for them) I'd insist
>> that we keep the existing design.
>>
>> Olaf
>>
>>> From: jayk123 at hotmail.comTo: wagner at elegosoft.com;  m3devel at elegosoft.comDate 
>>> : Tue, 6 May 2008 10:57:01 +0000Subject:  Re: [M3devel] www.opencm3.net/m3tests
>>>
>>>
>>> Olaf, I don't entirely agree.The logs should be fairly  
>>> informative  without intervention.Just not too verbose. I'd would  
>>> rather remove  the lines that say "compiling" and show the cm3cg  
>>> invocations.But  more than one line per source file is too much.- 
>>> commands doesn't  really work. Lots of bogus extra commands are  
>>> echoed (rm .tmp), and  not all the commands that are run are  
>>> echoed. I understand that  stability for tests is also a goal, but  
>>> information for the  interactive user and for post mortem  
>>> debugging via a log is also  valuable, and these are contrary to  
>>> stability-for-tests. Somehow  contradictory goals need to be met.  
>>> How about a compromise?How about  we always log more stuff to  
>>> TARGET/cm3.log? And then exactly what  you want to stdout/stderr? 
>>> While, as I said, more than one line per  file is overkill, as  
>>> part of this compromise I'd be willing to  include the cm3cg and  
>>> as invocation. Have folks used build.exe in  the Windows NT DDK? 
>>> It's model is close to what you get here.It has  three sets of  
>>> information:  to the console/stdout   build.log,  build.exe is a  
>>> wrapper over make, and this includes all the make  output -- all  
>>> the command lines run   build.err, a small subset of  console/ 
>>> stdout output My "design" here has been to avoid  over-verbosity.  
>>> Link and mt run on the order of once, or a small  number of times,  
>>> per directory, so showing the full command line  (response  
>>> files...) isn't so verbose -- vs. say something shown once  per  
>>> compiled file. There's another "problem" here that I have partly   
>>> fixed.Underlying errors are not shown on console/stdout/ 
>>> stderr.They  are often in like TARGET/m3core.lst. I changed stuff  
>>> to refer to  that file, after having hunted the errors down myself  
>>> slowly the  first time. We could change things to alway says "see   
>>> TARGET/cm3.log" for more information, or somesuch.  - Jay
>>>
>>>> Date: Tue, 6 May 2008 10:07:11 +0200> From:  
>>>> wagner at elegosoft.com>  To: m3devel at elegosoft.com> Subject: Re:  
>>>> [M3devel]  www.opencm3.net/m3tests> > Quoting Jay >>> >:> > >  The "problem" here, a really really small one, is just  
>>>> that the  link > > and mt commands got echoed.> > Olaf made them  
>>>> not echoed.  I then made them conditionally echoed.> > I made m3- 
>>>> sys\m3tests  define M3TESTS so that NT386.common doesn't echo.> >  
>>>> It's not a big  deal either way.> > Aha -- tests in other  
>>>> directories would have a  problem, and I think > > there are  
>>>> some.> >> > I like more echoing  usually, so the system explains  
>>>> what is going on,> > instead of the  vaguer "linking foo" sort of  
>>>> message.> > Granted, nobody bothers  watching gcc run assembler  
>>>> commands, so I > > guess it is just  quite gray.> > Jay, cm3  
>>>> needs to behave the same on all platforms.  By default> commands  
>>>> should _not_ be echoed to stdout or stderr;  that's what the> - 
>>>> commands switch is for: this gives you exactly  the commands the>  
>>>> compiler issues to invoke other tools.> > For  more verbose  
>>>> output, you may also depend on the -verbose or the>  -debug  
>>>> switches.> > Please adapt the configuration files that bey   
>>>> default all echoing> of commands is off.> > Olaf> > > I don't  
>>>> know  how to run the Tinderbox either yet, sorry.> > I tried.> >>  
>>>> > For  adding tests, well, there is m3-sys\m3tests.> > That is  
>>>> where a lot  of the tests are, but not all.> > I am not sure  
>>>> where tests belong.  I added a small number there.> > They are  
>>>> named with just a letter  and a number.> > The letters have some  
>>>> meaning, explained in the  m3makefile.> > "p" is programs that  
>>>> are run and their stdout/stderr  compared > > against expected> >  
>>>> "e" is programs build and the  errors from the compiler checked  
>>>> to be > > reasonable.> > I don't  think in general they are  
>>>> expected to successfully compile > > or  run, though the case of  
>>>> "warnings" may be unclear.> > "c" is  programs built so a human  
>>>> can look at the generated code.> > There  is another case I think  
>>>> for human checking.> > The numbers are just  001, 002, 003, etc.>  
>>>> > Each hundred tests are in a separate  directory, like p0\p001,  
>>>> > > p0\p002, p1\p100, p1\101, etc.> >> >  Something like this.> >  
>>>> Wherever I have details wrong, just look in  m3-sys\m3tests. It's  
>>>> > > pretty simple, obvious, and well  commented.> >> > The output  
>>>> is a little clearer if you have a  working diff.exe on the path.>  
>>>> > Then what you do is search for  "@@" in the output.> >> > -  
>>>> Jay> >> >> > Date: Tue, 6 May 2008  03:46:27 +0200From: dabenavidesd at yahoo.esTo 
>>>> : > >  m3devel at elegosoft.comSubject: [M3devel] www.opencm3.net/m3testsDear 
>>>>   > > developers:Does the recent tests on NT386 seem broken  
>>>> because a  > > recent change on the m3-sys tree, or is the HTML  
>>>> bad generated,  I > > mean can you check the last tests Sunday,  
>>>> May 4th (p001 to  p042) has > > a red background > >  http://www.opencm3.net/m3tests/m3tests-NT386-2008-04-23-13-30-57.html 
>>>>
p002 >>> class="small" width="45%"> Text>>> class="small">
Comparing files P0\P002\stdout.build and ..\SRC 
>>>> \P0\P002\STDOUT.BUILD***** P0\P002\stdout.buildlink  
>>>> @_m3responsefile0.txt 2>&1 > pgm.lstmt /nologo /manifest  
>>>> pgm.exe.manifest /outputresource:pgm.exe;1***** ..\SRC 
>>>> \P0\P002\STDOUT.BUILD*****Comparing files P0\P002\stderr.build  
>>>> and ..\SRC\P0\P002\STDERR.BUILDFC: no differences  
>>>> encounteredComparing files P0\P002\stdout.pgm and ..\SRC 
>>>> \P0\P002\STDOUT.PGMFC: no differences encounteredComparing files  
>>>> P0\P002\stderr.pgm and ..\SRC\P0\P002\STDERR.PGMFC: no  
>>>> differences encounteredand almost the same pattern in the above  
>>>> tests.I would suggest if it is thinkable using NT386 variant with  
>>>> a complete dedicated machine/system, I can try to set up one this  
>>>> week and send the data back (the machine is behind a proxy), but  
>>>> I don't remember the mail explaining the set up, and also want to  
>>>> know if there is a chance of run the tests with one run  
>>>> script.Also what is the best natural way to put a new tests, and  
>>>> the standard name it should > > have?Thanks> >> >> > Enviado  
>>>> desde Correo Yahoo!La bandeja de entrada m?s inteligente.> > > >  
>>>> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer- 
>>>> Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45  
>>>> 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com 
>>>>  | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister:  
>>>> Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:  DE163214194>
>>
>>
>>
>> -- 
>> Olaf Wagner -- elego Software Solutions GmbH
>>              Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin,  
>> Germany
>> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23  
>> 45 86 95
>>  http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz:  
>> Berlin
>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:  
>> DE163214194
>>
>



From jayk123 at hotmail.com  Tue May  6 16:16:35 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 6 May 2008 14:16:35 +0000
Subject: [M3devel] www.opencm3.net/m3tests
In-Reply-To: <48A1BCA0-B727-4777-A16C-BD0673AC4D28@cs.purdue.edu>
References: <313767.59466.qm@web27115.mail.ukl.yahoo.com>
	
	<20080506100711.d2rzqie6ow08csgs@mail.elegosoft.com>
	
	<48A1BCA0-B727-4777-A16C-BD0673AC4D28@cs.purdue.edu>
Message-ID: 

The bogus commands are actually a "simulation" of what the code is doing, I think.
It isn't so dumb as to run little rm commands here it and there. It deletes files without running anything and prints stuff that if run will approximate what it did. It is indeed worthwhile I think, though it isn't "-commands" per se.
That's my vague understanding not having read the code closely.
The "strange" thing is to see "rm" commands on NT386.
 
Planning for success is arguably wrong.
There will be errors. They need to be debugged.
You can't always rerun the scenario.
 
I think a log file with a little more information is a reasonable compromise.
 
Even that is gray. For example, the log file should not contain the output of -trace.
That's just too low level, too voluminous, and fails too rarely to be interesting.
 
Echoing command lines always into a log seems good on the assumption that command lines are expensive, so the i/o to put them in a log should be ok. This isn't entirely true, what with stuff like mkdir and rm.
On the assumption that command lines are running "big" things that "often" fail.
Again this is mixed. Most systems that show command lines still hide many.
ie: invocations of gcc are often shown, but invocations of cc1 and as not so much.
 
Personally I debug a lot of stuff and I err in favor of debuggability, be it live or post-mortem.
Debugging is hard enough, I don't like the obvious easy powers taken away from me.
I know logging and printf is incredibly crude vs. stepping through code in a debugger, but I also had it be fantastically successful and fast too many times to discount. Esp. in data-intensive code where the same code runs successfully many times before the problem occurs.
 
I will grant that in my Modula-3 use, debugging has mostly been easy enough, the repro cases available enough, that optimizing for post-mortem debugging of one and only one instance of a problem is probably overkill.
But still, a log file seems reasonable..
(The debugging has actually been not easy, quite difficult at times, the NT386GNU X windows problem, the double aligment, the stat overflow...but the repro cases and ability to peel the onion in run after run after run has been good; like cm3cg -y for example..and the logging we are talking about only helps in the easiest of cases...)
 
 - Jay


CC: wagner at elegosoft.com; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] www.opencm3.net/m3testsDate: Tue, 6 May 2008 10:05:25 -0400

On May 6, 2008, at 6:57 AM, Jay wrote:


Olaf, I don't entirely agree.The logs should be fairly informative without intervention.Just not too verbose. I'd would rather remove the lines that say "compiling" and show the cm3cg invocations.But more than one line per source file is too much.-commands doesn't really work. Lots of bogus extra commands are echoed (rm .tmp), and not all the commands that are run are echoed.

Not bogus - it does exactly what one would expect - showing all commands executed.   I'm  with  Olaf on this one.


I understand that stability for tests is also a goal, but information for the interactive user and for post mortem debugging via a log is also valuable, and these are contrary to stability-for-tests. Somehow contradictory goals need to be met.

I prefer terse output for tests  that complete normally.  On detailed  investigation l can always turn on a verbose flag.

How about a compromise?How about we always log more stuff to TARGET/cm3.log? And then exactly what you want to stdout/stderr?While, as I said, more than one line per file is overkill, as part of this compromise I'd be willing to include the cm3cg and as invocation. Have folks used build.exe in the Windows NT DDK?It's model is close to what you get here.It has three sets of information:  to the console/stdout   build.log, build.exe is a wrapper over make, and this includes all the make output -- all the command lines run   build.err, a small subset of console/stdout output My "design" here has been to avoid over-verbosity. Link and mt run on the order of once, or a small number of times, per directory, so showing the full command line (response files...) isn't so verbose -- vs. say something shown once per compiled file. There's another "problem" here that I have partly fixed.Underlying errors are not shown on console/stdout/stderr.They are often in like TARGET/m3core.lst. I changed stuff to refer to that file, after having hunted the errors down myself slowly the first time. We could change things to alway says "see TARGET/cm3.log" for more information, or somesuch.  - Jay

> Date: Tue, 6 May 2008 10:07:11 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] www.opencm3.net/m3tests> > Quoting Jay :> > > The "problem" here, a really really small one, is just that the link > > and mt commands got echoed.> > Olaf made them not echoed. I then made them conditionally echoed.> > I made m3-sys\m3tests define M3TESTS so that NT386.common doesn't echo.> > It's not a big deal either way.> > Aha -- tests in other directories would have a problem, and I think > > there are some.> >> > I like more echoing usually, so the system explains what is going on,> > instead of the vaguer "linking foo" sort of message.> > Granted, nobody bothers watching gcc run assembler commands, so I > > guess it is just quite gray.> > Jay, cm3 needs to behave the same on all platforms. By default> commands should _not_ be echoed to stdout or stderr; that's what the> -commands switch is for: this gives you exactly the commands the> compiler issues to invoke other tools.> > For more verbose output, you may also depend on the -verbose or the> -debug switches.> > Please adapt the configuration files that bey default all echoing> of commands is off.> > Olaf> > > I don't know how to run the Tinderbox either yet, sorry.> > I tried.> >> > For adding tests, well, there is m3-sys\m3tests.> > That is where a lot of the tests are, but not all.> > I am not sure where tests belong. I added a small number there.> > They are named with just a letter and a number.> > The letters have some meaning, explained in the m3makefile.> > "p" is programs that are run and their stdout/stderr compared > > against expected> > "e" is programs build and the errors from the compiler checked to be > > reasonable.> > I don't think in general they are expected to successfully compile > > or run, though the case of "warnings" may be unclear.> > "c" is programs built so a human can look at the generated code.> > There is another case I think for human checking.> > The numbers are just 001, 002, 003, etc.> > Each hundred tests are in a separate directory, like p0\p001, > > p0\p002, p1\p100, p1\101, etc.> >> > Something like this.> > Wherever I have details wrong, just look in m3-sys\m3tests. It's > > pretty simple, obvious, and well commented.> >> > The output is a little clearer if you have a working diff.exe on the path.> > Then what you do is search for "@@" in the output.> >> > - Jay> >> >> > Date: Tue, 6 May 2008 03:46:27 +0200From: dabenavidesd at yahoo.esTo: > > m3devel at elegosoft.comSubject: [M3devel] www.opencm3.net/m3testsDear > > developers:Does the recent tests on NT386 seem broken because a > > recent change on the m3-sys tree, or is the HTML bad generated, I > > mean can you check the last tests Sunday, May 4th (p001 to p042) has > > a red background > > http://www.opencm3.net/m3tests/m3tests-NT386-2008-04-23-13-30-57.html
p002 Text
Comparing files P0\P002\stdout.build and ..\SRC\P0\P002\STDOUT.BUILD***** P0\P002\stdout.buildlink @_m3responsefile0.txt 2>&1 > pgm.lstmt /nologo /manifest pgm.exe.manifest /outputresource:pgm.exe;1***** ..\SRC\P0\P002\STDOUT.BUILD*****Comparing files P0\P002\stderr.build and ..\SRC\P0\P002\STDERR.BUILDFC: no differences encounteredComparing files P0\P002\stdout.pgm and ..\SRC\P0\P002\STDOUT.PGMFC: no differences encounteredComparing files P0\P002\stderr.pgm and ..\SRC\P0\P002\STDERR.PGMFC: no differences encounteredand almost the same pattern in the above tests.I would suggest if it is thinkable using NT386 variant with a complete dedicated machine/system, I can try to set up one this week and send the data back (the machine is behind a proxy), but I don't remember the mail explaining the set up, and also want to know if there is a chance of run the tests with one run script.Also what is the best natural way to put a new tests, and the standard name it should > > have?Thanks> >> >> > Enviado desde Correo Yahoo!La bandeja de entrada m?s inteligente.> > > > -- > 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  Tue May  6 23:07:36 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 06 May 2008 23:07:36 +0200
Subject: [M3devel] m3cc build fails on older MacOS X
In-Reply-To: 
References: <20080506075754.o24j7xhx4wgokwwo@mail.elegosoft.com>
	
	<20080506130247.50uj68o11twcgkog@mail.elegosoft.com>
	
Message-ID: <20080506230736.n106yopfkwooo4s0@mail.elegosoft.com>

Quoting Jay :

> Olaf, can you try without my m3makefile wierdness, that works elsewhere?
>
>   cd %CVSROOT%/m3-sys/m3cc    mkdir obj1     cd obj1     
> ../gcc/configure --disable-bootstrap --enable-languages=c,cm3cg      
> make
>  I'm not sure of "cm3cg", it might be "m3cg".  And you can just omit  
>  that anyway, I doubt the error is m3 related.
> (Tony: I don't believe --srcdir is needed. configure figures it out;  
>  granted, maybe not trivially.)
> ?
>  I expect you will get the same error.  Which isn't the final   
> answer, just some relevant data.   And if I'm wrong, well, that   
> suggests some fix.

I got home later than expected. The build now stops at a different
step:

/Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/xgcc  
-B/Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/  
-B/usr/local/powerpc-apple-darwin7.9.0/bin/  
-B/usr/local/powerpc-apple-darwin7.9.0/lib/ -isystem  
/usr/local/powerpc-apple-darwin7.9.0/include -isystem  
/usr/local/powerpc-apple-darwin7.9.0/sys-include -O2  -O2 -g -g -O2    
-DIN_GCC    -W -Wall -Wwrite-strings -Wstrict-prototypes  
-Wmissing-prototypes -Wold-style-definition  -isystem ./include   
-Wa,-force_cpusubtype_ALL -pipe -mmacosx-version-min=10.4 -g  
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -dynamiclib  
-nodefaultlibs -install_name /usr/local/lib/libgcc_s`if test . = ppc64  
; then echo _. ; fi`.1.dylib -single_module -o ./libgcc_s.1.dylib.tmp  
-Wl,-exported_symbols_list,libgcc.map -compatibility_version 1  
-current_version 1.0 -O2 -g -g -O2 -B./ _muldi3_s.o _negdi2_s.o  
_lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o  
_clear_cache_s.o _enable_execute_stack_s.o _trampoline_s.o __main_s.o  
_absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o  
_subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o  
_ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o  
_ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o  
_popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o  
_powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o _muldc3_s.o  
_mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o  
_divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _fixunssfsi_s.o  
_fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o  
_fixtfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o  
_fixunstfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o  
_floatditf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o  
_floatunditf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o  
_udiv_w_sdiv_s.o _udivmoddi4_s.o darwin-tramp_s.o ppc64-fp_s.o  
darwin-64_s.o darwin-ldouble_s.o darwin-world_s.o unwind-dw2_s.o  
unwind-dw2-fde-darwin_s.o unwind-sjlj_s.o unwind-c_s.o  
darwin-fallback_s.o emutls_s.o -lc
/usr/bin/ld: unknown flag: -macosx_version_min
collect2: ld returned 1 exit status
make[2]: *** [libgcc_s.dylib] Error 1
make[1]: *** [all-target-libgcc] Error 2
make: *** [all] Error 2

I'm too sleepy to investigate further now,

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



From jayk123 at hotmail.com  Tue May  6 23:18:14 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 6 May 2008 21:18:14 +0000
Subject: [M3devel] m3cc build fails on older MacOS X
In-Reply-To: <20080506230736.n106yopfkwooo4s0@mail.elegosoft.com>
References: <20080506075754.o24j7xhx4wgokwwo@mail.elegosoft.com>
	
	<20080506130247.50uj68o11twcgkog@mail.elegosoft.com>
	 
	<20080506230736.n106yopfkwooo4s0@mail.elegosoft.com>
Message-ID: 

Search the web...
http://projects.scipy.org/pipermail/scipy-user/2007-March/011372.html
 
"
I've got a Mac OSx 10.4.8 machine and am compilingscipy according to the instructions on the webpage.  I'vegot gcc 4.0.0 gfortran 4.3.0 fftw3.0 and svn versions of numpyand scipy.   My python is version 2.5.Building numpy goes smoothly, but when I try scipy I have an ld error....
 
I have gcc 4.0.1 and gfortran 4.3.0 installed on my system, and I do not seethis problem. Can you try upgrading to the latest version of Xcode (which shouldhave gcc 4.0.1)? It's not coming from Python but, I suspect, gfortran.
...
Indeed-- after an almost 1Gig download of XCode 2.4.1 to get gcc 4.0.1it compiled and runs. :)  The tests give me 4 failed, but these  already havebeen noted on the email list...."
1) Upgrade to 2.4.1/4.0.1
2) configure should sniff for this and remove it if not supported.
 
 - Jay



> Date: Tue, 6 May 2008 23:07:36 +0200> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: RE: [M3devel] m3cc build fails on older MacOS X> > Quoting Jay :> > > Olaf, can you try without my m3makefile wierdness, that works elsewhere?> >> > cd %CVSROOT%/m3-sys/m3cc mkdir obj1 cd obj1 > > ../gcc/configure --disable-bootstrap --enable-languages=c,cm3cg > > make> > I'm not sure of "cm3cg", it might be "m3cg". And you can just omit > > that anyway, I doubt the error is m3 related.> > (Tony: I don't believe --srcdir is needed. configure figures it out; > > granted, maybe not trivially.)> > ?> > I expect you will get the same error. Which isn't the final > > answer, just some relevant data. And if I'm wrong, well, that > > suggests some fix.> > I got home later than expected. The build now stops at a different> step:> > /Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/xgcc > -B/Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/ > -B/usr/local/powerpc-apple-darwin7.9.0/bin/ > -B/usr/local/powerpc-apple-darwin7.9.0/lib/ -isystem > /usr/local/powerpc-apple-darwin7.9.0/include -isystem > /usr/local/powerpc-apple-darwin7.9.0/sys-include -O2 -O2 -g -g -O2 > -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes > -Wmissing-prototypes -Wold-style-definition -isystem ./include > -Wa,-force_cpusubtype_ALL -pipe -mmacosx-version-min=10.4 -g > -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -dynamiclib > -nodefaultlibs -install_name /usr/local/lib/libgcc_s`if test . = ppc64 > ; then echo _. ; fi`.1.dylib -single_module -o ./libgcc_s.1.dylib.tmp > -Wl,-exported_symbols_list,libgcc.map -compatibility_version 1 > -current_version 1.0 -O2 -g -g -O2 -B./ _muldi3_s.o _negdi2_s.o > _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o > _clear_cache_s.o _enable_execute_stack_s.o _trampoline_s.o __main_s.o > _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o > _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o > _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o > _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o > _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o > _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o _muldc3_s.o > _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o > _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _fixunssfsi_s.o > _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o > _fixtfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o > _fixunstfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o > _floatditf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o > _floatunditf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o > _udiv_w_sdiv_s.o _udivmoddi4_s.o darwin-tramp_s.o ppc64-fp_s.o > darwin-64_s.o darwin-ldouble_s.o darwin-world_s.o unwind-dw2_s.o > unwind-dw2-fde-darwin_s.o unwind-sjlj_s.o unwind-c_s.o > darwin-fallback_s.o emutls_s.o -lc> /usr/bin/ld: unknown flag: -macosx_version_min> collect2: ld returned 1 exit status> make[2]: *** [libgcc_s.dylib] Error 1> make[1]: *** [all-target-libgcc] Error 2> make: *** [all] Error 2> > I'm too sleepy to investigate further now,> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From wagner at elegosoft.com  Wed May  7 07:58:30 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Wed, 07 May 2008 07:58:30 +0200
Subject: [M3devel] m3cc build fails on older MacOS X
In-Reply-To: 
References: <20080506075754.o24j7xhx4wgokwwo@mail.elegosoft.com>
	
	<20080506130247.50uj68o11twcgkog@mail.elegosoft.com>
	
Message-ID: <20080507075830.sbcaopz70kg000co@mail.elegosoft.com>

Quoting Jay :

> Olaf, can you try without my m3makefile wierdness, that works elsewhere?
>
>   cd %CVSROOT%/m3-sys/m3cc    mkdir obj1     cd obj1     
> ../gcc/configure --disable-bootstrap --enable-languages=c,cm3cg      
> make
>  I'm not sure of "cm3cg", it might be "m3cg".  And you can just omit  
>  that anyway, I doubt the error is m3 related.
> (Tony: I don't believe --srcdir is needed. configure figures it out;  
>  granted, maybe not trivially.)
> ?
>  I expect you will get the same error.  Which isn't the final   
> answer, just some relevant data.   And if I'm wrong, well, that   
> suggests some fix.

I already answered this late yesterday evening, but somehow the mail
seems to have got lost. The build now stops with a wrong linker
switch:

mv tmp-libgcc.map libgcc.map
# @multilib_flags@ is still needed because this may use
# /Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/xgcc  
-B/Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/  
-B/usr/local/powerpc-apple-darwin7.9.0/bin/  
-B/usr/local/powerpc-apple-darwin7.9.0/lib/ -isystem  
/usr/local/powerpc-apple-darwin7.9.0/include -isystem  
/usr/local/powerpc-apple-darwin7.9.0/sys-include and -O2  -O2 -g -g  
-O2   -DIN_GCC    -W -Wall -Wwrite-strings -Wstrict-prototypes  
-Wmissing-prototypes -Wold-style-definition  -isystem ./include   
-Wa,-force_cpusubtype_ALL -pipe -mmacosx-version-min=10.4 -g  
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  directly.
# @multilib_dir@ is not really necessary, but sometimes it has
# more uses than just a directory name.
/bin/sh ../../../gcc/libgcc/../mkinstalldirs .
/Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/xgcc  
-B/Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/  
-B/usr/local/powerpc-apple-darwin7.9.0/bin/  
-B/usr/local/powerpc-apple-darwin7.9.0/lib/ -isystem  
/usr/local/powerpc-apple-darwin7.9.0/include -isystem  
/usr/local/powerpc-apple-darwin7.9.0/sys-include -O2  -O2 -g -g -O2    
-DIN_GCC    -W -Wall -Wwrite-strings -Wstrict-prototypes  
-Wmissing-prototypes -Wold-style-definition  -isystem ./include   
-Wa,-force_cpusubtype_ALL -pipe -mmacosx-version-min=10.4 -g  
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -dynamiclib  
-nodefaultlibs -install_name /usr/local/lib/libgcc_s`if test . = ppc64  
; then echo _. ; fi`.1.dylib -single_module -o ./libgcc_s.1.dylib.tmp  
-Wl,-exported_symbols_list,libgcc.map -compatibility_version 1  
-current_version 1.0 -O2 -g -g -O2 -B./ _muldi3_s.o _negdi2_s.o  
_lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o  
_clear_cache_s.o _enable_execute_stack_s.o _trampoline_s.o __main_s.o  
_absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o  
_subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o  
_ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o  
_ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o  
_popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o  
_powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o _muldc3_s.o  
_mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o  
_divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _fixunssfsi_s.o  
_fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o  
_fixtfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o  
_fixunstfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o  
_floatditf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o  
_floatunditf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o  
_udiv_w_sdiv_s.o _udivmoddi4_s.o darwin-tramp_s.o ppc64-fp_s.o  
darwin-64_s.o darwin-ldouble_s.o darwin-world_s.o unwind-dw2_s.o  
unwind-dw2-fde-darwin_s.o unwind-sjlj_s.o unwind-c_s.o  
darwin-fallback_s.o emutls_s.o -lc
/usr/bin/ld: unknown flag: -macosx_version_min
collect2: ld returned 1 exit status
make[2]: *** [libgcc_s.dylib] Error 1
make[1]: *** [all-target-libgcc] Error 2
make: *** [all] Error 2

Probably nobody cares anymore for Mac OS X 10.3.9; I'll consider an
upgrade 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 jayk123 at hotmail.com  Wed May  7 08:15:24 2008
From: jayk123 at hotmail.com (Jay)
Date: Wed, 7 May 2008 06:15:24 +0000
Subject: [M3devel] m3cc build fails on older MacOS X
In-Reply-To: <20080507075830.sbcaopz70kg000co@mail.elegosoft.com>
References: <20080506075754.o24j7xhx4wgokwwo@mail.elegosoft.com>
	
	<20080506130247.50uj68o11twcgkog@mail.elegosoft.com>
	 
	<20080507075830.sbcaopz70kg000co@mail.elegosoft.com>
Message-ID: 

I "answered" this, sort of. The mail was truncated but the important point came through.
Someone else reported this circa gcc 4.0 and then fixed in gcc 4.0.1 or such.
 
 > Probably nobody cares anymore for Mac OS X 10.3.9; I'll consider an
I'll add bringing up 10.2 or maybe 10.1 back somewhere on my list..
This should probably handled "upstream" via "configure".
 
Olaf, is what changed my m3makefile-ness or not?
That is, it fails one way with cm3, but differently/later/better with "regular" configure+make?
Could be a flaw in my m3makefile shenanigans. But so far they otherwise work and do cut out unnecessary stuff.
 
I haven't had a chance to look into anything all Tuesday.
 
 - Jay



> Date: Wed, 7 May 2008 07:58:30 +0200> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: RE: [M3devel] m3cc build fails on older MacOS X> > Quoting Jay :> > > Olaf, can you try without my m3makefile wierdness, that works elsewhere?> >> > cd %CVSROOT%/m3-sys/m3cc mkdir obj1 cd obj1 > > ../gcc/configure --disable-bootstrap --enable-languages=c,cm3cg > > make> > I'm not sure of "cm3cg", it might be "m3cg". And you can just omit > > that anyway, I doubt the error is m3 related.> > (Tony: I don't believe --srcdir is needed. configure figures it out; > > granted, maybe not trivially.)> > ?> > I expect you will get the same error. Which isn't the final > > answer, just some relevant data. And if I'm wrong, well, that > > suggests some fix.> > I already answered this late yesterday evening, but somehow the mail> seems to have got lost. The build now stops with a wrong linker> switch:> > mv tmp-libgcc.map libgcc.map> # @multilib_flags@ is still needed because this may use> # /Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/xgcc > -B/Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/ > -B/usr/local/powerpc-apple-darwin7.9.0/bin/ > -B/usr/local/powerpc-apple-darwin7.9.0/lib/ -isystem > /usr/local/powerpc-apple-darwin7.9.0/include -isystem > /usr/local/powerpc-apple-darwin7.9.0/sys-include and -O2 -O2 -g -g > -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes > -Wmissing-prototypes -Wold-style-definition -isystem ./include > -Wa,-force_cpusubtype_ALL -pipe -mmacosx-version-min=10.4 -g > -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED directly.> # @multilib_dir@ is not really necessary, but sometimes it has> # more uses than just a directory name.> /bin/sh ../../../gcc/libgcc/../mkinstalldirs .> /Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/xgcc > -B/Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/ > -B/usr/local/powerpc-apple-darwin7.9.0/bin/ > -B/usr/local/powerpc-apple-darwin7.9.0/lib/ -isystem > /usr/local/powerpc-apple-darwin7.9.0/include -isystem > /usr/local/powerpc-apple-darwin7.9.0/sys-include -O2 -O2 -g -g -O2 > -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes > -Wmissing-prototypes -Wold-style-definition -isystem ./include > -Wa,-force_cpusubtype_ALL -pipe -mmacosx-version-min=10.4 -g > -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -dynamiclib > -nodefaultlibs -install_name /usr/local/lib/libgcc_s`if test . = ppc64 > ; then echo _. ; fi`.1.dylib -single_module -o ./libgcc_s.1.dylib.tmp > -Wl,-exported_symbols_list,libgcc.map -compatibility_version 1 > -current_version 1.0 -O2 -g -g -O2 -B./ _muldi3_s.o _negdi2_s.o > _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o > _clear_cache_s.o _enable_execute_stack_s.o _trampoline_s.o __main_s.o > _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o > _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o > _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o > _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o > _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o > _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o _muldc3_s.o > _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o > _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _fixunssfsi_s.o > _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o > _fixtfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o > _fixunstfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o > _floatditf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o > _floatunditf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o > _udiv_w_sdiv_s.o _udivmoddi4_s.o darwin-tramp_s.o ppc64-fp_s.o > darwin-64_s.o darwin-ldouble_s.o darwin-world_s.o unwind-dw2_s.o > unwind-dw2-fde-darwin_s.o unwind-sjlj_s.o unwind-c_s.o > darwin-fallback_s.o emutls_s.o -lc> /usr/bin/ld: unknown flag: -macosx_version_min> collect2: ld returned 1 exit status> make[2]: *** [libgcc_s.dylib] Error 1> make[1]: *** [all-target-libgcc] Error 2> make: *** [all] Error 2> > Probably nobody cares anymore for Mac OS X 10.3.9; I'll consider an> upgrade 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> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From wagner at elegosoft.com  Wed May  7 08:23:20 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Wed, 07 May 2008 08:23:20 +0200
Subject: [M3devel] m3cc build fails on older MacOS X
In-Reply-To: 
References: <20080506075754.o24j7xhx4wgokwwo@mail.elegosoft.com>
	
	<20080506130247.50uj68o11twcgkog@mail.elegosoft.com>
	
	<20080507075830.sbcaopz70kg000co@mail.elegosoft.com>
	
Message-ID: <20080507082320.iuho7zbpz4w8cw4g@mail.elegosoft.com>

Quoting Jay :

> I "answered" this, sort of. The mail was truncated but the important  
>  point came through.
> Someone else reported this circa gcc 4.0 and then fixed in gcc 4.0.1 or such.

I don't get you here. If there already is a fix or workaround, why
isn't it checked-in? Could you please point me to your corresponding
mail?

>  > Probably nobody cares anymore for Mac OS X 10.3.9; I'll consider an
> I'll add bringing up 10.2 or maybe 10.1 back somewhere on my list..
> This should probably handled "upstream" via "configure".
>
> Olaf, is what changed my m3makefile-ness or not?
> That is, it fails one way with cm3, but differently/later/better   
> with "regular" configure+make?

Yes, it fails differently. I haven't investigated why, though.

> Could be a flaw in my m3makefile shenanigans. But so far they   
> otherwise work and do cut out unnecessary stuff.
>
> I haven't had a chance to look into anything all Tuesday.

No problem, neither had I except for a few minutes.

Olaf

>  - Jay
>
>
>
>> Date: Wed, 7 May 2008 07:58:30 +0200> From: wagner at elegosoft.com>   
>> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: RE:   
>> [M3devel] m3cc build fails on older MacOS X> > Quoting Jay   
>> :> > > Olaf, can you try without my m3makefile  
>>  wierdness, that works elsewhere?> >> > cd %CVSROOT%/m3-sys/m3cc   
>> mkdir obj1 cd obj1 > > ../gcc/configure --disable-bootstrap   
>> --enable-languages=c,cm3cg > > make> > I'm not sure of "cm3cg", it   
>> might be "m3cg". And you can just omit > > that anyway, I doubt the  
>>  error is m3 related.> > (Tony: I don't believe --srcdir is needed.  
>>  configure figures it out; > > granted, maybe not trivially.)> > ?>  
>>  > I expect you will get the same error. Which isn't the final > >   
>> answer, just some relevant data. And if I'm wrong, well, that > >   
>> suggests some fix.> > I already answered this late yesterday   
>> evening, but somehow the mail> seems to have got lost. The build   
>> now stops with a wrong linker> switch:> > mv tmp-libgcc.map   
>> libgcc.map> # @multilib_flags@ is still needed because this may   
>> use> # /Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/xgcc >   
>> -B/Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/ >   
>> -B/usr/local/powerpc-apple-darwin7.9.0/bin/ >   
>> -B/usr/local/powerpc-apple-darwin7.9.0/lib/ -isystem >   
>> /usr/local/powerpc-apple-darwin7.9.0/include -isystem >   
>> /usr/local/powerpc-apple-darwin7.9.0/sys-include and -O2 -O2 -g -g   
>> > -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes >   
>> -Wmissing-prototypes -Wold-style-definition -isystem ./include >   
>> -Wa,-force_cpusubtype_ALL -pipe -mmacosx-version-min=10.4 -g >   
>> -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   
>> directly.> # @multilib_dir@ is not really necessary, but sometimes   
>> it has> # more uses than just a directory name.> /bin/sh   
>> ../../../gcc/libgcc/../mkinstalldirs .>   
>> /Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/xgcc >   
>> -B/Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/ >   
>> -B/usr/local/powerpc-apple-darwin7.9.0/bin/ >   
>> -B/usr/local/powerpc-apple-darwin7.9.0/lib/ -isystem >   
>> /usr/local/powerpc-apple-darwin7.9.0/include -isystem >   
>> /usr/local/powerpc-apple-darwin7.9.0/sys-include -O2 -O2 -g -g -O2   
>> > -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes >   
>> -Wmissing-prototypes -Wold-style-definition -isystem ./include >   
>> -Wa,-force_cpusubtype_ALL -pipe -mmacosx-version-min=10.4 -g >   
>> -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   
>> -dynamiclib > -nodefaultlibs -install_name   
>> /usr/local/lib/libgcc_s`if test . = ppc64 > ; then echo _. ;   
>> fi`.1.dylib -single_module -o ./libgcc_s.1.dylib.tmp >   
>> -Wl,-exported_symbols_list,libgcc.map -compatibility_version 1 >   
>> -current_version 1.0 -O2 -g -g -O2 -B./ _muldi3_s.o _negdi2_s.o >   
>> _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o >   
>> _clear_cache_s.o _enable_execute_stack_s.o _trampoline_s.o   
>> __main_s.o > _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o   
>> _subvsi3_s.o > _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o   
>> _negvdi2_s.o > _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o   
>> _clzsi2_s.o _clzdi2_s.o > _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o  
>>  _popcountsi2_s.o > _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o   
>> _powisf2_s.o > _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o   
>> _muldc3_s.o > _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o   
>> _divxc3_s.o > _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o   
>> _fixunssfsi_s.o > _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o   
>> _fixdfdi_s.o _fixxfdi_s.o > _fixtfdi_s.o _fixunssfdi_s.o   
>> _fixunsdfdi_s.o _fixunsxfdi_s.o > _fixunstfdi_s.o _floatdisf_s.o   
>> _floatdidf_s.o _floatdixf_s.o > _floatditf_s.o _floatundisf_s.o   
>> _floatundidf_s.o _floatundixf_s.o > _floatunditf_s.o _divdi3_s.o   
>> _moddi3_s.o _udivdi3_s.o _umoddi3_s.o > _udiv_w_sdiv_s.o   
>> _udivmoddi4_s.o darwin-tramp_s.o ppc64-fp_s.o > darwin-64_s.o   
>> darwin-ldouble_s.o darwin-world_s.o unwind-dw2_s.o >   
>> unwind-dw2-fde-darwin_s.o unwind-sjlj_s.o unwind-c_s.o >   
>> darwin-fallback_s.o emutls_s.o -lc> /usr/bin/ld: unknown flag:   
>> -macosx_version_min> collect2: ld returned 1 exit status> make[2]:   
>> *** [libgcc_s.dylib] Error 1> make[1]: *** [all-target-libgcc]   
>> Error 2> make: *** [all] Error 2> > Probably nobody cares anymore   
>> for Mac OS X 10.3.9; I'll consider an> upgrade 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>



-- 
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 jayk123 at hotmail.com  Thu May  8 00:09:36 2008
From: jayk123 at hotmail.com (Jay)
Date: Wed, 7 May 2008 22:09:36 +0000
Subject: [M3devel] AMD64_LINUX snapshots available,
	without garbage collection
Message-ID: 


Now available at http://modula3.elegosoft.com/cm3/uploaded-archives/index.html


  cm3-min-POSIX-AMD64_LINUX-d5.7.0.tar.bz2
  cm3-min-POSIX-AMD64_LINUX-d5.7.0.tar.bz2


With some MAJOR caveats:


formsedit crashes
I haven't run most of the binaries.
Juno comes up.
Calculator comes up.
It builds itself -- cm3 works.
cm3cg is x86 hosted, can target x86 or AMD64 with -m32 or -m64.
cm3 is AMD64 hosted.


GARBAGE COLLECTION IS TURNED OFF via a one line hack in RTCollector.m3.
Turning it on crashes, not always in the same place.
This needs to be debugged.


This in a cminstall-less form, made with scripts/python/make-dist.py
  and manually patched to have Linux.common.


I have not yet tried m3tests.
I will shortly.


I also have TextLiteral.i3 locally changed to enable building from a 32 bit cm3.
Not a big deal, but if you are a stickler for binaries matching source..


If anyone else wants to debug the crashes with the garbage collector enabled, be my guest.
An easy repro is to build in m3-win/import-libs with cm3 -trace.
I assume -trace just causes more stuff to occur, more time to pass.


I didn't handle Uin.i3/Uucontext.i3 yet, hm.


This target is easily bootstrapped using x86 tools on an AMD64 system.
(ie: cm3; cm3cg as I said is still x86).
Hopefully soon I'll bring up platforms that don't have this 'cheat' available. :)

I do like:

 su
 cd /
 rm -rf /cm3
 tar xvf /cm3-min-POSIX-AMD64_LINUX-d5.7.0.tar.bz2
 cp -Rpv cm3-min-POSIX-AMD64_LINUX-d5.7.0 /cm3
 chown -R jay:jay /cm3
export PATH=$PATH:/cm3/bin
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/cm3/lib

However those are wrong if the paths are empty. They add the current working directory to the path if so, since "empty" is equivalent to ".", unfortunately. It should just be skipped/ignored but oh well.

I am using Ubuntu 8.4 Hardy Heron.
(Xubuntu, that was disappointing, so then apt-get-install kde or such)

 - Jay


From jayk123 at hotmail.com  Thu May  8 17:38:23 2008
From: jayk123 at hotmail.com (Jay)
Date: Thu, 8 May 2008 15:38:23 +0000
Subject: [M3devel] the matter of logging vs. NT386 C compilation
Message-ID: 

The Visual C++ compiler outputs source file name as they are compiled:
D:\dev2\cm3\m3-libs\m3core>cl -nologo -c nul.cnul.c
 
D:\dev2\cm3\m3-libs\m3core>cl -nologo -c nul.cnul.c
 
D:\dev2\cm3\m3-libs\m3core>cl -nologo -c nul.c nul.cnul.cnul.cGenerating Code...
I believe that suppressing this will suppress all other warning/error output.
See, they both go to stdout:
D:\dev2\cm3\m3-libs\m3core>echo error > foo.c
D:\dev2\cm3\m3-libs\m3core>cl -nologo -c foo.cfoo.cfoo.c(2) : fatal error C1004: unexpected end-of-file found
 
D:\dev2\cm3\m3-libs\m3core>cl -nologo -c foo.c >nul
 
D:\dev2\cm3\m3-libs\m3core>cl -nologo -c foo.c 2>nulfoo.cfoo.c(2) : fatal error C1004: unexpected end-of-file found
 
I tried something annoyingly expensive likecl -nologo -c foo.c | findstr /v /b /e foo.c 
 
which would only include lines that don't begin and end foo.c, but in normaluse, there are no such lines, there is just the one line, and so findstr fails, and so the overall command fails, not good.
 
You could do this:
 (echo. && cl -nologo -c foo.c)  | findstr /v /b /e foo.c 
Which nets you just a blank line output, but this seems to be heading to deep end, and even that blank line shouldn't be there.
Suggestions?
Maybe a change in cm3? Moving compile_c into it?My idea of moving Quake code into cm3 would be that cm3 has a definition of compile_c,but that if the user supplies compile_c, use that instead.
Doing that to solve just this is overkill, but it's not a bad idea anyway.
Smaller ideas could be considered, including:
1) Have all the compile_c implementations echo the source file, so they'd all have the same outputWhile is this is noisy in the user experience, there isn't much C.It does pollute all the platforms to cover up a small NT-specific problem.
2) What I suggested before, allow but to not encourage test cases to have per-platform results.This particular problem only affects test cases with C code, which is rare.There is one.
This would be very easy and solve the problem well.
It shouldn't be encouraged though, as it makes it more difficult to change the expected output of a test.
3) Currently if M3TESTS is defined, NT386.common redirects all C compiler output to nul.Good enough?
Related, in usage of GNU libtool, files are often compiled twice, once PIC, once not.The way it works, one invocation is directed to /dev/null, one is not.This would kinda sorta seem to set a precedent for redirecting C compiler output to /dev/null,except that they do run it both ways. It's not that errors are lost, just that they aren't doubled.
Also related, again, I suggest a log file.A detail hilighted here is that in fact ALL command would go to the log, and NONE would likelygo to stdout/stderr. Stdout/stderr would be strictly the domain of cm3.Perhaps cm3 could "sniff" for errors and pass them along, perhaps.
 
 
You know, really, the log file approach is already what is used for linking.
Why just linking? Why not everything run in the directory?
Ah, it looks like that isn't for all platforms though, just NT386.
 
I am half just making trouble here.
I think the logging should be more verbose, but even making it quiet is surprisingly difficult.
I guess the linking example shows the way though, I should just redirect C compiler output always to a file.
Maybe the same file as linking uses, maybe not.
The user experience in the face of error is, initially, badly degraded.
However there are ways to mitigate.
First, as with linking, upon error, we can tell the user about the file.
Second, upon error, we could just echo the file's contents to stdout.
It's just that for success, saying less is better.
 
I'll do that -- redirect to a file.
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Thu May  8 20:38:18 2008
From: jayk123 at hotmail.com (Jay)
Date: Thu, 8 May 2008 18:38:18 +0000
Subject: [M3devel] m3tests again
In-Reply-To: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
References: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
Message-ID: 

Olaf, sorry, not much here yet, except at least I do/did see problems where you see problems. Which ones are regressions?My numbers don't add up.I added one new failing test case, and I fixed one or two.
p116b floating pointp172  floating pointp185  floating point
--- p204 --- IP address initializers compiler crashes I think not new needs investigation
--- p206 --- ARRAY constructors in var decls using named open array types
 compiler gives reasonable error I think the compiler is correct. Updated expected outputs? Considering moving to category "e"?
 
--- p207 --- subrange declarations
 I think requires longint to really work. Disable for this platform?
--- p209 --- open array initializers compile failure
 compiler crashes (assertion failure) I think not new does need further investigation I changed the compiler to assert earlier for this
oh, also, I recently added this, knowing it doesn't pass yet
it is similar to p208 and/or p206.
 
--- p210 --- open array initializers runtime failure this is a new test I added I know it doesn't pass yet It shows a preexisting problem. And I messed up when I added it -- fixed now.
 
p209 and p210 are similar, but one fails an assertion in the compiler and one at runtime
--- r001 --- unhandled exception I believe this succeeds but possibly  the checking in the harness needs updated. I thought I had fixed it though. Darwin and FreeBSD need an update here though, simple.
--- e020 --- illegal recursive declaration builds and runs but is supposed to output a good error  and I think intead it infinitely recurses
--- e026 --- two types with the same brand I commited a fix in the compiler for this a few days ago.
 It was a simple error in yet another reinvention of linked lists.
--- e029 --- use type instead of value as an initializer fails assertion in compiler
 needs more investigation..
For most of these, I get no "@@" in the output,so maybe the test harness isn't working..But cd'ing around works.
sorry, I have to get going for nowmuch more hopefully later.
 - Jay


> Date: Tue, 6 May 2008 08:16:13 +0200> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: m3tests again> > Hi Jay,> > after several small fixes to the regression scripts, the nightrun> now shows for me> > >>> test_m3tests error extract:> >>> failed tests: p116b p172 p185 p204 p206 p207 p209 p210 r001 e020 > e026 e029> >>> 12 in test_m3tests 2008-05-06-01-30-23 > /home/wagner/work/cm3-ws/luthien-2008-05-06-01-30-23> > One week ago there were only 6. Could you have a closer look at this?> I'm still busy with other projects.> > 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 jayk123 at hotmail.com  Thu May  8 20:46:16 2008
From: jayk123 at hotmail.com (Jay)
Date: Thu, 8 May 2008 18:46:16 +0000
Subject: [M3devel] new NT386 snapshots
In-Reply-To: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
References: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
Message-ID: 

http://modula3.elegosoft.com/cm3/uploaded-archives/
 
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0.zip
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-WIN32-NT386-d5.7.0.zip
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0-symbols.zip
 
These should have:
  latest quake extensions 
  set relation fixes 
  other set fixes revealed through dynamic linking of one regression test 
  hypothetical ability to cross-build to AMD64_LINUX, AMD64_DARWIN  
  one jmpbuf size for all NT386 configurations (NT386, NT386GNU, NT386MINGNU) 
 
Built with Visual C++ 9.0 Express, so you'll want:
http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en
 
 
Still more work to do though, e.g. assertion failures in unit tests, pixmap..
 
Fuller disclosure:
Something is leaking memory on my system such that "everything" starts "failing" and I have to reboot.
This isn't Modula-3 related.
Hopefully these files aren't damaged as a result.
Must be some buggy driver or something..
 
Aside:
 The environment variable thingy has been bugging me a long time and I finally looked deeper at it.
It appears broken in CM3 4.x. I didn't check 3.x yet.
I'm still mulling a fix, and haven't run a repro of the break, but it's not a big deal either way.
Basically console apps use main that takes char** and gui apps use WinMain that doesn't get environment variables but the generated code calls GetEvironmentStrings() which returns null separated strings.
Must be that hardly anyone uses environment variables in Modula-3 on Win32 for this to have lingered so long, at least gui apps.
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Thu May  8 20:57:08 2008
From: jayk123 at hotmail.com (Jay)
Date: Thu, 8 May 2008 18:57:08 +0000
Subject: [M3devel] pixmap problem
In-Reply-To: <481F9804.1E75.00D7.1@scires.com>
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	 
	<481F9804.1E75.00D7.1@scires.com> 
Message-ID: 

Randy, At first very quick glance, this stuff looks ok.CM3-IDE probably doesn't really understand the config file, similar to m3cgcat's partial misunderstanding.
  (Which is why I keep TARGET declared in NT386* instead of just NT386.common.)
PKG_USE is defined I think, but it takes a really accurate understanding of Quake to get it.
 
The entry/subsystem stuff also seems complete but I didn't try examples yet.
Sorry, didn't give this all much time yet.
I did get me to look at the environment variable bug that's been sitting there forever, with a bogus fix..
 
Can CM3-IDE default PKG_USE to CM3_ROOT + "/pkg"? Or INSTALL_ROOT + "/pkg"? Or whatever?
That is what it always is, in anything that is checked in or that cminstall will give you.
It takes hand editing of cm3.cfg to get anything else I think.
 
Or CM3-IDE users can just edit the file some. Not a lot. But some.
Given an incomplete understanding of the config files, probably putting in CM3-IDE wants but under if FALSE will perhaps work.
Personally I wasn't impressed with Reactor... VC5 find-in-files gets me all I need. Anything besides plain text search doesn't scale..
 
 - Jay


From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problemDate: Tue, 6 May 2008 03:38:03 +0000


Randy, don't worry.Two of these problems are trivial to fix -- PKG_USE and popups.The pixmap one will need debugging.  - Jay


Date: Mon, 5 May 2008 23:28:10 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad news is that now I am getting a command window opening up in addition to the GUI window when the program runs.  This behavior does not occur on v4.1.  The command window seems to be the stdout/stderr of the GUI program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy>>> Jay  5/5/2008 10:47 PM >>>Randy, Yes.The NT386 config files are all checked in.You can use them verbatim. You don't need cminstall, I never use it, and you shouldn't need to edit the config files at all, any edits I make, I check in, and should be usable on all machines.As long as you set %PATH%/%INCLUDE%/%LIB%.If I'm wrong, I'd like to know why and try to fix. Consider the config files just part of cm3.exe.Not generally to be changed locally. Unless, well, unless you intend to, and you should strive to make one form that is usable by all.  - Jay


Date: Mon, 5 May 2008 22:42:30 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay,
When you say "took the updated config file", what do you mean?  Are you saying I need a different cm3.cfg file?
Regards,
Randy>>> Jay  5/5/2008 9:54 PM >>>And you took the updated config file?The way you can tell is that, roughly speaking, hand.obj should be in NT386\_m3responsefile0.txt.Or _m3responsefile1.txt, or, well, somewhere.Anyway, I think I saw the attachment, I can check later..and with 4.1 as I said.. I can see about making the fix not depend on config file changes...but it's not terrible asis, and I'd really like to merge more of the quake code into cm3.exe..  - Jay


Date: Mon, 5 May 2008 21:18:12 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem
Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly when the buildstandalone() directive is used.
 
Regards,
Randy>>> Jay  5/5/2008 7:04 PM >>>Thanks. I'll look into this tonight probably, as well as with 4.1 assuming I can find my binaries and source for it (probably).COULD BE the pixmap problem is something else and 4.1 also has the problem I fixed. We'll see. No need to speculate (unless I can't find my 4.1). - Jay


Date: Mon, 5 May 2008 10:59:27 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problem
Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy>>> Jay  5/4/2008 11:46 AM >>>Randy, Please try with /current/ source, as of this morning Sunday May 4 -- the changes are ALL in NT386.common, so you MUST use MY config files, which are checked in verbatim, or you should be able edit whatever config files you are using. (It's not really a config file issue, don't blame the general confusion people have with them.) I'll try to try later, but I don't have the source right now, gotta look on other machines, and I think it's on a machine on loan.  Or send it to me again.I'd also like to know if this worked with 4.1, or with any release that offered dynamic linking to m3core.dll, on Windows.  I recall a claim that it did. If today's change fixes it, I should be able to investigate 4.1.3.6 did not have such linking.If today's change does not help, well, I still plan on debugging it at some point.. If you aren't current and getting so is difficult, just send the attachment again, it's easy for me to test. Thanks, - Jay


From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rcoleburn at scires.comDate: Sat, 19 Jan 2008 08:52:08 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.I was going to try on PPC_DARWIN but I guess Tony's info suffices. I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. Debugging here is a big humungous pain.NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)And bundles look pretty simple, a bundle is just a generated source file with a constant in it.Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something. The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for? I have to say this is very surprising. I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so.The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: pointer to msvcrt!fopenpointer to msvcrt!fclosenullpointer to kernel32!Sleep But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo.But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo.That doesn't work for data though. There's no ability to intervenve like that.So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it.And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.However that would suck perf in order to make an uncommon case work.I hope Modula-3 doesn't do that either. :)Though I guess since this global data in question...maybe it is rare??? Later, - Jay

> From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 03:09:47 -0500> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] pixmap problem> > Looks fine to me on I386_DARWIN.> > On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:> > > > 

Need to know the score, the latest news, or you need your Hotmail?-get your "fix" Check it out. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Thu May  8 21:21:49 2008
From: jayk123 at hotmail.com (Jay)
Date: Thu, 8 May 2008 19:21:49 +0000
Subject: [M3devel] FW:  pixmap problem
In-Reply-To: <481F9804.1E75.00D7.1@scires.com>
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	 
	<481F9804.1E75.00D7.1@scires.com>  
Message-ID: 

truncated again...


From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problemDate: Thu, 8 May 2008 18:57:08 +0000


Randy, At first very quick glance, this stuff looks ok.CM3-IDE probably doesn't really understand the config file, similar to m3cgcat's partial misunderstanding.  (Which is why I keep TARGET declared in NT386* instead of just NT386.common.)PKG_USE is defined I think, but it takes a really accurate understanding of Quake to get it. The entry/subsystem stuff also seems complete but I didn't try examples yet.Sorry, didn't give this all much time yet.I did get me to look at the environment variable bug that's been sitting there forever, with a bogus fix.. Can CM3-IDE default PKG_USE to CM3_ROOT + "/pkg"? Or INSTALL_ROOT + "/pkg"? Or whatever?That is what it always is, in anything that is checked in or that cminstall will give you.It takes hand editing of cm3.cfg to get anything else I think. Or CM3-IDE users can just edit the file some. Not a lot. But some.Given an incomplete understanding of the config files, probably putting in CM3-IDE wants but under if FALSE will perhaps work.Personally I wasn't impressed with Reactor... VC5 find-in-files gets me all I need. Anything besides plain text search doesn't scale..  - Jay


From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problemDate: Tue, 6 May 2008 03:38:03 +0000

Randy, don't worry.Two of these problems are trivial to fix -- PKG_USE and popups.The pixmap one will need debugging.  - Jay


Date: Mon, 5 May 2008 23:28:10 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad news is that now I am getting a command window opening up in addition to the GUI window when the program runs.  This behavior does not occur on v4.1.  The command window seems to be the stdout/stderr of the GUI program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy>>> Jay  5/5/2008 10:47 PM >>>Randy, Yes.The NT386 config files are all checked in.You can use them verbatim. You don't need cminstall, I never use it, and you shouldn't need to edit the config files at all, any edits I make, I check in, and should be usable on all machines.As long as you set %PATH%/%INCLUDE%/%LIB%.If I'm wrong, I'd like to know why and try to fix. Consider the config files just part of cm3.exe.Not generally to be changed locally. Unless, well, unless you intend to, and you should strive to make one form that is usable by all.  - Jay


Date: Mon, 5 May 2008 22:42:30 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay,
When you say "took the updated config file", what do you mean?  Are you saying I need a different cm3.cfg file?
Regards,
Randy>>> Jay  5/5/2008 9:54 PM >>>And you took the updated config file?The way you can tell is that, roughly speaking, hand.obj should be in NT386\_m3responsefile0.txt.Or _m3responsefile1.txt, or, well, somewhere.Anyway, I think I saw the attachment, I can check later..and with 4.1 as I said.. I can see about making the fix not depend on config file changes...but it's not terrible asis, and I'd really like to merge more of the quake code into cm3.exe..  - Jay


Date: Mon, 5 May 2008 21:18:12 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem
Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly when the buildstandalone() directive is used.
 
Regards,
Randy>>> Jay  5/5/2008 7:04 PM >>>Thanks. I'll look into this tonight probably, as well as with 4.1 assuming I can find my binaries and source for it (probably).COULD BE the pixmap problem is something else and 4.1 also has the problem I fixed. We'll see. No need to speculate (unless I can't find my 4.1). - Jay


Date: Mon, 5 May 2008 10:59:27 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problem
Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy>>> Jay  5/4/2008 11:46 AM >>>Randy, Please try with /current/ source, as of this morning Sunday May 4 -- the changes are ALL in NT386.common, so you MUST use MY config files, which are checked in verbatim, or you should be able edit whatever config files you are using. (It's not really a config file issue, don't blame the general confusion people have with them.) I'll try to try later, but I don't have the source right now, gotta look on other machines, and I think it's on a machine on loan.  Or send it to me again.I'd also like to know if this worked with 4.1, or with any release that offered dynamic linking to m3core.dll, on Windows.  I recall a claim that it did. If today's change fixes it, I should be able to investigate 4.1.3.6 did not have such linking.If today's change does not help, well, I still plan on debugging it at some point.. If you aren't current and getting so is difficult, just send the attachment again, it's easy for me to test. Thanks, - Jay


From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rcoleburn at scires.comDate: Sat, 19 Jan 2008 08:52:08 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.I was going to try on PPC_DARWIN but I guess Tony's info suffices. I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. Debugging here is a big humungous pain.NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)And bundles look pretty simple, a bundle is just a generated source file with a constant in it.Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something. The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for? I have to say this is very surprising. I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so.The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: pointer to msvcrt!fopenpointer to msvcrt!fclosenullpointer to kernel32!Sleep But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo.But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo.That doesn't work for data though. There's no ability to intervenve like that.So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it.And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.However that would suck perf in order to make an uncommon case work.I hope Modula-3 doesn't do that either. :)Though I guess since this global data in question...maybe it is rare??? Later, - Jay

> From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 03:09:47 -0500> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] pixmap problem> > Looks fine to me on I386_DARWIN.> > On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:> > > > 

Need to know the score, the latest news, or you need your Hotmail?-get your "fix" Check it out. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Thu May  8 22:17:37 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Thu, 08 May 2008 16:17:37 -0400
Subject: [M3devel] new NT386 snapshots
In-Reply-To: 
References: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
	
Message-ID: <4823279D.1E75.00D7.1@scires.com>

Jay:
 
I have both console and gui programs built using 4.1 that do pull stuff out of the environment.  I've not noticed any problems with either mode.
 
>From my perspective, the old 4.1 seems more reliable than the current system in a number of respects.  I have a new project with a hard deadline that I would like to use the new cm3 system for, but until these problems (pixmaps, buildstandalone, environ vars, serial i/o, etc.) can be resolved, I'm going to keep using 4.1 for my production work.
 
Regards,
Randy

>>> Jay  5/8/2008 2:46 PM >>>
http://modula3.elegosoft.com/cm3/uploaded-archives/ 
 
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0.zip 
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-WIN32-NT386-d5.7.0.zip 
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0-symbols.zip 
 
These should have:
  latest quake extensions 
  set relation fixes 
  other set fixes revealed through dynamic linking of one regression test 
  hypothetical ability to cross-build to AMD64_LINUX, AMD64_DARWIN  
  one jmpbuf size for all NT386 configurations (NT386, NT386GNU, NT386MINGNU) 
 
Built with Visual C++ 9.0 Express, so you'll want:
http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en 
 
 
Still more work to do though, e.g. assertion failures in unit tests, pixmap..
 
Fuller disclosure:
Something is leaking memory on my system such that "everything" starts "failing" and I have to reboot.
This isn't Modula-3 related.
Hopefully these files aren't damaged as a result.
Must be some buggy driver or something..
 
Aside:
 The environment variable thingy has been bugging me a long time and I finally looked deeper at it.
It appears broken in CM3 4.x. I didn't check 3.x yet.
I'm still mulling a fix, and haven't run a repro of the break, but it's not a big deal either way.
Basically console apps use main that takes char** and gui apps use WinMain that doesn't get environment variables but the generated code calls GetEvironmentStrings() which returns null separated strings.
Must be that hardly anyone uses environment variables in Modula-3 on Win32 for this to have lingered so long, at least gui apps.
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Thu May  8 22:35:54 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Thu, 08 May 2008 16:35:54 -0400
Subject: [M3devel] FW:  pixmap problem
In-Reply-To: 
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	
	<481F9804.1E75.00D7.1@scires.com> <481F9804.1E75.00D7.1@scires.com>
	
Message-ID: <48232BE6.1E75.00D7.1@scires.com>

Jay:
 
I've made some changes to CM3IDE that seem to allow it to cope with
your new cm3.cfg file.  
 
[Aside:  I do not understand your insistence that we can no longer have
all of the variables defined that used to be there back in the 4.1 days.
 When you make these types of unilateral changes without making
provision for reliant code, you wind up breaking stuff that used to
work.]
 
Bottom line, I've got CM3IDE working now for me on WindowsXP using your
NT386/NT386.common for cm3.cfg.  Others will need to test on other
platforms once we get the final go-ahead to put the code in the
repository.
 
As for the difference in the console window startup for gui programs,
that will be real show-stopper for production code.  I can't deliver a
GUI program that is going to have a command shell window popped open for
stdout/stderr output.
 
The pixmap problem is another show-stopper for production code.
 
I can't use the new cm3 for production code until these major problems
are resolved.  Any help you can offer in resolving these is
appreciated.
 
[Aside:  What is the deal with your email program truncating your
messages?  This is very bothersome.]
 
Regards,
Randy

>>> Jay  5/8/2008 3:21 PM >>>
truncated again...




From: jayk123 at hotmail.com 
To: rcoleburn at scires.com; m3devel at elegosoft.com 
Subject: RE: [M3devel] pixmap problem
Date: Thu, 8 May 2008 18:57:08 +0000

Randy, At first very quick glance, this stuff looks ok.
CM3-IDE probably doesn't really understand the config file, similar to
m3cgcat's partial misunderstanding.
  (Which is why I keep TARGET declared in NT386* instead of just
NT386.common.)
PKG_USE is defined I think, but it takes a really accurate
understanding of Quake to get it.
 
The entry/subsystem stuff also seems complete but I didn't try examples
yet.
Sorry, didn't give this all much time yet.
I did get me to look at the environment variable bug that's been
sitting there forever, with a bogus fix..
 
Can CM3-IDE default PKG_USE to CM3_ROOT + "/pkg"? Or INSTALL_ROOT +
"/pkg"? Or whatever?
That is what it always is, in anything that is checked in or that
cminstall will give you.
It takes hand editing of cm3.cfg to get anything else I think.
 
Or CM3-IDE users can just edit the file some. Not a lot. But some.
Given an incomplete understanding of the config files, probably putting
in CM3-IDE wants but under if FALSE will perhaps work.
Personally I wasn't impressed with Reactor... VC5 find-in-files gets me
all I need. Anything besides plain text search doesn't scale..
 
 - Jay
From: jayk123 at hotmail.com 
To: rcoleburn at scires.com; m3devel at elegosoft.com 
Subject: RE: [M3devel] pixmap problem
Date: Tue, 6 May 2008 03:38:03 +0000

Randy, don't worry.
Two of these problems are trivial to fix -- PKG_USE and popups.
The pixmap one will need debugging.
 
 - Jay

Date: Mon, 5 May 2008 23:28:10 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com; jayk123 at hotmail.com 
Subject: RE: [M3devel] pixmap problem

Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've
copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad
news is that now I am getting a command window opening up in addition to
the GUI window when the program runs.  This behavior does not occur on
v4.1.  The command window seems to be the stdout/stderr of the GUI
program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which
needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy

>>> Jay  5/5/2008 10:47 PM >>>
Randy, Yes.
The NT386 config files are all checked in.
You can use them verbatim. You don't need cminstall, I never use it,
and you shouldn't need to edit the config files at all, any edits I
make, I check in, and should be usable on all machines.
As long as you set %PATH%/%INCLUDE%/%LIB%.
If I'm wrong, I'd like to know why and try to fix.
 
Consider the config files just part of cm3.exe.
Not generally to be changed locally. Unless, well, unless you intend
to, and you should strive to make one form that is usable by all.
 
 - Jay


Date: Mon, 5 May 2008 22:42:30 -0400
From: rcoleburn at scires.com 
To: jayk123 at hotmail.com 
Subject: RE: [M3devel] pixmap problem

Jay,
When you say "took the updated config file", what do you mean?  Are you
saying I need a different cm3.cfg file?
Regards,
Randy

>>> Jay  5/5/2008 9:54 PM >>>
And you took the updated config file?
The way you can tell is that, roughly speaking, hand.obj should be in
NT386\_m3responsefile0.txt.
Or _m3responsefile1.txt, or, well, somewhere.
Anyway, I think I saw the attachment, I can check later..and with 4.1
as I said..
 
I can see about making the fix not depend on config file changes...but
it's not terrible asis, and I'd really like to merge more of the quake
code into cm3.exe..
 
 - Jay

Date: Mon, 5 May 2008 21:18:12 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com 
Subject: Re: [M3devel] pixmap problem

Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly
when the buildstandalone() directive is used.
 
Regards,
Randy

>>> Jay  5/5/2008 7:04 PM >>>
Thanks. I'll look into this tonight probably, as well as with 4.1
assuming I can find my binaries and source for it (probably).

COULD BE the pixmap problem is something else and 4.1 also has the
problem I fixed. We'll see. No need to speculate (unless I can't find my
4.1).

 - Jay


Date: Mon, 5 May 2008 10:59:27 -0400
From: rcoleburn at scires.com 
To: jayk123 at hotmail.com 
CC: m3devel at elegosoft.com 
Subject: RE: [M3devel] pixmap problem

Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files
or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy

>>> Jay  5/4/2008 11:46 AM >>>
Randy, Please try with /current/ source, as of this morning Sunday May
4 -- the changes are ALL in NT386.common, so you MUST use MY config
files, which are checked in verbatim, or you should be able edit
whatever config files you are using.
 
(It's not really a config file issue, don't blame the general confusion
people have with them.)
 
I'll try to try later, but I don't have the source right now, gotta
look on other machines, and I think it's on a machine on loan.
  Or send it to me again.
I'd also like to know if this worked with 4.1, or with any release that
offered dynamic linking to m3core.dll, on Windows.
  I recall a claim that it did. If today's change fixes it, I should be
able to investigate 4.1.
3.6 did not have such linking.
If today's change does not help, well, I still plan on debugging it at
some point..
 
If you aren't current and getting so is difficult, just send the
attachment again, it's easy for me to test.
 
Thanks,
 - Jay

From: jayk123 at hotmail.com 
To: hosking at cs.purdue.edu; rcoleburn at scires.com 
Date: Sat, 19 Jan 2008 08:52:08 +0000
CC: m3devel at elegosoft.com 
Subject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.
I was going to try on PPC_DARWIN but I guess Tony's info suffices.
 
I tried rolling hand.c back to before I changed (months/year ago),
since it is involved in bit twiddling, no change, phew.
 
Debugging here is a big humungous pain.
NT386 has good stacks and line numbers, but no locals or type info, I'd
really sometime like to get Codeview info into those .objs...I think it
is documented well enough, but still not necessarily easy, or maybe have
a C generating backend partly for this reason (and to bring up more
targets, using native tools), and function calls in disassembly I think
don't resolve; NT386GNU can't yet build this, though it will soon, but
I'm not familiar with gdb and there appears to be no type info. I'm
building m3gdb right now, I don't know if it will work, I hope it has
type info, and I'm not familiar with the relevant code. In gdb I
struggle just to view bytes in memory, add numbers to addresses and see
those, etc. I think for MY problem, I'm going to link in C code to dump
the structs. There is tracing code and I enabled it, but even it crashes
in Text_Length. At least MY problem crashes, hopefully near the problem,
whereas your problem goes all the way through to completion with no
stopping to hint where the problem is. Darn it. :) on the mock rudeness
and :( on the lack of a crash.
 
You write the bundle out and it matches, so that doesn't rule out
bundles as being the problem? (darn)
And bundles look pretty simple, a bundle is just a generated source
file with a constant in it.
Maybe newline problems? That wouldn't make sense. I just downloaded
some program that might let me separately view the ppm, maybe it'll
reveal something.
 
The bad behavior has like regularly spaced solid color veritical bars a
few pixels side across the whole picture, and regularly spaced vertical
stripes from the correct picture alternating with that. Perhaps someone
with ppm/bitmap/graphics experience has seen this behavior and it
results from some common pixmap mismanagement we could look for?
 
I have to say this is very surprising.
 
I always wondered, and now I pretty much assume -- Modula-3 never
imports/exports data in its dynamic linking, right? It alway
imports/exports functions, right?
On Windows, functions have an optional optimization, but data must be
handled differently at compile time if it is going to be dynamically
imported.
For functions, if you don't apply the optimization at compile time, the
linker will just generate a single instruction thunk instead.
 
That is, given a symbol Foo, there is a symbol __imp__Foo that is a
pointer to the actual foo in another .dll/.so.
The loader only patches pointers, one per import if you build your .dll
correctly, it doesn't patch instructions or code strewn throughout a
.dll, just one contiguous array of pointers. MAYBE they don't have to be
contiguous for each .dl you import from.
 
That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my
.dll/.exe typically has an array:
 
pointer to msvcrt!fopen
pointer to msvcrt!fclose
null
pointer to kernel32!Sleep
 
But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not
be adjacent.
 
So, going back, my point/question is that, if the compiler knows the
function is imported, it can call through __imp__Foo instead of calling
Foo.
But if it calls Foo and you import Foo, the linker will create the
function Foo that just jmps through __imp__Foo.
That doesn't work for data though. There's no ability to intervenve
like that.
So for imported data, the compiler must generated a read and
dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to
be imported.
Data imports may be faster when appropriate, but for this reason, I'd
say they aren't worth it.
And for this reason, I HOPE Modula-3 never imports/exports data.
 
Oh, you could, for data, always reference the pointer __imp_Foo, and if
non materializes, create one.
However that would suck perf in order to make an uncommon case work.
I hope Modula-3 doesn't do that either. :)
Though I guess since this global data in question...maybe it is
rare???
 
Later,
 - Jay



> From: hosking at cs.purdue.edu 
> Date: Sat, 19 Jan 2008 03:09:47 -0500
> To: rcoleburn at scires.com 
> CC: m3devel at elegosoft.com 
> Subject: Re: [M3devel] pixmap problem
> 
> Looks fine to me on I386_DARWIN.
> 
> On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:
> 
> > 
> 


Need to know the score, the latest news, or you need your Hotmail*-get
your "fix" Check it out. ( http://www.msnmobilefix.com/Default.aspx ) 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Thu May  8 23:05:15 2008
From: jayk123 at hotmail.com (Jay)
Date: Thu, 8 May 2008 21:05:15 +0000
Subject: [M3devel] FW:  pixmap problem
In-Reply-To: <48232BE6.1E75.00D7.1@scires.com>
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	
	<481F9804.1E75.00D7.1@scires.com> <481F9804.1E75.00D7.1@scires.com>
	 
	<48232BE6.1E75.00D7.1@scires.com>
Message-ID: 

Randy, I don't insist on not having it -- it is in fact there. CM3IDE may have its own parser for quake files such that it doesn't understand it, but it is there. But indeed, variables that are either unused or almost never used, shouldn't stick around. Things get crufty when there is too much "just in case". Things get hard to change when some things depend on too many imlementation details.The gui problem is simple no matter what. There's just not much there. I'll look later.
 - Jay


Date: Thu, 8 May 2008 16:35:54 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] FW: pixmap problem

Jay:
 
I've made some changes to CM3IDE that seem to allow it to cope with your new cm3.cfg file.  
 
[Aside:  I do not understand your insistence that we can no longer have all of the variables defined that used to be there back in the 4.1 days.  When you make these types of unilateral changes without making provision for reliant code, you wind up breaking stuff that used to work.]
 
Bottom line, I've got CM3IDE working now for me on WindowsXP using your NT386/NT386.common for cm3.cfg.  Others will need to test on other platforms once we get the final go-ahead to put the code in the repository.
 
As for the difference in the console window startup for gui programs, that will be real show-stopper for production code.  I can't deliver a GUI program that is going to have a command shell window popped open for stdout/stderr output.
 
The pixmap problem is another show-stopper for production code.
 
I can't use the new cm3 for production code until these major problems are resolved.  Any help you can offer in resolving these is appreciated.
 
[Aside:  What is the deal with your email program truncating your messages?  This is very bothersome.]
 
Regards,
Randy>>> Jay  5/8/2008 3:21 PM >>>truncated again...


From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problemDate: Thu, 8 May 2008 18:57:08 +0000

Randy, At first very quick glance, this stuff looks ok.CM3-IDE probably doesn't really understand the config file, similar to m3cgcat's partial misunderstanding.  (Which is why I keep TARGET declared in NT386* instead of just NT386.common.)PKG_USE is defined I think, but it takes a really accurate understanding of Quake to get it. The entry/subsystem stuff also seems complete but I didn't try examples yet.Sorry, didn't give this all much time yet.I did get me to look at the environment variable bug that's been sitting there forever, with a bogus fix.. Can CM3-IDE default PKG_USE to CM3_ROOT + "/pkg"? Or INSTALL_ROOT + "/pkg"? Or whatever?That is what it always is, in anything that is checked in or that cminstall will give you.It takes hand editing of cm3.cfg to get anything else I think. Or CM3-IDE users can just edit the file some. Not a lot. But some.Given an incomplete understanding of the config files, probably putting in CM3-IDE wants but under if FALSE will perhaps work.Personally I wasn't impressed with Reactor... VC5 find-in-files gets me all I need. Anything besides plain text search doesn't scale..  - Jay


From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problemDate: Tue, 6 May 2008 03:38:03 +0000

Randy, don't worry.Two of these problems are trivial to fix -- PKG_USE and popups.The pixmap one will need debugging.  - Jay


Date: Mon, 5 May 2008 23:28:10 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad news is that now I am getting a command window opening up in addition to the GUI window when the program runs.  This behavior does not occur on v4.1.  The command window seems to be the stdout/stderr of the GUI program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy>>> Jay  5/5/2008 10:47 PM >>>Randy, Yes.The NT386 config files are all checked in.You can use them verbatim. You don't need cminstall, I never use it, and you shouldn't need to edit the config files at all, any edits I make, I check in, and should be usable on all machines.As long as you set %PATH%/%INCLUDE%/%LIB%.If I'm wrong, I'd like to know why and try to fix. Consider the config files just part of cm3.exe.Not generally to be changed locally. Unless, well, unless you intend to, and you should strive to make one form that is usable by all.  - Jay


Date: Mon, 5 May 2008 22:42:30 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay,
When you say "took the updated config file", what do you mean?  Are you saying I need a different cm3.cfg file?
Regards,
Randy>>> Jay  5/5/2008 9:54 PM >>>And you took the updated config file?The way you can tell is that, roughly speaking, hand.obj should be in NT386\_m3responsefile0.txt.Or _m3responsefile1.txt, or, well, somewhere.Anyway, I think I saw the attachment, I can check later..and with 4.1 as I said.. I can see about making the fix not depend on config file changes...but it's not terrible asis, and I'd really like to merge more of the quake code into cm3.exe..  - Jay


Date: Mon, 5 May 2008 21:18:12 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem
Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly when the buildstandalone() directive is used.
 
Regards,
Randy>>> Jay  5/5/2008 7:04 PM >>>Thanks. I'll look into this tonight probably, as well as with 4.1 assuming I can find my binaries and source for it (probably).COULD BE the pixmap problem is something else and 4.1 also has the problem I fixed. We'll see. No need to speculate (unless I can't find my 4.1). - Jay


Date: Mon, 5 May 2008 10:59:27 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problem
Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy>>> Jay  5/4/2008 11:46 AM >>>Randy, Please try with /current/ source, as of this morning Sunday May 4 -- the changes are ALL in NT386.common, so you MUST use MY config files, which are checked in verbatim, or you should be able edit whatever config files you are using. (It's not really a config file issue, don't blame the general confusion people have with them.) I'll try to try later, but I don't have the source right now, gotta look on other machines, and I think it's on a machine on loan.  Or send it to me again.I'd also like to know if this worked with 4.1, or with any release that offered dynamic linking to m3core.dll, on Windows.  I recall a claim that it did. If today's change fixes it, I should be able to investigate 4.1.3.6 did not have such linking.If today's change does not help, well, I still plan on debugging it at some point.. If you aren't current and getting so is difficult, just send the attachment again, it's easy for me to test. Thanks, - Jay


From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rcoleburn at scires.comDate: Sat, 19 Jan 2008 08:52:08 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.I was going to try on PPC_DARWIN but I guess Tony's info suffices. I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. Debugging here is a big humungous pain.NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)And bundles look pretty simple, a bundle is just a generated source file with a constant in it.Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something. The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for? I have to say this is very surprising. I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so.The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: pointer to msvcrt!fopenpointer to msvcrt!fclosenullpointer to kernel32!Sleep But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo.But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo.That doesn't work for data though. There's no ability to intervenve like that.So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it.And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.However that would suck perf in order to make an uncommon case work.I hope Modula-3 doesn't do that either. :)Though I guess since this global data in question...maybe it is rare??? Later, - Jay

> From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 03:09:47 -0500> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] pixmap problem> > Looks fine to me on I386_DARWIN.> > On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:> > > > 

Need to know the score, the latest news, or you need your Hotmail?-get your "fix" Check it out. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Thu May  8 23:18:04 2008
From: jayk123 at hotmail.com (Jay)
Date: Thu, 8 May 2008 21:18:04 +0000
Subject: [M3devel] new NT386 snapshots
In-Reply-To: <4823279D.1E75.00D7.1@scires.com>
References: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
	 
	<4823279D.1E75.00D7.1@scires.com>
Message-ID: 

The code in 4.1 in clearly, by inspection, incorrect. I'll have to test it out and debug it though. Inspection isn't enough.I have no idea why my mail gets truncated. I agree it is annoying.
 
F:\products\modula3\CONTRIB\SRC-M3\m3\m3core\src\runtime\WIN32\RTArgs.m3(7):(* In Windows/NT, "envp" points at a null-terminated block ofF:\products\modula3\CONTRIB\SRC-M3\m3\m3core\src\runtime\WIN32\RTArgs.m3(144):    envp : Ctypes.char_star := RTLinker.info.envp;
f:\products\modula3\CONTRIB\SRC-M3\m3\m3linker\src\MxGen.m3(117):    Out (s, "  _ADDRESS envp;", s.eol);f:\products\modula3\CONTRIB\SRC-M3\m3\m3linker\src\MxGen.m3(480):    Out (s, "  /* envp       */ 0,", s.eol);f:\products\modula3\CONTRIB\SRC-M3\m3\m3linker\src\MxGen.m3(498):      Out (s, "    _m3_link_info.envp = (_ADDRESS)GetEnvironmentStrings();", s.eol);f:\products\modula3\CONTRIB\SRC-M3\m3\m3linker\src\MxGen.m3(501):      Out (s, "int main (argc, argv, envp)", s.eol);f:\products\modula3\CONTRIB\SRC-M3\m3\m3linker\src\MxGen.m3(504):      Out (s, "char **envp;", s.eol);f:\products\modula3\CONTRIB\SRC-M3\m3\m3linker\src\MxGen.m3(512):      Out (s, "    _m3_link_info.envp = (_ADDRESS)(envp);", s.eol); > serial i/o?
 
I haven't touched it, looked it really, or heard of any problems.
I looked at it for purposes of NT386GNU but didn't really do anything.
 
Pixmaps need debugging, indeed.
 
I found my 4.1 CD. :)
 
- Jay


Date: Thu, 8 May 2008 16:17:37 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] new NT386 snapshots

Jay:
 
I have both console and gui programs built using 4.1 that do pull stuff out of the environment.  I've not noticed any problems with either mode.
 
>From my perspective, the old 4.1 seems more reliable than the current system in a number of respects.  I have a new project with a hard deadline that I would like to use the new cm3 system for, but until these problems (pixmaps, buildstandalone, environ vars, serial i/o, etc.) can be resolved, I'm going to keep using 4.1 for my production work.
 
Regards,
Randy>>> Jay  5/8/2008 2:46 PM >>>http://modula3.elegosoft.com/cm3/uploaded-archives/ http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0.ziphttp://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-WIN32-NT386-d5.7.0.ziphttp://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0-symbols.zip These should have:  latest quake extensions   set relation fixes   other set fixes revealed through dynamic linking of one regression test   hypothetical ability to cross-build to AMD64_LINUX, AMD64_DARWIN    one jmpbuf size for all NT386 configurations (NT386, NT386GNU, NT386MINGNU)  Built with Visual C++ 9.0 Express, so you'll want:http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en  Still more work to do though, e.g. assertion failures in unit tests, pixmap.. Fuller disclosure:Something is leaking memory on my system such that "everything" starts "failing" and I have to reboot.This isn't Modula-3 related.Hopefully these files aren't damaged as a result.Must be some buggy driver or something.. Aside: The environment variable thingy has been bugging me a long time and I finally looked deeper at it.It appears broken in CM3 4.x. I didn't check 3.x yet.I'm still mulling a fix, and haven't run a repro of the break, but it's not a big deal either way.Basically console apps use main that takes char** and gui apps use WinMain that doesn't get environment variables but the generated code calls GetEvironmentStrings() which returns null separated strings.Must be that hardly anyone uses environment variables in Modula-3 on Win32 for this to have lingered so long, at least gui apps.  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Thu May  8 23:53:26 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Thu, 08 May 2008 17:53:26 -0400
Subject: [M3devel] new NT386 snapshots
In-Reply-To: 
References: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
	
	<4823279D.1E75.00D7.1@scires.com>
	
Message-ID: <48233E12.1E75.00D7.1@scires.com>

Jay:
 
I have a working serial-I/O module for Windows and one for HPUX, so maybe I should compare it to what is out there now and make some fixes.
 
Regards,
Randy

>>> Jay  5/8/2008 5:18 PM >>>
The code in 4.1 in clearly, by inspection, incorrect. I'll have to test it out and debug it though. Inspection isn't enough.
I have no idea why my mail gets truncated. I agree it is annoying.
 
F:\products\modula3\CONTRIB\SRC-M3\m3\m3core\src\runtime\WIN32\RTArgs.m3(7):(* In Windows/NT, "envp" points at a null-terminated block of
F:\products\modula3\CONTRIB\SRC-M3\m3\m3core\src\runtime\WIN32\RTArgs.m3(144):    envp : Ctypes.char_star := RTLinker.info.envp;


f:\products\modula3\CONTRIB\SRC-M3\m3\m3linker\src\MxGen.m3(117):    Out (s, "  _ADDRESS envp;", s.eol);
f:\products\modula3\CONTRIB\SRC-M3\m3\m3linker\src\MxGen.m3(480):    Out (s, "  /* envp       */ 0,", s.eol);
f:\products\modula3\CONTRIB\SRC-M3\m3\m3linker\src\MxGen.m3(498):      Out (s, "    _m3_link_info.envp = (_ADDRESS)GetEnvironmentStrings();", s.eol);
f:\products\modula3\CONTRIB\SRC-M3\m3\m3linker\src\MxGen.m3(501):      Out (s, "int main (argc, argv, envp)", s.eol);
f:\products\modula3\CONTRIB\SRC-M3\m3\m3linker\src\MxGen.m3(504):      Out (s, "char **envp;", s.eol);
f:\products\modula3\CONTRIB\SRC-M3\m3\m3linker\src\MxGen.m3(512):      Out (s, "    _m3_link_info.envp = (_ADDRESS)(envp);", s.eol);

 > serial i/o?
 
I haven't touched it, looked it really, or heard of any problems.
I looked at it for purposes of NT386GNU but didn't really do anything.
 
Pixmaps need debugging, indeed.
 
I found my 4.1 CD. :)
 
- Jay

Date: Thu, 8 May 2008 16:17:37 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com 
Subject: Re: [M3devel] new NT386 snapshots

Jay:
 
I have both console and gui programs built using 4.1 that do pull stuff out of the environment.  I've not noticed any problems with either mode.
 
>From my perspective, the old 4.1 seems more reliable than the current system in a number of respects.  I have a new project with a hard deadline that I would like to use the new cm3 system for, but until these problems (pixmaps, buildstandalone, environ vars, serial i/o, etc.) can be resolved, I'm going to keep using 4.1 for my production work.
 
Regards,
Randy

>>> Jay  5/8/2008 2:46 PM >>>
http://modula3.elegosoft.com/cm3/uploaded-archives/ 
 
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0.zip 
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-WIN32-NT386-d5.7.0.zip 
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0-symbols.zip 
 
These should have:
  latest quake extensions 
  set relation fixes 
  other set fixes revealed through dynamic linking of one regression test 
  hypothetical ability to cross-build to AMD64_LINUX, AMD64_DARWIN  
  one jmpbuf size for all NT386 configurations (NT386, NT386GNU, NT386MINGNU) 
 
Built with Visual C++ 9.0 Express, so you'll want:
http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en 
 
 
Still more work to do though, e.g. assertion failures in unit tests, pixmap..
 
Fuller disclosure:
Something is leaking memory on my system such that "everything" starts "failing" and I have to reboot.
This isn't Modula-3 related.
Hopefully these files aren't damaged as a result.
Must be some buggy driver or something..
 
Aside:
 The environment variable thingy has been bugging me a long time and I finally looked deeper at it.
It appears broken in CM3 4.x. I didn't check 3.x yet.
I'm still mulling a fix, and haven't run a repro of the break, but it's not a big deal either way.
Basically console apps use main that takes char** and gui apps use WinMain that doesn't get environment variables but the generated code calls GetEvironmentStrings() which returns null separated strings.
Must be that hardly anyone uses environment variables in Modula-3 on Win32 for this to have lingered so long, at least gui apps.
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Fri May  9 07:43:08 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 9 May 2008 05:43:08 +0000
Subject: [M3devel] consoles appearing in gui apps (was pixmap...)
In-Reply-To: <481F9804.1E75.00D7.1@scires.com>
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	 
	<481F9804.1E75.00D7.1@scires.com>   
Message-ID: 

  > The bad news is that now I am getting a command window
  > opening up in addition to the GUI window when the program runs. 
  > This behavior does not occur on v4.1.  
 
Randy I've experimented with -gui. Just a few minutes, but I've covered all of the ground I can think of, except I only used -gui and not an m3makefile.
>From what I see, it all works as it should.
 
Here is my little program:
 
C:\dev2\j\m3\3>type Main.m3MODULE Main;IMPORT IO;IMPORT WinBase;
BEGIN  (* IO.Put("Hello\n"); *)  WinBase.Sleep(10000); (* 10 seconds *)
IF I uncomment out the IO.Put, and use -gui, then there is a "popup", and hello is printed there.
If I don't have the IO.Put however, no popup.
 
Is anything appearing in your console window? Or it is just empty?
Are you maybe running processes from your app? Or running them from Explorer?
I am running just one Modula-3 test app, from cmd.
 
It is possible that 4.1 does not bring up a console if you use stdout/stderr?
There is specific code in the current code to do this.
I don't have 4.1 handy..ok, I have 3.6.
 
This appears to have been a deliberate change.
 
 3.6
C:\net\modula3\m3\libm3\src\os\WIN32\ProcessWin32.m3(185):PROCEDURE GetFileHandle(hd: WinDef.DWORD; ds: FileWin32.DirectionSet): File.T =
PROCEDURE GetFileHandle(hd: WinDef.DWORD; ds: FileWin32.DirectionSet): File.T =  VAR h := WinBase.GetStdHandle(hd);  BEGIN    IF (h = NIL)      OR (h = LOOPHOLE (WinBase.INVALID_HANDLE_VALUE, WinDef.HANDLE)) THEN      RETURN NIL;    END;    TRY RETURN FileWin32.New(h, ds)    EXCEPT OSError.E => (* not available *)    END;    RETURN NIL;  END GetFileHandle;
 
vs.
 
current
 
C:\dev2\cm3\m3-libs\libm3\src\os\WIN32\ProcessWin32.m3(231):PROCEDURE GetFileHandle(hd: WinDef.DWORD; ds: FileWin32.DirectionSet): File.T =
PROCEDURE GetFileHandle(hd: WinDef.DWORD; ds: FileWin32.DirectionSet): File.T =  VAR h := WinBase.GetStdHandle(hd);  BEGIN    IF (h # NIL)      AND (h # LOOPHOLE (WinBase.INVALID_HANDLE_VALUE, WinDef.HANDLE)) THEN      TRY RETURN FileWin32.New(h, ds)      EXCEPT OSError.E => (* not available *)      END;    END;    (* if we can't get the standard handles, we might be a GUI program       so we'll lazily allocate a console if needed. *)    RETURN LazyConsole.New (hd, ds);  END GetFileHandle;
 
 
Ok, this change came in in the upgrade from Critical Mass 4.1 to 5.1.
4.1 being as I understand the actual one and only commercial release.
5.1 I guess being the then current but unreleated Critical Mass tree.
 
http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/WIN32/ProcessWin32.m3.diff?r1=1.1.1.1;r2=1.1.1.2;f=u
 
Please advise.
 
Also, to double check that things are working, run link -dump -headers foo.exe | findstr /i "subsystem entry"
 
GUI apps should show:
 
C:\dev2\j\m3\3>link -dump -headers NT386\prog.exe | findstr /i "subsystem entry"
            1C60 entry point (00401C60) _WinMainCRTStartup               2 subsystem (Windows GUI)
 
console apps should show:
 
C:\dev2\j\m3\3>link -dump -headers NT386\prog.exe | findstr /i "subsystem entry"
            1BE1 entry point (00401BE1) _mainCRTStartup               3 subsystem (Windows CUI)
C for console/commandline, G for gui/graphical.
 
If that is not what you are seeing, let's delve into that.
If my test program always brings up a popup, when compiled with -gui, with the IO.Put commented out, let's delve into that.
If your console is empty, let's look into that.
If you console has output in it, well, I'm inclined to say you are seeing improved correct behavior, but we can debate it, I guess.
 
 - Jay


From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: FW: [M3devel] pixmap problemDate: Thu, 8 May 2008 19:21:49 +0000


truncated again...


From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problemDate: Thu, 8 May 2008 18:57:08 +0000

Randy, At first very quick glance, this stuff looks ok.CM3-IDE probably doesn't really understand the config file, similar to m3cgcat's partial misunderstanding.  (Which is why I keep TARGET declared in NT386* instead of just NT386.common.)PKG_USE is defined I think, but it takes a really accurate understanding of Quake to get it. The entry/subsystem stuff also seems complete but I didn't try examples yet.Sorry, didn't give this all much time yet.I did get me to look at the environment variable bug that's been sitting there forever, with a bogus fix.. Can CM3-IDE default PKG_USE to CM3_ROOT + "/pkg"? Or INSTALL_ROOT + "/pkg"? Or whatever?That is what it always is, in anything that is checked in or that cminstall will give you.It takes hand editing of cm3.cfg to get anything else I think. Or CM3-IDE users can just edit the file some. Not a lot. But some.Given an incomplete understanding of the config files, probably putting in CM3-IDE wants but under if FALSE will perhaps work.Personally I wasn't impressed with Reactor... VC5 find-in-files gets me all I need. Anything besides plain text search doesn't scale..  - Jay


From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problemDate: Tue, 6 May 2008 03:38:03 +0000

Randy, don't worry.Two of these problems are trivial to fix -- PKG_USE and popups.The pixmap one will need debugging.  - Jay


Date: Mon, 5 May 2008 23:28:10 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad news is that now I am getting a command window opening up in addition to the GUI window when the program runs.  This behavior does not occur on v4.1.  The command window seems to be the stdout/stderr of the GUI program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy>>> Jay  5/5/2008 10:47 PM >>>Randy, Yes.The NT386 config files are all checked in.You can use them verbatim. You don't need cminstall, I never use it, and you shouldn't need to edit the config files at all, any edits I make, I check in, and should be usable on all machines.As long as you set %PATH%/%INCLUDE%/%LIB%.If I'm wrong, I'd like to know why and try to fix. Consider the config files just part of cm3.exe.Not generally to be changed locally. Unless, well, unless you intend to, and you should strive to make one form that is usable by all.  - Jay


Date: Mon, 5 May 2008 22:42:30 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay,
When you say "took the updated config file", what do you mean?  Are you saying I need a different cm3.cfg file?
Regards,
Randy>>> Jay  5/5/2008 9:54 PM >>>And you took the updated config file?The way you can tell is that, roughly speaking, hand.obj should be in NT386\_m3responsefile0.txt.Or _m3responsefile1.txt, or, well, somewhere.Anyway, I think I saw the attachment, I can check later..and with 4.1 as I said.. I can see about making the fix not depend on config file changes...but it's not terrible asis, and I'd really like to merge more of the quake code into cm3.exe..  - Jay


Date: Mon, 5 May 2008 21:18:12 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem
Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly when the buildstandalone() directive is used.
 
Regards,
Randy>>> Jay  5/5/2008 7:04 PM >>>Thanks. I'll look into this tonight probably, as well as with 4.1 assuming I can find my binaries and source for it (probably).COULD BE the pixmap problem is something else and 4.1 also has the problem I fixed. We'll see. No need to speculate (unless I can't find my 4.1). - Jay


Date: Mon, 5 May 2008 10:59:27 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problem
Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy>>> Jay  5/4/2008 11:46 AM >>>Randy, Please try with /current/ source, as of this morning Sunday May 4 -- the changes are ALL in NT386.common, so you MUST use MY config files, which are checked in verbatim, or you should be able edit whatever config files you are using. (It's not really a config file issue, don't blame the general confusion people have with them.) I'll try to try later, but I don't have the source right now, gotta look on other machines, and I think it's on a machine on loan.  Or send it to me again.I'd also like to know if this worked with 4.1, or with any release that offered dynamic linking to m3core.dll, on Windows.  I recall a claim that it did. If today's change fixes it, I should be able to investigate 4.1.3.6 did not have such linking.If today's change does not help, well, I still plan on debugging it at some point.. If you aren't current and getting so is difficult, just send the attachment again, it's easy for me to test. Thanks, - Jay


From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rcoleburn at scires.comDate: Sat, 19 Jan 2008 08:52:08 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.I was going to try on PPC_DARWIN but I guess Tony's info suffices. I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. Debugging here is a big humungous pain.NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)And bundles look pretty simple, a bundle is just a generated source file with a constant in it.Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something. The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for? I have to say this is very surprising. I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so.The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: pointer to msvcrt!fopenpointer to msvcrt!fclosenullpointer to kernel32!Sleep But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo.But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo.That doesn't work for data though. There's no ability to intervenve like that.So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it.And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.However that would suck perf in order to make an uncommon case work.I hope Modula-3 doesn't do that either. :)Though I guess since this global data in question...maybe it is rare??? Later, - Jay

> From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 03:09:47 -0500> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] pixmap problem> > Looks fine to me on I386_DARWIN.> > On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:> > > > 

Need to know the score, the latest news, or you need your Hotmail?-get your "fix" Check it out. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Fri May  9 09:44:09 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 9 May 2008 07:44:09 +0000
Subject: [M3devel] NT386 environment variables (new NT386 snapshots)
In-Reply-To: <4823279D.1E75.00D7.1@scires.com>
References: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
	 
	<4823279D.1E75.00D7.1@scires.com>
Message-ID: 

 > these problems (pixmaps, buildstandalone, environ vars, serial i/o, etc...
 
 Ok, here is the story with environment variables.
I tested 3.6 and current, gui and console.
This is the program:
C:\dev2\j\m3\3>type src\m3makefile
import ("m3core")import ("libm3")m3_option ("-gui")     twiddle this line in and out with a commentimplementation ("Main")program ("pgm")
 
C:\dev2\j\m3\3>type src\Main.m3
MODULE Main;IMPORT IO;IMPORT RTArgs;
 
BEGIN
(* IO.Put just crashes in 3.6 gui apps *)  IO.Put(RTArgs.GetArg(2));  IO.Put(RTArgs.GetEnv(2));
 
(* use this for gui apps *)  EVAL RTArgs.GetArg(2);  EVAL RTArgs.GetEnv(2);END Main.
In 3.6 console apps, RTArgs.GetEnv returns garbage. That makes sense from the code.
In current console apps, GetEnv works.In current gui apps, GetEnv access violates, or returns an invalid pointer.  This also makes sense from the code.
Randy, does this actually work for you?I'd be quite surprised.I haven't tried 4.1 yet, just 3.6 and current.
I will apply an easy fix.
 - Jay


Date: Thu, 8 May 2008 16:17:37 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] new NT386 snapshots

Jay:
 
I have both console and gui programs built using 4.1 that do pull stuff out of the environment.  I've not noticed any problems with either mode.
 
>From my perspective, the old 4.1 seems more reliable than the current system in a number of respects.  I have a new project with a hard deadline that I would like to use the new cm3 system for, but until these problems (pixmaps, buildstandalone, environ vars, serial i/o, etc.) can be resolved, I'm going to keep using 4.1 for my production work.
 
Regards,
Randy>>> Jay  5/8/2008 2:46 PM >>>http://modula3.elegosoft.com/cm3/uploaded-archives/ http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0.ziphttp://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-WIN32-NT386-d5.7.0.ziphttp://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0-symbols.zip These should have:  latest quake extensions   set relation fixes   other set fixes revealed through dynamic linking of one regression test   hypothetical ability to cross-build to AMD64_LINUX, AMD64_DARWIN    one jmpbuf size for all NT386 configurations (NT386, NT386GNU, NT386MINGNU)  Built with Visual C++ 9.0 Express, so you'll want:http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en  Still more work to do though, e.g. assertion failures in unit tests, pixmap.. Fuller disclosure:Something is leaking memory on my system such that "everything" starts "failing" and I have to reboot.This isn't Modula-3 related.Hopefully these files aren't damaged as a result.Must be some buggy driver or something.. Aside: The environment variable thingy has been bugging me a long time and I finally looked deeper at it.It appears broken in CM3 4.x. I didn't check 3.x yet.I'm still mulling a fix, and haven't run a repro of the break, but it's not a big deal either way.Basically console apps use main that takes char** and gui apps use WinMain that doesn't get environment variables but the generated code calls GetEvironmentStrings() which returns null separated strings.Must be that hardly anyone uses environment variables in Modula-3 on Win32 for this to have lingered so long, at least gui apps.  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Fri May  9 10:19:33 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 9 May 2008 08:19:33 +0000
Subject: [M3devel] FW:  NT386 environment variables (new NT386 snapshots)
In-Reply-To: <4823279D.1E75.00D7.1@scires.com>
References: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
	 
	<4823279D.1E75.00D7.1@scires.com> 
Message-ID: 

truncated again...
m3support -- nothing interesting in any logs regarding my mail?
And nobody else uses hotmail, right?
 
> I will apply an easy fix.
done


From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] NT386 environment variables (new NT386 snapshots)Date: Fri, 9 May 2008 07:44:09 +0000


 > these problems (pixmaps, buildstandalone, environ vars, serial i/o, etc...  Ok, here is the story with environment variables.I tested 3.6 and current, gui and console.This is the program:C:\dev2\j\m3\3>type src\m3makefileimport ("m3core")import ("libm3")m3_option ("-gui")     twiddle this line in and out with a commentimplementation ("Main")program ("pgm") C:\dev2\j\m3\3>type src\Main.m3MODULE Main;IMPORT IO;IMPORT RTArgs; BEGIN(* IO.Put just crashes in 3.6 gui apps *)  IO.Put(RTArgs.GetArg(2));  IO.Put(RTArgs.GetEnv(2)); (* use this for gui apps *)  EVAL RTArgs.GetArg(2);  EVAL RTArgs.GetEnv(2);END Main.In 3.6 console apps, RTArgs.GetEnv returns garbage. That makes sense from the code.In current console apps, GetEnv works.In current gui apps, GetEnv access violates, or returns an invalid pointer.  This also makes sense from the code.Randy, does this actually work for you?I'd be quite surprised.I haven't tried 4.1 yet, just 3.6 and current.I will apply an easy fix. - Jay


Date: Thu, 8 May 2008 16:17:37 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] new NT386 snapshots
Jay:
 
I have both console and gui programs built using 4.1 that do pull stuff out of the environment.  I've not noticed any problems with either mode.
 
>From my perspective, the old 4.1 seems more reliable than the current system in a number of respects.  I have a new project with a hard deadline that I would like to use the new cm3 system for, but until these problems (pixmaps, buildstandalone, environ vars, serial i/o, etc.) can be resolved, I'm going to keep using 4.1 for my production work.
 
Regards,
Randy>>> Jay  5/8/2008 2:46 PM >>>http://modula3.elegosoft.com/cm3/uploaded-archives/ http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0.ziphttp://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-WIN32-NT386-d5.7.0.ziphttp://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0-symbols.zip These should have:  latest quake extensions   set relation fixes   other set fixes revealed through dynamic linking of one regression test   hypothetical ability to cross-build to AMD64_LINUX, AMD64_DARWIN    one jmpbuf size for all NT386 configurations (NT386, NT386GNU, NT386MINGNU)  Built with Visual C++ 9.0 Express, so you'll want:http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en  Still more work to do though, e.g. assertion failures in unit tests, pixmap.. Fuller disclosure:Something is leaking memory on my system such that "everything" starts "failing" and I have to reboot.This isn't Modula-3 related.Hopefully these files aren't damaged as a result.Must be some buggy driver or something.. Aside: The environment variable thingy has been bugging me a long time and I finally looked deeper at it.It appears broken in CM3 4.x. I didn't check 3.x yet.I'm still mulling a fix, and haven't run a repro of the break, but it's not a big deal either way.Basically console apps use main that takes char** and gui apps use WinMain that doesn't get environment variables but the generated code calls GetEvironmentStrings() which returns null separated strings.Must be that hardly anyone uses environment variables in Modula-3 on Win32 for this to have lingered so long, at least gui apps.  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Fri May  9 11:10:36 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 9 May 2008 09:10:36 +0000
Subject: [M3devel] pixmap problem
In-Reply-To: <481F9804.1E75.00D7.1@scires.com>
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	 
	<481F9804.1E75.00D7.1@scires.com>
Message-ID: 

 > Also, more bad news, the pixmap problem is not solved.
 
Randy, this DOES actually fix it, but you have to rebuild more.
 
Try:
   cd scripts\python  
  .\do-cm3-std.py realclean  
  .\upgrade.py   (probably not needed) 
   do-cm3-std.py buildship  
 
Make sure "hand.obj" occurs in the various NT386\foo.lst files.
 
I think the fix should be restated to have the code reference *__imp__highbits instead of highbits, and go back to dynamic linking the data.
But ok for now.
 
The std distribution I put yesterday should work, though it is missing the RTArgs fix.
I'll see about making another.
 
  - Jay


Date: Mon, 5 May 2008 23:28:10 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem

Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad news is that now I am getting a command window opening up in addition to the GUI window when the program runs.  This behavior does not occur on v4.1.  The command window seems to be the stdout/stderr of the GUI program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy>>> Jay  5/5/2008 10:47 PM >>>Randy, Yes.The NT386 config files are all checked in.You can use them verbatim. You don't need cminstall, I never use it, and you shouldn't need to edit the config files at all, any edits I make, I check in, and should be usable on all machines.As long as you set %PATH%/%INCLUDE%/%LIB%.If I'm wrong, I'd like to know why and try to fix. Consider the config files just part of cm3.exe.Not generally to be changed locally. Unless, well, unless you intend to, and you should strive to make one form that is usable by all.  - Jay


Date: Mon, 5 May 2008 22:42:30 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay,
When you say "took the updated config file", what do you mean?  Are you saying I need a different cm3.cfg file?
Regards,
Randy>>> Jay  5/5/2008 9:54 PM >>>And you took the updated config file?The way you can tell is that, roughly speaking, hand.obj should be in NT386\_m3responsefile0.txt.Or _m3responsefile1.txt, or, well, somewhere.Anyway, I think I saw the attachment, I can check later..and with 4.1 as I said.. I can see about making the fix not depend on config file changes...but it's not terrible asis, and I'd really like to merge more of the quake code into cm3.exe..  - Jay


Date: Mon, 5 May 2008 21:18:12 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem
Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly when the buildstandalone() directive is used.
 
Regards,
Randy>>> Jay  5/5/2008 7:04 PM >>>Thanks. I'll look into this tonight probably, as well as with 4.1 assuming I can find my binaries and source for it (probably).COULD BE the pixmap problem is something else and 4.1 also has the problem I fixed. We'll see. No need to speculate (unless I can't find my 4.1). - Jay


Date: Mon, 5 May 2008 10:59:27 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problem
Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy>>> Jay  5/4/2008 11:46 AM >>>Randy, Please try with /current/ source, as of this morning Sunday May 4 -- the changes are ALL in NT386.common, so you MUST use MY config files, which are checked in verbatim, or you should be able edit whatever config files you are using. (It's not really a config file issue, don't blame the general confusion people have with them.) I'll try to try later, but I don't have the source right now, gotta look on other machines, and I think it's on a machine on loan.  Or send it to me again.I'd also like to know if this worked with 4.1, or with any release that offered dynamic linking to m3core.dll, on Windows.  I recall a claim that it did. If today's change fixes it, I should be able to investigate 4.1.3.6 did not have such linking.If today's change does not help, well, I still plan on debugging it at some point.. If you aren't current and getting so is difficult, just send the attachment again, it's easy for me to test. Thanks, - Jay


From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rcoleburn at scires.comDate: Sat, 19 Jan 2008 08:52:08 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.I was going to try on PPC_DARWIN but I guess Tony's info suffices. I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. Debugging here is a big humungous pain.NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)And bundles look pretty simple, a bundle is just a generated source file with a constant in it.Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something. The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for? I have to say this is very surprising. I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so.The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: pointer to msvcrt!fopenpointer to msvcrt!fclosenullpointer to kernel32!Sleep But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo.But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo.That doesn't work for data though. There's no ability to intervenve like that.So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it.And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.However that would suck perf in order to make an uncommon case work.I hope Modula-3 doesn't do that either. :)Though I guess since this global data in question...maybe it is rare??? Later, - Jay

> From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 03:09:47 -0500> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] pixmap problem> > Looks fine to me on I386_DARWIN.> > On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:> > > > 

Need to know the score, the latest news, or you need your Hotmail?-get your "fix" Check it out. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Sat May 10 10:31:04 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Sat, 10 May 2008 04:31:04 -0400
Subject: [M3devel] consoles appearing in gui apps (was pixmap...)
In-Reply-To: 
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	
	<481F9804.1E75.00D7.1@scires.com> <481F9804.1E75.00D7.1@scires.com>
	
Message-ID: <48252503.1E75.00D7.1@scires.com>

Jay:
 
Here are my results using your test program.  In all cases I have
created a desktop shortcut to the EXE and double-click this shortcut to
start the program:
 
1.  cm3 v4.1, VS 2005, with IO.Put commented out, no pop-up.
 
2.  cm3 v4.1, VS 2005, using IO.Put, I have to put "@M3novm" on command
line, but then get a pop-up showing a crash "runtime error, illegal
memory access, LockMutexx in ThreadWin32.m3"
 
3.  cm3 v.d5.7.0, VS 2008, with IO.Put commented out, no pop-up
 
4.  cm3 v.d5.7.0, VS 2008, using IO.Put, I get a pop-up window with the
word "Hello".
 
Also, I checked the "link dump" for GUI vs. CUI on both versions and it
appears to be working correctly.
 
Regards,
Randy

>>> Jay  5/9/2008 1:43 AM >>>
  > The bad news is that now I am getting a command window
  > opening up in addition to the GUI window when the program runs. 
  > This behavior does not occur on v4.1.  
 
Randy I've experimented with -gui. Just a few minutes, but I've covered
all of the ground I can think of, except I only used -gui and not an
m3makefile.
>From what I see, it all works as it should.
 
Here is my little program:
 
C:\dev2\j\m3\3>type Main.m3
MODULE Main;
IMPORT IO;
IMPORT WinBase;
BEGIN
  (* IO.Put("Hello\n"); *)
  WinBase.Sleep(10000); (* 10 seconds *)


IF I uncomment out the IO.Put, and use -gui, then there is a "popup",
and hello is printed there.
If I don't have the IO.Put however, no popup.
 
Is anything appearing in your console window? Or it is just empty?
Are you maybe running processes from your app? Or running them from
Explorer?
I am running just one Modula-3 test app, from cmd.
 
It is possible that 4.1 does not bring up a console if you use
stdout/stderr?
There is specific code in the current code to do this.
I don't have 4.1 handy..ok, I have 3.6.
 
This appears to have been a deliberate change.
 
 3.6
C:\net\modula3\m3\libm3\src\os\WIN32\ProcessWin32.m3(185):PROCEDURE
GetFileHandle(hd: WinDef.DWORD; ds: FileWin32.DirectionSet): File.T =

PROCEDURE GetFileHandle(hd: WinDef.DWORD; ds: FileWin32.DirectionSet):
File.T =
  VAR h := WinBase.GetStdHandle(hd);
  BEGIN
    IF (h = NIL)
      OR (h = LOOPHOLE (WinBase.INVALID_HANDLE_VALUE, WinDef.HANDLE))
THEN
      RETURN NIL;
    END;
    TRY RETURN FileWin32.New(h, ds)
    EXCEPT OSError.E => (* not available *)
    END;
    RETURN NIL;
  END GetFileHandle;

 
vs.
 
current
 
C:\dev2\cm3\m3-libs\libm3\src\os\WIN32\ProcessWin32.m3(231):PROCEDURE
GetFileHandle(hd: WinDef.DWORD; ds: FileWin32.DirectionSet): File.T =

PROCEDURE GetFileHandle(hd: WinDef.DWORD; ds: FileWin32.DirectionSet):
File.T =
  VAR h := WinBase.GetStdHandle(hd);
  BEGIN
    IF (h # NIL)
      AND (h # LOOPHOLE (WinBase.INVALID_HANDLE_VALUE, WinDef.HANDLE))
THEN
      TRY RETURN FileWin32.New(h, ds)
      EXCEPT OSError.E => (* not available *)
      END;
    END;
    (* if we can't get the standard handles, we might be a GUI program
       so we'll lazily allocate a console if needed. *)
    RETURN LazyConsole.New (hd, ds);
  END GetFileHandle;
 
 
Ok, this change came in in the upgrade from Critical Mass 4.1 to 5.1.
4.1 being as I understand the actual one and only commercial release.
5.1 I guess being the then current but unreleated Critical Mass tree.
 
http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/WIN32/ProcessWin32.m3.diff?r1=1.1.1.1;r2=1.1.1.2;f=u

 
Please advise.
 
Also, to double check that things are working, run link -dump -headers
foo.exe | findstr /i "subsystem entry"
 
GUI apps should show:
 

C:\dev2\j\m3\3>link -dump -headers NT386\prog.exe | findstr /i
"subsystem entry"
            1C60 entry point (00401C60) _WinMainCRTStartup
               2 subsystem (Windows GUI)
 
console apps should show:
 
C:\dev2\j\m3\3>link -dump -headers NT386\prog.exe | findstr /i
"subsystem entry"
            1BE1 entry point (00401BE1) _mainCRTStartup
               3 subsystem (Windows CUI)

C for console/commandline, G for gui/graphical.
 
If that is not what you are seeing, let's delve into that.
If my test program always brings up a popup, when compiled with -gui,
with the IO.Put commented out, let's delve into that.
If your console is empty, let's look into that.
If you console has output in it, well, I'm inclined to say you are
seeing improved correct behavior, but we can debate it, I guess.
 
 - Jay

From: jayk123 at hotmail.com 
To: rcoleburn at scires.com; m3devel at elegosoft.com 
Subject: FW: [M3devel] pixmap problem
Date: Thu, 8 May 2008 19:21:49 +0000

truncated again...




From: jayk123 at hotmail.com 
To: rcoleburn at scires.com; m3devel at elegosoft.com 
Subject: RE: [M3devel] pixmap problem
Date: Thu, 8 May 2008 18:57:08 +0000

Randy, At first very quick glance, this stuff looks ok.
CM3-IDE probably doesn't really understand the config file, similar to
m3cgcat's partial misunderstanding.
  (Which is why I keep TARGET declared in NT386* instead of just
NT386.common.)
PKG_USE is defined I think, but it takes a really accurate
understanding of Quake to get it.
 
The entry/subsystem stuff also seems complete but I didn't try examples
yet.
Sorry, didn't give this all much time yet.
I did get me to look at the environment variable bug that's been
sitting there forever, with a bogus fix..
 
Can CM3-IDE default PKG_USE to CM3_ROOT + "/pkg"? Or INSTALL_ROOT +
"/pkg"? Or whatever?
That is what it always is, in anything that is checked in or that
cminstall will give you.
It takes hand editing of cm3.cfg to get anything else I think.
 
Or CM3-IDE users can just edit the file some. Not a lot. But some.
Given an incomplete understanding of the config files, probably putting
in CM3-IDE wants but under if FALSE will perhaps work.
Personally I wasn't impressed with Reactor... VC5 find-in-files gets me
all I need. Anything besides plain text search doesn't scale..
 
 - Jay
From: jayk123 at hotmail.com 
To: rcoleburn at scires.com; m3devel at elegosoft.com 
Subject: RE: [M3devel] pixmap problem
Date: Tue, 6 May 2008 03:38:03 +0000

Randy, don't worry.
Two of these problems are trivial to fix -- PKG_USE and popups.
The pixmap one will need debugging.
 
 - Jay

Date: Mon, 5 May 2008 23:28:10 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com; jayk123 at hotmail.com 
Subject: RE: [M3devel] pixmap problem

Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've
copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad
news is that now I am getting a command window opening up in addition to
the GUI window when the program runs.  This behavior does not occur on
v4.1.  The command window seems to be the stdout/stderr of the GUI
program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which
needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy

>>> Jay  5/5/2008 10:47 PM >>>
Randy, Yes.
The NT386 config files are all checked in.
You can use them verbatim. You don't need cminstall, I never use it,
and you shouldn't need to edit the config files at all, any edits I
make, I check in, and should be usable on all machines.
As long as you set %PATH%/%INCLUDE%/%LIB%.
If I'm wrong, I'd like to know why and try to fix.
 
Consider the config files just part of cm3.exe.
Not generally to be changed locally. Unless, well, unless you intend
to, and you should strive to make one form that is usable by all.
 
 - Jay


Date: Mon, 5 May 2008 22:42:30 -0400
From: rcoleburn at scires.com 
To: jayk123 at hotmail.com 
Subject: RE: [M3devel] pixmap problem

Jay,
When you say "took the updated config file", what do you mean?  Are you
saying I need a different cm3.cfg file?
Regards,
Randy

>>> Jay  5/5/2008 9:54 PM >>>
And you took the updated config file?
The way you can tell is that, roughly speaking, hand.obj should be in
NT386\_m3responsefile0.txt.
Or _m3responsefile1.txt, or, well, somewhere.
Anyway, I think I saw the attachment, I can check later..and with 4.1
as I said..
 
I can see about making the fix not depend on config file changes...but
it's not terrible asis, and I'd really like to merge more of the quake
code into cm3.exe..
 
 - Jay

Date: Mon, 5 May 2008 21:18:12 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com 
Subject: Re: [M3devel] pixmap problem

Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly
when the buildstandalone() directive is used.
 
Regards,
Randy

>>> Jay  5/5/2008 7:04 PM >>>
Thanks. I'll look into this tonight probably, as well as with 4.1
assuming I can find my binaries and source for it (probably).

COULD BE the pixmap problem is something else and 4.1 also has the
problem I fixed. We'll see. No need to speculate (unless I can't find my
4.1).

 - Jay


Date: Mon, 5 May 2008 10:59:27 -0400
From: rcoleburn at scires.com 
To: jayk123 at hotmail.com 
CC: m3devel at elegosoft.com 
Subject: RE: [M3devel] pixmap problem

Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files
or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy

>>> Jay  5/4/2008 11:46 AM >>>
Randy, Please try with /current/ source, as of this morning Sunday May
4 -- the changes are ALL in NT386.common, so you MUST use MY config
files, which are checked in verbatim, or you should be able edit
whatever config files you are using.
 
(It's not really a config file issue, don't blame the general confusion
people have with them.)
 
I'll try to try later, but I don't have the source right now, gotta
look on other machines, and I think it's on a machine on loan.
  Or send it to me again.
I'd also like to know if this worked with 4.1, or with any release that
offered dynamic linking to m3core.dll, on Windows.
  I recall a claim that it did. If today's change fixes it, I should be
able to investigate 4.1.
3.6 did not have such linking.
If today's change does not help, well, I still plan on debugging it at
some point..
 
If you aren't current and getting so is difficult, just send the
attachment again, it's easy for me to test.
 
Thanks,
 - Jay

From: jayk123 at hotmail.com 
To: hosking at cs.purdue.edu; rcoleburn at scires.com 
Date: Sat, 19 Jan 2008 08:52:08 +0000
CC: m3devel at elegosoft.com 
Subject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.
I was going to try on PPC_DARWIN but I guess Tony's info suffices.
 
I tried rolling hand.c back to before I changed (months/year ago),
since it is involved in bit twiddling, no change, phew.
 
Debugging here is a big humungous pain.
NT386 has good stacks and line numbers, but no locals or type info, I'd
really sometime like to get Codeview info into those .objs...I think it
is documented well enough, but still not necessarily easy, or maybe have
a C generating backend partly for this reason (and to bring up more
targets, using native tools), and function calls in disassembly I think
don't resolve; NT386GNU can't yet build this, though it will soon, but
I'm not familiar with gdb and there appears to be no type info. I'm
building m3gdb right now, I don't know if it will work, I hope it has
type info, and I'm not familiar with the relevant code. In gdb I
struggle just to view bytes in memory, add numbers to addresses and see
those, etc. I think for MY problem, I'm going to link in C code to dump
the structs. There is tracing code and I enabled it, but even it crashes
in Text_Length. At least MY problem crashes, hopefully near the problem,
whereas your problem goes all the way through to completion with no
stopping to hint where the problem is. Darn it. :) on the mock rudeness
and :( on the lack of a crash.
 
You write the bundle out and it matches, so that doesn't rule out
bundles as being the problem? (darn)
And bundles look pretty simple, a bundle is just a generated source
file with a constant in it.
Maybe newline problems? That wouldn't make sense. I just downloaded
some program that might let me separately view the ppm, maybe it'll
reveal something.
 
The bad behavior has like regularly spaced solid color veritical bars a
few pixels side across the whole picture, and regularly spaced vertical
stripes from the correct picture alternating with that. Perhaps someone
with ppm/bitmap/graphics experience has seen this behavior and it
results from some common pixmap mismanagement we could look for?
 
I have to say this is very surprising.
 
I always wondered, and now I pretty much assume -- Modula-3 never
imports/exports data in its dynamic linking, right? It alway
imports/exports functions, right?
On Windows, functions have an optional optimization, but data must be
handled differently at compile time if it is going to be dynamically
imported.
For functions, if you don't apply the optimization at compile time, the
linker will just generate a single instruction thunk instead.
 
That is, given a symbol Foo, there is a symbol __imp__Foo that is a
pointer to the actual foo in another .dll/.so.
The loader only patches pointers, one per import if you build your .dll
correctly, it doesn't patch instructions or code strewn throughout a
.dll, just one contiguous array of pointers. MAYBE they don't have to be
contiguous for each .dl you import from.
 
That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my
.dll/.exe typically has an array:
 
pointer to msvcrt!fopen
pointer to msvcrt!fclose
null
pointer to kernel32!Sleep
 
But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not
be adjacent.
 
So, going back, my point/question is that, if the compiler knows the
function is imported, it can call through __imp__Foo instead of calling
Foo.
But if it calls Foo and you import Foo, the linker will create the
function Foo that just jmps through __imp__Foo.
That doesn't work for data though. There's no ability to intervenve
like that.
So for imported data, the compiler must generated a read and
dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to
be imported.
Data imports may be faster when appropriate, but for this reason, I'd
say they aren't worth it.
And for this reason, I HOPE Modula-3 never imports/exports data.
 
Oh, you could, for data, always reference the pointer __imp_Foo, and if
non materializes, create one.
However that would suck perf in order to make an uncommon case work.
I hope Modula-3 doesn't do that either. :)
Though I guess since this global data in question...maybe it is
rare???
 
Later,
 - Jay



> From: hosking at cs.purdue.edu 
> Date: Sat, 19 Jan 2008 03:09:47 -0500
> To: rcoleburn at scires.com 
> CC: m3devel at elegosoft.com 
> Subject: Re: [M3devel] pixmap problem
> 
> Looks fine to me on I386_DARWIN.
> 
> On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:
> 
> > 
> 


Need to know the score, the latest news, or you need your Hotmail*-get
your "fix" Check it out. ( http://www.msnmobilefix.com/Default.aspx ) 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Sat May 10 10:51:23 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Sat, 10 May 2008 04:51:23 -0400
Subject: [M3devel] pixmap problem
In-Reply-To: 
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	
	<481F9804.1E75.00D7.1@scires.com><481F9804.1E75.00D7.1@scires.com>
	
Message-ID: <482529C7.1E75.00D7.1@scires.com>

Jay:
 
I do not have python installed on my computer, so I can't run your
scripts.
 
I used the scripts in scripts\win to upgrade a few days ago.
 
I am not seeing hand.obj in the .lst file.
 
I will do a CVS update and try the upgrade again followed by
do-cm3-standard.
 
Regards,
Randy

>>> Jay  5/9/2008 5:10 AM >>>
 > Also, more bad news, the pixmap problem is not solved.
 
Randy, this DOES actually fix it, but you have to rebuild more.
 
Try:
   cd scripts\python  
  .\do-cm3-std.py realclean  
  .\upgrade.py   (probably not needed) 
   do-cm3-std.py buildship  
 
Make sure "hand.obj" occurs in the various NT386\foo.lst files.
 
I think the fix should be restated to have the code reference
*__imp__highbits instead of highbits, and go back to dynamic linking the
data.
But ok for now.
 
The std distribution I put yesterday should work, though it is missing
the RTArgs fix.
I'll see about making another.
 
  - Jay

Date: Mon, 5 May 2008 23:28:10 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com; jayk123 at hotmail.com 
Subject: RE: [M3devel] pixmap problem

Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've
copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad
news is that now I am getting a command window opening up in addition to
the GUI window when the program runs.  This behavior does not occur on
v4.1.  The command window seems to be the stdout/stderr of the GUI
program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which
needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy

>>> Jay  5/5/2008 10:47 PM >>>
Randy, Yes.
The NT386 config files are all checked in.
You can use them verbatim. You don't need cminstall, I never use it,
and you shouldn't need to edit the config files at all, any edits I
make, I check in, and should be usable on all machines.
As long as you set %PATH%/%INCLUDE%/%LIB%.
If I'm wrong, I'd like to know why and try to fix.
 
Consider the config files just part of cm3.exe.
Not generally to be changed locally. Unless, well, unless you intend
to, and you should strive to make one form that is usable by all.
 
 - Jay


Date: Mon, 5 May 2008 22:42:30 -0400
From: rcoleburn at scires.com 
To: jayk123 at hotmail.com 
Subject: RE: [M3devel] pixmap problem

Jay,
When you say "took the updated config file", what do you mean?  Are you
saying I need a different cm3.cfg file?
Regards,
Randy

>>> Jay  5/5/2008 9:54 PM >>>
And you took the updated config file?
The way you can tell is that, roughly speaking, hand.obj should be in
NT386\_m3responsefile0.txt.
Or _m3responsefile1.txt, or, well, somewhere.
Anyway, I think I saw the attachment, I can check later..and with 4.1
as I said..
 
I can see about making the fix not depend on config file changes...but
it's not terrible asis, and I'd really like to merge more of the quake
code into cm3.exe..
 
 - Jay

Date: Mon, 5 May 2008 21:18:12 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com 
Subject: Re: [M3devel] pixmap problem

Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly
when the buildstandalone() directive is used.
 
Regards,
Randy

>>> Jay  5/5/2008 7:04 PM >>>
Thanks. I'll look into this tonight probably, as well as with 4.1
assuming I can find my binaries and source for it (probably).

COULD BE the pixmap problem is something else and 4.1 also has the
problem I fixed. We'll see. No need to speculate (unless I can't find my
4.1).

 - Jay


Date: Mon, 5 May 2008 10:59:27 -0400
From: rcoleburn at scires.com 
To: jayk123 at hotmail.com 
CC: m3devel at elegosoft.com 
Subject: RE: [M3devel] pixmap problem

Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files
or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy

>>> Jay  5/4/2008 11:46 AM >>>
Randy, Please try with /current/ source, as of this morning Sunday May
4 -- the changes are ALL in NT386.common, so you MUST use MY config
files, which are checked in verbatim, or you should be able edit
whatever config files you are using.
 
(It's not really a config file issue, don't blame the general confusion
people have with them.)
 
I'll try to try later, but I don't have the source right now, gotta
look on other machines, and I think it's on a machine on loan.
  Or send it to me again.
I'd also like to know if this worked with 4.1, or with any release that
offered dynamic linking to m3core.dll, on Windows.
  I recall a claim that it did. If today's change fixes it, I should be
able to investigate 4.1.
3.6 did not have such linking.
If today's change does not help, well, I still plan on debugging it at
some point..
 
If you aren't current and getting so is difficult, just send the
attachment again, it's easy for me to test.
 
Thanks,
 - Jay

From: jayk123 at hotmail.com 
To: hosking at cs.purdue.edu; rcoleburn at scires.com 
Date: Sat, 19 Jan 2008 08:52:08 +0000
CC: m3devel at elegosoft.com 
Subject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.
I was going to try on PPC_DARWIN but I guess Tony's info suffices.
 
I tried rolling hand.c back to before I changed (months/year ago),
since it is involved in bit twiddling, no change, phew.
 
Debugging here is a big humungous pain.
NT386 has good stacks and line numbers, but no locals or type info, I'd
really sometime like to get Codeview info into those .objs...I think it
is documented well enough, but still not necessarily easy, or maybe have
a C generating backend partly for this reason (and to bring up more
targets, using native tools), and function calls in disassembly I think
don't resolve; NT386GNU can't yet build this, though it will soon, but
I'm not familiar with gdb and there appears to be no type info. I'm
building m3gdb right now, I don't know if it will work, I hope it has
type info, and I'm not familiar with the relevant code. In gdb I
struggle just to view bytes in memory, add numbers to addresses and see
those, etc. I think for MY problem, I'm going to link in C code to dump
the structs. There is tracing code and I enabled it, but even it crashes
in Text_Length. At least MY problem crashes, hopefully near the problem,
whereas your problem goes all the way through to completion with no
stopping to hint where the problem is. Darn it. :) on the mock rudeness
and :( on the lack of a crash.
 
You write the bundle out and it matches, so that doesn't rule out
bundles as being the problem? (darn)
And bundles look pretty simple, a bundle is just a generated source
file with a constant in it.
Maybe newline problems? That wouldn't make sense. I just downloaded
some program that might let me separately view the ppm, maybe it'll
reveal something.
 
The bad behavior has like regularly spaced solid color veritical bars a
few pixels side across the whole picture, and regularly spaced vertical
stripes from the correct picture alternating with that. Perhaps someone
with ppm/bitmap/graphics experience has seen this behavior and it
results from some common pixmap mismanagement we could look for?
 
I have to say this is very surprising.
 
I always wondered, and now I pretty much assume -- Modula-3 never
imports/exports data in its dynamic linking, right? It alway
imports/exports functions, right?
On Windows, functions have an optional optimization, but data must be
handled differently at compile time if it is going to be dynamically
imported.
For functions, if you don't apply the optimization at compile time, the
linker will just generate a single instruction thunk instead.
 
That is, given a symbol Foo, there is a symbol __imp__Foo that is a
pointer to the actual foo in another .dll/.so.
The loader only patches pointers, one per import if you build your .dll
correctly, it doesn't patch instructions or code strewn throughout a
.dll, just one contiguous array of pointers. MAYBE they don't have to be
contiguous for each .dl you import from.
 
That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my
.dll/.exe typically has an array:
 
pointer to msvcrt!fopen
pointer to msvcrt!fclose
null
pointer to kernel32!Sleep
 
But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not
be adjacent.
 
So, going back, my point/question is that, if the compiler knows the
function is imported, it can call through __imp__Foo instead of calling
Foo.
But if it calls Foo and you import Foo, the linker will create the
function Foo that just jmps through __imp__Foo.
That doesn't work for data though. There's no ability to intervenve
like that.
So for imported data, the compiler must generated a read and
dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to
be imported.
Data imports may be faster when appropriate, but for this reason, I'd
say they aren't worth it.
And for this reason, I HOPE Modula-3 never imports/exports data.
 
Oh, you could, for data, always reference the pointer __imp_Foo, and if
non materializes, create one.
However that would suck perf in order to make an uncommon case work.
I hope Modula-3 doesn't do that either. :)
Though I guess since this global data in question...maybe it is
rare???
 
Later,
 - Jay



> From: hosking at cs.purdue.edu 
> Date: Sat, 19 Jan 2008 03:09:47 -0500
> To: rcoleburn at scires.com 
> CC: m3devel at elegosoft.com 
> Subject: Re: [M3devel] pixmap problem
> 
> Looks fine to me on I386_DARWIN.
> 
> On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:
> 
> > 
> 


Need to know the score, the latest news, or you need your Hotmail*-get
your "fix" Check it out. ( http://www.msnmobilefix.com/Default.aspx ) 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sat May 10 11:01:22 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 10 May 2008 09:01:22 +0000
Subject: [M3devel] consoles appearing in gui apps (was pixmap...)
In-Reply-To: <48252503.1E75.00D7.1@scires.com>
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	
	<481F9804.1E75.00D7.1@scires.com> <481F9804.1E75.00D7.1@scires.com>
	 
	<48252503.1E75.00D7.1@scires.com>
Message-ID: 

Randy, this is about what I expect. I only tried 3.6 so far; will try 4.1 later.
Are you satisfied now or not?
Or is your larger actual program showing a popup without output?
 
Or you want output to stderr/stdout in gui apps to just disappear as in 4.1?
 
There definitely is a change from 4.1, and it came in with the Critical Mass code in 5.1.
 
We could I guess put in an @M3 switch to either disappear stdout/stderr in gui apps, or specify a file or files for them to go to. We could also export a function that you'd call to change the global behavior. That's better. It wouldn't do anything on Unix (unless there is a way...?)
 
"Regular" C/C++ stdout/stderr in Windows gui apps does just disappear, but the Modula-3 libraries don't necessarily have to be "the same".
 
There isn't as far as I know an analog on Unix.
I think if you launch something from a typical gui (KDE Kicker, GNOME panels, etc.), stdout/stderr is lost.
If you launch from a console, it is not. I see quite a bit of stdout/stderr spew in gui apps like Kate, KDevelop, etc., seems like bugs (kind of like Windows's OutputDebugString?)
 
 - Jay


Date: Sat, 10 May 2008 04:31:04 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] consoles appearing in gui apps (was pixmap...)

Jay:
 
Here are my results using your test program.  In all cases I have created a desktop shortcut to the EXE and double-click this shortcut to start the program:
 
1.  cm3 v4.1, VS 2005, with IO.Put commented out, no pop-up.
 
2.  cm3 v4.1, VS 2005, using IO.Put, I have to put "@M3novm" on command line, but then get a pop-up showing a crash "runtime error, illegal memory access, LockMutexx in ThreadWin32.m3"
 
3.  cm3 v.d5.7.0, VS 2008, with IO.Put commented out, no pop-up
 
4.  cm3 v.d5.7.0, VS 2008, using IO.Put, I get a pop-up window with the word "Hello".
 
Also, I checked the "link dump" for GUI vs. CUI on both versions and it appears to be working correctly.
 
Regards,
Randy>>> Jay  5/9/2008 1:43 AM >>>  > The bad news is that now I am getting a command window  > opening up in addition to the GUI window when the program runs.   > This behavior does not occur on v4.1.   Randy I've experimented with -gui. Just a few minutes, but I've covered all of the ground I can think of, except I only used -gui and not an m3makefile.From what I see, it all works as it should. Here is my little program: C:\dev2\j\m3\3>type Main.m3MODULE Main;IMPORT IO;IMPORT WinBase;BEGIN  (* IO.Put("Hello\n"); *)  WinBase.Sleep(10000); (* 10 seconds *)IF I uncomment out the IO.Put, and use -gui, then there is a "popup", and hello is printed there.If I don't have the IO.Put however, no popup. Is anything appearing in your console window? Or it is just empty?Are you maybe running processes from your app? Or running them from Explorer?I am running just one Modula-3 test app, from cmd. It is possible that 4.1 does not bring up a console if you use stdout/stderr?There is specific code in the current code to do this.I don't have 4.1 handy..ok, I have 3.6. This appears to have been a deliberate change.  3.6C:\net\modula3\m3\libm3\src\os\WIN32\ProcessWin32.m3(185):PROCEDURE GetFileHandle(hd: WinDef.DWORD; ds: FileWin32.DirectionSet): File.T =PROCEDURE GetFileHandle(hd: WinDef.DWORD; ds: FileWin32.DirectionSet): File.T =  VAR h := WinBase.GetStdHandle(hd);  BEGIN    IF (h = NIL)      OR (h = LOOPHOLE (WinBase.INVALID_HANDLE_VALUE, WinDef.HANDLE)) THEN      RETURN NIL;    END;    TRY RETURN FileWin32.New(h, ds)    EXCEPT OSError.E => (* not available *)    END;    RETURN NIL;  END GetFileHandle; vs. current C:\dev2\cm3\m3-libs\libm3\src\os\WIN32\ProcessWin32.m3(231):PROCEDURE GetFileHandle(hd: WinDef.DWORD; ds: FileWin32.DirectionSet): File.T =PROCEDURE GetFileHandle(hd: WinDef.DWORD; ds: FileWin32.DirectionSet): File.T =  VAR h := WinBase.GetStdHandle(hd);  BEGIN    IF (h # NIL)      AND (h # LOOPHOLE (WinBase.INVALID_HANDLE_VALUE, WinDef.HANDLE)) THEN      TRY RETURN FileWin32.New(h, ds)      EXCEPT OSError.E => (* not available *)      END;    END;    (* if we can't get the standard handles, we might be a GUI program       so we'll lazily allocate a console if needed. *)    RETURN LazyConsole.New (hd, ds);  END GetFileHandle;  Ok, this change came in in the upgrade from Critical Mass 4.1 to 5.1.4.1 being as I understand the actual one and only commercial release.5.1 I guess being the then current but unreleated Critical Mass tree. http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/WIN32/ProcessWin32.m3.diff?r1=1.1.1.1;r2=1.1.1.2;f=u Please advise. Also, to double check that things are working, run link -dump -headers foo.exe | findstr /i "subsystem entry" GUI apps should show: C:\dev2\j\m3\3>link -dump -headers NT386\prog.exe | findstr /i "subsystem entry"            1C60 entry point (00401C60) _WinMainCRTStartup               2 subsystem (Windows GUI) console apps should show: C:\dev2\j\m3\3>link -dump -headers NT386\prog.exe | findstr /i "subsystem entry"            1BE1 entry point (00401BE1) _mainCRTStartup               3 subsystem (Windows CUI)C for console/commandline, G for gui/graphical. If that is not what you are seeing, let's delve into that.If my test program always brings up a popup, when compiled with -gui, with the IO.Put commented out, let's delve into that.If your console is empty, let's look into that.If you console has output in it, well, I'm inclined to say you are seeing improved correct behavior, but we can debate it, I guess.  - Jay


From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: FW: [M3devel] pixmap problemDate: Thu, 8 May 2008 19:21:49 +0000

truncated again...


From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problemDate: Thu, 8 May 2008 18:57:08 +0000

Randy, At first very quick glance, this stuff looks ok.CM3-IDE probably doesn't really understand the config file, similar to m3cgcat's partial misunderstanding.  (Which is why I keep TARGET declared in NT386* instead of just NT386.common.)PKG_USE is defined I think, but it takes a really accurate understanding of Quake to get it. The entry/subsystem stuff also seems complete but I didn't try examples yet.Sorry, didn't give this all much time yet.I did get me to look at the environment variable bug that's been sitting there forever, with a bogus fix.. Can CM3-IDE default PKG_USE to CM3_ROOT + "/pkg"? Or INSTALL_ROOT + "/pkg"? Or whatever?That is what it always is, in anything that is checked in or that cminstall will give you.It takes hand editing of cm3.cfg to get anything else I think. Or CM3-IDE users can just edit the file some. Not a lot. But some.Given an incomplete understanding of the config files, probably putting in CM3-IDE wants but under if FALSE will perhaps work.Personally I wasn't impressed with Reactor... VC5 find-in-files gets me all I need. Anything besides plain text search doesn't scale..  - Jay


From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problemDate: Tue, 6 May 2008 03:38:03 +0000

Randy, don't worry.Two of these problems are trivial to fix -- PKG_USE and popups.The pixmap one will need debugging.  - Jay


Date: Mon, 5 May 2008 23:28:10 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad news is that now I am getting a command window opening up in addition to the GUI window when the program runs.  This behavior does not occur on v4.1.  The command window seems to be the stdout/stderr of the GUI program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy>>> Jay  5/5/2008 10:47 PM >>>Randy, Yes.The NT386 config files are all checked in.You can use them verbatim. You don't need cminstall, I never use it, and you shouldn't need to edit the config files at all, any edits I make, I check in, and should be usable on all machines.As long as you set %PATH%/%INCLUDE%/%LIB%.If I'm wrong, I'd like to know why and try to fix. Consider the config files just part of cm3.exe.Not generally to be changed locally. Unless, well, unless you intend to, and you should strive to make one form that is usable by all.  - Jay


Date: Mon, 5 May 2008 22:42:30 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay,
When you say "took the updated config file", what do you mean?  Are you saying I need a different cm3.cfg file?
Regards,
Randy>>> Jay  5/5/2008 9:54 PM >>>And you took the updated config file?The way you can tell is that, roughly speaking, hand.obj should be in NT386\_m3responsefile0.txt.Or _m3responsefile1.txt, or, well, somewhere.Anyway, I think I saw the attachment, I can check later..and with 4.1 as I said.. I can see about making the fix not depend on config file changes...but it's not terrible asis, and I'd really like to merge more of the quake code into cm3.exe..  - Jay


Date: Mon, 5 May 2008 21:18:12 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem
Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly when the buildstandalone() directive is used.
 
Regards,
Randy>>> Jay  5/5/2008 7:04 PM >>>Thanks. I'll look into this tonight probably, as well as with 4.1 assuming I can find my binaries and source for it (probably).COULD BE the pixmap problem is something else and 4.1 also has the problem I fixed. We'll see. No need to speculate (unless I can't find my 4.1). - Jay


Date: Mon, 5 May 2008 10:59:27 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problem
Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy>>> Jay  5/4/2008 11:46 AM >>>Randy, Please try with /current/ source, as of this morning Sunday May 4 -- the changes are ALL in NT386.common, so you MUST use MY config files, which are checked in verbatim, or you should be able edit whatever config files you are using. (It's not really a config file issue, don't blame the general confusion people have with them.) I'll try to try later, but I don't have the source right now, gotta look on other machines, and I think it's on a machine on loan.  Or send it to me again.I'd also like to know if this worked with 4.1, or with any release that offered dynamic linking to m3core.dll, on Windows.  I recall a claim that it did. If today's change fixes it, I should be able to investigate 4.1.3.6 did not have such linking.If today's change does not help, well, I still plan on debugging it at some point.. If you aren't current and getting so is difficult, just send the attachment again, it's easy for me to test. Thanks, - Jay


From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rcoleburn at scires.comDate: Sat, 19 Jan 2008 08:52:08 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.I was going to try on PPC_DARWIN but I guess Tony's info suffices. I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. Debugging here is a big humungous pain.NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)And bundles look pretty simple, a bundle is just a generated source file with a constant in it.Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something. The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for? I have to say this is very surprising. I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so.The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: pointer to msvcrt!fopenpointer to msvcrt!fclosenullpointer to kernel32!Sleep But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo.But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo.That doesn't work for data though. There's no ability to intervenve like that.So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it.And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.However that would suck perf in order to make an uncommon case work.I hope Modula-3 doesn't do that either. :)Though I guess since this global data in question...maybe it is rare??? Later, - Jay

> From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 03:09:47 -0500> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] pixmap problem> > Looks fine to me on I386_DARWIN.> > On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:> > > > 

Need to know the score, the latest news, or you need your Hotmail?-get your "fix" Check it out. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sat May 10 11:19:59 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 10 May 2008 09:19:59 +0000
Subject: [M3devel] pixmap problem
In-Reply-To: <482529C7.1E75.00D7.1@scires.com>
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	
	<481F9804.1E75.00D7.1@scires.com><481F9804.1E75.00D7.1@scires.com>
	 
	<482529C7.1E75.00D7.1@scires.com>
Message-ID: 

Randy, I strongly recommend you install Python. It is trivial, and gives you something good.
"Try it. You'll like it."
It is WAY more pleasant than dealing with sh or cmd or Perl, and I've spent quite a while fighting with cmd and Perl.
 
scripts\win\do-cm3-std buildship will probably work too.
I'm hoping to find some excuse to delete that directory, like some grand new important feature in the *.sh and *.py files.
 
I put up an updated distribution, and cleaned out older ones.
 
I do consider it a bit of a flaw that cm3 has a "builder", but not a "multi directory builder".
As well, it should be easy to put the build intermediates outside of the source tree.
As well, it should be possible to build outputs directly into the install, for the very optimistic scenario.
I went to build distributions with make-dist.cmd and make-dist.py at the same time and that fails because they fight over intermediate directories.
 
 > I am not seeing hand.obj in the .lst file.
 
You REALLY need to fix that, besides building std.
Linking to hand.obj is THE FIX, at least the current form of it.
My config files always link to it.
You do have to rebuild m3core in order to produce and ship it, which do-cm3-std will do, and upgrade will do.
 
The .lst file I speak of..oh, I guess there's others now, but the main one is the linker output.
  Which is really to say, it is the linker dumping the response file contents.
Or you can check the _m3response0.txt, _m3response1.txt files.
There are now a few more .lst files where there is a C compilation, in order to quash the C compiler output that upsets Olaf and Tony. But these are rare, hand.lst, dtoa.lst, RTLinkerC.lst, we could remove two of them.
 
I can probably remove hand.obj, but a reason to push people away from wierdo heavily customized config files is a good thing.
 
I am certain this bug is fixed.
 
 - Jay



Date: Sat, 10 May 2008 04:51:23 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem


Jay:
 
I do not have python installed on my computer, so I can't run your scripts.
 
I used the scripts in scripts\win to upgrade a few days ago.
 
I am not seeing hand.obj in the .lst file.
 
I will do a CVS update and try the upgrade again followed by do-cm3-standard.
 
Regards,
Randy>>> Jay  5/9/2008 5:10 AM >>>
 > Also, more bad news, the pixmap problem is not solved. Randy, this DOES actually fix it, but you have to rebuild more. Try:   cd scripts\python    .\do-cm3-std.py realclean    .\upgrade.py   (probably not needed)    do-cm3-std.py buildship   Make sure "hand.obj" occurs in the various NT386\foo.lst files. I think the fix should be restated to have the code reference *__imp__highbits instead of highbits, and go back to dynamic linking the data.But ok for now. The std distribution I put yesterday should work, though it is missing the RTArgs fix.I'll see about making another.   - Jay


Date: Mon, 5 May 2008 23:28:10 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad news is that now I am getting a command window opening up in addition to the GUI window when the program runs.  This behavior does not occur on v4.1.  The command window seems to be the stdout/stderr of the GUI program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy>>> Jay  5/5/2008 10:47 PM >>>Randy, Yes.The NT386 config files are all checked in.You can use them verbatim. You don't need cminstall, I never use it, and you shouldn't need to edit the config files at all, any edits I make, I check in, and should be usable on all machines.As long as you set %PATH%/%INCLUDE%/%LIB%.If I'm wrong, I'd like to know why and try to fix. Consider the config files just part of cm3.exe.Not generally to be changed locally. Unless, well, unless you intend to, and you should strive to make one form that is usable by all.  - Jay


Date: Mon, 5 May 2008 22:42:30 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay,
When you say "took the updated config file", what do you mean?  Are you saying I need a different cm3.cfg file?
Regards,
Randy>>> Jay  5/5/2008 9:54 PM >>>And you took the updated config file?The way you can tell is that, roughly speaking, hand.obj should be in NT386\_m3responsefile0.txt.Or _m3responsefile1.txt, or, well, somewhere.Anyway, I think I saw the attachment, I can check later..and with 4.1 as I said.. I can see about making the fix not depend on config file changes...but it's not terrible asis, and I'd really like to merge more of the quake code into cm3.exe..  - Jay


Date: Mon, 5 May 2008 21:18:12 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem
Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly when the buildstandalone() directive is used.
 
Regards,
Randy>>> Jay  5/5/2008 7:04 PM >>>Thanks. I'll look into this tonight probably, as well as with 4.1 assuming I can find my binaries and source for it (probably).COULD BE the pixmap problem is something else and 4.1 also has the problem I fixed. We'll see. No need to speculate (unless I can't find my 4.1). - Jay


Date: Mon, 5 May 2008 10:59:27 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problem
Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy>>> Jay  5/4/2008 11:46 AM >>>Randy, Please try with /current/ source, as of this morning Sunday May 4 -- the changes are ALL in NT386.common, so you MUST use MY config files, which are checked in verbatim, or you should be able edit whatever config files you are using. (It's not really a config file issue, don't blame the general confusion people have with them.) I'll try to try later, but I don't have the source right now, gotta look on other machines, and I think it's on a machine on loan.  Or send it to me again.I'd also like to know if this worked with 4.1, or with any release that offered dynamic linking to m3core.dll, on Windows.  I recall a claim that it did. If today's change fixes it, I should be able to investigate 4.1.3.6 did not have such linking.If today's change does not help, well, I still plan on debugging it at some point.. If you aren't current and getting so is difficult, just send the attachment again, it's easy for me to test. Thanks, - Jay


From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rcoleburn at scires.comDate: Sat, 19 Jan 2008 08:52:08 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.I was going to try on PPC_DARWIN but I guess Tony's info suffices. I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. Debugging here is a big humungous pain.NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)And bundles look pretty simple, a bundle is just a generated source file with a constant in it.Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something. The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for? I have to say this is very surprising. I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so.The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: pointer to msvcrt!fopenpointer to msvcrt!fclosenullpointer to kernel32!Sleep But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo.But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo.That doesn't work for data though. There's no ability to intervenve like that.So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it.And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.However that would suck perf in order to make an uncommon case work.I hope Modula-3 doesn't do that either. :)Though I guess since this global data in question...maybe it is rare??? Later, - Jay

> From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 03:09:47 -0500> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] pixmap problem> > Looks fine to me on I386_DARWIN.> > On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:> > > > 

Need to know the score, the latest news, or you need your Hotmail?-get your "fix" Check it out. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Sat May 10 11:23:35 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Sat, 10 May 2008 05:23:35 -0400
Subject: [M3devel] pixmap problem
In-Reply-To: <482529C7.1E75.00D7.1@scires.com>
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	
	<481F9804.1E75.00D7.1@scires.com><481F9804.1E75.00D7.1@scires.com>
	
	<482529C7.1E75.00D7.1@scires.com>
Message-ID: <48253152.1E75.00D7.1@scires.com>

Jay:
 
I've performed the following and it seems to have fixed the problem
with the TestPixmap program when built standalone:
 
1.  performed CVS update
2.  updated cm3.cfg and NT386* in \cm3\bin based on sources in
cminstall\config
3.  scripts\win\upgrade
4.  scripts\win\do-cm3-std buildship
 
I checked the .lst file and I am now seeing "hand.obj"
 
Regards,
Randy

>>> "Randy Coleburn"  5/10/2008 4:51 AM >>>
Jay:
 
I do not have python installed on my computer, so I can't run your
scripts.
 
I used the scripts in scripts\win to upgrade a few days ago.
 
I am not seeing hand.obj in the .lst file.
 
I will do a CVS update and try the upgrade again followed by
do-cm3-standard.
 
Regards,
Randy

>>> Jay  5/9/2008 5:10 AM >>>
 > Also, more bad news, the pixmap problem is not solved.
 
Randy, this DOES actually fix it, but you have to rebuild more.
 
Try:
   cd scripts\python  
  .\do-cm3-std.py realclean  
  .\upgrade.py   (probably not needed) 
   do-cm3-std.py buildship  
 
Make sure "hand.obj" occurs in the various NT386\foo.lst files.
 
I think the fix should be restated to have the code reference
*__imp__highbits instead of highbits, and go back to dynamic linking the
data.
But ok for now.
 
The std distribution I put yesterday should work, though it is missing
the RTArgs fix.
I'll see about making another.
 
  - Jay

Date: Mon, 5 May 2008 23:28:10 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com; jayk123 at hotmail.com 
Subject: RE: [M3devel] pixmap problem

Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've
copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad
news is that now I am getting a command window opening up in addition to
the GUI window when the program runs.  This behavior does not occur on
v4.1.  The command window seems to be the stdout/stderr of the GUI
program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which
needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy

>>> Jay  5/5/2008 10:47 PM >>>
Randy, Yes.
The NT386 config files are all checked in.
You can use them verbatim. You don't need cminstall, I never use it,
and you shouldn't need to edit the config files at all, any edits I
make, I check in, and should be usable on all machines.
As long as you set %PATH%/%INCLUDE%/%LIB%.
If I'm wrong, I'd like to know why and try to fix.
 
Consider the config files just part of cm3.exe.
Not generally to be changed locally. Unless, well, unless you intend
to, and you should strive to make one form that is usable by all.
 
 - Jay


Date: Mon, 5 May 2008 22:42:30 -0400
From: rcoleburn at scires.com 
To: jayk123 at hotmail.com 
Subject: RE: [M3devel] pixmap problem

Jay,
When you say "took the updated config file", what do you mean?  Are you
saying I need a different cm3.cfg file?
Regards,
Randy

>>> Jay  5/5/2008 9:54 PM >>>
And you took the updated config file?
The way you can tell is that, roughly speaking, hand.obj should be in
NT386\_m3responsefile0.txt.
Or _m3responsefile1.txt, or, well, somewhere.
Anyway, I think I saw the attachment, I can check later..and with 4.1
as I said..
 
I can see about making the fix not depend on config file changes...but
it's not terrible asis, and I'd really like to merge more of the quake
code into cm3.exe..
 
 - Jay

Date: Mon, 5 May 2008 21:18:12 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com 
Subject: Re: [M3devel] pixmap problem

Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly
when the buildstandalone() directive is used.
 
Regards,
Randy

>>> Jay  5/5/2008 7:04 PM >>>
Thanks. I'll look into this tonight probably, as well as with 4.1
assuming I can find my binaries and source for it (probably).

COULD BE the pixmap problem is something else and 4.1 also has the
problem I fixed. We'll see. No need to speculate (unless I can't find my
4.1).

 - Jay


Date: Mon, 5 May 2008 10:59:27 -0400
From: rcoleburn at scires.com 
To: jayk123 at hotmail.com 
CC: m3devel at elegosoft.com 
Subject: RE: [M3devel] pixmap problem

Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files
or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy

>>> Jay  5/4/2008 11:46 AM >>>
Randy, Please try with /current/ source, as of this morning Sunday May
4 -- the changes are ALL in NT386.common, so you MUST use MY config
files, which are checked in verbatim, or you should be able edit
whatever config files you are using.
 
(It's not really a config file issue, don't blame the general confusion
people have with them.)
 
I'll try to try later, but I don't have the source right now, gotta
look on other machines, and I think it's on a machine on loan.
  Or send it to me again.
I'd also like to know if this worked with 4.1, or with any release that
offered dynamic linking to m3core.dll, on Windows.
  I recall a claim that it did. If today's change fixes it, I should be
able to investigate 4.1.
3.6 did not have such linking.
If today's change does not help, well, I still plan on debugging it at
some point..
 
If you aren't current and getting so is difficult, just send the
attachment again, it's easy for me to test.
 
Thanks,
 - Jay

From: jayk123 at hotmail.com 
To: hosking at cs.purdue.edu; rcoleburn at scires.com 
Date: Sat, 19 Jan 2008 08:52:08 +0000
CC: m3devel at elegosoft.com 
Subject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.
I was going to try on PPC_DARWIN but I guess Tony's info suffices.
 
I tried rolling hand.c back to before I changed (months/year ago),
since it is involved in bit twiddling, no change, phew.
 
Debugging here is a big humungous pain.
NT386 has good stacks and line numbers, but no locals or type info, I'd
really sometime like to get Codeview info into those .objs...I think it
is documented well enough, but still not necessarily easy, or maybe have
a C generating backend partly for this reason (and to bring up more
targets, using native tools), and function calls in disassembly I think
don't resolve; NT386GNU can't yet build this, though it will soon, but
I'm not familiar with gdb and there appears to be no type info. I'm
building m3gdb right now, I don't know if it will work, I hope it has
type info, and I'm not familiar with the relevant code. In gdb I
struggle just to view bytes in memory, add numbers to addresses and see
those, etc. I think for MY problem, I'm going to link in C code to dump
the structs. There is tracing code and I enabled it, but even it crashes
in Text_Length. At least MY problem crashes, hopefully near the problem,
whereas your problem goes all the way through to completion with no
stopping to hint where the problem is. Darn it. :) on the mock rudeness
and :( on the lack of a crash.
 
You write the bundle out and it matches, so that doesn't rule out
bundles as being the problem? (darn)
And bundles look pretty simple, a bundle is just a generated source
file with a constant in it.
Maybe newline problems? That wouldn't make sense. I just downloaded
some program that might let me separately view the ppm, maybe it'll
reveal something.
 
The bad behavior has like regularly spaced solid color veritical bars a
few pixels side across the whole picture, and regularly spaced vertical
stripes from the correct picture alternating with that. Perhaps someone
with ppm/bitmap/graphics experience has seen this behavior and it
results from some common pixmap mismanagement we could look for?
 
I have to say this is very surprising.
 
I always wondered, and now I pretty much assume -- Modula-3 never
imports/exports data in its dynamic linking, right? It alway
imports/exports functions, right?
On Windows, functions have an optional optimization, but data must be
handled differently at compile time if it is going to be dynamically
imported.
For functions, if you don't apply the optimization at compile time, the
linker will just generate a single instruction thunk instead.
 
That is, given a symbol Foo, there is a symbol __imp__Foo that is a
pointer to the actual foo in another .dll/.so.
The loader only patches pointers, one per import if you build your .dll
correctly, it doesn't patch instructions or code strewn throughout a
.dll, just one contiguous array of pointers. MAYBE they don't have to be
contiguous for each .dl you import from.
 
That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my
.dll/.exe typically has an array:
 
pointer to msvcrt!fopen
pointer to msvcrt!fclose
null
pointer to kernel32!Sleep
 
But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not
be adjacent.
 
So, going back, my point/question is that, if the compiler knows the
function is imported, it can call through __imp__Foo instead of calling
Foo.
But if it calls Foo and you import Foo, the linker will create the
function Foo that just jmps through __imp__Foo.
That doesn't work for data though. There's no ability to intervenve
like that.
So for imported data, the compiler must generated a read and
dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to
be imported.
Data imports may be faster when appropriate, but for this reason, I'd
say they aren't worth it.
And for this reason, I HOPE Modula-3 never imports/exports data.
 
Oh, you could, for data, always reference the pointer __imp_Foo, and if
non materializes, create one.
However that would suck perf in order to make an uncommon case work.
I hope Modula-3 doesn't do that either. :)
Though I guess since this global data in question...maybe it is
rare???
 
Later,
 - Jay



> From: hosking at cs.purdue.edu 
> Date: Sat, 19 Jan 2008 03:09:47 -0500
> To: rcoleburn at scires.com 
> CC: m3devel at elegosoft.com 
> Subject: Re: [M3devel] pixmap problem
> 
> Looks fine to me on I386_DARWIN.
> 
> On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:
> 
> > 
> 


Need to know the score, the latest news, or you need your Hotmail*-get
your "fix" Check it out. ( http://www.msnmobilefix.com/Default.aspx ) 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Sat May 10 11:24:31 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Sat, 10 May 2008 05:24:31 -0400
Subject: [M3devel] NT386 environment variables (new NT386	snapshots)
References: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
	
	<4823279D.1E75.00D7.1@scires.com>
	
	<482528BA.1E75.00D7.1@scires.com>
Message-ID: <4825318A.1E75.00D7.1@scires.com>

Jay:
 
Here are my results using the program you supplied:
 
1.  cm3 v4.1, VS 2005, GUI mode, get a pop-up dos window, but program crashes
 
2.  cm3 v4.1, VS 2005, console mode, program crashes
 
3.  cm3 v.d5.7.0, VS 2008 GUI mode, get a pop-up window but it disappears too fast to see any contents
 
4.  cm3 v.d5.7.0, VS 2008 console mode, program crashes
 
Regards,
Randy

>>> Jay  5/9/2008 3:44 AM >>>
 > these problems (pixmaps, buildstandalone, environ vars, serial i/o, etc...
 
 Ok, here is the story with environment variables.

I tested 3.6 and current, gui and console.

This is the program:

C:\dev2\j\m3\3>type src\m3makefile

import ("m3core")
import ("libm3")
m3_option ("-gui")     twiddle this line in and out with a comment
implementation ("Main")
program ("pgm")
 
C:\dev2\j\m3\3>type src\Main.m3
MODULE Main;
IMPORT IO;
IMPORT RTArgs;
 
BEGIN
(* IO.Put just crashes in 3.6 gui apps *)
  IO.Put(RTArgs.GetArg(2));
  IO.Put(RTArgs.GetEnv(2));
 
(* use this for gui apps *)
  EVAL RTArgs.GetArg(2);
  EVAL RTArgs.GetEnv(2);
END Main.

In 3.6 console apps, RTArgs.GetEnv returns garbage. That makes sense from the code.
In current console apps, GetEnv works.
In current gui apps, GetEnv access violates, or returns an invalid pointer.
  This also makes sense from the code.

Randy, does this actually work for you?
I'd be quite surprised.
I haven't tried 4.1 yet, just 3.6 and current.

I will apply an easy fix.

 - Jay

Date: Thu, 8 May 2008 16:17:37 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com 
Subject: Re: [M3devel] new NT386 snapshots

Jay:
 
I have both console and gui programs built using 4.1 that do pull stuff out of the environment.  I've not noticed any problems with either mode.
 
>From my perspective, the old 4.1 seems more reliable than the current system in a number of respects.  I have a new project with a hard deadline that I would like to use the new cm3 system for, but until these problems (pixmaps, buildstandalone, environ vars, serial i/o, etc.) can be resolved, I'm going to keep using 4.1 for my production work.
 
Regards,
Randy

>>> Jay  5/8/2008 2:46 PM >>>
http://modula3.elegosoft.com/cm3/uploaded-archives/ 
 
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0.zip 
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-WIN32-NT386-d5.7.0.zip 
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0-symbols.zip 
 
These should have:
  latest quake extensions 
  set relation fixes 
  other set fixes revealed through dynamic linking of one regression test 
  hypothetical ability to cross-build to AMD64_LINUX, AMD64_DARWIN  
  one jmpbuf size for all NT386 configurations (NT386, NT386GNU, NT386MINGNU) 
 
Built with Visual C++ 9.0 Express, so you'll want:
http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en 
 
 
Still more work to do though, e.g. assertion failures in unit tests, pixmap..
 
Fuller disclosure:
Something is leaking memory on my system such that "everything" starts "failing" and I have to reboot.
This isn't Modula-3 related.
Hopefully these files aren't damaged as a result.
Must be some buggy driver or something..
 
Aside:
 The environment variable thingy has been bugging me a long time and I finally looked deeper at it.
It appears broken in CM3 4.x. I didn't check 3.x yet.
I'm still mulling a fix, and haven't run a repro of the break, but it's not a big deal either way.
Basically console apps use main that takes char** and gui apps use WinMain that doesn't get environment variables but the generated code calls GetEvironmentStrings() which returns null separated strings.
Must be that hardly anyone uses environment variables in Modula-3 on Win32 for this to have lingered so long, at least gui apps.
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sat May 10 11:38:30 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 10 May 2008 09:38:30 +0000
Subject: [M3devel] pixmap problem
In-Reply-To: <48253152.1E75.00D7.1@scires.com>
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	
	<481F9804.1E75.00D7.1@scires.com><481F9804.1E75.00D7.1@scires.com>
	
	<482529C7.1E75.00D7.1@scires.com>  <48253152.1E75.00D7.1@scires.com>
Message-ID: 

Randy, clarification, the bug occured when NOT building standalone.
You must know that, since you reproed it recently.
Just try both ways, both should work.
 
(You don't have to take my cm3.cfg, but you do need NT386.common, and then either copy NT386 to cm3.cfg, or take NT386 and have cm3.cfg be just one line, include("NT386"))
 
Any reason left for you to stick with 4.1? :)
Something with serialio?
 
At least one question does remain -- the TestPixmap behavior and why on 4.1.
I'll look into that shortly.
3.6 isn't relevant, since it didn't have .dlls.
 
Thanks,
 - Jay


Date: Sat, 10 May 2008 05:23:35 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem

Jay:
 
I've performed the following and it seems to have fixed the problem with the TestPixmap program when built standalone:
 
1.  performed CVS update
2.  updated cm3.cfg and NT386* in \cm3\bin based on sources in cminstall\config
3.  scripts\win\upgrade
4.  scripts\win\do-cm3-std buildship
 
I checked the .lst file and I am now seeing "hand.obj"
 
Regards,
Randy>>> "Randy Coleburn"  5/10/2008 4:51 AM >>>
Jay:
 
I do not have python installed on my computer, so I can't run your scripts.
 
I used the scripts in scripts\win to upgrade a few days ago.
 
I am not seeing hand.obj in the .lst file.
 
I will do a CVS update and try the upgrade again followed by do-cm3-standard.
 
Regards,
Randy>>> Jay  5/9/2008 5:10 AM >>>
 > Also, more bad news, the pixmap problem is not solved. Randy, this DOES actually fix it, but you have to rebuild more. Try:   cd scripts\python    .\do-cm3-std.py realclean    .\upgrade.py   (probably not needed)    do-cm3-std.py buildship   Make sure "hand.obj" occurs in the various NT386\foo.lst files. I think the fix should be restated to have the code reference *__imp__highbits instead of highbits, and go back to dynamic linking the data.But ok for now. The std distribution I put yesterday should work, though it is missing the RTArgs fix.I'll see about making another.   - Jay


Date: Mon, 5 May 2008 23:28:10 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad news is that now I am getting a command window opening up in addition to the GUI window when the program runs.  This behavior does not occur on v4.1.  The command window seems to be the stdout/stderr of the GUI program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy>>> Jay  5/5/2008 10:47 PM >>>Randy, Yes.The NT386 config files are all checked in.You can use them verbatim. You don't need cminstall, I never use it, and you shouldn't need to edit the config files at all, any edits I make, I check in, and should be usable on all machines.As long as you set %PATH%/%INCLUDE%/%LIB%.If I'm wrong, I'd like to know why and try to fix. Consider the config files just part of cm3.exe.Not generally to be changed locally. Unless, well, unless you intend to, and you should strive to make one form that is usable by all.  - Jay


Date: Mon, 5 May 2008 22:42:30 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay,
When you say "took the updated config file", what do you mean?  Are you saying I need a different cm3.cfg file?
Regards,
Randy>>> Jay  5/5/2008 9:54 PM >>>And you took the updated config file?The way you can tell is that, roughly speaking, hand.obj should be in NT386\_m3responsefile0.txt.Or _m3responsefile1.txt, or, well, somewhere.Anyway, I think I saw the attachment, I can check later..and with 4.1 as I said.. I can see about making the fix not depend on config file changes...but it's not terrible asis, and I'd really like to merge more of the quake code into cm3.exe..  - Jay


Date: Mon, 5 May 2008 21:18:12 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem
Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly when the buildstandalone() directive is used.
 
Regards,
Randy>>> Jay  5/5/2008 7:04 PM >>>Thanks. I'll look into this tonight probably, as well as with 4.1 assuming I can find my binaries and source for it (probably).COULD BE the pixmap problem is something else and 4.1 also has the problem I fixed. We'll see. No need to speculate (unless I can't find my 4.1). - Jay


Date: Mon, 5 May 2008 10:59:27 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problem
Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy>>> Jay  5/4/2008 11:46 AM >>>Randy, Please try with /current/ source, as of this morning Sunday May 4 -- the changes are ALL in NT386.common, so you MUST use MY config files, which are checked in verbatim, or you should be able edit whatever config files you are using. (It's not really a config file issue, don't blame the general confusion people have with them.) I'll try to try later, but I don't have the source right now, gotta look on other machines, and I think it's on a machine on loan.  Or send it to me again.I'd also like to know if this worked with 4.1, or with any release that offered dynamic linking to m3core.dll, on Windows.  I recall a claim that it did. If today's change fixes it, I should be able to investigate 4.1.3.6 did not have such linking.If today's change does not help, well, I still plan on debugging it at some point.. If you aren't current and getting so is difficult, just send the attachment again, it's easy for me to test. Thanks, - Jay


From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rcoleburn at scires.comDate: Sat, 19 Jan 2008 08:52:08 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.I was going to try on PPC_DARWIN but I guess Tony's info suffices. I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. Debugging here is a big humungous pain.NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)And bundles look pretty simple, a bundle is just a generated source file with a constant in it.Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something. The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for? I have to say this is very surprising. I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so.The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: pointer to msvcrt!fopenpointer to msvcrt!fclosenullpointer to kernel32!Sleep But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo.But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo.That doesn't work for data though. There's no ability to intervenve like that.So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it.And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.However that would suck perf in order to make an uncommon case work.I hope Modula-3 doesn't do that either. :)Though I guess since this global data in question...maybe it is rare??? Later, - Jay

> From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 03:09:47 -0500> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] pixmap problem> > Looks fine to me on I386_DARWIN.> > On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:> > > > 

Need to know the score, the latest news, or you need your Hotmail?-get your "fix" Check it out. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sat May 10 11:43:45 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 10 May 2008 09:43:45 +0000
Subject: [M3devel] NT386 environment variables (new NT386	snapshots)
In-Reply-To: <4825318A.1E75.00D7.1@scires.com>
References: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
	
	<4823279D.1E75.00D7.1@scires.com>
	
	<482528BA.1E75.00D7.1@scires.com>  <4825318A.1E75.00D7.1@scires.com>
Message-ID: 

Randy,You can make the popup stick around easily enough, put in WinBase.Sleep(10000), or maybe run under a debugger.
For 5.7 to work, you need the very recent fix to RTArgs.m3 AND you need to pass a few parameters to the test program, like
NT386\pgm abc def ghi
 
 - Jay


Date: Sat, 10 May 2008 05:24:31 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] NT386 environment variables (new NT386 snapshots)

Jay:
 
Here are my results using the program you supplied:
 
1.  cm3 v4.1, VS 2005, GUI mode, get a pop-up dos window, but program crashes
 
2.  cm3 v4.1, VS 2005, console mode, program crashes
 
3.  cm3 v.d5.7.0, VS 2008 GUI mode, get a pop-up window but it disappears too fast to see any contents
 
4.  cm3 v.d5.7.0, VS 2008 console mode, program crashes
 
Regards,
Randy>>> Jay  5/9/2008 3:44 AM >>> > these problems (pixmaps, buildstandalone, environ vars, serial i/o, etc...  Ok, here is the story with environment variables.I tested 3.6 and current, gui and console.This is the program:C:\dev2\j\m3\3>type src\m3makefileimport ("m3core")import ("libm3")m3_option ("-gui")     twiddle this line in and out with a commentimplementation ("Main")program ("pgm") C:\dev2\j\m3\3>type src\Main.m3MODULE Main;IMPORT IO;IMPORT RTArgs; BEGIN(* IO.Put just crashes in 3.6 gui apps *)  IO.Put(RTArgs.GetArg(2));  IO.Put(RTArgs.GetEnv(2)); (* use this for gui apps *)  EVAL RTArgs.GetArg(2);  EVAL RTArgs.GetEnv(2);END Main.In 3.6 console apps, RTArgs.GetEnv returns garbage. That makes sense from the code.In current console apps, GetEnv works.In current gui apps, GetEnv access violates, or returns an invalid pointer.  This also makes sense from the code.Randy, does this actually work for you?I'd be quite surprised.I haven't tried 4.1 yet, just 3.6 and current.I will apply an easy fix. - Jay


Date: Thu, 8 May 2008 16:17:37 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] new NT386 snapshots
Jay:
 
I have both console and gui programs built using 4.1 that do pull stuff out of the environment.  I've not noticed any problems with either mode.
 
>From my perspective, the old 4.1 seems more reliable than the current system in a number of respects.  I have a new project with a hard deadline that I would like to use the new cm3 system for, but until these problems (pixmaps, buildstandalone, environ vars, serial i/o, etc.) can be resolved, I'm going to keep using 4.1 for my production work.
 
Regards,
Randy>>> Jay  5/8/2008 2:46 PM >>>http://modula3.elegosoft.com/cm3/uploaded-archives/ http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0.ziphttp://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-WIN32-NT386-d5.7.0.ziphttp://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0-symbols.zip These should have:  latest quake extensions   set relation fixes   other set fixes revealed through dynamic linking of one regression test   hypothetical ability to cross-build to AMD64_LINUX, AMD64_DARWIN    one jmpbuf size for all NT386 configurations (NT386, NT386GNU, NT386MINGNU)  Built with Visual C++ 9.0 Express, so you'll want:http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en  Still more work to do though, e.g. assertion failures in unit tests, pixmap.. Fuller disclosure:Something is leaking memory on my system such that "everything" starts "failing" and I have to reboot.This isn't Modula-3 related.Hopefully these files aren't damaged as a result.Must be some buggy driver or something.. Aside: The environment variable thingy has been bugging me a long time and I finally looked deeper at it.It appears broken in CM3 4.x. I didn't check 3.x yet.I'm still mulling a fix, and haven't run a repro of the break, but it's not a big deal either way.Basically console apps use main that takes char** and gui apps use WinMain that doesn't get environment variables but the generated code calls GetEvironmentStrings() which returns null separated strings.Must be that hardly anyone uses environment variables in Modula-3 on Win32 for this to have lingered so long, at least gui apps.  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Sat May 10 11:46:16 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Sat, 10 May 2008 05:46:16 -0400
Subject: [M3devel] NT386 environment variables (new	NT386	snapshots)
In-Reply-To: 
References: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
	
	<4823279D.1E75.00D7.1@scires.com>
	
	<482528BA.1E75.00D7.1@scires.com>
	
Message-ID: <482536A3.1E75.00D7.1@scires.com>

Jay:
 
Ok, I've added the sleep.
Here are the new results using my newly rebuilt cm3 and my old v4.1:
 
v4.1:  pgm.exe @M3novm abc def ghi
v5.7:  pgm.exe abc def ghi
 
1.  cm3 4.1, VS 2005, GUI mode, popup with runtime error crash message
 
2.  cm3 4.1, VS 2005, console mode, no popup, output shows "def*5;"
 
3.  cm3 d5.7.0, VS 2008, GUI mode, popup with output shows
"def=ExitCode=00000000"
 
4.  cm3 d5.7.0, VS 2008, console mode, no popup with output shows
"def=ExitCode=00000000"
 
Regards,
Randy

>>> Jay  5/10/2008 5:04 AM >>>
Randy,
You can make the popup stick around, put in WinBase.Sleep(10000), or
run under a debugger.
Since 5.7 is crashing, I assume you don't have the fix I very recently
commited? Or the last point.
I assume if 5.7 doesn't crash, you are satisfied.
 
I forgot to tell you -- make sure you pass a few command line options
to the program, like
 
NT386\pgm.exe abc def ghi.
 
 - Jay

Date: Sat, 10 May 2008 04:46:54 -0400
From: rcoleburn at scires.com 
To: jayk123 at hotmail.com 
Subject: RE: [M3devel] NT386 environment variables (new NT386
snapshots)

Jay:
 
Here are my results using the program you supplied:
 
1.  cm3 v4.1, VS 2005, GUI mode, get a pop-up dos window, but program
crashes
 
2.  cm3 v4.1, VS 2005, console mode, program crashes
 
3.  cm3 v.d5.7.0, VS 2008 GUI mode, get a pop-up window but it
disappears too fast to see any contents
 
4.  cm3 v.d5.7.0, VS 2008 console mode, program crashes
 
Regards,
Randy

>>> Jay  5/9/2008 3:44 AM >>>
 > these problems (pixmaps, buildstandalone, environ vars, serial i/o,
etc...
 
 Ok, here is the story with environment variables.

I tested 3.6 and current, gui and console.

This is the program:

C:\dev2\j\m3\3>type src\m3makefile

import ("m3core")
import ("libm3")
m3_option ("-gui")     twiddle this line in and out with a comment
implementation ("Main")
program ("pgm")
 
C:\dev2\j\m3\3>type src\Main.m3
MODULE Main;
IMPORT IO;
IMPORT RTArgs;
 
BEGIN
(* IO.Put just crashes in 3.6 gui apps *)
  IO.Put(RTArgs.GetArg(2));
  IO.Put(RTArgs.GetEnv(2));
 
(* use this for gui apps *)
  EVAL RTArgs.GetArg(2);
  EVAL RTArgs.GetEnv(2);
END Main.

In 3.6 console apps, RTArgs.GetEnv returns garbage. That makes sense
from the code.
In current console apps, GetEnv works.
In current gui apps, GetEnv access violates, or returns an invalid
pointer.
  This also makes sense from the code.

Randy, does this actually work for you?
I'd be quite surprised.
I haven't tried 4.1 yet, just 3.6 and current.

I will apply an easy fix.

 - Jay

Date: Thu, 8 May 2008 16:17:37 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com 
Subject: Re: [M3devel] new NT386 snapshots

Jay:
 
I have both console and gui programs built using 4.1 that do pull stuff
out of the environment.  I've not noticed any problems with either
mode.
 
>From my perspective, the old 4.1 seems more reliable than the current
system in a number of respects.  I have a new project with a hard
deadline that I would like to use the new cm3 system for, but until
these problems (pixmaps, buildstandalone, environ vars, serial i/o,
etc.) can be resolved, I'm going to keep using 4.1 for my production
work.
 
Regards,
Randy

>>> Jay  5/8/2008 2:46 PM >>>
http://modula3.elegosoft.com/cm3/uploaded-archives/ 
 
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0.zip

http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-WIN32-NT386-d5.7.0.zip

http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0-symbols.zip

 
These should have:
  latest quake extensions 
  set relation fixes 
  other set fixes revealed through dynamic linking of one regression
test 
  hypothetical ability to cross-build to AMD64_LINUX, AMD64_DARWIN  
  one jmpbuf size for all NT386 configurations (NT386, NT386GNU,
NT386MINGNU) 
 
Built with Visual C++ 9.0 Express, so you'll want:
http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en

 
 
Still more work to do though, e.g. assertion failures in unit tests,
pixmap..
 
Fuller disclosure:
Something is leaking memory on my system such that "everything" starts
"failing" and I have to reboot.
This isn't Modula-3 related.
Hopefully these files aren't damaged as a result.
Must be some buggy driver or something..
 
Aside:
 The environment variable thingy has been bugging me a long time and I
finally looked deeper at it.
It appears broken in CM3 4.x. I didn't check 3.x yet.
I'm still mulling a fix, and haven't run a repro of the break, but it's
not a big deal either way.
Basically console apps use main that takes char** and gui apps use
WinMain that doesn't get environment variables but the generated code
calls GetEvironmentStrings() which returns null separated strings.
Must be that hardly anyone uses environment variables in Modula-3 on
Win32 for this to have lingered so long, at least gui apps.
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sat May 10 12:01:09 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 10 May 2008 10:01:09 +0000
Subject: [M3devel] NT386 environment variables (new	NT386	snapshots)
In-Reply-To: <482536A3.1E75.00D7.1@scires.com>
References: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
	
	<4823279D.1E75.00D7.1@scires.com>
	
	<482528BA.1E75.00D7.1@scires.com>
	 
	<482536A3.1E75.00D7.1@scires.com>
Message-ID: 

 > I have both console and gui programs built using 4.1 that do pull stuff out of the environment.
I assume you weren't using RTArgs?
 
Everything good, move along?
 
(Not "everything", there are still m3tests failures..though I guess -- maybe also try them with 3.6, 4.1, 5.1...)
 
 - Jay


Date: Sat, 10 May 2008 05:46:16 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] NT386 environment variables (new NT386 snapshots)

Jay:
 
Ok, I've added the sleep.
Here are the new results using my newly rebuilt cm3 and my old v4.1:
 
v4.1:  pgm.exe @M3novm abc def ghi

v5.7:  pgm.exe abc def ghi
 
1.  cm3 4.1, VS 2005, GUI mode, popup with runtime error crash message
 
2.  cm3 4.1, VS 2005, console mode, no popup, output shows "def?5;"
 
3.  cm3 d5.7.0, VS 2008, GUI mode, popup with output shows "def=ExitCode=00000000"
 
4.  cm3 d5.7.0, VS 2008, console mode, no popup with output shows "def=ExitCode=00000000"
 
Regards,
Randy>>> Jay  5/10/2008 5:04 AM >>>Randy,You can make the popup stick around, put in WinBase.Sleep(10000), or run under a debugger.Since 5.7 is crashing, I assume you don't have the fix I very recently commited? Or the last point.I assume if 5.7 doesn't crash, you are satisfied. I forgot to tell you -- make sure you pass a few command line options to the program, like NT386\pgm.exe abc def ghi.  - Jay


Date: Sat, 10 May 2008 04:46:54 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comSubject: RE: [M3devel] NT386 environment variables (new NT386 snapshots)
Jay:
 
Here are my results using the program you supplied:
 
1.  cm3 v4.1, VS 2005, GUI mode, get a pop-up dos window, but program crashes
 
2.  cm3 v4.1, VS 2005, console mode, program crashes
 
3.  cm3 v.d5.7.0, VS 2008 GUI mode, get a pop-up window but it disappears too fast to see any contents
 
4.  cm3 v.d5.7.0, VS 2008 console mode, program crashes
 
Regards,
Randy>>> Jay  5/9/2008 3:44 AM >>> > these problems (pixmaps, buildstandalone, environ vars, serial i/o, etc...  Ok, here is the story with environment variables.I tested 3.6 and current, gui and console.This is the program:C:\dev2\j\m3\3>type src\m3makefileimport ("m3core")import ("libm3")m3_option ("-gui")     twiddle this line in and out with a commentimplementation ("Main")program ("pgm") C:\dev2\j\m3\3>type src\Main.m3MODULE Main;IMPORT IO;IMPORT RTArgs; BEGIN(* IO.Put just crashes in 3.6 gui apps *)  IO.Put(RTArgs.GetArg(2));  IO.Put(RTArgs.GetEnv(2)); (* use this for gui apps *)  EVAL RTArgs.GetArg(2);  EVAL RTArgs.GetEnv(2);END Main.In 3.6 console apps, RTArgs.GetEnv returns garbage. That makes sense from the code.In current console apps, GetEnv works.In current gui apps, GetEnv access violates, or returns an invalid pointer.  This also makes sense from the code.Randy, does this actually work for you?I'd be quite surprised.I haven't tried 4.1 yet, just 3.6 and current.I will apply an easy fix. - Jay


Date: Thu, 8 May 2008 16:17:37 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] new NT386 snapshots
Jay:
 
I have both console and gui programs built using 4.1 that do pull stuff out of the environment.  I've not noticed any problems with either mode.
 
>From my perspective, the old 4.1 seems more reliable than the current system in a number of respects.  I have a new project with a hard deadline that I would like to use the new cm3 system for, but until these problems (pixmaps, buildstandalone, environ vars, serial i/o, etc.) can be resolved, I'm going to keep using 4.1 for my production work.
 
Regards,
Randy>>> Jay  5/8/2008 2:46 PM >>>http://modula3.elegosoft.com/cm3/uploaded-archives/ http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0.ziphttp://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-WIN32-NT386-d5.7.0.ziphttp://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0-symbols.zip These should have:  latest quake extensions   set relation fixes   other set fixes revealed through dynamic linking of one regression test   hypothetical ability to cross-build to AMD64_LINUX, AMD64_DARWIN    one jmpbuf size for all NT386 configurations (NT386, NT386GNU, NT386MINGNU)  Built with Visual C++ 9.0 Express, so you'll want:http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en  Still more work to do though, e.g. assertion failures in unit tests, pixmap.. Fuller disclosure:Something is leaking memory on my system such that "everything" starts "failing" and I have to reboot.This isn't Modula-3 related.Hopefully these files aren't damaged as a result.Must be some buggy driver or something.. Aside: The environment variable thingy has been bugging me a long time and I finally looked deeper at it.It appears broken in CM3 4.x. I didn't check 3.x yet.I'm still mulling a fix, and haven't run a repro of the break, but it's not a big deal either way.Basically console apps use main that takes char** and gui apps use WinMain that doesn't get environment variables but the generated code calls GetEvironmentStrings() which returns null separated strings.Must be that hardly anyone uses environment variables in Modula-3 on Win32 for this to have lingered so long, at least gui apps.  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Sat May 10 12:05:02 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Sat, 10 May 2008 06:05:02 -0400
Subject: [M3devel] pixmap problem
In-Reply-To: 
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	
	<481F9804.1E75.00D7.1@scires.com><481F9804.1E75.00D7.1@scires.com>
	
	<482529C7.1E75.00D7.1@scires.com>
	<48253152.1E75.00D7.1@scires.com><48253152.1E75.00D7.1@scires.com>
	
Message-ID: <48253B09.1E75.00D7.1@scires.com>

Jay:
 
I get correct behavior now for TestPixmap on d5.7 when built either
way, with or without standalone option.
THANKS!
 
On 4.1, TestPixmap also works both ways.  The problem was occurring
before your fix on d5.7 (and on earlier releases after 4.1).  Not sure
what your fix does or what changed from 4.1 to d5.7 that made your fix
necessary.
 
I am using your NT386 stuff for cm3.cfg now.
 
I don't have 3.6.
 
I will need to run tests now with d5.7 against my programs to see if
they are working correctly before I can abandon 4.1.  Also, we will need
to drive a stake in the ground at some point soon to create an official
5.7 release.  My company will want to be able to point to a given
development environment for future support of the product I'm working
on.  They won't accept a "d5.7" release that is in a state of flux.
 
Also, the other issue I'll have to work is getting all the GUI changes
incorporated into this edition.  We will need the custom look&feel that
CMass put together for us.  I'll check into it.  If I am successful, I
can create a branch on CVS with this edition in case anyone else wants
it.
 
Regards,
Randy

>>> Jay  5/10/2008 5:38 AM >>>
Randy, clarification, the bug occured when NOT building standalone.
You must know that, since you reproed it recently.
Just try both ways, both should work.
 
(You don't have to take my cm3.cfg, but you do need NT386.common, and
then either copy NT386 to cm3.cfg, or take NT386 and have cm3.cfg be
just one line, include("NT386"))
 
Any reason left for you to stick with 4.1? :)
Something with serialio?
 
At least one question does remain -- the TestPixmap behavior and why on
4.1.
I'll look into that shortly.
3.6 isn't relevant, since it didn't have .dlls.
 
Thanks,
 - Jay
Date: Sat, 10 May 2008 05:23:35 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com 
Subject: Re: [M3devel] pixmap problem

Jay:
 
I've performed the following and it seems to have fixed the problem
with the TestPixmap program when built standalone:
 
1.  performed CVS update
2.  updated cm3.cfg and NT386* in \cm3\bin based on sources in
cminstall\config
3.  scripts\win\upgrade
4.  scripts\win\do-cm3-std buildship
 
I checked the .lst file and I am now seeing "hand.obj"
 
Regards,
Randy

>>> "Randy Coleburn"  5/10/2008 4:51 AM >>>
Jay:
 
I do not have python installed on my computer, so I can't run your
scripts.
 
I used the scripts in scripts\win to upgrade a few days ago.
 
I am not seeing hand.obj in the .lst file.
 
I will do a CVS update and try the upgrade again followed by
do-cm3-standard.
 
Regards,
Randy

>>> Jay  5/9/2008 5:10 AM >>>
 > Also, more bad news, the pixmap problem is not solved.
 
Randy, this DOES actually fix it, but you have to rebuild more.
 
Try:
   cd scripts\python  
  .\do-cm3-std.py realclean  
  .\upgrade.py   (probably not needed) 
   do-cm3-std.py buildship  
 
Make sure "hand.obj" occurs in the various NT386\foo.lst files.
 
I think the fix should be restated to have the code reference
*__imp__highbits instead of highbits, and go back to dynamic linking the
data.
But ok for now.
 
The std distribution I put yesterday should work, though it is missing
the RTArgs fix.
I'll see about making another.
 
  - Jay

Date: Mon, 5 May 2008 23:28:10 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com; jayk123 at hotmail.com 
Subject: RE: [M3devel] pixmap problem

Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've
copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad
news is that now I am getting a command window opening up in addition to
the GUI window when the program runs.  This behavior does not occur on
v4.1.  The command window seems to be the stdout/stderr of the GUI
program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which
needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy

>>> Jay  5/5/2008 10:47 PM >>>
Randy, Yes.
The NT386 config files are all checked in.
You can use them verbatim. You don't need cminstall, I never use it,
and you shouldn't need to edit the config files at all, any edits I
make, I check in, and should be usable on all machines.
As long as you set %PATH%/%INCLUDE%/%LIB%.
If I'm wrong, I'd like to know why and try to fix.
 
Consider the config files just part of cm3.exe.
Not generally to be changed locally. Unless, well, unless you intend
to, and you should strive to make one form that is usable by all.
 
 - Jay


Date: Mon, 5 May 2008 22:42:30 -0400
From: rcoleburn at scires.com 
To: jayk123 at hotmail.com 
Subject: RE: [M3devel] pixmap problem

Jay,
When you say "took the updated config file", what do you mean?  Are you
saying I need a different cm3.cfg file?
Regards,
Randy

>>> Jay  5/5/2008 9:54 PM >>>
And you took the updated config file?
The way you can tell is that, roughly speaking, hand.obj should be in
NT386\_m3responsefile0.txt.
Or _m3responsefile1.txt, or, well, somewhere.
Anyway, I think I saw the attachment, I can check later..and with 4.1
as I said..
 
I can see about making the fix not depend on config file changes...but
it's not terrible asis, and I'd really like to merge more of the quake
code into cm3.exe..
 
 - Jay

Date: Mon, 5 May 2008 21:18:12 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com 
Subject: Re: [M3devel] pixmap problem

Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly
when the buildstandalone() directive is used.
 
Regards,
Randy

>>> Jay  5/5/2008 7:04 PM >>>
Thanks. I'll look into this tonight probably, as well as with 4.1
assuming I can find my binaries and source for it (probably).

COULD BE the pixmap problem is something else and 4.1 also has the
problem I fixed. We'll see. No need to speculate (unless I can't find my
4.1).

 - Jay


Date: Mon, 5 May 2008 10:59:27 -0400
From: rcoleburn at scires.com 
To: jayk123 at hotmail.com 
CC: m3devel at elegosoft.com 
Subject: RE: [M3devel] pixmap problem

Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files
or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy

>>> Jay  5/4/2008 11:46 AM >>>
Randy, Please try with /current/ source, as of this morning Sunday May
4 -- the changes are ALL in NT386.common, so you MUST use MY config
files, which are checked in verbatim, or you should be able edit
whatever config files you are using.
 
(It's not really a config file issue, don't blame the general confusion
people have with them.)
 
I'll try to try later, but I don't have the source right now, gotta
look on other machines, and I think it's on a machine on loan.
  Or send it to me again.
I'd also like to know if this worked with 4.1, or with any release that
offered dynamic linking to m3core.dll, on Windows.
  I recall a claim that it did. If today's change fixes it, I should be
able to investigate 4.1.
3.6 did not have such linking.
If today's change does not help, well, I still plan on debugging it at
some point..
 
If you aren't current and getting so is difficult, just send the
attachment again, it's easy for me to test.
 
Thanks,
 - Jay

From: jayk123 at hotmail.com 
To: hosking at cs.purdue.edu; rcoleburn at scires.com 
Date: Sat, 19 Jan 2008 08:52:08 +0000
CC: m3devel at elegosoft.com 
Subject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.
I was going to try on PPC_DARWIN but I guess Tony's info suffices.
 
I tried rolling hand.c back to before I changed (months/year ago),
since it is involved in bit twiddling, no change, phew.
 
Debugging here is a big humungous pain.
NT386 has good stacks and line numbers, but no locals or type info, I'd
really sometime like to get Codeview info into those .objs...I think it
is documented well enough, but still not necessarily easy, or maybe have
a C generating backend partly for this reason (and to bring up more
targets, using native tools), and function calls in disassembly I think
don't resolve; NT386GNU can't yet build this, though it will soon, but
I'm not familiar with gdb and there appears to be no type info. I'm
building m3gdb right now, I don't know if it will work, I hope it has
type info, and I'm not familiar with the relevant code. In gdb I
struggle just to view bytes in memory, add numbers to addresses and see
those, etc. I think for MY problem, I'm going to link in C code to dump
the structs. There is tracing code and I enabled it, but even it crashes
in Text_Length. At least MY problem crashes, hopefully near the problem,
whereas your problem goes all the way through to completion with no
stopping to hint where the problem is. Darn it. :) on the mock rudeness
and :( on the lack of a crash.
 
You write the bundle out and it matches, so that doesn't rule out
bundles as being the problem? (darn)
And bundles look pretty simple, a bundle is just a generated source
file with a constant in it.
Maybe newline problems? That wouldn't make sense. I just downloaded
some program that might let me separately view the ppm, maybe it'll
reveal something.
 
The bad behavior has like regularly spaced solid color veritical bars a
few pixels side across the whole picture, and regularly spaced vertical
stripes from the correct picture alternating with that. Perhaps someone
with ppm/bitmap/graphics experience has seen this behavior and it
results from some common pixmap mismanagement we could look for?
 
I have to say this is very surprising.
 
I always wondered, and now I pretty much assume -- Modula-3 never
imports/exports data in its dynamic linking, right? It alway
imports/exports functions, right?
On Windows, functions have an optional optimization, but data must be
handled differently at compile time if it is going to be dynamically
imported.
For functions, if you don't apply the optimization at compile time, the
linker will just generate a single instruction thunk instead.
 
That is, given a symbol Foo, there is a symbol __imp__Foo that is a
pointer to the actual foo in another .dll/.so.
The loader only patches pointers, one per import if you build your .dll
correctly, it doesn't patch instructions or code strewn throughout a
.dll, just one contiguous array of pointers. MAYBE they don't have to be
contiguous for each .dl you import from.
 
That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my
.dll/.exe typically has an array:
 
pointer to msvcrt!fopen
pointer to msvcrt!fclose
null
pointer to kernel32!Sleep
 
But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not
be adjacent.
 
So, going back, my point/question is that, if the compiler knows the
function is imported, it can call through __imp__Foo instead of calling
Foo.
But if it calls Foo and you import Foo, the linker will create the
function Foo that just jmps through __imp__Foo.
That doesn't work for data though. There's no ability to intervenve
like that.
So for imported data, the compiler must generated a read and
dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to
be imported.
Data imports may be faster when appropriate, but for this reason, I'd
say they aren't worth it.
And for this reason, I HOPE Modula-3 never imports/exports data.
 
Oh, you could, for data, always reference the pointer __imp_Foo, and if
non materializes, create one.
However that would suck perf in order to make an uncommon case work.
I hope Modula-3 doesn't do that either. :)
Though I guess since this global data in question...maybe it is
rare???
 
Later,
 - Jay



> From: hosking at cs.purdue.edu 
> Date: Sat, 19 Jan 2008 03:09:47 -0500
> To: rcoleburn at scires.com 
> CC: m3devel at elegosoft.com 
> Subject: Re: [M3devel] pixmap problem
> 
> Looks fine to me on I386_DARWIN.
> 
> On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:
> 
> > 
> 


Need to know the score, the latest news, or you need your Hotmail*-get
your "fix" Check it out. ( http://www.msnmobilefix.com/Default.aspx ) 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Sat May 10 12:14:46 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Sat, 10 May 2008 06:14:46 -0400
Subject: [M3devel] NT386 environment variables	(new	NT386	snapshots)
In-Reply-To: 
References: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
	
	<4823279D.1E75.00D7.1@scires.com>
	
	<482528BA.1E75.00D7.1@scires.com>
	
	<482536A3.1E75.00D7.1@scires.com><482536A3.1E75.00D7.1@scires.com>
	
Message-ID: <48253D51.1E75.00D7.1@scires.com>

Jay:
 
No, I don't think I was using RTArgs.  I was using Env.Get().
 
Regards,
Randy

>>> Jay  5/10/2008 6:01 AM >>>
 > I have both console and gui programs built using 4.1 that do pull
stuff out of the environment.

I assume you weren't using RTArgs?
 
Everything good, move along?
 
(Not "everything", there are still m3tests failures..though I guess --
maybe also try them with 3.6, 4.1, 5.1...)
 
 - Jay

Date: Sat, 10 May 2008 05:46:16 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com 
Subject: Re: [M3devel] NT386 environment variables (new NT386
snapshots)

Jay:
 
Ok, I've added the sleep.
Here are the new results using my newly rebuilt cm3 and my old v4.1:
 
v4.1:  pgm.exe @M3novm abc def ghi
v5.7:  pgm.exe abc def ghi
 
1.  cm3 4.1, VS 2005, GUI mode, popup with runtime error crash message
 
2.  cm3 4.1, VS 2005, console mode, no popup, output shows "def*5;"
 
3.  cm3 d5.7.0, VS 2008, GUI mode, popup with output shows
"def=ExitCode=00000000"
 
4.  cm3 d5.7.0, VS 2008, console mode, no popup with output shows
"def=ExitCode=00000000"
 
Regards,
Randy

>>> Jay  5/10/2008 5:04 AM >>>
Randy,
You can make the popup stick around, put in WinBase.Sleep(10000), or
run under a debugger.
Since 5.7 is crashing, I assume you don't have the fix I very recently
commited? Or the last point.
I assume if 5.7 doesn't crash, you are satisfied.
 
I forgot to tell you -- make sure you pass a few command line options
to the program, like
 
NT386\pgm.exe abc def ghi.
 
 - Jay

Date: Sat, 10 May 2008 04:46:54 -0400
From: rcoleburn at scires.com 
To: jayk123 at hotmail.com 
Subject: RE: [M3devel] NT386 environment variables (new NT386
snapshots)

Jay:
 
Here are my results using the program you supplied:
 
1.  cm3 v4.1, VS 2005, GUI mode, get a pop-up dos window, but program
crashes
 
2.  cm3 v4.1, VS 2005, console mode, program crashes
 
3.  cm3 v.d5.7.0, VS 2008 GUI mode, get a pop-up window but it
disappears too fast to see any contents
 
4.  cm3 v.d5.7.0, VS 2008 console mode, program crashes
 
Regards,
Randy

>>> Jay  5/9/2008 3:44 AM >>>
 > these problems (pixmaps, buildstandalone, environ vars, serial i/o,
etc...
 
 Ok, here is the story with environment variables.

I tested 3.6 and current, gui and console.

This is the program:

C:\dev2\j\m3\3>type src\m3makefile

import ("m3core")
import ("libm3")
m3_option ("-gui")     twiddle this line in and out with a comment
implementation ("Main")
program ("pgm")
 
C:\dev2\j\m3\3>type src\Main.m3
MODULE Main;
IMPORT IO;
IMPORT RTArgs;
 
BEGIN
(* IO.Put just crashes in 3.6 gui apps *)
  IO.Put(RTArgs.GetArg(2));
  IO.Put(RTArgs.GetEnv(2));
 
(* use this for gui apps *)
  EVAL RTArgs.GetArg(2);
  EVAL RTArgs.GetEnv(2);
END Main.

In 3.6 console apps, RTArgs.GetEnv returns garbage. That makes sense
from the code.
In current console apps, GetEnv works.
In current gui apps, GetEnv access violates, or returns an invalid
pointer.
  This also makes sense from the code.

Randy, does this actually work for you?
I'd be quite surprised.
I haven't tried 4.1 yet, just 3.6 and current.

I will apply an easy fix.

 - Jay

Date: Thu, 8 May 2008 16:17:37 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com 
Subject: Re: [M3devel] new NT386 snapshots

Jay:
 
I have both console and gui programs built using 4.1 that do pull stuff
out of the environment.  I've not noticed any problems with either
mode.
 
>From my perspective, the old 4.1 seems more reliable than the current
system in a number of respects.  I have a new project with a hard
deadline that I would like to use the new cm3 system for, but until
these problems (pixmaps, buildstandalone, environ vars, serial i/o,
etc.) can be resolved, I'm going to keep using 4.1 for my production
work.
 
Regards,
Randy

>>> Jay  5/8/2008 2:46 PM >>>
http://modula3.elegosoft.com/cm3/uploaded-archives/ 
 
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0.zip

http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-WIN32-NT386-d5.7.0.zip

http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0-symbols.zip

 
These should have:
  latest quake extensions 
  set relation fixes 
  other set fixes revealed through dynamic linking of one regression
test 
  hypothetical ability to cross-build to AMD64_LINUX, AMD64_DARWIN  
  one jmpbuf size for all NT386 configurations (NT386, NT386GNU,
NT386MINGNU) 
 
Built with Visual C++ 9.0 Express, so you'll want:
http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en

 
 
Still more work to do though, e.g. assertion failures in unit tests,
pixmap..
 
Fuller disclosure:
Something is leaking memory on my system such that "everything" starts
"failing" and I have to reboot.
This isn't Modula-3 related.
Hopefully these files aren't damaged as a result.
Must be some buggy driver or something..
 
Aside:
 The environment variable thingy has been bugging me a long time and I
finally looked deeper at it.
It appears broken in CM3 4.x. I didn't check 3.x yet.
I'm still mulling a fix, and haven't run a repro of the break, but it's
not a big deal either way.
Basically console apps use main that takes char** and gui apps use
WinMain that doesn't get environment variables but the generated code
calls GetEvironmentStrings() which returns null separated strings.
Must be that hardly anyone uses environment variables in Modula-3 on
Win32 for this to have lingered so long, at least gui apps.
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sat May 10 12:48:08 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 10 May 2008 10:48:08 +0000
Subject: [M3devel] pixmap problem
In-Reply-To: <48253B09.1E75.00D7.1@scires.com>
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	
	<481F9804.1E75.00D7.1@scires.com><481F9804.1E75.00D7.1@scires.com>
	
	<482529C7.1E75.00D7.1@scires.com>
	<48253152.1E75.00D7.1@scires.com><48253152.1E75.00D7.1@scires.com>
	 
	<48253B09.1E75.00D7.1@scires.com>
Message-ID: 

Randy, 3.6 is still available for download on the web, and it still works.
 
I know exactly what my fix does and why it wasn't working before in the immediate past -- some set operations are dependent on data in m3core, in hand.c, and importing data from a .dll requires dereferencing a pointer to get the data. Whereas getting data from a static .lib does not. The pointer for data "foo" is usually called "__imp__foo", though that is just a convention implemented by the linker. So, let's say foo is a function. The generated code to call foo can be, and in Modula-3 always is, merely "call foo", or maybe "call _foo". x86 Windows tends to put a leading underscore on everything. That's a different matter. Now, again, foo is a function let's say, and the code says "call foo". Now, if foo ends up being imported from a .dll, what the linker does is generate a one instruction function like so:
 
foo:
  jmp dword ptr [__imp__foo]
 
And then __imp__foo is also special. __imp__foo is created such that at runtime, at load time, it is overwritten with the address of the actual location of the actual foo function in another .dll. All the __imp__ symbols are adjacent, so these writes aren't scattered around and written pages are kept to a minimum, at least in this regard.
 
Now, if you KNOW you are going to import foo, you can give the compiler a small optimization hint, and the compiler can "call dword ptr [__imp__foo]" directly, skipping the one instruction -- said instruction also having poor locality. As well, the Visual C++ compiler is smart enough to prefetch the instruction, and if you make repeated calls to an imported function, even keep it around in a register. There is no way to get this in Modula-3 today, and really it doesn't seem like a big deal to me. See, you know, if you don't know if foo will be dynamically linked or statically linked, "call foo" is reasonable efficient generic code. If you think it will be imported, you can generate "call dword ptr [__imp__foo]" instead, but then if you are wrong, either a) you get a link error, or b) you can go ahead and generate the pointer that points to the function, and you will pay an extra pointer dereference in the function calls, but at least not an extra instruction. As I wildly guess, calls to statically linked functions are more common than calls to dynamically linked functions, so erring toward making the static call more efficient seems better. On the other hand, it appears to me that Windows is alone here. My brief look into the Linux and Darwin calling conventions indicates they use big inefficient methods, worse than the "worst case" Windows uses, when you take either of the deoptimizations I describe. Granted, everyone else tends to get actually position independent code, and Windows does not. Windows get relocatable code, but not position independent, and the cost of the relocation can be high (every page written, loss of physical memory sharing, dirty pages backed by pagefile instead of the original .exe/.dll).
AMD64 Windows has mostly position independent code via the new RIP-relative addressing mode, but not fully. What often bites you is pointers in your data, like vtables. I do wish Windows had fully position independent code and I don't know if that would result in exactly the inefficient sequences I see on Linux and Darwin or not.
 
 
Ok now. That only mentioned functions. There was no mention of data.
You must pay close attention to particular details. In particular, the code always says "call foo" and if foo is imported, the linker generates a single instruction function, named foo, just like expected, that indirects through a pointer. You must indirect through a pointer for dynamic linking. And since there is a function call involved, a function can be generated to fit.
There's some saying here, like, you know that "any problem can be solved by an extra level of indirection", well, there's some corralary like "give me a function call and I can add indirection afterward".
 
But if you think about data, compiler generates something like "mov eax, foo" -- there's no way for the linker to intercede there -- there is no function call. It actually should fail to link. That is a different related matter. If you make the kind of error in C code that we have in Modula-3, you would get a link error. I'll show you in a sec. What happens in Modula-3, is, well, something, like mklib, doesn't know foo is data instead of a function, and goes ahead and generates foo that jmps through __imp__foo. That function foo is what these data references end up using, with fairly "random" results.
 
What my fix does is statically link in foo (_highbits, _lowbits). So the regular "mov eax, foo" works. No pointer derefence is needed for static linking, no __imp__ foo. I should go and fix the compiler to reference __imp__foo, and if we end up statically linked, like for standalone, there can be an extra pointer __imp_foo = &foo, and standalone will pay an extra, unnecessary, pointer deref.
 
Here is how you can see this problem in C.
 
  dll.c  
  __declspec(dllexport) int foo;  
   
  exe.c  
  extern int foo;   
  int main()  
 {  
   printf("%d\n", foo);    
  return 0;     }  
 
 cl -LD dll.c -link -noentry -nodefaultlib 
 rem really that's all it takes to make a .dll 
 cl exe.c dll.lib 
 rem really, that's it takes to build an .exe that uses the .dll 
 
 >> exe.obj : error LNK2019: unresolved external symbol foo referenced in function main 
 
But if you change it to:
 
  __declspec(dllimport) extern int foo;  
 
then it works. I don't fully understand this -- something somewhere knows that foo is data and doesn't generate the function for it. If you use a .def file, you mark the symbol as "data".
 
The GNU tools, ld --help, suggests some workaround here. That they let you generate the "wrong" code and the linker somehow makes it work. I don't know what it is..the only thing I can think of might not work and would look really ugly. I think link -dump crashes on ld output so I stopped looking..
 
I will look into 4.1 to determine what changed and why it worked.
 
The result in 5.x is actually not guaranteeably wrong, just very very difficult to predict the outcome of.
Instead of referencing the correct data, some fairly arbitrary data is used. But of course not every bit matters.
Could be the 4.1 code doesn't use the set operations here even, avoiding this problem.
We'll see. "There is no need to speculate; just debug it and know." :)
That's my own saying. I see so much unnecessary speculation and metaphorical throwing of hands in the air, and not enough debugging. :)  (Granted, something is screwy on my XP AMD64 machine and I'm more likely to reinstall than debug it...and maybe if it recurs then I'll debug some...can't do much without source and symbols though...that's where my debugging skills rapidly fall off...(which is a complaint I have about Modula-3, there's a certain lack of symbols for global data I believe, probably should be fixed...)) 
 
 - Jay


Date: Sat, 10 May 2008 06:05:02 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem

Jay:
 
I get correct behavior now for TestPixmap on d5.7 when built either way, with or without standalone option.
THANKS!
 
On 4.1, TestPixmap also works both ways.  The problem was occurring before your fix on d5.7 (and on earlier releases after 4.1).  Not sure what your fix does or what changed from 4.1 to d5.7 that made your fix necessary.
 
I am using your NT386 stuff for cm3.cfg now.
 
I don't have 3.6.
 
I will need to run tests now with d5.7 against my programs to see if they are working correctly before I can abandon 4.1.  Also, we will need to drive a stake in the ground at some point soon to create an official 5.7 release.  My company will want to be able to point to a given development environment for future support of the product I'm working on.  They won't accept a "d5.7" release that is in a state of flux.
 
Also, the other issue I'll have to work is getting all the GUI changes incorporated into this edition.  We will need the custom look&feel that CMass put together for us.  I'll check into it.  If I am successful, I can create a branch on CVS with this edition in case anyone else wants it.
 
Regards,
Randy>>> Jay  5/10/2008 5:38 AM >>>Randy, clarification, the bug occured when NOT building standalone.You must know that, since you reproed it recently.Just try both ways, both should work. (You don't have to take my cm3.cfg, but you do need NT386.common, and then either copy NT386 to cm3.cfg, or take NT386 and have cm3.cfg be just one line, include("NT386")) Any reason left for you to stick with 4.1? :)Something with serialio? At least one question does remain -- the TestPixmap behavior and why on 4.1.I'll look into that shortly.3.6 isn't relevant, since it didn't have .dlls. Thanks, - Jay


Date: Sat, 10 May 2008 05:23:35 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem
Jay:
 
I've performed the following and it seems to have fixed the problem with the TestPixmap program when built standalone:
 
1.  performed CVS update
2.  updated cm3.cfg and NT386* in \cm3\bin based on sources in cminstall\config
3.  scripts\win\upgrade
4.  scripts\win\do-cm3-std buildship
 
I checked the .lst file and I am now seeing "hand.obj"
 
Regards,
Randy>>> "Randy Coleburn"  5/10/2008 4:51 AM >>>
Jay:
 
I do not have python installed on my computer, so I can't run your scripts.
 
I used the scripts in scripts\win to upgrade a few days ago.
 
I am not seeing hand.obj in the .lst file.
 
I will do a CVS update and try the upgrade again followed by do-cm3-standard.
 
Regards,
Randy>>> Jay  5/9/2008 5:10 AM >>>
 > Also, more bad news, the pixmap problem is not solved. Randy, this DOES actually fix it, but you have to rebuild more. Try:   cd scripts\python    .\do-cm3-std.py realclean    .\upgrade.py   (probably not needed)    do-cm3-std.py buildship   Make sure "hand.obj" occurs in the various NT386\foo.lst files. I think the fix should be restated to have the code reference *__imp__highbits instead of highbits, and go back to dynamic linking the data.But ok for now. The std distribution I put yesterday should work, though it is missing the RTArgs fix.I'll see about making another.   - Jay


Date: Mon, 5 May 2008 23:28:10 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad news is that now I am getting a command window opening up in addition to the GUI window when the program runs.  This behavior does not occur on v4.1.  The command window seems to be the stdout/stderr of the GUI program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy>>> Jay  5/5/2008 10:47 PM >>>Randy, Yes.The NT386 config files are all checked in.You can use them verbatim. You don't need cminstall, I never use it, and you shouldn't need to edit the config files at all, any edits I make, I check in, and should be usable on all machines.As long as you set %PATH%/%INCLUDE%/%LIB%.If I'm wrong, I'd like to know why and try to fix. Consider the config files just part of cm3.exe.Not generally to be changed locally. Unless, well, unless you intend to, and you should strive to make one form that is usable by all.  - Jay


Date: Mon, 5 May 2008 22:42:30 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay,
When you say "took the updated config file", what do you mean?  Are you saying I need a different cm3.cfg file?
Regards,
Randy>>> Jay  5/5/2008 9:54 PM >>>And you took the updated config file?The way you can tell is that, roughly speaking, hand.obj should be in NT386\_m3responsefile0.txt.Or _m3responsefile1.txt, or, well, somewhere.Anyway, I think I saw the attachment, I can check later..and with 4.1 as I said.. I can see about making the fix not depend on config file changes...but it's not terrible asis, and I'd really like to merge more of the quake code into cm3.exe..  - Jay


Date: Mon, 5 May 2008 21:18:12 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem
Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly when the buildstandalone() directive is used.
 
Regards,
Randy>>> Jay  5/5/2008 7:04 PM >>>Thanks. I'll look into this tonight probably, as well as with 4.1 assuming I can find my binaries and source for it (probably).COULD BE the pixmap problem is something else and 4.1 also has the problem I fixed. We'll see. No need to speculate (unless I can't find my 4.1). - Jay


Date: Mon, 5 May 2008 10:59:27 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problem
Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy>>> Jay  5/4/2008 11:46 AM >>>Randy, Please try with /current/ source, as of this morning Sunday May 4 -- the changes are ALL in NT386.common, so you MUST use MY config files, which are checked in verbatim, or you should be able edit whatever config files you are using. (It's not really a config file issue, don't blame the general confusion people have with them.) I'll try to try later, but I don't have the source right now, gotta look on other machines, and I think it's on a machine on loan.  Or send it to me again.I'd also like to know if this worked with 4.1, or with any release that offered dynamic linking to m3core.dll, on Windows.  I recall a claim that it did. If today's change fixes it, I should be able to investigate 4.1.3.6 did not have such linking.If today's change does not help, well, I still plan on debugging it at some point.. If you aren't current and getting so is difficult, just send the attachment again, it's easy for me to test. Thanks, - Jay


From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rcoleburn at scires.comDate: Sat, 19 Jan 2008 08:52:08 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.I was going to try on PPC_DARWIN but I guess Tony's info suffices. I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. Debugging here is a big humungous pain.NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)And bundles look pretty simple, a bundle is just a generated source file with a constant in it.Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something. The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for? I have to say this is very surprising. I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so.The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: pointer to msvcrt!fopenpointer to msvcrt!fclosenullpointer to kernel32!Sleep But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo.But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo.That doesn't work for data though. There's no ability to intervenve like that.So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it.And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.However that would suck perf in order to make an uncommon case work.I hope Modula-3 doesn't do that either. :)Though I guess since this global data in question...maybe it is rare??? Later, - Jay

> From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 03:09:47 -0500> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] pixmap problem> > Looks fine to me on I386_DARWIN.> > On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:> > > > 

Need to know the score, the latest news, or you need your Hotmail?-get your "fix" Check it out. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sat May 10 17:40:40 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 10 May 2008 15:40:40 +0000
Subject: [M3devel] _lowbits / _highbits (Pixmap bug-- 4.1 vs. buggy 5.x)
Message-ID: 

There is SOME evidence that this lowbits/highbitsproblem is a regression introduced in Critical Mass 5.1.And there are inconsistent data.
(I believe 5.1 is the name given to the Critical Mass tree at the time it was open-sourced, vs. 4.1 which was commercially released, and some source withheld.)
 
The source history is a little incomplete.Critical Mass 4.1 did not ship with complete source.In particular, the compiler source is missing.Libraries are there.
 
Aside: I wonder if the 4.1 release can be made more widelyavailable, for purposes such as this. For one thing, I can contributehow to trivially patch the NT386 binary to not care about the registration key.I did buy it, but finding the key is..difficult.
 
The Elegosoft repository claims to have an import of 4.1 followed by an update to 5.1, but it is suspicious.
 
3.6 Stackx86.m3 -- no reference to  _lowbits / _highbits3.6 hand.c -- no implementation of ditto3.6 didn't offer dynamic linking, so it would have been ok.
 
The 4.1 CD includes the 3.6 source in "contrib" and some of the4.1 source in "source". That confused me at first, to have two of everything.I merely ASSUME what is what. I didn't look in detail.
 
4.1 CD hand.c -- no implementation of _lowbits / _highbits4.1 CD Stackx86.m3 -- source not available, darn it
 
4.1 in repository hand.c -- no implementation of ditto4.1 in repositoy Stackx86.m3 -- references _lowbits / _highbits
 
5.1 in repository hand.c -- implementation of ditto5.1 in repositoy Stackx86.m3 -- no change
 
The supposed 4.1 to 5.1 lack of diff (not that I understand CVS revision numbers or anything...) http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3back/src/Stackx86.m3.diff?r1=1.1;r2=1.1.1.1
 
introduction of _lowbits / _highbits in a more belieable 4.1 to 5.1 diff: http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/Csupport/Common/hand.c.diff?r1=1.1.1.1;r2=1.1.1.2
 
This is all a bit tedious so someone please double check me.
 
The 4.1 source in the repository is not self consistent.I contend it is wrong.I contend that the 4.1 Stackx86.m3 is more like the 3.6 -- no use of highbits / lowbits.
Since the symbols are not exported from the 4.1 CD m3core.dll nor are in the 4.1 CD hand.c source.
 
5.1 in the repository is self consistent, and I contend has the bug.
 
The 4.1 m3core.dll does export HiBits / LoBits -- different spelling, different casing,  and none of the .dlls in the system import them.
  Several versions have LoBits / HiBits be file-level static, further    implying they aren't used outside of hand.c.
  It is difficult for me to browse the old version of the tree however.  I guess I should try something like checkout -revision 1 and then search that locally?
  Inspection says that HiBits / LoBits went static in 2003 here:
 
 http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/Csupport/Common/hand.c
 
  and then later, I made them non-static FOR 32 BIT TARGETS, as part of merging them with  _lowbits / _highbits. This is a bit tangential, but the point is to exonerate  LoBits / HiBits of any involvement. _lowbits / _highbits are the relevant party.  They are nearly identical. See hand.c for how they relate. There is an extra  entry in one pair or the other, either at the start or the end, and one is uint and the  other ulong, when sizeof(uint) == sizeof(ulong), they share storage, my doing.  The NT386 compiler references _lowbits / _highbits. LoBits / HiBits are only used internally to hand.c.
  The gcc backend does not reference _lowbits / _highbits.
So obviously another fix is to go back to the 3.6 code and remove the symbols entirely.And make sure m3tests passes with that.I didn't look at the code yet.In general the code quality is not super high so it probably matters little.
Also obviously it would be prudent to review the code here to make sure it is correct,or to look at the relevant unit test and see if it seems comprhensive.
 
 
Thoughts?
 
 
Presume Critical Mass introduced the regression in 5.1, and give up attaining accurate 4.1 source??
I should findstr (grep) against the 4.1 cm3, but the lack of the symbols in its m3core is pretty conclusive.
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sun May 11 07:08:22 2008
From: jayk123 at hotmail.com (Jay)
Date: Sun, 11 May 2008 05:08:22 +0000
Subject: [M3devel] _lowbits / _highbits (Pixmap bug-- 4.1 vs. buggy 5.x)
Message-ID: 

Clarification: I now see that 3.6 did have these tables. They had different names. It appears they were generated for every ...I don't know, every source file or every .dll/.exe. That would work. That is similar to what we have now with my fix, though my fix statically links more than this -- everything in hand.obj.
 
D:\cm3-4.1\CONTRIB\SRC-M3\m3\m3back\src\Codex86.m3(2033):PROCEDURE init_intvar (t: T; size: ByteSize; f_lit: FLiteral; abscall: AbsCall;
D:\cm3-4.1\CONTRIB\SRC-M3\m3\m3back\src\Codex86.i3(96):TYPE IntnlVar = { Lowset_table, Highset_table };D:\cm3-4.1\CONTRIB\SRC-M3\m3\m3back\src\Codex86.m3(2077):      IntnlVar.Lowset_table =>D:\cm3-4.1\CONTRIB\SRC-M3\m3\m3back\src\Stackx86.m3(1953):                             o := ORD(IntnlVar.Lowset_table),
D:\cm3-4.1\CONTRIB\SRC-M3\m3\m3back\src\Stackx86.m3(34):        lowset_table  : MVar;D:\cm3-4.1\CONTRIB\SRC-M3\m3\m3back\src\Stackx86.m3(1298):        t.cg.tableOp(Op.oAND, stop2, stop0, 4, t.lowset_table);D:\cm3-4.1\CONTRIB\SRC-M3\m3\m3back\src\Stackx86.m3(1430):      t.cg.tableOp(Op.oMOV, t.cg.reg[maskreg], stop0, 4, t.lowset_table);D:\cm3-4.1\CONTRIB\SRC-M3\m3\m3back\src\Stackx86.m3(1443):      t.cg.tableOp(Op.oMOV, t.cg.reg[maskreg], stop0, 4, t.lowset_table);D:\cm3-4.1\CONTRIB\SRC-M3\m3\m3back\src\Stackx86.m3(1495):      intable := t.lowset_table;D:\cm3-4.1\CONTRIB\SRC-M3\m3\m3back\src\Stackx86.m3(1952):    t.lowset_table := MVar { var := t.cg.internalvar,
That at least clarifies there wasn't likely an older less efficient table-less codegen, just that the tables were gotten differently.
 
 - Jay


From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: _lowbits / _highbits (Pixmap bug-- 4.1 vs. buggy 5.x)Date: Sat, 10 May 2008 15:40:40 +0000


There is SOME evidence that this lowbits/highbitsproblem is a regression introduced in Critical Mass 5.1.And there are inconsistent data.(I believe 5.1 is the name given to the Critical Mass tree at the time it was open-sourced, vs. 4.1 which was commercially released, and some source withheld.) The source history is a little incomplete.Critical Mass 4.1 did not ship with complete source.In particular, the compiler source is missing.Libraries are there. Aside: I wonder if the 4.1 release can be made more widelyavailable, for purposes such as this. For one thing, I can contributehow to trivially patch the NT386 binary to not care about the registration key.I did buy it, but finding the key is..difficult. The Elegosoft repository claims to have an import of 4.1 followed by an update to 5.1, but it is suspicious. 3.6 Stackx86.m3 -- no reference to  _lowbits / _highbits3.6 hand.c -- no implementation of ditto3.6 didn't offer dynamic linking, so it would have been ok. The 4.1 CD includes the 3.6 source in "contrib" and some of the4.1 source in "source". That confused me at first, to have two of everything.I merely ASSUME what is what. I didn't look in detail. 4.1 CD hand.c -- no implementation of _lowbits / _highbits4.1 CD Stackx86.m3 -- source not available, darn it 4.1 in repository hand.c -- no implementation of ditto4.1 in repositoy Stackx86.m3 -- references _lowbits / _highbits 5.1 in repository hand.c -- implementation of ditto5.1 in repositoy Stackx86.m3 -- no change The supposed 4.1 to 5.1 lack of diff (not that I understand CVS revision numbers or anything...) http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3back/src/Stackx86.m3.diff?r1=1.1;r2=1.1.1.1 introduction of _lowbits / _highbits in a more belieable 4.1 to 5.1 diff: http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/Csupport/Common/hand.c.diff?r1=1.1.1.1;r2=1.1.1.2 This is all a bit tedious so someone please double check me. The 4.1 source in the repository is not self consistent.I contend it is wrong.I contend that the 4.1 Stackx86.m3 is more like the 3.6 -- no use of highbits / lowbits.Since the symbols are not exported from the 4.1 CD m3core.dll nor are in the 4.1 CD hand.c source. 5.1 in the repository is self consistent, and I contend has the bug. The 4.1 m3core.dll does export HiBits / LoBits -- different spelling, different casing,  and none of the .dlls in the system import them.  Several versions have LoBits / HiBits be file-level static, further    implying they aren't used outside of hand.c.  It is difficult for me to browse the old version of the tree however.  I guess I should try something like checkout -revision 1 and then search that locally?  Inspection says that HiBits / LoBits went static in 2003 here:  http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/Csupport/Common/hand.c   and then later, I made them non-static FOR 32 BIT TARGETS, as part of merging them with  _lowbits / _highbits. This is a bit tangential, but the point is to exonerate  LoBits / HiBits of any involvement. _lowbits / _highbits are the relevant party.  They are nearly identical. See hand.c for how they relate. There is an extra  entry in one pair or the other, either at the start or the end, and one is uint and the  other ulong, when sizeof(uint) == sizeof(ulong), they share storage, my doing.  The NT386 compiler references _lowbits / _highbits. LoBits / HiBits are only used internally to hand.c.  The gcc backend does not reference _lowbits / _highbits.So obviously another fix is to go back to the 3.6 code and remove the symbols entirely.And make sure m3tests passes with that.I didn't look at the code yet.In general the code quality is not super high so it probably matters little.Also obviously it would be prudent to review the code here to make sure it is correct,or to look at the relevant unit test and see if it seems comprhensive.  Thoughts?  Presume Critical Mass introduced the regression in 5.1, and give up attaining accurate 4.1 source??I should findstr (grep) against the 4.1 cm3, but the lack of the symbols in its m3core is pretty conclusive.  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sun May 11 07:45:31 2008
From: jayk123 at hotmail.com (Jay)
Date: Sun, 11 May 2008 05:45:31 +0000
Subject: [M3devel] RTLinker/RTArgs breaking change
Message-ID: 

RTLinker/RTArgs breaking change
I would like to cleanup my RTArgs change.
In particular, the interface among main <=> RTLinker <=> RTArgs
will change, on Windows.Posix should be unchanged.(Ok, at least Posix main <=> RTLinker unchanged, RTLinker <=> RTArgs maybe not).
One of the things holding me back is the knowledge thata current compiler must work against an old runtime,and the code did sometimes work.
However, m3-sys has no references to RTArgs,  nor to ".envp", so I am fairly confident that this can  be changed without breaking bootstrapping.
  My own near future experience implementing it should prove it one way or the other.
The change would be that for Win32 targets, MxGen.m3will always pass NIL for the envp parameter to RTLinker.InitRuntime.The parameter is ignored in current RTLinker with my recent change anyway.And then Win32/RTArgs will always just call GetEnvironmentStringsitself, ignoring RTLinker.envp.
RTLinker.envp should probably just go away, since it had no easily portable use.And then, RTLinker.InitRuntime should probably call a new functionRTArgs.SetEnv that would do nothing on Win32 and would set an internal variablein Posix/RTArgs.
That is, partly, since RTLinker.envp was fairly broken, remove it.RTArgs.GetEnv was also fairly broken, but repair it (it is already repaired).
As well, interfaces should have more functions and less data.
That is, as well, leverage that RTArgs is already platform-split, so use it  for "all" platform-specificity here. Well, as much as is reasonale.  MxGen would have a platform-switch as to what it is targeting.  My new RTLinkerC.c would go away. It could have been Modula-3 in the first place,   but it would have been platform-split.
ok?
This is really not a big deal actually.But I don't want to break bootstrapping a new compiler with an old runtime.My current fix, while a bit ugly, definitely does not break that, as  it avoided this change.
 
Another avenue is to clarify whether or not "envp" is always available from the C runtime,
such as via char** environ. I suspect it is. "But data imports are bad".
Win32 GUI and console apps could perhaps just use that.
 
Ah -- http://msdn.microsoft.com/en-us/library/aa246422(VS.60).aspx
Calling getenv("") forces environ to be initialized. Maybe reasonable.
There is an issue as to just how many copies of the environment there are..
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Tue May 13 01:35:16 2008
From: jayk123 at hotmail.com (Jay)
Date: Mon, 12 May 2008 23:35:16 +0000
Subject: [M3devel] eliminate Target.Global_handler_stack?
In-Reply-To: <20080511164932.GA4829@fuseki.my.domain>
References: 
	<20080511164932.GA4829@fuseki.my.domain> 
Message-ID: 

Target.Global_handler_stack is FALSE for targets that ever use kernel threads.Target.Global_handler_stack is TRUE for targets that never use kernel threads.
Targets that can go either way set it to FALSE.
 
When Global_handler_stack is TRUE, inline code is generated to,  I guess, manipulate a per-thread linked list of stack frames.
 
When Global_handler_stack is FALSE, function calls are generated  to do same.
 
That is, Global_handler_stack is TRUE is a little more efficient.
 
Given that Global_handler_stack is TRUE for all "recent", "active", "interesting"  targets, with the presumably temporary exception of PPC_LINUX, how about  we remove Global_handler_stack as a variable and just act as if it is always FALSE?
 
(I have some suspicion that this linked list is absent on targets with a stack walker, so it'd make no difference on them. I'll check later..NT386 ought use fs:0 but it doesn't.)
 
I figure target-specificity should be minimized.
Make it easier to bring up new targets -- not that the code isn't pretty
  well commented and easy to understand, so it's really no easier without this.
 
The counterpoints would be:  Even if it is target-specific, it does work and isn't complicated, so leave it alone.  If those old targets are alive, and lack pthreads, it is slightly faster this way.  If people want current/new targets to have a "faster" single threaded mode, this    could be part of that. Note though that single threaded apps can't/don't exist,
   unless maybe if you never heap allocate, since the heap allocator/garbage collector
   creates a thread at initialization (shouldn't it wait for a heap allocation? Maybe.
   If there really is a chance it won't occur or won't occur for a while).
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From hosking at cs.purdue.edu  Tue May 13 01:43:35 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 12 May 2008 19:43:35 -0400
Subject: [M3devel] eliminate Target.Global_handler_stack?
In-Reply-To: 
References: 
	<20080511164932.GA4829@fuseki.my.domain>
	
Message-ID: 


On May 12, 2008, at 7:35 PM, Jay wrote:

> Target.Global_handler_stack is FALSE for targets that ever use  
> kernel threads.
> Target.Global_handler_stack is TRUE for targets that never use  
> kernel threads.
> Targets that can go either way set it to FALSE.
>
>
> When Global_handler_stack is TRUE, inline code is generated to,
>   I guess, manipulate a per-thread linked list of stack frames.
>
>
> When Global_handler_stack is FALSE, function calls are generated
>   to do same.
>
>
> That is, Global_handler_stack is TRUE is a little more efficient.
>
>
> Given that Global_handler_stack is TRUE for all "recent", "active",  
> "interesting"
>   targets, with the presumably temporary exception of PPC_LINUX, how  
> about
>   we remove Global_handler_stack as a variable and just act as if it  
> is always FALSE?

Don't you mean "false" for all current targets (i.e., using threads)?

> (I have some suspicion that this linked list is absent on targets
> with a stack walker, so it'd make no difference on them. I'll check  
> later..
> NT386 ought use fs:0 but it doesn't.)

Indeed, the list is absent on such targets.

> I figure target-specificity should be minimized.
> Make it easier to bring up new targets -- not that the code isn't  
> pretty
>   well commented and easy to understand, so it's really no easier  
> without this.

I have no  objection.

> The counterpoints would be:
>   Even if it is target-specific, it does work and isn't complicated,  
> so leave it alone.
>   If those old targets are alive, and lack pthreads, it is slightly  
> faster this way.
>   If people want current/new targets to have a "faster" single  
> threaded mode, this
>    could be part of that. Note though that single threaded apps  
> can't/don't exist,
>    unless maybe if you never heap allocate, since the heap allocator/ 
> garbage collector
>    creates a thread at initialization (shouldn't it wait for a heap  
> allocation? Maybe.
>    If there really is a chance it won't occur or won't occur for a  
> while).

When does the GC currently create a thread?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Tue May 13 02:23:43 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 13 May 2008 00:23:43 +0000
Subject: [M3devel] eliminate Target.Global_handler_stack?
In-Reply-To: 
References: 
	<20080511164932.GA4829@fuseki.my.domain>
	
	
Message-ID: 

Tony, Yep, I got my true/false backwards at least once.
 
 > I have no  objection. 
 
Thanks. Expect a few deleted lines "soon".
 
 > When does the GC currently create a thread?
 
I'd have to double check. I thought it was in RTAllocator's module initialization. But maybe not.
No mystery here, just that I'm out of Modula-3 mode for a few hours.
It might be on-demand actually -- which would then have to be synchronized -- so doing it early might be preferable..er...well...actually..problem either way I now realize, depending..
 
There is this interesting useful but problematic aspect of .dlls on Windows.
.dlls have an "entry point", a "main" if you will. Usually called DllMain, but the name can be anything. It isn't exported, it's a field in the file format. The signature is
BOOLEAN DlMain(int reason, ADDRESS opaqueHandleToSelf, ADDRESS additionalBit);
 
The reasons are
  process attach, process detach, thread attach, thread detach 
  the opaqueHandleToSelf can be used for example to load "resources" from yourself
  additionalBit has a null vs. non-null meaning
    when reason == process detach, the nullness indicates if the .dll is being unloaded because the process is going away, or it is being unloaded but the process is staying around -- if the process is going away, basically nothing should be done, if the process is not going away, cleanup any process-global resources 
 
Process attach means the .dll was "just" loaded.
 
If you return false for failure from process attach, then the process will fail to launch or the LoadLibrary (dlopen) will fail, depending on if you are a static dependency of the .exe, or dynamically loaded via LoadLibrary (dlopen).
 
I believe the return values from all the other reasons are ignored.
 
There are many oddities here. Including the fact that threads can be created before the .dll loads and destroyed after it unloads, so the interface of thread attach/detach isn't what it seems -- you don't necessarily get the calls, you only get the calls for threads created/destroyed while you are already loaded (and perhaps one extra when you get loaded/unloaded?)
 
Folks who think they can do their per-thread cleanup in thread detach are sorely wrong.
What you have to do is keep all your thread-locals in a global list and free them in process detach.
Or just don't have any, that's the best policy.
 
Now, the important aspect here is that there is a lock around all DllMain calls, be they the process or thread ones.
 
This is "useful" because it means you can initialize your globals without worrying about synchronization.
Now, because of the lock, there isn't much you can do without risking deadlock.
But you would typically limit your activities to heap allocation, TlsAlloc (pthread_threadspecific_allocate_key or such), and critical section initialization. Win32 critical sections sadly require an initialization call, rather than just being initialized to all zeros. There's an API in Vista to allow static initialization.
(Cygwin's pthreads stuff also doesn't have zero initialization, but at least static).
 
On-demand initialization outside of DllMain must be synchronized, as threads can be created fairly arbitrarily early.
If you create a thread in DllMain, it essentially won't start until all the DllMains return.
It is possible though to have multiple threads running concurrently with "main".
 
And just because "you" don't create a thread in your app/.exe, doesn't mean some .dll you loaded didn't create some.
There's no such thing as a single-threaded process.
 
I suspect there is therefore a problem here in Modula-3. Or at least some double checking needed -- around the thread safety of various initialization.
 
A common pattern in Win32 is /ROUGHLY/:
 
T* g_pt; // global pointer to a T
 
T* GetTheT(void)
{
  if (g_pt != NULL)
    return g_pt;
  T* pt = new T();
  MemoryBarrier(); // ensure T's constructor finished before storing the global pointer
  if (InterlockedCompareExchangePointer(&g_pt, pt, NULL) != NULL)
   {
     // somebody else won the race
    delete pt;
   }
   return g_pt;
}
 
This way, initialization is done on-demand and thread safely.
This code assumes that race conditions will be rare vs. the expense of creating a T that is thrown away, and that creating, multiple T's in the event of a race, only to cleanup all but one right away, is ok.
 
If you must not ever create more than one T, then other code is needed.
Easiest is to initialize a critical section in DllMain and then just use that.
 
Or implement a little spin lock, assuming initialization of T is cheap.
 
In Vista there is a "once" synchronization object for handling this.
It is very disappointing that this wasn't introduced 10+ years ago.
As well as statically initializable locks and reader/writer locks.
 
I keep tending to think that Modula-3 module intializers have this same lock, at least on Windows.
But that is definitely NOT necessariiy true, at least in the face of static linking, and probably even with dynamic linking, since Modula-3 implements this stuff itself.
 
I'll have to review the code. Maybe it is just fine already.
 
If it isn't, well, there are a few easy solutions.
As well, this could be a problem on all platforms.
So it might make sense for the runtime to recognize when it is calling module initializers and endeavor to "not start" any threads while they are running.
 
Corrallary, on Win32, and in this scheme, that if you create  a thread in DllMain/thread initializer and then wait for it to make progress, you deadlock.
 
Gotta run,
 - Jay


CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] eliminate Target.Global_handler_stack?Date: Mon, 12 May 2008 19:43:35 -0400

On May 12, 2008, at 7:35 PM, Jay wrote:

Target.Global_handler_stack is FALSE for targets that ever use kernel threads.Target.Global_handler_stack is TRUE for targets that never use kernel threads.Targets that can go either way set it to FALSE. When Global_handler_stack is TRUE, inline code is generated to,  I guess, manipulate a per-thread linked list of stack frames. When Global_handler_stack is FALSE, function calls are generated  to do same. That is, Global_handler_stack is TRUE is a little more efficient. Given that Global_handler_stack is TRUE for all "recent", "active", "interesting"  targets, with the presumably temporary exception of PPC_LINUX, how about  we remove Global_handler_stack as a variable and just act as if it is always FALSE?
Don't you mean "false" for all current targets (i.e., using threads)?


(I have some suspicion that this linked list is absent on targets with a stack walker, so it'd make no difference on them. I'll check later..NT386 ought use fs:0 but it doesn't.)

Indeed, the list is absent on such targets.

I figure target-specificity should be minimized.Make it easier to bring up new targets -- not that the code isn't pretty  well commented and easy to understand, so it's really no easier without this.
I have no  objection. 


The counterpoints would be:  Even if it is target-specific, it does work and isn't complicated, so leave it alone.  If those old targets are alive, and lack pthreads, it is slightly faster this way.  If people want current/new targets to have a "faster" single threaded mode, this    could be part of that. Note though that single threaded apps can't/don't exist,   unless maybe if you never heap allocate, since the heap allocator/garbage collector   creates a thread at initialization (shouldn't it wait for a heap allocation? Maybe.   If there really is a chance it won't occur or won't occur for a while).

When does the GC currently create a thread?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Tue May 13 03:09:12 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 13 May 2008 01:09:12 +0000
Subject: [M3devel] FW:  eliminate Target.Global_handler_stack?
In-Reply-To: 
References: 
	<20080511164932.GA4829@fuseki.my.domain>
	
	 
Message-ID: 

 truncated yet again..
Olaf is there anything in any mail log on your end?
 
 - Jay


From: jayk123 at hotmail.comTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] eliminate Target.Global_handler_stack?Date: Tue, 13 May 2008 00:23:43 +0000


Tony, Yep, I got my true/false backwards at least once.  > I have no  objection.  Thanks. Expect a few deleted lines "soon". 
 > When does the GC currently create a thread? I'd have to double check. I thought it was in RTAllocator's module initialization. But maybe not.No mystery here, just that I'm out of Modula-3 mode for a few hours.It might be on-demand actually -- which would then have to be synchronized -- so doing it early might be preferable..er...well...actually..problem either way I now realize, depending.. There is this interesting useful but problematic aspect of .dlls on Windows..dlls have an "entry point", a "main" if you will. Usually called DllMain, but the name can be anything. It isn't exported, it's a field in the file format. The signature isBOOLEAN DlMain(int reason, ADDRESS opaqueHandleToSelf, ADDRESS additionalBit); The reasons are  process attach, process detach, thread attach, thread detach   the opaqueHandleToSelf can be used for example to load "resources" from yourself  additionalBit has a null vs. non-null meaning    when reason == process detach, the nullness indicates if the .dll is being unloaded because the process is going away, or it is being unloaded but the process is staying around -- if the process is going away, basically nothing should be done, if the process is not going away, cleanup any process-global resources  Process attach means the .dll was "just" loaded. If you return false for failure from process attach, then the process will fail to launch or the LoadLibrary (dlopen) will fail, depending on if you are a static dependency of the .exe, or dynamically loaded via LoadLibrary (dlopen). I believe the return values from all the other reasons are ignored. There are many oddities here. Including the fact that threads can be created before the .dll loads and destroyed after it unloads, so the interface of thread attach/detach isn't what it seems -- you don't necessarily get the calls, you only get the calls for threads created/destroyed while you are already loaded (and perhaps one extra when you get loaded/unloaded?) Folks who think they can do their per-thread cleanup in thread detach are sorely wrong.What you have to do is keep all your thread-locals in a global list and free them in process detach.Or just don't have any, that's the best policy. Now, the important aspect here is that there is a lock around all DllMain calls, be they the process or thread ones. This is "useful" because it means you can initialize your globals without worrying about synchronization.Now, because of the lock, there isn't much you can do without risking deadlock.But you would typically limit your activities to heap allocation, TlsAlloc (pthread_threadspecific_allocate_key or such), and critical section initialization. Win32 critical sections sadly require an initialization call, rather than just being initialized to all zeros. There's an API in Vista to allow static initialization.(Cygwin's pthreads stuff also doesn't have zero initialization, but at least static). On-demand initialization outside of DllMain must be synchronized, as threads can be created fairly arbitrarily early.If you create a thread in DllMain, it essentially won't start until all the DllMains return.It is possible though to have multiple threads running concurrently with "main". And just because "you" don't create a thread in your app/.exe, doesn't mean some .dll you loaded didn't create some.There's no such thing as a single-threaded process. I suspect there is therefore a problem here in Modula-3. Or at least some double checking needed -- around the thread safety of various initialization. A common pattern in Win32 is /ROUGHLY/: T* g_pt; // global pointer to a T T* GetTheT(void){  if (g_pt != NULL)    return g_pt;  T* pt = new T();  MemoryBarrier(); // ensure T's constructor finished before storing the global pointer  if (InterlockedCompareExchangePointer(&g_pt, pt, NULL) != NULL)   {     // somebody else won the race    delete pt;   }   return g_pt;} This way, initialization is done on-demand and thread safely.This code assumes that race conditions will be rare vs. the expense of creating a T that is thrown away, and that creating, multiple T's in the event of a race, only to cleanup all but one right away, is ok. If you must not ever create more than one T, then other code is needed.Easiest is to initialize a critical section in DllMain and then just use that. Or implement a little spin lock, assuming initialization of T is cheap. In Vista there is a "once" synchronization object for handling this.It is very disappointing that this wasn't introduced 10+ years ago.As well as statically initializable locks and reader/writer locks. I keep tending to think that Modula-3 module intializers have this same lock, at least on Windows.But that is definitely NOT necessariiy true, at least in the face of static linking, and probably even with dynamic linking, since Modula-3 implements this stuff itself. I'll have to review the code. Maybe it is just fine already. If it isn't, well, there are a few easy solutions.As well, this could be a problem on all platforms.So it might make sense for the runtime to recognize when it is calling module initializers and endeavor to "not start" any threads while they are running. Corrallary, on Win32, and in this scheme, that if you create  a thread in DllMain/thread initializer and then wait for it to make progress, you deadlock. Gotta run, - Jay


CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] eliminate Target.Global_handler_stack?Date: Mon, 12 May 2008 19:43:35 -0400

On May 12, 2008, at 7:35 PM, Jay wrote:

Target.Global_handler_stack is FALSE for targets that ever use kernel threads.Target.Global_handler_stack is TRUE for targets that never use kernel threads.Targets that can go either way set it to FALSE. When Global_handler_stack is TRUE, inline code is generated to,  I guess, manipulate a per-thread linked list of stack frames. When Global_handler_stack is FALSE, function calls are generated  to do same. That is, Global_handler_stack is TRUE is a little more efficient. Given that Global_handler_stack is TRUE for all "recent", "active", "interesting"  targets, with the presumably temporary exception of PPC_LINUX, how about  we remove Global_handler_stack as a variable and just act as if it is always FALSE?
Don't you mean "false" for all current targets (i.e., using threads)?


(I have some suspicion that this linked list is absent on targets with a stack walker, so it'd make no difference on them. I'll check later..NT386 ought use fs:0 but it doesn't.)

Indeed, the list is absent on such targets.

I figure target-specificity should be minimized.Make it easier to bring up new targets -- not that the code isn't pretty  well commented and easy to understand, so it's really no easier without this.
I have no  objection. 


The counterpoints would be:  Even if it is target-specific, it does work and isn't complicated, so leave it alone.  If those old targets are alive, and lack pthreads, it is slightly faster this way.  If people want current/new targets to have a "faster" single threaded mode, this    could be part of that. Note though that single threaded apps can't/don't exist,   unless maybe if you never heap allocate, since the heap allocator/garbage collector   creates a thread at initialization (shouldn't it wait for a heap allocation? Maybe.   If there really is a chance it won't occur or won't occur for a while).

When does the GC currently create a thread?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Tue May 13 15:52:08 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 13 May 2008 13:52:08 +0000
Subject: [M3devel] open vs. fixed arrays?
Message-ID: 




I'm being a bit lazy here. I could experiment more with the compiler and check the green book.  The compiler does not correctly implement:    VAR a : ARRAY [0..0] OF CHAR := ARRAY OF CHAR {'a'};  at least for reasons of alignment.  What is this code supposed to mean?  Is ARRAY OF CHAR {'a'} a constant fixed array with a deduced size of 1?Or a constant open array with a deduced size of 1?I believe it is supposed to be a constant open array.  And then, what is the difference?What are the visible differences?  Between  VAR a : ARRAY [0..0] OF CHAR := ARRAY OF CHAR {'a'};and  VAR a : ARRAY [0..0] OF CHAR := ARRAY [0..0] OF CHAR {'a'}; Can I act on "a" different at runtime between the two?Given that its static type is the same, I doubt it. But I haven't really thought about it.  If there is no visible difference, should the compiler implement it as the second -- probably saving a tiny bit of space.  And if not, is it supposed to generate an open array, and an initializer to do the copy?  A constant likeCONST a = ARRAY OF CHAR{'a'}  is an open array I believe, with visible differences, I think, not sure,so in the unlikely even that a "bigger" change is ok here, it has to be careful of this and other scenarios.  Really, I'm just being a bit slow. I bet these should remain open arrays but somewhere the compiler gets confused and computes the alignment and perhaps size as a fixed array, leading to assertion failures in the compiler, depending on the actual sizes, e.g.:  MODULE Main;<*UNUSED*> VAR a : ARRAY [0..0] OF CHAR := ARRAY OF CHAR {'a'};<*UNUSED*> VAR b : ARRAY OF CHAR := ARRAY OF CHAR {'a'};BEGINEND.  fails an assertion in the compiler, depending on the target -- but I expect all x86/AMD64 targets. Thanks,  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From hosking at cs.purdue.edu  Tue May 13 17:28:24 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 13 May 2008 11:28:24 -0400
Subject: [M3devel] open vs. fixed arrays?
In-Reply-To: 
References: 
Message-ID: 


On May 13, 2008, at 9:52 AM, Jay wrote:

> I'm being a bit lazy here. I could experiment more with the compiler  
> and check the green book.
>
>
> The compiler does not correctly implement:
>
>
>
>  VAR a : ARRAY [0..0] OF CHAR := ARRAY OF CHAR {'a'};
>
> at least for reasons of alignment.
>
>
> What is this code supposed to mean?
It should assign the elements of the open array to those of the fixed  
array.
>
>
>
> Is ARRAY OF CHAR {'a'} a constant fixed array with a deduced size of  
> 1?

No, it is open.

>
> Or a constant open array with a deduced size of 1?
No.
> I believe it is supposed to be a constant open array.
Yes.

>
>
> And then, what is the difference?
> What are the visible differences?
>
>
> Between
>
>  VAR a : ARRAY [0..0] OF CHAR := ARRAY OF CHAR {'a'};
> and
>   VAR a : ARRAY [0..0] OF CHAR := ARRAY [0..0] OF CHAR {'a'};
>
> Can I act on "a" different at runtime between the two?
> Given that its static type is the same, I doubt it. But I haven't  
> really thought about it.
>
>
> If there is no visible difference, should the compiler implement it  
> as the second -- probably saving a tiny bit of space.
>
>
> And if not, is it supposed to generate an open array, and an  
> initializer to do the copy?
Probably should.

>
>
>
> A constant like
> CONST a = ARRAY OF CHAR{'a'}
>
>
> is an open array I believe, with visible differences, I think, not  
> sure,
> so in the unlikely even that a "bigger" change is ok here, it has to  
> be careful of this and other scenarios.
>
>
> Really, I'm just being a bit slow. I bet these should remain open  
> arrays but somewhere the compiler gets confused and computes the  
> alignment and perhaps size as a fixed array, leading to assertion  
> failures in the compiler, depending on the actual sizes, e.g.:
>
>
> MODULE Main;
> <*UNUSED*> VAR a : ARRAY [0..0] OF CHAR := ARRAY OF CHAR {'a'};
> <*UNUSED*> VAR b : ARRAY OF CHAR := ARRAY OF CHAR {'a'};
> BEGIN
> END.
>
>
> fails an assertion in the compiler, depending on the target -- but I  
> expect all x86/AMD64 targets.
>
> Thanks,
>  - Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Wed May 14 19:18:54 2008
From: jayk123 at hotmail.com (Jay)
Date: Wed, 14 May 2008 17:18:54 +0000
Subject: [M3devel] _lowbits / _highbits (Pixmap bug-- 4.1 vs. buggy 5.x)
In-Reply-To: 
References: 
Message-ID: 

1) Just fyi, NT386GNU didn't build with my fix, so it is disabled there only, and the bug could very well be present there.
Er, then again, this stuff works differently for the gcc backend, so I don't know, I'll have to look, and run the tests, not today.
Which reminds me also, these symbols should be static hand.c, except for NT386 -- the source can't tell, so it'll have to be a define from the m3makefile.
 
2) Can anyone confirm my history and the missing source?
ie: Confirm that what is marked as 4.1 and 5.1 in CVS really is 4.1 and 5.1? I don't think 4.1 is accurately marked.
In particular, I don't think the 4.1 Stackx86.m3  is what 4.1 actually shipped.
 
3) Or confirm my analysis that leads to the "accusation"? It was tedious.
 
 - Jay


From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Sat, 10 May 2008 15:40:40 +0000Subject: [M3devel] _lowbits / _highbits (Pixmap bug-- 4.1 vs. buggy 5.x)


There is SOME evidence that this lowbits/highbitsproblem is a regression introduced in Critical Mass 5.1.And there are inconsistent data.(I believe 5.1 is the name given to the Critical Mass tree at the time it was open-sourced, vs. 4.1 which was commercially released, and some source withheld.) The source history is a little incomplete.Critical Mass 4.1 did not ship with complete source.In particular, the compiler source is missing.Libraries are there. Aside: I wonder if the 4.1 release can be made more widelyavailable, for purposes such as this. For one thing, I can contributehow to trivially patch the NT386 binary to not care about the registration key.I did buy it, but finding the key is..difficult. The Elegosoft repository claims to have an import of 4.1 followed by an update to 5.1, but it is suspicious. 3.6 Stackx86.m3 -- no reference to  _lowbits / _highbits3.6 hand.c -- no implementation of ditto3.6 didn't offer dynamic linking, so it would have been ok. The 4.1 CD includes the 3.6 source in "contrib" and some of the4.1 source in "source". That confused me at first, to have two of everything.I merely ASSUME what is what. I didn't look in detail. 4.1 CD hand.c -- no implementation of _lowbits / _highbits4.1 CD Stackx86.m3 -- source not available, darn it 4.1 in repository hand.c -- no implementation of ditto4.1 in repositoy Stackx86.m3 -- references _lowbits / _highbits 5.1 in repository hand.c -- implementation of ditto5.1 in repositoy Stackx86.m3 -- no change The supposed 4.1 to 5.1 lack of diff (not that I understand CVS revision numbers or anything...) http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3back/src/Stackx86.m3.diff?r1=1.1;r2=1.1.1.1 introduction of _lowbits / _highbits in a more belieable 4.1 to 5.1 diff: http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/Csupport/Common/hand.c.diff?r1=1.1.1.1;r2=1.1.1.2 This is all a bit tedious so someone please double check me. The 4.1 source in the repository is not self consistent.I contend it is wrong.I contend that the 4.1 Stackx86.m3 is more like the 3.6 -- no use of highbits / lowbits.Since the symbols are not exported from the 4.1 CD m3core.dll nor are in the 4.1 CD hand.c source. 5.1 in the repository is self consistent, and I contend has the bug. The 4.1 m3core.dll does export HiBits / LoBits -- different spelling, different casing,  and none of the .dlls in the system import them.  Several versions have LoBits / HiBits be file-level static, further    implying they aren't used outside of hand.c.  It is difficult for me to browse the old version of the tree however.  I guess I should try something like checkout -revision 1 and then search that locally?  Inspection says that HiBits / LoBits went static in 2003 here:  http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/Csupport/Common/hand.c   and then later, I made them non-static FOR 32 BIT TARGETS, as part of merging them with  _lowbits / _highbits. This is a bit tangential, but the point is to exonerate  LoBits / HiBits of any involvement. _lowbits / _highbits are the relevant party.  They are nearly identical. See hand.c for how they relate. There is an extra  entry in one pair or the other, either at the start or the end, and one is uint and the  other ulong, when sizeof(uint) == sizeof(ulong), they share storage, my doing.  The NT386 compiler references _lowbits / _highbits. LoBits / HiBits are only used internally to hand.c.  The gcc backend does not reference _lowbits / _highbits.So obviously another fix is to go back to the 3.6 code and remove the symbols entirely.And make sure m3tests passes with that.I didn't look at the code yet.In general the code quality is not super high so it probably matters little.Also obviously it would be prudent to review the code here to make sure it is correct,or to look at the relevant unit test and see if it seems comprhensive.  Thoughts?  Presume Critical Mass introduced the regression in 5.1, and give up attaining accurate 4.1 source??I should findstr (grep) against the 4.1 cm3, but the lack of the symbols in its m3core is pretty conclusive.  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Wed May 14 19:25:38 2008
From: jayk123 at hotmail.com (Jay)
Date: Wed, 14 May 2008 17:25:38 +0000
Subject: [M3devel] which platforms?
In-Reply-To: 
References: 
Message-ID: 

What do people run?In particular: NetBSD? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN? I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM_WINCE? AMD64_NT?
 
Just curious, I'll probably bring up whatever I can, it's fun, and yes, get back and fix AMD64_LINUX to have
garbage collection, NT386GNU and NT386 tests, cross-platform sets, setup some Tinderboxes, etc...
 
(AMD64_NT: the gcc available for this includes a bunch of patches, so I'm inclined to either wait for them to go upstream,
or seek an alternate route such as "port" the in-proc backend, llvm, generate C, or maybe write an interpreter for the IL;
and "porting" the backend is probably best preceded by a) x86 LONGINT support b) other x86 targets "for practise", at least one,
though regarding .obj file formats, that would be tangential.)
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Wed May 14 19:46:15 2008
From: jayk123 at hotmail.com (Jay)
Date: Wed, 14 May 2008 17:46:15 +0000
Subject: [M3devel] SPARC32_LINUX
In-Reply-To: 
References: 
Message-ID: 





  I was having some hardware/network problem and as an indirect result, am not running Linux/sparc for a bit.         I was going to make distributions and bring up SPARC64_LINUX, but it'll wait some.          If anyone can help me a bit with Sun-specific problems, please ping me privately.       In the meantime, there is:       http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-base-POSIX-SPARC32_LINUX-1.tar.bz2       It should be called "boot", but something didn't like that.       roughly:       wget http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-base-POSIX-SPARC32_LINUX-1.tar.bz2    tar xf cm3-base-POSIX-SPARC32_LINUX-1.tar.bz2    cd cm3-boot-POSIX-SPARC32_LINUX-1    . ./1.sh    mkdir -p /cm3/bin   cp exe/cm3 /cm3/bin   export PATH=/cm3/bin:$PATH   cd $CVSROOT/scripts/python      ./upgrade.py    and then optionally ./make-dist.py    
 
or, I'm not sure upgrade ships/installs/copies cm3cg, so:
  cd $CVSROOT/scripts/python      ./do-pkg.py m3cc 
  cp ../../m3-sys/m3cc/SPARC32_LINUX/cm3cg /cm3/bin    OMIT_GCC=yes ./upgrade.py         SHOULD work. /usr/local/cm3 should work, but I find that rather long.Actually I never built beyond "front".   And dynamic linking and garbage collection are both off, for now.      Then again, I suspect nobody runs Linux on SPARC, esp. not here.   It was educational though to bring up a platform on which I couldnot rely on an existing ability to run cm3.
I'll TRY to get back and tie up a bunch of loose ends, there are a lot now, I know..
    - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From hosking at cs.purdue.edu  Thu May 15 17:44:21 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 15 May 2008 11:44:21 -0400
Subject: [M3devel] which platforms?
In-Reply-To: 
References: 
	
Message-ID: <6AF85D14-364B-4155-A186-840119342DF7@cs.purdue.edu>


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



On May 14, 2008, at 1:25 PM, Jay wrote:

> What do people run?
> In particular: NetBSD? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN?  
> I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM_WINCE? AMD64_NT?
>
> Just curious, I'll probably bring up whatever I can, it's fun, and  
> yes, get back and fix AMD64_LINUX to have
> garbage collection, NT386GNU and NT386 tests, cross-platform sets,  
> setup some Tinderboxes, etc...
>
> (AMD64_NT: the gcc available for this includes a bunch of patches,  
> so I'm inclined to either wait for them to go upstream,
> or seek an alternate route such as "port" the in-proc backend, llvm,  
> generate C, or maybe write an interpreter for the IL;
> and "porting" the backend is probably best preceded by a) x86  
> LONGINT support b) other x86 targets "for practise", at least one,
> though regarding .obj file formats, that would be tangential.)
>
>  - Jay
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From hosking at cs.purdue.edu  Thu May 15 17:47:41 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 15 May 2008 11:47:41 -0400
Subject: [M3devel] which platforms?
In-Reply-To: 
References: 
	
Message-ID: <948C63CA-8763-46AE-9FDB-54DAF01CC28D@cs.purdue.edu>

SOLgnu
PPC_DARWIN
I386_DARWIN
AMD64_DARWIN
LINUXLIBC6
I'd like AMD64_LINUX, SPARC64_SOLARISN but no time right now to devote  
to them.

On May 14, 2008, at 1:25 PM, Jay wrote:

> What do people run?
> In particular: NetBSD? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN?  
> I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM_WINCE? AMD64_NT?
>
> Just curious, I'll probably bring up whatever I can, it's fun, and  
> yes, get back and fix AMD64_LINUX to have
> garbage collection, NT386GNU and NT386 tests, cross-platform sets,  
> setup some Tinderboxes, etc...
>
> (AMD64_NT: the gcc available for this includes a bunch of patches,  
> so I'm inclined to either wait for them to go upstream,
> or seek an alternate route such as "port" the in-proc backend, llvm,  
> generate C, or maybe write an interpreter for the IL;
> and "porting" the backend is probably best preceded by a) x86  
> LONGINT support b) other x86 targets "for practise", at least one,
> though regarding .obj file formats, that would be tangential.)
>
>  - Jay
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From darko at darko.org  Thu May 15 21:50:31 2008
From: darko at darko.org (Darko)
Date: Thu, 15 May 2008 21:50:31 +0200
Subject: [M3devel] which platforms?
In-Reply-To: 
References: 
	
Message-ID: <4599968C-BCFA-4A5E-B50A-7E1A589B7C30@darko.org>

I'd really like to see some ARM backends in particular ARM_DARWIN  
(iPod Touch, iPhone), ARM_NOKIA (on their Open C API) and ARM_WINCE.  
This would have CM3 the gamut from servers to small handheld devices.


On 14/05/2008, at 7:25 PM, Jay wrote:

> What do people run?
> In particular: NetBSD? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN?  
> I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM_WINCE? AMD64_NT?
>
> Just curious, I'll probably bring up whatever I can, it's fun, and  
> yes, get back and fix AMD64_LINUX to have
> garbage collection, NT386GNU and NT386 tests, cross-platform sets,  
> setup some Tinderboxes, etc...
>
> (AMD64_NT: the gcc available for this includes a bunch of patches,  
> so I'm inclined to either wait for them to go upstream,
> or seek an alternate route such as "port" the in-proc backend, llvm,  
> generate C, or maybe write an interpreter for the IL;
> and "porting" the backend is probably best preceded by a) x86  
> LONGINT support b) other x86 targets "for practise", at least one,
> though regarding .obj file formats, that would be tangential.)
>
>  - Jay
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Thu May 15 22:19:16 2008
From: jayk123 at hotmail.com (Jay)
Date: Thu, 15 May 2008 20:19:16 +0000
Subject: [M3devel] which platforms?
In-Reply-To: <4599968C-BCFA-4A5E-B50A-7E1A589B7C30@darko.org>
References: 
	
	<4599968C-BCFA-4A5E-B50A-7E1A589B7C30@darko.org>
Message-ID: 

Oh -- iPod Touch -- iPhone hardware/software without a service plan. Clever. :)
I don't know about Nokia but definitely CE and somewhat iPhone "intrigue" me (as in, I never use this stuff, but a port sounds interesting).
I'm hoping CE can be done with free beer emulators but I don't have anything up and running dev tool wise there, other than older command line compilers (for a bunch of CE -- arm, mips, powepc, sh, x86). I'm not confident gcc will move so easily to new Windows platforms, without significant patches, so C or LLVM might be good.
Yeah I wasn't sure ARM_IPHONE or ARM_DARWIN. :)
I'd still like to call it ARCH_MACOSX or ARCH_MACX oh well too late.
 
None of these things have X servers, right?
And gui is hard anyway on small screens, "less portable".
Port to Qt??
I'm not going there any time soon, very little familiarity with either Trestle or the underlying systems..
Headless servers and command line apps on phones for now. :)
 
 - Jay
 



CC: m3devel at elegosoft.comFrom: darko at darko.orgTo: jayk123 at hotmail.comSubject: Re: [M3devel] which platforms?Date: Thu, 15 May 2008 21:50:31 +0200

I'd really like to see some ARM backends in particular ARM_DARWIN (iPod Touch, iPhone), ARM_NOKIA (on their Open C API) and ARM_WINCE. This would have CM3 the gamut from servers to small handheld devices.


On 14/05/2008, at 7:25 PM, Jay wrote:

What do people run?In particular: NetBSD? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN? I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM_WINCE? AMD64_NT? Just curious, I'll probably bring up whatever I can, it's fun, and yes, get back and fix AMD64_LINUX to havegarbage collection, NT386GNU and NT386 tests, cross-platform sets, setup some Tinderboxes, etc... (AMD64_NT: the gcc available for this includes a bunch of patches, so I'm inclined to either wait for them to go upstream,or seek an alternate route such as "port" the in-proc backend, llvm, generate C, or maybe write an interpreter for the IL;and "porting" the backend is probably best preceded by a) x86 LONGINT support b) other x86 targets "for practise", at least one,though regarding .obj file formats, that would be tangential.)  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From darko at darko.org  Thu May 15 22:55:58 2008
From: darko at darko.org (Darko)
Date: Thu, 15 May 2008 22:55:58 +0200
Subject: [M3devel] which platforms?
In-Reply-To: 
References: 
	
	<4599968C-BCFA-4A5E-B50A-7E1A589B7C30@darko.org>
	
Message-ID: <21F3FBDA-3DE6-4DA0-951A-E5F4BE999F52@darko.org>

I haven't seen X for any of them but I guess its not beyond the realm  
of possibility. I'm mostly interested in native user interfaces and  
porting the native APIs for M3. Darwin is the name of lower levels of  
the OS of the Mac and iPhone and is open source, so its appropriate.

Apple provide a GCC for the ARM and Darwin. There is GCC for ARM under  
WinCE platforms. I would have though the issues are mainly with the M3  
runtime on these platforms.



On 15/05/2008, at 10:19 PM, Jay wrote:

> Oh -- iPod Touch -- iPhone hardware/software without a service plan.  
> Clever. :)
> I don't know about Nokia but definitely CE and somewhat iPhone  
> "intrigue" me (as in, I never use this stuff, but a port sounds  
> interesting).
> I'm hoping CE can be done with free beer emulators but I don't have  
> anything up and running dev tool wise there, other than older  
> command line compilers (for a bunch of CE -- arm, mips, powepc, sh,  
> x86). I'm not confident gcc will move so easily to new Windows  
> platforms, without significant patches, so C or LLVM might be good.
> Yeah I wasn't sure ARM_IPHONE or ARM_DARWIN. :)
> I'd still like to call it ARCH_MACOSX or ARCH_MACX oh well too late.
>
> None of these things have X servers, right?
> And gui is hard anyway on small screens, "less portable".
> Port to Qt??
> I'm not going there any time soon, very little familiarity with  
> either Trestle or the underlying systems..
> Headless servers and command line apps on phones for now. :)
>
>  - Jay
>
>
>
> CC: m3devel at elegosoft.com
> From: darko at darko.org
> To: jayk123 at hotmail.com
> Subject: Re: [M3devel] which platforms?
> Date: Thu, 15 May 2008 21:50:31 +0200
>
>
> I'd really like to see some ARM backends in particular ARM_DARWIN  
> (iPod Touch, iPhone), ARM_NOKIA (on their Open C API) and ARM_WINCE.  
> This would have CM3 the gamut from servers to small handheld devices.
>
>
> On 14/05/2008, at 7:25 PM, Jay wrote:
>
> What do people run?
> In particular: NetBSD? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN?  
> I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM_WINCE? AMD64_NT?
>
> Just curious, I'll probably bring up whatever I can, it's fun, and  
> yes, get back and fix AMD64_LINUX to have
> garbage collection, NT386GNU and NT386 tests, cross-platform sets,  
> setup some Tinderboxes, etc...
>
> (AMD64_NT: the gcc available for this includes a bunch of patches,  
> so I'm inclined to either wait for them to go upstream,
> or seek an alternate route such as "port" the in-proc backend, llvm,  
> generate C, or maybe write an interpreter for the IL;
> and "porting" the backend is probably best preceded by a) x86  
> LONGINT support b) other x86 targets "for practise", at least one,
> though regarding .obj file formats, that would be tangential.)
>
>  - Jay
>
>
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mika at async.caltech.edu  Thu May 15 23:30:36 2008
From: mika at async.caltech.edu (Mika Nystrom)
Date: Thu, 15 May 2008 14:30:36 -0700
Subject: [M3devel] which platforms?
In-Reply-To: Your message of "Thu, 15 May 2008 11:47:41 EDT."
	<948C63CA-8763-46AE-9FDB-54DAF01CC28D@cs.purdue.edu> 
Message-ID: <200805152130.m4FLUa9B060478@camembert.async.caltech.edu>

here it is:

FreeBSD4
PPC_DARWIN
NT386GNU
LINUXLIBC6

I386_DARWIN coming soon

Tony Hosking writes:
>
>--Apple-Mail-4-631028010
>Content-Type: text/plain;
>	charset=US-ASCII;
>	format=flowed;
>	delsp=yes
>Content-Transfer-Encoding: 7bit
>
>SOLgnu
>PPC_DARWIN
>I386_DARWIN
>AMD64_DARWIN
>LINUXLIBC6
>I'd like AMD64_LINUX, SPARC64_SOLARISN but no time right now to devote  
>to them.
>
>On May 14, 2008, at 1:25 PM, Jay wrote:
>
>> What do people run?
>> In particular: NetBSD? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN?  
>> I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM_WINCE? AMD64_NT?
>>
>> Just curious, I'll probably bring up whatever I can, it's fun, and  
>> yes, get back and fix AMD64_LINUX to have
>> garbage collection, NT386GNU and NT386 tests, cross-platform sets,  
>> setup some Tinderboxes, etc...
>>
>> (AMD64_NT: the gcc available for this includes a bunch of patches,  
>> so I'm inclined to either wait for them to go upstream,
>> or seek an alternate route such as "port" the in-proc backend, llvm,  
>> generate C, or maybe write an interpreter for the IL;
>> and "porting" the backend is probably best preceded by a) x86  
>> LONGINT support b) other x86 targets "for practise", at least one,
>> though regarding .obj file formats, that would be tangential.)
>>
>>  - Jay
>>
>>
>>
>>
>
>
>--Apple-Mail-4-631028010
>Content-Type: text/html;
>	charset=US-ASCII
>Content-Transfer-Encoding: quoted-printable
>
>-webkit-line-break: after-white-space; ">
apple-content-edited=3D"true">style=3D"border-collapse: separate; border-spacing: 0px 0px; color: =
>rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
>normal; font-variant: normal; font-weight: normal; letter-spacing: =
>normal; line-height: normal; text-align: auto; =
>-khtml-text-decorations-in-effect: none; text-indent: 0px; =
>-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; ">
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
>-khtml-line-break: after-white-space; ">style=3D"border-collapse: separate; border-spacing: 0px 0px; color: =
>rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
>normal; font-variant: normal; font-weight: normal; letter-spacing: =
>normal; line-height: normal; text-align: auto; =
>-khtml-text-decorations-in-effect: none; text-indent: 0px; =
>-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; =
>">SOLgnu
-khtml-nbsp-mode: space; -khtml-line-break: after-white-space; =
>">PPC_DARWIN
space; -khtml-line-break: after-white-space; ">I386_DARWIN
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
>-khtml-line-break: after-white-space; ">AMD64_DARWIN
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
>-khtml-line-break: after-white-space; ">LINUXLIBC6
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
>-khtml-line-break: after-white-space; ">I'd like AMD64_LINUX, class=3D"Apple-style-span" style=3D"font-family: Tahoma; font-size: =
>13px; ">SPARC64_SOLARISN but no time right now to devote to =
>them.

On May 14, 2008, at 1:25 =
>PM, Jay wrote:

type=3D"cite">separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; orphans: 2; text-align: =
>auto; text-indent: 0px; text-transform: none; white-space: normal; =
>widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
>-webkit-border-vertical-spacing: 0px; =
>-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
>auto; -webkit-text-stroke-width: 0; ">
style=3D"font-size: 10pt; font-family: Tahoma; ">What do people =
>run?
In particular: NetBSD? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN? =
>I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM_WINCE? =
>AMD64_NT?
 
Just curious, I'll probably bring up whatever I =
>can, it's fun, and yes, get back and fix AMD64_LINUX to have
garbage =
>collection, NT386GNU and NT386 tests, cross-platform sets, setup =
>some Tinderboxes, etc...
 
(AMD64_NT: the gcc available for =
>this includes a bunch of patches, so I'm inclined to either wait for =
>them to go upstream,
or seek an alternate route such as "port" the =
>in-proc backend, llvm, generate C, or maybe write an interpreter for the =
>IL;
and "porting" the backend is probably best preceded by a) x86 =
>LONGINT support b) other x86 targets "for practise", at least =
>one,
though regarding .obj file formats, that would be =
>tangential.)
 
 - =
>Jay





=
>
>--Apple-Mail-4-631028010--


From jayk123 at hotmail.com  Fri May 16 00:43:30 2008
From: jayk123 at hotmail.com (Jay)
Date: Thu, 15 May 2008 22:43:30 +0000
Subject: [M3devel] which platforms? and questions about FreeBSD
 versioning
In-Reply-To: <200805152130.m4FLUa9B060478@camembert.async.caltech.edu>
References: Your message of "Thu, 15 May 2008 11:47:41 EDT."
	<948C63CA-8763-46AE-9FDB-54DAF01CC28D@cs.purdue.edu>  
	<200805152130.m4FLUa9B060478@camembert.async.caltech.edu>
Message-ID: 

Mika, ok, this is tangential: Have you tried the current NT386GNU cm3?
 
I meant, more about what "operating systems" that Modula-3 does not support do people here use, would like to see Modula-3 on. Or maybe I meant both.
 
Speaking of the "4" in FreeBSD4:
 
Has FreeBSD, and the other BSDs, really broken backward compat?
They really change interfaces a lot such that binaries built with current headers/libs won't run on older versions?
And there isn't an easy way on current platforms to build something using older tools to run on older and newer platforms?
Look at Windows for example. If you call a "new" function directly, you will fail to load on older platforms. So either don't call them, or use LoadLibrary/GetProcAddress. Structures almost never change size, though there is some screwiness there, stuff like:
 
struct FOO {  size_t Size;
  int Field1;
#if VERSION > 1234
  int Field2;
#endif
};
 
I think it should be more like:
 
struct FOO {  size_t Size;
  int Field1;
#if VERSION > 1234
  int Field2;
#endif
};
 
struct FOO_V1{  size_t Size;
  int Field1;
};
 
struct FOO_V2 {  size_t Size;
  int Field1;
  int Field2;
};
 
#if VERSION > 1234
typedef FOO_V2 FOO;
#else
typedef FOO_V1 FOO;
#endif
 
I understand that binaries built on the older platform will continue to work on the newer platform.
That is one thing.
But it is also useful to be able to build binaries on the newer platform that will on the older platform.
Apple also invests a bunch here.
 
Well, ok, if it was really "bad", there'd be FreeBSD5, 6, 7.
I guess maybe they broke this stuff sometimes but haven't in a while?
That you can build FreeBSD4 binaries on FreeBSD7 and the run down to 4?
 
And then, same questions about OpenBSD and NetBSD.
I understand -- I could/must go and install a bajillion operating systems and test and find out, but I don't expect to spend the time that way and push comes to shove, any BSD (and Linux, Solaris, NT, CE, etc.) variants I introduce will have no version number in them, will be built on whatever I have, and it will be unknown if they work on older. And maybe something will materialize to be more portable, like interfacing to the Posix via C instead of cloned headers.
 
 - Jay



> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] which platforms? > Date: Thu, 15 May 2008 14:30:36 -0700> From: mika at async.caltech.edu> > here it is:> > FreeBSD4> PPC_DARWIN> NT386GNU> LINUXLIBC6> > I386_DARWIN coming soon> > Tony Hosking writes:> >> >--Apple-Mail-4-631028010> >Content-Type: text/plain;> > charset=US-ASCII;> > format=flowed;> > delsp=yes> >Content-Transfer-Encoding: 7bit> >> >SOLgnu> >PPC_DARWIN> >I386_DARWIN> >AMD64_DARWIN> >LINUXLIBC6> >I'd like AMD64_LINUX, SPARC64_SOLARISN but no time right now to devote > >to them.> >> >On May 14, 2008, at 1:25 PM, Jay wrote:> >> >> What do people run?> >> In particular: NetBSD? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN? > >> I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM_WINCE? AMD64_NT?> >>> >> Just curious, I'll probably bring up whatever I can, it's fun, and > >> yes, get back and fix AMD64_LINUX to have> >> garbage collection, NT386GNU and NT386 tests, cross-platform sets, > >> setup some Tinderboxes, etc...> >>> >> (AMD64_NT: the gcc available for this includes a bunch of patches, > >> so I'm inclined to either wait for them to go upstream,> >> or seek an alternate route such as "port" the in-proc backend, llvm, > >> generate C, or maybe write an interpreter for the IL;> >> and "porting" the backend is probably best preceded by a) x86 > >> LONGINT support b) other x86 targets "for practise", at least one,> >> though regarding .obj file formats, that would be tangential.)> >>> >> - Jay> >>> >>> >>> >>> >> >> >--Apple-Mail-4-631028010> >Content-Type: text/html;> > charset=US-ASCII> >Content-Transfer-Encoding: quoted-printable> >> > >-webkit-line-break: after-white-space; ">
 >apple-content-edited=3D"true"> >style=3D"border-collapse: separate; border-spacing: 0px 0px; color: => >rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: => >normal; font-variant: normal; font-weight: normal; letter-spacing: => >normal; line-height: normal; text-align: auto; => >-khtml-text-decorations-in-effect: none; text-indent: 0px; => >-apple-text-size-adjust: auto; text-transform: none; orphans: 2; => >white-space: normal; widows: 2; word-spacing: 0px; ">
 >style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; => >-khtml-line-break: after-white-space; "> >style=3D"border-collapse: separate; border-spacing: 0px 0px; color: => >rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: => >normal; font-variant: normal; font-weight: normal; letter-spacing: => >normal; line-height: normal; text-align: auto; => >-khtml-text-decorations-in-effect: none; text-indent: 0px; => >-apple-text-size-adjust: auto; text-transform: none; orphans: 2; => >white-space: normal; widows: 2; word-spacing: 0px; => >">SOLgnu
 >-khtml-nbsp-mode: space; -khtml-line-break: after-white-space; => >">PPC_DARWIN
 >space; -khtml-line-break: after-white-space; ">I386_DARWIN
 >style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; => >-khtml-line-break: after-white-space; ">AMD64_DARWIN
 >style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; => >-khtml-line-break: after-white-space; ">LINUXLIBC6
 >style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; => >-khtml-line-break: after-white-space; ">I'd like AMD64_LINUX,  >class=3D"Apple-style-span" style=3D"font-family: Tahoma; font-size: => >13px; ">SPARC64_SOLARISN but no time right now to devote to => >them.

On May 14, 2008, at 1:25 => >PM, Jay wrote:

 >type=3D"cite"> >separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; => >font-style: normal; font-variant: normal; font-weight: normal; => >letter-spacing: normal; line-height: normal; orphans: 2; text-align: => >auto; text-indent: 0px; text-transform: none; white-space: normal; => >widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; => >-webkit-border-vertical-spacing: 0px; => >-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: => >auto; -webkit-text-stroke-width: 0; ">
 >style=3D"font-size: 10pt; font-family: Tahoma; ">What do people => >run?
In particular: NetBSD? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN? => >I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM_WINCE? => >AMD64_NT?
 
Just curious, I'll probably bring up whatever I => >can, it's fun, and yes, get back and fix AMD64_LINUX to have
garbage => >collection, NT386GNU and NT386 tests, cross-platform sets, setup => >some Tinderboxes, etc...
 
(AMD64_NT: the gcc available for => >this includes a bunch of patches, so I'm inclined to either wait for => >them to go upstream,
or seek an alternate route such as "port" the => >in-proc backend, llvm, generate C, or maybe write an interpreter for the => >IL;
and "porting" the backend is probably best preceded by a) x86 => >LONGINT support b) other x86 targets "for practise", at least => >one,
though regarding .obj file formats, that would be => >tangential.)
 
 - => >Jay





=> >> >--Apple-Mail-4-631028010--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mika at async.caltech.edu  Fri May 16 07:54:28 2008
From: mika at async.caltech.edu (Mika Nystrom)
Date: Thu, 15 May 2008 22:54:28 -0700
Subject: [M3devel] which platforms? and questions about FreeBSD
	versioning
In-Reply-To: Your message of "Thu, 15 May 2008 22:43:30 -0000."
	 
Message-ID: <200805160554.m4G5sShX067480@camembert.async.caltech.edu>


No, sorry, haven't gotten around to testing the current NT386GNU
cm3... I have a lot of version synchronizing to do, unfortunately :(

Yes, FreeBSD is backwards-compatible, *not* forwards-compatible.
That is, you can build even fairly complex software packages on an old
FreeBSD system and expect it to run on the latest release.  You cannot,
as a general rule, build anything on a newer system and expect it to work
on an older one.  There must be "some" way of doing it that way, but
I don't know what it is, and I don't know if it's very well supported.
I keep FreeBSD 4.x systems around for precisely this reason: the binaries
compiled there work fine on 5.x and 6.x (as far as I have tested).  Not
the other way around!  In fact it has never worked the other way, as 
long as I can remember, with FreeBSD.

This is also why I suggest that a "FreeBSD4" bootstrap should actually
be built on FreeBSD 4.x and not 5.x, 6.x, or 7.x!

    Mika

Jay writes:
>--_14c076c4-fb7c-48b0-b705-2e38d4b4a333_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>Mika, ok, this is tangential: Have you tried the current NT386GNU cm3?
>=20
>I meant, more about what "operating systems" that Modula-3 does not support=
> do people here use, would like to see Modula-3 on. Or maybe I meant both.
>=20
>Speaking of the "4" in FreeBSD4:
>=20
>Has FreeBSD, and the other BSDs, really broken backward compat?
>They really change interfaces a lot such that binaries built with current h=
>eaders/libs won't run on older versions?
>And there isn't an easy way on current platforms to build something using o=
>lder tools to run on older and newer platforms?
>Look at Windows for example. If you call a "new" function directly, you wil=
>l fail to load on older platforms. So either don't call them, or use LoadLi=
>brary/GetProcAddress. Structures almost never change size, though there is =
>some screwiness there, stuff like:
>=20
>struct FOO {  size_t Size;
>  int Field1;
>#if VERSION > 1234
>  int Field2;
>#endif
>};
>=20
>I think it should be more like:
>=20
>struct FOO {  size_t Size;
>  int Field1;
>#if VERSION > 1234
>  int Field2;
>#endif
>};
>=20
>struct FOO_V1{  size_t Size;
>  int Field1;
>};
>=20
>struct FOO_V2 {  size_t Size;
>  int Field1;
>  int Field2;
>};
>=20
>#if VERSION > 1234
>typedef FOO_V2 FOO;
>#else
>typedef FOO_V1 FOO;
>#endif
>=20
>I understand that binaries built on the older platform will continue to wor=
>k on the newer platform.
>That is one thing.
>But it is also useful to be able to build binaries on the newer platform th=
>at will on the older platform.
>Apple also invests a bunch here.
>=20
>Well, ok, if it was really "bad", there'd be FreeBSD5, 6, 7.
>I guess maybe they broke this stuff sometimes but haven't in a while?
>That you can build FreeBSD4 binaries on FreeBSD7 and the run down to 4?
>=20
>And then, same questions about OpenBSD and NetBSD.
>I understand -- I could/must go and install a bajillion operating systems a=
>nd test and find out, but I don't expect to spend the time that way and pus=
>h comes to shove, any BSD (and Linux, Solaris, NT, CE, etc.) variants I int=
>roduce will have no version number in them, will be built on whatever I hav=
>e, and it will be unknown if they work on older. And maybe something will m=
>aterialize to be more portable, like interfacing to the Posix via C instead=
> of cloned headers.
>=20
> - Jay
>
>
>
>> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel=
>] which platforms? > Date: Thu, 15 May 2008 14:30:36 -0700> From: mika at asyn=
>c.caltech.edu> > here it is:> > FreeBSD4> PPC_DARWIN> NT386GNU> LINUXLIBC6>=
> > I386_DARWIN coming soon> > Tony Hosking writes:> >> >--Apple-Mail-4-6310=
>28010> >Content-Type: text/plain;> > charset=3DUS-ASCII;> > format=3Dflowed=
>;> > delsp=3Dyes> >Content-Transfer-Encoding: 7bit> >> >SOLgnu> >PPC_DARWIN=
>> >I386_DARWIN> >AMD64_DARWIN> >LINUXLIBC6> >I'd like AMD64_LINUX, SPARC64_=
>SOLARISN but no time right now to devote > >to them.> >> >On May 14, 2008, =
>at 1:25 PM, Jay wrote:> >> >> What do people run?> >> In particular: NetBSD=
>? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN? > >> I386_SOLARIS? AMD64_SOLARIS=
>? SPARC64_SOLARIS? ARM_WINCE? AMD64_NT?> >>> >> Just curious, I'll probably=
> bring up whatever I can, it's fun, and > >> yes, get back and fix AMD64_LI=
>NUX to have> >> garbage collection, NT386GNU and NT386 tests, cross-platfor=
>m sets, > >> setup some Tinderboxes, etc...> >>> >> (AMD64_NT: the gcc avai=
>lable for this includes a bunch of patches, > >> so I'm inclined to either =
>wait for them to go upstream,> >> or seek an alternate route such as "port"=
> the in-proc backend, llvm, > >> generate C, or maybe write an interpreter =
>for the IL;> >> and "porting" the backend is probably best preceded by a) x=
>86 > >> LONGINT support b) other x86 targets "for practise", at least one,>=
> >> though regarding .obj file formats, that would be tangential.)> >>> >> =
>- Jay> >>> >>> >>> >>> >> >> >--Apple-Mail-4-631028010> >Content-Type: text=
>/html;> > charset=3DUS-ASCII> >Content-Transfer-Encoding: quoted-printable>=
> >> >; =3D> >-webkit-line-break: after-white-space; ">
 >apple-content-e=
>dited=3D3D"true"> >style=3D3D"border=
>-collapse: separate; border-spacing: 0px 0px; color: =3D> >rgb(0, 0, 0); fo=
>nt-family: Helvetica; font-size: 12px; font-style: =3D> >normal; font-varia=
>nt: normal; font-weight: normal; letter-spacing: =3D> >normal; line-height:=
> normal; text-align: auto; =3D> >-khtml-text-decorations-in-effect: none; t=
>ext-indent: 0px; =3D> >-apple-text-size-adjust: auto; text-transform: none;=
> orphans: 2; =3D> >white-space: normal; widows: 2; word-spacing: 0px; ">v =3D> >style=3D3D"word-wrap: break-word; -khtml-nbsp-mode: space; =3D> >-k=
>html-line-break: after-white-space; ">=3D> >style=3D3D"border-collapse: separate; border-spacing: 0px 0px; color:=
> =3D> >rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
>=3D> >normal; font-variant: normal; font-weight: normal; letter-spacing: =
>=3D> >normal; line-height: normal; text-align: auto; =3D> >-khtml-text-deco=
>rations-in-effect: none; text-indent: 0px; =3D> >-apple-text-size-adjust: a=
>uto; text-transform: none; orphans: 2; =3D> >white-space: normal; widows: 2=
>; word-spacing: 0px; =3D> >">SOLgnu
break-word; =3D> >-khtml-nbsp-mode: space; -khtml-line-break: after-white-s=
>pace; =3D> >">PPC_DARWIN
-nbsp-mode: =3D> >space; -khtml-line-break: after-white-space; ">I386_DARWI=
>N
 >style=3D3D"word-wrap: break-word; -khtml-nbsp-mode: space=
>; =3D> >-khtml-line-break: after-white-space; ">AMD64_DARWIN
=
> >style=3D3D"word-wrap: break-word; -khtml-nbsp-mode: space; =3D> >-khtml-l=
>ine-break: after-white-space; ">LINUXLIBC6
 >style=3D3D"word-=
>wrap: break-word; -khtml-nbsp-mode: space; =3D> >-khtml-line-break: after-w=
>hite-space; ">I'd like AMD64_LINUX,  >class=3D3D"Apple-style=
>-span" style=3D3D"font-family: Tahoma; font-size: =3D> >13px; ">SPARC64_SOL=
>ARISN but no time right now to devote to =3D> >them.
iv>
On May 14, 2008, at 1:25 =3D> >PM, Jay wrote:

ss=3D3D"Apple-interchange-newline">
 >type=3D3D"cite">class=3D3D"Apple-style-span" style=3D3D"border-collapse: =3D> >separate; co=
>lor: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =3D> >font-styl=
>e: normal; font-variant: normal; font-weight: normal; =3D> >letter-spacing:=
> normal; line-height: normal; orphans: 2; text-align: =3D> >auto; text-inde=
>nt: 0px; text-transform: none; white-space: normal; =3D> >widows: 2; word-s=
>pacing: 0px; -webkit-border-horizontal-spacing: 0px; =3D> >-webkit-border-v=
>ertical-spacing: 0px; =3D> >-webkit-text-decorations-in-effect: none; -webk=
>it-text-size-adjust: =3D> >auto; -webkit-text-stroke-width: 0; ">
=3D3D"hmmessage" =3D> >style=3D3D"font-size: 10pt; font-family: Tahoma; ">W=
>hat do people =3D> >run?
In particular: NetBSD? OpenBSD? Sparc32? Sparc6=
>4? PPC64_DARWIN? =3D> >I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM_WI=
>NCE? =3D> >AMD64_NT?
 
Just curious, I'll probably bring up what=
>ever I =3D> >can, it's fun, and yes, get back and fix AMD64_LINUX to haver>garbage =3D> >collection, NT386GNU and NT386 tests, cross-platform s=
>ets, setup =3D> >some Tinderboxes, etc...
 
(AMD64_NT: the gcc a=
>vailable for =3D> >this includes a bunch of patches, so I'm inclined to eit=
>her wait for =3D> >them to go upstream,
or seek an alternate route such =
>as "port" the =3D> >in-proc backend, llvm, generate C, or maybe write an in=
>terpreter for the =3D> >IL;
and "porting" the backend is probably best p=
>receded by a) x86 =3D> >LONGINT support b) other x86 targets "for practise"=
>, at least =3D> >one,
though regarding .obj file formats, that would be =
>=3D> >tangential.)
 
 - =3D> >Jay




=
>

=3D> >> >--Apple-Mail-4-6310280=
>10--=
>
>--_14c076c4-fb7c-48b0-b705-2e38d4b4a333_
>Content-Type: text/html; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>
>
>
>
>Mika, ok, this is tangential: Have you =
>tried the current NT386GNU cm3?

> 

>I meant, more about what "operating systems" that Modula-3 does not support=
> do people here use, would like to see Modula-3 on. Or maybe I meant both.<=
>BR>
> 

>Speaking of the "4" in FreeBSD4:

> 

>Has FreeBSD, and the other BSDs, really broken backward compat?

>They really change interfaces a lot such that binaries built with current h=
>eaders/libs won't run on older versions?

>And there isn't an easy way on current platforms to build something using o=
>lder tools to run on older and newer platforms?

>Look at Windows for example. If you call a "new" function directly, you wil=
>l fail to load on older platforms. So either don't call them, or use LoadLi=
>brary/GetProcAddress. Structures almost never change size, though there is =
>some screwiness there, stuff like:

> 

>struct FOO {
  size_t Size;

>  int Field1;

>#if VERSION > 1234

>  int Field2;

>#endif

>};

> 

>I think it should be more like:

> 

>struct FOO {
  size_t Size;

>  int Field1;

>#if VERSION > 1234

>  int Field2;

>#endif

>};

> 

>struct FOO_V1{
  size_t Size;

>  int Field1;

>};

> 

>struct FOO_V2 {
  size_t Size;

>  int Field1;

>  int Field2;

>};

> 

>#if VERSION > 1234

>typedef FOO_V2 FOO;

>#else

>typedef FOO_V1 FOO;

>#endif

> 

>I understand that binaries built on the older platform will continue to wor=
>k on the newer platform.

>That is one thing.

>But it is also useful to be able to build binaries on the newer platform th=
>at will on the older platform.

>Apple also invests a bunch here.

> 

>Well, ok, if it was really "bad", there'd be FreeBSD5, 6, 7.

>I guess maybe they broke this stuff sometimes but haven't in a while?

>That you can build FreeBSD4 binaries on FreeBSD7 and the run down to 4?

> 

>And then, same questions about OpenBSD and NetBSD.

>I understand -- I could/must go and install a bajillion operating systems a=
>nd test and find out, but I don't expect to spend the time that way and pus=
>h comes to shove, any BSD (and Linux, Solaris, NT, CE, etc.) variants I int=
>roduce will have no version number in them, will be built on whatever I hav=
>e, and it will be unknown if they work on older. And maybe something will m=
>aterialize to be more portable, like interfacing to the Posix via C instead=
> of cloned headers.

> 

> - Jay



>
>

>

>> To: jayk123 at hotmail.com
> CC: m3devel at elegosoft.com
> Subj=
>ect: Re: [M3devel] which platforms? 
> Date: Thu, 15 May 2008 14:30:3=
>6 -0700
> From: mika at async.caltech.edu
> 
> here it is:R>> 
> FreeBSD4
> PPC_DARWIN
> NT386GNU
> LINUXL=
>IBC6
> 
> I386_DARWIN coming soon
> 
> Tony Hosking=
> writes:
> >
> >--Apple-Mail-4-631028010
> >Cont=
>ent-Type: text/plain;
> > charset=3DUS-ASCII;
> > format=
>=3Dflowed;
> > delsp=3Dyes
> >Content-Transfer-Encoding: =
>7bit
> >
> >SOLgnu
> >PPC_DARWIN
> >I38=
>6_DARWIN
> >AMD64_DARWIN
> >LINUXLIBC6
> >I'd li=
>ke AMD64_LINUX, SPARC64_SOLARISN but no time right now to devote 
> &=
>gt;to them.
> >
> >On May 14, 2008, at 1:25 PM, Jay wrote=
>:
> >
> >> What do people run?
> >> In par=
>ticular: NetBSD? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN? 
> >>=
> I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM_WINCE? AMD64_NT?
>=
> >>
> >> Just curious, I'll probably bring up whatever I =
>can, it's fun, and 
> >> yes, get back and fix AMD64_LINUX to h=
>ave
> >> garbage collection, NT386GNU and NT386 tests, cross-pl=
>atform sets, 
> >> setup some Tinderboxes, etc...
> >&=
>gt;
> >> (AMD64_NT: the gcc available for this includes a bunch=
> of patches, 
> >> so I'm inclined to either wait for them to g=
>o upstream,
> >> or seek an alternate route such as "port" the =
>in-proc backend, llvm, 
> >> generate C, or maybe write an inte=
>rpreter for the IL;
> >> and "porting" the backend is probably =
>best preceded by a) x86 
> >> LONGINT support b) other x86 targ=
>ets "for practise", at least one,
> >> though regarding .obj fi=
>le formats, that would be tangential.)
> >>
> >> - =
>Jay
> >>
> >>
> >>
> >>
=
>> >
> >
> >--Apple-Mail-4-631028010
> >Con=
>tent-Type: text/html;
> > charset=3DUS-ASCII
> >Content-T=
>ransfer-Encoding: quoted-printable
> >
> ><html><=
>;body style=3D3D"word-wrap: break-word; -webkit-nbsp-mode: space; =3D
&g=
>t; >-webkit-line-break: after-white-space; "><div =3D
> >=
>apple-content-edited=3D3D"true"><span class=3D3D"Apple-style-span" =
>=3D
> >style=3D3D"border-collapse: separate; border-spacing: 0px 0=
>px; color: =3D
> >rgb(0, 0, 0); font-family: Helvetica; font-size:=
> 12px; font-style: =3D
> >normal; font-variant: normal; font-weigh=
>t: normal; letter-spacing: =3D
> >normal; line-height: normal; tex=
>t-align: auto; =3D
> >-khtml-text-decorations-in-effect: none; tex=
>t-indent: 0px; =3D
> >-apple-text-size-adjust: auto; text-transfor=
>m: none; orphans: 2; =3D
> >white-space: normal; widows: 2; word-s=
>pacing: 0px; "><div =3D
> >style=3D3D"word-wrap: break-word;=
> -khtml-nbsp-mode: space; =3D
> >-khtml-line-break: after-white-sp=
>ace; "><span class=3D3D"Apple-style-span" =3D
> >style=3D3D"=
>border-collapse: separate; border-spacing: 0px 0px; color: =3D
> >=
>rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =3D
&=
>gt; >normal; font-variant: normal; font-weight: normal; letter-spacing: =
>=3D
> >normal; line-height: normal; text-align: auto; =3D
> =
>>-khtml-text-decorations-in-effect: none; text-indent: 0px; =3D
> =
>>-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =3D>> >white-space: normal; widows: 2; word-spacing: 0px; =3D
> &g=
>t;">SOLgnu</span></div><div style=3D3D"word-wrap: break-w=
>ord; =3D
> >-khtml-nbsp-mode: space; -khtml-line-break: after-whit=
>e-space; =3D
> >">PPC_DARWIN</div><div style=3D3D"word=
>-wrap: break-word; -khtml-nbsp-mode: =3D
> >space; -khtml-line-bre=
>ak: after-white-space; ">I386_DARWIN</div><div =3D
> >=
>style=3D3D"word-wrap: break-word; -khtml-nbsp-mode: space; =3D
> >=
>-khtml-line-break: after-white-space; ">AMD64_DARWIN</div><div =
>=3D
> >style=3D3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
>=3D
> >-khtml-line-break: after-white-space; ">LINUXLIBC6</d=
>iv><div =3D
> >style=3D3D"word-wrap: break-word; -khtml-nbsp=
>-mode: space; =3D
> >-khtml-line-break: after-white-space; ">I'=
>d like AMD64_LINUX,&nbsp;<span =3D
> >class=3D3D"Apple-styl=
>e-span" style=3D3D"font-family: Tahoma; font-size: =3D
> >13px; "&=
>gt;SPARC64_SOLARISN but no time right now to devote to =3D
> >them=
>.</span></div></span></div><br><div><=
>;div>On May 14, 2008, at 1:25 =3D
> >PM, Jay wrote:</div>=
><br class=3D3D"Apple-interchange-newline"><blockquote =3D
> =
>>type=3D3D"cite"><span class=3D3D"Apple-style-span" style=3D3D"bor=
>der-collapse: =3D
> >separate; color: rgb(0, 0, 0); font-family: H=
>elvetica; font-size: 12px; =3D
> >font-style: normal; font-variant=
>: normal; font-weight: normal; =3D
> >letter-spacing: normal; line=
>-height: normal; orphans: 2; text-align: =3D
> >auto; text-indent:=
> 0px; text-transform: none; white-space: normal; =3D
> >widows: 2;=
> word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =3D
> >=
>;-webkit-border-vertical-spacing: 0px; =3D
> >-webkit-text-decorat=
>ions-in-effect: none; -webkit-text-size-adjust: =3D
> >auto; -webk=
>it-text-stroke-width: 0; "><div class=3D3D"hmmessage" =3D
> >=
>;style=3D3D"font-size: 10pt; font-family: Tahoma; ">What do people =3DR>> >run?<br>In particular: NetBSD? OpenBSD? Sparc32? Sparc64? =
>PPC64_DARWIN? =3D
> >I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS?=
> ARM_WINCE? =3D
> >AMD64_NT?<br>&nbsp;<br>Just cur=
>ious, I'll probably bring up whatever I =3D
> >can, it's fun, and =
>yes, get back and fix AMD64_LINUX to have<br>garbage =3D
> >=
>collection, NT386GNU and NT386 tests,&nbsp;cross-platform sets, setup =
>=3D
> >some Tinderboxes, etc...<br>&nbsp;<br>(AMD6=
>4_NT: the gcc available for =3D
> >this includes a bunch of patche=
>s, so I'm inclined to either wait for =3D
> >them to go upstream,&=
>lt;br>or seek an alternate route such as "port" the =3D
> >in-p=
>roc backend, llvm, generate C, or maybe write an interpreter for the =3D>> >IL;<br>and "porting" the backend is probably best preceded =
>by a) x86 =3D
> >LONGINT support b) other x86 targets "for practis=
>e", at least =3D
> >one,<br>though regarding .obj file forma=
>ts, that would be =3D
> >tangential.)<br>&nbsp;<br>=
>;&nbsp;- =3D
> >Jay<br><br><br><br><=
>;br></div></span></blockquote></div><br>&l=
>t;/body></html>=3D
> >
> >--Apple-Mail-4-6310280=
>10--


>=
>
>--_14c076c4-fb7c-48b0-b705-2e38d4b4a333_--


From jayk123 at hotmail.com  Fri May 16 08:40:49 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 16 May 2008 06:40:49 +0000
Subject: [M3devel] which platforms? and questions about FreeBSD
 versioning
In-Reply-To: <200805160554.m4G5sShX067480@camembert.async.caltech.edu>
References: Your message of "Thu, 15 May 2008 22:43:30 -0000."
	  
	<200805160554.m4G5sShX067480@camembert.async.caltech.edu>
Message-ID: 

Wow that is crazy.
The "OS" is backwards compatible.
The tools -- or at least the headers/libs -- are not backwards compatible.
They apparently don't produce binaries that run on older systems.
 
Hm, so I did some diffing amongm3-libs\m3core\src\unix\freebsd-*
they are all amost identical.and almost all compatible.Freebsd-1 to -2 is the least compatible.otherwise the only actual difference I see is in Usignal sa_flags and sa_mask getting reversed. and sigcontext changed.
Otherwise it's mostly things like long vs. unsigned_long,int64_t vs. quad_t, short vs. int16_t.
The DIR record grew, but as long as it is not implementedin Modula-3 and the new fields not access, no matter.
Oh one errno value changed.
Sometimes some types or functions got added, but that is ok.
 
Maybe more research at a might later date...
 
 - Jay



> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] which platforms? and questions about FreeBSD versioning > Date: Thu, 15 May 2008 22:54:28 -0700> From: mika at async.caltech.edu> > > No, sorry, haven't gotten around to testing the current NT386GNU> cm3... I have a lot of version synchronizing to do, unfortunately :(> > Yes, FreeBSD is backwards-compatible, *not* forwards-compatible.> That is, you can build even fairly complex software packages on an old> FreeBSD system and expect it to run on the latest release. You cannot,> as a general rule, build anything on a newer system and expect it to work> on an older one. There must be "some" way of doing it that way, but> I don't know what it is, and I don't know if it's very well supported.> I keep FreeBSD 4.x systems around for precisely this reason: the binaries> compiled there work fine on 5.x and 6.x (as far as I have tested). Not> the other way around! In fact it has never worked the other way, as > long as I can remember, with FreeBSD.> > This is also why I suggest that a "FreeBSD4" bootstrap should actually> be built on FreeBSD 4.x and not 5.x, 6.x, or 7.x!> > Mika> > Jay writes:> >--_14c076c4-fb7c-48b0-b705-2e38d4b4a333_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >Mika, ok, this is tangential: Have you tried the current NT386GNU cm3?> >=20> >I meant, more about what "operating systems" that Modula-3 does not support=> > do people here use, would like to see Modula-3 on. Or maybe I meant both.> >=20> >Speaking of the "4" in FreeBSD4:> >=20> >Has FreeBSD, and the other BSDs, really broken backward compat?> >They really change interfaces a lot such that binaries built with current h=> >eaders/libs won't run on older versions?> >And there isn't an easy way on current platforms to build something using o=> >lder tools to run on older and newer platforms?> >Look at Windows for example. If you call a "new" function directly, you wil=> >l fail to load on older platforms. So either don't call them, or use LoadLi=> >brary/GetProcAddress. Structures almost never change size, though there is => >some screwiness there, stuff like:> >=20> >struct FOO { size_t Size;> > int Field1;> >#if VERSION > 1234> > int Field2;> >#endif> >};> >=20> >I think it should be more like:> >=20> >struct FOO { size_t Size;> > int Field1;> >#if VERSION > 1234> > int Field2;> >#endif> >};> >=20> >struct FOO_V1{ size_t Size;> > int Field1;> >};> >=20> >struct FOO_V2 { size_t Size;> > int Field1;> > int Field2;> >};> >=20> >#if VERSION > 1234> >typedef FOO_V2 FOO;> >#else> >typedef FOO_V1 FOO;> >#endif> >=20> >I understand that binaries built on the older platform will continue to wor=> >k on the newer platform.> >That is one thing.> >But it is also useful to be able to build binaries on the newer platform th=> >at will on the older platform.> >Apple also invests a bunch here.> >=20> >Well, ok, if it was really "bad", there'd be FreeBSD5, 6, 7.> >I guess maybe they broke this stuff sometimes but haven't in a while?> >That you can build FreeBSD4 binaries on FreeBSD7 and the run down to 4?> >=20> >And then, same questions about OpenBSD and NetBSD.> >I understand -- I could/must go and install a bajillion operating systems a=> >nd test and find out, but I don't expect to spend the time that way and pus=> >h comes to shove, any BSD (and Linux, Solaris, NT, CE, etc.) variants I int=> >roduce will have no version number in them, will be built on whatever I hav=> >e, and it will be unknown if they work on older. And maybe something will m=> >aterialize to be more portable, like interfacing to the Posix via C instead=> > of cloned headers.> >=20> > - Jay> >> >> >> >> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel=> >] which platforms? > Date: Thu, 15 May 2008 14:30:36 -0700> From: mika at asyn=> >c.caltech.edu> > here it is:> > FreeBSD4> PPC_DARWIN> NT386GNU> LINUXLIBC6>=> > > I386_DARWIN coming soon> > Tony Hosking writes:> >> >--Apple-Mail-4-6310=> >28010> >Content-Type: text/plain;> > charset=3DUS-ASCII;> > format=3Dflowed=> >;> > delsp=3Dyes> >Content-Transfer-Encoding: 7bit> >> >SOLgnu> >PPC_DARWIN=> >> >I386_DARWIN> >AMD64_DARWIN> >LINUXLIBC6> >I'd like AMD64_LINUX, SPARC64_=> >SOLARISN but no time right now to devote > >to them.> >> >On May 14, 2008, => >at 1:25 PM, Jay wrote:> >> >> What do people run?> >> In particular: NetBSD=> >? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN? > >> I386_SOLARIS? AMD64_SOLARIS=> >? SPARC64_SOLARIS? ARM_WINCE? AMD64_NT?> >>> >> Just curious, I'll probably=> > bring up whatever I can, it's fun, and > >> yes, get back and fix AMD64_LI=> >NUX to have> >> garbage collection, NT386GNU and NT386 tests, cross-platfor=> >m sets, > >> setup some Tinderboxes, etc...> >>> >> (AMD64_NT: the gcc avai=> >lable for this includes a bunch of patches, > >> so I'm inclined to either => >wait for them to go upstream,> >> or seek an alternate route such as "port"=> > the in-proc backend, llvm, > >> generate C, or maybe write an interpreter => >for the IL;> >> and "porting" the backend is probably best preceded by a) x=> >86 > >> LONGINT support b) other x86 targets "for practise", at least one,>=> > >> though regarding .obj file formats, that would be tangential.)> >>> >> => >- Jay> >>> >>> >>> >>> >> >> >--Apple-Mail-4-631028010> >Content-Type: text=> >/html;> > charset=3DUS-ASCII> >Content-Transfer-Encoding: quoted-printable>=> > >> > >; =3D> >-webkit-line-break: after-white-space; ">
 >apple-content-e=> >dited=3D3D"true"> >style=3D3D"border=> >-collapse: separate; border-spacing: 0px 0px; color: =3D> >rgb(0, 0, 0); fo=> >nt-family: Helvetica; font-size: 12px; font-style: =3D> >normal; font-varia=> >nt: normal; font-weight: normal; letter-spacing: =3D> >normal; line-height:=> > normal; text-align: auto; =3D> >-khtml-text-decorations-in-effect: none; t=> >ext-indent: 0px; =3D> >-apple-text-size-adjust: auto; text-transform: none;=> > orphans: 2; =3D> >white-space: normal; widows: 2; word-spacing: 0px; "> >v =3D> >style=3D3D"word-wrap: break-word; -khtml-nbsp-mode: space; =3D> >-k=> >html-line-break: after-white-space; "> >=3D> >style=3D3D"border-collapse: separate; border-spacing: 0px 0px; color:=> > =3D> >rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: => >=3D> >normal; font-variant: normal; font-weight: normal; letter-spacing: => >=3D> >normal; line-height: normal; text-align: auto; =3D> >-khtml-text-deco=> >rations-in-effect: none; text-indent: 0px; =3D> >-apple-text-size-adjust: a=> >uto; text-transform: none; orphans: 2; =3D> >white-space: normal; widows: 2=> >; word-spacing: 0px; =3D> >">SOLgnu
 >break-word; =3D> >-khtml-nbsp-mode: space; -khtml-line-break: after-white-s=> >pace; =3D> >">PPC_DARWIN
 >-nbsp-mode: =3D> >space; -khtml-line-break: after-white-space; ">I386_DARWI=> >N
 >style=3D3D"word-wrap: break-word; -khtml-nbsp-mode: space=> >; =3D> >-khtml-line-break: after-white-space; ">AMD64_DARWIN
=> > >style=3D3D"word-wrap: break-word; -khtml-nbsp-mode: space; =3D> >-khtml-l=> >ine-break: after-white-space; ">LINUXLIBC6
 >style=3D3D"word-=> >wrap: break-word; -khtml-nbsp-mode: space; =3D> >-khtml-line-break: after-w=> >hite-space; ">I'd like AMD64_LINUX,  >class=3D3D"Apple-style=> >-span" style=3D3D"font-family: Tahoma; font-size: =3D> >13px; ">SPARC64_SOL=> >ARISN but no time right now to devote to =3D> >them.
 >iv>
On May 14, 2008, at 1:25 =3D> >PM, Jay wrote:

 >ss=3D3D"Apple-interchange-newline">
 >type=3D3D"cite"> >class=3D3D"Apple-style-span" style=3D3D"border-collapse: =3D> >separate; co=> >lor: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =3D> >font-styl=> >e: normal; font-variant: normal; font-weight: normal; =3D> >letter-spacing:=> > normal; line-height: normal; orphans: 2; text-align: =3D> >auto; text-inde=> >nt: 0px; text-transform: none; white-space: normal; =3D> >widows: 2; word-s=> >pacing: 0px; -webkit-border-horizontal-spacing: 0px; =3D> >-webkit-border-v=> >ertical-spacing: 0px; =3D> >-webkit-text-decorations-in-effect: none; -webk=> >it-text-size-adjust: =3D> >auto; -webkit-text-stroke-width: 0; ">
 >=3D3D"hmmessage" =3D> >style=3D3D"font-size: 10pt; font-family: Tahoma; ">W=> >hat do people =3D> >run?
In particular: NetBSD? OpenBSD? Sparc32? Sparc6=> >4? PPC64_DARWIN? =3D> >I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM_WI=> >NCE? =3D> >AMD64_NT?
 
Just curious, I'll probably bring up what=> >ever I =3D> >can, it's fun, and yes, get back and fix AMD64_LINUX to have >r>garbage =3D> >collection, NT386GNU and NT386 tests, cross-platform s=> >ets, setup =3D> >some Tinderboxes, etc...
 
(AMD64_NT: the gcc a=> >vailable for =3D> >this includes a bunch of patches, so I'm inclined to eit=> >her wait for =3D> >them to go upstream,
or seek an alternate route such => >as "port" the =3D> >in-proc backend, llvm, generate C, or maybe write an in=> >terpreter for the =3D> >IL;
and "porting" the backend is probably best p=> >receded by a) x86 =3D> >LONGINT support b) other x86 targets "for practise"=> >, at least =3D> >one,
though regarding .obj file formats, that would be => >=3D> >tangential.)
 
 - =3D> >Jay




=> >

=3D> >> >--Apple-Mail-4-6310280=> >10--=> >> >--_14c076c4-fb7c-48b0-b705-2e38d4b4a333_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >> >> >> >Mika, ok, this is tangential: Have you => >tried the current NT386GNU cm3?
> > 
> >I meant, more about what "operating systems" that Modula-3 does not support=> > do people here use, would like to see Modula-3 on. Or maybe I meant both.<=> >BR>> > 
> >Speaking of the "4" in FreeBSD4:
> > 
> >Has FreeBSD, and the other BSDs, really broken backward compat?
> >They really change interfaces a lot such that binaries built with current h=> >eaders/libs won't run on older versions?
> >And there isn't an easy way on current platforms to build something using o=> >lder tools to run on older and newer platforms?
> >Look at Windows for example. If you call a "new" function directly, you wil=> >l fail to load on older platforms. So either don't call them, or use LoadLi=> >brary/GetProcAddress. Structures almost never change size, though there is => >some screwiness there, stuff like:
> > 
> >struct FOO {
  size_t Size;
> >  int Field1;
> >#if VERSION > 1234
> >  int Field2;
> >#endif
> >};
> > 
> >I think it should be more like:
> > 
> >struct FOO {
  size_t Size;
> >  int Field1;
> >#if VERSION > 1234
> >  int Field2;
> >#endif
> >};
> > 
> >struct FOO_V1{
  size_t Size;
> >  int Field1;
> >};
> > 
> >struct FOO_V2 {
  size_t Size;
> >  int Field1;
> >  int Field2;
> >};
> > 
> >#if VERSION > 1234
> >typedef FOO_V2 FOO;
> >#else
> >typedef FOO_V1 FOO;
> >#endif
> > 
> >I understand that binaries built on the older platform will continue to wor=> >k on the newer platform.
> >That is one thing.
> >But it is also useful to be able to build binaries on the newer platform th=> >at will on the older platform.
> >Apple also invests a bunch here.
> > 
> >Well, ok, if it was really "bad", there'd be FreeBSD5, 6, 7.
> >I guess maybe they broke this stuff sometimes but haven't in a while?
> >That you can build FreeBSD4 binaries on FreeBSD7 and the run down to 4?
> > 
> >And then, same questions about OpenBSD and NetBSD.
> >I understand -- I could/must go and install a bajillion operating systems a=> >nd test and find out, but I don't expect to spend the time that way and pus=> >h comes to shove, any BSD (and Linux, Solaris, NT, CE, etc.) variants I int=> >roduce will have no version number in them, will be built on whatever I hav=> >e, and it will be unknown if they work on older. And maybe something will m=> >aterialize to be more portable, like interfacing to the Posix via C instead=> > of cloned headers.
> > 
> > - Jay


> >> >
> >
> >> To: jayk123 at hotmail.com
> CC: m3devel at elegosoft.com
> Subj=> >ect: Re: [M3devel] which platforms? 
> Date: Thu, 15 May 2008 14:30:3=> >6 -0700
> From: mika at async.caltech.edu
> 
> here it is: >R>> 
> FreeBSD4
> PPC_DARWIN
> NT386GNU
> LINUXL=> >IBC6
> 
> I386_DARWIN coming soon
> 
> Tony Hosking=> > writes:
> >
> >--Apple-Mail-4-631028010
> >Cont=> >ent-Type: text/plain;
> > charset=3DUS-ASCII;
> > format=> >=3Dflowed;
> > delsp=3Dyes
> >Content-Transfer-Encoding: => >7bit
> >
> >SOLgnu
> >PPC_DARWIN
> >I38=> >6_DARWIN
> >AMD64_DARWIN
> >LINUXLIBC6
> >I'd li=> >ke AMD64_LINUX, SPARC64_SOLARISN but no time right now to devote 
> &=> >gt;to them.
> >
> >On May 14, 2008, at 1:25 PM, Jay wrote=> >:
> >
> >> What do people run?
> >> In par=> >ticular: NetBSD? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN? 
> >>=> > I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM_WINCE? AMD64_NT?
>=> > >>
> >> Just curious, I'll probably bring up whatever I => >can, it's fun, and 
> >> yes, get back and fix AMD64_LINUX to h=> >ave
> >> garbage collection, NT386GNU and NT386 tests, cross-pl=> >atform sets, 
> >> setup some Tinderboxes, etc...
> >&=> >gt;
> >> (AMD64_NT: the gcc available for this includes a bunch=> > of patches, 
> >> so I'm inclined to either wait for them to g=> >o upstream,
> >> or seek an alternate route such as "port" the => >in-proc backend, llvm, 
> >> generate C, or maybe write an inte=> >rpreter for the IL;
> >> and "porting" the backend is probably => >best preceded by a) x86 
> >> LONGINT support b) other x86 targ=> >ets "for practise", at least one,
> >> though regarding .obj fi=> >le formats, that would be tangential.)
> >>
> >> - => >Jay
> >>
> >>
> >>
> >>
=> >> >
> >
> >--Apple-Mail-4-631028010
> >Con=> >tent-Type: text/html;
> > charset=3DUS-ASCII
> >Content-T=> >ransfer-Encoding: quoted-printable
> >
> ><html><=> >;body style=3D3D"word-wrap: break-word; -webkit-nbsp-mode: space; =3D
&g=> >t; >-webkit-line-break: after-white-space; "><div =3D
> >=> >apple-content-edited=3D3D"true"><span class=3D3D"Apple-style-span" => >=3D
> >style=3D3D"border-collapse: separate; border-spacing: 0px 0=> >px; color: =3D
> >rgb(0, 0, 0); font-family: Helvetica; font-size:=> > 12px; font-style: =3D
> >normal; font-variant: normal; font-weigh=> >t: normal; letter-spacing: =3D
> >normal; line-height: normal; tex=> >t-align: auto; =3D
> >-khtml-text-decorations-in-effect: none; tex=> >t-indent: 0px; =3D
> >-apple-text-size-adjust: auto; text-transfor=> >m: none; orphans: 2; =3D
> >white-space: normal; widows: 2; word-s=> >pacing: 0px; "><div =3D
> >style=3D3D"word-wrap: break-word;=> > -khtml-nbsp-mode: space; =3D
> >-khtml-line-break: after-white-sp=> >ace; "><span class=3D3D"Apple-style-span" =3D
> >style=3D3D"=> >border-collapse: separate; border-spacing: 0px 0px; color: =3D
> >=> >rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =3D
&=> >gt; >normal; font-variant: normal; font-weight: normal; letter-spacing: => >=3D
> >normal; line-height: normal; text-align: auto; =3D
> => >>-khtml-text-decorations-in-effect: none; text-indent: 0px; =3D
> => >>-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =3D >>> >white-space: normal; widows: 2; word-spacing: 0px; =3D
> &g=> >t;">SOLgnu</span></div><div style=3D3D"word-wrap: break-w=> >ord; =3D
> >-khtml-nbsp-mode: space; -khtml-line-break: after-whit=> >e-space; =3D
> >">PPC_DARWIN</div><div style=3D3D"word=> >-wrap: break-word; -khtml-nbsp-mode: =3D
> >space; -khtml-line-bre=> >ak: after-white-space; ">I386_DARWIN</div><div =3D
> >=> >style=3D3D"word-wrap: break-word; -khtml-nbsp-mode: space; =3D
> >=> >-khtml-line-break: after-white-space; ">AMD64_DARWIN</div><div => >=3D
> >style=3D3D"word-wrap: break-word; -khtml-nbsp-mode: space; => >=3D
> >-khtml-line-break: after-white-space; ">LINUXLIBC6</d=> >iv><div =3D
> >style=3D3D"word-wrap: break-word; -khtml-nbsp=> >-mode: space; =3D
> >-khtml-line-break: after-white-space; ">I'=> >d like AMD64_LINUX,&nbsp;<span =3D
> >class=3D3D"Apple-styl=> >e-span" style=3D3D"font-family: Tahoma; font-size: =3D
> >13px; "&=> >gt;SPARC64_SOLARISN but no time right now to devote to =3D
> >them=> >.</span></div></span></div><br><div><=> >;div>On May 14, 2008, at 1:25 =3D
> >PM, Jay wrote:</div>=> ><br class=3D3D"Apple-interchange-newline"><blockquote =3D
> => >>type=3D3D"cite"><span class=3D3D"Apple-style-span" style=3D3D"bor=> >der-collapse: =3D
> >separate; color: rgb(0, 0, 0); font-family: H=> >elvetica; font-size: 12px; =3D
> >font-style: normal; font-variant=> >: normal; font-weight: normal; =3D
> >letter-spacing: normal; line=> >-height: normal; orphans: 2; text-align: =3D
> >auto; text-indent:=> > 0px; text-transform: none; white-space: normal; =3D
> >widows: 2;=> > word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =3D
> >=> >;-webkit-border-vertical-spacing: 0px; =3D
> >-webkit-text-decorat=> >ions-in-effect: none; -webkit-text-size-adjust: =3D
> >auto; -webk=> >it-text-stroke-width: 0; "><div class=3D3D"hmmessage" =3D
> >=> >;style=3D3D"font-size: 10pt; font-family: Tahoma; ">What do people =3D >R>> >run?<br>In particular: NetBSD? OpenBSD? Sparc32? Sparc64? => >PPC64_DARWIN? =3D
> >I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS?=> > ARM_WINCE? =3D
> >AMD64_NT?<br>&nbsp;<br>Just cur=> >ious, I'll probably bring up whatever I =3D
> >can, it's fun, and => >yes, get back and fix AMD64_LINUX to have<br>garbage =3D
> >=> >collection, NT386GNU and NT386 tests,&nbsp;cross-platform sets, setup => >=3D
> >some Tinderboxes, etc...<br>&nbsp;<br>(AMD6=> >4_NT: the gcc available for =3D
> >this includes a bunch of patche=> >s, so I'm inclined to either wait for =3D
> >them to go upstream,&=> >lt;br>or seek an alternate route such as "port" the =3D
> >in-p=> >roc backend, llvm, generate C, or maybe write an interpreter for the =3D >>> >IL;<br>and "porting" the backend is probably best preceded => >by a) x86 =3D
> >LONGINT support b) other x86 targets "for practis=> >e", at least =3D
> >one,<br>though regarding .obj file forma=> >ts, that would be =3D
> >tangential.)<br>&nbsp;<br>=> >;&nbsp;- =3D
> >Jay<br><br><br><br><=> >;br></div></span></blockquote></div><br>&l=> >t;/body></html>=3D
> >
> >--Apple-Mail-4-6310280=> >10--

> >=> >> >--_14c076c4-fb7c-48b0-b705-2e38d4b4a333_--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mika at async.caltech.edu  Fri May 16 08:46:35 2008
From: mika at async.caltech.edu (Mika Nystrom)
Date: Thu, 15 May 2008 23:46:35 -0700
Subject: [M3devel] which platforms? and questions about FreeBSD
	versioning
In-Reply-To: Your message of "Fri, 16 May 2008 06:40:49 -0000."
	 
Message-ID: <200805160646.m4G6kZTb068480@camembert.async.caltech.edu>


Did you check the system call numbers?  I often get ... "unknown
system call", I think, when I try to do what you are describing.

By the way I have had far less trouble using binaries across versions
of FreeBSD than trying the same trick on Linux... maybe I just know
better what I am doing on FreeBSD?  I have some very very old programs
that still work fine.  Even the compiler tends to keep working when
upgrading from one major version to the next.  (But yes you do need
to have the compatibility libraries installed on the new system.)

     Mika

Jay writes:
>--_a9d87328-63f1-414c-abcb-03c34a9cee30_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>Wow that is crazy.
>The "OS" is backwards compatible.
>The tools -- or at least the headers/libs -- are not backwards compatible.
>They apparently don't produce binaries that run on older systems.
>=20
>Hm, so I did some diffing amongm3-libs\m3core\src\unix\freebsd-*
>they are all amost identical.and almost all compatible.Freebsd-1 to -2 is t=
>he least compatible.otherwise the only actual difference I see is in Usigna=
>l sa_flags and sa_mask getting reversed. and sigcontext changed.
>Otherwise it's mostly things like long vs. unsigned_long,int64_t vs. quad_t=
>, short vs. int16_t.
>The DIR record grew, but as long as it is not implementedin Modula-3 and th=
>e new fields not access, no matter.
>Oh one errno value changed.
>Sometimes some types or functions got added, but that is ok.
>=20
>Maybe more research at a might later date...
>=20
> - Jay
>
>
>
>> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel=
>] which platforms? and questions about FreeBSD versioning > Date: Thu, 15 M=
>ay 2008 22:54:28 -0700> From: mika at async.caltech.edu> > > No, sorry, haven'=
>t gotten around to testing the current NT386GNU> cm3... I have a lot of ver=
>sion synchronizing to do, unfortunately :(> > Yes, FreeBSD is backwards-com=
>patible, *not* forwards-compatible.> That is, you can build even fairly com=
>plex software packages on an old> FreeBSD system and expect it to run on th=
>e latest release. You cannot,> as a general rule, build anything on a newer=
> system and expect it to work> on an older one. There must be "some" way of=
> doing it that way, but> I don't know what it is, and I don't know if it's =
>very well supported.> I keep FreeBSD 4.x systems around for precisely this =
>reason: the binaries> compiled there work fine on 5.x and 6.x (as far as I =
>have tested). Not> the other way around! In fact it has never worked the ot=
>her way, as > long as I can remember, with FreeBSD.> > This is also why I s=
>uggest that a "FreeBSD4" bootstrap should actually> be built on FreeBSD 4.x=
> and not 5.x, 6.x, or 7.x!> > Mika> > Jay writes:> >--_14c076c4-fb7c-48b0-b=
>705-2e38d4b4a333_> >Content-Type: text/plain; charset=3D"iso-8859-1"> >Cont=
>ent-Transfer-Encoding: quoted-printable> >> >Mika, ok, this is tangential: =
>Have you tried the current NT386GNU cm3?> >=3D20> >I meant, more about what=
> "operating systems" that Modula-3 does not support=3D> > do people here us=
>e, would like to see Modula-3 on. Or maybe I meant both.> >=3D20> >Speaking=
> of the "4" in FreeBSD4:> >=3D20> >Has FreeBSD, and the other BSDs, really =
>broken backward compat?> >They really change interfaces a lot such that bin=
>aries built with current h=3D> >eaders/libs won't run on older versions?> >=
>And there isn't an easy way on current platforms to build something using o=
>=3D> >lder tools to run on older and newer platforms?> >Look at Windows for=
> example. If you call a "new" function directly, you wil=3D> >l fail to loa=
>d on older platforms. So either don't call them, or use LoadLi=3D> >brary/G=
>etProcAddress. Structures almost never change size, though there is =3D> >s=
>ome screwiness there, stuff like:> >=3D20> >struct FOO { size_t Size;> > in=
>t Field1;> >#if VERSION > 1234> > int Field2;> >#endif> >};> >=3D20> >I thi=
>nk it should be more like:> >=3D20> >struct FOO { size_t Size;> > int Field=
>1;> >#if VERSION > 1234> > int Field2;> >#endif> >};> >=3D20> >struct FOO_V=
>1{ size_t Size;> > int Field1;> >};> >=3D20> >struct FOO_V2 { size_t Size;>=
> > int Field1;> > int Field2;> >};> >=3D20> >#if VERSION > 1234> >typedef F=
>OO_V2 FOO;> >#else> >typedef FOO_V1 FOO;> >#endif> >=3D20> >I understand th=
>at binaries built on the older platform will continue to wor=3D> >k on the =
>newer platform.> >That is one thing.> >But it is also useful to be able to =
>build binaries on the newer platform th=3D> >at will on the older platform.=
>> >Apple also invests a bunch here.> >=3D20> >Well, ok, if it was really "b=
>ad", there'd be FreeBSD5, 6, 7.> >I guess maybe they broke this stuff somet=
>imes but haven't in a while?> >That you can build FreeBSD4 binaries on Free=
>BSD7 and the run down to 4?> >=3D20> >And then, same questions about OpenBS=
>D and NetBSD.> >I understand -- I could/must go and install a bajillion ope=
>rating systems a=3D> >nd test and find out, but I don't expect to spend the=
> time that way and pus=3D> >h comes to shove, any BSD (and Linux, Solaris, =
>NT, CE, etc.) variants I int=3D> >roduce will have no version number in the=
>m, will be built on whatever I hav=3D> >e, and it will be unknown if they w=
>ork on older. And maybe something will m=3D> >aterialize to be more portabl=
>e, like interfacing to the Posix via C instead=3D> > of cloned headers.> >=
>=3D20> > - Jay> >> >> >> >> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.=
>com> Subject: Re: [M3devel=3D> >] which platforms? > Date: Thu, 15 May 2008=
> 14:30:36 -0700> From: mika at asyn=3D> >c.caltech.edu> > here it is:> > FreeB=
>SD4> PPC_DARWIN> NT386GNU> LINUXLIBC6>=3D> > > I386_DARWIN coming soon> > T=
>ony Hosking writes:> >> >--Apple-Mail-4-6310=3D> >28010> >Content-Type: tex=
>t/plain;> > charset=3D3DUS-ASCII;> > format=3D3Dflowed=3D> >;> > delsp=3D3D=
>yes> >Content-Transfer-Encoding: 7bit> >> >SOLgnu> >PPC_DARWIN=3D> >> >I386=
>_DARWIN> >AMD64_DARWIN> >LINUXLIBC6> >I'd like AMD64_LINUX, SPARC64_=3D> >S=
>OLARISN but no time right now to devote > >to them.> >> >On May 14, 2008, =
>=3D> >at 1:25 PM, Jay wrote:> >> >> What do people run?> >> In particular: =
>NetBSD=3D> >? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN? > >> I386_SOLARIS? A=
>MD64_SOLARIS=3D> >? SPARC64_SOLARIS? ARM_WINCE? AMD64_NT?> >>> >> Just curi=
>ous, I'll probably=3D> > bring up whatever I can, it's fun, and > >> yes, g=
>et back and fix AMD64_LI=3D> >NUX to have> >> garbage collection, NT386GNU =
>and NT386 tests, cross-platfor=3D> >m sets, > >> setup some Tinderboxes, et=
>c...> >>> >> (AMD64_NT: the gcc avai=3D> >lable for this includes a bunch o=
>f patches, > >> so I'm inclined to either =3D> >wait for them to go upstrea=
>m,> >> or seek an alternate route such as "port"=3D> > the in-proc backend,=
> llvm, > >> generate C, or maybe write an interpreter =3D> >for the IL;> >>=
> and "porting" the backend is probably best preceded by a) x=3D> >86 > >> L=
>ONGINT support b) other x86 targets "for practise", at least one,>=3D> > >>=
> though regarding .obj file formats, that would be tangential.)> >>> >> =3D=
>> >- Jay> >>> >>> >>> >>> >> >> >--Apple-Mail-4-631028010> >Content-Type: t=
>ext=3D> >/html;> > charset=3D3DUS-ASCII> >Content-Transfer-Encoding: quoted=
-printable>=3D> > >> >it-nbsp-mode: space=3D> >; =3D3D> >-webkit-line-break: after-white-space; "=
>>
 >apple-content-e=3D> >dited=3D3D3D"true">ple-style-span" =3D3D> >style=3D3D3D"border=3D> >-collapse: separate; borde=
>r-spacing: 0px 0px; color: =3D3D> >rgb(0, 0, 0); fo=3D> >nt-family: Helveti=
>ca; font-size: 12px; font-style: =3D3D> >normal; font-varia=3D> >nt: normal=
>; font-weight: normal; letter-spacing: =3D3D> >normal; line-height:=3D> > n=
>ormal; text-align: auto; =3D3D> >-khtml-text-decorations-in-effect: none; t=
>=3D> >ext-indent: 0px; =3D3D> >-apple-text-size-adjust: auto; text-transfor=
>m: none;=3D> > orphans: 2; =3D3D> >white-space: normal; widows: 2; word-spa=
>cing: 0px; "> >v =3D3D> >style=3D3D3D"word-wrap: break-word; -khtml-=
>nbsp-mode: space; =3D3D> >-k=3D> >html-line-break: after-white-space; ">an class=3D3D3D"Apple-style-span" =3D> >=3D3D> >style=3D3D3D"border-collaps=
>e: separate; border-spacing: 0px 0px; color:=3D> > =3D3D> >rgb(0, 0, 0); fo=
>nt-family: Helvetica; font-size: 12px; font-style: =3D> >=3D3D> >normal; fo=
>nt-variant: normal; font-weight: normal; letter-spacing: =3D> >=3D3D> >norm=
>al; line-height: normal; text-align: auto; =3D3D> >-khtml-text-deco=3D> >ra=
>tions-in-effect: none; text-indent: 0px; =3D3D> >-apple-text-size-adjust: a=
>=3D> >uto; text-transform: none; orphans: 2; =3D3D> >white-space: normal; w=
>idows: 2=3D> >; word-spacing: 0px; =3D3D> >">SOLgnu
=3D3D3D"word-wrap: =3D> >break-word; =3D3D> >-khtml-nbsp-mode: space; -khtm=
>l-line-break: after-white-s=3D> >pace; =3D3D> >">PPC_DARWIN
=3D3D3D"word-wrap: break-word; -khtml=3D> >-nbsp-mode: =3D3D> >space; -khtm=
>l-line-break: after-white-space; ">I386_DARWI=3D> >N
 >styl=
>e=3D3D3D"word-wrap: break-word; -khtml-nbsp-mode: space=3D> >; =3D3D> >-kht=
>ml-line-break: after-white-space; ">AMD64_DARWIN
=3D> > >st=
>yle=3D3D3D"word-wrap: break-word; -khtml-nbsp-mode: space; =3D3D> >-khtml-l=
>=3D> >ine-break: after-white-space; ">LINUXLIBC6
 >style=3D=
>3D3D"word-=3D> >wrap: break-word; -khtml-nbsp-mode: space; =3D3D> >-khtml-l=
>ine-break: after-w=3D> >hite-space; ">I'd like AMD64_LINUX, D> >class=3D3D3D"Apple-style=3D> >-span" style=3D3D3D"font-family: Tahoma; =
>font-size: =3D3D> >13px; ">SPARC64_SOL=3D> >ARISN but no time right now to =
>devote to =3D3D> >them.
 >iv>
On May=
> 14, 2008, at 1:25 =3D3D> >PM, Jay wrote:

 >ss=3D3D3D"Apple=
>-interchange-newline">
 >type=3D3D3D"cite"> >cla=
>ss=3D3D3D"Apple-style-span" style=3D3D3D"border-collapse: =3D3D> >separate;=
> co=3D> >lor: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =3D3D>=
> >font-styl=3D> >e: normal; font-variant: normal; font-weight: normal; =3D3=
>D> >letter-spacing:=3D> > normal; line-height: normal; orphans: 2; text-ali=
>gn: =3D3D> >auto; text-inde=3D> >nt: 0px; text-transform: none; white-space=
>: normal; =3D3D> >widows: 2; word-s=3D> >pacing: 0px; -webkit-border-horizo=
>ntal-spacing: 0px; =3D3D> >-webkit-border-v=3D> >ertical-spacing: 0px; =3D3=
>D> >-webkit-text-decorations-in-effect: none; -webk=3D> >it-text-size-adjus=
>t: =3D3D> >auto; -webkit-text-stroke-width: 0; ">
 >=3D3D3D"hm=
>message" =3D3D> >style=3D3D3D"font-size: 10pt; font-family: Tahoma; ">W=3D>=
> >hat do people =3D3D> >run?
In particular: NetBSD? OpenBSD? Sparc32? Sp=
>arc6=3D> >4? PPC64_DARWIN? =3D3D> >I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOL=
>ARIS? ARM_WI=3D> >NCE? =3D3D> >AMD64_NT?
 
Just curious, I'll pr=
>obably bring up what=3D> >ever I =3D3D> >can, it's fun, and yes, get back a=
>nd fix AMD64_LINUX to have >r>garbage =3D3D> >collection, NT386GNU an=
>d NT386 tests, cross-platform s=3D> >ets, setup =3D3D> >some Tinderbox=
>es, etc...
 
(AMD64_NT: the gcc a=3D> >vailable for =3D3D> >this=
> includes a bunch of patches, so I'm inclined to eit=3D> >her wait for =3D3=
>D> >them to go upstream,
or seek an alternate route such =3D> >as "port"=
> the =3D3D> >in-proc backend, llvm, generate C, or maybe write an in=3D> >t=
>erpreter for the =3D3D> >IL;
and "porting" the backend is probably best =
>p=3D> >receded by a) x86 =3D3D> >LONGINT support b) other x86 targets "for =
>practise"=3D> >, at least =3D3D> >one,
though regarding .obj file format=
>s, that would be =3D> >=3D3D> >tangential.)
 
 - =3D3D> >Ja=
>y




=3D> >

l>=3D3D> >> >--Apple-Mail-4-6310280=3D> >10--=3D> >> >--_14c076c4-fb7c-48b0=
>-b705-2e38d4b4a333_> >Content-Type: text/html; charset=3D"iso-8859-1"> >Con=
>tent-Transfer-Encoding: quoted-printable> >> >> >> >> >> >3D'hmmessage'>Mika, ok, this is tangential: Have you =3D> >tried =
>the current NT386GNU cm3?
> > 
> >I meant, more about what "oper=
>ating systems" that Modula-3 does not support=3D> > do people here use, wou=
>ld like to see Modula-3 on. Or maybe I meant both.<=3D> >BR>> > 
> =
>>Speaking of the "4" in FreeBSD4:
> > 
> >Has FreeBSD, and the o=
>ther BSDs, really broken backward compat?
> >They really change int=
>erfaces a lot such that binaries built with current h=3D> >eaders/libs won'=
>t run on older versions?
> >And there isn't an easy way on current platf=
>orms to build something using o=3D> >lder tools to run on older and newer p=
>latforms?
> >Look at Windows for example. If you call a "new" function d=
>irectly, you wil=3D> >l fail to load on older platforms. So either don't ca=
>ll them, or use LoadLi=3D> >brary/GetProcAddress. Structures almost never c=
>hange size, though there is =3D> >some screwiness there, stuff like:
> >=
> 
> >struct FOO {
  size_t Size;
> >  int Field1;R>> >#if VERSION > 1234
> >  int Field2;
> >#endif
> >};R>> > 
> >I think it should be more like:
> > 
> >struct=
> FOO {
  size_t Size;
> >  int Field1;
> >#if VERSION &g=
>t; 1234
> >  int Field2;
> >#endif
> >};
> > 
> >s=
>truct FOO_V1{
  size_t Size;
> >  int Field1;
> >};
>=
> > 
> >struct FOO_V2 {
  size_t Size;
> >  int Fiel=
>d1;
> >  int Field2;
> >};
> > 
> >#if VERSION > 1=
>234
> >typedef FOO_V2 FOO;
> >#else
> >typedef FOO_V1 FOO;
> >#=
>endif
> > 
> >I understand that binaries built on the older plat=
>form will continue to wor=3D> >k on the newer platform.
> >That is one t=
>hing.
> >But it is also useful to be able to build binaries on the newer=
> platform th=3D> >at will on the older platform.
> >Apple also invests a=
> bunch here.
> > 
> >Well, ok, if it was really "bad", there'd b=
>e FreeBSD5, 6, 7.
> >I guess maybe they broke this stuff sometimes but h=
>aven't in a while?
> >That you can build FreeBSD4 binaries on FreeBSD7 a=
>nd the run down to 4?
> > 
> >And then, same questions about Ope=
>nBSD and NetBSD.
> >I understand -- I could/must go and install a bajill=
>ion operating systems a=3D> >nd test and find out, but I don't expect to sp=
>end the time that way and pus=3D> >h comes to shove, any BSD (and Linux, So=
>laris, NT, CE, etc.) variants I int=3D> >roduce will have no version number=
> in them, will be built on whatever I hav=3D> >e, and it will be unknown if=
> they work on older. And maybe something will m=3D> >aterialize to be more =
>portable, like interfacing to the Posix via C instead=3D> > of cloned heade=
>rs.
> > 
> > - Jay


> >> >
>> >
> >> To: jayk123 at hotmail.com
> CC: m3devel at elegosoft.comR>> Subj=3D> >ect: Re: [M3devel] which platforms? 
> Date: Thu, 15=
> May 2008 14:30:3=3D> >6 -0700
> From: mika at async.caltech.edu
>=
> 
> here it is: >R>> 
> FreeBSD4
> PPC_DARWIN>> NT386GNU
> LINUXL=3D> >IBC6
> 
> I386_DARWIN coming=
> soon
> 
> Tony Hosking=3D> > writes:
> >
> >=
>--Apple-Mail-4-631028010
> >Cont=3D> >ent-Type: text/plain;
>=
>; > charset=3D3DUS-ASCII;
> > format=3D> >=3D3Dflowed;
> =
>> delsp=3D3Dyes
> >Content-Transfer-Encoding: =3D> >7bit
>=
>; >
> >SOLgnu
> >PPC_DARWIN
> >I38=3D> >6_DAR=
>WIN
> >AMD64_DARWIN
> >LINUXLIBC6
> >I'd li=3D> =
>>ke AMD64_LINUX, SPARC64_SOLARISN but no time right now to devote 
> =
>&=3D> >gt;to them.
> >
> >On May 14, 2008, at 1:25 PM, Ja=
>y wrote=3D> >:
> >
> >> What do people run?
> &g=
>t;> In par=3D> >ticular: NetBSD? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN=
>? 
> >>=3D> > I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM=
>_WINCE? AMD64_NT?
>=3D> > >>
> >> Just curious, I'l=
>l probably bring up whatever I =3D> >can, it's fun, and 
> >> y=
>es, get back and fix AMD64_LINUX to h=3D> >ave
> >> garbage col=
>lection, NT386GNU and NT386 tests, cross-pl=3D> >atform sets, 
> >=
>> setup some Tinderboxes, etc...
> >&=3D> >gt;
> >>=
> (AMD64_NT: the gcc available for this includes a bunch=3D> > of patches, <=
>BR>> >> so I'm inclined to either wait for them to g=3D> >o upstre=
>am,
> >> or seek an alternate route such as "port" the =3D> >in=
>-proc backend, llvm, 
> >> generate C, or maybe write an inte=
>=3D> >rpreter for the IL;
> >> and "porting" the backend is pro=
>bably =3D> >best preceded by a) x86 
> >> LONGINT support b) ot=
>her x86 targ=3D> >ets "for practise", at least one,
> >> though=
> regarding .obj fi=3D> >le formats, that would be tangential.)
> >=
>>
> >> - =3D> >Jay
> >>
> >>
>=
> >>
> >>
=3D> >> >
> >
> >--Ap=
>ple-Mail-4-631028010
> >Con=3D> >tent-Type: text/html;
> >=
>; charset=3D3DUS-ASCII
> >Content-T=3D> >ransfer-Encoding: quoted-=
>printable
> >
> ><html><=3D> >;body style=3D3D3D"=
>word-wrap: break-word; -webkit-nbsp-mode: space; =3D3D
&g=3D> >t; >-w=
>ebkit-line-break: after-white-space; "><div =3D3D
> >=3D> >a=
>pple-content-edited=3D3D3D"true"><span class=3D3D3D"Apple-style-span"=
> =3D> >=3D3D
> >style=3D3D3D"border-collapse: separate; border-spa=
>cing: 0px 0=3D> >px; color: =3D3D
> >rgb(0, 0, 0); font-family: He=
>lvetica; font-size:=3D> > 12px; font-style: =3D3D
> >normal; font-=
>variant: normal; font-weigh=3D> >t: normal; letter-spacing: =3D3D
> &=
>gt;normal; line-height: normal; tex=3D> >t-align: auto; =3D3D
> >-=
>khtml-text-decorations-in-effect: none; tex=3D> >t-indent: 0px; =3D3D
&g=
>t; >-apple-text-size-adjust: auto; text-transfor=3D> >m: none; orphans: =
>2; =3D3D
> >white-space: normal; widows: 2; word-s=3D> >pacing: 0p=
>x; "><div =3D3D
> >style=3D3D3D"word-wrap: break-word;=3D> >=
> -khtml-nbsp-mode: space; =3D3D
> >-khtml-line-break: after-white-=
>sp=3D> >ace; "><span class=3D3D3D"Apple-style-span" =3D3D
> >=
>;style=3D3D3D"=3D> >border-collapse: separate; border-spacing: 0px 0px; col=
>or: =3D3D
> >=3D> >rgb(0, 0, 0); font-family: Helvetica; font-size=
>: 12px; font-style: =3D3D
&=3D> >gt; >normal; font-variant: normal; f=
>ont-weight: normal; letter-spacing: =3D> >=3D3D
> >normal; line-he=
>ight: normal; text-align: auto; =3D3D
> =3D> >>-khtml-text-decorat=
>ions-in-effect: none; text-indent: 0px; =3D3D
> =3D> >>-apple-text=
>-size-adjust: auto; text-transform: none; orphans: 2; =3D3D >>> &=
>gt;white-space: normal; widows: 2; word-spacing: 0px; =3D3D
> &g=3D> =
>>t;">SOLgnu</span></div><div style=3D3D3D"word-wrap: brea=
>k-w=3D> >ord; =3D3D
> >-khtml-nbsp-mode: space; -khtml-line-break:=
> after-whit=3D> >e-space; =3D3D
> >">PPC_DARWIN</div><=
>div style=3D3D3D"word=3D> >-wrap: break-word; -khtml-nbsp-mode: =3D3D
&g=
>t; >space; -khtml-line-bre=3D> >ak: after-white-space; ">I386_DARWIN&=
>lt;/div><div =3D3D
> >=3D> >style=3D3D3D"word-wrap: break-wo=
>rd; -khtml-nbsp-mode: space; =3D3D
> >=3D> >-khtml-line-break: aft=
>er-white-space; ">AMD64_DARWIN</div><div =3D> >=3D3D
> &g=
>t;style=3D3D3D"word-wrap: break-word; -khtml-nbsp-mode: space; =3D> >=3D3D<=
>BR>> >-khtml-line-break: after-white-space; ">LINUXLIBC6</d=3D>=
> >iv><div =3D3D
> >style=3D3D3D"word-wrap: break-word; -khtm=
>l-nbsp=3D> >-mode: space; =3D3D
> >-khtml-line-break: after-white-=
>space; ">I'=3D> >d like AMD64_LINUX,&nbsp;<span =3D3D
> >=
>;class=3D3D3D"Apple-styl=3D> >e-span" style=3D3D3D"font-family: Tahoma; fon=
>t-size: =3D3D
> >13px; "&=3D> >gt;SPARC64_SOLARISN but no time rig=
>ht now to devote to =3D3D
> >them=3D> >.</span></div>&=
>lt;/span></div><br><div><=3D> >;div>On May 14, 20=
>08, at 1:25 =3D3D
> >PM, Jay wrote:</div>=3D> ><br class=
>=3D3D3D"Apple-interchange-newline"><blockquote =3D3D
> =3D> >&g=
>t;type=3D3D3D"cite"><span class=3D3D3D"Apple-style-span" style=3D3D3D=
>"bor=3D> >der-collapse: =3D3D
> >separate; color: rgb(0, 0, 0); fo=
>nt-family: H=3D> >elvetica; font-size: 12px; =3D3D
> >font-style: =
>normal; font-variant=3D> >: normal; font-weight: normal; =3D3D
> >=
>letter-spacing: normal; line=3D> >-height: normal; orphans: 2; text-align: =
>=3D3D
> >auto; text-indent:=3D> > 0px; text-transform: none; white=
>-space: normal; =3D3D
> >widows: 2;=3D> > word-spacing: 0px; -webk=
>it-border-horizontal-spacing: 0px; =3D3D
> >=3D> >;-webkit-border-v=
>ertical-spacing: 0px; =3D3D
> >-webkit-text-decorat=3D> >ions-in-e=
>ffect: none; -webkit-text-size-adjust: =3D3D
> >auto; -webk=3D> >i=
>t-text-stroke-width: 0; "><div class=3D3D3D"hmmessage" =3D3D
> =
>>=3D> >;style=3D3D3D"font-size: 10pt; font-family: Tahoma; ">What do p=
>eople =3D3D >R>> >run?<br>In particular: NetBSD? OpenBSD?=
> Sparc32? Sparc64? =3D> >PPC64_DARWIN? =3D3D
> >I386_SOLARIS? AMD6=
>4_SOLARIS? SPARC64_SOLARIS?=3D> > ARM_WINCE? =3D3D
> >AMD64_NT?<=
>;br>&nbsp;<br>Just cur=3D> >ious, I'll probably bring up whate=
>ver I =3D3D
> >can, it's fun, and =3D> >yes, get back and fix AMD6=
>4_LINUX to have<br>garbage =3D3D
> >=3D> >collection, NT386G=
>NU and NT386 tests,&nbsp;cross-platform sets, setup =3D> >=3D3D
>=
> >some Tinderboxes, etc...<br>&nbsp;<br>(AMD6=3D> >4_NT:=
> the gcc available for =3D3D
> >this includes a bunch of patche=3D=
>> >s, so I'm inclined to either wait for =3D3D
> >them to go upstr=
>eam,&=3D> >lt;br>or seek an alternate route such as "port" the =3D3D
=
>> >in-p=3D> >roc backend, llvm, generate C, or maybe write an interpr=
>eter for the =3D3D >>> >IL;<br>and "porting" the backend=
> is probably best preceded =3D> >by a) x86 =3D3D
> >LONGINT suppor=
>t b) other x86 targets "for practis=3D> >e", at least =3D3D
> >one=
>,<br>though regarding .obj file forma=3D> >ts, that would be =3D3D>> >tangential.)<br>&nbsp;<br>=3D> >;&nbsp;- =3D3D=
>
> >Jay<br><br><br><br><=3D> >;br><=
>;/div></span></blockquote></div><br>&l=3D> >t;/b=
>ody></html>=3D3D
> >
> >--Apple-Mail-4-6310280=
>=3D> >10--

> >=3D> >> >--_14c076c4-fb7c-48b0-b705-2e38=
>d4b4a333_--=
>
>--_a9d87328-63f1-414c-abcb-03c34a9cee30_
>Content-Type: text/html; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>
>
>
>
>Wow that is crazy.

>The "OS" is backwards compatible.

>The tools -- or at least the headers/libs -- are not backwards compati=
>ble.

>They apparently don't produce binaries that run on older systems.

> 

>Hm, so I did some diffing among
m3-libs\m3core\src\unix\freebsd-*

>they are all amost identical.
and almost all compatible.
Freebsd-1 to=
> -2 is the least compatible.
otherwise the only actual difference I see =
>is
 in Usignal sa_flags and sa_mask getting reversed.
 and =
>sigcontext changed.

>
Otherwise it's mostly things like long vs. unsigned_long,
int64_t vs=
>. quad_t, short vs. int16_t.

>
The DIR record grew, but as long as it is not implemented
in Modula-=
>3 and the new fields not access, no matter.

>Oh one errno value changed.

>Sometimes some types or functions got added, but
 that is ok.

> 

>Maybe more research at a might later date...

> 

> - Jay



>
>

>

>> To: jayk123 at hotmail.com
> CC: m3devel at elegosoft.com
> Subj=
>ect: Re: [M3devel] which platforms? and questions about FreeBSD versioning =
>
> Date: Thu, 15 May 2008 22:54:28 -0700
> From: mika at async.cal=
>tech.edu
> 
> 
> No, sorry, haven't gotten around to test=
>ing the current NT386GNU
> cm3... I have a lot of version synchronizi=
>ng to do, unfortunately :(
> 
> Yes, FreeBSD is backwards-compa=
>tible, *not* forwards-compatible.
> That is, you can build even fairl=
>y complex software packages on an old
> FreeBSD system and expect it =
>to run on the latest release. You cannot,
> as a general rule, build =
>anything on a newer system and expect it to work
> on an older one. T=
>here must be "some" way of doing it that way, but
> I don't know what=
> it is, and I don't know if it's very well supported.
> I keep FreeBS=
>D 4.x systems around for precisely this reason: the binaries
> compil=
>ed there work fine on 5.x and 6.x (as far as I have tested). Not
> th=
>e other way around! In fact it has never worked the other way, as 
> =
>long as I can remember, with FreeBSD.
> 
> This is also why I s=
>uggest that a "FreeBSD4" bootstrap should actually
> be built on Free=
>BSD 4.x and not 5.x, 6.x, or 7.x!
> 
> Mika
> 
> Ja=
>y writes:
> >--_14c076c4-fb7c-48b0-b705-2e38d4b4a333_
> >=
>Content-Type: text/plain; charset=3D"iso-8859-1"
> >Content-Transf=
>er-Encoding: quoted-printable
> >
> >Mika, ok, this is ta=
>ngential: Have you tried the current NT386GNU cm3?
> >=3D20
>=
>; >I meant, more about what "operating systems" that Modula-3 does not s=
>upport=3D
> > do people here use, would like to see Modula-3 on. O=
>r maybe I meant both.
> >=3D20
> >Speaking of the "4" in =
>FreeBSD4:
> >=3D20
> >Has FreeBSD, and the other BSDs, re=
>ally broken backward compat?
> >They really change interfaces a lo=
>t such that binaries built with current h=3D
> >eaders/libs won't =
>run on older versions?
> >And there isn't an easy way on current p=
>latforms to build something using o=3D
> >lder tools to run on old=
>er and newer platforms?
> >Look at Windows for example. If you cal=
>l a "new" function directly, you wil=3D
> >l fail to load on older=
> platforms. So either don't call them, or use LoadLi=3D
> >brary/G=
>etProcAddress. Structures almost never change size, though there is =3D
=
>> >some screwiness there, stuff like:
> >=3D20
> >s=
>truct FOO { size_t Size;
> > int Field1;
> >#if VERSION &=
>gt; 1234
> > int Field2;
> >#endif
> >};
>=
> >=3D20
> >I think it should be more like:
> >=3D20>> >struct FOO { size_t Size;
> > int Field1;
> >#i=
>f VERSION > 1234
> > int Field2;
> >#endif
> >=
>;};
> >=3D20
> >struct FOO_V1{ size_t Size;
> > =
>int Field1;
> >};
> >=3D20
> >struct FOO_V2 { si=
>ze_t Size;
> > int Field1;
> > int Field2;
> >};=
>
> >=3D20
> >#if VERSION > 1234
> >typedef FO=
>O_V2 FOO;
> >#else
> >typedef FOO_V1 FOO;
> >#en=
>dif
> >=3D20
> >I understand that binaries built on the o=
>lder platform will continue to wor=3D
> >k on the newer platform.<=
>BR>> >That is one thing.
> >But it is also useful to be able=
> to build binaries on the newer platform th=3D
> >at will on the o=
>lder platform.
> >Apple also invests a bunch here.
> >=3D=
>20
> >Well, ok, if it was really "bad", there'd be FreeBSD5, 6, 7.=
>
> >I guess maybe they broke this stuff sometimes but haven't in a=
> while?
> >That you can build FreeBSD4 binaries on FreeBSD7 and th=
>e run down to 4?
> >=3D20
> >And then, same questions abo=
>ut OpenBSD and NetBSD.
> >I understand -- I could/must go and inst=
>all a bajillion operating systems a=3D
> >nd test and find out, bu=
>t I don't expect to spend the time that way and pus=3D
> >h comes =
>to shove, any BSD (and Linux, Solaris, NT, CE, etc.) variants I int=3D
&=
>gt; >roduce will have no version number in them, will be built on whatev=
>er I hav=3D
> >e, and it will be unknown if they work on older. An=
>d maybe something will m=3D
> >aterialize to be more portable, lik=
>e interfacing to the Posix via C instead=3D
> > of cloned headers.=
>
> >=3D20
> > - Jay
> >
> >
> >=
>;
> >> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com>=
>; Subject: Re: [M3devel=3D
> >] which platforms? > Date: Thu, 1=
>5 May 2008 14:30:36 -0700> From: mika at asyn=3D
> >c.caltech.edu&=
>gt; > here it is:> > FreeBSD4> PPC_DARWIN> NT386GNU> LINU=
>XLIBC6>=3D
> > > I386_DARWIN coming soon> > Tony Hoski=
>ng writes:> >> >--Apple-Mail-4-6310=3D
> >28010> &g=
>t;Content-Type: text/plain;> > charset=3D3DUS-ASCII;> > format=
>=3D3Dflowed=3D
> >;> > delsp=3D3Dyes> >Content-Transfe=
>r-Encoding: 7bit> >> >SOLgnu> >PPC_DARWIN=3D
> >=
>> >I386_DARWIN> >AMD64_DARWIN> >LINUXLIBC6> >I'd li=
>ke AMD64_LINUX, SPARC64_=3D
> >SOLARISN but no time right now to d=
>evote > >to them.> >> >On May 14, 2008, =3D
> >a=
>t 1:25 PM, Jay wrote:> >> >> What do people run?> >>=
>; In particular: NetBSD=3D
> >? OpenBSD? Sparc32? Sparc64? PPC64_D=
>ARWIN? > >> I386_SOLARIS? AMD64_SOLARIS=3D
> >? SPARC64_S=
>OLARIS? ARM_WINCE? AMD64_NT?> >>> >> Just curious, I'll p=
>robably=3D
> > bring up whatever I can, it's fun, and > >>=
>; yes, get back and fix AMD64_LI=3D
> >NUX to have> >> ga=
>rbage collection, NT386GNU and NT386 tests, cross-platfor=3D
> >m =
>sets, > >> setup some Tinderboxes, etc...> >>> >>=
>; (AMD64_NT: the gcc avai=3D
> >lable for this includes a bunch of=
> patches, > >> so I'm inclined to either =3D
> >wait for =
>them to go upstream,> >> or seek an alternate route such as "port"=
>=3D
> > the in-proc backend, llvm, > >> generate C, or ma=
>ybe write an interpreter =3D
> >for the IL;> >> and "port=
>ing" the backend is probably best preceded by a) x=3D
> >86 > &=
>gt;> LONGINT support b) other x86 targets "for practise", at least one,&=
>gt;=3D
> > >> though regarding .obj file formats, that would=
> be tangential.)> >>> >> =3D
> >- Jay> >&g=
>t;> >>> >>> >>> >> >> >--Apple=
>-Mail-4-631028010> >Content-Type: text=3D
> >/html;> >=
> charset=3D3DUS-ASCII> >Content-Transfer-Encoding: quoted-printable&g=
>t;=3D
> > >> ><html><body style=3D3D3D"word-wrap=
>: break-word; -webkit-nbsp-mode: space=3D
> >; =3D3D> >-webk=
>it-line-break: after-white-space; "><div =3D3D> >apple-content-=
>e=3D
> >dited=3D3D3D"true"><span class=3D3D3D"Apple-style-sp=
>an" =3D3D> >style=3D3D3D"border=3D
> >-collapse: separate; b=
>order-spacing: 0px 0px; color: =3D3D> >rgb(0, 0, 0); fo=3D
> &g=
>t;nt-family: Helvetica; font-size: 12px; font-style: =3D3D> >normal; =
>font-varia=3D
> >nt: normal; font-weight: normal; letter-spacing: =
>=3D3D> >normal; line-height:=3D
> > normal; text-align: auto=
>; =3D3D> >-khtml-text-decorations-in-effect: none; t=3D
> >e=
>xt-indent: 0px; =3D3D> >-apple-text-size-adjust: auto; text-transform=
>: none;=3D
> > orphans: 2; =3D3D> >white-space: normal; wido=
>ws: 2; word-spacing: 0px; "><di=3D
> >v =3D3D> >style=
>=3D3D3D"word-wrap: break-word; -khtml-nbsp-mode: space; =3D3D> >-k=3D=
>
> >html-line-break: after-white-space; "><span class=3D3D3D=
>"Apple-style-span" =3D
> >=3D3D> >style=3D3D3D"border-collap=
>se: separate; border-spacing: 0px 0px; color:=3D
> > =3D3D> >=
>;rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =3D
=
>> >=3D3D> >normal; font-variant: normal; font-weight: normal; l=
>etter-spacing: =3D
> >=3D3D> >normal; line-height: normal; t=
>ext-align: auto; =3D3D> >-khtml-text-deco=3D
> >rations-in-e=
>ffect: none; text-indent: 0px; =3D3D> >-apple-text-size-adjust: a=3D<=
>BR>> >uto; text-transform: none; orphans: 2; =3D3D> >white-spac=
>e: normal; widows: 2=3D
> >; word-spacing: 0px; =3D3D> >">=
>;SOLgnu</span></div><div style=3D3D3D"word-wrap: =3D
>=
> >break-word; =3D3D> >-khtml-nbsp-mode: space; -khtml-line-break: =
>after-white-s=3D
> >pace; =3D3D> >">PPC_DARWIN</div>=
>;<div style=3D3D3D"word-wrap: break-word; -khtml=3D
> >-nbsp-mo=
>de: =3D3D> >space; -khtml-line-break: after-white-space; ">I386_DA=
>RWI=3D
> >N</div><div =3D3D> >style=3D3D3D"word-wra=
>p: break-word; -khtml-nbsp-mode: space=3D
> >; =3D3D> >-khtm=
>l-line-break: after-white-space; ">AMD64_DARWIN</div><div =3D3D=
>>=3D
> > >style=3D3D3D"word-wrap: break-word; -khtml-nbsp-mo=
>de: space; =3D3D> >-khtml-l=3D
> >ine-break: after-white-spa=
>ce; ">LINUXLIBC6</div><div =3D3D> >style=3D3D3D"word-=3D<=
>BR>> >wrap: break-word; -khtml-nbsp-mode: space; =3D3D> >-khtml=
>-line-break: after-w=3D
> >hite-space; ">I'd like AMD64_LINUX,&=
>amp;nbsp;<span =3D3D> >class=3D3D3D"Apple-style=3D
> >-sp=
>an" style=3D3D3D"font-family: Tahoma; font-size: =3D3D> >13px; ">S=
>PARC64_SOL=3D
> >ARISN but no time right now to devote to =3D3D>=
>; >them.</span></div></span></d=3D
> >iv&g=
>t;<br><div><div>On May 14, 2008, at 1:25 =3D3D> >PM=
>, Jay wrote:</div><br cla=3D
> >ss=3D3D3D"Apple-interchan=
>ge-newline"><blockquote =3D3D> >type=3D3D3D"cite"><span =
>=3D
> >class=3D3D3D"Apple-style-span" style=3D3D3D"border-collapse=
>: =3D3D> >separate; co=3D
> >lor: rgb(0, 0, 0); font-family:=
> Helvetica; font-size: 12px; =3D3D> >font-styl=3D
> >e: norm=
>al; font-variant: normal; font-weight: normal; =3D3D> >letter-spacing=
>:=3D
> > normal; line-height: normal; orphans: 2; text-align: =3D3=
>D> >auto; text-inde=3D
> >nt: 0px; text-transform: none; whi=
>te-space: normal; =3D3D> >widows: 2; word-s=3D
> >pacing: 0p=
>x; -webkit-border-horizontal-spacing: 0px; =3D3D> >-webkit-border-v=
>=3D
> >ertical-spacing: 0px; =3D3D> >-webkit-text-decoration=
>s-in-effect: none; -webk=3D
> >it-text-size-adjust: =3D3D> >=
>auto; -webkit-text-stroke-width: 0; "><div class=3D
> >=3D3D=
>3D"hmmessage" =3D3D> >style=3D3D3D"font-size: 10pt; font-family: Taho=
>ma; ">W=3D
> >hat do people =3D3D> >run?<br>In part=
>icular: NetBSD? OpenBSD? Sparc32? Sparc6=3D
> >4? PPC64_DARWIN? =
>=3D3D> >I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM_WI=3D
&g=
>t; >NCE? =3D3D> >AMD64_NT?<br>&nbsp;<br>Just curio=
>us, I'll probably bring up what=3D
> >ever I =3D3D> >can, it=
>'s fun, and yes, get back and fix AMD64_LINUX to have<b=3D
> >r=
>>garbage =3D3D> >collection, NT386GNU and NT386 tests,&nbsp;cr=
>oss-platform s=3D
> >ets, setup =3D3D> >some Tinderboxes, et=
>c...<br>&nbsp;<br>(AMD64_NT: the gcc a=3D
> >vaila=
>ble for =3D3D> >this includes a bunch of patches, so I'm inclined to =
>eit=3D
> >her wait for =3D3D> >them to go upstream,<br>=
>;or seek an alternate route such =3D
> >as "port" the =3D3D> &g=
>t;in-proc backend, llvm, generate C, or maybe write an in=3D
> >te=
>rpreter for the =3D3D> >IL;<br>and "porting" the backend is pro=
>bably best p=3D
> >receded by a) x86 =3D3D> >LONGINT support=
> b) other x86 targets "for practise"=3D
> >, at least =3D3D> &g=
>t;one,<br>though regarding .obj file formats, that would be =3D
&g=
>t; >=3D3D> >tangential.)<br>&nbsp;<br>&nbsp;- =
>=3D3D> >Jay<br><br><br><br><br></div=
>>=3D
> ></span></blockquote></div><br>&=
>lt;/body></html>=3D3D> >> >--Apple-Mail-4-6310280=3DR>> >10--=3D
> >
> >--_14c076c4-fb7c-48b0-b705-2e38=
>d4b4a333_
> >Content-Type: text/html; charset=3D"iso-8859-1"
&g=
>t; >Content-Transfer-Encoding: quoted-printable
> >
> >=
>;<html>
> ><head>
> ><style>
> &g=
>t;.hmmessage P
> >{
> >margin:0px;
> >padding:0p=
>x
> >}
> >body.hmmessage
> >{
> >FONT-S=
>IZE: 10pt;
> >FONT-FAMILY:Tahoma
> >}
> ></st=
>yle>
> ></head>
> ><body class=3D3D'hmmessage=
>'>Mika, ok, this is&nbsp;tangential:&nbsp;Have you =3D
> &=
>gt;tried the current NT386GNU cm3?<BR>
> >&nbsp;<BR&g=
>t;
> >I meant, more about what "operating systems" that Modula-3 d=
>oes not support=3D
> > do people here use, would like to see Modul=
>a-3 on. Or maybe I meant both.<=3D
> >BR>
> >&n=
>bsp;<BR>
> >Speaking of the "4" in FreeBSD4:<BR>
&g=
>t; >&nbsp;<BR>
> >Has FreeBSD, and the other BSDs, re=
>ally broken&nbsp;backward compat?<BR>
> >They really cha=
>nge interfaces a lot such that binaries built with current h=3D
> >=
>;eaders/libs won't run on older versions?<BR>
> >And there i=
>sn't an easy way on current platforms to build something using o=3D
>=
> >lder tools to run on older and newer platforms?<BR>
> >=
>Look at Windows for example. If you call a "new" function directly, you wil=
>=3D
> >l fail to load on older platforms. So either don't call the=
>m, or use LoadLi=3D
> >brary/GetProcAddress. Structures almost nev=
>er change size, though there is =3D
> >some screwiness there, stuf=
>f like:<BR>
> >&nbsp;<BR>
> >struct FOO {=
><BR>&nbsp; size_t Size;<BR>
> >&nbsp; int Fiel=
>d1;<BR>
> >#if VERSION &gt; 1234<BR>
> >&=
>amp;nbsp; int Field2;<BR>
> >#endif<BR>
> >};=
><BR>
> >&nbsp;<BR>
> >I think it should b=
>e more like:<BR>
> >&nbsp;<BR>
> >struct =
>FOO {<BR>&nbsp; size_t Size;<BR>
> >&nbsp; int=
> Field1;<BR>
> >#if VERSION &gt; 1234<BR>
> =
>>&nbsp; int Field2;<BR>
> >#endif<BR>
> &=
>gt;};<BR>
> >&nbsp;<BR>
> >struct FOO_V1{=
><BR>&nbsp; size_t Size;<BR>
> >&nbsp; int Fiel=
>d1;<BR>
> >};<BR>
> >&nbsp;<BR>
=
>> >struct FOO_V2 {<BR>&nbsp; size_t Size;<BR>
>=
> >&nbsp; int Field1;<BR>
> >&nbsp; int Field2;<=
>;BR>
> >};<BR>
> >&nbsp;<BR>
> &=
>gt;#if VERSION &gt; 1234<BR>
> >typedef FOO_V2 FOO;<B=
>R>
> >#else<BR>
> >typedef FOO_V1 FOO;<BR>=
>
> >#endif<BR>
> >&nbsp;<BR>
> >=
>I understand that binaries built on the older platform will continue to wor=
>=3D
> >k on the newer platform.<BR>
> >That is one =
>thing.<BR>
> >But it is also useful to be able to build bina=
>ries on the newer platform th=3D
> >at will on the older platform.=
><BR>
> >Apple also invests a bunch here.<BR>
> &=
>gt;&nbsp;<BR>
> >Well, ok, if it was really "bad", there=
>'d be FreeBSD5, 6, 7.<BR>
> >I guess maybe they broke this s=
>tuff sometimes but haven't in a while?<BR>
> >That you can b=
>uild FreeBSD4 binaries on FreeBSD7 and the run down to 4?<BR>
>=
> >&nbsp;<BR>
> >And then, same questions about OpenBS=
>D and NetBSD.<BR>
> >I understand -- I could/must go and ins=
>tall a bajillion operating systems a=3D
> >nd test and find out, b=
>ut I don't expect to spend the time that way and pus=3D
> >h comes=
> to shove, any BSD (and Linux, Solaris, NT, CE, etc.) variants I int=3D
=
>> >roduce will have no version number in them, will be built on whate=
>ver I hav=3D
> >e, and it will be unknown if they work on older. A=
>nd maybe something will m=3D
> >aterialize to be more portable, li=
>ke interfacing to the Posix via C instead=3D
> > of cloned headers=
>.<BR>
> >&nbsp;<BR>
> >&nbsp;- Jay<=
>;BR><BR><BR>
> >
> ><HR id=3D3DstopSpel=
>ling>
> ><BR>
> >&gt; To: jayk123 at hotmail.co=
>m<BR>&gt; CC: m3devel at elegosoft.com<BR>&gt; Subj=3D
=
>> >ect: Re: [M3devel] which platforms? <BR>&gt; Date: Thu, =
>15 May 2008 14:30:3=3D
> >6 -0700<BR>&gt; From: mika at asy=
>nc.caltech.edu<BR>&gt; <BR>&gt; here it is:<B=3D
=
>> >R>&gt; <BR>&gt; FreeBSD4<BR>&gt; PPC_DA=
>RWIN<BR>&gt; NT386GNU<BR>&gt; LINUXL=3D
> >IBC=
>6<BR>&gt; <BR>&gt; I386_DARWIN coming soon<BR>&am=
>p;gt; <BR>&gt; Tony Hosking=3D
> > writes:<BR>&=
>;gt; &gt;<BR>&gt; &gt;--Apple-Mail-4-631028010<BR>&=
>amp;gt; &gt;Cont=3D
> >ent-Type: text/plain;<BR>&gt;=
> &gt; charset=3D3DUS-ASCII;<BR>&gt; &gt; format=3D
>=
>; >=3D3Dflowed;<BR>&gt; &gt; delsp=3D3Dyes<BR>&g=
>t; &gt;Content-Transfer-Encoding: =3D
> >7bit<BR>&gt=
>; &gt;<BR>&gt; &gt;SOLgnu<BR>&gt; &gt;PPC_D=
>ARWIN<BR>&gt; &gt;I38=3D
> >6_DARWIN<BR>&g=
>t; &gt;AMD64_DARWIN<BR>&gt; &gt;LINUXLIBC6<BR>&=
>gt; &gt;I'd li=3D
> >ke AMD64_LINUX, SPARC64_SOLARISN but no t=
>ime right now to devote <BR>&gt; &=3D
> >gt;to them.=
><BR>&gt; &gt;<BR>&gt; &gt;On May 14, 2008, at 1=
>:25 PM, Jay wrote=3D
> >:<BR>&gt; &gt;<BR>&=
>;gt; &gt;&gt; What do people run?<BR>&gt; &gt;&gt=
>; In par=3D
> >ticular: NetBSD? OpenBSD? Sparc32? Sparc64? PPC64_D=
>ARWIN? <BR>&gt; &gt;&gt;=3D
> > I386_SOLARIS? AM=
>D64_SOLARIS? SPARC64_SOLARIS? ARM_WINCE? AMD64_NT?<BR>&gt;=3D
=
>> > &gt;&gt;<BR>&gt; &gt;&gt; Just curious,=
> I'll probably bring up whatever I =3D
> >can, it's fun, and <B=
>R>&gt; &gt;&gt; yes, get back and fix AMD64_LINUX to h=3D>> >ave<BR>&gt; &gt;&gt; garbage collection, NT386G=
>NU and NT386 tests, cross-pl=3D
> >atform sets, <BR>&gt;=
> &gt;&gt; setup some Tinderboxes, etc...<BR>&gt; &gt;=
>&=3D
> >gt;<BR>&gt; &gt;&gt; (AMD64_NT: the =
>gcc available for this includes a bunch=3D
> > of patches, <BR&=
>gt;&gt; &gt;&gt; so I'm inclined to either wait for them to g=
>=3D
> >o upstream,<BR>&gt; &gt;&gt; or seek an a=
>lternate route such as "port" the =3D
> >in-proc backend, llvm, &l=
>t;BR>&gt; &gt;&gt; generate C, or maybe write an inte=3D
=
>> >rpreter for the IL;<BR>&gt; &gt;&gt; and "portin=
>g" the backend is probably =3D
> >best preceded by a) x86 <BR&g=
>t;&gt; &gt;&gt; LONGINT support b) other x86 targ=3D
> &g=
>t;ets "for practise", at least one,<BR>&gt; &gt;&gt; thou=
>gh regarding .obj fi=3D
> >le formats, that would be tangential.)&=
>lt;BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt; - =3D=
>
> >Jay<BR>&gt; &gt;&gt;<BR>&gt; &=
>gt;&gt;<BR>&gt; &gt;&gt;<BR>&gt; &gt;&a=
>mp;gt;<BR>=3D
> >&gt; &gt;<BR>&gt; &gt=
>;<BR>&gt; &gt;--Apple-Mail-4-631028010<BR>&gt; &=
>;gt;Con=3D
> >tent-Type: text/html;<BR>&gt; &gt; cha=
>rset=3D3DUS-ASCII<BR>&gt; &gt;Content-T=3D
> >ransfe=
>r-Encoding: quoted-printable<BR>&gt; &gt;<BR>&gt; &=
>amp;gt;&lt;html&gt;&lt=3D
> >;body style=3D3D3D"word-w=
>rap: break-word; -webkit-nbsp-mode: space; =3D3D<BR>&g=3D
>=
> >t; &gt;-webkit-line-break: after-white-space; "&gt;&lt;div=
> =3D3D<BR>&gt; &gt;=3D
> >apple-content-edited=3D3D3=
>D"true"&gt;&lt;span class=3D3D3D"Apple-style-span" =3D
> >=
>=3D3D<BR>&gt; &gt;style=3D3D3D"border-collapse: separate; bor=
>der-spacing: 0px 0=3D
> >px; color: =3D3D<BR>&gt; &g=
>t;rgb(0, 0, 0); font-family: Helvetica; font-size:=3D
> > 12px; fo=
>nt-style: =3D3D<BR>&gt; &gt;normal; font-variant: normal; fon=
>t-weigh=3D
> >t: normal; letter-spacing: =3D3D<BR>&gt; &=
>amp;gt;normal; line-height: normal; tex=3D
> >t-align: auto; =3D3D=
><BR>&gt; &gt;-khtml-text-decorations-in-effect: none; tex=3D<=
>BR>> >t-indent: 0px; =3D3D<BR>&gt; &gt;-apple-text-size=
>-adjust: auto; text-transfor=3D
> >m: none; orphans: 2; =3D3D<B=
>R>&gt; &gt;white-space: normal; widows: 2; word-s=3D
> >=
>;pacing: 0px; "&gt;&lt;div =3D3D<BR>&gt; &gt;style=3D=
>3D3D"word-wrap: break-word;=3D
> > -khtml-nbsp-mode: space; =3D3D&=
>lt;BR>&gt; &gt;-khtml-line-break: after-white-sp=3D
> >=
>ace; "&gt;&lt;span class=3D3D3D"Apple-style-span" =3D3D<BR>&a=
>mp;gt; &gt;style=3D3D3D"=3D
> >border-collapse: separate; bord=
>er-spacing: 0px 0px; color: =3D3D<BR>&gt; &gt;=3D
> >=
>;rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =3D3D&l=
>t;BR>&=3D
> >gt; &gt;normal; font-variant: normal; font=
>-weight: normal; letter-spacing: =3D
> >=3D3D<BR>&gt; &a=
>mp;gt;normal; line-height: normal; text-align: auto; =3D3D<BR>&gt=
>; =3D
> >&gt;-khtml-text-decorations-in-effect: none; text-ind=
>ent: 0px; =3D3D<BR>&gt; =3D
> >&gt;-apple-text-size-=
>adjust: auto; text-transform: none; orphans: 2; =3D3D<BR=3D
> >=
>>&gt; &gt;white-space: normal; widows: 2; word-spacing: 0px; =3D=
>3D<BR>&gt; &g=3D
> >t;"&gt;SOLgnu&lt;/span&a=
>mp;gt;&lt;/div&gt;&lt;div style=3D3D3D"word-wrap: break-w=3D>> >ord; =3D3D<BR>&gt; &gt;-khtml-nbsp-mode: space; -kh=
>tml-line-break: after-whit=3D
> >e-space; =3D3D<BR>&gt; =
>&gt;"&gt;PPC_DARWIN&lt;/div&gt;&lt;div style=3D3D3D"wor=
>d=3D
> >-wrap: break-word; -khtml-nbsp-mode: =3D3D<BR>&g=
>t; &gt;space; -khtml-line-bre=3D
> >ak: after-white-space; "&a=
>mp;gt;I386_DARWIN&lt;/div&gt;&lt;div =3D3D<BR>&gt; &a=
>mp;gt;=3D
> >style=3D3D3D"word-wrap: break-word; -khtml-nbsp-mode:=
> space; =3D3D<BR>&gt; &gt;=3D
> >-khtml-line-break: =
>after-white-space; "&gt;AMD64_DARWIN&lt;/div&gt;&lt;div =3D=
>
> >=3D3D<BR>&gt; &gt;style=3D3D3D"word-wrap: break-=
>word; -khtml-nbsp-mode: space; =3D
> >=3D3D<BR>&gt; &=
>;gt;-khtml-line-break: after-white-space; "&gt;LINUXLIBC6&lt;/d=3D<=
>BR>> >iv&gt;&lt;div =3D3D<BR>&gt; &gt;style=3D3=
>D3D"word-wrap: break-word; -khtml-nbsp=3D
> >-mode: space; =3D3D&l=
>t;BR>&gt; &gt;-khtml-line-break: after-white-space; "&gt;I'=
>=3D
> >d like AMD64_LINUX,&amp;nbsp;&lt;span =3D3D<BR&g=
>t;&gt; &gt;class=3D3D3D"Apple-styl=3D
> >e-span" style=3D3=
>D3D"font-family: Tahoma; font-size: =3D3D<BR>&gt; &gt;13px; "=
>&=3D
> >gt;SPARC64_SOLARISN but no time right now to devote to=
> =3D3D<BR>&gt; &gt;them=3D
> >.&lt;/span&gt;=
>&lt;/div&gt;&lt;/span&gt;&lt;/div&gt;&lt;br&=
>;gt;&lt;div&gt;&lt=3D
> >;div&gt;On May 14, 2008, =
>at 1:25 =3D3D<BR>&gt; &gt;PM, Jay wrote:&lt;/div&gt;=
>=3D
> >&lt;br class=3D3D3D"Apple-interchange-newline"&gt;&=
>amp;lt;blockquote =3D3D<BR>&gt; =3D
> >&gt;type=3D3D=
>3D"cite"&gt;&lt;span class=3D3D3D"Apple-style-span" style=3D3D3D"bo=
>r=3D
> >der-collapse: =3D3D<BR>&gt; &gt;separate; co=
>lor: rgb(0, 0, 0); font-family: H=3D
> >elvetica; font-size: 12px;=
> =3D3D<BR>&gt; &gt;font-style: normal; font-variant=3D
>=
>; >: normal; font-weight: normal; =3D3D<BR>&gt; &gt;letter=
>-spacing: normal; line=3D
> >-height: normal; orphans: 2; text-ali=
>gn: =3D3D<BR>&gt; &gt;auto; text-indent:=3D
> > 0px;=
> text-transform: none; white-space: normal; =3D3D<BR>&gt; &gt=
>;widows: 2;=3D
> > word-spacing: 0px; -webkit-border-horizontal-sp=
>acing: 0px; =3D3D<BR>&gt; &gt=3D
> >;-webkit-border-=
>vertical-spacing: 0px; =3D3D<BR>&gt; &gt;-webkit-text-decorat=
>=3D
> >ions-in-effect: none; -webkit-text-size-adjust: =3D3D<BR=
>>&gt; &gt;auto; -webk=3D
> >it-text-stroke-width: 0; "&=
>amp;gt;&lt;div class=3D3D3D"hmmessage" =3D3D<BR>&gt; &gt=
>=3D
> >;style=3D3D3D"font-size: 10pt; font-family: Tahoma; "&g=
>t;What do people =3D3D<B=3D
> >R>&gt; &gt;run?&l=
>t;br&gt;In particular: NetBSD? OpenBSD? Sparc32? Sparc64? =3D
> &=
>gt;PPC64_DARWIN? =3D3D<BR>&gt; &gt;I386_SOLARIS? AMD64_SOLARI=
>S? SPARC64_SOLARIS?=3D
> > ARM_WINCE? =3D3D<BR>&gt; &=
>;gt;AMD64_NT?&lt;br&gt;&amp;nbsp;&lt;br&gt;Just cur=3D<=
>BR>> >ious, I'll probably bring up whatever I =3D3D<BR>&gt;=
> &gt;can, it's fun, and =3D
> >yes, get back and fix AMD64_LIN=
>UX to have&lt;br&gt;garbage =3D3D<BR>&gt; &gt;=3D
=
>> >collection, NT386GNU and NT386 tests,&amp;nbsp;cross-platform =
>sets, setup =3D
> >=3D3D<BR>&gt; &gt;some Tinderboxe=
>s, etc...&lt;br&gt;&amp;nbsp;&lt;br&gt;(AMD6=3D
>=
> >4_NT: the gcc available for =3D3D<BR>&gt; &gt;this inclu=
>des a bunch of patche=3D
> >s, so I'm inclined to either wait for =
>=3D3D<BR>&gt; &gt;them to go upstream,&=3D
> >lt=
>;br&gt;or seek an alternate route such as "port" the =3D3D<BR>&am=
>p;gt; &gt;in-p=3D
> >roc backend, llvm, generate C, or maybe w=
>rite an interpreter for the =3D3D<BR=3D
> >>&gt; &gt=
>;IL;&lt;br&gt;and "porting" the backend is probably best preceded =
>=3D
> >by a) x86 =3D3D<BR>&gt; &gt;LONGINT support b=
>) other x86 targets "for practis=3D
> >e", at least =3D3D<BR>=
>;&gt; &gt;one,&lt;br&gt;though regarding .obj file forma=3D=
>
> >ts, that would be =3D3D<BR>&gt; &gt;tangential.)=
>&lt;br&gt;&amp;nbsp;&lt;br&gt=3D
> >;&amp;=
>nbsp;- =3D3D<BR>&gt; &gt;Jay&lt;br&gt;&lt;br&=
>gt;&lt;br&gt;&lt;br&gt;&lt=3D
> >;br&gt;&a=
>mp;lt;/div&gt;&lt;/span&gt;&lt;/blockquote&gt;&lt;/=
>div&gt;&lt;br&gt;&l=3D
> >t;/body&gt;&lt;/=
>html&gt;=3D3D<BR>&gt; &gt;<BR>&gt; &gt;--Ap=
>ple-Mail-4-6310280=3D
> >10--<BR><BR></body>
=
>> ></html>=3D
> >
> >--_14c076c4-fb7c-48b0-b7=
>05-2e38d4b4a333_--


>=
>
>--_a9d87328-63f1-414c-abcb-03c34a9cee30_--


From jayk123 at hotmail.com  Sun May 18 20:54:41 2008
From: jayk123 at hotmail.com (Jay)
Date: Sun, 18 May 2008 18:54:41 +0000
Subject: [M3devel] modula-3/pthreads
In-Reply-To: <20080518162217.GA27882@schlund.de>
References: 
	<20080518162217.GA27882@schlund.de>
Message-ID: 

Given that pthreads has all of mutex, rwlock, and most importantly condition variables, couldn't ThreadPThread.m3 be very much thinner?
Like, not do any of its own scheduling?
Also, shouldn;t the attr for stack size be destroyed? Else leak on some platforms? Is it even needed at all?
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From ndantam at purdue.edu  Sun May 18 22:08:20 2008
From: ndantam at purdue.edu (Neil T. Dantam)
Date: Sun, 18 May 2008 16:08:20 -0400
Subject: [M3devel] modula-3/pthreads
In-Reply-To: 
References: 	<20080518162217.GA27882@schlund.de>
	
Message-ID: <48308CB4.1050902@purdue.edu>

Jay wrote:
> Given that pthreads has all of mutex, rwlock, and most importantly
> condition variables, couldn't ThreadPThread.m3 be very much thinner?

Much of that is Object wrappers around the pthread primitives.
This is necessary so that we can garbage collect these types.

Also, RWLocks aren't really standard pthreads, but they seem to be
implemented on the platforms we currently care about.

> Like, not do any of its own scheduling?

The condition variable implementation does seem to do more than
necessary.  Perhaps this is so that it will do the right thing on
pthreads implementations that don't?

We also need to wrap pthread_create to maintain some thread local state
used for GC and probably other things as well.  It may be possible to
achieve this another way (ie using gcc's thread-local builtins), but
that would be a nontrivial change.

> Also, shouldn;t the attr for stack size be destroyed? Else leak on
> some platforms?

Probably.

> Is it even needed at all?

Not on linux, at least.

--
Neil


From dabenavidesd at yahoo.es  Mon May 19 00:39:58 2008
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sun, 18 May 2008 22:39:58 +0000 (GMT)
Subject: [M3devel] garbage collection problem on LINUXLIBC6?
Message-ID: <509246.28438.qm@web27102.mail.ukl.yahoo.com>

An HTML attachment was scrubbed...
URL: 

From hosking at cs.purdue.edu  Mon May 19 13:16:23 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 19 May 2008 07:16:23 -0400
Subject: [M3devel] modula-3/pthreads
In-Reply-To: 
References: 
	<20080518162217.GA27882@schlund.de>
	
Message-ID: 

Jay,

Indeed, I originally tried something slightly thinner (see the logs  
for the gory evolution...) but it only happened to work with Linux  
threads.  What we have now is about as thin as it can be, given the  
constraints imposed by the need to schedule thread alerts, etc.  For  
example, on some systems one cannot reliably wake up a specific thread  
from among many that are waiting on a condition.  Hence the need for  
every M3 thread too have its own private condition variable on which  
it will park itself pending alerts and conditions.


-- Tony

On May 18, 2008, at 2:54 PM, Jay wrote:

> Given that pthreads has all of mutex, rwlock, and most importantly  
> condition variables, couldn't ThreadPThread.m3 be very much thinner?
> Like, not do any of its own scheduling?
>
> Also, shouldn;t the attr for stack size be destroyed? Else leak on  
> some platforms? Is it even needed at all?
>
>  - Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Mon May 19 14:04:10 2008
From: jayk123 at hotmail.com (Jay)
Date: Mon, 19 May 2008 12:04:10 +0000
Subject: [M3devel] modula-3/pthreads
In-Reply-To: 
References: 
	<20080518162217.GA27882@schlund.de>
	
	
Message-ID: 

Tony, does Posix say that? Or testing? Esp. if this behavior is "substandard", should we have GoodPThread.m3 and BadPThread.m3?
And the "attr" is leaked, and perhaps unnecessary?
I'll be running a loop "soon" to see if the attr is leaked, but can't yet.
 
 - Jay


CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] modula-3/pthreadsDate: Mon, 19 May 2008 07:16:23 -0400


Jay,

Indeed, I originally tried something slightly thinner (see the logs for the gory evolution...) but it only happened to work with Linux threads.  What we have now is about as thin as it can be, given the constraints imposed by the need to schedule thread alerts, etc.  For example, on some systems one cannot reliably wake up a specific thread from among many that are waiting on a condition.  Hence the need for every M3 thread too have its own private condition variable on which it will park itself pending alerts and conditions.


-- Tony

On May 18, 2008, at 2:54 PM, Jay wrote:

Given that pthreads has all of mutex, rwlock, and most importantly condition variables, couldn't ThreadPThread.m3 be very much thinner?Like, not do any of its own scheduling?Also, shouldn;t the attr for stack size be destroyed? Else leak on some platforms? Is it even needed at all? - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From hosking at cs.purdue.edu  Mon May 19 14:31:56 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 19 May 2008 08:31:56 -0400
Subject: [M3devel] modula-3/pthreads
In-Reply-To: 
References: 
	<20080518162217.GA27882@schlund.de>
	
	
	
Message-ID: <54B5F97D-35EC-4902-804D-158F3FDE1650@cs.purdue.edu>

POSIX is *very* liberal in what behaviors it allows.  I don't think it  
makes any sense to further divide thread subsystems into good/bad  
based on behaviors that are undefined by the SPEC.

On May 19, 2008, at 8:04 AM, Jay wrote:

> Tony, does Posix say that? Or testing? Esp. if this behavior is  
> "substandard", should we have GoodPThread.m3 and BadPThread.m3?
> And the "attr" is leaked, and perhaps unnecessary?
> I'll be running a loop "soon" to see if the attr is leaked, but  
> can't yet.
>
>  - Jay
>
> CC: m3devel at elegosoft.com
> From: hosking at cs.purdue.edu
> To: jayk123 at hotmail.com
> Subject: Re: [M3devel] modula-3/pthreads
> Date: Mon, 19 May 2008 07:16:23 -0400
>
> Jay,
>
> Indeed, I originally tried something slightly thinner (see the logs  
> for the gory evolution...) but it only happened to work with Linux  
> threads.  What we have now is about as thin as it can be, given the  
> constraints imposed by the need to schedule thread alerts, etc.  For  
> example, on some systems one cannot reliably wake up a specific  
> thread from among many that are waiting on a condition.  Hence the  
> need for every M3 thread too have its own private condition variable  
> on which it will park itself pending alerts and conditions.
>
>
> -- Tony
>
> On May 18, 2008, at 2:54 PM, Jay wrote:
>
> Given that pthreads has all of mutex, rwlock, and most importantly  
> condition variables, couldn't ThreadPThread.m3 be very much thinner?
> Like, not do any of its own scheduling?
>
> Also, shouldn;t the attr for stack size be destroyed? Else leak on  
> some platforms? Is it even needed at all?
>
>  - Jay
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Mon May 19 14:47:46 2008
From: jayk123 at hotmail.com (Jay)
Date: Mon, 19 May 2008 12:47:46 +0000
Subject: [M3devel] gcc/m3cc/cm3c for OpenBSD?
Message-ID: 

What is the right way to handle these: http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/gcc/4.3/patches/
I imagine: 1) import them m3-sys/m3cc/src/patches/openbsd 2) perhaps use a vendor branch for the import   however they haven't changed in 14 months   and HOPEFULLY they get ported upstream 3) apply patches at build time
Seems kind of bad, but I figure also too much to manage to checkin the patch results?I realize it stinks largely due to the risk of accidentally doing what is avoided.Maybe there is like "VPATH" and the to-be-patched files can be copied in the outputdirectory and patched there?
 They aren't all needed, by far, but definitely some of them are needed.
 
 not needed, roughly:    *objc*, *ada*, *lib*
 needed, roughly:   *config* 
 unclear:  all the NULL to (void*) 0 diffs, which are a lot of it
 I kinda'thunk:  #ifdef __cplusplus  #define NULL 0 /* would perhaps need patch, depending on what calling conventions
  do with parameters and return values smaller than a word */   #else  #define NULL ((void*) 0) /* no need for patch */   #endif
in particular because in C++ a cast from void* to another* is needed, but not in C.
In fact I see this on OpenBSD:
 #ifndef NULL #ifdef  __GNUG__ #define NULL    __null #else #define NULL    0L #endif
Similar question for the AMD64_NT gcc patches, though these are newer, apparentlystill need testing, and since they are new, more hope they will go upstream.I don't know why the OpenBSD patches linger, I didn't ask.
I'll proceed as my suggest takes but presumably won't be read to commit  till after broader judgement/consensus rendered.
  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Mon May 19 17:08:05 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Mon, 19 May 2008 11:08:05 -0400
Subject: [M3devel] garbage collection problem on LINUXLIBC6?
In-Reply-To: <509246.28438.qm@web27102.mail.ukl.yahoo.com>
References: <509246.28438.qm@web27102.mail.ukl.yahoo.com>
Message-ID: <48315F96.1E75.00D7.1@scires.com>

Daniel, I have this same problem on GUI applications created on cm3
v4.1.  If I don't put "@M3novm" on the command line, the programs crash
during startup.  It has something to do with the garbage collector.  In
my testing of cm3 d5.7.0 on Windows XP, I have not run into the problem
yet, so I think Tony has fixed it with his new garbage collector, at
least on Windows.
Regards,
Randy

>>> "Daniel Alejandro Benavides D."  5/18/2008
6:39 PM >>>

Dear developers:
I'm running a new installed cm3 on an ubuntu 8.04 32 bits, and I can't
run anything with gui if I don't use @M3nogc
The rest of the applications, the compiler, and m3browser seem to work
without problems *?
I'm debugging mentor but I just got this until now:
Breakpoint 5, Init () at ../src/color/ColorName.m3:207
207           IF table.put (NormalizeName (Basic [i].name), i) THEN
(m3gdb) where
#0  Init () at ../src/color/ColorName.m3:207
#1  0xb7c7b7ff in ColorName (mode=1) at ../src/color/ColorName.m3:214
#2  0xb70e2389 in RunMainBody (m=16_b7ca2fa0) at
../src/runtime/common/RTLinker.m3:399
#3  0xb70e2055 in RunMainBody (m=16_b7d38100) at
../src/runtime/common/RTLinker.m3:379
#4  0xb70e2055 in RunMainBody (m=16_b7d2fe20) at
../src/runtime/common/RTLinker.m3:379
#5  0xb70e2055 in RunMainBody (m=16_b7d34480) at
../src/runtime/common/RTLinker.m3:379
#6  0xb70e2055 in RunMainBody (m=16_b7d30d60) at
../src/runtime/common/RTLinker.m3:379
#7  0xb70e2055 in RunMainBody (m=16_b7d4d620) at
../src/runtime/common/RTLinker.m3:379
#8  0xb70e2055 in RunMainBody (m=16_b7e31d80) at
../src/runtime/common/RTLinker.m3:379
#9  0xb70e2055 in RunMainBody (m=16_b7e33220) at
../src/runtime/common/RTLinker.m3:379
#10 0xb70e2055 in RunMainBody (m=16_b7e36d40) at
../src/runtime/common/RTLinker.m3:379
#11 0xb70e2055 in RunMainBody (m=16_b7e364e0) at
../src/runtime/common/RTLinker.m3:379
#12 0xb70e2055 in RunMainBody (m=16_b7e36ba0) at
../src/runtime/common/RTLinker.m3:379
#13 0xb70e2055 in RunMainBody (m=16_b7e32cc0) at
../src/runtime/common/RTLinker.m3:379
#14 0xb70e2055 in RunMainBody (m=16_b7e32900) at
../src/runtime/common/RTLinker.m3:379
#15 0xb70e2055 in RunMainBody (m=16_08255600) at
../src/runtime/common/RTLinker.m3:379
#16 0xb70e2055 in RunMainBody (m=16_08256040) at
../src/runtime/common/RTLinker.m3:379
#17 0xb70e2055 in RunMainBody (m=16_08312aa0) at
../src/runtime/common/RTLinker.m3:379
#18 0xb70e0dff in AddUnitI (m=16_08312aa0) at
../src/runtime/common/RTLinker.m3:113
#19 0xb70e0e8d in AddUnit (b={"Main_M3", Declared at:
../src/Main.m3:164}) at ../src/runtime/common/RTLinker.m3:122
#20 0x0806df1e in main (argc=3, argv=0xbfa03774, envp=0xbfa03784) at
_m3main.mc:4
#21 0xb6d44450 in __libc_start_main () from
/lib/tls/i686/cmov/libc.so.6
#22 0x0806de71 in _start ()
(m3gdb) cont
Continuando.

Breakpoint 5, Init () at ../src/color/ColorName.m3:207
207           IF table.put (NormalizeName (Basic [i].name), i) THEN
(m3gdb) cont
and the process hangs there when debugging mentor.

I have checked  Juno under m3gdb after have killed it and got:

(m3gdb) where
#0  0xb7fb0410 in __kernel_vsyscall ()
#1  0xb7018ae7 in pthread_kill () from
/lib/tls/i686/cmov/libpthread.so.0
#2  0xb728c397 in SignalThread (act=16_0813c120, state=Stopping) at
../src/thread/PTHREAD/ThreadPThread.m3:1058
#3  0xb728c55e in StopWorld () at
../src/thread/PTHREAD/ThreadPThread.m3:1116
#4  0xb728b9e7 in SuspendOthers () at
../src/thread/PTHREAD/ThreadPThread.m3:905
#5  0xb7265244 in CollectSomeInStateZero () at
../src/runtime/common/RTCollector.m3:755
#6  0xb7265203 in CollectSome () at
../src/runtime/common/RTCollector.m3:729
#7  0xb7264c24 in CollectEnough () at
../src/runtime/common/RTCollector.m3:656
#8  0xb72686c1 in AllocTraced (def=16_b7be1400, dataSize=12,
dataAlignment=4, initProc=NIL)
    at ../src/runtime/common/RTCollector.m3:1462
#9  0xb725ad8f in GetTracedRef (def=16_b7be1400) at
../src/runtime/common/RTAllocator.m3:191
#10 0xb725a987 in AllocateTracedRef (defn=16_b7be1400) at
../src/runtime/common/RTAllocator.m3:126
#11 0xb7b5d8fb in Put (tbl=16_b6e50438, key=8047, val=244) at
../LINUXLIBC6/IntIntTbl.m3 => ../src/table/Table.mg:127
#12 0xb7dd4e2c in Set (a='>', b='o', c=244, bothCases=FALSE,
reversed=TRUE) at ../src/etext/KeyFilter.m3:288
#13 0xb7dd521c in Set (a='o', b='>', c=244, bothCases=FALSE,
reversed=FALSE) at ../src/etext/KeyFilter.m3:304
#14 0xb7dd5882 in KeyFilter (mode=1) at ../src/etext/KeyFilter.m3:437
#15 0xb7273389 in RunMainBody (m=16_b7e51da0) at
../src/runtime/common/RTLinker.m3:399
#16 0xb7273055 in RunMainBody (m=16_b7e547e0) at
../src/runtime/common/RTLinker.m3:379
#17 0xb7273055 in RunMainBody (m=16_b7e56c00) at
../src/runtime/common/RTLinker.m3:379
#18 0xb7273055 in RunMainBody (m=16_b7e54240) at
../src/runtime/common/RTLinker.m3:379
#19 0xb7273055 in RunMainBody (m=16_b7e537e0) at
../src/runtime/common/RTLinker.m3:379
#20 0xb7273055 in RunMainBody (m=16_080b85a0) at
../src/runtime/common/RTLinker.m3:379
#21 0xb7271dff in AddUnitI (m=16_080b85a0) at
../src/runtime/common/RTLinker.m3:113
#22 0xb7271e8d in AddUnit (b={"Juno_M3", Declared at:
../src/Juno.m3:1974}) at ../src/runtime/common/RTLinker.m3:122
#23 0x0805120e in main (argc=1, argv=0xbf96ff14, envp=0xbf96ff1c) at
_m3main.mc:4
#24 0xb6ed5450 in __libc_start_main () from
/lib/tls/i686/cmov/libc.so.6
#25 0x08051161 in _start ()


When killing mentor under m3gdb it shows like the same back trace:
(m3gdb) where
#0  0xb70fb39a in SignalThread (act=16_0834ff08, state=Stopping) at
../src/thread/PTHREAD/ThreadPThread.m3:1058
#1  0xb70fb6dc in StopWorld () at
../src/thread/PTHREAD/ThreadPThread.m3:1142
#2  0xb70fa9e7 in SuspendOthers () at
../src/thread/PTHREAD/ThreadPThread.m3:905
#3  0xb70d4244 in CollectSomeInStateZero () at
../src/runtime/common/RTCollector.m3:755
#4  0xb70d4203 in CollectSome () at
../src/runtime/common/RTCollector.m3:729
#5  0xb70d3c24 in CollectEnough () at
../src/runtime/common/RTCollector.m3:656
#6  0xb70d76c1 in AllocTraced (def=16_b712d934, dataSize=24,
dataAlignment=4, initProc=Static link does not lead to a valid frame.
)
    at ../src/runtime/common/RTCollector.m3:1462
#7  0xb70c9f25 in GetTracedObj (def=16_b712d934) at
../src/runtime/common/RTAllocator.m3:206
#8  0xb70c99b0 in AllocateTracedObj (defn=16_b712d934) at
../src/runtime/common/RTAllocator.m3:131
#9  0xb710d586 in New (a={'a','z','u','r','e','4'}) at
../src/text/Text8Short.m3:16
#10 0xb710ce87 in New (a={'a','z','u','r','e','4'}) at
../src/text/Text8.m3:18
#11 0xb710ba9d in FromChars (a={'a','z','u','r','e','4'}) at
../src/text/Text.m3:206
#12 0xb7c7a62f in NormalizeName (a=16_b7ca378c) at
../src/color/ColorName.m3:83
#13 0xb7c7b789 in Init () at ../src/color/ColorName.m3:207
#14 0xb7c7b7ff in ColorName (mode=1) at ../src/color/ColorName.m3:214
#15 0xb70e2389 in RunMainBody (m=16_b7ca2fa0) at
../src/runtime/common/RTLinker.m3:399
#16 0xb70e2055 in RunMainBody (m=16_b7d38100) at
../src/runtime/common/RTLinker.m3:379
#17 0xb70e2055 in RunMainBody (m=16_b7d2fe20) at
../src/runtime/common/RTLinker.m3:379
#18 0xb70e2055 in RunMainBody (m=16_b7d34480) at
../src/runtime/common/RTLinker.m3:379
#19 0xb70e2055 in RunMainBody (m=16_b7d30d60) at
../src/runtime/common/RTLinker.m3:379
#20 0xb70e2055 in RunMainBody (m=16_b7d4d620) at
../src/runtime/common/RTLinker.m3:379
#21 0xb70e2055 in RunMainBody (m=16_b7e31d80) at
../src/runtime/common/RTLinker.m3:379
#22 0xb70e2055 in RunMainBody (m=16_b7e33220) at
../src/runtime/common/RTLinker.m3:379
#23 0xb70e2055 in RunMainBody (m=16_b7e36d40) at
../src/runtime/common/RTLinker.m3:379
#24 0xb70e2055 in RunMainBody (m=16_b7e364e0) at
../src/runtime/common/RTLinker.m3:379
#25 0xb70e2055 in RunMainBody (m=16_b7e36ba0) at
../src/runtime/common/RTLinker.m3:379
#26 0xb70e2055 in RunMainBody (m=16_b7e32cc0) at
../src/runtime/common/RTLinker.m3:379
#27 0xb70e2055 in RunMainBody (m=16_b7e32900) at
../src/runtime/common/RTLinker.m3:379
#28 0xb70e2055 in RunMainBody (m=16_08255600) at
../src/runtime/common/RTLinker.m3:379
#29 0xb70e2055 in RunMainBody (m=16_08256040) at
../src/runtime/common/RTLinker.m3:379
#30 0xb70e2055 in RunMainBody (m=16_08312aa0) at
../src/runtime/common/RTLinker.m3:379
#31 0xb70e0dff in AddUnitI (m=16_08312aa0) at
../src/runtime/common/RTLinker.m3:113
#32 0xb70e0e8d in AddUnit (b={"Main_M3", Declared at:
../src/Main.m3:164}) at ../src/runtime/common/RTLinker.m3:122
#33 0x0806df1e in main (argc=3, argv=0xbfa03774, envp=0xbfa03784) at
_m3main.mc:4
#34 0xb6d44450 in __libc_start_main () from
/lib/tls/i686/cmov/libc.so.6
#35 0x0806de71 in _start ()

Thanks in advance


Enviado desde Correo Yahoo! (
http://us.rd.yahoo.com/mailuk/taglines/isp/control/*http://us.rd.yahoo.com/evt=52431/*http://es.docs.yahoo.com/mail/overview/index.html
)
La bandeja de entrada m?s inteligente.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From dabenavidesd at yahoo.es  Mon May 19 18:52:09 2008
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 19 May 2008 16:52:09 +0000 (GMT)
Subject: [M3devel] garbage collection problem on LINUXLIBC6?
In-Reply-To: <48315F96.1E75.00D7.1@scires.com>
Message-ID: <735107.82429.qm@web27103.mail.ukl.yahoo.com>

An HTML attachment was scrubbed...
URL: 

From dabenavidesd at yahoo.es  Mon May 19 19:02:00 2008
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 19 May 2008 17:02:00 +0000 (GMT)
Subject: [M3devel] garbage collection problem on LINUXLIBC6?
In-Reply-To: <735107.82429.qm@web27103.mail.ukl.yahoo.com>
Message-ID: <163131.36279.qm@web27101.mail.ukl.yahoo.com>

An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sat May 24 07:11:50 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 24 May 2008 05:11:50 +0000
Subject: [M3devel] new platform names (for actual new platforms)
Message-ID: 

Do people object to new platform names like:
  PPC32_OPENBSD    SPARC32_OPENBSD    SPARC32_LINUX  
 
?
For that matter, anyone consider spelling out POWERPC32_OPENBSD?
?
Seriously I am far along on PPC32_OPENBSD and SPARC64_OPENBSDand once those work, I figure I'll try to flesh out Linux, NetBSD,FreeBSD on ppc32/sparc/sparc64. So this isn't just hypothetical
debate about platform names.
 
At some point it almost seems like there's a 2 dimensional matrixand the support should be processor and OS, somewhat independent..well, it is kind of like in parts already.
 
Should I really stick more like:  PPC_OPENBSD   SPARC_LINUX   SPARC64_LINUX    etc.?
64bits isn't so unusual now, that 32bits isn't so automatically implied???
That's kind of my point. Not putting in "32" or "64" used to imply "32" but
now seems almost ambiguous. ?
(Linux doesn't really still support 32 bit SPARC kernels, butdefinitely 32 bit userland; in fact it looks like SPARC Linuxis mostly 32 bit userland, and SPARC64 OpenBSD is purely 64 bit,not even gcc -m32)
I'd still kind of like to rename stuff like to  I386_NT, I386_LINUX, I386_CYGWIN, I386_MINGWIN, SPARC_SOLARIS_SUN,  SPARC_SOLARIS_GNU, alas...  
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sat May 24 11:49:57 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 24 May 2008 09:49:57 +0000
Subject: [M3devel] stat file types?
In-Reply-To: 
References: 
Message-ID: 

It SEEMS:
 
S_IFPIPE appears to be made up by Modula-3.S_IFPORT appears to be made up by Modula-3 as a synonym for S_IFIFO.
 
PROPOSED:
This code:
D:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX\FilePosix.i3(36):   error if "fd" is not "S_IFPIPE", "S_IFPORT", or "S_IFSOCK". *)D:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX\FilePosix.m3(47):    | Ustat.S_IFPIPE, Ustat.S_IFPORT, Ustat.S_IFSOCK =>
 
should check for S_IFSOCK and S_IFIFO.
all references to and definitions of S_IFPORT and S_IFPIPE should go away.
 
Or did some actual systems actually define either of these?
 
Most of the *.i3 files set S_IFPORT = S_IFIFO and S_IFPIPE = 0.
Many of them say that there is no S_IFPIPE in their .h file.
Irix has them reversed but the same result: S_IFPORT = 0 and S_IFPIPE = S_IFIFO.
 
Any objections?
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sat May 24 11:50:50 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 24 May 2008 09:50:50 +0000
Subject: [M3devel] stat file types?
In-Reply-To: 
References: 
Message-ID: 

It SEEMS:
 
S_IFPIPE appears to be made up by Modula-3.S_IFPORT appears to be made up by Modula-3 as a synonym for S_IFIFO.
 
PROPOSED:
This code:
D:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX\FilePosix.i3(36):   error if "fd" is not "S_IFPIPE", "S_IFPORT", or "S_IFSOCK". *)D:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX\FilePosix.m3(47):    | Ustat.S_IFPIPE, Ustat.S_IFPORT, Ustat.S_IFSOCK =>
 
should check for S_IFSOCK and S_IFIFO.
all references to and definitions of S_IFPORT and S_IFPIPE should go away.
 
Or did some actual systems actually define either of these?
 
Most of the *.i3 files set S_IFPORT = S_IFIFO and S_IFPIPE = 0.
Many of them say that there is no S_IFPIPE in their .h file.
Irix has them reversed but the same result: S_IFPORT = 0 and S_IFPIPE = S_IFIFO.
 
Any objections?
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From dabenavidesd at yahoo.es  Sat May 24 19:29:27 2008
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sat, 24 May 2008 17:29:27 +0000 (GMT)
Subject: [M3devel] garbage collection problem on LINUXLIBC6?
In-Reply-To: <163131.36279.qm@web27101.mail.ukl.yahoo.com>
Message-ID: <406663.93255.qm@web27103.mail.ukl.yahoo.com>

Hi:
I recently have compiled the cm3 system with good results on a 2-core machine on LINUXLIBC6, kubuntu of 32 bits. It runs gui applications of cm3 with no problems at all.
I think maybe the issue is related with something about the operating system, or at least the machine, I didn't check this until now.

Thanks

--- 19/5/08, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> wrote:
De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] garbage collection problem on LINUXLIBC6?
Para: m3devel at elegosoft.com, "Randy Coleburn" <rcoleburn at scires.com>
Fecha: lunes, 19 mayo, 2008 12:02

Hi again:
and the process is using the cpu very much (using top command)

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 9758 daniel    20   0 33644 3836 2684 R 60.0  0.7   1:05.17 draw

Thanks in advance.


--- 19/5/08, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> wrote:
De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] garbage collection problem on LINUXLIBC6?
Para: m3devel at elegosoft.com, "Randy Coleburn" <rcoleburn at scires.com>
Fecha: lunes, 19 mayo, 2008 11:52

Hi Randy:
In my case, the program just doesn't start, maybe after some minutes yes, but obviously this is abnormal.
When I start mentor @M3tracelinker, I got after a lot of output the following lines and it just doesn't start after it:
  ../src/color/Color.i3(3)
  ../src/runtime/common/RTHooks.i3(3)
RunMainBody: exec: ../src/color/ColorNameTable.i3(3)
RunMainBody: exec: ../src/color/ColorNameF.i3(3)
RunMainBody: exec: ../src/color/ColorNa

But if I put @M3nogc @M3tracelinker the program starts and the output is:
RunMainBody: ../LINUXLIBC6/MentorBundle.m3(2)
  ../LINUXLIBC6/MentorBundle.i3(5)
  ../src/rw/TextWr.i3(3)
  ../src/rw/Wr.i3(3)
 
 ../src/thread/Common/Thread.i3(3)
  ../src/text/Text.i3(3)
  ../src/bundleintf/BundleRep.i3(3)
  ../src/bundleintf/Bundle.i3(3)
 
 ../src/runtime/common/RTHooks.i3(3)
RunMainBody: exec: ../LINUXLIBC6/MentorBundle.m3(3)
RunMainBody: exec: ../LINUXLIBC6/MentorBundle.i3(3)
RunMainBody: exec: ../src/Main.m3(3)

However when examining a simple gui program, the stdout shows the same  out for @M3tracelinker with or without garbage collection

  ../src/split/TextVBT.i3(5)
  ../src/runtime/common/RTHooks.i3(3)
RunMainBody: exec: ../src/split/TextVBTClass.i3(3)
RunMainBody: exec: ../src/split/TextVBT.m3(3)
RunMainBody: exec: ../src/split/TextVBT.i3(3)
RunMainBody: exec: ../src/Draw.m3(3)

If I run the program under m3gdb without parametres, breaking on RTLinker.RunMainBody, I got:
Breakpoint 3, RunMainBody (m=16_b7e108c0)
    at ../src/runtime/common/RTLinker.m3:349
349       VAR desc, desc2: InitPtr;  imp: RT0.ImportPtr;  m2:
 RT0.ModulePtr;
(m3gdb)
Continuando.

Breakpoint 3, RunMainBody (m=16_b7e10ba0)
    at ../src/runtime/common/RTLinker.m3:349
349       VAR desc, desc2: InitPtr;  imp: RT0.ImportPtr;  m2: RT0.ModulePtr;
(m3gdb)
Continuando.

Breakpoint 3, RunMainBody (m=16_b7e0b660)
    at ../src/runtime/common/RTLinker.m3:349
349       VAR desc, desc2: InitPtr;  imp: RT0.ImportPtr;  m2: RT0.ModulePtr;
(m3gdb)
Continuando.


[Nuevo Thread -1234015344 (LWP 9706)]
[Thread -1234015344 (LWP 9706) exited]

And the program hangs there.
And again the same situation on the stack trace when killing the process inside m3gdb (also got a segment violation on m3gdb):

(m3gdb) where
#0  0xb7fbf410 in __kernel_vsyscall ()
#1  0xb7108ae7 in pthread_kill () from
 /lib/tls/i686/cmov/libpthread.so.0
#2  0xb737c397 in SignalThread (act=16_08055d88, state=Stopping)
    at ../src/thread/PTHREAD/ThreadPThread.m3:1058
#3  0xb737c6dc in StopWorld () at ../src/thread/PTHREAD/ThreadPThread.m3:1142
#4  0xb737b9e7 in SuspendOthers ()
    at ../src/thread/PTHREAD/ThreadPThread.m3:905
#5  0xb7355244 in CollectSomeInStateZero ()
    at ../src/runtime/common/RTCollector.m3:755
#6  0xb7355203 in CollectSome () at ../src/runtime/common/RTCollector.m3:729
#7  0xb7354c24 in CollectEnough () at ../src/runtime/common/RTCollector.m3:656
#8  0xb73586c1 in AllocTraced (def=16_b7dfbfb4, dataSize=456, dataAlignment=4,
    initProc=Static link does not lead to a valid frame.
) at ../src/runtime/common/RTCollector.m3:1462
#9  0xb734af25 in GetTracedObj (def=16_b7dfbfb4)
    at
 ../src/runtime/common/RTAllocator.m3:206
#10 0xb734a9b0 in AllocateTracedObj (defn=16_b7dfbfb4)
    at ../src/runtime/common/RTAllocator.m3:131
#11 0xb7d63df5 in Connect (inst=NIL, trsl=NIL) at ../src/xvbt/XClientF.m3:495
#12 0xb7d66717 in DoConnect (self=16_b6f41d5c, inst=NIL, localOnly=FALSE,
    t=NIL) at ../src/xvbt/XClientF.m3:637
#13 0xb7d46c23 in DoConnect (self=16_b6f41d5c, inst=NIL, localOnly=FALSE,
    t=NIL) at ../src/xvbt/XClient.m3:1495
#14 0xb7d9962c in Connect (inst=NIL, localOnly=FALSE)
---Type <return> to continue, or q <return> to quit---
    at ../src/vbt/TrestleClass.m3:30
#15 0xb7df2117 in Default () at ../src/trestle/Trestle.m3:838
#16 0xb7ded789 in PreAttach (v=16_b6f41cf8, trsl=NIL)
    at ../src/trestle/Trestle.m3:264
#17 0xb7deb95b in Install (v=16_b6f41cf8, applName=NIL, inst=NIL,
Fallo de
 segmentaci?n


Maybe could be some gcc backend issue?
I would like to know if others have the same problem.
Thanks.
  
--- 19/5/08, Randy Coleburn <rcoleburn at scires.com> wrote:
De: Randy Coleburn <rcoleburn at scires.com>
Asunto: Re: [M3devel] garbage collection problem on LINUXLIBC6?
Para: m3devel at elegosoft.com
Fecha: lunes, 19 mayo, 2008 10:08


 
Daniel, I have this same problem on GUI applications created on cm3 v4.1.  If I don't put "@M3novm" on the command line, the programs crash during startup.  It has something to do with the garbage collector.  In my testing of cm3 d5.7.0 on Windows XP, I have not run into the problem yet, so I think Tony has fixed it with his new garbage collector, at least on Windows.
Regards,
Randy

>>> "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> 5/18/2008 6:39 PM >>>




Dear developers:
I'm running a new installed cm3 on an ubuntu 8.04 32 bits, and I can't run anything with gui if I don't use @M3nogc
The rest of the applications, the compiler, and m3browser seem to work without problems ??
I'm debugging mentor but I just got this until now:
Breakpoint 5, Init () at ../src/color/ColorName.m3:207
207           IF table.put (NormalizeName (Basic [i].name), i) THEN
(m3gdb) where
#0  Init () at ../src/color/ColorName.m3:207
#1  0xb7c7b7ff in ColorName (mode=1) at ../src/color/ColorName.m3:214
#2  0xb70e2389 in RunMainBody (m=16_b7ca2fa0) at ../src/runtime/common/RTLinker.m3:399
#3  0xb70e2055 in RunMainBody (m=16_b7d38100) at ../src/runtime/common/RTLinker.m3:379
#4  0xb70e2055 in RunMainBody (m=16_b7d2fe20) at ../src/runtime/common/RTLinker.m3:379
#5  0xb70e2055 in RunMainBody (m=16_b7d34480) at
 ../src/runtime/common/RTLinker.m3:379
#6  0xb70e2055 in RunMainBody (m=16_b7d30d60) at ../src/runtime/common/RTLinker.m3:379
#7  0xb70e2055 in RunMainBody (m=16_b7d4d620) at ../src/runtime/common/RTLinker.m3:379
#8  0xb70e2055 in RunMainBody (m=16_b7e31d80) at ../src/runtime/common/RTLinker.m3:379
#9  0xb70e2055 in RunMainBody (m=16_b7e33220) at ../src/runtime/common/RTLinker.m3:379
#10 0xb70e2055 in RunMainBody (m=16_b7e36d40) at ../src/runtime/common/RTLinker.m3:379
#11 0xb70e2055 in RunMainBody (m=16_b7e364e0) at ../src/runtime/common/RTLinker.m3:379
#12 0xb70e2055 in RunMainBody (m=16_b7e36ba0) at ../src/runtime/common/RTLinker.m3:379
#13 0xb70e2055 in RunMainBody (m=16_b7e32cc0) at ../src/runtime/common/RTLinker.m3:379
#14 0xb70e2055 in RunMainBody (m=16_b7e32900) at ../src/runtime/common/RTLinker.m3:379
#15 0xb70e2055 in RunMainBody (m=16_08255600) at ../src/runtime/common/RTLinker.m3:379
#16
 0xb70e2055 in RunMainBody (m=16_08256040) at ../src/runtime/common/RTLinker.m3:379
#17 0xb70e2055 in RunMainBody (m=16_08312aa0) at ../src/runtime/common/RTLinker.m3:379
#18 0xb70e0dff in AddUnitI (m=16_08312aa0) at ../src/runtime/common/RTLinker.m3:113
#19 0xb70e0e8d in AddUnit (b={"Main_M3", Declared at: ../src/Main.m3:164}) at ../src/runtime/common/RTLinker.m3:122
#20 0x0806df1e in main (argc=3, argv=0xbfa03774, envp=0xbfa03784) at _m3main.mc:4
#21 0xb6d44450 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#22 0x0806de71 in _start ()
(m3gdb) cont
Continuando.

Breakpoint 5, Init () at ../src/color/ColorName.m3:207
207           IF table.put (NormalizeName (Basic [i].name), i) THEN
(m3gdb) cont
and the process hangs there when debugging mentor.

I have checked  Juno under m3gdb after have killed it and got:

(m3gdb) where
#0 
 0xb7fb0410 in __kernel_vsyscall ()
#1  0xb7018ae7 in pthread_kill () from /lib/tls/i686/cmov/libpthread.so.0
#2  0xb728c397 in SignalThread (act=16_0813c120, state=Stopping) at ../src/thread/PTHREAD/ThreadPThread.m3:1058
#3  0xb728c55e in StopWorld () at ../src/thread/PTHREAD/ThreadPThread.m3:1116
#4  0xb728b9e7 in SuspendOthers () at ../src/thread/PTHREAD/ThreadPThread.m3:905
#5  0xb7265244 in CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:755
#6  0xb7265203 in CollectSome () at ../src/runtime/common/RTCollector.m3:729
#7  0xb7264c24 in CollectEnough () at ../src/runtime/common/RTCollector.m3:656
#8  0xb72686c1 in AllocTraced (def=16_b7be1400, dataSize=12, dataAlignment=4, initProc=NIL)
    at ../src/runtime/common/RTCollector.m3:1462
#9  0xb725ad8f in GetTracedRef (def=16_b7be1400) at ../src/runtime/common/RTAllocator.m3:191
#10 0xb725a987
 in AllocateTracedRef (defn=16_b7be1400) at ../src/runtime/common/RTAllocator.m3:126
#11 0xb7b5d8fb in Put (tbl=16_b6e50438, key=8047, val=244) at ../LINUXLIBC6/IntIntTbl.m3 => ../src/table/Table.mg:127
#12 0xb7dd4e2c in Set (a='>', b='o', c=244, bothCases=FALSE, reversed=TRUE) at ../src/etext/KeyFilter.m3:288
#13 0xb7dd521c in Set (a='o', b='>', c=244, bothCases=FALSE, reversed=FALSE) at ../src/etext/KeyFilter.m3:304
#14 0xb7dd5882 in KeyFilter (mode=1) at ../src/etext/KeyFilter.m3:437
#15 0xb7273389 in RunMainBody (m=16_b7e51da0) at ../src/runtime/common/RTLinker.m3:399
#16 0xb7273055 in RunMainBody (m=16_b7e547e0) at ../src/runtime/common/RTLinker.m3:379
#17 0xb7273055 in RunMainBody (m=16_b7e56c00) at ../src/runtime/common/RTLinker.m3:379
#18 0xb7273055 in RunMainBody (m=16_b7e54240) at ../src/runtime/common/RTLinker.m3:379
#19 0xb7273055 in RunMainBody (m=16_b7e537e0) at
 ../src/runtime/common/RTLinker.m3:379
#20 0xb7273055 in RunMainBody (m=16_080b85a0) at ../src/runtime/common/RTLinker.m3:379
#21 0xb7271dff in AddUnitI (m=16_080b85a0) at ../src/runtime/common/RTLinker.m3:113
#22 0xb7271e8d in AddUnit (b={"Juno_M3", Declared at: ../src/Juno.m3:1974}) at ../src/runtime/common/RTLinker.m3:122
#23 0x0805120e in main (argc=1, argv=0xbf96ff14, envp=0xbf96ff1c) at _m3main.mc:4
#24 0xb6ed5450 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#25 0x08051161 in _start ()


When killing mentor under m3gdb it shows like the same back trace:
(m3gdb) where
#0  0xb70fb39a in SignalThread (act=16_0834ff08, state=Stopping) at ../src/thread/PTHREAD/ThreadPThread.m3:1058
#1  0xb70fb6dc in StopWorld () at ../src/thread/PTHREAD/ThreadPThread.m3:1142
#2  0xb70fa9e7 in SuspendOthers () at ../src/thread/PTHREAD/ThreadPThread.m3:905
#3  0xb70d4244 in CollectSomeInStateZero
 () at ../src/runtime/common/RTCollector.m3:755
#4  0xb70d4203 in CollectSome () at ../src/runtime/common/RTCollector.m3:729
#5  0xb70d3c24 in CollectEnough () at ../src/runtime/common/RTCollector.m3:656
#6  0xb70d76c1 in AllocTraced (def=16_b712d934, dataSize=24, dataAlignment=4, initProc=Static link does not lead to a valid frame.
)
    at ../src/runtime/common/RTCollector.m3:1462
#7  0xb70c9f25 in GetTracedObj (def=16_b712d934) at ../src/runtime/common/RTAllocator.m3:206
#8  0xb70c99b0 in AllocateTracedObj (defn=16_b712d934) at ../src/runtime/common/RTAllocator.m3:131
#9  0xb710d586 in New (a={'a','z','u','r','e','4'}) at ../src/text/Text8Short.m3:16
#10 0xb710ce87 in New (a={'a','z','u','r','e','4'}) at ../src/text/Text8.m3:18
#11 0xb710ba9d in FromChars (a={'a','z','u','r','e','4'}) at ../src/text/Text.m3:206
#12 0xb7c7a62f in NormalizeName (a=16_b7ca378c) at
 ../src/color/ColorName.m3:83
#13 0xb7c7b789 in Init () at ../src/color/ColorName.m3:207
#14 0xb7c7b7ff in ColorName (mode=1) at ../src/color/ColorName.m3:214
#15 0xb70e2389 in RunMainBody (m=16_b7ca2fa0) at ../src/runtime/common/RTLinker.m3:399
#16 0xb70e2055 in RunMainBody (m=16_b7d38100) at ../src/runtime/common/RTLinker.m3:379
#17 0xb70e2055 in RunMainBody (m=16_b7d2fe20) at ../src/runtime/common/RTLinker.m3:379
#18 0xb70e2055 in RunMainBody (m=16_b7d34480) at ../src/runtime/common/RTLinker.m3:379
#19 0xb70e2055 in RunMainBody (m=16_b7d30d60) at ../src/runtime/common/RTLinker.m3:379
#20 0xb70e2055 in RunMainBody (m=16_b7d4d620) at ../src/runtime/common/RTLinker.m3:379
#21 0xb70e2055 in RunMainBody (m=16_b7e31d80) at ../src/runtime/common/RTLinker.m3:379
#22 0xb70e2055 in RunMainBody (m=16_b7e33220) at ../src/runtime/common/RTLinker.m3:379
#23 0xb70e2055 in RunMainBody (m=16_b7e36d40) at
 ../src/runtime/common/RTLinker.m3:379
#24 0xb70e2055 in RunMainBody (m=16_b7e364e0) at ../src/runtime/common/RTLinker.m3:379
#25 0xb70e2055 in RunMainBody (m=16_b7e36ba0) at ../src/runtime/common/RTLinker.m3:379
#26 0xb70e2055 in RunMainBody (m=16_b7e32cc0) at ../src/runtime/common/RTLinker.m3:379
#27 0xb70e2055 in RunMainBody (m=16_b7e32900) at ../src/runtime/common/RTLinker.m3:379
#28 0xb70e2055 in RunMainBody (m=16_08255600) at ../src/runtime/common/RTLinker.m3:379
#29 0xb70e2055 in RunMainBody (m=16_08256040) at ../src/runtime/common/RTLinker.m3:379
#30 0xb70e2055 in RunMainBody (m=16_08312aa0) at ../src/runtime/common/RTLinker.m3:379
#31 0xb70e0dff in AddUnitI (m=16_08312aa0) at ../src/runtime/common/RTLinker.m3:113
#32 0xb70e0e8d in AddUnit (b={"Main_M3", Declared at: ../src/Main.m3:164}) at ../src/runtime/common/RTLinker.m3:122
#33 0x0806df1e in main (argc=3, argv=0xbfa03774, envp=0xbfa03784) at _m3main.mc:4
#34
 0xb6d44450 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#35 0x0806de71 in _start ()

Thanks in advance




Enviado desde Correo Yahoo!
La bandeja de entrada m?s inteligente.








      
Enviado desde Correo Yahoo!
La bandeja de entrada m?s inteligente.









      
Enviado desde Correo Yahoo!
La bandeja de entrada m?s inteligente.




      ______________________________________________ 
Enviado desde Correo Yahoo! La bandeja de entrada m?s inteligente.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Sun May 25 00:48:25 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Sat, 24 May 2008 18:48:25 -0400
Subject: [M3devel] new problems
Message-ID: <483862F4.1E75.00D7.1@scires.com>

I'm having some new problems crop up with the cm3ide program.
 
Have there been any recent changes to quake or the QMachine that have not been thoroughly checked out?  That is where I suspect the problems are coming from.
 
Regards,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sun May 25 01:33:14 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 24 May 2008 23:33:14 +0000
Subject: [M3devel] new problems
In-Reply-To: <483862F4.1E75.00D7.1@scires.com>
References: <483862F4.1E75.00D7.1@scires.com>
Message-ID: 

Randy, can you describe the problems more?
 
"Something is wrong."?
 
Can the problems be made debuggable by others?
 
When did the problems start?
 
 - Jay


Date: Sat, 24 May 2008 18:48:25 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: [M3devel] new problems

I'm having some new problems crop up with the cm3ide program.
 
Have there been any recent changes to quake or the QMachine that have not been thoroughly checked out?  That is where I suspect the problems are coming from.
 
Regards,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sun May 25 02:16:01 2008
From: jayk123 at hotmail.com (Jay)
Date: Sun, 25 May 2008 00:16:01 +0000
Subject: [M3devel] function pointers and comparison to nil? mis-typed
 function pointers?
In-Reply-To: <483862F4.1E75.00D7.1@scires.com>
References: <483862F4.1E75.00D7.1@scires.com>
Message-ID: 

I'm being lazy...
Tony can you explain this stuff?
Comparison of function pointers..What are the various representations and rules?
What does it mean to compare nested functions?
What does it mean to compare a function to NIL?
I'll poke around more.
What I am seeing is that comparison of function pointers to NIL is surprisinglyexpensive, and probably somewhat buggy. Or at least some of the runtimegenerated "metadata-ish" stuff is produced or typed incorrectly.
In particular, RTLinker.m3:
PROCEDURE AddUnit (b: RT0.Binder) =  VAR m: RT0.ModulePtr;  BEGIN    IF (b = NIL) THEN RETURN END;   line 119    m := b(0);                      line 120    IF (m = NIL) THEN RETURN END;   line 121    AddUnitI(m);                    line 122   END AddUnit;
generates a lot of code, just for the first line:
  (556) set_source_line      source line  119    (557) load      m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb    (558) load_nil    (559) if_eq    (560) load      m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb    (561) load_indirect      load address offset 0x0 src_t 0x5 dst_t 0x5    (562) load_integer      integer n_bytes 0x0 hi 0x0 low 0x1 sign -1    (563) if_eq    (564) set_label    (565) load_nil    (566) load      m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb    (567) if_ne    (568) set_label    (569) exit_proc    (570) set_label    (571) set_source_line      source line  120  
The details on the load_integer trace might not be completely correct. I will test a fix shortly.Esp. that n_bytes gets decremented to zero before the trace.
Ok, I see now why some of the bloat -- because the "then return end" is on the same line.If it were written as:  if (b = NIL THEN      return   end   
It probably wouldn't look so bad. That took me a while to realize.
The following is generated for SPARC64_OPENBSD:
 
 line 119 
 .stabn 68,0,119,.LLM61-.LLFBB4 .LLM61: ldx [%fp+2175], %g1 brz %g1, .LL26  nop ldx [%fp+2175], %g1 ldx [%g1], %g1            bus error here? yes, probably this one cmp %g1, -1 be %xcc, .LL27  nop.LL26: ldx [%fp+2175], %g1 brz %g1, .LL33  nop.LL27:
 line 120 
 .stabn 68,0,120,.LLM62-.LLFBB4.LLM62:
 ldx [%fp+2175], %g1 stx %g1, [%fp+2007] ldx [%fp+2007], %g1 brz %g1, .LL30  nop ldx [%fp+2007], %g1 ldx [%g1], %g1            or here ? cmp %g1, -1 bne %xcc, .LL30  nop ldx [%fp+2007], %g1 add %g1, 16, %g1 ldx [%g1], %g1           or here?  stx %g1, [%fp+2015] ldx [%fp+2007], %g1 add %g1, 8, %g1 ldx [%g1], %g1 stx %g1, [%fp+2007].LL30: ldx [%fp+2007], %g1 ldx [%fp+2015], %g5 mov 0, %o0 call %g1, 0  nop mov %o0, %g1 stx %g1, [%fp+2023] ldx [%fp+2023], %g1 stx %g1, [%fp+1999]   line 121 
 .stabn 68,0,121,.LLM63-.LLFBB4.LLM63: ldx [%fp+1999], %g1 brz %g1, .LL33  nop.LL32: .stabn 68,0,122,.LLM64-.LLFBB4.LLM64:
g1 points to RTSignal_I3
(gdb) x/i $pc0x3ff0a8 :        ldx  [ %g1 ], %g1
(gdb) x/i $g10x4021f4 : save  %sp, -208, %sp
I am willing to accept that a "function pointer" is a pair of pointers, or even three pointers.A pointer to code, a pointer to globals for position independent code, a frame pointer to locals.That equality comparison of function pointers requires comparing two (or three) pointers.
  (Though the global pointer shouldn't need comparing.)At least for nested functions. Less so for non-nested. ?Much less for comparison to NIL. ?
And either way, this code is reading bogus data.There isn't a pointer at the function address, there is code.
Something doesn't add up.
I'm going to try setting "aligned procedures" but that's quite bogus I think.
EqualExpr.m3 says
       Note: procedures pointers are always aligned!
but maybe not?
Yeah yeah I'm being lazy. I'll read more code..
I also wonder if a "function pointer" can be optimized for the case of not being to a nested function.It looks like calling a function pointer is very inefficient.It looks like..am I reading that correctly?.. that if the pointer points to -1, then it is nested anda pair of pointers, and not otherwise. That -1 is treated specially as the first bytes of a function?
Is that a Modula-3-ism or a SPARC-ism?It looks like a Modula-3-ism. And it seems dubious.But I'll have to read more..
 
NT386GNU does the same sort of wrong looking thing:
 
LFBB4: pushl %ebp movl %esp, %ebp subl $24, %espLBB5: .stabn 68,0,117,LM60-LFBB4LM60: movl $0, -16(%ebp) .stabn 68,0,119,LM61-LFBB4LM61: movl 8(%ebp), %eax testl %eax, %eax je L26 movl 8(%ebp), %eax movl (%eax), %eax                  BAD  cmpl $-1, %eax                       BAD  je L27L26: movl 8(%ebp), %eax testl %eax, %eax je L33L27: .stabn 68,0,120,LM62-LFBB4LM62:
 
and NT386:
 
0:000> ucm3!RTLinker__AddUnit:00607864 55              push    ebp00607865 8bec            mov     ebp,esp00607867 81ec0c000000    sub     esp,0Ch0060786d 53              push    ebx0060786e 56              push    esi0060786f 57              push    edi00607870 c745fc00000000  mov     dword ptr [ebp-4],000607877 837d0800        cmp     dword ptr [ebp+8],00:000> ucm3!RTLinker__AddUnit+0x17:0060787b 0f840f000000    je      cm3!RTLinker__AddUnit+0x2c (00607890)00607881 8b7508          mov     esi,dword ptr [ebp+8]00607884 8b5e00          mov     ebx,dword ptr [esi]                            BAD  00607887 83fbff          cmp     ebx,0FFFFFFFFh                                  BAD 0060788a 0f840f000000    je      cm3!RTLinker__AddUnit+0x3b (0060789f)00607890 837d0800        cmp     dword ptr [ebp+8],000607894 0f8505000000    jne     cm3!RTLinker__AddUnit+0x3b (0060789f)0060789a e969000000      jmp     cm3!RTLinker__AddUnit+0xa4 (00607908)
 
cm3!RTLinker__AddUnit+0x20:00607884 8b5e00          mov     ebx,dword ptr [esi]  ds:002b:0062c950=81ec8b550:000> u @esicm3!RTLinker_I3:0062c950 55              push    ebp0062c951 8bec            mov     ebp,esp0062c953 81ec00000000    sub     esp,00062c959 53              push    ebx0062c95a 56              push    esi0062c95b 57              push    edi0062c95c 837d0800        cmp     dword ptr [ebp+8],00062c960 0f8400000000    je      cm3!RTLinker_I3+0x16 (0062c966)
 
This is just wrong.
Comparing bytes of code to -1.
 
I think the likely fix is for the "I3" code to be laid out as a "constant function pointer", a pointer to a pair of pointers where one points to the code and one is to -1. Something like that. That can't be quite correct given that the existing data is callable.
  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sun May 25 02:48:32 2008
From: jayk123 at hotmail.com (Jay)
Date: Sun, 25 May 2008 00:48:32 +0000
Subject: [M3devel] function pointers and comparison to nil? mis-typed
 function pointers?
In-Reply-To: 
References: <483862F4.1E75.00D7.1@scires.com>
	
Message-ID: 

I see somewhat.
It's stuff around "closure".
The comparison of code bytes to -1 comes from If_closure for example.
 
The problem is presumably to come up with a unified representation of pointers to functions that may or may not be nested, while avoiding runtime codegen, even just a little bit, and for Modula-3 and C function pointers to use the same representation.
I don't think the present solution is really valid, and I am skeptical that there is a solution.
One of the requirements has to be dropped.
Sniffing code bytes and trying to decide if they are code or not as appears to currently happen is bogus.
 
I think the solution is to remove the requirement that a Modula-3 function pointer and a C function pointer are the same.
Except, well, that probably doesn't work -- it means you need two types of function pointers.
 
Darn this is a hard problem.
 
The runtime codegen required can be exceedingly simple, fast, and small IF it were allowed to be on the stack. But that's a killer these days.
 
I think you have to give up unification of "closures" and "function pointers".
If you take the address of a nested function and call it, you cannot access the locals of the enclosing scopes.
So in affect, you end up with "two types of function pointers".
Regular stateless ones and "closures" with some captured state.
 
Thoughts?
 
I'm kind of stumped. It's a desirable problem to solve, and there is a purported solution in place, but the solution that is there is completely bogus, despite appearing to work for a long time, and there is no solution. That is my understanding. I could be wrong on any number of points but I'm pretty sure.
 
I think you have to separate out function pointers and closures.
Sniffing what it pointed to is dubous esp. as currently implemented.
If this is really the way to go, then signature bytes need to be worked out for all architectures that are guaranteed to not look like code.
Or vice versa -- signature bytes worked out that all functions start with, which is viable for Modula-3 but not for interop with C.
Currently -1 is used, of pointer-size.
That appears to be reasonable for x86:
 
0:000> eb . ff ff ff ff0:000> u .ntdll32!DbgBreakPoint:7d61002d ff              ???7d61002e ff              ???7d61002f ff              ???7d610030 ffc3            inc     ebx
 
but the instruction encodings or disassembly on other architectures would have to be checked.
 
 - Jay


From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Sun, 25 May 2008 00:16:01 +0000Subject: [M3devel] function pointers and comparison to nil? mis-typed function pointers?


I'm being lazy...Tony can you explain this stuff?Comparison of function pointers..What are the various representations and rules?What does it mean to compare nested functions?What does it mean to compare a function to NIL?I'll poke around more.What I am seeing is that comparison of function pointers to NIL is surprisinglyexpensive, and probably somewhat buggy. Or at least some of the runtimegenerated "metadata-ish" stuff is produced or typed incorrectly.In particular, RTLinker.m3:PROCEDURE AddUnit (b: RT0.Binder) =  VAR m: RT0.ModulePtr;  BEGIN    IF (b = NIL) THEN RETURN END;   line 119    m := b(0);                      line 120    IF (m = NIL) THEN RETURN END;   line 121    AddUnitI(m);                    line 122   END AddUnit;generates a lot of code, just for the first line:  (556) set_source_line      source line  119    (557) load      m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb    (558) load_nil    (559) if_eq    (560) load      m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb    (561) load_indirect      load address offset 0x0 src_t 0x5 dst_t 0x5    (562) load_integer      integer n_bytes 0x0 hi 0x0 low 0x1 sign -1    (563) if_eq    (564) set_label    (565) load_nil    (566) load      m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb    (567) if_ne    (568) set_label    (569) exit_proc    (570) set_label    (571) set_source_line      source line  120  The details on the load_integer trace might not be completely correct. I will test a fix shortly.Esp. that n_bytes gets decremented to zero before the trace.Ok, I see now why some of the bloat -- because the "then return end" is on the same line.If it were written as:  if (b = NIL THEN      return   end   It probably wouldn't look so bad. That took me a while to realize.The following is generated for SPARC64_OPENBSD:  line 119  .stabn 68,0,119,.LLM61-.LLFBB4 .LLM61: ldx [%fp+2175], %g1 brz %g1, .LL26  nop ldx [%fp+2175], %g1 ldx [%g1], %g1            bus error here? yes, probably this one cmp %g1, -1 be %xcc, .LL27  nop.LL26: ldx [%fp+2175], %g1 brz %g1, .LL33  nop.LL27: line 120  .stabn 68,0,120,.LLM62-.LLFBB4.LLM62: ldx [%fp+2175], %g1 stx %g1, [%fp+2007] ldx [%fp+2007], %g1 brz %g1, .LL30  nop ldx [%fp+2007], %g1 ldx [%g1], %g1            or here ? cmp %g1, -1 bne %xcc, .LL30  nop ldx [%fp+2007], %g1 add %g1, 16, %g1 ldx [%g1], %g1           or here?  stx %g1, [%fp+2015] ldx [%fp+2007], %g1 add %g1, 8, %g1 ldx [%g1], %g1 stx %g1, [%fp+2007].LL30: ldx [%fp+2007], %g1 ldx [%fp+2015], %g5 mov 0, %o0 call %g1, 0  nop mov %o0, %g1 stx %g1, [%fp+2023] ldx [%fp+2023], %g1 stx %g1, [%fp+1999]   line 121  .stabn 68,0,121,.LLM63-.LLFBB4.LLM63: ldx [%fp+1999], %g1 brz %g1, .LL33  nop.LL32: .stabn 68,0,122,.LLM64-.LLFBB4.LLM64:g1 points to RTSignal_I3(gdb) x/i $pc0x3ff0a8 :        ldx  [ %g1 ], %g1(gdb) x/i $g10x4021f4 : save  %sp, -208, %spI am willing to accept that a "function pointer" is a pair of pointers, or even three pointers.A pointer to code, a pointer to globals for position independent code, a frame pointer to locals.That equality comparison of function pointers requires comparing two (or three) pointers.  (Though the global pointer shouldn't need comparing.)At least for nested functions. Less so for non-nested. ?Much less for comparison to NIL. ?And either way, this code is reading bogus data.There isn't a pointer at the function address, there is code.Something doesn't add up.I'm going to try setting "aligned procedures" but that's quite bogus I think.EqualExpr.m3 says       Note: procedures pointers are always aligned!but maybe not?Yeah yeah I'm being lazy. I'll read more code..I also wonder if a "function pointer" can be optimized for the case of not being to a nested function.It looks like calling a function pointer is very inefficient.It looks like..am I reading that correctly?.. that if the pointer points to -1, then it is nested anda pair of pointers, and not otherwise. That -1 is treated specially as the first bytes of a function?Is that a Modula-3-ism or a SPARC-ism?It looks like a Modula-3-ism. And it seems dubious.But I'll have to read more.. NT386GNU does the same sort of wrong looking thing: LFBB4: pushl %ebp movl %esp, %ebp subl $24, %espLBB5: .stabn 68,0,117,LM60-LFBB4LM60: movl $0, -16(%ebp) .stabn 68,0,119,LM61-LFBB4LM61: movl 8(%ebp), %eax testl %eax, %eax je L26 movl 8(%ebp), %eax movl (%eax), %eax                  BAD  cmpl $-1, %eax                       BAD  je L27L26: movl 8(%ebp), %eax testl %eax, %eax je L33L27: .stabn 68,0,120,LM62-LFBB4LM62: and NT386: 0:000> ucm3!RTLinker__AddUnit:00607864 55              push    ebp00607865 8bec            mov     ebp,esp00607867 81ec0c000000    sub     esp,0Ch0060786d 53              push    ebx0060786e 56              push    esi0060786f 57              push    edi00607870 c745fc00000000  mov     dword ptr [ebp-4],000607877 837d0800        cmp     dword ptr [ebp+8],00:000> ucm3!RTLinker__AddUnit+0x17:0060787b 0f840f000000    je      cm3!RTLinker__AddUnit+0x2c (00607890)00607881 8b7508          mov     esi,dword ptr [ebp+8]00607884 8b5e00          mov     ebx,dword ptr [esi]                            BAD  00607887 83fbff          cmp     ebx,0FFFFFFFFh                                  BAD 0060788a 0f840f000000    je      cm3!RTLinker__AddUnit+0x3b (0060789f)00607890 837d0800        cmp     dword ptr [ebp+8],000607894 0f8505000000    jne     cm3!RTLinker__AddUnit+0x3b (0060789f)0060789a e969000000      jmp     cm3!RTLinker__AddUnit+0xa4 (00607908) cm3!RTLinker__AddUnit+0x20:00607884 8b5e00          mov     ebx,dword ptr [esi]  ds:002b:0062c950=81ec8b550:000> u @esicm3!RTLinker_I3:0062c950 55              push    ebp0062c951 8bec            mov     ebp,esp0062c953 81ec00000000    sub     esp,00062c959 53              push    ebx0062c95a 56              push    esi0062c95b 57              push    edi0062c95c 837d0800        cmp     dword ptr [ebp+8],00062c960 0f8400000000    je      cm3!RTLinker_I3+0x16 (0062c966) This is just wrong.Comparing bytes of code to -1. I think the likely fix is for the "I3" code to be laid out as a "constant function pointer", a pointer to a pair of pointers where one points to the code and one is to -1. Something like that. That can't be quite correct given that the existing data is callable.  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sun May 25 08:42:35 2008
From: jayk123 at hotmail.com (Jay)
Date: Sun, 25 May 2008 06:42:35 +0000
Subject: [M3devel] cstdio.i3?
In-Reply-To: 
References: <483862F4.1E75.00D7.1@scires.com>
	
Message-ID: 

I'm wondering about Cstdio.i3..
 
It bugs me to see duplicated code/declarations, code I can't easily verify the correctness of, code that duplicates internal details either that aren't necessary and/or are subject to change (ie: it *might* be useful to know the size of a FILE, but knowing the internal makeup is not generally useful, as well the size can be abstracted away behind a tiny bit of portable C), etc.
 
interface Cstdio seems
 
- almost not used at all within the "std" packages
I realize folks out there with other code could be using it.
The only use I see is related to the next:
 
 - to offer little in the way of a portable interface
About the main portable thing is presents is that there is a type FILE_star, though even that isn't quite universial across them all; conceptually it is of course
However, a medium sized very portable interface is easy to expose, though it isn't necessarily easy to make much use of.
 
So:
 - do nothing?
 - reduce it all down to just a common two-liner TYPE FILE = RECORD END; FILE_star = UNTRACED REF FILE ?
 - bulk it up slightly to a very portable (target-independent) interface?
   NT386/Cstdio.i3 is close to what that would be.
 
And no, I'm not forgetful. I know I brought this up a few months ago when I introduced NT386/Cstdio.i3.
 
Does anyone find the knowledge built up in the myriad Cstdio.i3 files useful?
One thing to do is leave all the per-platform files but not put them in the m3makefile, only actually compile the two line or medium sized portable version.
 
 ?
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rodney.bates at wichita.edu  Mon May 26 05:50:15 2008
From: rodney.bates at wichita.edu (Rodney M. Bates)
Date: Sun, 25 May 2008 22:50:15 -0500
Subject: [M3devel] function pointers and comparison to nil? mis-typed
 function pointers?
In-Reply-To: 
References: <483862F4.1E75.00D7.1@scires.com>
	
	
Message-ID: <483A3377.7070801@wichita.edu>

I think I can shed some light on this, having spent some time making
m3gdb handle the various operations on nested procedures.  As for code
that mixes M3 and C, I believe the following are true:

- Within M3 code only, the closure system works correctly in all cases.
   This answers one of Jay's worries.

- For values of M3 procedure/C function pointer that are top-level
   (nonnested) procedures/functions, M3 and C code (generated by gcc,
   at least) are interchangeable.  This answers another of Jay's worries.
   This will cover that great majority of cases.

- Standard C has no nested functions.  Gcc adds them as a language
   extension.  Thus, only in gcc-compiled C code do we need to worry
   about nested procedures/functions between languages.  (Do any other
   C compilers exist that also have nested functions?)

- M3 code should be able to call the value of a procedure variable
   that was originally produced by C code as a pointer to a nested
   function, and get the environment set up right, so its nonlocal
   variable references will work, _if_ the nested function's
   environment has not disappeared.  This partially answers another
   of Jay's worries.  But:

- M3's normal runtime check that precludes assigning a nonlocal
   procedure value will not detect a C-code-produced nonlocal value,
   thus the environment could indeed have disappeared if the programmer
   was not careful.  However, gcc-extended C's nested functions have
   no protection against this bug when only C code is involved, so
   perhaps not detecting it in mixed M3/C is to be expected.

- C code that attempts to call a function pointer value that was
   originally produced by M3 code as a nested procedure value will
   almost certainly crash at the time of the call.  This is the only
   case that presents a significant problem.  M3 code will not be
   able to give a nested procedure as a callback to a C library.

M3's mechanism:  A value of procedure type is a pointer to either
1) the first byte of the procedure's machine code, if it is top level, or
2) A closure.

A closure is a block of 3 words.  The first word contains -1.  Assuming
a word of all one bits is not valid machine code on any target machine
(or at least doesn't occur as the first code of any procedure), this can
be used at runtime to detect that this is indeed a closure and not code.
The remaining two words hold the code address and the environment address.

So, an assignment of a procedure value has to check that it is not a closure,
and raise a runtime error if it is.  A call on a procedure value has to check,
and if it is a closure, load/copy its environment pointer value into wherever
the calling convention expects it, then branch to the code address.  Passing
a nested procedure constant as a parameter involves constructing a closure for
it and passing its address.

gcc-C's mechanism:  A value of type pointer to function is a pointer to either
1) the first byte of the function's machine code, if it is top level,
    (the same as with M3), or
2) A trampoline.

A trampoline is a bit of code that loads/copies an environment pointer (hard
coded into the trampoline) and then branches to the function code.

Trampolines probably have a small constant-time speed advantage for _calls_,
but would be slower for some of the other operations, and the runtime check
could be tricky.  Probably it could be fooled into failing when it shouldn't.
Moreover, trampolines are highly target-machine-dependent.  Switching to them
would create a really big problem for m3gdb, which would have to have
different code for each target for each of the nested procedure operations.

Jay wrote:
> I see somewhat.
> It's stuff around "closure".
> The comparison of code bytes to -1 comes from If_closure for example.
>  
> The problem is presumably to come up with a unified representation of 
> pointers to functions that may or may not be nested, while avoiding 
> runtime codegen, even just a little bit, and for Modula-3 and C function 
> pointers to use the same representation.
> I don't think the present solution is really valid, and I am skeptical 
> that there is a solution.
> One of the requirements has to be dropped.
> Sniffing code bytes and trying to decide if they are code or not as 
> appears to currently happen is bogus.
>  
> I think the solution is to remove the requirement that a Modula-3 
> function pointer and a C function pointer are the same.
> Except, well, that probably doesn't work -- it means you need two types 
> of function pointers.
>  
> Darn this is a hard problem.
>  
> The runtime codegen required can be exceedingly simple, fast, and small 
> IF it were allowed to be on the stack. But that's a killer these days.
>  
> I think you have to give up unification of "closures" and "function 
> pointers".
> If you take the address of a nested function and call it, you cannot 
> access the locals of the enclosing scopes.
> So in affect, you end up with "two types of function pointers".
> Regular stateless ones and "closures" with some captured state.
>  
> Thoughts?
>  
> I'm kind of stumped. It's a desirable problem to solve, and there is a 
> purported solution in place, but the solution that is there is 
> completely bogus, despite appearing to work for a long time, and there 
> is no solution. That is my understanding. I could be wrong on any number 
> of points but I'm pretty sure.
>  
> I think you have to separate out function pointers and closures.
> Sniffing what it pointed to is dubous esp. as currently implemented.
> If this is really the way to go, then signature bytes need to be worked 
> out for all architectures that are guaranteed to not look like code.
> Or vice versa -- signature bytes worked out that all functions start 
> with, which is viable for Modula-3 but not for interop with C.
> Currently -1 is used, of pointer-size.
> That appears to be reasonable for x86:
>  
> 0:000> eb . ff ff ff ff
> 0:000> u .
> ntdll32!DbgBreakPoint:
> 7d61002d ff              ???
> 7d61002e ff              ???
> 7d61002f ff              ???
> 7d610030 ffc3            inc     ebx
>  
> but the instruction encodings or disassembly on other architectures 
> would have to be checked.
>  
>  - Jay
> 
>     ------------------------------------------------------------------------
>     From: jayk123 at hotmail.com
>     To: m3devel at elegosoft.com
>     Date: Sun, 25 May 2008 00:16:01 +0000
>     Subject: [M3devel] function pointers and comparison to nil?
>     mis-typed function pointers?
> 
>     I'm being lazy...
> 
>     Tony can you explain this stuff?
> 
>     Comparison of function pointers..
>     What are the various representations and rules?
> 
>     What does it mean to compare nested functions?
> 
>     What does it mean to compare a function to NIL?
> 
>     I'll poke around more.
> 
>     What I am seeing is that comparison of function pointers to NIL is
>     surprisingly
>     expensive, and probably somewhat buggy. Or at least some of the runtime
>     generated "metadata-ish" stuff is produced or typed incorrectly.
> 
>     In particular, RTLinker.m3:
> 
>     PROCEDURE AddUnit (b: RT0.Binder) =
>       VAR m: RT0.ModulePtr;
>       BEGIN
>         IF (b = NIL) THEN RETURN END;   line 119
>         m := b(0);                      line 120
>         IF (m = NIL) THEN RETURN END;   line 121
>         AddUnitI(m);                    line 122
>       END AddUnit;
> 
>     generates a lot of code, just for the first line:
>       (556) set_source_line 
>         source line  119 
>       (557) load 
>         m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb 
>       (558) load_nil 
>       (559) if_eq 
>       (560) load 
>         m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb 
>       (561) load_indirect 
>         load address offset 0x0 src_t 0x5 dst_t 0x5 
>       (562) load_integer 
>         integer n_bytes 0x0 hi 0x0 low 0x1 sign -1 
>       (563) if_eq 
>       (564) set_label 
>       (565) load_nil 
>       (566) load 
>         m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb 
>       (567) if_ne 
>       (568) set_label 
>       (569) exit_proc 
>       (570) set_label 
>       (571) set_source_line 
>         source line  120 
> 
>     The details on the load_integer trace might not be completely
>     correct. I will test a fix shortly.
>     Esp. that n_bytes gets decremented to zero before the trace.
> 
>     Ok, I see now why some of the bloat -- because the "then return end"
>     is on the same line.
>     If it were written as:
>       if (b = NIL THEN 
>         return
>       end  
>     It probably wouldn't look so bad. That took me a while to realize.
> 
>     The following is generated for SPARC64_OPENBSD:
>      
>      line 119
>      .stabn 68,0,119,.LLM61-.LLFBB4
>     .LLM61:
>      ldx [%fp+2175], %g1
>      brz %g1, .LL26
>       nop
>      ldx [%fp+2175], %g1
>      ldx [%g1], %g1            bus error here? yes, probably this one
>      cmp %g1, -1
>      be %xcc, .LL27
>       nop
>     .LL26:
>      ldx [%fp+2175], %g1
>      brz %g1, .LL33
>       nop
>     .LL27:
>      line 120
>      .stabn 68,0,120,.LLM62-.LLFBB4
>     .LLM62:
>      ldx [%fp+2175], %g1
>      stx %g1, [%fp+2007]
>      ldx [%fp+2007], %g1
>      brz %g1, .LL30
>       nop
>      ldx [%fp+2007], %g1
>      ldx [%g1], %g1            or here ?
>      cmp %g1, -1
>      bne %xcc, .LL30
>       nop
>      ldx [%fp+2007], %g1
>      add %g1, 16, %g1
>      ldx [%g1], %g1           or here?
>      stx %g1, [%fp+2015]
>      ldx [%fp+2007], %g1
>      add %g1, 8, %g1
>      ldx [%g1], %g1
>      stx %g1, [%fp+2007]
>     .LL30:
>      ldx [%fp+2007], %g1
>      ldx [%fp+2015], %g5
>      mov 0, %o0
>      call %g1, 0
>       nop
>      mov %o0, %g1
>      stx %g1, [%fp+2023]
>      ldx [%fp+2023], %g1
>      stx %g1, [%fp+1999]
>      
>      line 121
> 
>      .stabn 68,0,121,.LLM63-.LLFBB4
>     .LLM63:
>      ldx [%fp+1999], %g1
>      brz %g1, .LL33
>       nop
>     .LL32:
>      .stabn 68,0,122,.LLM64-.LLFBB4
>     .LLM64:
> 
>     g1 points to RTSignal_I3
> 
>     (gdb) x/i $pc
>     0x3ff0a8 :        ldx  [ %g1 ], %g1
>     (gdb) x/i $g1
>     0x4021f4 : save  %sp, -208, %sp
> 
>     I am willing to accept that a "function pointer" is a pair of
>     pointers, or even three pointers.
>     A pointer to code, a pointer to globals for position independent
>     code, a frame pointer to locals.
>     That equality comparison of function pointers requires comparing two
>     (or three) pointers.
>       (Though the global pointer shouldn't need comparing.)
>     At least for nested functions. Less so for non-nested. ?
>     Much less for comparison to NIL. ?
> 
>     And either way, this code is reading bogus data.
>     There isn't a pointer at the function address, there is code.
> 
>     Something doesn't add up.
> 
>     I'm going to try setting "aligned procedures" but that's quite bogus
>     I think.
> 
>     EqualExpr.m3 says
> 
>            Note: procedures pointers are always aligned!
> 
>     but maybe not?
> 
>     Yeah yeah I'm being lazy. I'll read more code..
> 
>     I also wonder if a "function pointer" can be optimized for the case
>     of not being to a nested function.
>     It looks like calling a function pointer is very inefficient.
>     It looks like..am I reading that correctly?.. that if the pointer
>     points to -1, then it is nested and
>     a pair of pointers, and not otherwise. That -1 is treated specially
>     as the first bytes of a function?
>     Is that a Modula-3-ism or a SPARC-ism?
>     It looks like a Modula-3-ism. And it seems dubious.
>     But I'll have to read more..
>      
>     NT386GNU does the same sort of wrong looking thing:
>      
>     LFBB4:
>      pushl %ebp
>      movl %esp, %ebp
>      subl $24, %esp
>     LBB5:
>      .stabn 68,0,117,LM60-LFBB4
>     LM60:
>      movl $0, -16(%ebp)
>      .stabn 68,0,119,LM61-LFBB4
>     LM61:
>      movl 8(%ebp), %eax
>      testl %eax, %eax
>      je L26
>      movl 8(%ebp), %eax
>      movl (%eax), %eax                  BAD
>      cmpl $-1, %eax                       BAD
>      je L27
>     L26:
>      movl 8(%ebp), %eax
>      testl %eax, %eax
>      je L33
>     L27:
>      .stabn 68,0,120,LM62-LFBB4
>     LM62:
> 
>      
>     and NT386:
>      
>     0:000> u
>     cm3!RTLinker__AddUnit:
>     00607864 55              push    ebp
>     00607865 8bec            mov     ebp,esp
>     00607867 81ec0c000000    sub     esp,0Ch
>     0060786d 53              push    ebx
>     0060786e 56              push    esi
>     0060786f 57              push    edi
>     00607870 c745fc00000000  mov     dword ptr [ebp-4],0
>     00607877 837d0800        cmp     dword ptr [ebp+8],0
>     0:000> u
>     cm3!RTLinker__AddUnit+0x17:
>     0060787b 0f840f000000    je      cm3!RTLinker__AddUnit+0x2c (00607890)
>     00607881 8b7508          mov     esi,dword ptr [ebp+8]
>     00607884 8b5e00          mov     ebx,dword ptr
>     [esi]                            BAD 
>     00607887 83fbff          cmp    
>     ebx,0FFFFFFFFh                                  BAD
>     0060788a 0f840f000000    je      cm3!RTLinker__AddUnit+0x3b (0060789f)
>     00607890 837d0800        cmp     dword ptr [ebp+8],0
>     00607894 0f8505000000    jne     cm3!RTLinker__AddUnit+0x3b (0060789f)
>     0060789a e969000000      jmp     cm3!RTLinker__AddUnit+0xa4 (00607908)
>      
>     cm3!RTLinker__AddUnit+0x20:
>     00607884 8b5e00          mov     ebx,dword ptr [esi] 
>     ds:002b:0062c950=81ec8b55
>     0:000> u @esi
>     cm3!RTLinker_I3:
>     0062c950 55              push    ebp
>     0062c951 8bec            mov     ebp,esp
>     0062c953 81ec00000000    sub     esp,0
>     0062c959 53              push    ebx
>     0062c95a 56              push    esi
>     0062c95b 57              push    edi
>     0062c95c 837d0800        cmp     dword ptr [ebp+8],0
>     0062c960 0f8400000000    je      cm3!RTLinker_I3+0x16 (0062c966)
>      
>     This is just wrong.
>     Comparing bytes of code to -1.
>      
>     I think the likely fix is for the "I3" code to be laid out as a
>     "constant function pointer", a pointer to a pair of pointers where
>     one points to the code and one is to -1. Something like that. That
>     can't be quite correct given that the existing data is callable.
> 
>       - Jay

-- 
-------------------------------------------------------------
Rodney M. Bates, retired assistant professor
Dept. of Computer Science, Wichita State University
Wichita, KS 67260-0083
316-978-3922
rodney.bates at wichita.edu


From jayk123 at hotmail.com  Mon May 26 07:26:41 2008
From: jayk123 at hotmail.com (Jay)
Date: Mon, 26 May 2008 05:26:41 +0000
Subject: [M3devel] function pointers and comparison to nil? mis-typed
 function pointers?
In-Reply-To: <483A3377.7070801@wichita.edu>
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
Message-ID: 

Rodney, this agrees with much of what I figured out and guessed. I did not think of or look into some of what you point out though:
  - what gcc's nested functions look like, and if you can take the address, and what that does 
  - calling Modula-3 nested functions as callbacks from C 
 
Now, regarding trampolines.
I alluded to them. It should be easy enough to generate them, and this would solve a few problems, but I believe also bring up a new big problem.
Generating trampolines solves at least two problems: 
 - it allows Modula-3 nested function pointers ("closures") to be called from C 
 - it enables removing the check for -1 
 
I contend that the check for -1 is not good. It is a somewhat risky assumption, that "-1" is not valid code.
You do bring up a nice mitigation -- the assumption that it doesn't begin any functions, which is much narrower than it being valid code anywhere.
 
For SPARC64_OPENBSD I figured out what the original authors meant to be the fix.
You declare functions as not aligned, leading to the check for -1 first checking alignment (bigger code).
Any pointer not aligned on an integer-sized address is presumed not a closure and not checked for the -1.
This lets SPARC64_OPENBSD get further. Both it and PPC32_OPENBSD now for some reason suffer from an inability to heap allocate anything, failing around the attempt to create a new thread like in RTAllocator_M or so. I'll look into this more later.
Now, the problem of trampolines..I consider the platform-dependent-ness to be surmountable.
But where do you put the generated code? Putting it on the stack is counter to modern (and possibly old) "security" mechanisms.
The stack is not generally executable, and even when it is, best just not do use that imho.
 
That means, potentially/obviously, the need to heap allocate executable memory, for very small short lived data, quite inefficient.
 
Is there some other way/place to produce trampolines, efficiently?
 
In the absence of any good solution, I have to resign myself to assuming that -1 isn't the valid start of a function, and perhaps moving the marker into Target.i3, Target.m3 so that "more obvious" values get chosen. Like a breakpoint. Or "an epilogue", or "a trap instruction". I realize this needs details and is easily seen as "wrong". In particular, a function that does nothing could be termed as only having an "an epilogue".
 
I know that other systems are "forced" to create "trampolines" so I should look into how they do that.
I know that ATL, a Windows-specific library, is forced to heap allocate small executable chunks of memory and uses an efficient cache to optimize it.
 
I do find this dependence on -1 not being the valid start of a function rather sleazy and at risk of being wrong.
 
 - Jay



> Date: Sun, 25 May 2008 22:50:15 -0500> From: rodney.bates at wichita.edu> To: m3devel at elegosoft.com> Subject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?> > I think I can shed some light on this, having spent some time making> m3gdb handle the various operations on nested procedures. As for code> that mixes M3 and C, I believe the following are true:> > - Within M3 code only, the closure system works correctly in all cases.> This answers one of Jay's worries.> > - For values of M3 procedure/C function pointer that are top-level> (nonnested) procedures/functions, M3 and C code (generated by gcc,> at least) are interchangeable. This answers another of Jay's worries.> This will cover that great majority of cases.> > - Standard C has no nested functions. Gcc adds them as a language> extension. Thus, only in gcc-compiled C code do we need to worry> about nested procedures/functions between languages. (Do any other> C compilers exist that also have nested functions?)> > - M3 code should be able to call the value of a procedure variable> that was originally produced by C code as a pointer to a nested> function, and get the environment set up right, so its nonlocal> variable references will work, _if_ the nested function's> environment has not disappeared. This partially answers another> of Jay's worries. But:> > - M3's normal runtime check that precludes assigning a nonlocal> procedure value will not detect a C-code-produced nonlocal value,> thus the environment could indeed have disappeared if the programmer> was not careful. However, gcc-extended C's nested functions have> no protection against this bug when only C code is involved, so> perhaps not detecting it in mixed M3/C is to be expected.> > - C code that attempts to call a function pointer value that was> originally produced by M3 code as a nested procedure value will> almost certainly crash at the time of the call. This is the only> case that presents a significant problem. M3 code will not be> able to give a nested procedure as a callback to a C library.> > M3's mechanism: A value of procedure type is a pointer to either> 1) the first byte of the procedure's machine code, if it is top level, or> 2) A closure.> > A closure is a block of 3 words. The first word contains -1. Assuming> a word of all one bits is not valid machine code on any target machine> (or at least doesn't occur as the first code of any procedure), this can> be used at runtime to detect that this is indeed a closure and not code.> The remaining two words hold the code address and the environment address.> > So, an assignment of a procedure value has to check that it is not a closure,> and raise a runtime error if it is. A call on a procedure value has to check,> and if it is a closure, load/copy its environment pointer value into wherever> the calling convention expects it, then branch to the code address. Passing> a nested procedure constant as a parameter involves constructing a closure for> it and passing its address.> > gcc-C's mechanism: A value of type pointer to function is a pointer to either> 1) the first byte of the function's machine code, if it is top level,> (the same as with M3), or> 2) A trampoline.> > A trampoline is a bit of code that loads/copies an environment pointer (hard> coded into the trampoline) and then branches to the function code.> > Trampolines probably have a small constant-time speed advantage for _calls_,> but would be slower for some of the other operations, and the runtime check> could be tricky. Probably it could be fooled into failing when it shouldn't.> Moreover, trampolines are highly target-machine-dependent. Switching to them> would create a really big problem for m3gdb, which would have to have> different code for each target for each of the nested procedure operations.> > Jay wrote:> > I see somewhat.> > It's stuff around "closure".> > The comparison of code bytes to -1 comes from If_closure for example.> > > > The problem is presumably to come up with a unified representation of > > pointers to functions that may or may not be nested, while avoiding > > runtime codegen, even just a little bit, and for Modula-3 and C function > > pointers to use the same representation.> > I don't think the present solution is really valid, and I am skeptical > > that there is a solution.> > One of the requirements has to be dropped.> > Sniffing code bytes and trying to decide if they are code or not as > > appears to currently happen is bogus.> > > > I think the solution is to remove the requirement that a Modula-3 > > function pointer and a C function pointer are the same.> > Except, well, that probably doesn't work -- it means you need two types > > of function pointers.> > > > Darn this is a hard problem.> > > > The runtime codegen required can be exceedingly simple, fast, and small > > IF it were allowed to be on the stack. But that's a killer these days.> > > > I think you have to give up unification of "closures" and "function > > pointers".> > If you take the address of a nested function and call it, you cannot > > access the locals of the enclosing scopes.> > So in affect, you end up with "two types of function pointers".> > Regular stateless ones and "closures" with some captured state.> > > > Thoughts?> > > > I'm kind of stumped. It's a desirable problem to solve, and there is a > > purported solution in place, but the solution that is there is > > completely bogus, despite appearing to work for a long time, and there > > is no solution. That is my understanding. I could be wrong on any number > > of points but I'm pretty sure.> > > > I think you have to separate out function pointers and closures.> > Sniffing what it pointed to is dubous esp. as currently implemented.> > If this is really the way to go, then signature bytes need to be worked > > out for all architectures that are guaranteed to not look like code.> > Or vice versa -- signature bytes worked out that all functions start > > with, which is viable for Modula-3 but not for interop with C.> > Currently -1 is used, of pointer-size.> > That appears to be reasonable for x86:> > > > 0:000> eb . ff ff ff ff> > 0:000> u .> > ntdll32!DbgBreakPoint:> > 7d61002d ff ???> > 7d61002e ff ???> > 7d61002f ff ???> > 7d610030 ffc3 inc ebx> > > > but the instruction encodings or disassembly on other architectures > > would have to be checked.> > > > - Jay> > > > ------------------------------------------------------------------------> > From: jayk123 at hotmail.com> > To: m3devel at elegosoft.com> > Date: Sun, 25 May 2008 00:16:01 +0000> > Subject: [M3devel] function pointers and comparison to nil?> > mis-typed function pointers?> > > > I'm being lazy...> > > > Tony can you explain this stuff?> > > > Comparison of function pointers..> > What are the various representations and rules?> > > > What does it mean to compare nested functions?> > > > What does it mean to compare a function to NIL?> > > > I'll poke around more.> > > > What I am seeing is that comparison of function pointers to NIL is> > surprisingly> > expensive, and probably somewhat buggy. Or at least some of the runtime> > generated "metadata-ish" stuff is produced or typed incorrectly.> > > > In particular, RTLinker.m3:> > > > PROCEDURE AddUnit (b: RT0.Binder) => > VAR m: RT0.ModulePtr;> > BEGIN> > IF (b = NIL) THEN RETURN END; line 119> > m := b(0); line 120> > IF (m = NIL) THEN RETURN END; line 121> > AddUnitI(m); line 122> > END AddUnit;> > > > generates a lot of code, just for the first line:> > (556) set_source_line > > source line 119 > > (557) load > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb > > (558) load_nil > > (559) if_eq > > (560) load > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb > > (561) load_indirect > > load address offset 0x0 src_t 0x5 dst_t 0x5 > > (562) load_integer > > integer n_bytes 0x0 hi 0x0 low 0x1 sign -1 > > (563) if_eq > > (564) set_label > > (565) load_nil > > (566) load > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb > > (567) if_ne > > (568) set_label > > (569) exit_proc > > (570) set_label > > (571) set_source_line > > source line 120 > > > > The details on the load_integer trace might not be completely> > correct. I will test a fix shortly.> > Esp. that n_bytes gets decremented to zero before the trace.> > > > Ok, I see now why some of the bloat -- because the "then return end"> > is on the same line.> > If it were written as:> > if (b = NIL THEN > > return> > end > > It probably wouldn't look so bad. That took me a while to realize.> > > > The following is generated for SPARC64_OPENBSD:> > > > line 119> > .stabn 68,0,119,.LLM61-.LLFBB4> > .LLM61:> > ldx [%fp+2175], %g1> > brz %g1, .LL26> > nop> > ldx [%fp+2175], %g1> > ldx [%g1], %g1 bus error here? yes, probably this one> > cmp %g1, -1> > be %xcc, .LL27> > nop> > .LL26:> > ldx [%fp+2175], %g1> > brz %g1, .LL33> > nop> > .LL27:> > line 120> > .stabn 68,0,120,.LLM62-.LLFBB4> > .LLM62:> > ldx [%fp+2175], %g1> > stx %g1, [%fp+2007]> > ldx [%fp+2007], %g1> > brz %g1, .LL30> > nop> > ldx [%fp+2007], %g1> > ldx [%g1], %g1 or here ?> > cmp %g1, -1> > bne %xcc, .LL30> > nop> > ldx [%fp+2007], %g1> > add %g1, 16, %g1> > ldx [%g1], %g1 or here?> > stx %g1, [%fp+2015]> > ldx [%fp+2007], %g1> > add %g1, 8, %g1> > ldx [%g1], %g1> > stx %g1, [%fp+2007]> > .LL30:> > ldx [%fp+2007], %g1> > ldx [%fp+2015], %g5> > mov 0, %o0> > call %g1, 0> > nop> > mov %o0, %g1> > stx %g1, [%fp+2023]> > ldx [%fp+2023], %g1> > stx %g1, [%fp+1999]> > > > line 121> > > > .stabn 68,0,121,.LLM63-.LLFBB4> > .LLM63:> > ldx [%fp+1999], %g1> > brz %g1, .LL33> > nop> > .LL32:> > .stabn 68,0,122,.LLM64-.LLFBB4> > .LLM64:> > > > g1 points to RTSignal_I3> > > > (gdb) x/i $pc> > 0x3ff0a8 : ldx [ %g1 ], %g1> > (gdb) x/i $g1> > 0x4021f4 : save %sp, -208, %sp> > > > I am willing to accept that a "function pointer" is a pair of> > pointers, or even three pointers.> > A pointer to code, a pointer to globals for position independent> > code, a frame pointer to locals.> > That equality comparison of function pointers requires comparing two> > (or three) pointers.> > (Though the global pointer shouldn't need comparing.)> > At least for nested functions. Less so for non-nested. ?> > Much less for comparison to NIL. ?> > > > And either way, this code is reading bogus data.> > There isn't a pointer at the function address, there is code.> > > > Something doesn't add up.> > > > I'm going to try setting "aligned procedures" but that's quite bogus> > I think.> > > > EqualExpr.m3 says> > > > Note: procedures pointers are always aligned!> > > > but maybe not?> > > > Yeah yeah I'm being lazy. I'll read more code..> > > > I also wonder if a "function pointer" can be optimized for the case> > of not being to a nested function.> > It looks like calling a function pointer is very inefficient.> > It looks like..am I reading that correctly?.. that if the pointer> > points to -1, then it is nested and> > a pair of pointers, and not otherwise. That -1 is treated specially> > as the first bytes of a function?> > Is that a Modula-3-ism or a SPARC-ism?> > It looks like a Modula-3-ism. And it seems dubious.> > But I'll have to read more..> > > > NT386GNU does the same sort of wrong looking thing:> > > > LFBB4:> > pushl %ebp> > movl %esp, %ebp> > subl $24, %esp> > LBB5:> > .stabn 68,0,117,LM60-LFBB4> > LM60:> > movl $0, -16(%ebp)> > .stabn 68,0,119,LM61-LFBB4> > LM61:> > movl 8(%ebp), %eax> > testl %eax, %eax> > je L26> > movl 8(%ebp), %eax> > movl (%eax), %eax BAD> > cmpl $-1, %eax BAD> > je L27> > L26:> > movl 8(%ebp), %eax> > testl %eax, %eax> > je L33> > L27:> > .stabn 68,0,120,LM62-LFBB4> > LM62:> > > > > > and NT386:> > > > 0:000> u> > cm3!RTLinker__AddUnit:> > 00607864 55 push ebp> > 00607865 8bec mov ebp,esp> > 00607867 81ec0c000000 sub esp,0Ch> > 0060786d 53 push ebx> > 0060786e 56 push esi> > 0060786f 57 push edi> > 00607870 c745fc00000000 mov dword ptr [ebp-4],0> > 00607877 837d0800 cmp dword ptr [ebp+8],0> > 0:000> u> > cm3!RTLinker__AddUnit+0x17:> > 0060787b 0f840f000000 je cm3!RTLinker__AddUnit+0x2c (00607890)> > 00607881 8b7508 mov esi,dword ptr [ebp+8]> > 00607884 8b5e00 mov ebx,dword ptr> > [esi] BAD > > 00607887 83fbff cmp > > ebx,0FFFFFFFFh BAD> > 0060788a 0f840f000000 je cm3!RTLinker__AddUnit+0x3b (0060789f)> > 00607890 837d0800 cmp dword ptr [ebp+8],0> > 00607894 0f8505000000 jne cm3!RTLinker__AddUnit+0x3b (0060789f)> > 0060789a e969000000 jmp cm3!RTLinker__AddUnit+0xa4 (00607908)> > > > cm3!RTLinker__AddUnit+0x20:> > 00607884 8b5e00 mov ebx,dword ptr [esi] > > ds:002b:0062c950=81ec8b55> > 0:000> u @esi> > cm3!RTLinker_I3:> > 0062c950 55 push ebp> > 0062c951 8bec mov ebp,esp> > 0062c953 81ec00000000 sub esp,0> > 0062c959 53 push ebx> > 0062c95a 56 push esi> > 0062c95b 57 push edi> > 0062c95c 837d0800 cmp dword ptr [ebp+8],0> > 0062c960 0f8400000000 je cm3!RTLinker_I3+0x16 (0062c966)> > > > This is just wrong.> > Comparing bytes of code to -1.> > > > I think the likely fix is for the "I3" code to be laid out as a> > "constant function pointer", a pointer to a pair of pointers where> > one points to the code and one is to -1. Something like that. That> > can't be quite correct given that the existing data is callable.> > > > - Jay> > -- > -------------------------------------------------------------> Rodney M. Bates, retired assistant professor> Dept. of Computer Science, Wichita State University> Wichita, KS 67260-0083> 316-978-3922> rodney.bates at wichita.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Mon May 26 12:04:56 2008
From: jayk123 at hotmail.com (Jay)
Date: Mon, 26 May 2008 10:04:56 +0000
Subject: [M3devel] function pointers and comparison to nil? mis-typed
 function pointers?
In-Reply-To: 
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
	
Message-ID: 

Cygwin gcc clearly generates code on the stack for nested functions.
And then search the web..that's how it works in general.
Nested functions have been deprecated on Mac OS X, in anticipation of possibly making the stack not executable.
 
OpenBSD doesn't allow execution on the stack.
They use mprotect to let trampolines run:
  http://gcc.gnu.org/ml/gcc/2004-01/msg00742.html 
and
  http://resin.csoft.net/cgi-bin/man.cgi?section=1&topic=gcc-local 
 
Even though nested functions are a gcc extension to the C language, email threads out there discuss Ada, Pascal, and even ! Modula-3 as having nested functions, and that therefore deprecating the C language feature doesn't "solve" the "problem".
 
I remain uncertain what, if anything, to do here.
 - keep the -1 hack, do nothing 
    generalize it slightly to let targets pick "better" markers 
 - use gcc's supported for nested functions 
   (plus the integrated backend, not difficult) 
 
Clearly this is a dilemna to more than just me. :)
 
 - Jay


From: jayk123 at hotmail.comTo: rodney.bates at wichita.edu; m3devel at elegosoft.comDate: Mon, 26 May 2008 05:26:41 +0000Subject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?


Rodney, this agrees with much of what I figured out and guessed. I did not think of or look into some of what you point out though:  - what gcc's nested functions look like, and if you can take the address, and what that does   - calling Modula-3 nested functions as callbacks from C  Now, regarding trampolines.I alluded to them. It should be easy enough to generate them, and this would solve a few problems, but I believe also bring up a new big problem.Generating trampolines solves at least two problems:  - it allows Modula-3 nested function pointers ("closures") to be called from C  - it enables removing the check for -1  I contend that the check for -1 is not good. It is a somewhat risky assumption, that "-1" is not valid code.You do bring up a nice mitigation -- the assumption that it doesn't begin any functions, which is much narrower than it being valid code anywhere. For SPARC64_OPENBSD I figured out what the original authors meant to be the fix.You declare functions as not aligned, leading to the check for -1 first checking alignment (bigger code).Any pointer not aligned on an integer-sized address is presumed not a closure and not checked for the -1.This lets SPARC64_OPENBSD get further. Both it and PPC32_OPENBSD now for some reason suffer from an inability to heap allocate anything, failing around the attempt to create a new thread like in RTAllocator_M or so. I'll look into this more later.Now, the problem of trampolines..I consider the platform-dependent-ness to be surmountable.But where do you put the generated code? Putting it on the stack is counter to modern (and possibly old) "security" mechanisms.The stack is not generally executable, and even when it is, best just not do use that imho. That means, potentially/obviously, the need to heap allocate executable memory, for very small short lived data, quite inefficient. Is there some other way/place to produce trampolines, efficiently? In the absence of any good solution, I have to resign myself to assuming that -1 isn't the valid start of a function, and perhaps moving the marker into Target.i3, Target.m3 so that "more obvious" values get chosen. Like a breakpoint. Or "an epilogue", or "a trap instruction". I realize this needs details and is easily seen as "wrong". In particular, a function that does nothing could be termed as only having an "an epilogue". I know that other systems are "forced" to create "trampolines" so I should look into how they do that.I know that ATL, a Windows-specific library, is forced to heap allocate small executable chunks of memory and uses an efficient cache to optimize it. I do find this dependence on -1 not being the valid start of a function rather sleazy and at risk of being wrong.  - Jay

> Date: Sun, 25 May 2008 22:50:15 -0500> From: rodney.bates at wichita.edu> To: m3devel at elegosoft.com> Subject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?> > I think I can shed some light on this, having spent some time making> m3gdb handle the various operations on nested procedures. As for code> that mixes M3 and C, I believe the following are true:> > - Within M3 code only, the closure system works correctly in all cases.> This answers one of Jay's worries.> > - For values of M3 procedure/C function pointer that are top-level> (nonnested) procedures/functions, M3 and C code (generated by gcc,> at least) are interchangeable. This answers another of Jay's worries.> This will cover that great majority of cases.> > - Standard C has no nested functions. Gcc adds them as a language> extension. Thus, only in gcc-compiled C code do we need to worry> about nested procedures/functions between languages. (Do any other> C compilers exist that also have nested functions?)> > - M3 code should be able to call the value of a procedure variable> that was originally produced by C code as a pointer to a nested> function, and get the environment set up right, so its nonlocal> variable references will work, _if_ the nested function's> environment has not disappeared. This partially answers another> of Jay's worries. But:> > - M3's normal runtime check that precludes assigning a nonlocal> procedure value will not detect a C-code-produced nonlocal value,> thus the environment could indeed have disappeared if the programmer> was not careful. However, gcc-extended C's nested functions have> no protection against this bug when only C code is involved, so> perhaps not detecting it in mixed M3/C is to be expected.> > - C code that attempts to call a function pointer value that was> originally produced by M3 code as a nested procedure value will> almost certainly crash at the time of the call. This is the only> case that presents a significant problem. M3 code will not be> able to give a nested procedure as a callback to a C library.> > M3's mechanism: A value of procedure type is a pointer to either> 1) the first byte of the procedure's machine code, if it is top level, or> 2) A closure.> > A closure is a block of 3 words. The first word contains -1. Assuming> a word of all one bits is not valid machine code on any target machine> (or at least doesn't occur as the first code of any procedure), this can> be used at runtime to detect that this is indeed a closure and not code.> The remaining two words hold the code address and the environment address.> > So, an assignment of a procedure value has to check that it is not a closure,> and raise a runtime error if it is. A call on a procedure value has to check,> and if it is a closure, load/copy its environment pointer value into wherever> the calling convention expects it, then branch to the code address. Passing> a nested procedure constant as a parameter involves constructing a closure for> it and passing its address.> > gcc-C's mechanism: A value of type pointer to function is a pointer to either> 1) the first byte of the function's machine code, if it is top level,> (the same as with M3), or> 2) A trampoline.> > A trampoline is a bit of code that loads/copies an environment pointer (hard> coded into the trampoline) and then branches to the function code.> > Trampolines probably have a small constant-time speed advantage for _calls_,> but would be slower for some of the other operations, and the runtime check> could be tricky. Probably it could be fooled into failing when it shouldn't.> Moreover, trampolines are highly target-machine-dependent. Switching to them> would create a really big problem for m3gdb, which would have to have> different code for each target for each of the nested procedure operations.> > Jay wrote:> > I see somewhat.> > It's stuff around "closure".> > The comparison of code bytes to -1 comes from If_closure for example.> > > > The problem is presumably to come up with a unified representation of > > pointers to functions that may or may not be nested, while avoiding > > runtime codegen, even just a little bit, and for Modula-3 and C function > > pointers to use the same representation.> > I don't think the present solution is really valid, and I am skeptical > > that there is a solution.> > One of the requirements has to be dropped.> > Sniffing code bytes and trying to decide if they are code or not as > > appears to currently happen is bogus.> > > > I think the solution is to remove the requirement that a Modula-3 > > function pointer and a C function pointer are the same.> > Except, well, that probably doesn't work -- it means you need two types > > of function pointers.> > > > Darn this is a hard problem.> > > > The runtime codegen required can be exceedingly simple, fast, and small > > IF it were allowed to be on the stack. But that's a killer these days.> > > > I think you have to give up unification of "closures" and "function > > pointers".> > If you take the address of a nested function and call it, you cannot > > access the locals of the enclosing scopes.> > So in affect, you end up with "two types of function pointers".> > Regular stateless ones and "closures" with some captured state.> > > > Thoughts?> > > > I'm kind of stumped. It's a desirable problem to solve, and there is a > > purported solution in place, but the solution that is there is > > completely bogus, despite appearing to work for a long time, and there > > is no solution. That is my understanding. I could be wrong on any number > > of points but I'm pretty sure.> > > > I think you have to separate out function pointers and closures.> > Sniffing what it pointed to is dubous esp. as currently implemented.> > If this is really the way to go, then signature bytes need to be worked > > out for all architectures that are guaranteed to not look like code.> > Or vice versa -- signature bytes worked out that all functions start > > with, which is viable for Modula-3 but not for interop with C.> > Currently -1 is used, of pointer-size.> > That appears to be reasonable for x86:> > > > 0:000> eb . ff ff ff ff> > 0:000> u .> > ntdll32!DbgBreakPoint:> > 7d61002d ff ???> > 7d61002e ff ???> > 7d61002f ff ???> > 7d610030 ffc3 inc ebx> > > > but the instruction encodings or disassembly on other architectures > > would have to be checked.> > > > - Jay> > > > ------------------------------------------------------------------------> > From: jayk123 at hotmail.com> > To: m3devel at elegosoft.com> > Date: Sun, 25 May 2008 00:16:01 +0000> > Subject: [M3devel] function pointers and comparison to nil?> > mis-typed function pointers?> > > > I'm being lazy...> > > > Tony can you explain this stuff?> > > > Comparison of function pointers..> > What are the various representations and rules?> > > > What does it mean to compare nested functions?> > > > What does it mean to compare a function to NIL?> > > > I'll poke around more.> > > > What I am seeing is that comparison of function pointers to NIL is> > surprisingly> > expensive, and probably somewhat buggy. Or at least some of the runtime> > generated "metadata-ish" stuff is produced or typed incorrectly.> > > > In particular, RTLinker.m3:> > > > PROCEDURE AddUnit (b: RT0.Binder) => > VAR m: RT0.ModulePtr;> > BEGIN> > IF (b = NIL) THEN RETURN END; line 119> > m := b(0); line 120> > IF (m = NIL) THEN RETURN END; line 121> > AddUnitI(m); line 122> > END AddUnit;> > > > generates a lot of code, just for the first line:> > (556) set_source_line > > source line 119 > > (557) load > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb > > (558) load_nil > > (559) if_eq > > (560) load > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb > > (561) load_indirect > > load address offset 0x0 src_t 0x5 dst_t 0x5 > > (562) load_integer > > integer n_bytes 0x0 hi 0x0 low 0x1 sign -1 > > (563) if_eq > > (564) set_label > > (565) load_nil > > (566) load > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb > > (567) if_ne > > (568) set_label > > (569) exit_proc > > (570) set_label > > (571) set_source_line > > source line 120 > > > > The details on the load_integer trace might not be completely> > correct. I will test a fix shortly.> > Esp. that n_bytes gets decremented to zero before the trace.> > > > Ok, I see now why some of the bloat -- because the "then return end"> > is on the same line.> > If it were written as:> > if (b = NIL THEN > > return> > end > > It probably wouldn't look so bad. That took me a while to realize.> > > > The following is generated for SPARC64_OPENBSD:> > > > line 119> > .stabn 68,0,119,.LLM61-.LLFBB4> > .LLM61:> > ldx [%fp+2175], %g1> > brz %g1, .LL26> > nop> > ldx [%fp+2175], %g1> > ldx [%g1], %g1 bus error here? yes, probably this one> > cmp %g1, -1> > be %xcc, .LL27> > nop> > .LL26:> > ldx [%fp+2175], %g1> > brz %g1, .LL33> > nop> > .LL27:> > line 120> > .stabn 68,0,120,.LLM62-.LLFBB4> > .LLM62:> > ldx [%fp+2175], %g1> > stx %g1, [%fp+2007]> > ldx [%fp+2007], %g1> > brz %g1, .LL30> > nop> > ldx [%fp+2007], %g1> > ldx [%g1], %g1 or here ?> > cmp %g1, -1> > bne %xcc, .LL30> > nop> > ldx [%fp+2007], %g1> > add %g1, 16, %g1> > ldx [%g1], %g1 or here?> > stx %g1, [%fp+2015]> > ldx [%fp+2007], %g1> > add %g1, 8, %g1> > ldx [%g1], %g1> > stx %g1, [%fp+2007]> > .LL30:> > ldx [%fp+2007], %g1> > ldx [%fp+2015], %g5> > mov 0, %o0> > call %g1, 0> > nop> > mov %o0, %g1> > stx %g1, [%fp+2023]> > ldx [%fp+2023], %g1> > stx %g1, [%fp+1999]> > > > line 121> > > > .stabn 68,0,121,.LLM63-.LLFBB4> > .LLM63:> > ldx [%fp+1999], %g1> > brz %g1, .LL33> > nop> > .LL32:> > .stabn 68,0,122,.LLM64-.LLFBB4> > .LLM64:> > > > g1 points to RTSignal_I3> > > > (gdb) x/i $pc> > 0x3ff0a8 : ldx [ %g1 ], %g1> > (gdb) x/i $g1> > 0x4021f4 : save %sp, -208, %sp> > > > I am willing to accept that a "function pointer" is a pair of> > pointers, or even three pointers.> > A pointer to code, a pointer to globals for position independent> > code, a frame pointer to locals.> > That equality comparison of function pointers requires comparing two> > (or three) pointers.> > (Though the global pointer shouldn't need comparing.)> > At least for nested functions. Less so for non-nested. ?> > Much less for comparison to NIL. ?> > > > And either way, this code is reading bogus data.> > There isn't a pointer at the function address, there is code.> > > > Something doesn't add up.> > > > I'm going to try setting "aligned procedures" but that's quite bogus> > I think.> > > > EqualExpr.m3 says> > > > Note: procedures pointers are always aligned!> > > > but maybe not?> > > > Yeah yeah I'm being lazy. I'll read more code..> > > > I also wonder if a "function pointer" can be optimized for the case> > of not being to a nested function.> > It looks like calling a function pointer is very inefficient.> > It looks like..am I reading that correctly?.. that if the pointer> > points to -1, then it is nested and> > a pair of pointers, and not otherwise. That -1 is treated specially> > as the first bytes of a function?> > Is that a Modula-3-ism or a SPARC-ism?> > It looks like a Modula-3-ism. And it seems dubious.> > But I'll have to read more..> > > > NT386GNU does the same sort of wrong looking thing:> > > > LFBB4:> > pushl %ebp> > movl %esp, %ebp> > subl $24, %esp> > LBB5:> > .stabn 68,0,117,LM60-LFBB4> > LM60:> > movl $0, -16(%ebp)> > .stabn 68,0,119,LM61-LFBB4> > LM61:> > movl 8(%ebp), %eax> > testl %eax, %eax> > je L26> > movl 8(%ebp), %eax> > movl (%eax), %eax BAD> > cmpl $-1, %eax BAD> > je L27> > L26:> > movl 8(%ebp), %eax> > testl %eax, %eax> > je L33> > L27:> > .stabn 68,0,120,LM62-LFBB4> > LM62:> > > > > > and NT386:> > > > 0:000> u> > cm3!RTLinker__AddUnit:> > 00607864 55 push ebp> > 00607865 8bec mov ebp,esp> > 00607867 81ec0c000000 sub esp,0Ch> > 0060786d 53 push ebx> > 0060786e 56 push esi> > 0060786f 57 push edi> > 00607870 c745fc00000000 mov dword ptr [ebp-4],0> > 00607877 837d0800 cmp dword ptr [ebp+8],0> > 0:000> u> > cm3!RTLinker__AddUnit+0x17:> > 0060787b 0f840f000000 je cm3!RTLinker__AddUnit+0x2c (00607890)> > 00607881 8b7508 mov esi,dword ptr [ebp+8]> > 00607884 8b5e00 mov ebx,dword ptr> > [esi] BAD > > 00607887 83fbff cmp > > ebx,0FFFFFFFFh BAD> > 0060788a 0f840f000000 je cm3!RTLinker__AddUnit+0x3b (0060789f)> > 00607890 837d0800 cmp dword ptr [ebp+8],0> > 00607894 0f8505000000 jne cm3!RTLinker__AddUnit+0x3b (0060789f)> > 0060789a e969000000 jmp cm3!RTLinker__AddUnit+0xa4 (00607908)> > > > cm3!RTLinker__AddUnit+0x20:> > 00607884 8b5e00 mov ebx,dword ptr [esi] > > ds:002b:0062c950=81ec8b55> > 0:000> u @esi> > cm3!RTLinker_I3:> > 0062c950 55 push ebp> > 0062c951 8bec mov ebp,esp> > 0062c953 81ec00000000 sub esp,0> > 0062c959 53 push ebx> > 0062c95a 56 push esi> > 0062c95b 57 push edi> > 0062c95c 837d0800 cmp dword ptr [ebp+8],0> > 0062c960 0f8400000000 je cm3!RTLinker_I3+0x16 (0062c966)> > > > This is just wrong.> > Comparing bytes of code to -1.> > > > I think the likely fix is for the "I3" code to be laid out as a> > "constant function pointer", a pointer to a pair of pointers where> > one points to the code and one is to -1. Something like that. That> > can't be quite correct given that the existing data is callable.> > > > - Jay> > -- > -------------------------------------------------------------> Rodney M. Bates, retired assistant professor> Dept. of Computer Science, Wichita State University> Wichita, KS 67260-0083> 316-978-3922> rodney.bates at wichita.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From hosking at cs.purdue.edu  Mon May 26 15:35:17 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 26 May 2008 14:35:17 +0100
Subject: [M3devel] function pointers and comparison to nil? mis-typed
	function pointers?
In-Reply-To: <483A3377.7070801@wichita.edu>
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
Message-ID: <3A6D6696-338C-4DB3-80B0-1F6EE2021E49@cs.purdue.edu>

Great summary Rodney.

Plus, trampolines typically require executable code on the stack which  
is disallowed by some OSs.

On May 26, 2008, at 4:50 AM, Rodney M. Bates wrote:

> I think I can shed some light on this, having spent some time making
> m3gdb handle the various operations on nested procedures.  As for code
> that mixes M3 and C, I believe the following are true:
>
> - Within M3 code only, the closure system works correctly in all  
> cases.
>  This answers one of Jay's worries.
>
> - For values of M3 procedure/C function pointer that are top-level
>  (nonnested) procedures/functions, M3 and C code (generated by gcc,
>  at least) are interchangeable.  This answers another of Jay's  
> worries.
>  This will cover that great majority of cases.
>
> - Standard C has no nested functions.  Gcc adds them as a language
>  extension.  Thus, only in gcc-compiled C code do we need to worry
>  about nested procedures/functions between languages.  (Do any other
>  C compilers exist that also have nested functions?)
>
> - M3 code should be able to call the value of a procedure variable
>  that was originally produced by C code as a pointer to a nested
>  function, and get the environment set up right, so its nonlocal
>  variable references will work, _if_ the nested function's
>  environment has not disappeared.  This partially answers another
>  of Jay's worries.  But:
>
> - M3's normal runtime check that precludes assigning a nonlocal
>  procedure value will not detect a C-code-produced nonlocal value,
>  thus the environment could indeed have disappeared if the programmer
>  was not careful.  However, gcc-extended C's nested functions have
>  no protection against this bug when only C code is involved, so
>  perhaps not detecting it in mixed M3/C is to be expected.
>
> - C code that attempts to call a function pointer value that was
>  originally produced by M3 code as a nested procedure value will
>  almost certainly crash at the time of the call.  This is the only
>  case that presents a significant problem.  M3 code will not be
>  able to give a nested procedure as a callback to a C library.
>
> M3's mechanism:  A value of procedure type is a pointer to either
> 1) the first byte of the procedure's machine code, if it is top  
> level, or
> 2) A closure.
>
> A closure is a block of 3 words.  The first word contains -1.   
> Assuming
> a word of all one bits is not valid machine code on any target machine
> (or at least doesn't occur as the first code of any procedure), this  
> can
> be used at runtime to detect that this is indeed a closure and not  
> code.
> The remaining two words hold the code address and the environment  
> address.
>
> So, an assignment of a procedure value has to check that it is not a  
> closure,
> and raise a runtime error if it is.  A call on a procedure value has  
> to check,
> and if it is a closure, load/copy its environment pointer value into  
> wherever
> the calling convention expects it, then branch to the code address.   
> Passing
> a nested procedure constant as a parameter involves constructing a  
> closure for
> it and passing its address.
>
> gcc-C's mechanism:  A value of type pointer to function is a pointer  
> to either
> 1) the first byte of the function's machine code, if it is top level,
>   (the same as with M3), or
> 2) A trampoline.
>
> A trampoline is a bit of code that loads/copies an environment  
> pointer (hard
> coded into the trampoline) and then branches to the function code.
>
> Trampolines probably have a small constant-time speed advantage for  
> _calls_,
> but would be slower for some of the other operations, and the  
> runtime check
> could be tricky.  Probably it could be fooled into failing when it  
> shouldn't.
> Moreover, trampolines are highly target-machine-dependent.   
> Switching to them
> would create a really big problem for m3gdb, which would have to have
> different code for each target for each of the nested procedure  
> operations.
>
> Jay wrote:
>> I see somewhat.
>> It's stuff around "closure".
>> The comparison of code bytes to -1 comes from If_closure for example.
>> The problem is presumably to come up with a unified representation  
>> of pointers to functions that may or may not be nested, while  
>> avoiding runtime codegen, even just a little bit, and for Modula-3  
>> and C function pointers to use the same representation.
>> I don't think the present solution is really valid, and I am  
>> skeptical that there is a solution.
>> One of the requirements has to be dropped.
>> Sniffing code bytes and trying to decide if they are code or not as  
>> appears to currently happen is bogus.
>> I think the solution is to remove the requirement that a Modula-3  
>> function pointer and a C function pointer are the same.
>> Except, well, that probably doesn't work -- it means you need two  
>> types of function pointers.
>> Darn this is a hard problem.
>> The runtime codegen required can be exceedingly simple, fast, and  
>> small IF it were allowed to be on the stack. But that's a killer  
>> these days.
>> I think you have to give up unification of "closures" and "function  
>> pointers".
>> If you take the address of a nested function and call it, you  
>> cannot access the locals of the enclosing scopes.
>> So in affect, you end up with "two types of function pointers".
>> Regular stateless ones and "closures" with some captured state.
>> Thoughts?
>> I'm kind of stumped. It's a desirable problem to solve, and there  
>> is a purported solution in place, but the solution that is there is  
>> completely bogus, despite appearing to work for a long time, and  
>> there is no solution. That is my understanding. I could be wrong on  
>> any number of points but I'm pretty sure.
>> I think you have to separate out function pointers and closures.
>> Sniffing what it pointed to is dubous esp. as currently implemented.
>> If this is really the way to go, then signature bytes need to be  
>> worked out for all architectures that are guaranteed to not look  
>> like code.
>> Or vice versa -- signature bytes worked out that all functions  
>> start with, which is viable for Modula-3 but not for interop with C.
>> Currently -1 is used, of pointer-size.
>> That appears to be reasonable for x86:
>> 0:000> eb . ff ff ff ff
>> 0:000> u .
>> ntdll32!DbgBreakPoint:
>> 7d61002d ff              ???
>> 7d61002e ff              ???
>> 7d61002f ff              ???
>> 7d610030 ffc3            inc     ebx
>> but the instruction encodings or disassembly on other architectures  
>> would have to be checked.
>>  - Jay
>>     
>> ------------------------------------------------------------------------
>>    From: jayk123 at hotmail.com
>>    To: m3devel at elegosoft.com
>>    Date: Sun, 25 May 2008 00:16:01 +0000
>>    Subject: [M3devel] function pointers and comparison to nil?
>>    mis-typed function pointers?
>>    I'm being lazy...
>>    Tony can you explain this stuff?
>>    Comparison of function pointers..
>>    What are the various representations and rules?
>>    What does it mean to compare nested functions?
>>    What does it mean to compare a function to NIL?
>>    I'll poke around more.
>>    What I am seeing is that comparison of function pointers to NIL is
>>    surprisingly
>>    expensive, and probably somewhat buggy. Or at least some of the  
>> runtime
>>    generated "metadata-ish" stuff is produced or typed incorrectly.
>>    In particular, RTLinker.m3:
>>    PROCEDURE AddUnit (b: RT0.Binder) =
>>      VAR m: RT0.ModulePtr;
>>      BEGIN
>>        IF (b = NIL) THEN RETURN END;   line 119
>>        m := b(0);                      line 120
>>        IF (m = NIL) THEN RETURN END;   line 121
>>        AddUnitI(m);                    line 122
>>      END AddUnit;
>>    generates a lot of code, just for the first line:
>>      (556) set_source_line         source line  119       (557)  
>> load         m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb ->  
>> 0xb       (558) load_nil       (559) if_eq       (560) load          
>> m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb       (561)  
>> load_indirect         load address offset 0x0 src_t 0x5 dst_t  
>> 0x5       (562) load_integer         integer n_bytes 0x0 hi 0x0 low  
>> 0x1 sign -1       (563) if_eq       (564) set_label       (565)  
>> load_nil       (566) load         m3cg_load (M3_DjPxE5_b): offset  
>> 0x0, convert 0xb -> 0xb       (567) if_ne       (568)  
>> set_label       (569) exit_proc       (570) set_label       (571)  
>> set_source_line         source line  120     The details on the  
>> load_integer trace might not be completely
>>    correct. I will test a fix shortly.
>>    Esp. that n_bytes gets decremented to zero before the trace.
>>    Ok, I see now why some of the bloat -- because the "then return  
>> end"
>>    is on the same line.
>>    If it were written as:
>>      if (b = NIL THEN         return
>>      end      It probably wouldn't look so bad. That took me a  
>> while to realize.
>>    The following is generated for SPARC64_OPENBSD:
>>          line 119
>>     .stabn 68,0,119,.LLM61-.LLFBB4
>>    .LLM61:
>>     ldx [%fp+2175], %g1
>>     brz %g1, .LL26
>>      nop
>>     ldx [%fp+2175], %g1
>>     ldx [%g1], %g1            bus error here? yes, probably this one
>>     cmp %g1, -1
>>     be %xcc, .LL27
>>      nop
>>    .LL26:
>>     ldx [%fp+2175], %g1
>>     brz %g1, .LL33
>>      nop
>>    .LL27:
>>     line 120
>>     .stabn 68,0,120,.LLM62-.LLFBB4
>>    .LLM62:
>>     ldx [%fp+2175], %g1
>>     stx %g1, [%fp+2007]
>>     ldx [%fp+2007], %g1
>>     brz %g1, .LL30
>>      nop
>>     ldx [%fp+2007], %g1
>>     ldx [%g1], %g1            or here ?
>>     cmp %g1, -1
>>     bne %xcc, .LL30
>>      nop
>>     ldx [%fp+2007], %g1
>>     add %g1, 16, %g1
>>     ldx [%g1], %g1           or here?
>>     stx %g1, [%fp+2015]
>>     ldx [%fp+2007], %g1
>>     add %g1, 8, %g1
>>     ldx [%g1], %g1
>>     stx %g1, [%fp+2007]
>>    .LL30:
>>     ldx [%fp+2007], %g1
>>     ldx [%fp+2015], %g5
>>     mov 0, %o0
>>     call %g1, 0
>>      nop
>>     mov %o0, %g1
>>     stx %g1, [%fp+2023]
>>     ldx [%fp+2023], %g1
>>     stx %g1, [%fp+1999]
>>          line 121
>>     .stabn 68,0,121,.LLM63-.LLFBB4
>>    .LLM63:
>>     ldx [%fp+1999], %g1
>>     brz %g1, .LL33
>>      nop
>>    .LL32:
>>     .stabn 68,0,122,.LLM64-.LLFBB4
>>    .LLM64:
>>    g1 points to RTSignal_I3
>>    (gdb) x/i $pc
>>    0x3ff0a8 :        ldx  [ %g1 ], %g1
>>    (gdb) x/i $g1
>>    0x4021f4 : save  %sp, -208, %sp
>>    I am willing to accept that a "function pointer" is a pair of
>>    pointers, or even three pointers.
>>    A pointer to code, a pointer to globals for position independent
>>    code, a frame pointer to locals.
>>    That equality comparison of function pointers requires comparing  
>> two
>>    (or three) pointers.
>>      (Though the global pointer shouldn't need comparing.)
>>    At least for nested functions. Less so for non-nested. ?
>>    Much less for comparison to NIL. ?
>>    And either way, this code is reading bogus data.
>>    There isn't a pointer at the function address, there is code.
>>    Something doesn't add up.
>>    I'm going to try setting "aligned procedures" but that's quite  
>> bogus
>>    I think.
>>    EqualExpr.m3 says
>>           Note: procedures pointers are always aligned!
>>    but maybe not?
>>    Yeah yeah I'm being lazy. I'll read more code..
>>    I also wonder if a "function pointer" can be optimized for the  
>> case
>>    of not being to a nested function.
>>    It looks like calling a function pointer is very inefficient.
>>    It looks like..am I reading that correctly?.. that if the pointer
>>    points to -1, then it is nested and
>>    a pair of pointers, and not otherwise. That -1 is treated  
>> specially
>>    as the first bytes of a function?
>>    Is that a Modula-3-ism or a SPARC-ism?
>>    It looks like a Modula-3-ism. And it seems dubious.
>>    But I'll have to read more..
>>         NT386GNU does the same sort of wrong looking thing:
>>         LFBB4:
>>     pushl %ebp
>>     movl %esp, %ebp
>>     subl $24, %esp
>>    LBB5:
>>     .stabn 68,0,117,LM60-LFBB4
>>    LM60:
>>     movl $0, -16(%ebp)
>>     .stabn 68,0,119,LM61-LFBB4
>>    LM61:
>>     movl 8(%ebp), %eax
>>     testl %eax, %eax
>>     je L26
>>     movl 8(%ebp), %eax
>>     movl (%eax), %eax                  BAD
>>     cmpl $-1, %eax                       BAD
>>     je L27
>>    L26:
>>     movl 8(%ebp), %eax
>>     testl %eax, %eax
>>     je L33
>>    L27:
>>     .stabn 68,0,120,LM62-LFBB4
>>    LM62:
>>         and NT386:
>>         0:000> u
>>    cm3!RTLinker__AddUnit:
>>    00607864 55              push    ebp
>>    00607865 8bec            mov     ebp,esp
>>    00607867 81ec0c000000    sub     esp,0Ch
>>    0060786d 53              push    ebx
>>    0060786e 56              push    esi
>>    0060786f 57              push    edi
>>    00607870 c745fc00000000  mov     dword ptr [ebp-4],0
>>    00607877 837d0800        cmp     dword ptr [ebp+8],0
>>    0:000> u
>>    cm3!RTLinker__AddUnit+0x17:
>>    0060787b 0f840f000000    je      cm3!RTLinker__AddUnit+0x2c  
>> (00607890)
>>    00607881 8b7508          mov     esi,dword ptr [ebp+8]
>>    00607884 8b5e00          mov     ebx,dword ptr
>>    [esi]                            BAD     00607887  
>> 83fbff          cmp        ebx, 
>> 0FFFFFFFFh                                  BAD
>>    0060788a 0f840f000000    je      cm3!RTLinker__AddUnit+0x3b  
>> (0060789f)
>>    00607890 837d0800        cmp     dword ptr [ebp+8],0
>>    00607894 0f8505000000    jne     cm3!RTLinker__AddUnit+0x3b  
>> (0060789f)
>>    0060789a e969000000      jmp     cm3!RTLinker__AddUnit+0xa4  
>> (00607908)
>>         cm3!RTLinker__AddUnit+0x20:
>>    00607884 8b5e00          mov     ebx,dword ptr [esi]     ds:002b: 
>> 0062c950=81ec8b55
>>    0:000> u @esi
>>    cm3!RTLinker_I3:
>>    0062c950 55              push    ebp
>>    0062c951 8bec            mov     ebp,esp
>>    0062c953 81ec00000000    sub     esp,0
>>    0062c959 53              push    ebx
>>    0062c95a 56              push    esi
>>    0062c95b 57              push    edi
>>    0062c95c 837d0800        cmp     dword ptr [ebp+8],0
>>    0062c960 0f8400000000    je      cm3!RTLinker_I3+0x16 (0062c966)
>>         This is just wrong.
>>    Comparing bytes of code to -1.
>>         I think the likely fix is for the "I3" code to be laid out  
>> as a
>>    "constant function pointer", a pointer to a pair of pointers where
>>    one points to the code and one is to -1. Something like that. That
>>    can't be quite correct given that the existing data is callable.
>>      - Jay
>
> -- 
> -------------------------------------------------------------
> Rodney M. Bates, retired assistant professor
> Dept. of Computer Science, Wichita State University
> Wichita, KS 67260-0083
> 316-978-3922
> rodney.bates at wichita.edu



From hosking at cs.purdue.edu  Mon May 26 15:38:53 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 26 May 2008 14:38:53 +0100
Subject: [M3devel] function pointers and comparison to nil? mis-typed
	function pointers?
In-Reply-To: 
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
	
	
Message-ID: 

Moving away from the current implementation would be a portability  
disaster because of the fact that gcc requires an executable stack for  
its nested function implementation which is non-portable.

On May 26, 2008, at 11:04 AM, Jay wrote:

> Cygwin gcc clearly generates code on the stack for nested functions.
> And then search the web..that's how it works in general.
> Nested functions have been deprecated on Mac OS X, in anticipation  
> of possibly making the stack not executable.
>
> OpenBSD doesn't allow execution on the stack.
> They use mprotect to let trampolines run:
>   http://gcc.gnu.org/ml/gcc/2004-01/msg00742.html
> and
>   http://resin.csoft.net/cgi-bin/man.cgi?section=1&topic=gcc-local
>
> Even though nested functions are a gcc extension to the C language,  
> email threads out there discuss Ada, Pascal, and even ! Modula-3 as  
> having nested functions, and that therefore deprecating the C  
> language feature doesn't "solve" the "problem".
>
> I remain uncertain what, if anything, to do here.
>  - keep the -1 hack, do nothing
>     generalize it slightly to let targets pick "better" markers
>  - use gcc's supported for nested functions
>    (plus the integrated backend, not difficult)
>
> Clearly this is a dilemna to more than just me. :)
>
>  - Jay
> From: jayk123 at hotmail.com
> To: rodney.bates at wichita.edu; m3devel at elegosoft.com
> Date: Mon, 26 May 2008 05:26:41 +0000
> Subject: Re: [M3devel] function pointers and comparison to nil? mis- 
> typed function pointers?
>
> Rodney, this agrees with much of what I figured out and guessed. I  
> did not think of or look into some of what you point out though:
>   - what gcc's nested functions look like, and if you can take the  
> address, and what that does
>   - calling Modula-3 nested functions as callbacks from C
>
> Now, regarding trampolines.
> I alluded to them. It should be easy enough to generate them, and  
> this would solve a few problems, but I believe also bring up a new  
> big problem.
> Generating trampolines solves at least two problems:
>  - it allows Modula-3 nested function pointers ("closures") to be  
> called from C
>  - it enables removing the check for -1
>
> I contend that the check for -1 is not good. It is a somewhat risky  
> assumption, that "-1" is not valid code.
> You do bring up a nice mitigation -- the assumption that it doesn't  
> begin any functions, which is much narrower than it being valid code  
> anywhere.
>
> For SPARC64_OPENBSD I figured out what the original authors meant to  
> be the fix.
> You declare functions as not aligned, leading to the check for -1  
> first checking alignment (bigger code).
> Any pointer not aligned on an integer-sized address is presumed not  
> a closure and not checked for the -1.
> This lets SPARC64_OPENBSD get further. Both it and PPC32_OPENBSD now  
> for some reason suffer from an inability to heap allocate anything,  
> failing around the attempt to create a new thread like in  
> RTAllocator_M or so. I'll look into this more later.
>
> Now, the problem of trampolines..I consider the platform-dependent- 
> ness to be surmountable.
> But where do you put the generated code? Putting it on the stack is  
> counter to modern (and possibly old) "security" mechanisms.
> The stack is not generally executable, and even when it is, best  
> just not do use that imho.
>
> That means, potentially/obviously, the need to heap allocate  
> executable memory, for very small short lived data, quite inefficient.
>
> Is there some other way/place to produce trampolines, efficiently?
>
> In the absence of any good solution, I have to resign myself to  
> assuming that -1 isn't the valid start of a function, and perhaps  
> moving the marker into Target.i3, Target.m3 so that "more obvious"  
> values get chosen. Like a breakpoint. Or "an epilogue", or "a trap  
> instruction". I realize this needs details and is easily seen as  
> "wrong". In particular, a function that does nothing could be termed  
> as only having an "an epilogue".
>
> I know that other systems are "forced" to create "trampolines" so I  
> should look into how they do that.
> I know that ATL, a Windows-specific library, is forced to heap  
> allocate small executable chunks of memory and uses an efficient  
> cache to optimize it.
>
> I do find this dependence on -1 not being the valid start of a  
> function rather sleazy and at risk of being wrong.
>
>  - Jay
>
>
>
>
> > Date: Sun, 25 May 2008 22:50:15 -0500
> > From: rodney.bates at wichita.edu
> > To: m3devel at elegosoft.com
> > Subject: Re: [M3devel] function pointers and comparison to nil?  
> mis-typed function pointers?
> >
> > I think I can shed some light on this, having spent some time making
> > m3gdb handle the various operations on nested procedures. As for  
> code
> > that mixes M3 and C, I believe the following are true:
> >
> > - Within M3 code only, the closure system works correctly in all  
> cases.
> > This answers one of Jay's worries.
> >
> > - For values of M3 procedure/C function pointer that are top-level
> > (nonnested) procedures/functions, M3 and C code (generated by gcc,
> > at least) are interchangeable. This answers another of Jay's  
> worries.
> > This will cover that great majority of cases.
> >
> > - Standard C has no nested functions. Gcc adds them as a language
> > extension. Thus, only in gcc-compiled C code do we need to worry
> > about nested procedures/functions between languages. (Do any other
> > C compilers exist that also have nested functions?)
> >
> > - M3 code should be able to call the value of a procedure variable
> > that was originally produced by C code as a pointer to a nested
> > function, and get the environment set up right, so its nonlocal
> > variable references will work, _if_ the nested function's
> > environment has not disappeared. This partially answers another
> > of Jay's worries. But:
> >
> > - M3's normal runtime check that precludes assigning a nonlocal
> > procedure value will not detect a C-code-produced nonlocal value,
> > thus the environment could indeed have disappeared if the programmer
> > was not careful. However, gcc-extended C's nested functions have
> > no protection against this bug when only C code is involved, so
> > perhaps not detecting it in mixed M3/C is to be expected.
> >
> > - C code that attempts to call a function pointer value that was
> > originally produced by M3 code as a nested procedure value will
> > almost certainly crash at the time of the call. This is the only
> > case that presents a significant problem. M3 code will not be
> > able to give a nested procedure as a callback to a C library.
> >
> > M3's mechanism: A value of procedure type is a pointer to either
> > 1) the first byte of the procedure's machine code, if it is top  
> level, or
> > 2) A closure.
> >
> > A closure is a block of 3 words. The first word contains -1.  
> Assuming
> > a word of all one bits is not valid machine code on any target  
> machine
> > (or at least doesn't occur as the first code of any procedure),  
> this can
> > be used at runtime to detect that this is indeed a closure and not  
> code.
> > The remaining two words hold the code address and the environment  
> address.
> >
> > So, an assignment of a procedure value has to check that it is not  
> a closure,
> > and raise a runtime error if it is. A call on a procedure value  
> has to check,
> > and if it is a closure, load/copy its environment pointer value  
> into wherever
> > the calling convention expects it, then branch to the code  
> address. Passing
> > a nested procedure constant as a parameter involves constructing a  
> closure for
> > it and passing its address.
> >
> > gcc-C's mechanism: A value of type pointer to function is a  
> pointer to either
> > 1) the first byte of the function's machine code, if it is top  
> level,
> > (the same as with M3), or
> > 2) A trampoline.
> >
> > A trampoline is a bit of code that loads/copies an environment  
> pointer (hard
> > coded into the trampoline) and then branches to the function code.
> >
> > Trampolines probably have a small constant-time speed advantage  
> for _calls_,
> > but would be slower for some of the other operations, and the  
> runtime check
> > could be tricky. Probably it could be fooled into failing when it  
> shouldn't.
> > Moreover, trampolines are highly target-machine-dependent.  
> Switching to them
> > would create a really big problem for m3gdb, which would have to  
> have
> > different code for each target for each of the nested procedure  
> operations.
> >
> > Jay wrote:
> > > I see somewhat.
> > > It's stuff around "closure".
> > > The comparison of code bytes to -1 comes from If_closure for  
> example.
> > >
> > > The problem is presumably to come up with a unified  
> representation of
> > > pointers to functions that may or may not be nested, while  
> avoiding
> > > runtime codegen, even just a little bit, and for Modula-3 and C  
> function
> > > pointers to use the same representation.
> > > I don't think the present solution is really valid, and I am  
> skeptical
> > > that there is a solution.
> > > One of the requirements has to be dropped.
> > > Sniffing code bytes and trying to decide if they are code or not  
> as
> > > appears to currently happen is bogus.
> > >
> > > I think the solution is to remove the requirement that a Modula-3
> > > function pointer and a C function pointer are the same.
> > > Except, well, that probably doesn't work -- it means you need  
> two types
> > > of function pointers.
> > >
> > > Darn this is a hard problem.
> > >
> > > The runtime codegen required can be exceedingly simple, fast,  
> and small
> > > IF it were allowed to be on the stack. But that's a killer these  
> days.
> > >
> > > I think you have to give up unification of "closures" and  
> "function
> > > pointers".
> > > If you take the address of a nested function and call it, you  
> cannot
> > > access the locals of the enclosing scopes.
> > > So in affect, you end up with "two types of function pointers".
> > > Regular stateless ones and "closures" with some captured state.
> > >
> > > Thoughts?
> > >
> > > I'm kind of stumped. It's a desirable problem to solve, and  
> there is a
> > > purported solution in place, but the solution that is there is
> > > completely bogus, despite appearing to work for a long time, and  
> there
> > > is no solution. That is my understanding. I could be wrong on  
> any number
> > > of points but I'm pretty sure.
> > >
> > > I think you have to separate out function pointers and closures.
> > > Sniffing what it pointed to is dubous esp. as currently  
> implemented.
> > > If this is really the way to go, then signature bytes need to be  
> worked
> > > out for all architectures that are guaranteed to not look like  
> code.
> > > Or vice versa -- signature bytes worked out that all functions  
> start
> > > with, which is viable for Modula-3 but not for interop with C.
> > > Currently -1 is used, of pointer-size.
> > > That appears to be reasonable for x86:
> > >
> > > 0:000> eb . ff ff ff ff
> > > 0:000> u .
> > > ntdll32!DbgBreakPoint:
> > > 7d61002d ff ???
> > > 7d61002e ff ???
> > > 7d61002f ff ???
> > > 7d610030 ffc3 inc ebx
> > >
> > > but the instruction encodings or disassembly on other  
> architectures
> > > would have to be checked.
> > >
> > > - Jay
> > >
> > >  
> ------------------------------------------------------------------------
> > > From: jayk123 at hotmail.com
> > > To: m3devel at elegosoft.com
> > > Date: Sun, 25 May 2008 00:16:01 +0000
> > > Subject: [M3devel] function pointers and comparison to nil?
> > > mis-typed function pointers?
> > >
> > > I'm being lazy...
> > >
> > > Tony can you explain this stuff?
> > >
> > > Comparison of function pointers..
> > > What are the various representations and rules?
> > >
> > > What does it mean to compare nested functions?
> > >
> > > What does it mean to compare a function to NIL?
> > >
> > > I'll poke around more.
> > >
> > > What I am seeing is that comparison of function pointers to NIL is
> > > surprisingly
> > > expensive, and probably somewhat buggy. Or at least some of the  
> runtime
> > > generated "metadata-ish" stuff is produced or typed incorrectly.
> > >
> > > In particular, RTLinker.m3:
> > >
> > > PROCEDURE AddUnit (b: RT0.Binder) =
> > > VAR m: RT0.ModulePtr;
> > > BEGIN
> > > IF (b = NIL) THEN RETURN END; line 119
> > > m := b(0); line 120
> > > IF (m = NIL) THEN RETURN END; line 121
> > > AddUnitI(m); line 122
> > > END AddUnit;
> > >
> > > generates a lot of code, just for the first line:
> > > (556) set_source_line
> > > source line 119
> > > (557) load
> > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb
> > > (558) load_nil
> > > (559) if_eq
> > > (560) load
> > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb
> > > (561) load_indirect
> > > load address offset 0x0 src_t 0x5 dst_t 0x5
> > > (562) load_integer
> > > integer n_bytes 0x0 hi 0x0 low 0x1 sign -1
> > > (563) if_eq
> > > (564) set_label
> > > (565) load_nil
> > > (566) load
> > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb
> > > (567) if_ne
> > > (568) set_label
> > > (569) exit_proc
> > > (570) set_label
> > > (571) set_source_line
> > > source line 120
> > >
> > > The details on the load_integer trace might not be completely
> > > correct. I will test a fix shortly.
> > > Esp. that n_bytes gets decremented to zero before the trace.
> > >
> > > Ok, I see now why some of the bloat -- because the "then return  
> end"
> > > is on the same line.
> > > If it were written as:
> > > if (b = NIL THEN
> > > return
> > > end
> > > It probably wouldn't look so bad. That took me a while to realize.
> > >
> > > The following is generated for SPARC64_OPENBSD:
> > >
> > > line 119
> > > .stabn 68,0,119,.LLM61-.LLFBB4
> > > .LLM61:
> > > ldx [%fp+2175], %g1
> > > brz %g1, .LL26
> > > nop
> > > ldx [%fp+2175], %g1
> > > ldx [%g1], %g1 bus error here? yes, probably this one
> > > cmp %g1, -1
> > > be %xcc, .LL27
> > > nop
> > > .LL26:
> > > ldx [%fp+2175], %g1
> > > brz %g1, .LL33
> > > nop
> > > .LL27:
> > > line 120
> > > .stabn 68,0,120,.LLM62-.LLFBB4
> > > .LLM62:
> > > ldx [%fp+2175], %g1
> > > stx %g1, [%fp+2007]
> > > ldx [%fp+2007], %g1
> > > brz %g1, .LL30
> > > nop
> > > ldx [%fp+2007], %g1
> > > ldx [%g1], %g1 or here ?
> > > cmp %g1, -1
> > > bne %xcc, .LL30
> > > nop
> > > ldx [%fp+2007], %g1
> > > add %g1, 16, %g1
> > > ldx [%g1], %g1 or here?
> > > stx %g1, [%fp+2015]
> > > ldx [%fp+2007], %g1
> > > add %g1, 8, %g1
> > > ldx [%g1], %g1
> > > stx %g1, [%fp+2007]
> > > .LL30:
> > > ldx [%fp+2007], %g1
> > > ldx [%fp+2015], %g5
> > > mov 0, %o0
> > > call %g1, 0
> > > nop
> > > mov %o0, %g1
> > > stx %g1, [%fp+2023]
> > > ldx [%fp+2023], %g1
> > > stx %g1, [%fp+1999]
> > >
> > > line 121
> > >
> > > .stabn 68,0,121,.LLM63-.LLFBB4
> > > .LLM63:
> > > ldx [%fp+1999], %g1
> > > brz %g1, .LL33
> > > nop
> > > .LL32:
> > > .stabn 68,0,122,.LLM64-.LLFBB4
> > > .LLM64:
> > >
> > > g1 points to RTSignal_I3
> > >
> > > (gdb) x/i $pc
> > > 0x3ff0a8 : ldx [ %g1 ], %g1
> > > (gdb) x/i $g1
> > > 0x4021f4 : save %sp, -208, %sp
> > >
> > > I am willing to accept that a "function pointer" is a pair of
> > > pointers, or even three pointers.
> > > A pointer to code, a pointer to globals for position independent
> > > code, a frame pointer to locals.
> > > That equality comparison of function pointers requires comparing  
> two
> > > (or three) pointers.
> > > (Though the global pointer shouldn't need comparing.)
> > > At least for nested functions. Less so for non-nested. ?
> > > Much less for comparison to NIL. ?
> > >
> > > And either way, this code is reading bogus data.
> > > There isn't a pointer at the function address, there is code.
> > >
> > > Something doesn't add up.
> > >
> > > I'm going to try setting "aligned procedures" but that's quite  
> bogus
> > > I think.
> > >
> > > EqualExpr.m3 says
> > >
> > > Note: procedures pointers are always aligned!
> > >
> > > but maybe not?
> > >
> > > Yeah yeah I'm being lazy. I'll read more code..
> > >
> > > I also wonder if a "function pointer" can be optimized for the  
> case
> > > of not being to a nested function.
> > > It looks like calling a function pointer is very inefficient.
> > > It looks like..am I reading that correctly?.. that if the pointer
> > > points to -1, then it is nested and
> > > a pair of pointers, and not otherwise. That -1 is treated  
> specially
> > > as the first bytes of a function?
> > > Is that a Modula-3-ism or a SPARC-ism?
> > > It looks like a Modula-3-ism. And it seems dubious.
> > > But I'll have to read more..
> > >
> > > NT386GNU does the same sort of wrong looking thing:
> > >
> > > LFBB4:
> > > pushl %ebp
> > > movl %esp, %ebp
> > > subl $24, %esp
> > > LBB5:
> > > .stabn 68,0,117,LM60-LFBB4
> > > LM60:
> > > movl $0, -16(%ebp)
> > > .stabn 68,0,119,LM61-LFBB4
> > > LM61:
> > > movl 8(%ebp), %eax
> > > testl %eax, %eax
> > > je L26
> > > movl 8(%ebp), %eax
> > > movl (%eax), %eax BAD
> > > cmpl $-1, %eax BAD
> > > je L27
> > > L26:
> > > movl 8(%ebp), %eax
> > > testl %eax, %eax
> > > je L33
> > > L27:
> > > .stabn 68,0,120,LM62-LFBB4
> > > LM62:
> > >
> > >
> > > and NT386:
> > >
> > > 0:000> u
> > > cm3!RTLinker__AddUnit:
> > > 00607864 55 push ebp
> > > 00607865 8bec mov ebp,esp
> > > 00607867 81ec0c000000 sub esp,0Ch
> > > 0060786d 53 push ebx
> > > 0060786e 56 push esi
> > > 0060786f 57 push edi
> > > 00607870 c745fc00000000 mov dword ptr [ebp-4],0
> > > 00607877 837d0800 cmp dword ptr [ebp+8],0
> > > 0:000> u
> > > cm3!RTLinker__AddUnit+0x17:
> > > 0060787b 0f840f000000 je cm3!RTLinker__AddUnit+0x2c (00607890)
> > > 00607881 8b7508 mov esi,dword ptr [ebp+8]
> > > 00607884 8b5e00 mov ebx,dword ptr
> > > [esi] BAD
> > > 00607887 83fbff cmp
> > > ebx,0FFFFFFFFh BAD
> > > 0060788a 0f840f000000 je cm3!RTLinker__AddUnit+0x3b (0060789f)
> > > 00607890 837d0800 cmp dword ptr [ebp+8],0
> > > 00607894 0f8505000000 jne cm3!RTLinker__AddUnit+0x3b (0060789f)
> > > 0060789a e969000000 jmp cm3!RTLinker__AddUnit+0xa4 (00607908)
> > >
> > > cm3!RTLinker__AddUnit+0x20:
> > > 00607884 8b5e00 mov ebx,dword ptr [esi]
> > > ds:002b:0062c950=81ec8b55
> > > 0:000> u @esi
> > > cm3!RTLinker_I3:
> > > 0062c950 55 push ebp
> > > 0062c951 8bec mov ebp,esp
> > > 0062c953 81ec00000000 sub esp,0
> > > 0062c959 53 push ebx
> > > 0062c95a 56 push esi
> > > 0062c95b 57 push edi
> > > 0062c95c 837d0800 cmp dword ptr [ebp+8],0
> > > 0062c960 0f8400000000 je cm3!RTLinker_I3+0x16 (0062c966)
> > >
> > > This is just wrong.
> > > Comparing bytes of code to -1.
> > >
> > > I think the likely fix is for the "I3" code to be laid out as a
> > > "constant function pointer", a pointer to a pair of pointers where
> > > one points to the code and one is to -1. Something like that. That
> > > can't be quite correct given that the existing data is callable.
> > >
> > > - Jay
> >
> > --
> > -------------------------------------------------------------
> > Rodney M. Bates, retired assistant professor
> > Dept. of Computer Science, Wichita State University
> > Wichita, KS 67260-0083
> > 316-978-3922
> > rodney.bates at wichita.edu
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Mon May 26 15:54:18 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Mon, 26 May 2008 09:54:18 -0400
Subject: [M3devel] function pointers and comparison to nil?	mis-typed
	function pointers?
In-Reply-To: <483A3377.7070801@wichita.edu>
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
Message-ID: <483A88C5.1E75.00D7.1@scires.com>

I'm just "listening" here, but it would seem that much of what Rodney has stated would make for an excellent set of comments to be added to the code source file so that folks reading the code will better understand the reasoning behind what is going on.
--Randy

>>> "Rodney M. Bates"  5/25/2008 11:50 PM >>>
I think I can shed some light on this, having spent some time making
m3gdb handle the various operations on nested procedures.  As for code
that mixes M3 and C, I believe the following are true:

- Within M3 code only, the closure system works correctly in all cases.
   This answers one of Jay's worries.

- For values of M3 procedure/C function pointer that are top-level
   (nonnested) procedures/functions, M3 and C code (generated by gcc,
   at least) are interchangeable.  This answers another of Jay's worries.
   This will cover that great majority of cases.

- Standard C has no nested functions.  Gcc adds them as a language
   extension.  Thus, only in gcc-compiled C code do we need to worry
   about nested procedures/functions between languages.  (Do any other
   C compilers exist that also have nested functions?)

- M3 code should be able to call the value of a procedure variable
   that was originally produced by C code as a pointer to a nested
   function, and get the environment set up right, so its nonlocal
   variable references will work, _if_ the nested function's
   environment has not disappeared.  This partially answers another
   of Jay's worries.  But:

- M3's normal runtime check that precludes assigning a nonlocal
   procedure value will not detect a C-code-produced nonlocal value,
   thus the environment could indeed have disappeared if the programmer
   was not careful.  However, gcc-extended C's nested functions have
   no protection against this bug when only C code is involved, so
   perhaps not detecting it in mixed M3/C is to be expected.

- C code that attempts to call a function pointer value that was
   originally produced by M3 code as a nested procedure value will
   almost certainly crash at the time of the call.  This is the only
   case that presents a significant problem.  M3 code will not be
   able to give a nested procedure as a callback to a C library.

M3's mechanism:  A value of procedure type is a pointer to either
1) the first byte of the procedure's machine code, if it is top level, or
2) A closure.

A closure is a block of 3 words.  The first word contains -1.  Assuming
a word of all one bits is not valid machine code on any target machine
(or at least doesn't occur as the first code of any procedure), this can
be used at runtime to detect that this is indeed a closure and not code.
The remaining two words hold the code address and the environment address.

So, an assignment of a procedure value has to check that it is not a closure,
and raise a runtime error if it is.  A call on a procedure value has to check,
and if it is a closure, load/copy its environment pointer value into wherever
the calling convention expects it, then branch to the code address.  Passing
a nested procedure constant as a parameter involves constructing a closure for
it and passing its address.

gcc-C's mechanism:  A value of type pointer to function is a pointer to either
1) the first byte of the function's machine code, if it is top level,
    (the same as with M3), or
2) A trampoline.

A trampoline is a bit of code that loads/copies an environment pointer (hard
coded into the trampoline) and then branches to the function code.

Trampolines probably have a small constant-time speed advantage for _calls_,
but would be slower for some of the other operations, and the runtime check
could be tricky.  Probably it could be fooled into failing when it shouldn't.
Moreover, trampolines are highly target-machine-dependent.  Switching to them
would create a really big problem for m3gdb, which would have to have
different code for each target for each of the nested procedure operations.

Jay wrote:
> I see somewhat.
> It's stuff around "closure".
> The comparison of code bytes to -1 comes from If_closure for example.
>  
> The problem is presumably to come up with a unified representation of 
> pointers to functions that may or may not be nested, while avoiding 
> runtime codegen, even just a little bit, and for Modula-3 and C function 
> pointers to use the same representation.
> I don't think the present solution is really valid, and I am skeptical 
> that there is a solution.
> One of the requirements has to be dropped.
> Sniffing code bytes and trying to decide if they are code or not as 
> appears to currently happen is bogus.
>  
> I think the solution is to remove the requirement that a Modula-3 
> function pointer and a C function pointer are the same.
> Except, well, that probably doesn't work -- it means you need two types 
> of function pointers.
>  
> Darn this is a hard problem.
>  
> The runtime codegen required can be exceedingly simple, fast, and small 
> IF it were allowed to be on the stack. But that's a killer these days.
>  
> I think you have to give up unification of "closures" and "function 
> pointers".
> If you take the address of a nested function and call it, you cannot 
> access the locals of the enclosing scopes.
> So in affect, you end up with "two types of function pointers".
> Regular stateless ones and "closures" with some captured state.
>  
> Thoughts?
>  
> I'm kind of stumped. It's a desirable problem to solve, and there is a 
> purported solution in place, but the solution that is there is 
> completely bogus, despite appearing to work for a long time, and there 
> is no solution. That is my understanding. I could be wrong on any number 
> of points but I'm pretty sure.
>  
> I think you have to separate out function pointers and closures.
> Sniffing what it pointed to is dubous esp. as currently implemented.
> If this is really the way to go, then signature bytes need to be worked 
> out for all architectures that are guaranteed to not look like code.
> Or vice versa -- signature bytes worked out that all functions start 
> with, which is viable for Modula-3 but not for interop with C.
> Currently -1 is used, of pointer-size.
> That appears to be reasonable for x86:
>  
> 0:000> eb . ff ff ff ff
> 0:000> u .
> ntdll32!DbgBreakPoint:
> 7d61002d ff              ???
> 7d61002e ff              ???
> 7d61002f ff              ???
> 7d610030 ffc3            inc     ebx
>  
> but the instruction encodings or disassembly on other architectures 
> would have to be checked.
>  
>  - Jay
> 
>     ------------------------------------------------------------------------
>     From: jayk123 at hotmail.com 
>     To: m3devel at elegosoft.com 
>     Date: Sun, 25 May 2008 00:16:01 +0000
>     Subject: [M3devel] function pointers and comparison to nil?
>     mis-typed function pointers?
> 
>     I'm being lazy...
> 
>     Tony can you explain this stuff?
> 
>     Comparison of function pointers..
>     What are the various representations and rules?
> 
>     What does it mean to compare nested functions?
> 
>     What does it mean to compare a function to NIL?
> 
>     I'll poke around more.
> 
>     What I am seeing is that comparison of function pointers to NIL is
>     surprisingly
>     expensive, and probably somewhat buggy. Or at least some of the runtime
>     generated "metadata-ish" stuff is produced or typed incorrectly.
> 
>     In particular, RTLinker.m3:
> 
>     PROCEDURE AddUnit (b: RT0.Binder) =
>       VAR m: RT0.ModulePtr;
>       BEGIN
>         IF (b = NIL) THEN RETURN END;   line 119
>         m := b(0);                      line 120
>         IF (m = NIL) THEN RETURN END;   line 121
>         AddUnitI(m);                    line 122
>       END AddUnit;
> 
>     generates a lot of code, just for the first line:
>       (556) set_source_line 
>         source line  119 
>       (557) load 
>         m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb 
>       (558) load_nil 
>       (559) if_eq 
>       (560) load 
>         m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb 
>       (561) load_indirect 
>         load address offset 0x0 src_t 0x5 dst_t 0x5 
>       (562) load_integer 
>         integer n_bytes 0x0 hi 0x0 low 0x1 sign -1 
>       (563) if_eq 
>       (564) set_label 
>       (565) load_nil 
>       (566) load 
>         m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb 
>       (567) if_ne 
>       (568) set_label 
>       (569) exit_proc 
>       (570) set_label 
>       (571) set_source_line 
>         source line  120 
> 
>     The details on the load_integer trace might not be completely
>     correct. I will test a fix shortly.
>     Esp. that n_bytes gets decremented to zero before the trace.
> 
>     Ok, I see now why some of the bloat -- because the "then return end"
>     is on the same line.
>     If it were written as:
>       if (b = NIL THEN 
>         return
>       end  
>     It probably wouldn't look so bad. That took me a while to realize.
> 
>     The following is generated for SPARC64_OPENBSD:
>      
>      line 119
>      .stabn 68,0,119,.LLM61-.LLFBB4
>     .LLM61:
>      ldx [%fp+2175], %g1
>      brz %g1, .LL26
>       nop
>      ldx [%fp+2175], %g1
>      ldx [%g1], %g1            bus error here? yes, probably this one
>      cmp %g1, -1
>      be %xcc, .LL27
>       nop
>     .LL26:
>      ldx [%fp+2175], %g1
>      brz %g1, .LL33
>       nop
>     .LL27:
>      line 120
>      .stabn 68,0,120,.LLM62-.LLFBB4
>     .LLM62:
>      ldx [%fp+2175], %g1
>      stx %g1, [%fp+2007]
>      ldx [%fp+2007], %g1
>      brz %g1, .LL30
>       nop
>      ldx [%fp+2007], %g1
>      ldx [%g1], %g1            or here ?
>      cmp %g1, -1
>      bne %xcc, .LL30
>       nop
>      ldx [%fp+2007], %g1
>      add %g1, 16, %g1
>      ldx [%g1], %g1           or here?
>      stx %g1, [%fp+2015]
>      ldx [%fp+2007], %g1
>      add %g1, 8, %g1
>      ldx [%g1], %g1
>      stx %g1, [%fp+2007]
>     .LL30:
>      ldx [%fp+2007], %g1
>      ldx [%fp+2015], %g5
>      mov 0, %o0
>      call %g1, 0
>       nop
>      mov %o0, %g1
>      stx %g1, [%fp+2023]
>      ldx [%fp+2023], %g1
>      stx %g1, [%fp+1999]
>      
>      line 121
> 
>      .stabn 68,0,121,.LLM63-.LLFBB4
>     .LLM63:
>      ldx [%fp+1999], %g1
>      brz %g1, .LL33
>       nop
>     .LL32:
>      .stabn 68,0,122,.LLM64-.LLFBB4
>     .LLM64:
> 
>     g1 points to RTSignal_I3
> 
>     (gdb) x/i $pc
>     0x3ff0a8 :        ldx  [ %g1 ], %g1
>     (gdb) x/i $g1
>     0x4021f4 : save  %sp, -208, %sp
> 
>     I am willing to accept that a "function pointer" is a pair of
>     pointers, or even three pointers.
>     A pointer to code, a pointer to globals for position independent
>     code, a frame pointer to locals.
>     That equality comparison of function pointers requires comparing two
>     (or three) pointers.
>       (Though the global pointer shouldn't need comparing.)
>     At least for nested functions. Less so for non-nested. ?
>     Much less for comparison to NIL. ?
> 
>     And either way, this code is reading bogus data.
>     There isn't a pointer at the function address, there is code.
> 
>     Something doesn't add up.
> 
>     I'm going to try setting "aligned procedures" but that's quite bogus
>     I think.
> 
>     EqualExpr.m3 says
> 
>            Note: procedures pointers are always aligned!
> 
>     but maybe not?
> 
>     Yeah yeah I'm being lazy. I'll read more code..
> 
>     I also wonder if a "function pointer" can be optimized for the case
>     of not being to a nested function.
>     It looks like calling a function pointer is very inefficient.
>     It looks like..am I reading that correctly?.. that if the pointer
>     points to -1, then it is nested and
>     a pair of pointers, and not otherwise. That -1 is treated specially
>     as the first bytes of a function?
>     Is that a Modula-3-ism or a SPARC-ism?
>     It looks like a Modula-3-ism. And it seems dubious.
>     But I'll have to read more..
>      
>     NT386GNU does the same sort of wrong looking thing:
>      
>     LFBB4:
>      pushl %ebp
>      movl %esp, %ebp
>      subl $24, %esp
>     LBB5:
>      .stabn 68,0,117,LM60-LFBB4
>     LM60:
>      movl $0, -16(%ebp)
>      .stabn 68,0,119,LM61-LFBB4
>     LM61:
>      movl 8(%ebp), %eax
>      testl %eax, %eax
>      je L26
>      movl 8(%ebp), %eax
>      movl (%eax), %eax                  BAD
>      cmpl $-1, %eax                       BAD
>      je L27
>     L26:
>      movl 8(%ebp), %eax
>      testl %eax, %eax
>      je L33
>     L27:
>      .stabn 68,0,120,LM62-LFBB4
>     LM62:
> 
>      
>     and NT386:
>      
>     0:000> u
>     cm3!RTLinker__AddUnit:
>     00607864 55              push    ebp
>     00607865 8bec            mov     ebp,esp
>     00607867 81ec0c000000    sub     esp,0Ch
>     0060786d 53              push    ebx
>     0060786e 56              push    esi
>     0060786f 57              push    edi
>     00607870 c745fc00000000  mov     dword ptr [ebp-4],0
>     00607877 837d0800        cmp     dword ptr [ebp+8],0
>     0:000> u
>     cm3!RTLinker__AddUnit+0x17:
>     0060787b 0f840f000000    je      cm3!RTLinker__AddUnit+0x2c (00607890)
>     00607881 8b7508          mov     esi,dword ptr [ebp+8]
>     00607884 8b5e00          mov     ebx,dword ptr
>     [esi]                            BAD 
>     00607887 83fbff          cmp    
>     ebx,0FFFFFFFFh                                  BAD
>     0060788a 0f840f000000    je      cm3!RTLinker__AddUnit+0x3b (0060789f)
>     00607890 837d0800        cmp     dword ptr [ebp+8],0
>     00607894 0f8505000000    jne     cm3!RTLinker__AddUnit+0x3b (0060789f)
>     0060789a e969000000      jmp     cm3!RTLinker__AddUnit+0xa4 (00607908)
>      
>     cm3!RTLinker__AddUnit+0x20:
>     00607884 8b5e00          mov     ebx,dword ptr [esi] 
>     ds:002b:0062c950=81ec8b55
>     0:000> u @esi
>     cm3!RTLinker_I3:
>     0062c950 55              push    ebp
>     0062c951 8bec            mov     ebp,esp
>     0062c953 81ec00000000    sub     esp,0
>     0062c959 53              push    ebx
>     0062c95a 56              push    esi
>     0062c95b 57              push    edi
>     0062c95c 837d0800        cmp     dword ptr [ebp+8],0
>     0062c960 0f8400000000    je      cm3!RTLinker_I3+0x16 (0062c966)
>      
>     This is just wrong.
>     Comparing bytes of code to -1.
>      
>     I think the likely fix is for the "I3" code to be laid out as a
>     "constant function pointer", a pointer to a pair of pointers where
>     one points to the code and one is to -1. Something like that. That
>     can't be quite correct given that the existing data is callable.
> 
>       - Jay

-- 
-------------------------------------------------------------
Rodney M. Bates, retired assistant professor
Dept. of Computer Science, Wichita State University
Wichita, KS 67260-0083
316-978-3922
rodney.bates at wichita.edu 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Mon May 26 21:45:37 2008
From: jayk123 at hotmail.com (Jay)
Date: Mon, 26 May 2008 19:45:37 +0000
Subject: [M3devel] function pointers and comparison to nil? mis-typed
 function pointers?
In-Reply-To: 
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
	
	
	
Message-ID: 

It stinks either way imho.
The portability is handled, somehow or another, by gcc's support for nested functions.
For example on OpenBSD, they call mprotect to make the trampoline executable -- expensive! and leaves a bit of a security hole.
On Linux you can sometimes mark the .exe as needing an executable stack or not. Similarly on Windows, linker has /nxcompat, /nxcompat:no switch.
ATL on Windows puts trampolines in the heap and specifically makes them executable -- since the heap isn't necessarily executable either.
The -1 marker is also a bit of a portability problem but I guess in practise it works out.
I'd be curious to see how it decodes on various processors.
 
 - Jay


CC: rodney.bates at wichita.edu; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?Date: Mon, 26 May 2008 14:38:53 +0100

Moving away from the current implementation would be a portability disaster because of the fact that gcc requires an executable stack for its nested function implementation which is non-portable.

On May 26, 2008, at 11:04 AM, Jay wrote:

Cygwin gcc clearly generates code on the stack for nested functions.And then search the web..that's how it works in general.Nested functions have been deprecated on Mac OS X, in anticipation of possibly making the stack not executable. OpenBSD doesn't allow execution on the stack.They use mprotect to let trampolines run:  http://gcc.gnu.org/ml/gcc/2004-01/msg00742.html and  http://resin.csoft.net/cgi-bin/man.cgi?section=1&topic=gcc-local  Even though nested functions are a gcc extension to the C language, email threads out there discuss Ada, Pascal, and even ! Modula-3 as having nested functions, and that therefore deprecating the C language feature doesn't "solve" the "problem". I remain uncertain what, if anything, to do here. - keep the -1 hack, do nothing     generalize it slightly to let targets pick "better" markers  - use gcc's supported for nested functions    (plus the integrated backend, not difficult)  Clearly this is a dilemna to more than just me. :)  - Jay


From: jayk123 at hotmail.comTo: rodney.bates at wichita.edu; m3devel at elegosoft.comDate: Mon, 26 May 2008 05:26:41 +0000Subject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?Rodney, this agrees with much of what I figured out and guessed. I did not think of or look into some of what you point out though:  - what gcc's nested functions look like, and if you can take the address, and what that does   - calling Modula-3 nested functions as callbacks from C  Now, regarding trampolines.I alluded to them. It should be easy enough to generate them, and this would solve a few problems, but I believe also bring up a new big problem.Generating trampolines solves at least two problems:  - it allows Modula-3 nested function pointers ("closures") to be called from C  - it enables removing the check for -1  I contend that the check for -1 is not good. It is a somewhat risky assumption, that "-1" is not valid code.You do bring up a nice mitigation -- the assumption that it doesn't begin any functions, which is much narrower than it being valid code anywhere. For SPARC64_OPENBSD I figured out what the original authors meant to be the fix.You declare functions as not aligned, leading to the check for -1 first checking alignment (bigger code).Any pointer not aligned on an integer-sized address is presumed not a closure and not checked for the -1.This lets SPARC64_OPENBSD get further. Both it and PPC32_OPENBSD now for some reason suffer from an inability to heap allocate anything, failing around the attempt to create a new thread like in RTAllocator_M or so. I'll look into this more later.Now, the problem of trampolines..I consider the platform-dependent-ness to be surmountable.But where do you put the generated code? Putting it on the stack is counter to modern (and possibly old) "security" mechanisms.The stack is not generally executable, and even when it is, best just not do use that imho. That means, potentially/obviously, the need to heap allocate executable memory, for very small short lived data, quite inefficient. Is there some other way/place to produce trampolines, efficiently? In the absence of any good solution, I have to resign myself to assuming that -1 isn't the valid start of a function, and perhaps moving the marker into Target.i3, Target.m3 so that "more obvious" values get chosen. Like a breakpoint. Or "an epilogue", or "a trap instruction". I realize this needs details and is easily seen as "wrong". In particular, a function that does nothing could be termed as only having an "an epilogue". I know that other systems are "forced" to create "trampolines" so I should look into how they do that.I know that ATL, a Windows-specific library, is forced to heap allocate small executable chunks of memory and uses an efficient cache to optimize it. I do find this dependence on -1 not being the valid start of a function rather sleazy and at risk of being wrong.  - Jay

> Date: Sun, 25 May 2008 22:50:15 -0500> From: rodney.bates at wichita.edu> To: m3devel at elegosoft.com> Subject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?> > I think I can shed some light on this, having spent some time making> m3gdb handle the various operations on nested procedures. As for code> that mixes M3 and C, I believe the following are true:> > - Within M3 code only, the closure system works correctly in all cases.> This answers one of Jay's worries.> > - For values of M3 procedure/C function pointer that are top-level> (nonnested) procedures/functions, M3 and C code (generated by gcc,> at least) are interchangeable. This answers another of Jay's worries.> This will cover that great majority of cases.> > - Standard C has no nested functions. Gcc adds them as a language> extension. Thus, only in gcc-compiled C code do we need to worry> about nested procedures/functions between languages. (Do any other> C compilers exist that also have nested functions?)> > - M3 code should be able to call the value of a procedure variable> that was originally produced by C code as a pointer to a nested> function, and get the environment set up right, so its nonlocal> variable references will work, _if_ the nested function's> environment has not disappeared. This partially answers another> of Jay's worries. But:> > - M3's normal runtime check that precludes assigning a nonlocal> procedure value will not detect a C-code-produced nonlocal value,> thus the environment could indeed have disappeared if the programmer> was not careful. However, gcc-extended C's nested functions have> no protection against this bug when only C code is involved, so> perhaps not detecting it in mixed M3/C is to be expected.> > - C code that attempts to call a function pointer value that was> originally produced by M3 code as a nested procedure value will> almost certainly crash at the time of the call. This is the only> case that presents a significant problem. M3 code will not be> able to give a nested procedure as a callback to a C library.> > M3's mechanism: A value of procedure type is a pointer to either> 1) the first byte of the procedure's machine code, if it is top level, or> 2) A closure.> > A closure is a block of 3 words. The first word contains -1. Assuming> a word of all one bits is not valid machine code on any target machine> (or at least doesn't occur as the first code of any procedure), this can> be used at runtime to detect that this is indeed a closure and not code.> The remaining two words hold the code address and the environment address.> > So, an assignment of a procedure value has to check that it is not a closure,> and raise a runtime error if it is. A call on a procedure value has to check,> and if it is a closure, load/copy its environment pointer value into wherever> the calling convention expects it, then branch to the code address. Passing> a nested procedure constant as a parameter involves constructing a closure for> it and passing its address.> > gcc-C's mechanism: A value of type pointer to function is a pointer to either> 1) the first byte of the function's machine code, if it is top level,> (the same as with M3), or> 2) A trampoline.> > A trampoline is a bit of code that loads/copies an environment pointer (hard> coded into the trampoline) and then branches to the function code.> > Trampolines probably have a small constant-time speed advantage for _calls_,> but would be slower for some of the other operations, and the runtime check> could be tricky. Probably it could be fooled into failing when it shouldn't.> Moreover, trampolines are highly target-machine-dependent. Switching to them> would create a really big problem for m3gdb, which would have to have> different code for each target for each of the nested procedure operations.> > Jay wrote:> > I see somewhat.> > It's stuff around "closure".> > The comparison of code bytes to -1 comes from If_closure for example.> > > > The problem is presumably to come up with a unified representation of > > pointers to functions that may or may not be nested, while avoiding > > runtime codegen, even just a little bit, and for Modula-3 and C function > > pointers to use the same representation.> > I don't think the present solution is really valid, and I am skeptical > > that there is a solution.> > One of the requirements has to be dropped.> > Sniffing code bytes and trying to decide if they are code or not as > > appears to currently happen is bogus.> > > > I think the solution is to remove the requirement that a Modula-3 > > function pointer and a C function pointer are the same.> > Except, well, that probably doesn't work -- it means you need two types > > of function pointers.> > > > Darn this is a hard problem.> > > > The runtime codegen required can be exceedingly simple, fast, and small > > IF it were allowed to be on the stack. But that's a killer these days.> > > > I think you have to give up unification of "closures" and "function > > pointers".> > If you take the address of a nested function and call it, you cannot > > access the locals of the enclosing scopes.> > So in affect, you end up with "two types of function pointers".> > Regular stateless ones and "closures" with some captured state.> > > > Thoughts?> > > > I'm kind of stumped. It's a desirable problem to solve, and there is a > > purported solution in place, but the solution that is there is > > completely bogus, despite appearing to work for a long time, and there > > is no solution. That is my understanding. I could be wrong on any number > > of points but I'm pretty sure.> > > > I think you have to separate out function pointers and closures.> > Sniffing what it pointed to is dubous esp. as currently implemented.> > If this is really the way to go, then signature bytes need to be worked > > out for all architectures that are guaranteed to not look like code.> > Or vice versa -- signature bytes worked out that all functions start > > with, which is viable for Modula-3 but not for interop with C.> > Currently -1 is used, of pointer-size.> > That appears to be reasonable for x86:> > > > 0:000> eb . ff ff ff ff> > 0:000> u .> > ntdll32!DbgBreakPoint:> > 7d61002d ff ???> > 7d61002e ff ???> > 7d61002f ff ???> > 7d610030 ffc3 inc ebx> > > > but the instruction encodings or disassembly on other architectures > > would have to be checked.> > > > - Jay> > > > ------------------------------------------------------------------------> > From: jayk123 at hotmail.com> > To: m3devel at elegosoft.com> > Date: Sun, 25 May 2008 00:16:01 +0000> > Subject: [M3devel] function pointers and comparison to nil?> > mis-typed function pointers?> > > > I'm being lazy...> > > > Tony can you explain this stuff?> > > > Comparison of function pointers..> > What are the various representations and rules?> > > > What does it mean to compare nested functions?> > > > What does it mean to compare a function to NIL?> > > > I'll poke around more.> > > > What I am seeing is that comparison of function pointers to NIL is> > surprisingly> > expensive, and probably somewhat buggy. Or at least some of the runtime> > generated "metadata-ish" stuff is produced or typed incorrectly.> > > > In particular, RTLinker.m3:> > > > PROCEDURE AddUnit (b: RT0.Binder) => > VAR m: RT0.ModulePtr;> > BEGIN> > IF (b = NIL) THEN RETURN END; line 119> > m := b(0); line 120> > IF (m = NIL) THEN RETURN END; line 121> > AddUnitI(m); line 122> > END AddUnit;> > > > generates a lot of code, just for the first line:> > (556) set_source_line > > source line 119 > > (557) load > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb > > (558) load_nil > > (559) if_eq > > (560) load > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb > > (561) load_indirect > > load address offset 0x0 src_t 0x5 dst_t 0x5 > > (562) load_integer > > integer n_bytes 0x0 hi 0x0 low 0x1 sign -1 > > (563) if_eq > > (564) set_label > > (565) load_nil > > (566) load > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb > > (567) if_ne > > (568) set_label > > (569) exit_proc > > (570) set_label > > (571) set_source_line > > source line 120 > > > > The details on the load_integer trace might not be completely> > correct. I will test a fix shortly.> > Esp. that n_bytes gets decremented to zero before the trace.> > > > Ok, I see now why some of the bloat -- because the "then return end"> > is on the same line.> > If it were written as:> > if (b = NIL THEN > > return> > end > > It probably wouldn't look so bad. That took me a while to realize.> > > > The following is generated for SPARC64_OPENBSD:> > > > line 119> > .stabn 68,0,119,.LLM61-.LLFBB4> > .LLM61:> > ldx [%fp+2175], %g1> > brz %g1, .LL26> > nop> > ldx [%fp+2175], %g1> > ldx [%g1], %g1 bus error here? yes, probably this one> > cmp %g1, -1> > be %xcc, .LL27> > nop> > .LL26:> > ldx [%fp+2175], %g1> > brz %g1, .LL33> > nop> > .LL27:> > line 120> > .stabn 68,0,120,.LLM62-.LLFBB4> > .LLM62:> > ldx [%fp+2175], %g1> > stx %g1, [%fp+2007]> > ldx [%fp+2007], %g1> > brz %g1, .LL30> > nop> > ldx [%fp+2007], %g1> > ldx [%g1], %g1 or here ?> > cmp %g1, -1> > bne %xcc, .LL30> > nop> > ldx [%fp+2007], %g1> > add %g1, 16, %g1> > ldx [%g1], %g1 or here?> > stx %g1, [%fp+2015]> > ldx [%fp+2007], %g1> > add %g1, 8, %g1> > ldx [%g1], %g1> > stx %g1, [%fp+2007]> > .LL30:> > ldx [%fp+2007], %g1> > ldx [%fp+2015], %g5> > mov 0, %o0> > call %g1, 0> > nop> > mov %o0, %g1> > stx %g1, [%fp+2023]> > ldx [%fp+2023], %g1> > stx %g1, [%fp+1999]> > > > line 121> > > > .stabn 68,0,121,.LLM63-.LLFBB4> > .LLM63:> > ldx [%fp+1999], %g1> > brz %g1, .LL33> > nop> > .LL32:> > .stabn 68,0,122,.LLM64-.LLFBB4> > .LLM64:> > > > g1 points to RTSignal_I3> > > > (gdb) x/i $pc> > 0x3ff0a8 : ldx [ %g1 ], %g1> > (gdb) x/i $g1> > 0x4021f4 : save %sp, -208, %sp> > > > I am willing to accept that a "function pointer" is a pair of> > pointers, or even three pointers.> > A pointer to code, a pointer to globals for position independent> > code, a frame pointer to locals.> > That equality comparison of function pointers requires comparing two> > (or three) pointers.> > (Though the global pointer shouldn't need comparing.)> > At least for nested functions. Less so for non-nested. ?> > Much less for comparison to NIL. ?> > > > And either way, this code is reading bogus data.> > There isn't a pointer at the function address, there is code.> > > > Something doesn't add up.> > > > I'm going to try setting "aligned procedures" but that's quite bogus> > I think.> > > > EqualExpr.m3 says> > > > Note: procedures pointers are always aligned!> > > > but maybe not?> > > > Yeah yeah I'm being lazy. I'll read more code..> > > > I also wonder if a "function pointer" can be optimized for the case> > of not being to a nested function.> > It looks like calling a function pointer is very inefficient.> > It looks like..am I reading that correctly?.. that if the pointer> > points to -1, then it is nested and> > a pair of pointers, and not otherwise. That -1 is treated specially> > as the first bytes of a function?> > Is that a Modula-3-ism or a SPARC-ism?> > It looks like a Modula-3-ism. And it seems dubious.> > But I'll have to read more..> > > > NT386GNU does the same sort of wrong looking thing:> > > > LFBB4:> > pushl %ebp> > movl %esp, %ebp> > subl $24, %esp> > LBB5:> > .stabn 68,0,117,LM60-LFBB4> > LM60:> > movl $0, -16(%ebp)> > .stabn 68,0,119,LM61-LFBB4> > LM61:> > movl 8(%ebp), %eax> > testl %eax, %eax> > je L26> > movl 8(%ebp), %eax> > movl (%eax), %eax BAD> > cmpl $-1, %eax BAD> > je L27> > L26:> > movl 8(%ebp), %eax> > testl %eax, %eax> > je L33> > L27:> > .stabn 68,0,120,LM62-LFBB4> > LM62:> > > > > > and NT386:> > > > 0:000> u> > cm3!RTLinker__AddUnit:> > 00607864 55 push ebp> > 00607865 8bec mov ebp,esp> > 00607867 81ec0c000000 sub esp,0Ch> > 0060786d 53 push ebx> > 0060786e 56 push esi> > 0060786f 57 push edi> > 00607870 c745fc00000000 mov dword ptr [ebp-4],0> > 00607877 837d0800 cmp dword ptr [ebp+8],0> > 0:000> u> > cm3!RTLinker__AddUnit+0x17:> > 0060787b 0f840f000000 je cm3!RTLinker__AddUnit+0x2c (00607890)> > 00607881 8b7508 mov esi,dword ptr [ebp+8]> > 00607884 8b5e00 mov ebx,dword ptr> > [esi] BAD > > 00607887 83fbff cmp > > ebx,0FFFFFFFFh BAD> > 0060788a 0f840f000000 je cm3!RTLinker__AddUnit+0x3b (0060789f)> > 00607890 837d0800 cmp dword ptr [ebp+8],0> > 00607894 0f8505000000 jne cm3!RTLinker__AddUnit+0x3b (0060789f)> > 0060789a e969000000 jmp cm3!RTLinker__AddUnit+0xa4 (00607908)> > > > cm3!RTLinker__AddUnit+0x20:> > 00607884 8b5e00 mov ebx,dword ptr [esi] > > ds:002b:0062c950=81ec8b55> > 0:000> u @esi> > cm3!RTLinker_I3:> > 0062c950 55 push ebp> > 0062c951 8bec mov ebp,esp> > 0062c953 81ec00000000 sub esp,0> > 0062c959 53 push ebx> > 0062c95a 56 push esi> > 0062c95b 57 push edi> > 0062c95c 837d0800 cmp dword ptr [ebp+8],0> > 0062c960 0f8400000000 je cm3!RTLinker_I3+0x16 (0062c966)> > > > This is just wrong.> > Comparing bytes of code to -1.> > > > I think the likely fix is for the "I3" code to be laid out as a> > "constant function pointer", a pointer to a pair of pointers where> > one points to the code and one is to -1. Something like that. That> > can't be quite correct given that the existing data is callable.> > > > - Jay> > -- > -------------------------------------------------------------> Rodney M. Bates, retired assistant professor> Dept. of Computer Science, Wichita State University> Wichita, KS 67260-0083> 316-978-3922> rodney.bates at wichita.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rodney.bates at wichita.edu  Mon May 26 22:47:53 2008
From: rodney.bates at wichita.edu (Rodney M. Bates)
Date: Mon, 26 May 2008 15:47:53 -0500
Subject: [M3devel] function pointers and comparison to nil? mis-typed
 function pointers?
In-Reply-To: 
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
	
	
	
	
Message-ID: <483B21F9.6070205@wichita.edu>



Jay wrote:
> It stinks either way imho.
> The portability is handled, somehow or another, by gcc's support for 
> nested functions.
> For example on OpenBSD, they call mprotect to make the trampoline 
> executable -- expensive! and leaves a bit of a security hole.
> On Linux you can sometimes mark the .exe as needing an executable stack 
> or not. Similarly on Windows, linker has /nxcompat, /nxcompat:no switch.
> ATL on Windows puts trampolines in the heap and specifically makes them 
> executable -- since the heap isn't necessarily executable either.
> The -1 marker is also a bit of a portability problem but I guess in 
> practise it works out.

Using trampolines would make this problem worse, perhaps much worse.
Mistaking the function's real code for a closure is a lot less likely
than mistaking the function's real code for a trampoline.  A trampoline
is, after all, always valid machine code on the executing processor.
Not necessarily so for -1.

> I'd be curious to see how it decodes on various processors.
>  
>  - Jay
>
-- 
-------------------------------------------------------------
Rodney M. Bates, retired assistant professor
Dept. of Computer Science, Wichita State University
Wichita, KS 67260-0083
316-978-3922
rodney.bates at wichita.edu


From jayk123 at hotmail.com  Mon May 26 23:33:21 2008
From: jayk123 at hotmail.com (Jay)
Date: Mon, 26 May 2008 21:33:21 +0000
Subject: [M3devel] function pointers and comparison to nil? mis-typed
 function pointers?
In-Reply-To: <483B21F9.6070205@wichita.edu>
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
	
	
	
	 
	<483B21F9.6070205@wichita.edu>
Message-ID: 

 > Mistaking the function's real code for a closure is a lot less likely  > than mistaking the function's real code for a trampoline. A trampoline 
What is the danger in "mistaking" "real code" for a "trampoline"?
They are both "real code".
The differences are:
  - trampoline has limited lifetime -- unless it is heap allocated and garbage collected 
    ("real code" also has "limited lifetime", but relatively much longer, if code can be unloaded, which it can be in many environments) 
  - the "real code" of nested functions has a different calling convention than "real code" for non nested functions; it has an extra parameter "somewhere", for the "static link"; in gcc C nested functions on Cygwin/x86, this is in ecx 
 
What do folks think about putting trampolines in executable garbage collected heap?
I think that's inefficient but I'm usually in the minority here regarding the heap being inefficient.
 
One way or another, gcc makes C nested functions fairly portable, except Apple's gcc on Darwin.
Portability of -1 as a marker denoting "not code" is also dubious.
 
I think it stinks either way.
 
Anyone think coming up with "better" per-architecture markers is reasonable?
 
 - Jay



> Date: Mon, 26 May 2008 15:47:53 -0500> From: rodney.bates at wichita.edu> To: m3devel at elegosoft.com> Subject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?> > > > Jay wrote:> > It stinks either way imho.> > The portability is handled, somehow or another, by gcc's support for > > nested functions.> > For example on OpenBSD, they call mprotect to make the trampoline > > executable -- expensive! and leaves a bit of a security hole.> > On Linux you can sometimes mark the .exe as needing an executable stack > > or not. Similarly on Windows, linker has /nxcompat, /nxcompat:no switch.> > ATL on Windows puts trampolines in the heap and specifically makes them > > executable -- since the heap isn't necessarily executable either.> > The -1 marker is also a bit of a portability problem but I guess in > > practise it works out.> > Using trampolines would make this problem worse, perhaps much worse.> Mistaking the function's real code for a closure is a lot less likely> than mistaking the function's real code for a trampoline. A trampoline> is, after all, always valid machine code on the executing processor.> Not necessarily so for -1.> > > I'd be curious to see how it decodes on various processors.> > > > - Jay> >> -- > -------------------------------------------------------------> Rodney M. Bates, retired assistant professor> Dept. of Computer Science, Wichita State University> Wichita, KS 67260-0083> 316-978-3922> rodney.bates at wichita.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Tue May 27 07:14:11 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 27 May 2008 05:14:11 +0000
Subject: [M3devel] stat file types?
In-Reply-To: 
References: 
Message-ID: 

Hm. I was about to commit this and then I found:
 
 http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/sys/stat.h  http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libbc/inc/include/sys/stat.h 
 
One of these defines S_IFPORT, and it isn't equal to S_IFIFO.
The Modula-3 implementation is *perhaps* incorrect.
 
I don't yet have a Solaris install to see which of these is /usr/include/sys/stat.h and/or to determine what "the other" is.
 
I still haven't found any systems that define S_IFPIPE.
 
 - Jay


From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: stat file types?Date: Sat, 24 May 2008 09:50:50 +0000


It SEEMS: S_IFPIPE appears to be made up by Modula-3.S_IFPORT appears to be made up by Modula-3 as a synonym for S_IFIFO. PROPOSED:This code:D:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX\FilePosix.i3(36):   error if "fd" is not "S_IFPIPE", "S_IFPORT", or "S_IFSOCK". *)D:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX\FilePosix.m3(47):    | Ustat.S_IFPIPE, Ustat.S_IFPORT, Ustat.S_IFSOCK => should check for S_IFSOCK and S_IFIFO.all references to and definitions of S_IFPORT and S_IFPIPE should go away. Or did some actual systems actually define either of these? Most of the *.i3 files set S_IFPORT = S_IFIFO and S_IFPIPE = 0.Many of them say that there is no S_IFPIPE in their .h file.Irix has them reversed but the same result: S_IFPORT = 0 and S_IFPIPE = S_IFIFO. Any objections? - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From hosking at cs.purdue.edu  Tue May 27 10:48:37 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 27 May 2008 09:48:37 +0100
Subject: [M3devel] function pointers and comparison to nil? mis-typed
	function pointers?
In-Reply-To: 
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
	
	
	
	
Message-ID: <7F087A94-FCF4-487C-8744-530F82B95F95@cs.purdue.edu>

gcc just allows computation of the static link.

I think there is an alternate compilation mode supported by the front- 
end for other platforms (like the integrated back end) but I have not  
looked at that closely.



On May 26, 2008, at 8:45 PM, Jay wrote:

> It stinks either way imho.
> The portability is handled, somehow or another, by gcc's support for  
> nested functions.
> For example on OpenBSD, they call mprotect to make the trampoline  
> executable -- expensive! and leaves a bit of a security hole.
> On Linux you can sometimes mark the .exe as needing an executable  
> stack or not. Similarly on Windows, linker has /nxcompat, / 
> nxcompat:no switch.
> ATL on Windows puts trampolines in the heap and specifically makes  
> them executable -- since the heap isn't necessarily executable either.
> The -1 marker is also a bit of a portability problem but I guess in  
> practise it works out.
> I'd be curious to see how it decodes on various processors.
>
>  - Jay
>
> CC: rodney.bates at wichita.edu; m3devel at elegosoft.com
> From: hosking at cs.purdue.edu
> To: jayk123 at hotmail.com
> Subject: Re: [M3devel] function pointers and comparison to nil? mis- 
> typed function pointers?
> Date: Mon, 26 May 2008 14:38:53 +0100
>
> Moving away from the current implementation would be a portability  
> disaster because of the fact that gcc requires an executable stack  
> for its nested function implementation which is non-portable.
>
> On May 26, 2008, at 11:04 AM, Jay wrote:
>
> Cygwin gcc clearly generates code on the stack for nested functions.
> And then search the web..that's how it works in general.
> Nested functions have been deprecated on Mac OS X, in anticipation  
> of possibly making the stack not executable.
>
> OpenBSD doesn't allow execution on the stack.
> They use mprotect to let trampolines run:
>   http://gcc.gnu.org/ml/gcc/2004-01/msg00742.html
> and
>   http://resin.csoft.net/cgi-bin/man.cgi?section=1&topic=gcc-local
>
> Even though nested functions are a gcc extension to the C language,  
> email threads out there discuss Ada, Pascal, and even ! Modula-3 as  
> having nested functions, and that therefore deprecating the C  
> language feature doesn't "solve" the "problem".
>
> I remain uncertain what, if anything, to do here.
>  - keep the -1 hack, do nothing
>     generalize it slightly to let targets pick "better" markers
>  - use gcc's supported for nested functions
>    (plus the integrated backend, not difficult)
>
> Clearly this is a dilemna to more than just me. :)
>
>  - Jay
> From: jayk123 at hotmail.com
> To: rodney.bates at wichita.edu; m3devel at elegosoft.com
> Date: Mon, 26 May 2008 05:26:41 +0000
> Subject: Re: [M3devel] function pointers and comparison to nil? mis- 
> typed function pointers?
>
> Rodney, this agrees with much of what I figured out and guessed. I  
> did not think of or look into some of what you point out though:
>   - what gcc's nested functions look like, and if you can take the  
> address, and what that does
>   - calling Modula-3 nested functions as callbacks from C
>
> Now, regarding trampolines.
> I alluded to them. It should be easy enough to generate them, and  
> this would solve a few problems, but I believe also bring up a new  
> big problem.
> Generating trampolines solves at least two problems:
>  - it allows Modula-3 nested function pointers ("closures") to be  
> called from C
>  - it enables removing the check for -1
>
> I contend that the check for -1 is not good. It is a somewhat risky  
> assumption, that "-1" is not valid code.
> You do bring up a nice mitigation -- the assumption that it doesn't  
> begin any functions, which is much narrower than it being valid code  
> anywhere.
>
> For SPARC64_OPENBSD I figured out what the original authors meant to  
> be the fix.
> You declare functions as not aligned, leading to the check for -1  
> first checking alignment (bigger code).
> Any pointer not aligned on an integer-sized address is presumed not  
> a closure and not checked for the -1.
> This lets SPARC64_OPENBSD get further. Both it and PPC32_OPENBSD now  
> for some reason suffer from an inability to heap allocate anything,  
> failing around the attempt to create a new thread like in  
> RTAllocator_M or so. I'll look into this more later.
>
> Now, the problem of trampolines..I consider the platform-dependent- 
> ness to be surmountable.
> But where do you put the generated code? Putting it on the stack is  
> counter to modern (and possibly old) "security" mechanisms.
> The stack is not generally executable, and even when it is, best  
> just not do use that imho.
>
> That means, potentially/obviously, the need to heap allocate  
> executable memory, for very small short lived data, quite inefficient.
>
> Is there some other way/place to produce trampolines, efficiently?
>
> In the absence of any good solution, I have to resign myself to  
> assuming that -1 isn't the valid start of a function, and perhaps  
> moving the marker into Target.i3, Target.m3 so that "more obvious"  
> values get chosen. Like a breakpoint. Or "an epilogue", or "a trap  
> instruction". I realize this needs details and is easily seen as  
> "wrong". In particular, a function that does nothing could be termed  
> as only having an "an epilogue".
>
> I know that other systems are "forced" to create "trampolines" so I  
> should look into how they do that.
> I know that ATL, a Windows-specific library, is forced to heap  
> allocate small executable chunks of memory and uses an efficient  
> cache to optimize it.
>
> I do find this dependence on -1 not being the valid start of a  
> function rather sleazy and at risk of being wrong.
>
>  - Jay
>
>
>
>
> > Date: Sun, 25 May 2008 22:50:15 -0500
> > From: rodney.bates at wichita.edu
> > To: m3devel at elegosoft.com
> > Subject: Re: [M3devel] function pointers and comparison to nil?  
> mis-typed function pointers?
> >
> > I think I can shed some light on this, having spent some time making
> > m3gdb handle the various operations on nested procedures. As for  
> code
> > that mixes M3 and C, I believe the following are true:
> >
> > - Within M3 code only, the closure system works correctly in all  
> cases.
> > This answers one of Jay's worries.
> >
> > - For values of M3 procedure/C function pointer that are top-level
> > (nonnested) procedures/functions, M3 and C code (generated by gcc,
> > at least) are interchangeable. This answers another of Jay's  
> worries.
> > This will cover that great majority of cases.
> >
> > - Standard C has no nested functions. Gcc adds them as a language
> > extension. Thus, only in gcc-compiled C code do we need to worry
> > about nested procedures/functions between languages. (Do any other
> > C compilers exist that also have nested functions?)
> >
> > - M3 code should be able to call the value of a procedure variable
> > that was originally produced by C code as a pointer to a nested
> > function, and get the environment set up right, so its nonlocal
> > variable references will work, _if_ the nested function's
> > environment has not disappeared. This partially answers another
> > of Jay's worries. But:
> >
> > - M3's normal runtime check that precludes assigning a nonlocal
> > procedure value will not detect a C-code-produced nonlocal value,
> > thus the environment could indeed have disappeared if the programmer
> > was not careful. However, gcc-extended C's nested functions have
> > no protection against this bug when only C code is involved, so
> > perhaps not detecting it in mixed M3/C is to be expected.
> >
> > - C code that attempts to call a function pointer value that was
> > originally produced by M3 code as a nested procedure value will
> > almost certainly crash at the time of the call. This is the only
> > case that presents a significant problem. M3 code will not be
> > able to give a nested procedure as a callback to a C library.
> >
> > M3's mechanism: A value of procedure type is a pointer to either
> > 1) the first byte of the procedure's machine code, if it is top  
> level, or
> > 2) A closure.
> >
> > A closure is a block of 3 words. The first word contains -1.  
> Assuming
> > a word of all one bits is not valid machine code on any target  
> machine
> > (or at least doesn't occur as the first code of any procedure),  
> this can
> > be used at runtime to detect that this is indeed a closure and not  
> code.
> > The remaining two words hold the code address and the environment  
> address.
> >
> > So, an assignment of a procedure value has to check that it is not  
> a closure,
> > and raise a runtime error if it is. A call on a procedure value  
> has to check,
> > and if it is a closure, load/copy its environment pointer value  
> into wherever
> > the calling convention expects it, then branch to the code  
> address. Passing
> > a nested procedure constant as a parameter involves constructing a  
> closure for
> > it and passing its address.
> >
> > gcc-C's mechanism: A value of type pointer to function is a  
> pointer to either
> > 1) the first byte of the function's machine code, if it is top  
> level,
> > (the same as with M3), or
> > 2) A trampoline.
> >
> > A trampoline is a bit of code that loads/copies an environment  
> pointer (hard
> > coded into the trampoline) and then branches to the function code.
> >
> > Trampolines probably have a small constant-time speed advantage  
> for _calls_,
> > but would be slower for some of the other operations, and the  
> runtime check
> > could be tricky. Probably it could be fooled into failing when it  
> shouldn't.
> > Moreover, trampolines are highly target-machine-dependent.  
> Switching to them
> > would create a really big problem for m3gdb, which would have to  
> have
> > different code for each target for each of the nested procedure  
> operations.
> >
> > Jay wrote:
> > > I see somewhat.
> > > It's stuff around "closure".
> > > The comparison of code bytes to -1 comes from If_closure for  
> example.
> > >
> > > The problem is presumably to come up with a unified  
> representation of
> > > pointers to functions that may or may not be nested, while  
> avoiding
> > > runtime codegen, even just a little bit, and for Modula-3 and C  
> function
> > > pointers to use the same representation.
> > > I don't think the present solution is really valid, and I am  
> skeptical
> > > that there is a solution.
> > > One of the requirements has to be dropped.
> > > Sniffing code bytes and trying to decide if they are code or not  
> as
> > > appears to currently happen is bogus.
> > >
> > > I think the solution is to remove the requirement that a Modula-3
> > > function pointer and a C function pointer are the same.
> > > Except, well, that probably doesn't work -- it means you need  
> two types
> > > of function pointers.
> > >
> > > Darn this is a hard problem.
> > >
> > > The runtime codegen required can be exceedingly simple, fast,  
> and small
> > > IF it were allowed to be on the stack. But that's a killer these  
> days.
> > >
> > > I think you have to give up unification of "closures" and  
> "function
> > > pointers".
> > > If you take the address of a nested function and call it, you  
> cannot
> > > access the locals of the enclosing scopes.
> > > So in affect, you end up with "two types of function pointers".
> > > Regular stateless ones and "closures" with some captured state.
> > >
> > > Thoughts?
> > >
> > > I'm kind of stumped. It's a desirable problem to solve, and  
> there is a
> > > purported solution in place, but the solution that is there is
> > > completely bogus, despite appearing to work for a long time, and  
> there
> > > is no solution. That is my understanding. I could be wrong on  
> any number
> > > of points but I'm pretty sure.
> > >
> > > I think you have to separate out function pointers and closures.
> > > Sniffing what it pointed to is dubous esp. as currently  
> implemented.
> > > If this is really the way to go, then signature bytes need to be  
> worked
> > > out for all architectures that are guaranteed to not look like  
> code.
> > > Or vice versa -- signature bytes worked out that all functions  
> start
> > > with, which is viable for Modula-3 but not for interop with C.
> > > Currently -1 is used, of pointer-size.
> > > That appears to be reasonable for x86:
> > >
> > > 0:000> eb . ff ff ff ff
> > > 0:000> u .
> > > ntdll32!DbgBreakPoint:
> > > 7d61002d ff ???
> > > 7d61002e ff ???
> > > 7d61002f ff ???
> > > 7d610030 ffc3 inc ebx
> > >
> > > but the instruction encodings or disassembly on other  
> architectures
> > > would have to be checked.
> > >
> > > - Jay
> > >
> > >  
> ------------------------------------------------------------------------
> > > From: jayk123 at hotmail.com
> > > To: m3devel at elegosoft.com
> > > Date: Sun, 25 May 2008 00:16:01 +0000
> > > Subject: [M3devel] function pointers and comparison to nil?
> > > mis-typed function pointers?
> > >
> > > I'm being lazy...
> > >
> > > Tony can you explain this stuff?
> > >
> > > Comparison of function pointers..
> > > What are the various representations and rules?
> > >
> > > What does it mean to compare nested functions?
> > >
> > > What does it mean to compare a function to NIL?
> > >
> > > I'll poke around more.
> > >
> > > What I am seeing is that comparison of function pointers to NIL is
> > > surprisingly
> > > expensive, and probably somewhat buggy. Or at least some of the  
> runtime
> > > generated "metadata-ish" stuff is produced or typed incorrectly.
> > >
> > > In particular, RTLinker.m3:
> > >
> > > PROCEDURE AddUnit (b: RT0.Binder) =
> > > VAR m: RT0.ModulePtr;
> > > BEGIN
> > > IF (b = NIL) THEN RETURN END; line 119
> > > m := b(0); line 120
> > > IF (m = NIL) THEN RETURN END; line 121
> > > AddUnitI(m); line 122
> > > END AddUnit;
> > >
> > > generates a lot of code, just for the first line:
> > > (556) set_source_line
> > > source line 119
> > > (557) load
> > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb
> > > (558) load_nil
> > > (559) if_eq
> > > (560) load
> > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb
> > > (561) load_indirect
> > > load address offset 0x0 src_t 0x5 dst_t 0x5
> > > (562) load_integer
> > > integer n_bytes 0x0 hi 0x0 low 0x1 sign -1
> > > (563) if_eq
> > > (564) set_label
> > > (565) load_nil
> > > (566) load
> > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb
> > > (567) if_ne
> > > (568) set_label
> > > (569) exit_proc
> > > (570) set_label
> > > (571) set_source_line
> > > source line 120
> > >
> > > The details on the load_integer trace might not be completely
> > > correct. I will test a fix shortly.
> > > Esp. that n_bytes gets decremented to zero before the trace.
> > >
> > > Ok, I see now why some of the bloat -- because the "then return  
> end"
> > > is on the same line.
> > > If it were written as:
> > > if (b = NIL THEN
> > > return
> > > end
> > > It probably wouldn't look so bad. That took me a while to realize.
> > >
> > > The following is generated for SPARC64_OPENBSD:
> > >
> > > line 119
> > > .stabn 68,0,119,.LLM61-.LLFBB4
> > > .LLM61:
> > > ldx [%fp+2175], %g1
> > > brz %g1, .LL26
> > > nop
> > > ldx [%fp+2175], %g1
> > > ldx [%g1], %g1 bus error here? yes, probably this one
> > > cmp %g1, -1
> > > be %xcc, .LL27
> > > nop
> > > .LL26:
> > > ldx [%fp+2175], %g1
> > > brz %g1, .LL33
> > > nop
> > > .LL27:
> > > line 120
> > > .stabn 68,0,120,.LLM62-.LLFBB4
> > > .LLM62:
> > > ldx [%fp+2175], %g1
> > > stx %g1, [%fp+2007]
> > > ldx [%fp+2007], %g1
> > > brz %g1, .LL30
> > > nop
> > > ldx [%fp+2007], %g1
> > > ldx [%g1], %g1 or here ?
> > > cmp %g1, -1
> > > bne %xcc, .LL30
> > > nop
> > > ldx [%fp+2007], %g1
> > > add %g1, 16, %g1
> > > ldx [%g1], %g1 or here?
> > > stx %g1, [%fp+2015]
> > > ldx [%fp+2007], %g1
> > > add %g1, 8, %g1
> > > ldx [%g1], %g1
> > > stx %g1, [%fp+2007]
> > > .LL30:
> > > ldx [%fp+2007], %g1
> > > ldx [%fp+2015], %g5
> > > mov 0, %o0
> > > call %g1, 0
> > > nop
> > > mov %o0, %g1
> > > stx %g1, [%fp+2023]
> > > ldx [%fp+2023], %g1
> > > stx %g1, [%fp+1999]
> > >
> > > line 121
> > >
> > > .stabn 68,0,121,.LLM63-.LLFBB4
> > > .LLM63:
> > > ldx [%fp+1999], %g1
> > > brz %g1, .LL33
> > > nop
> > > .LL32:
> > > .stabn 68,0,122,.LLM64-.LLFBB4
> > > .LLM64:
> > >
> > > g1 points to RTSignal_I3
> > >
> > > (gdb) x/i $pc
> > > 0x3ff0a8 : ldx [ %g1 ], %g1
> > > (gdb) x/i $g1
> > > 0x4021f4 : save %sp, -208, %sp
> > >
> > > I am willing to accept that a "function pointer" is a pair of
> > > pointers, or even three pointers.
> > > A pointer to code, a pointer to globals for position independent
> > > code, a frame pointer to locals.
> > > That equality comparison of function pointers requires comparing  
> two
> > > (or three) pointers.
> > > (Though the global pointer shouldn't need comparing.)
> > > At least for nested functions. Less so for non-nested. ?
> > > Much less for comparison to NIL. ?
> > >
> > > And either way, this code is reading bogus data.
> > > There isn't a pointer at the function address, there is code.
> > >
> > > Something doesn't add up.
> > >
> > > I'm going to try setting "aligned procedures" but that's quite  
> bogus
> > > I think.
> > >
> > > EqualExpr.m3 says
> > >
> > > Note: procedures pointers are always aligned!
> > >
> > > but maybe not?
> > >
> > > Yeah yeah I'm being lazy. I'll read more code..
> > >
> > > I also wonder if a "function pointer" can be optimized for the  
> case
> > > of not being to a nested function.
> > > It looks like calling a function pointer is very inefficient.
> > > It looks like..am I reading that correctly?.. that if the pointer
> > > points to -1, then it is nested and
> > > a pair of pointers, and not otherwise. That -1 is treated  
> specially
> > > as the first bytes of a function?
> > > Is that a Modula-3-ism or a SPARC-ism?
> > > It looks like a Modula-3-ism. And it seems dubious.
> > > But I'll have to read more..
> > >
> > > NT386GNU does the same sort of wrong looking thing:
> > >
> > > LFBB4:
> > > pushl %ebp
> > > movl %esp, %ebp
> > > subl $24, %esp
> > > LBB5:
> > > .stabn 68,0,117,LM60-LFBB4
> > > LM60:
> > > movl $0, -16(%ebp)
> > > .stabn 68,0,119,LM61-LFBB4
> > > LM61:
> > > movl 8(%ebp), %eax
> > > testl %eax, %eax
> > > je L26
> > > movl 8(%ebp), %eax
> > > movl (%eax), %eax BAD
> > > cmpl $-1, %eax BAD
> > > je L27
> > > L26:
> > > movl 8(%ebp), %eax
> > > testl %eax, %eax
> > > je L33
> > > L27:
> > > .stabn 68,0,120,LM62-LFBB4
> > > LM62:
> > >
> > >
> > > and NT386:
> > >
> > > 0:000> u
> > > cm3!RTLinker__AddUnit:
> > > 00607864 55 push ebp
> > > 00607865 8bec mov ebp,esp
> > > 00607867 81ec0c000000 sub esp,0Ch
> > > 0060786d 53 push ebx
> > > 0060786e 56 push esi
> > > 0060786f 57 push edi
> > > 00607870 c745fc00000000 mov dword ptr [ebp-4],0
> > > 00607877 837d0800 cmp dword ptr [ebp+8],0
> > > 0:000> u
> > > cm3!RTLinker__AddUnit+0x17:
> > > 0060787b 0f840f000000 je cm3!RTLinker__AddUnit+0x2c (00607890)
> > > 00607881 8b7508 mov esi,dword ptr [ebp+8]
> > > 00607884 8b5e00 mov ebx,dword ptr
> > > [esi] BAD
> > > 00607887 83fbff cmp
> > > ebx,0FFFFFFFFh BAD
> > > 0060788a 0f840f000000 je cm3!RTLinker__AddUnit+0x3b (0060789f)
> > > 00607890 837d0800 cmp dword ptr [ebp+8],0
> > > 00607894 0f8505000000 jne cm3!RTLinker__AddUnit+0x3b (0060789f)
> > > 0060789a e969000000 jmp cm3!RTLinker__AddUnit+0xa4 (00607908)
> > >
> > > cm3!RTLinker__AddUnit+0x20:
> > > 00607884 8b5e00 mov ebx,dword ptr [esi]
> > > ds:002b:0062c950=81ec8b55
> > > 0:000> u @esi
> > > cm3!RTLinker_I3:
> > > 0062c950 55 push ebp
> > > 0062c951 8bec mov ebp,esp
> > > 0062c953 81ec00000000 sub esp,0
> > > 0062c959 53 push ebx
> > > 0062c95a 56 push esi
> > > 0062c95b 57 push edi
> > > 0062c95c 837d0800 cmp dword ptr [ebp+8],0
> > > 0062c960 0f8400000000 je cm3!RTLinker_I3+0x16 (0062c966)
> > >
> > > This is just wrong.
> > > Comparing bytes of code to -1.
> > >
> > > I think the likely fix is for the "I3" code to be laid out as a
> > > "constant function pointer", a pointer to a pair of pointers where
> > > one points to the code and one is to -1. Something like that. That
> > > can't be quite correct given that the existing data is callable.
> > >
> > > - Jay
> >
> > --
> > -------------------------------------------------------------
> > Rodney M. Bates, retired assistant professor
> > Dept. of Computer Science, Wichita State University
> > Wichita, KS 67260-0083
> > 316-978-3922
> > rodney.bates at wichita.edu
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From hosking at cs.purdue.edu  Tue May 27 11:37:31 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 27 May 2008 10:37:31 +0100
Subject: [M3devel] gcc/m3cc/cm3c for OpenBSD?
In-Reply-To: 
References: 
Message-ID: <9B55DC75-DDBB-46F8-929F-2216922E39BE@cs.purdue.edu>



On May 19, 2008, at 1:47 PM, Jay wrote:

> What is the right way to handle these:
>  http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/gcc/4.3/patches/
> I imagine:
>  1) import them m3-sys/m3cc/src/patches/openbsd
>  2) perhaps use a vendor branch for the import
>    however they haven't changed in 14 months
>    and HOPEFULLY they get ported upstream

Best this so later vendor upgrades don't confuse them with M3-related  
changes.

>
>  3) apply patches at build time
>
> Seems kind of bad, but I figure also too much to manage to checkin  
> the patch results?
> I realize it stinks largely due to the risk of accidentally doing  
> what is avoided.
> Maybe there is like "VPATH" and the to-be-patched files can be  
> copied in the output
> directory and patched there?
>
>  They aren't all needed, by far, but definitely some of them are  
> needed.
>
>  not needed, roughly:
>     *objc*, *ada*, *lib*
>
>  needed, roughly:
>   *config*
>
>  unclear:
>   all the NULL to (void*) 0 diffs, which are a lot of it
>
>  I kinda'thunk:
>   #ifdef __cplusplus
>   #define NULL 0 /* would perhaps need patch, depending on what  
> calling conventions
>   do with parameters and return values smaller than a word */
>   #else
>   #define NULL ((void*) 0) /* no need for patch */
>   #endif
>
> in particular because in C++ a cast from void* to another* is  
> needed, but not in C.
>
> In fact I see this on OpenBSD:
>
>  #ifndef NULL
>  #ifdef  __GNUG__
>  #define NULL    __null
>  #else
>  #define NULL    0L
>  #endif
>
> Similar question for the AMD64_NT gcc patches, though these are  
> newer, apparently
> still need testing, and since they are new, more hope they will go  
> upstream.
> I don't know why the OpenBSD patches linger, I didn't ask.
>
> I'll proceed as my suggest takes but presumably won't be read to  
> commit
>   till after broader judgement/consensus rendered.
>
>   - Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Tue May 27 13:15:12 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 27 May 2008 11:15:12 +0000
Subject: [M3devel] gcc/m3cc/cm3c for OpenBSD?
In-Reply-To: <9B55DC75-DDBB-46F8-929F-2216922E39BE@cs.purdue.edu>
References: 
	<9B55DC75-DDBB-46F8-929F-2216922E39BE@cs.purdue.edu>
Message-ID: 

Tony, I'm not sure what your answer is below, but I commited #1  +#3.
 
 >> 1) import them m3-sys/m3cc/src/patches/openbsd >> 3) apply patches at build time
Obvious major danger with the current code is of accidentally commiting the patched files.
Perhaps something like copying files into the output and using VPATH can remove that danger.
Or perhaps if the accident occurs, it is easily undone? I don't know.
 
 >> 2) perhaps use a vendor branch for the import 
 
Could there be a vendor branch for "OpenBSD gcc" and then "mainline" is the merge of the various branches?
 
 
 - Jay


CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] gcc/m3cc/cm3c for OpenBSD?Date: Tue, 27 May 2008 10:37:31 +0100



On May 19, 2008, at 1:47 PM, Jay wrote:

What is the right way to handle these: http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/gcc/4.3/patches/I imagine: 1) import them m3-sys/m3cc/src/patches/openbsd 2) perhaps use a vendor branch for the import   however they haven't changed in 14 months   and HOPEFULLY they get ported upstream

Best this so later vendor upgrades don't confuse them with M3-related changes.

 3) apply patches at build timeSeems kind of bad, but I figure also too much to manage to checkin the patch results?I realize it stinks largely due to the risk of accidentally doing what is avoided.Maybe there is like "VPATH" and the to-be-patched files can be copied in the outputdirectory and patched there? They aren't all needed, by far, but definitely some of them are needed.  not needed, roughly:    *objc*, *ada*, *lib* needed, roughly:   *config*  unclear:  all the NULL to (void*) 0 diffs, which are a lot of it I kinda'thunk:  #ifdef __cplusplus  #define NULL 0 /* would perhaps need patch, depending on what calling conventions  do with parameters and return values smaller than a word */   #else  #define NULL ((void*) 0) /* no need for patch */   #endifin particular because in C++ a cast from void* to another* is needed, but not in C.In fact I see this on OpenBSD: #ifndef NULL #ifdef  __GNUG__ #define NULL    __null #else #define NULL    0L #endifSimilar question for the AMD64_NT gcc patches, though these are newer, apparentlystill need testing, and since they are new, more hope they will go upstream.I don't know why the OpenBSD patches linger, I didn't ask.I'll proceed as my suggest takes but presumably won't be read to commit  till after broader judgement/consensus rendered.  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Tue May 27 13:34:39 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 27 May 2008 11:34:39 +0000
Subject: [M3devel] function pointers and comparison to nil? mis-typed
 function pointers?
In-Reply-To: <7F087A94-FCF4-487C-8744-530F82B95F95@cs.purdue.edu>
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
	
	
	
	
	<7F087A94-FCF4-487C-8744-530F82B95F95@cs.purdue.edu>
Message-ID: 

gcc via the C front end does more -- it allows taking the address of a nested function, which generates code on the stack.
I have NOT looked at where the line is here between the C front end and the back end.
..but Ada and Pascal reportedly need this, and it is quite target-dependent, so presumably this is a back end feature.
Still, gcc's vaunted portability here is not clearly adequate consolation and merely shifting the work to it is not clearly a good move.
(besides the integrated backend and any hypothetical LLVM backend or C backend)
 
I was looking into this stuff because calling the module binders in RTLinker.m3 on SPARC64_OPENBSD hit an alignment fault, because SPARC64 instructions are 32bits and 32bit aligned (I guess) but SPARC64 integers are 64bits (definitely) and 64bit aligned (guess), and therefore the code to sniffs for the -1 faults. I'm well past this. The fix is simply to mark in Target.m3 procedures as not aligned and then the check for the -1 marker is preceded by a check of the alignment of the pointer, and unaligned pointers are presumed to not be closures.
 
I'd love to be able to say "This area is obviously messed up and it should be done such and such a way.", but the first is true and the second doesn't exist. Oh well.
My perfectionist and fixy/churny streak can only muster "I wonder how -1 decodes on various architectures and if more reliable per-target markers can be formulated.." esp. something that doesn't depend on invalid encodings, which could be reclaimed in the future for some new instrutions, but perhaps instead relies on valid encodings that would "never" be at the start of a function..though it is pretty hard to rule out anything -- maybe a jmp to 0? I realize that load/store instruction sets can't even necessarily encode that.
Nope -- x86 encodes jmps as PC-relative.
Ok -- indirect call:
 
7c901230 ff1500000000    call    dword ptr ds:[0]7c901236 0f84c4ed6f83    je      00000000
 
so ff 15 00 00 00 00 may be a better marker of "not code" than ff ff ff ff, on x86, maybe.
 
You know -1 may not be legal today, but it could be become legal in the future..
Whereas *arguably* call indirect 0 is "legal" today, so would not change meaning, but "never" occurs, so could be a marker, for some definition of "legal", "never", etc....
 
 - Jay


CC: rodney.bates at wichita.edu; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?Date: Tue, 27 May 2008 09:48:37 +0100gcc just allows computation of the static link.

I think there is an alternate compilation mode supported by the front-end for other platforms (like the integrated back end) but I have not looked at that closely.





On May 26, 2008, at 8:45 PM, Jay wrote:

It stinks either way imho.The portability is handled, somehow or another, by gcc's support for nested functions.For example on OpenBSD, they call mprotect to make the trampoline executable -- expensive! and leaves a bit of a security hole.On Linux you can sometimes mark the .exe as needing an executable stack or not. Similarly on Windows, linker has /nxcompat, /nxcompat:no switch.ATL on Windows puts trampolines in the heap and specifically makes them executable -- since the heap isn't necessarily executable either.The -1 marker is also a bit of a portability problem but I guess in practise it works out.I'd be curious to see how it decodes on various processors.  - Jay


CC: rodney.bates at wichita.edu; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?Date: Mon, 26 May 2008 14:38:53 +0100

Moving away from the current implementation would be a portability disaster because of the fact that gcc requires an executable stack for its nested function implementation which is non-portable.

On May 26, 2008, at 11:04 AM, Jay wrote:

Cygwin gcc clearly generates code on the stack for nested functions.And then search the web..that's how it works in general.Nested functions have been deprecated on Mac OS X, in anticipation of possibly making the stack not executable. OpenBSD doesn't allow execution on the stack.They use mprotect to let trampolines run:  http://gcc.gnu.org/ml/gcc/2004-01/msg00742.html and  http://resin.csoft.net/cgi-bin/man.cgi?section=1&topic=gcc-local  Even though nested functions are a gcc extension to the C language, email threads out there discuss Ada, Pascal, and even ! Modula-3 as having nested functions, and that therefore deprecating the C language feature doesn't "solve" the "problem". I remain uncertain what, if anything, to do here. - keep the -1 hack, do nothing     generalize it slightly to let targets pick "better" markers  - use gcc's supported for nested functions    (plus the integrated backend, not difficult)  Clearly this is a dilemna to more than just me. :)  - Jay


From: jayk123 at hotmail.comTo: rodney.bates at wichita.edu; m3devel at elegosoft.comDate: Mon, 26 May 2008 05:26:41 +0000Subject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?Rodney, this agrees with much of what I figured out and guessed. I did not think of or look into some of what you point out though:  - what gcc's nested functions look like, and if you can take the address, and what that does   - calling Modula-3 nested functions as callbacks from C  Now, regarding trampolines.I alluded to them. It should be easy enough to generate them, and this would solve a few problems, but I believe also bring up a new big problem.Generating trampolines solves at least two problems:  - it allows Modula-3 nested function pointers ("closures") to be called from C  - it enables removing the check for -1  I contend that the check for -1 is not good. It is a somewhat risky assumption, that "-1" is not valid code.You do bring up a nice mitigation -- the assumption that it doesn't begin any functions, which is much narrower than it being valid code anywhere. For SPARC64_OPENBSD I figured out what the original authors meant to be the fix.You declare functions as not aligned, leading to the check for -1 first checking alignment (bigger code).Any pointer not aligned on an integer-sized address is presumed not a closure and not checked for the -1.This lets SPARC64_OPENBSD get further. Both it and PPC32_OPENBSD now for some reason suffer from an inability to heap allocate anything, failing around the attempt to create a new thread like in RTAllocator_M or so. I'll look into this more later.Now, the problem of trampolines..I consider the platform-dependent-ness to be surmountable.But where do you put the generated code? Putting it on the stack is counter to modern (and possibly old) "security" mechanisms.The stack is not generally executable, and even when it is, best just not do use that imho. That means, potentially/obviously, the need to heap allocate executable memory, for very small short lived data, quite inefficient. Is there some other way/place to produce trampolines, efficiently? In the absence of any good solution, I have to resign myself to assuming that -1 isn't the valid start of a function, and perhaps moving the marker into Target.i3, Target.m3 so that "more obvious" values get chosen. Like a breakpoint. Or "an epilogue", or "a trap instruction". I realize this needs details and is easily seen as "wrong". In particular, a function that does nothing could be termed as only having an "an epilogue". I know that other systems are "forced" to create "trampolines" so I should look into how they do that.I know that ATL, a Windows-specific library, is forced to heap allocate small executable chunks of memory and uses an efficient cache to optimize it. I do find this dependence on -1 not being the valid start of a function rather sleazy and at risk of being wrong.  - Jay

> Date: Sun, 25 May 2008 22:50:15 -0500> From: rodney.bates at wichita.edu> To: m3devel at elegosoft.com> Subject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?> > I think I can shed some light on this, having spent some time making> m3gdb handle the various operations on nested procedures. As for code> that mixes M3 and C, I believe the following are true:> > - Within M3 code only, the closure system works correctly in all cases.> This answers one of Jay's worries.> > - For values of M3 procedure/C function pointer that are top-level> (nonnested) procedures/functions, M3 and C code (generated by gcc,> at least) are interchangeable. This answers another of Jay's worries.> This will cover that great majority of cases.> > - Standard C has no nested functions. Gcc adds them as a language> extension. Thus, only in gcc-compiled C code do we need to worry> about nested procedures/functions between languages. (Do any other> C compilers exist that also have nested functions?)> > - M3 code should be able to call the value of a procedure variable> that was originally produced by C code as a pointer to a nested> function, and get the environment set up right, so its nonlocal> variable references will work, _if_ the nested function's> environment has not disappeared. This partially answers another> of Jay's worries. But:> > - M3's normal runtime check that precludes assigning a nonlocal> procedure value will not detect a C-code-produced nonlocal value,> thus the environment could indeed have disappeared if the programmer> was not careful. However, gcc-extended C's nested functions have> no protection against this bug when only C code is involved, so> perhaps not detecting it in mixed M3/C is to be expected.> > - C code that attempts to call a function pointer value that was> originally produced by M3 code as a nested procedure value will> almost certainly crash at the time of the call. This is the only> case that presents a significant problem. M3 code will not be> able to give a nested procedure as a callback to a C library.> > M3's mechanism: A value of procedure type is a pointer to either> 1) the first byte of the procedure's machine code, if it is top level, or> 2) A closure.> > A closure is a block of 3 words. The first word contains -1. Assuming> a word of all one bits is not valid machine code on any target machine> (or at least doesn't occur as the first code of any procedure), this can> be used at runtime to detect that this is indeed a closure and not code.> The remaining two words hold the code address and the environment address.> > So, an assignment of a procedure value has to check that it is not a closure,> and raise a runtime error if it is. A call on a procedure value has to check,> and if it is a closure, load/copy its environment pointer value into wherever> the calling convention expects it, then branch to the code address. Passing> a nested procedure constant as a parameter involves constructing a closure for> it and passing its address.> > gcc-C's mechanism: A value of type pointer to function is a pointer to either> 1) the first byte of the function's machine code, if it is top level,> (the same as with M3), or> 2) A trampoline.> > A trampoline is a bit of code that loads/copies an environment pointer (hard> coded into the trampoline) and then branches to the function code.> > Trampolines probably have a small constant-time speed advantage for _calls_,> but would be slower for some of the other operations, and the runtime check> could be tricky. Probably it could be fooled into failing when it shouldn't.> Moreover, trampolines are highly target-machine-dependent. Switching to them> would create a really big problem for m3gdb, which would have to have> different code for each target for each of the nested procedure operations.> > Jay wrote:> > I see somewhat.> > It's stuff around "closure".> > The comparison of code bytes to -1 comes from If_closure for example.> > > > The problem is presumably to come up with a unified representation of > > pointers to functions that may or may not be nested, while avoiding > > runtime codegen, even just a little bit, and for Modula-3 and C function > > pointers to use the same representation.> > I don't think the present solution is really valid, and I am skeptical > > that there is a solution.> > One of the requirements has to be dropped.> > Sniffing code bytes and trying to decide if they are code or not as > > appears to currently happen is bogus.> > > > I think the solution is to remove the requirement that a Modula-3 > > function pointer and a C function pointer are the same.> > Except, well, that probably doesn't work -- it means you need two types > > of function pointers.> > > > Darn this is a hard problem.> > > > The runtime codegen required can be exceedingly simple, fast, and small > > IF it were allowed to be on the stack. But that's a killer these days.> > > > I think you have to give up unification of "closures" and "function > > pointers".> > If you take the address of a nested function and call it, you cannot > > access the locals of the enclosing scopes.> > So in affect, you end up with "two types of function pointers".> > Regular stateless ones and "closures" with some captured state.> > > > Thoughts?> > > > I'm kind of stumped. It's a desirable problem to solve, and there is a > > purported solution in place, but the solution that is there is > > completely bogus, despite appearing to work for a long time, and there > > is no solution. That is my understanding. I could be wrong on any number > > of points but I'm pretty sure.> > > > I think you have to separate out function pointers and closures.> > Sniffing what it pointed to is dubous esp. as currently implemented.> > If this is really the way to go, then signature bytes need to be worked > > out for all architectures that are guaranteed to not look like code.> > Or vice versa -- signature bytes worked out that all functions start > > with, which is viable for Modula-3 but not for interop with C.> > Currently -1 is used, of pointer-size.> > That appears to be reasonable for x86:> > > > 0:000> eb . ff ff ff ff> > 0:000> u .> > ntdll32!DbgBreakPoint:> > 7d61002d ff ???> > 7d61002e ff ???> > 7d61002f ff ???> > 7d610030 ffc3 inc ebx> > > > but the instruction encodings or disassembly on other architectures > > would have to be checked.> > > > - Jay> > > > ------------------------------------------------------------------------> > From: jayk123 at hotmail.com> > To: m3devel at elegosoft.com> > Date: Sun, 25 May 2008 00:16:01 +0000> > Subject: [M3devel] function pointers and comparison to nil?> > mis-typed function pointers?> > > > I'm being lazy...> > > > Tony can you explain this stuff?> > > > Comparison of function pointers..> > What are the various representations and rules?> > > > What does it mean to compare nested functions?> > > > What does it mean to compare a function to NIL?> > > > I'll poke around more.> > > > What I am seeing is that comparison of function pointers to NIL is> > surprisingly> > expensive, and probably somewhat buggy. Or at least some of the runtime> > generated "metadata-ish" stuff is produced or typed incorrectly.> > > > In particular, RTLinker.m3:> > > > PROCEDURE AddUnit (b: RT0.Binder) => > VAR m: RT0.ModulePtr;> > BEGIN> > IF (b = NIL) THEN RETURN END; line 119> > m := b(0); line 120> > IF (m = NIL) THEN RETURN END; line 121> > AddUnitI(m); line 122> > END AddUnit;> > > > generates a lot of code, just for the first line:> > (556) set_source_line > > source line 119 > > (557) load > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb > > (558) load_nil > > (559) if_eq > > (560) load > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb > > (561) load_indirect > > load address offset 0x0 src_t 0x5 dst_t 0x5 > > (562) load_integer > > integer n_bytes 0x0 hi 0x0 low 0x1 sign -1 > > (563) if_eq > > (564) set_label > > (565) load_nil > > (566) load > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb > > (567) if_ne > > (568) set_label > > (569) exit_proc > > (570) set_label > > (571) set_source_line > > source line 120 > > > > The details on the load_integer trace might not be completely> > correct. I will test a fix shortly.> > Esp. that n_bytes gets decremented to zero before the trace.> > > > Ok, I see now why some of the bloat -- because the "then return end"> > is on the same line.> > If it were written as:> > if (b = NIL THEN > > return> > end > > It probably wouldn't look so bad. That took me a while to realize.> > > > The following is generated for SPARC64_OPENBSD:> > > > line 119> > .stabn 68,0,119,.LLM61-.LLFBB4> > .LLM61:> > ldx [%fp+2175], %g1> > brz %g1, .LL26> > nop> > ldx [%fp+2175], %g1> > ldx [%g1], %g1 bus error here? yes, probably this one> > cmp %g1, -1> > be %xcc, .LL27> > nop> > .LL26:> > ldx [%fp+2175], %g1> > brz %g1, .LL33> > nop> > .LL27:> > line 120> > .stabn 68,0,120,.LLM62-.LLFBB4> > .LLM62:> > ldx [%fp+2175], %g1> > stx %g1, [%fp+2007]> > ldx [%fp+2007], %g1> > brz %g1, .LL30> > nop> > ldx [%fp+2007], %g1> > ldx [%g1], %g1 or here ?> > cmp %g1, -1> > bne %xcc, .LL30> > nop> > ldx [%fp+2007], %g1> > add %g1, 16, %g1> > ldx [%g1], %g1 or here?> > stx %g1, [%fp+2015]> > ldx [%fp+2007], %g1> > add %g1, 8, %g1> > ldx [%g1], %g1> > stx %g1, [%fp+2007]> > .LL30:> > ldx [%fp+2007], %g1> > ldx [%fp+2015], %g5> > mov 0, %o0> > call %g1, 0> > nop> > mov %o0, %g1> > stx %g1, [%fp+2023]> > ldx [%fp+2023], %g1> > stx %g1, [%fp+1999]> > > > line 121> > > > .stabn 68,0,121,.LLM63-.LLFBB4> > .LLM63:> > ldx [%fp+1999], %g1> > brz %g1, .LL33> > nop> > .LL32:> > .stabn 68,0,122,.LLM64-.LLFBB4> > .LLM64:> > > > g1 points to RTSignal_I3> > > > (gdb) x/i $pc> > 0x3ff0a8 : ldx [ %g1 ], %g1> > (gdb) x/i $g1> > 0x4021f4 : save %sp, -208, %sp> > > > I am willing to accept that a "function pointer" is a pair of> > pointers, or even three pointers.> > A pointer to code, a pointer to globals for position independent> > code, a frame pointer to locals.> > That equality comparison of function pointers requires comparing two> > (or three) pointers.> > (Though the global pointer shouldn't need comparing.)> > At least for nested functions. Less so for non-nested. ?> > Much less for comparison to NIL. ?> > > > And either way, this code is reading bogus data.> > There isn't a pointer at the function address, there is code.> > > > Something doesn't add up.> > > > I'm going to try setting "aligned procedures" but that's quite bogus> > I think.> > > > EqualExpr.m3 says> > > > Note: procedures pointers are always aligned!> > > > but maybe not?> > > > Yeah yeah I'm being lazy. I'll read more code..> > > > I also wonder if a "function pointer" can be optimized for the case> > of not being to a nested function.> > It looks like calling a function pointer is very inefficient.> > It looks like..am I reading that correctly?.. that if the pointer> > points to -1, then it is nested and> > a pair of pointers, and not otherwise. That -1 is treated specially> > as the first bytes of a function?> > Is that a Modula-3-ism or a SPARC-ism?> > It looks like a Modula-3-ism. And it seems dubious.> > But I'll have to read more..> > > > NT386GNU does the same sort of wrong looking thing:> > > > LFBB4:> > pushl %ebp> > movl %esp, %ebp> > subl $24, %esp> > LBB5:> > .stabn 68,0,117,LM60-LFBB4> > LM60:> > movl $0, -16(%ebp)> > .stabn 68,0,119,LM61-LFBB4> > LM61:> > movl 8(%ebp), %eax> > testl %eax, %eax> > je L26> > movl 8(%ebp), %eax> > movl (%eax), %eax BAD> > cmpl $-1, %eax BAD> > je L27> > L26:> > movl 8(%ebp), %eax> > testl %eax, %eax> > je L33> > L27:> > .stabn 68,0,120,LM62-LFBB4> > LM62:> > > > > > and NT386:> > > > 0:000> u> > cm3!RTLinker__AddUnit:> > 00607864 55 push ebp> > 00607865 8bec mov ebp,esp> > 00607867 81ec0c000000 sub esp,0Ch> > 0060786d 53 push ebx> > 0060786e 56 push esi> > 0060786f 57 push edi> > 00607870 c745fc00000000 mov dword ptr [ebp-4],0> > 00607877 837d0800 cmp dword ptr [ebp+8],0> > 0:000> u> > cm3!RTLinker__AddUnit+0x17:> > 0060787b 0f840f000000 je cm3!RTLinker__AddUnit+0x2c (00607890)> > 00607881 8b7508 mov esi,dword ptr [ebp+8]> > 00607884 8b5e00 mov ebx,dword ptr> > [esi] BAD > > 00607887 83fbff cmp > > ebx,0FFFFFFFFh BAD> > 0060788a 0f840f000000 je cm3!RTLinker__AddUnit+0x3b (0060789f)> > 00607890 837d0800 cmp dword ptr [ebp+8],0> > 00607894 0f8505000000 jne cm3!RTLinker__AddUnit+0x3b (0060789f)> > 0060789a e969000000 jmp cm3!RTLinker__AddUnit+0xa4 (00607908)> > > > cm3!RTLinker__AddUnit+0x20:> > 00607884 8b5e00 mov ebx,dword ptr [esi] > > ds:002b:0062c950=81ec8b55> > 0:000> u @esi> > cm3!RTLinker_I3:> > 0062c950 55 push ebp> > 0062c951 8bec mov ebp,esp> > 0062c953 81ec00000000 sub esp,0> > 0062c959 53 push ebx> > 0062c95a 56 push esi> > 0062c95b 57 push edi> > 0062c95c 837d0800 cmp dword ptr [ebp+8],0> > 0062c960 0f8400000000 je cm3!RTLinker_I3+0x16 (0062c966)> > > > This is just wrong.> > Comparing bytes of code to -1.> > > > I think the likely fix is for the "I3" code to be laid out as a> > "constant function pointer", a pointer to a pair of pointers where> > one points to the code and one is to -1. Something like that. That> > can't be quite correct given that the existing data is callable.> > > > - Jay> > -- > -------------------------------------------------------------> Rodney M. Bates, retired assistant professor> Dept. of Computer Science, Wichita State University> Wichita, KS 67260-0083> 316-978-3922> rodney.bates at wichita.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From wagner at elegosoft.com  Tue May 27 14:44:52 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 27 May 2008 14:44:52 +0200
Subject: [M3devel] gcc/m3cc/cm3c for OpenBSD?
In-Reply-To: 
References: 
	<9B55DC75-DDBB-46F8-929F-2216922E39BE@cs.purdue.edu>
	
Message-ID: <20080527144452.f6j8bolwgksw0wsc@mail.elegosoft.com>

Quoting Jay :

> Tony, I'm not sure what your answer is below, but I commited #1  +#3.
>
>  >> 1) import them m3-sys/m3cc/src/patches/openbsd >> 3) apply   
> patches at build time
> Obvious major danger with the current code is of accidentally   
> commiting the patched files.
> Perhaps something like copying files into the output and using VPATH  
>  can remove that danger.
> Or perhaps if the accident occurs, it is easily undone? I don't know.
>
>  >> 2) perhaps use a vendor branch for the import
>
> Could there be a vendor branch for "OpenBSD gcc" and then "mainline"  
>  is the merge of the various branches?

CVS does only really support _one_ vendor branch, even if some
docs say otherwise. So if the original gcc sources are on a vendor
branch, openbsd changes for examples should be imported on another
branch, and then explicitly merged (vendor branch is merged implicitly,
which is arguably a feature or a bug ;-)

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  Tue May 27 15:59:26 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 27 May 2008 15:59:26 +0200
Subject: [M3devel] FW: NT386 environment variables (new NT386	snapshots)
In-Reply-To: 
References: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
	
	<4823279D.1E75.00D7.1@scires.com>
	
Message-ID: <20080527155926.203bam89w4w0kgko@mail.elegosoft.com>

Quoting Jay :

> truncated again...
> m3support -- nothing interesting in any logs regarding my mail?
> And nobody else uses hotmail, right?

@Ronny, can you please check if our mail logs reveal any reason
for Jay's mails to be truncated now and then?

>> I will apply an easy fix.
> done

I'm not sure if this means that the issues concerning evnironment
variable access (both via Env and RTArgs) are now fixed for NT386(GNU)...
Can we forget about this issue?

Olaf

> From: jayk123 at hotmail.comTo: rcoleburn at scires.com;   
> m3devel at elegosoft.comSubject: RE: [M3devel] NT386 environment   
> variables (new NT386 snapshots)Date: Fri, 9 May 2008 07:44:09 +0000
>
>
>  > these problems (pixmaps, buildstandalone, environ vars, serial   
> i/o, etc...  Ok, here is the story with environment variables.I   
> tested 3.6 and current, gui and console.This is the   
> program:C:\dev2\j\m3\3>type src\m3makefileimport ("m3core")import   
> ("libm3")m3_option ("-gui")     twiddle this line in and out with a   
> commentimplementation ("Main")program ("pgm") C:\dev2\j\m3\3>type   
> src\Main.m3MODULE Main;IMPORT IO;IMPORT RTArgs; BEGIN(* IO.Put just   
> crashes in 3.6 gui apps *)  IO.Put(RTArgs.GetArg(2));    
> IO.Put(RTArgs.GetEnv(2)); (* use this for gui apps *)  EVAL   
> RTArgs.GetArg(2);  EVAL RTArgs.GetEnv(2);END Main.In 3.6 console   
> apps, RTArgs.GetEnv returns garbage. That makes sense from the   
> code.In current console apps, GetEnv works.In current gui apps,   
> GetEnv access violates, or returns an invalid pointer.  This also   
> makes sense from the code.Randy, does this actually work for you?I'd  
>  be quite surprised.I haven't tried 4.1 yet, just 3.6 and current.I   
> will apply an easy fix. - Jay
>
>
> Date: Thu, 8 May 2008 16:17:37 -0400From: rcoleburn at scires.comTo:   
> m3devel at elegosoft.comSubject: Re: [M3devel] new NT386 snapshots
> Jay:
>
> I have both console and gui programs built using 4.1 that do pull   
> stuff out of the environment.  I've not noticed any problems with   
> either mode.
>
> From my perspective, the old 4.1 seems more reliable than the   
> current system in a number of respects.  I have a new project with a  
>  hard deadline that I would like to use the new cm3 system for, but   
> until these problems (pixmaps, buildstandalone, environ vars, serial  
>  i/o, etc.) can be resolved, I'm going to keep using 4.1 for my   
> production work.
>
> Regards,
> Randy>>> Jay  5/8/2008 2:46 PM   
> >>>http://modula3.elegosoft.com/cm3/uploaded-archives/   
> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0.ziphttp://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-WIN32-NT386-d5.7.0.ziphttp://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0-symbols.zip These should have:  latest quake extensions   set relation fixes   other set fixes revealed through dynamic linking of one regression test   hypothetical ability to cross-build to AMD64_LINUX, AMD64_DARWIN    one jmpbuf size for all NT386 configurations (NT386, NT386GNU, NT386MINGNU)  Built with Visual C++ 9.0 Express, so you'll want:http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en  Still more work to do though, e.g. assertion failures in unit tests, pixmap.. Fuller disclosure:Something is leaking memory on my system such that "everything" starts "failing" and I have to reboot.This isn't Modula-3 related.Hopefully these files aren't damaged as a result.Must be some buggy driver or something.. Aside: The environment variable thingy has been bugging me a long time and I finally looked deeper at it.It appears broken in CM3 4.x. I didn't check 3.x yet.I'm still mulling a fix, and haven't run a repro of the break, but it's not a big deal either way.Basically console apps use main that takes char** and gui apps use WinMain that doesn't get environment variables but the generated code calls GetEvironmentStrings() which returns null separated strings.Must be that hardly anyone uses environment variables in Modula-3 on Win32 for this to have lingered so long, at least gui apps.  -   
> 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 hosking at cs.purdue.edu  Tue May 27 15:56:51 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 27 May 2008 14:56:51 +0100
Subject: [M3devel] function pointers and comparison to nil? mis-typed
	function pointers?
In-Reply-To: 
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
	
	
	
	
	<7F087A94-FCF4-487C-8744-530F82B95F95@cs.purdue.edu>
	
Message-ID: <551F22B1-0098-4828-A91B-3FD4E368231A@cs.purdue.edu>

On May 27, 2008, at 12:34 PM, Jay wrote:

> gcc via the C front end does more -- it allows taking the address of  
> a nested function, which generates code on the stack.
> I have NOT looked at where the line is here between the C front end  
> and the back end.
> ..but Ada and Pascal reportedly need this, and it is quite target- 
> dependent, so presumably this is a back end feature.
> Still, gcc's vaunted portability here is not clearly adequate  
> consolation and merely shifting the work to it is not clearly a good  
> move.
> (besides the integrated backend and any hypothetical LLVM backend or  
> C backend)

True, but it is deprecated and doesn't work on all platforms because  
of stack non-executability.  We compute the static chain using gcc's  
support as it is (with hacks to avoid computation of a function  
pointer via trampoline).

> I was looking into this stuff because calling the module binders in  
> RTLinker.m3 on SPARC64_OPENBSD hit an alignment fault, because  
> SPARC64 instructions are 32bits and 32bit aligned (I guess) but  
> SPARC64 integers are 64bits (definitely) and 64bit aligned (guess),  
> and therefore the code to sniffs for the -1 faults. I'm well past  
> this. The fix is simply to mark in Target.m3 procedures as not  
> aligned and then the check for the -1 marker is preceded by a check  
> of the alignment of the pointer, and unaligned pointers are presumed  
> to not be closures.

OK.

> I'd love to be able to say "This area is obviously messed up and it  
> should be done such and such a way.", but the first is true and the  
> second doesn't exist. Oh well.
> My perfectionist and fixy/churny streak can only muster "I wonder  
> how -1 decodes on various architectures and if more reliable per- 
> target markers can be formulated.." esp. something that doesn't  
> depend on invalid encodings, which could be reclaimed in the future  
> for some new instrutions, but perhaps instead relies on valid  
> encodings that would "never" be at the start of a function..though  
> it is pretty hard to rule out anything -- maybe a jmp to 0? I  
> realize that load/store instruction sets can't even necessarily  
> encode that.
> Nope -- x86 encodes jmps as PC-relative.
> Ok -- indirect call:
>
> 7c901230 ff1500000000    call    dword ptr ds:[0]
> 7c901236 0f84c4ed6f83    je      00000000
>
> so ff 15 00 00 00 00 may be a better marker of "not code" than ff ff  
> ff ff, on x86, maybe.
>
> You know -1 may not be legal today, but it could be become legal in  
> the future..
> Whereas *arguably* call indirect 0 is "legal" today, so would not  
> change meaning, but "never" occurs, so could be a marker, for some  
> definition of "legal", "never", etc....
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From hendrik at topoi.pooq.com  Tue May 27 17:45:51 2008
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Tue, 27 May 2008 11:45:51 -0400
Subject: [M3devel] function pointers and comparison to nil? mis-typed
	function pointers?
In-Reply-To: <483A3377.7070801@wichita.edu>
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
Message-ID: <20080527154551.GA24415@topoi.pooq.com>

On Sun, May 25, 2008 at 10:50:15PM -0500, Rodney M. Bates wrote:
> I think I can shed some light on this, having spent some time making
> m3gdb handle the various operations on nested procedures.  As for code
> that mixes M3 and C, I believe the following are true:
> 
> - Within M3 code only, the closure system works correctly in all cases.
>   This answers one of Jay's worries.

As long as procedure-entry code can be guaranteed never to start wit a 
word of one-bits.  We do have some influence on this code, though, and 
if necessary might be able to choose a different bit pattern on a 
specific platform.

> 
> - For values of M3 procedure/C function pointer that are top-level
>   (nonnested) procedures/functions, M3 and C code (generated by gcc,
>   at least) are interchangeable.  This answers another of Jay's worries.
>   This will cover that great majority of cases.

Yes.  And in many cases, we will know statically that this is the case.

> 
> - Standard C has no nested functions.  Gcc adds them as a language
>   extension.  Thus, only in gcc-compiled C code do we need to worry
>   about nested procedures/functions between languages.  (Do any other
>   C compilers exist that also have nested functions?)

Standard C has no nested function, and does not need closures.  As a 
result, Standard C can use simple pointers to represent function 
addresses.  The language extension retrofits closures using run-time 
code generation.  The way this is done (on the satck) is nonportable, 
and we'd like to avoid that nonportability.

The problem with seems to be just that you seem to want to use an 
address of a function as a function pointer, and that just doesn't have 
enough space in it to represent a closure.

But why do it that way?  Why not just let *all* Modula 3 functions be 
represented by closures?  Then you never have to test whether something 
is a closure, it just always is.  Top-level functions with no 
environment just use a null pointer as environment -- and never use it.

The only arguments for not doing this would seem to be 
(a) the waste of space, making functions a little larger than necessary, 
(b) and C compatibility.

Now (a) is probably a nonissue, since the vast majority of functions 
never have their addresses taken, are never passes as parameters to 
other procedures, and so forth.  So for the vast majority of functions, 
you simply never have to build the closure.

(b) might be a problem. The obvious trick is just to forbid passing to C 
a non-top-level function.  Since even the C programmers who devise 
interfaces with callbacks realise that just a functino pointer isn't 
enough, they usually provide a machanism for passing a void pointer to 
additional information the callback might need.  Nothing here puts 
Modula 3 at a disadvantage relative to C.  You can just use a top-level 
function and let the programmer provide it with whatever it needs.

But if it is deemed essential to provide actual single-pointer callback 
addresses, this can be done by using a built-in function to convert a 
procedure to a single-pointer callback.  This functin will have to be 
rewritten for each platform, and can allocate the necessary 
dynamically-genereated code on the heap (or, of course, on the stack, if 
possible on that platform).  As for portability, it's certianly no 
big deal to do this;  compared with writing a platform-dependent code 
generator (itself a requirement), this is not huge.

> - M3's normal runtime check that precludes assigning a nonlocal
>   procedure value will not detect a C-code-produced nonlocal value,
>   thus the environment could indeed have disappeared if the programmer
>   was not careful.  However, gcc-extended C's nested functions have
>   no protection against this bug when only C code is involved, so
>   perhaps not detecting it in mixed M3/C is to be expected.

We really can't protect against bugs in C code.  If we could prevent 
bugs in C, the market for it would be huge, and we'd be well advised to 
consider that our main business.

> 
> - C code that attempts to call a function pointer value that was
>   originally produced by M3 code as a nested procedure value will
>   almost certainly crash at the time of the call.  This is the only
>   case that presents a significant problem.  M3 code will not be
>   able to give a nested procedure as a callback to a C library.

Wherefor only in this case should we do run-time code generation.

It has been argued that we don't need to protect against C programmers 
going hog-wild and breaking their own code.  Such is the nature of C.

But, we can chack for some of it, it we are willing to go to the effort.  
The technique used in the CDC Algol 68 compiler long ago might even 
enable us to restrict the constraint on assigning nested procedures to 
variables by a suitable run-time check.

The CDC Algol 68 compiler had a trick for recognising expired scopes 
using the garbage collector.  Let's see if I can remember the details.  
It involved special treatment for procedures whose addresses are taken, 
and for the blocks that contain them.  When entering such a block at 
run-time, a word is allocated on the heap representing that scope.   It 
is filled with something relevant, such as the address if the stack 
frame for the block, and the stack frame also pointed to that scope-cell 
(as I'll describe it).  Taking the  address of a procedure involved 
building a closure that points to that scope-cell.  When leaving the 
block, the contents of the scope-cell is wiped to some recognisable 
invalid value.  When entering the procedure the scope-cell will 
still be around even if the scope is not.  The procedure (this is inside 
the procedure itself, not at the call) checks that the scope-cell has 
not been wiped, and therefore is still valid.  If valid, it contains the 
necessary environment information.  If not, break off execution.

-- hendrik


From dabenavidesd at yahoo.es  Wed May 28 04:10:05 2008
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 28 May 2008 02:10:05 +0000 (GMT)
Subject: [M3devel] garbage collection problem on LINUXLIBC6?
In-Reply-To: <406663.93255.qm@web27103.mail.ukl.yahoo.com>
Message-ID: <540006.79045.qm@web27102.mail.ukl.yahoo.com>

Dear developers:
I have finally understood that the issue was related with the terminal emulator from which I launched the M3 executables. All M3 executables are fine and working well.
Thanks for your attention.

--- 24/5/08, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> wrote:
De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] garbage collection problem on LINUXLIBC6?
Para: m3devel at elegosoft.com
Fecha: s?bado, 24 mayo, 2008 12:29

Hi:
I recently have compiled the cm3 system with good results on a 2-core machine on LINUXLIBC6, kubuntu of 32 bits. It runs gui applications of cm3 with no problems at all.
I think maybe the issue is related with something about the operating system, or at least the machine, I didn't check this until now.

Thanks

--- 19/5/08, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> wrote:
De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] garbage collection problem on LINUXLIBC6?
Para: m3devel at elegosoft.com, "Randy Coleburn"
 <rcoleburn at scires.com>
Fecha: lunes, 19 mayo, 2008 12:02

Hi again:
and the process is using the cpu very much (using top command)

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 9758 daniel    20   0 33644 3836 2684 R 60.0  0.7   1:05.17 draw

Thanks in advance.


--- 19/5/08, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> wrote:
De: Daniel Alejandro
 Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] garbage collection problem on LINUXLIBC6?
Para: m3devel at elegosoft.com, "Randy Coleburn" <rcoleburn at scires.com>
Fecha: lunes, 19 mayo, 2008 11:52

Hi Randy:
In my case, the program just doesn't start, maybe after some minutes yes, but obviously this is abnormal.
When I start mentor @M3tracelinker, I got after a lot of output the following lines and it just doesn't start after it:
  ../src/color/Color.i3(3)
  ../src/runtime/common/RTHooks.i3(3)
RunMainBody: exec: ../src/color/ColorNameTable.i3(3)
RunMainBody: exec: ../src/color/ColorNameF.i3(3)
RunMainBody: exec:
 ../src/color/ColorNa

But if I put @M3nogc @M3tracelinker the program starts and the output is:
RunMainBody: ../LINUXLIBC6/MentorBundle.m3(2)
  ../LINUXLIBC6/MentorBundle.i3(5)
  ../src/rw/TextWr.i3(3)
  ../src/rw/Wr.i3(3)
 
 ../src/thread/Common/Thread.i3(3)
  ../src/text/Text.i3(3)
  ../src/bundleintf/BundleRep.i3(3)
  ../src/bundleintf/Bundle.i3(3)
 
 ../src/runtime/common/RTHooks.i3(3)
RunMainBody: exec: ../LINUXLIBC6/MentorBundle.m3(3)
RunMainBody: exec: ../LINUXLIBC6/MentorBundle.i3(3)
RunMainBody: exec: ../src/Main.m3(3)

However when examining a simple gui program, the stdout shows the same  out for @M3tracelinker with or without garbage collection

  ../src/split/TextVBT.i3(5)
  ../src/runtime/common/RTHooks.i3(3)
RunMainBody: exec: ../src/split/TextVBTClass.i3(3)
RunMainBody: exec: ../src/split/TextVBT.m3(3)
RunMainBody: exec: ../src/split/TextVBT.i3(3)
RunMainBody: exec: ../src/Draw.m3(3)

If I run the program under m3gdb without parametres, breaking on RTLinker.RunMainBody, I got:
Breakpoint 3, RunMainBody (m=16_b7e108c0)
    at ../src/runtime/common/RTLinker.m3:349
349       VAR desc, desc2: InitPtr;  imp: RT0.ImportPtr;  m2:
 RT0.ModulePtr;
(m3gdb)
Continuando.

Breakpoint 3, RunMainBody (m=16_b7e10ba0)
    at ../src/runtime/common/RTLinker.m3:349
349       VAR desc, desc2: InitPtr;  imp: RT0.ImportPtr;  m2: RT0.ModulePtr;
(m3gdb)
Continuando.

Breakpoint 3, RunMainBody (m=16_b7e0b660)
    at ../src/runtime/common/RTLinker.m3:349
349       VAR desc, desc2: InitPtr;  imp: RT0.ImportPtr;  m2: RT0.ModulePtr;
(m3gdb)
Continuando.


[Nuevo Thread -1234015344 (LWP 9706)]
[Thread -1234015344 (LWP 9706) exited]

And the program hangs there.
And again the same situation on the stack trace when killing the process inside m3gdb (also got a segment violation on m3gdb):

(m3gdb) where
#0  0xb7fbf410 in __kernel_vsyscall ()
#1  0xb7108ae7 in pthread_kill () from
 /lib/tls/i686/cmov/libpthread.so.0
#2  0xb737c397 in SignalThread (act=16_08055d88, state=Stopping)
    at ../src/thread/PTHREAD/ThreadPThread.m3:1058
#3  0xb737c6dc in StopWorld () at ../src/thread/PTHREAD/ThreadPThread.m3:1142
#4  0xb737b9e7 in SuspendOthers ()
    at ../src/thread/PTHREAD/ThreadPThread.m3:905
#5  0xb7355244 in CollectSomeInStateZero ()
    at ../src/runtime/common/RTCollector.m3:755
#6  0xb7355203 in CollectSome () at ../src/runtime/common/RTCollector.m3:729
#7  0xb7354c24 in CollectEnough () at ../src/runtime/common/RTCollector.m3:656
#8  0xb73586c1 in AllocTraced (def=16_b7dfbfb4, dataSize=456, dataAlignment=4,
    initProc=Static link does not lead to a valid frame.
) at ../src/runtime/common/RTCollector.m3:1462
#9  0xb734af25 in GetTracedObj (def=16_b7dfbfb4)
    at
 ../src/runtime/common/RTAllocator.m3:206
#10 0xb734a9b0 in AllocateTracedObj (defn=16_b7dfbfb4)
    at ../src/runtime/common/RTAllocator.m3:131
#11 0xb7d63df5 in Connect (inst=NIL, trsl=NIL) at ../src/xvbt/XClientF.m3:495
#12 0xb7d66717 in DoConnect (self=16_b6f41d5c, inst=NIL, localOnly=FALSE,
    t=NIL) at ../src/xvbt/XClientF.m3:637
#13 0xb7d46c23 in DoConnect (self=16_b6f41d5c, inst=NIL, localOnly=FALSE,
    t=NIL) at ../src/xvbt/XClient.m3:1495
#14 0xb7d9962c in Connect (inst=NIL, localOnly=FALSE)
---Type <return> to continue, or q <return> to quit---
    at ../src/vbt/TrestleClass.m3:30
#15 0xb7df2117 in Default () at ../src/trestle/Trestle.m3:838
#16 0xb7ded789 in PreAttach (v=16_b6f41cf8, trsl=NIL)
    at ../src/trestle/Trestle.m3:264
#17 0xb7deb95b in Install (v=16_b6f41cf8, applName=NIL, inst=NIL,
Fallo de
 segmentaci?n


Maybe could be some gcc backend issue?
I would like to know if others have the same problem.
Thanks.
  
--- 19/5/08, Randy Coleburn <rcoleburn at scires.com> wrote:
De: Randy Coleburn <rcoleburn at scires.com>
Asunto: Re: [M3devel] garbage collection problem on LINUXLIBC6?
Para: m3devel at elegosoft.com
Fecha: lunes, 19 mayo, 2008 10:08


 
Daniel, I have this same problem on GUI applications created on cm3 v4.1.  If I don't put "@M3novm" on the command line, the programs crash during startup.  It has something to do with the garbage collector.  In my testing of cm3 d5.7.0 on Windows XP, I have not run into the problem yet, so I think Tony has fixed it with his new garbage collector, at least on Windows.
Regards,
Randy

>>> "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> 5/18/2008 6:39 PM >>>




Dear developers:
I'm running a new installed cm3 on an ubuntu 8.04 32 bits, and I can't run anything with gui if I don't use @M3nogc
The rest of the applications, the compiler, and m3browser seem to work without problems ??
I'm debugging mentor but I just got this until now:
Breakpoint 5, Init () at ../src/color/ColorName.m3:207
207           IF table.put (NormalizeName (Basic [i].name), i) THEN
(m3gdb) where
#0  Init () at ../src/color/ColorName.m3:207
#1  0xb7c7b7ff in ColorName (mode=1) at ../src/color/ColorName.m3:214
#2  0xb70e2389 in RunMainBody (m=16_b7ca2fa0) at ../src/runtime/common/RTLinker.m3:399
#3  0xb70e2055 in RunMainBody (m=16_b7d38100) at ../src/runtime/common/RTLinker.m3:379
#4  0xb70e2055 in RunMainBody (m=16_b7d2fe20) at ../src/runtime/common/RTLinker.m3:379
#5  0xb70e2055 in RunMainBody (m=16_b7d34480) at
 ../src/runtime/common/RTLinker.m3:379
#6  0xb70e2055 in RunMainBody (m=16_b7d30d60) at ../src/runtime/common/RTLinker.m3:379
#7  0xb70e2055 in RunMainBody (m=16_b7d4d620) at ../src/runtime/common/RTLinker.m3:379
#8  0xb70e2055 in RunMainBody (m=16_b7e31d80) at ../src/runtime/common/RTLinker.m3:379
#9  0xb70e2055 in RunMainBody (m=16_b7e33220) at ../src/runtime/common/RTLinker.m3:379
#10 0xb70e2055 in RunMainBody (m=16_b7e36d40) at ../src/runtime/common/RTLinker.m3:379
#11 0xb70e2055 in RunMainBody (m=16_b7e364e0) at ../src/runtime/common/RTLinker.m3:379
#12 0xb70e2055 in RunMainBody (m=16_b7e36ba0) at ../src/runtime/common/RTLinker.m3:379
#13 0xb70e2055 in RunMainBody (m=16_b7e32cc0) at ../src/runtime/common/RTLinker.m3:379
#14 0xb70e2055 in RunMainBody (m=16_b7e32900) at ../src/runtime/common/RTLinker.m3:379
#15 0xb70e2055 in RunMainBody (m=16_08255600) at ../src/runtime/common/RTLinker.m3:379
#16
 0xb70e2055 in RunMainBody (m=16_08256040) at ../src/runtime/common/RTLinker.m3:379
#17 0xb70e2055 in RunMainBody (m=16_08312aa0) at ../src/runtime/common/RTLinker.m3:379
#18 0xb70e0dff in AddUnitI (m=16_08312aa0) at ../src/runtime/common/RTLinker.m3:113
#19 0xb70e0e8d in AddUnit (b={"Main_M3", Declared at: ../src/Main.m3:164}) at ../src/runtime/common/RTLinker.m3:122
#20 0x0806df1e in main (argc=3, argv=0xbfa03774, envp=0xbfa03784) at _m3main.mc:4
#21 0xb6d44450 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#22 0x0806de71 in _start ()
(m3gdb) cont
Continuando.

Breakpoint 5, Init () at ../src/color/ColorName.m3:207
207           IF table.put (NormalizeName (Basic [i].name), i) THEN
(m3gdb) cont
and the process hangs there when debugging mentor.

I have checked  Juno under m3gdb after have killed it and got:

(m3gdb) where
#0 
 0xb7fb0410 in __kernel_vsyscall ()
#1  0xb7018ae7 in pthread_kill () from /lib/tls/i686/cmov/libpthread.so.0
#2  0xb728c397 in SignalThread (act=16_0813c120, state=Stopping) at ../src/thread/PTHREAD/ThreadPThread.m3:1058
#3  0xb728c55e in StopWorld () at ../src/thread/PTHREAD/ThreadPThread.m3:1116
#4  0xb728b9e7 in SuspendOthers () at ../src/thread/PTHREAD/ThreadPThread.m3:905
#5  0xb7265244 in CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:755
#6  0xb7265203 in CollectSome () at ../src/runtime/common/RTCollector.m3:729
#7  0xb7264c24 in CollectEnough () at ../src/runtime/common/RTCollector.m3:656
#8  0xb72686c1 in AllocTraced (def=16_b7be1400, dataSize=12, dataAlignment=4, initProc=NIL)
    at ../src/runtime/common/RTCollector.m3:1462
#9  0xb725ad8f in GetTracedRef (def=16_b7be1400) at ../src/runtime/common/RTAllocator.m3:191
#10 0xb725a987
 in AllocateTracedRef (defn=16_b7be1400) at ../src/runtime/common/RTAllocator.m3:126
#11 0xb7b5d8fb in Put (tbl=16_b6e50438, key=8047, val=244) at ../LINUXLIBC6/IntIntTbl.m3 => ../src/table/Table.mg:127
#12 0xb7dd4e2c in Set (a='>', b='o', c=244, bothCases=FALSE, reversed=TRUE) at ../src/etext/KeyFilter.m3:288
#13 0xb7dd521c in Set (a='o', b='>', c=244, bothCases=FALSE, reversed=FALSE) at ../src/etext/KeyFilter.m3:304
#14 0xb7dd5882 in KeyFilter (mode=1) at ../src/etext/KeyFilter.m3:437
#15 0xb7273389 in RunMainBody (m=16_b7e51da0) at ../src/runtime/common/RTLinker.m3:399
#16 0xb7273055 in RunMainBody (m=16_b7e547e0) at ../src/runtime/common/RTLinker.m3:379
#17 0xb7273055 in RunMainBody (m=16_b7e56c00) at ../src/runtime/common/RTLinker.m3:379
#18 0xb7273055 in RunMainBody (m=16_b7e54240) at ../src/runtime/common/RTLinker.m3:379
#19 0xb7273055 in RunMainBody (m=16_b7e537e0) at
 ../src/runtime/common/RTLinker.m3:379
#20 0xb7273055 in RunMainBody (m=16_080b85a0) at ../src/runtime/common/RTLinker.m3:379
#21 0xb7271dff in AddUnitI (m=16_080b85a0) at ../src/runtime/common/RTLinker.m3:113
#22 0xb7271e8d in AddUnit (b={"Juno_M3", Declared at: ../src/Juno.m3:1974}) at ../src/runtime/common/RTLinker.m3:122
#23 0x0805120e in main (argc=1, argv=0xbf96ff14, envp=0xbf96ff1c) at _m3main.mc:4
#24 0xb6ed5450 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#25 0x08051161 in _start ()


When killing mentor under m3gdb it shows like the same back trace:
(m3gdb) where
#0  0xb70fb39a in SignalThread (act=16_0834ff08, state=Stopping) at ../src/thread/PTHREAD/ThreadPThread.m3:1058
#1  0xb70fb6dc in StopWorld () at ../src/thread/PTHREAD/ThreadPThread.m3:1142
#2  0xb70fa9e7 in SuspendOthers () at ../src/thread/PTHREAD/ThreadPThread.m3:905
#3  0xb70d4244 in CollectSomeInStateZero
 () at ../src/runtime/common/RTCollector.m3:755
#4  0xb70d4203 in CollectSome () at ../src/runtime/common/RTCollector.m3:729
#5  0xb70d3c24 in CollectEnough () at ../src/runtime/common/RTCollector.m3:656
#6  0xb70d76c1 in AllocTraced (def=16_b712d934, dataSize=24, dataAlignment=4, initProc=Static link does not lead to a valid frame.
)
    at ../src/runtime/common/RTCollector.m3:1462
#7  0xb70c9f25 in GetTracedObj (def=16_b712d934) at ../src/runtime/common/RTAllocator.m3:206
#8  0xb70c99b0 in AllocateTracedObj (defn=16_b712d934) at ../src/runtime/common/RTAllocator.m3:131
#9  0xb710d586 in New (a={'a','z','u','r','e','4'}) at ../src/text/Text8Short.m3:16
#10 0xb710ce87 in New (a={'a','z','u','r','e','4'}) at ../src/text/Text8.m3:18
#11 0xb710ba9d in FromChars (a={'a','z','u','r','e','4'}) at ../src/text/Text.m3:206
#12 0xb7c7a62f in NormalizeName (a=16_b7ca378c) at
 ../src/color/ColorName.m3:83
#13 0xb7c7b789 in Init () at ../src/color/ColorName.m3:207
#14 0xb7c7b7ff in ColorName (mode=1) at ../src/color/ColorName.m3:214
#15 0xb70e2389 in RunMainBody (m=16_b7ca2fa0) at ../src/runtime/common/RTLinker.m3:399
#16 0xb70e2055 in RunMainBody (m=16_b7d38100) at ../src/runtime/common/RTLinker.m3:379
#17 0xb70e2055 in RunMainBody (m=16_b7d2fe20) at ../src/runtime/common/RTLinker.m3:379
#18 0xb70e2055 in RunMainBody (m=16_b7d34480) at ../src/runtime/common/RTLinker.m3:379
#19 0xb70e2055 in RunMainBody (m=16_b7d30d60) at ../src/runtime/common/RTLinker.m3:379
#20 0xb70e2055 in RunMainBody (m=16_b7d4d620) at ../src/runtime/common/RTLinker.m3:379
#21 0xb70e2055 in RunMainBody (m=16_b7e31d80) at ../src/runtime/common/RTLinker.m3:379
#22 0xb70e2055 in RunMainBody (m=16_b7e33220) at ../src/runtime/common/RTLinker.m3:379
#23 0xb70e2055 in RunMainBody (m=16_b7e36d40) at
 ../src/runtime/common/RTLinker.m3:379
#24 0xb70e2055 in RunMainBody (m=16_b7e364e0) at ../src/runtime/common/RTLinker.m3:379
#25 0xb70e2055 in RunMainBody (m=16_b7e36ba0) at ../src/runtime/common/RTLinker.m3:379
#26 0xb70e2055 in RunMainBody (m=16_b7e32cc0) at ../src/runtime/common/RTLinker.m3:379
#27 0xb70e2055 in RunMainBody (m=16_b7e32900) at ../src/runtime/common/RTLinker.m3:379
#28 0xb70e2055 in RunMainBody (m=16_08255600) at ../src/runtime/common/RTLinker.m3:379
#29 0xb70e2055 in RunMainBody (m=16_08256040) at ../src/runtime/common/RTLinker.m3:379
#30 0xb70e2055 in RunMainBody (m=16_08312aa0) at ../src/runtime/common/RTLinker.m3:379
#31 0xb70e0dff in AddUnitI (m=16_08312aa0) at ../src/runtime/common/RTLinker.m3:113
#32 0xb70e0e8d in AddUnit (b={"Main_M3", Declared at: ../src/Main.m3:164}) at ../src/runtime/common/RTLinker.m3:122
#33 0x0806df1e in main (argc=3, argv=0xbfa03774, envp=0xbfa03784) at _m3main.mc:4
#34
 0xb6d44450 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#35 0x0806de71 in _start ()

Thanks in advance




Enviado desde Correo Yahoo!
La bandeja de entrada m?s inteligente.








      
Enviado desde Correo Yahoo!
La bandeja de entrada m?s inteligente.









      
Enviado desde Correo Yahoo!
La bandeja de entrada m?s inteligente.









      
Enviado desde Correo Yahoo!
La bandeja de entrada m?s inteligente.



      ______________________________________________ 
Enviado desde Correo Yahoo! La bandeja de entrada m?s inteligente.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Wed May 28 06:26:10 2008
From: jayk123 at hotmail.com (Jay)
Date: Wed, 28 May 2008 04:26:10 +0000
Subject: [M3devel] function pointers and comparison to nil?
	mis-typed	function pointers?
In-Reply-To: <20080527154551.GA24415@topoi.pooq.com>
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
	<20080527154551.GA24415@topoi.pooq.com>
Message-ID: 

> The CDC Algol 68 compiler had a trick for recognising expired scopes 
Hendrik -- but then again there is that heap allocation cost..
 
This is also a step toward, like, heap allocated stack frames, except the garbage collected heap is only being used for its "lifetime features" and not its ability to store anything (other than lifetime/liveness).
 
As I understand..and this is maybe crazy...a straightforward Scheme implementation -- with no static analysis -- and "Stackless Python" take that next step -- all frames are heap allocated and garbage collected, and therefore a pointer to a nested function can outlive its original context. Neat but seems expensive. Perhaps can be fast enough.
I like the canonical Scheme example:
 
  (define make-adder (x) (lamba (y) (+ x y)))  
  (define add5 (make-adder 5))  
  (add5 3)  
 
  => 8  
 
implies make-adder's frame that contains "5" is heap allocated and then "add5" is a heap allocated chunk that contains merely that pointer and a pointer to the nexted function.
 
 > procedure to a single-pointer callback. This functin will have to be   > rewritten for each platform, and can allocate the necessary   > dynamically-genereated code on the heap (or, of course, on the stack, if   > possible on that platform). As for portability, it's certianly no  
I think it's easy enough to generate the code, the problem is where to put it.
Stack is not necessarily executable, heap is more expensive to allocate.
But in this forum I'm always contradicted on that last point, so it could just be in the heap.
Note that the heap isn't necessarily executable either.
 
I don't think breaking the existing compatibility with C function pointers is good.
In fact, I dare suggest that C interop should be aided by the Modula-3 compiler generating "headers" for C.
Really just a possible part of any "C backend". :)
 
If the type system is strong enough..having two separate types for C function pointers and Modula-3 function pointers might be viable. But you'd have to review all the "loopholes". Again probably a losing effort.
 
As I've said a few times, I'm fairly content to leave this all alone. Maybe just to research "reliable" markers that cannot now or ever be confused for "real code". It's hard to make such a guarantee what with processors always evolving and gaining new instructions. If the constant could be dynamic, it could be an absolute reference to a particular reserved symbol. If you manage to call it incorrectly, that symbol would be a real function and raise an exception. This a) depends on their being a suitable addressing mode, ie: not PC-relative and allowing for large enough constants (possibly multiple instructions..big, wasteful) b) makes the check for the signature much more expensive since it'd have to read memory another time c) likewise for the formation of the closures. Could be that part of the signature is constant and part dynamic.
 
Another idea would be to have a static check post-link run through all the code and verify the marker doesn't appear at the start of any function, if there is sufficient ability to read the code that way.
 
Anyway, it's probably all fairly moot.
Just need to disassemble -1 on every platform now and every so often, to "lazily" "ensure" it is not valid code.
 
Had I not hit the alignment fault I never would have discovered this stuff and we wouldn't be talking too much about it... :)
 
 - Jay



> Date: Tue, 27 May 2008 11:45:51 -0400> From: hendrik at topoi.pooq.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?> > On Sun, May 25, 2008 at 10:50:15PM -0500, Rodney M. Bates wrote:> > I think I can shed some light on this, having spent some time making> > m3gdb handle the various operations on nested procedures. As for code> > that mixes M3 and C, I believe the following are true:> > > > - Within M3 code only, the closure system works correctly in all cases.> > This answers one of Jay's worries.> > As long as procedure-entry code can be guaranteed never to start wit a > word of one-bits. We do have some influence on this code, though, and > if necessary might be able to choose a different bit pattern on a > specific platform.> > > > > - For values of M3 procedure/C function pointer that are top-level> > (nonnested) procedures/functions, M3 and C code (generated by gcc,> > at least) are interchangeable. This answers another of Jay's worries.> > This will cover that great majority of cases.> > Yes. And in many cases, we will know statically that this is the case.> > > > > - Standard C has no nested functions. Gcc adds them as a language> > extension. Thus, only in gcc-compiled C code do we need to worry> > about nested procedures/functions between languages. (Do any other> > C compilers exist that also have nested functions?)> > Standard C has no nested function, and does not need closures. As a > result, Standard C can use simple pointers to represent function > addresses. The language extension retrofits closures using run-time > code generation. The way this is done (on the satck) is nonportable, > and we'd like to avoid that nonportability.> > The problem with seems to be just that you seem to want to use an > address of a function as a function pointer, and that just doesn't have > enough space in it to represent a closure.> > But why do it that way? Why not just let *all* Modula 3 functions be > represented by closures? Then you never have to test whether something > is a closure, it just always is. Top-level functions with no > environment just use a null pointer as environment -- and never use it.> > The only arguments for not doing this would seem to be > (a) the waste of space, making functions a little larger than necessary, > (b) and C compatibility.> > Now (a) is probably a nonissue, since the vast majority of functions > never have their addresses taken, are never passes as parameters to > other procedures, and so forth. So for the vast majority of functions, > you simply never have to build the closure.> > (b) might be a problem. The obvious trick is just to forbid passing to C > a non-top-level function. Since even the C programmers who devise > interfaces with callbacks realise that just a functino pointer isn't > enough, they usually provide a machanism for passing a void pointer to > additional information the callback might need. Nothing here puts > Modula 3 at a disadvantage relative to C. You can just use a top-level > function and let the programmer provide it with whatever it needs.> > But if it is deemed essential to provide actual single-pointer callback > addresses, this can be done by using a built-in function to convert a > procedure to a single-pointer callback. This functin will have to be > rewritten for each platform, and can allocate the necessary > dynamically-genereated code on the heap (or, of course, on the stack, if > possible on that platform). As for portability, it's certianly no > big deal to do this; compared with writing a platform-dependent code > generator (itself a requirement), this is not huge.> > > - M3's normal runtime check that precludes assigning a nonlocal> > procedure value will not detect a C-code-produced nonlocal value,> > thus the environment could indeed have disappeared if the programmer> > was not careful. However, gcc-extended C's nested functions have> > no protection against this bug when only C code is involved, so> > perhaps not detecting it in mixed M3/C is to be expected.> > We really can't protect against bugs in C code. If we could prevent > bugs in C, the market for it would be huge, and we'd be well advised to > consider that our main business.> > > > > - C code that attempts to call a function pointer value that was> > originally produced by M3 code as a nested procedure value will> > almost certainly crash at the time of the call. This is the only> > case that presents a significant problem. M3 code will not be> > able to give a nested procedure as a callback to a C library.> > Wherefor only in this case should we do run-time code generation.> > It has been argued that we don't need to protect against C programmers > going hog-wild and breaking their own code. Such is the nature of C.> > But, we can chack for some of it, it we are willing to go to the effort. > The technique used in the CDC Algol 68 compiler long ago might even > enable us to restrict the constraint on assigning nested procedures to > variables by a suitable run-time check.> > The CDC Algol 68 compiler had a trick for recognising expired scopes > using the garbage collector. Let's see if I can remember the details. > It involved special treatment for procedures whose addresses are taken, > and for the blocks that contain them. When entering such a block at > run-time, a word is allocated on the heap representing that scope. It > is filled with something relevant, such as the address if the stack > frame for the block, and the stack frame also pointed to that scope-cell > (as I'll describe it). Taking the address of a procedure involved > building a closure that points to that scope-cell. When leaving the > block, the contents of the scope-cell is wiped to some recognisable > invalid value. When entering the procedure the scope-cell will > still be around even if the scope is not. The procedure (this is inside > the procedure itself, not at the call) checks that the scope-cell has > not been wiped, and therefore is still valid. If valid, it contains the > necessary environment information. If not, break off execution.> > -- hendrik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From hendrik at topoi.pooq.com  Wed May 28 08:14:24 2008
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Wed, 28 May 2008 02:14:24 -0400
Subject: [M3devel] function pointers and comparison to nil?
	mis-typed	function pointers?
In-Reply-To: 
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
	<20080527154551.GA24415@topoi.pooq.com>
	
Message-ID: <20080528061424.GA25708@topoi.pooq.com>

On Wed, May 28, 2008 at 04:26:10AM +0000, Jay wrote:
> > The CDC Algol 68 compiler had a trick for recognising expired scopes 
> Hendrik -- but then again there is that heap allocation cost..

But only for the blocks closest-containing procedures whose addresses 
are taken.  That is relatively rare, and it will not cause heap allocation 
for anyone that does not take addresses of nested procedures.
>  
> This is also a step toward, like, heap allocated stack frames, except 
> the garbage collected heap is only being used for its "lifetime 
> features" and not its ability to store anything (other than 
> lifetime/liveness).
>  
> As I understand..and this is maybe crazy...a straightforward Scheme implementation -- with no static analysis -- and "Stackless Python" take that next step -- all frames are heap allocated and garbage collected, and therefore a pointer to a nested function can outlive its original context. Neat but seems expensive. Perhaps can be fast enough.
> I like the canonical Scheme example:
>  
>   (define make-adder (x) (lamba (y) (+ x y)))  
>   (define add5 (make-adder 5))  
>   (add5 3)  
>  
>   => 8  
>  
> implies make-adder's frame that contains "5" is heap allocated and then "add5" is a heap allocated chunk that contains merely that pointer and a pointer to the nexted function.
>  
>  > procedure to a single-pointer callback. This functin will have to be   > rewritten for each platform, and can allocate the necessary   > dynamically-genereated code on the heap (or, of course, on the stack, if   > possible on that platform). As for portability, it's certianly no  

> I think it's easy enough to generate the code, the problem is where to put it.
> Stack is not necessarily executable, heap is more expensive to allocate.
> But in this forum I'm always contradicted on that last point, so it could just be in the heap.
> Note that the heap isn't necessarily executable either.

Id you can't write into dynamically-allocated code space, you may as 
well forget about JIT compilers.  Well, I suppose there could be 
machines that can't have JIT compilers.
 
Actually, if you're talking to C, you should be able to follow the 
same restrictions that C uses.

>  
> I don't think breaking the existing compatibility with C function 
> pointers is good.

Until this discussion started, I never dreamed there was any 
compatibility with C functino pointers except for non-nested procedures.  
This all came as a surprise to me.

> In fact, I dare suggest that C interop should be aided by the Modula-3 
> compiler generating "headers" for C.
> Really just a possible part of any "C backend". :)
>  
> If the type system is strong enough..having two separate types for C 
> function pointers and Modula-3 function pointers might be viable. But 
> you'd have to review all the "loopholes". Again probably a losing 
> effort.

Just like C strings and Modula 3 strings?

>  
> As I've said a few times, I'm fairly content to leave this all alone. 

I, too.  But I thought it ws worth pointing out that there is a 
conceptually clean solution, especially since conceptually clean 
practicality is one of Modula 3's hallmarks.

-- hendrik


From jayk123 at hotmail.com  Wed May 28 09:04:58 2008
From: jayk123 at hotmail.com (Jay)
Date: Wed, 28 May 2008 07:04:58 +0000
Subject: [M3devel] function pointers and comparison to
	nil?	mis-typed	function pointers?
In-Reply-To: <20080528061424.GA25708@topoi.pooq.com>
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
	<20080527154551.GA24415@topoi.pooq.com>
	 
	<20080528061424.GA25708@topoi.pooq.com>
Message-ID: 

> Id you can't write into dynamically-allocated code space, you may as > well forget about JIT compilers. Well, I suppose there could be > machines that can't have JIT compilers.
Those systems are slow.....AND this "proposal" (exaggeration!) as I understand equates to a heap alloc per function call for CERTAIN RARE function calls, or perhaps more fine grained, per taking-address-of-nested functions.
 
These slow systems with JITs don't usually JIT "that often".
They JIT like at one of:
   module load 
   first time a function is called  
   first time a block is entered 
 
but not for subsequent loads/runs, at least not with the same process or "app domain".
 
> Until this discussion started, I never dreamed there was any > compatibility with C functino pointers except for non-nested procedures. > This all came as a surprise to me.
That is all there is. You cannot pass a closure pointer off to C code as a function pointer.
You CAN pass gcc nested C functions off as such however.
Opposing forces -- closures as dynamically sniffed pair of pointers vs. closures as dynamically generated code.
Ok, also nested functions that don't happen to use their parent frames' locals probably interop.
 
Ok, probably I should go and implement the *option* cm3cg -trampolines and m3 -trampolines or somesuch.
 
I guess a pragma <* trampoline *> or <* c function pointer *> to let source ask for it, but that's getting ahead of things, it's "experimental" and probably just not desirable, but maybe just interesting to get working...
 
 - Jay



> Date: Wed, 28 May 2008 02:14:24 -0400> From: hendrik at topoi.pooq.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?> > On Wed, May 28, 2008 at 04:26:10AM +0000, Jay wrote:> > > The CDC Algol 68 compiler had a trick for recognising expired scopes > > Hendrik -- but then again there is that heap allocation cost..> > But only for the blocks closest-containing procedures whose addresses > are taken. That is relatively rare, and it will not cause heap allocation > for anyone that does not take addresses of nested procedures.> > > > This is also a step toward, like, heap allocated stack frames, except > > the garbage collected heap is only being used for its "lifetime > > features" and not its ability to store anything (other than > > lifetime/liveness).> > > > As I understand..and this is maybe crazy...a straightforward Scheme implementation -- with no static analysis -- and "Stackless Python" take that next step -- all frames are heap allocated and garbage collected, and therefore a pointer to a nested function can outlive its original context. Neat but seems expensive. Perhaps can be fast enough.> > I like the canonical Scheme example:> > > > (define make-adder (x) (lamba (y) (+ x y))) > > (define add5 (make-adder 5)) > > (add5 3) > > > > => 8 > > > > implies make-adder's frame that contains "5" is heap allocated and then "add5" is a heap allocated chunk that contains merely that pointer and a pointer to the nexted function.> > > > > procedure to a single-pointer callback. This functin will have to be > rewritten for each platform, and can allocate the necessary > dynamically-genereated code on the heap (or, of course, on the stack, if > possible on that platform). As for portability, it's certianly no > > > I think it's easy enough to generate the code, the problem is where to put it.> > Stack is not necessarily executable, heap is more expensive to allocate.> > But in this forum I'm always contradicted on that last point, so it could just be in the heap.> > Note that the heap isn't necessarily executable either.> > Id you can't write into dynamically-allocated code space, you may as > well forget about JIT compilers. Well, I suppose there could be > machines that can't have JIT compilers.> > Actually, if you're talking to C, you should be able to follow the > same restrictions that C uses.> > > > > I don't think breaking the existing compatibility with C function > > pointers is good.> > Until this discussion started, I never dreamed there was any > compatibility with C functino pointers except for non-nested procedures. > This all came as a surprise to me.> > > In fact, I dare suggest that C interop should be aided by the Modula-3 > > compiler generating "headers" for C.> > Really just a possible part of any "C backend". :)> > > > If the type system is strong enough..having two separate types for C > > function pointers and Modula-3 function pointers might be viable. But > > you'd have to review all the "loopholes". Again probably a losing > > effort.> > Just like C strings and Modula 3 strings?> > > > > As I've said a few times, I'm fairly content to leave this all alone. > > I, too. But I thought it ws worth pointing out that there is a > conceptually clean solution, especially since conceptually clean > practicality is one of Modula 3's hallmarks.> > -- hendrik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From ronny.forberger at elegosoft.com  Wed May 28 11:52:29 2008
From: ronny.forberger at elegosoft.com (Ronny Forberger)
Date: Wed, 28 May 2008 11:52:29 +0200
Subject: [M3devel] FW: NT386 environment variables (new NT386	snapshots)
In-Reply-To: <20080527155926.203bam89w4w0kgko@mail.elegosoft.com>
References: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
	
	<4823279D.1E75.00D7.1@scires.com>
	
	<20080527155926.203bam89w4w0kgko@mail.elegosoft.com>
Message-ID: <20080528115229.yjpegnw34ow4g0o8@mail.elegosoft.com>

--
Message from: Olaf Wagner 
Date: Di 27 Mai 2008 15:59:26 CEST
Subject: Re: [M3devel] FW: NT386 environment variables (new NT386 snapshots)


> Quoting Jay :
>
>> truncated again...
>> m3support -- nothing interesting in any logs regarding my mail?
>> And nobody else uses hotmail, right?
>
> @Ronny, can you please check if our mail logs reveal any reason
> for Jay's mails to be truncated now and then?

The logs don't say anything about it. But it might be that this  
happens when mailman converts HTML-only messages to plain text, which  
is common behavior on mailing lists.

Jay, if your messages are HTML-only, you perhaps could try sending  
plain text only messages to the lists and check again.

[...]

Regards,

Ronny

-- 
Ronny Forberger
IT Services & Support

elego Software Solutions GmbH
Gustav-Meyer-Allee 25
Building 12.3 (BIG) room 227
13355 Berlin, Germany

phone +49 30 23 45 86 96      ronny.forberger at elegosoft.com
fax   +49 30 23 45 86 95      http://www.elegosoft.com

Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin
Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194



From hendrik at topoi.pooq.com  Wed May 28 14:00:30 2008
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Wed, 28 May 2008 08:00:30 -0400
Subject: [M3devel] function pointers and comparison to
	nil?	mis-typed	function pointers?
In-Reply-To: 
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
	<20080527154551.GA24415@topoi.pooq.com>
	
	<20080528061424.GA25708@topoi.pooq.com>
	
Message-ID: <20080528120030.GA26129@topoi.pooq.com>

On Wed, May 28, 2008 at 07:04:58AM +0000, Jay wrote:
> > Id you can't write into dynamically-allocated code space, you may as > well forget about JIT compilers. Well, I suppose there could be > machines that can't have JIT compilers.
> Those systems are slow.....AND this "proposal" (exaggeration!) as I understand equates to a heap alloc per function call for CERTAIN RARE function calls, or perhaps more fine grained, per taking-address-of-nested functions.
>  
> These slow systems with JITs don't usually JIT "that often".
> They JIT like at one of:
>    module load 
>    first time a function is called  
>    first time a block is entered 
>  
> but not for subsequent loads/runs, at least not with the same process or "app domain".
>  
> > Until this discussion started, I never dreamed there was any
> > compatibility with C functino pointers except for non-nested 
> > procedures.
> > This all came as a surprise to me.

> That is all there is. You cannot pass a closure pointer off to C code 
> as a function pointer.

So the only programs that will be affected by the heap allocation to 
convert Modula 3 closures to C closures are programs which are currently 
illegal.  This makes it effectively have zero cost for existing code.

> You CAN pass gcc nested C functions off as such however.

Thus eventually we can expect to have to interface with libraries that 
expect nested C functino closures and don't pass an extra void pointer 
for environment.

> Opposing forces -- closures as dynamically sniffed pair of pointers 
> vs. closures as dynamically generated code.
> Ok, also nested functions that don't happen to use their parent 
> frames' locals probably interop.

I fact, everywhere we talk about the syntactically enclosing block, we 
should be talking about the most local enclosing block that declares 
names used in the function.

>  
> Ok, probably I should go and implement the *option* cm3cg -trampolines 
> and m3 -trampolines or somesuch.
>  
> I guess a pragma <* trampoline *> or <* c function pointer *> to let 
> source ask for it, but that's getting ahead of things, it's 
> "experimental" and probably just not desirable, but maybe just 
> interesting to get working...
>  
>  - Jay


From wagner at elegosoft.com  Thu May 29 15:02:09 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Thu, 29 May 2008 15:02:09 +0200
Subject: [M3devel] _lowbits / _highbits (Pixmap bug-- 4.1 vs. buggy	5.x)
In-Reply-To: 
References: 
	
Message-ID: <20080529150209.vnhlgwbjcog4wc04@mail.elegosoft.com>

Quoting Jay :

> 1) Just fyi, NT386GNU didn't build with my fix, so it is disabled   
> there only, and the bug could very well be present there.
> Er, then again, this stuff works differently for the gcc backend, so  
>  I don't know, I'll have to look, and run the tests, not today.
> Which reminds me also, these symbols should be static hand.c, except  
>  for NT386 -- the source can't tell, so it'll have to be a define   
> from the m3makefile.
>
> 2) Can anyone confirm my history and the missing source?
> ie: Confirm that what is marked as 4.1 and 5.1 in CVS really is 4.1   
> and 5.1? I don't think 4.1 is accurately marked.
> In particular, I don't think the 4.1 Stackx86.m3  is what 4.1   
> actually shipped.
>
> 3) Or confirm my analysis that leads to the "accusation"? It was tedious.

I don't think that a complete 4.1 code set was ever imported into
the CVS CM3 repository; at least I don't remember we got the complete
4.1 code from Farshad Nayeri. What we got was 5.1 and it wasn't even
compilable by any existing M3 compiler. The gcc backend was so old
that it wasn't usable on any system we had. I think we extensively used
PM3 for booting and even incorporated some of PM3's code where
necessary.

I remember that I had several evaluation CDs from CM3 some years before
the open source release, so it may be that contents from one of these
CDs were imported as 4.1. I'm afraid it is not really traceable now.
We never got any versioned code from Critical Mass (I don't know what
they used for version control), only the bare source code.

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 rcoleburn at scires.com  Thu May 29 18:31:14 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Thu, 29 May 2008 12:31:14 -0400
Subject: [M3devel] _lowbits / _highbits (Pixmap bug-- 4.1 vs.	buggy	5.x)
In-Reply-To: <20080529150209.vnhlgwbjcog4wc04@mail.elegosoft.com>
References: 
	
	<20080529150209.vnhlgwbjcog4wc04@mail.elegosoft.com>
Message-ID: <483EA20A.1E75.00D7.1@scires.com>

Olaf / Jay:
 
My Reactor v4.1 CD has a source directory, but this folder does not
contain the sources for the compiler or Reactor, just the libraries et
al.
 
Here is a list of the archives in that folder:
 
BINUTILS.TGZ
m3-comm.TGZ
m3-db.TGZ
M3-DEMO.TGZ
M3-GAMES.TGZ
M3-LCTRN.TGZ
m3-libs.TGZ
M3-MAIL.TGZ
M3-OBLIQ.TGZ
M3-PKGTL.TGZ
M3-TOOLS.TGZ
m3-ui.TGZ
m3-www.TGZ
M3CC.TGZ
M3GDB.TGZ
 
There is also a CONTRIB folder with the following:
 
CVSUP
IDLM3
M2TOM3
M3DDD
M3PC
M3TOMIF
SRC-M3
 
If Farshad is ok with it, I can send you these files, but I would need
his approval because we licensed this product from Critical Mass.
 
On a side note, I just built a new laptop computer from a fresh install
of XP Pro.  I got the latest cm3 from the repository and rebuilt
everything.  On this platform, my pixmaps show up with a "yellow" color
everywhere "white" would normally show.  This is strange behavior.  I
checked the .lst file and it is showing as a GUI program and the
"hand.obj" is included.  Any ideas?
 
Since Jay has made good progress on fixing some of my major gripes, I
am trying to use the new (current) cm3 for my project that is due for
delivery at the end of July.  The new garbage collector seems to work
much better on Windows than the one from 4.1.  Since we don't have an
official stable release right now, I am going to have to draw a line in
the sand at some point soon and take a snapshot of the cm3 source tree
as the "official" development environment for future support of my
project deliverables.
 
This latest problem with pixmaps on one platform and with CM3IDE on all
XP platforms I've tested so far is disturbing.  As soon as I can get a
handle on these problems, I think I am going to freeze my development
environment for this project unless someone comes up with a major
fix/change.
 
Regards,
Randy

>>> Olaf Wagner  5/29/2008 9:02 AM >>>
Quoting Jay :

> 1) Just fyi, NT386GNU didn't build with my fix, so it is disabled   
> there only, and the bug could very well be present there.
> Er, then again, this stuff works differently for the gcc backend, so 

>  I don't know, I'll have to look, and run the tests, not today.
> Which reminds me also, these symbols should be static hand.c, except 

>  for NT386 -- the source can't tell, so it'll have to be a define   
> from the m3makefile.
>
> 2) Can anyone confirm my history and the missing source?
> ie: Confirm that what is marked as 4.1 and 5.1 in CVS really is 4.1  

> and 5.1? I don't think 4.1 is accurately marked.
> In particular, I don't think the 4.1 Stackx86.m3  is what 4.1   
> actually shipped.
>
> 3) Or confirm my analysis that leads to the "accusation"? It was
tedious.

I don't think that a complete 4.1 code set was ever imported into
the CVS CM3 repository; at least I don't remember we got the complete
4.1 code from Farshad Nayeri. What we got was 5.1 and it wasn't even
compilable by any existing M3 compiler. The gcc backend was so old
that it wasn't usable on any system we had. I think we extensively
used
PM3 for booting and even incorporated some of PM3's code where
necessary.

I remember that I had several evaluation CDs from CM3 some years
before
the open source release, so it may be that contents from one of these
CDs were imported as 4.1. I'm afraid it is not really traceable now.
We never got any versioned code from Critical Mass (I don't know what
they used for version control), only the bare source code.

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 mika at async.caltech.edu  Thu May 29 20:53:01 2008
From: mika at async.caltech.edu (Mika Nystrom)
Date: Thu, 29 May 2008 11:53:01 -0700
Subject: [M3devel] _lowbits / _highbits (Pixmap bug-- 4.1 vs. buggy 5.x)
In-Reply-To: Your message of "Thu, 29 May 2008 12:31:14 EDT."
	<483EA20A.1E75.00D7.1@scires.com> 
Message-ID: <200805291853.m4TIr1FF079831@camembert.async.caltech.edu>

"Randy Coleburn" writes:
...
>On a side note, I just built a new laptop computer from a fresh install
>of XP Pro.  I got the latest cm3 from the repository and rebuilt
>everything.  On this platform, my pixmaps show up with a "yellow" color
>everywhere "white" would normally show.  This is strange behavior.  I
>checked the .lst file and it is showing as a GUI program and the
>"hand.obj" is included.  Any ideas?
...

Not sure if this is related, but "xv" does exactly this for me when
running under VNC, at least with certain combinations of color depths.
No Modula-3 involved.  This is when I am accessing a FreeBSD VNC server
remotely from RealVNC on win2k as well as win XP.  Never quite figured
out why it happens.

    Mika


From jayk123 at hotmail.com  Thu May 29 21:07:40 2008
From: jayk123 at hotmail.com (Jay)
Date: Thu, 29 May 2008 19:07:40 +0000
Subject: [M3devel] _lowbits / _highbits (Pixmap bug-- 4.1 vs.	buggy	5.x)
In-Reply-To: <483EA20A.1E75.00D7.1@scires.com>
References: 
	
	<20080529150209.vnhlgwbjcog4wc04@mail.elegosoft.com> 
	<483EA20A.1E75.00D7.1@scires.com>
Message-ID: 

I have the 4.1 CD. I bought it from Critical Mass the normal legitimate way. I hacked my cm3.exe the other day to skip the license check since I can't find my key, it's very easy to do.
My observations agree with yours -- no source on the CD to the compiler, contrib includes the DEC 3.6 code.
 
What are the CM3IDE problems?
 
What is the pixmap behavior with build_standalone()?
I'm inclined to think this is not a Modula-3 problem but hard to debug remotely like this..
 
 - Jay


Date: Thu, 29 May 2008 12:31:14 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] _lowbits / _highbits (Pixmap bug-- 4.1 vs. buggy 5.x)

Olaf / Jay:
 
My Reactor v4.1 CD has a source directory, but this folder does not contain the sources for the compiler or Reactor, just the libraries et al.
 
Here is a list of the archives in that folder:
 
BINUTILS.TGZm3-comm.TGZm3-db.TGZM3-DEMO.TGZM3-GAMES.TGZM3-LCTRN.TGZm3-libs.TGZM3-MAIL.TGZM3-OBLIQ.TGZM3-PKGTL.TGZM3-TOOLS.TGZm3-ui.TGZm3-www.TGZM3CC.TGZM3GDB.TGZ
 
There is also a CONTRIB folder with the following:
 
CVSUPIDLM3M2TOM3M3DDDM3PCM3TOMIFSRC-M3
 
If Farshad is ok with it, I can send you these files, but I would need his approval because we licensed this product from Critical Mass.
 
On a side note, I just built a new laptop computer from a fresh install of XP Pro.  I got the latest cm3 from the repository and rebuilt everything.  On this platform, my pixmaps show up with a "yellow" color everywhere "white" would normally show.  This is strange behavior.  I checked the .lst file and it is showing as a GUI program and the "hand.obj" is included.  Any ideas?
 
Since Jay has made good progress on fixing some of my major gripes, I am trying to use the new (current) cm3 for my project that is due for delivery at the end of July.  The new garbage collector seems to work much better on Windows than the one from 4.1.  Since we don't have an official stable release right now, I am going to have to draw a line in the sand at some point soon and take a snapshot of the cm3 source tree as the "official" development environment for future support of my project deliverables.
 
This latest problem with pixmaps on one platform and with CM3IDE on all XP platforms I've tested so far is disturbing.  As soon as I can get a handle on these problems, I think I am going to freeze my development environment for this project unless someone comes up with a major fix/change.
 
Regards,
Randy>>> Olaf Wagner  5/29/2008 9:02 AM >>>Quoting Jay :> 1) Just fyi, NT386GNU didn't build with my fix, so it is disabled   > there only, and the bug could very well be present there.> Er, then again, this stuff works differently for the gcc backend, so  >  I don't know, I'll have to look, and run the tests, not today.> Which reminds me also, these symbols should be static hand.c, except  >  for NT386 -- the source can't tell, so it'll have to be a define   > from the m3makefile.>> 2) Can anyone confirm my history and the missing source?> ie: Confirm that what is marked as 4.1 and 5.1 in CVS really is 4.1   > and 5.1? I don't think 4.1 is accurately marked.> In particular, I don't think the 4.1 Stackx86.m3  is what 4.1   > actually shipped.>> 3) Or confirm my analysis that leads to the "accusation"? It was tedious.I don't think that a complete 4.1 code set was ever imported intothe CVS CM3 repository; at least I don't remember we got the complete4.1 code from Farshad Nayeri. What we got was 5.1 and it wasn't evencompilable by any existing M3 compiler. The gcc backend was so oldthat it wasn't usable on any system we had. I think we extensively usedPM3 for booting and even incorporated some of PM3's code wherenecessary.I remember that I had several evaluation CDs from CM3 some years beforethe open source release, so it may be that contents from one of theseCDs were imported as 4.1. I'm afraid it is not really traceable now.We never got any versioned code from Critical Mass (I don't know whatthey used for version control), only the bare source code.Olaf-- Olaf Wagner -- elego Software Solutions GmbH                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germanyphone: +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: BerlinHandelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Thu May 29 21:41:45 2008
From: jayk123 at hotmail.com (Jay)
Date: Thu, 29 May 2008 19:41:45 +0000
Subject: [M3devel] _lowbits / _highbits (Pixmap bug-- 4.1 vs. buggy	5.x)
In-Reply-To: <20080529150209.vnhlgwbjcog4wc04@mail.elegosoft.com>
References: 
	 
	<20080529150209.vnhlgwbjcog4wc04@mail.elegosoft.com>
Message-ID: 

Ok, I stand by my earlier analysis, though I forget what it was. :)
Partly that the "4.1" source in CVS is not 4.1, so understanding how it worked can't be done from source. Though I guess I could read the assembly if we really need to know..
 
Thanks,
 - Jay



> Date: Thu, 29 May 2008 15:02:09 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] _lowbits / _highbits (Pixmap bug-- 4.1 vs. buggy 5.x)> > Quoting Jay :> > > 1) Just fyi, NT386GNU didn't build with my fix, so it is disabled > > there only, and the bug could very well be present there.> > Er, then again, this stuff works differently for the gcc backend, so > > I don't know, I'll have to look, and run the tests, not today.> > Which reminds me also, these symbols should be static hand.c, except > > for NT386 -- the source can't tell, so it'll have to be a define > > from the m3makefile.> >> > 2) Can anyone confirm my history and the missing source?> > ie: Confirm that what is marked as 4.1 and 5.1 in CVS really is 4.1 > > and 5.1? I don't think 4.1 is accurately marked.> > In particular, I don't think the 4.1 Stackx86.m3 is what 4.1 > > actually shipped.> >> > 3) Or confirm my analysis that leads to the "accusation"? It was tedious.> > I don't think that a complete 4.1 code set was ever imported into> the CVS CM3 repository; at least I don't remember we got the complete> 4.1 code from Farshad Nayeri. What we got was 5.1 and it wasn't even> compilable by any existing M3 compiler. The gcc backend was so old> that it wasn't usable on any system we had. I think we extensively used> PM3 for booting and even incorporated some of PM3's code where> necessary.> > I remember that I had several evaluation CDs from CM3 some years before> the open source release, so it may be that contents from one of these> CDs were imported as 4.1. I'm afraid it is not really traceable now.> We never got any versioned code from Critical Mass (I don't know what> they used for version control), only the bare source code.> > 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 jayk123 at hotmail.com  Fri May 30 08:31:19 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 30 May 2008 06:31:19 +0000
Subject: [M3devel] _lowbits / _highbits (Pixmap bug-- 4.1 vs.	buggy	5.x)
In-Reply-To: 
References: 
	
	<20080529150209.vnhlgwbjcog4wc04@mail.elegosoft.com> 
	<483EA20A.1E75.00D7.1@scires.com> 
	
Message-ID: 



Also if you can send me a test case I can build and run for the current pixmap problem, please do.


 - Jay



________________________________

From: jayk123 at hotmail.com
To: rcoleburn at scires.com; m3devel at elegosoft.com
Date: Thu, 29 May 2008 19:07:40 +0000
Subject: Re: [M3devel] _lowbits / _highbits (Pixmap bug-- 4.1 vs. buggy 5.x)




I have the 4.1 CD. I bought it from Critical Mass the normal legitimate way. I hacked my cm3.exe the other day to skip the license check since I can't find my key, it's very easy to do.
My observations agree with yours -- no source on the CD to the compiler, contrib includes the DEC 3.6 code.

What are the CM3IDE problems?

What is the pixmap behavior with build_standalone()?
I'm inclined to think this is not a Modula-3 problem but hard to debug remotely like this..

 - Jay



________________________________

Date: Thu, 29 May 2008 12:31:14 -0400
From: rcoleburn at scires.com
To: m3devel at elegosoft.com
Subject: Re: [M3devel] _lowbits / _highbits (Pixmap bug-- 4.1 vs. buggy 5.x)


Olaf / Jay:



My Reactor v4.1 CD has a source directory, but this folder does not contain the sources for the compiler or Reactor, just the libraries et al.



Here is a list of the archives in that folder:



BINUTILS.TGZ
m3-comm.TGZ
m3-db.TGZ
M3-DEMO.TGZ
M3-GAMES.TGZ
M3-LCTRN.TGZ
m3-libs.TGZ
M3-MAIL.TGZ
M3-OBLIQ.TGZ
M3-PKGTL.TGZ
M3-TOOLS.TGZ
m3-ui.TGZ
m3-www.TGZ
M3CC.TGZ
M3GDB.TGZ



There is also a CONTRIB folder with the following:



CVSUP
IDLM3
M2TOM3
M3DDD
M3PC
M3TOMIF
SRC-M3



If Farshad is ok with it, I can send you these files, but I would need his approval because we licensed this product from Critical Mass.



On a side note, I just built a new laptop computer from a fresh install of XP Pro.  I got the latest cm3 from the repository and rebuilt everything.  On this platform, my pixmaps show up with a "yellow" color everywhere "white" would normally show.  This is strange behavior.  I checked the .lst file and it is showing as a GUI program and the "hand.obj" is included.  Any ideas?



Since Jay has made good progress on fixing some of my major gripes, I am trying to use the new (current) cm3 for my project that is due for delivery at the end of July.  The new garbage collector seems to work much better on Windows than the one from 4.1.  Since we don't have an official stable release right now, I am going to have to draw a line in the sand at some point soon and take a snapshot of the cm3 source tree as the "official" development environment for future support of my project deliverables.



This latest problem with pixmaps on one platform and with CM3IDE on all XP platforms I've tested so far is disturbing.  As soon as I can get a handle on these problems, I think I am going to freeze my development environment for this project unless someone comes up with a major fix/change.



Regards,

Randy

>>> Olaf Wagner  5/29/2008 9:02 AM>>>
Quoting Jay :

> 1) Just fyi, NT386GNU didn't build with my fix, so it is disabled
> there only, and the bug could very well be present there.
> Er, then again, this stuff works differently for the gcc backend, so
>  I don't know, I'll have to look, and run the tests, not today.
> Which reminds me also, these symbols should be static hand.c, except
>  for NT386 -- the source can't tell, so it'll have to be a define
> from the m3makefile.
>
> 2) Can anyone confirm my history and the missing source?
> ie: Confirm that what is marked as 4.1 and 5.1 in CVS really is 4.1
> and 5.1? I don't think 4.1 is accurately marked.
> In particular, I don't think the 4.1 Stackx86.m3  is what 4.1
> actually shipped.
>
> 3) Or confirm my analysis that leads to the "accusation"? It was tedious.

I don't think that a complete 4.1 code set was ever imported into
the CVS CM3 repository; at least I don't remember we got the complete
4.1 code from Farshad Nayeri. What we got was 5.1 and it wasn't even
compilable by any existing M3 compiler. The gcc backend was so old
that it wasn't usable on any system we had. I think we extensively used
PM3 for booting and even incorporated some of PM3's code where
necessary.

I remember that I had several evaluation CDs from CM3 some years before
the open source release, so it may be that contents from one of these
CDs were imported as 4.1. I'm afraid it is not really traceable now.
We never got any versioned code from Critical Mass (I don't know what
they used for version control), only the bare source code.

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 jayk123 at hotmail.com  Fri May 30 08:45:03 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 30 May 2008 06:45:03 +0000
Subject: [M3devel] FW: NT386 environment variables (new NT386	snapshots)
In-Reply-To: <20080527155926.203bam89w4w0kgko@mail.elegosoft.com>
References: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
	
	<4823279D.1E75.00D7.1@scires.com>
	 
	<20080527155926.203bam89w4w0kgko@mail.elegosoft.com>
Message-ID: 


Yes, RTArgs and Env should work now on NT386.

NT386GNU actually probably doesn't yet implement "gui" apps, and NT386GNU console apps I expect work.
I should finish and test that, very small feature. More interesting for NT386MINGNU probably, but the same code to implement it and trivial.

The fix could be better/smaller, but probably ok.
In particular, the compiler generates a main that passes data to the runtime.
Sometimes main is right, sometimes wrong.
I left the compiler/main alone, but changed the NT386 runtime to always just fetch the data itself and always ignore the data it got from main. This might let some hypothetical bootstrapping scenarios keep working, using a new compiler to target an old runtime..

I'll switch to plain text and see how it goes.
Apparently that requires switching to "classic" Hotmail and I haven't seen if I can make it "sticky" or not.
We'll see. jay.krell at cornell.edu will work again shortly too but that won't help. :)
I have ONE other report of truncated mail.

 - Jay


> Date: Tue, 27 May 2008 15:59:26 +0200
> From: wagner
> To: m3devel; rforb
> Subject: Re: [M3devel] FW: NT386 environment variables (new NT386 snapshots)
>
> Quoting Jay 
>
>> truncated again...
>> m3support -- nothing interesting in any logs regarding my mail?
>> And nobody else uses hotmail, right?
>
> @Ronny, can you please check if our mail logs reveal any reason
> for Jay's mails to be truncated now and then?
>
>>> I will apply an easy fix.
>> done
>
> I'm not sure if this means that the issues concerning evnironment
> variable access (both via Env and RTArgs) are now fixed for NT386(GNU)...
> Can we forget about this issue?
>
> Olaf
>
....snip snip snip....


From rodney.bates at wichita.edu  Sat May 31 00:14:36 2008
From: rodney.bates at wichita.edu (Rodney M. Bates)
Date: Fri, 30 May 2008 17:14:36 -0500
Subject: [M3devel] function pointers and comparison to nil? mis-typed
 function pointers?
In-Reply-To: 
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
	
	
	
	
	<483B21F9.6070205@wichita.edu>
	
Message-ID: <48407C4C.5020407@wichita.edu>



Jay wrote:
>  > Mistaking the function's real code for a closure is a lot less likely
>  > than mistaking the function's real code for a trampoline. A trampoline
> 
> What is the danger in "mistaking" "real code" for a "trampoline"?
> They are both "real code".

This mistake would break correct implementation of the language.  It
would mean a runtime error, called for by the language semantics,
would go undetected.

(2.3.1: Since there is no way to determine statically whether the
value of a procedure parameter is local or global, assigning a local
procedure is a runtime rather than a static error.)

> The differences are:
>   - trampoline has limited lifetime -- unless it is heap allocated and

Not sure if this is what you meant, but the needed lifetime of either a
M3 closure or a trampoline are the same.  Either way, it is created on
the stack during a call to which a nested procedure is passed as parameter.
In Modula-3, the only reason to heap allocate would be if it is a trampoline,
to get around the possible non-executable state of the stack on some targets.
There is no need for heap lifetime semantics.

> garbage collected
>     ("real code" also has "limited lifetime", but relatively much 
> longer, if code can be unloaded, which it can be in many environments)
>   - the "real code" of nested functions has a different calling 
> convention than "real code" for non nested functions; it has an extra 
> parameter "somewhere", for the "static link"; in gcc C nested functions 
> on Cygwin/x86, this is in ecx

Again, this difference in calling convention is entirely independent of
whether M3 closures or trampolines are used.  They are different ways of
getting the environment pointer (ecx, on x86) loaded, before actually
transferring to the callee's code.

>  
> What do folks think about putting trampolines in executable garbage 
> collected heap?
> I think that's inefficient but I'm usually in the minority here 
> regarding the heap being inefficient.
>  
> One way or another, gcc makes C nested functions fairly portable, except 
> Apple's gcc on Darwin.
> Portability of -1 as a marker denoting "not code" is also dubious.
>  
> I think it stinks either way.
>  
> Anyone think coming up with "better" per-architecture markers is reasonable?

If we keep M3-style closures, the only architecture dependence is the value of
the marker word, that would be a dependence I could live with.  Trampolines,
in contrast, would have target opcodes in them, the bit layout of the trampoline
would vary, and the two pointers would almost surely be unaligned on many targets,
making m3gdb's job a lot harder.

>  
>  - Jay
> 
> ------------------------------------------------------------------------
> 
>  > Date: Mon, 26 May 2008 15:47:53 -0500
>  > From: rodney.bates at wichita.edu
>  > To: m3devel at elegosoft.com
>  > Subject: Re: [M3devel] function pointers and comparison to nil? 
> mis-typed function pointers?
>  >
>  >
>  >
>  > Jay wrote:
>  > > It stinks either way imho.
>  > > The portability is handled, somehow or another, by gcc's support for
>  > > nested functions.
>  > > For example on OpenBSD, they call mprotect to make the trampoline
>  > > executable -- expensive! and leaves a bit of a security hole.
>  > > On Linux you can sometimes mark the .exe as needing an executable 
> stack
>  > > or not. Similarly on Windows, linker has /nxcompat, /nxcompat:no 
> switch.
>  > > ATL on Windows puts trampolines in the heap and specifically makes 
> them
>  > > executable -- since the heap isn't necessarily executable either.
>  > > The -1 marker is also a bit of a portability problem but I guess in
>  > > practise it works out.
>  >
>  > Using trampolines would make this problem worse, perhaps much worse.
>  > Mistaking the function's real code for a closure is a lot less likely
>  > than mistaking the function's real code for a trampoline. A trampoline
>  > is, after all, always valid machine code on the executing processor.
>  > Not necessarily so for -1.
>  >
>  > > I'd be curious to see how it decodes on various processors.
>  > >
>  > > - Jay
>  > >
>  > --
>  > -------------------------------------------------------------
>  > Rodney M. Bates, retired assistant professor
>  > Dept. of Computer Science, Wichita State University
>  > Wichita, KS 67260-0083
>  > 316-978-3922
>  > rodney.bates at wichita.edu
> 

-- 
-------------------------------------------------------------
Rodney M. Bates, retired assistant professor
Dept. of Computer Science, Wichita State University
Wichita, KS 67260-0083
316-978-3922
rodney.bates at wichita.edu


From rodney.bates at wichita.edu  Sat May 31 01:17:02 2008
From: rodney.bates at wichita.edu (Rodney M. Bates)
Date: Fri, 30 May 2008 18:17:02 -0500
Subject: [M3devel] function pointers and comparison to nil? mis-typed
 function pointers?
In-Reply-To: 
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
	
	
Message-ID: <48408AEE.8090405@wichita.edu>

I still want to obsess on variables of type procedure/pointer-to-function,
because some of the discussion appears to me to maybe forgetting that each
language has a definition, and language implementors should adhere to it.
These are not the bad old days of the 1960s, when the only authority on the
semantics of a language was "whatever our particular compiler does".

The various languages have different rules for dealing with the problem of
dangling environment pointers in procedure variables, and these affect the
implementation choices.

In Pascal, procedures can be passed as parameters but never assigned,
regardless of whether nested or not.  It is a consequence of normal
lifetime rules that dangling environments can't happen.  The most obvious
implementation is to always use a traditional, two-word closure, nested or
not, so no marker is needed   This has an environment pointer and a code
pointer.

In Modula-2, procedures can be both passed and assigned, but only global
procedure values are allowed.  This can be checked statically and prevents
dangling environment pointers in a different way.  No environment pointer
is needed, so one-word pointers to code can be used as the implementation.

In Modula-3, you can pass any procedure but only assign a top-level procedure.
This precludes dangling environments in yet another way, that is more liberal
than either Pascal or Modula-2,, but requires a runtime check on procedure
assignments.  Modula-3 could be implemented using always two-word closures
with no marker, or the way it is.

In C, as extended by gcc, dangling environment pointers can happen and the
language makes no attempt to prevent them.  In the words of the gcc manual,
if you use one, "all hell will break loose".  Trampolines implement this
fine, while keeping pointers to global functions having the expected,
one-word representation.

My one handy Algol68 book has the usual tutorial language book problem: it
omits the cases you really need to look up.  It only states that there will
be problems if you use a dangling environment, but not whether the language
specifies this should be detected by the language, or whether "all hell will
break loose."  I'm guessing it's the latter. The implementation technique
Hendrik describes makes it a detected runtime error, but not unless/until
you try to use the lost environment.  This is more generous than Modula-3's rule.

And, of course, if your language is really dynamic, it could just say an
environment is always accessible, requiring many or all activation records
to be heap allocated.

Though it's obviously desirable,  Supporting all this for mixtures of
languages is, IMO, highly unrealistic without a lot of cooperation among
the developers of all the compilers of all the languages involved.  And this
involves both defining semantics and coming up with compatible implementations.
The horse is already long gone from the barn on other language definitions
and their compilers.

The system we now have is actually a quite good after-the-fact compromise.
It correctly implements Modula-3, and allows free intermixing of C and Modula-3
procedure/pointer-to-function values, as long as the values are not nested.
It also doesn't require an executable stack.  Not bad, considering we have
no influence on any other language definers or compiler writers.

Jay wrote:
>  
> Even though nested functions are a gcc extension to the C language, 
> email threads out there discuss Ada, Pascal, and even ! Modula-3 as 
> having nested functions, and that therefore deprecating the C language 
> feature doesn't "solve" the "problem".
>  
> I remain uncertain what, if anything, to do here.
>  - keep the -1 hack, do nothing
>     generalize it slightly to let targets pick "better" markers
>  - use gcc's supported for nested functions
>    (plus the integrated backend, not difficult)
>  
> Clearly this is a dilemna to more than just me. :)
>  
>  - Jay
>
-- 
-------------------------------------------------------------
Rodney M. Bates, retired assistant professor
Dept. of Computer Science, Wichita State University
Wichita, KS 67260-0083
316-978-3922
rodney.bates at wichita.edu


From hendrik at topoi.pooq.com  Sat May 31 15:29:24 2008
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sat, 31 May 2008 09:29:24 -0400
Subject: [M3devel] function pointers and comparison to nil? mis-typed
	function pointers?
In-Reply-To: <48408AEE.8090405@wichita.edu>
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
	
	
	<48408AEE.8090405@wichita.edu>
Message-ID: <20080531132924.GA30413@topoi.pooq.com>

On Fri, May 30, 2008 at 06:17:02PM -0500, Rodney M. Bates wrote:
> 
> My one handy Algol68 book has the usual tutorial language book problem: it
> omits the cases you really need to look up.  It only states that there will
> be problems if you use a dangling environment, but not whether the language
> specifies this should be detected by the language, or whether "all hell will
> break loose."  I'm guessing it's the latter. The implementation technique
> Hendrik describes makes it a detected runtime error, but not unless/until
> you try to use the lost environment.  This is more generous than Modula-3's 
> rule.

The actual Algol 68 definition does pronounce on this.  The CDC 
implementation was much more liberal than the language definition.

Every reference/variable and every procedure has a scope.  The scope of 
a variable is the level on the run-time stack at which it is allocated.  
Variables can be on the heap; this is global scope.  The scope of a 
procedure is the stack elvel at which its most local global identifier 
is bound.  Even if the identifier refers to an object on the heap, it is 
the level at which it is bound that counts.

There is a universal scope restriction:  No object can refer to a more 
local object.  The constraint in the language definition is applied on 
assignment.

I know of no Algol 68 implementation that I can say for sure implements 
this restriction with a run-time check.  Of course it can be done, 
either by tagging each pointer with an explicit mention of its stack 
level (which takes space) or by comparing its value and comparing it to 
various stack locations in a kind of search.

The first release of the CDC algol 68 compiler just allocated all 
variables on the heap, making the check unnecessary for safety.  
Programmers almost never wrote code that passed procedures out-of-scope.

Later releases performed static analysis to determine where it was safe 
to allocate in the stack (almost all the time), and used the mechanism I 
described earlier to check procedures when they were called if the 
static check didn't suffice..
> 
> And, of course, if your language is really dynamic, it could just say an
> environment is always accessible, requiring many or all activation records
> to be heap allocated.

Which was a proposal made for the original Algol 68, but was turned 
down.  I think it should have been accepted.  We would have had a 
strongly-typed Scheme ahead of its time.

-- hendrik



From jayk123 at hotmail.com  Thu May  1 04:00:30 2008
From: jayk123 at hotmail.com (Jay)
Date: Thu, 1 May 2008 02:00:30 +0000
Subject: [M3devel] tinderbox
Message-ID: 

PPC_DARWIN:
 
6551           -> archiving libpatternmatching.a6552          Undefined symbols:6553            "_GlobTree__MatchTest", referenced from:6554                _L_1 in GlobTree.mo6555                _L_1 in GlobTree.moPerhaps fallout from my parse.c change?
I'll look -- later.
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From hosking at cs.purdue.edu  Thu May  1 06:29:13 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 1 May 2008 00:29:13 -0400
Subject: [M3devel] tinderbox
In-Reply-To: 
References: 
Message-ID: 

I wonder if we need TREE_USED(p) for proc_addr(p)?

On Apr 30, 2008, at 10:00 PM, Jay wrote:

> PPC_DARWIN:
>
> 6551           -> archiving libpatternmatching.a
> 6552          Undefined symbols:
> 6553            "_GlobTree__MatchTest", referenced from:
> 6554                _L_1 in GlobTree.mo
> 6555                _L_1 in GlobTree.mo
>
>
> Perhaps fallout from my parse.c change?
> I'll look -- later.
>
>  - Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Thu May  1 12:36:53 2008
From: jayk123 at hotmail.com (Jay)
Date: Thu, 1 May 2008 10:36:53 +0000
Subject: [M3devel] tinderbox
In-Reply-To: 
References: 
	
Message-ID: 


so far I can confirm:
1) "no" other solution known for AMD64_LINUX
er, actually, public = (level != 0) should work
but a few other solutions didn't work -- e.g. -fvisibility=hidden has no affect as expected

2) DECL_PRESERVE_P and TREE_USED both sound promising
really, gcc is just a mess of hard to understand flags all over the place..

3) I can reproduce the problem on PPC_DARWIN
The "actual" uses of the functions have the names replaced by generated names -- ok, but bad for debugging
The references are then from the module information...so much for dead stripping?
I don't think those should be there.
I don't know why the names end up generated, maybe because of static = 1?
Not clear if static means "C file scope" or something else.

I'll keep poking -- waiting for my PPC_DARWIN build of m3cg (hm, I must have cleaned out the previous).

There is a nice optimization to my larger fix here, and it doesn't even go far enough, but for now checking (level != 0) will probably suffice.

 - Jay

CC: m3devel at elegosoft.com
From: hosking at cs.purdue.edu
To: jayk123 at hotmail.com
Subject: Re: [M3devel] tinderbox
Date: Thu, 1 May 2008 00:29:13 -0400

I wonder if we need TREE_USED(p) for proc_addr(p)?
 On Apr 30, 2008, at 10:00 PM, Jay wrote:PPC_DARWIN:
 
6551           -> archiving libpatternmatching.a
6552          Undefined symbols:
6553            "_GlobTree__MatchTest", referenced from:
6554                _L_1 in GlobTree.mo
6555                _L_1 in GlobTree.mo


Perhaps fallout from my parse.c change?
I'll look -- later.
 
 - Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From wagner at elegosoft.com  Thu May  1 22:55:06 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Thu, 01 May 2008 22:55:06 +0200
Subject: [M3devel] Popup Windows stalling regression tests on WinXP
In-Reply-To: <495318.48565.qm@web27105.mail.ukl.yahoo.com>
References: <495318.48565.qm@web27105.mail.ukl.yahoo.com>
Message-ID: <20080501225506.7gxpp2zh34w8ccgs@mail.elegosoft.com>

Quoting "Daniel Alejandro Benavides D." :

> Hi all:
> Olaf, I don't have the Win box here (just a Kubuntu one). But even   
> if you  don't want to send the file,  one can see the report file in  
>  a window. Should be  with two steps: The first click on the blue   
> label "Click here " in the first pop up window. That throws another   
> window with a label that you can click-on and actually see it
> Well I found with google the instruction to disable that error pop up:
> http://pcsupport.about.com/od/windowsxp/ht/disableerror.htm
> I hope this helps to you.

I now tried that, within a new VM (Win4BSD), and the tests ran
until p204, and then crashed (without popup window, which is good).
When I got home though, and had a look at the state of things, I had
about ten seconds before the VM rebootet :-(

So there's no more information right now; it seems that I'll have to run
this test within a debugger.

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 jayk123 at hotmail.com  Thu May  1 23:57:30 2008
From: jayk123 at hotmail.com (Jay)
Date: Thu, 1 May 2008 21:57:30 +0000
Subject: [M3devel] Popup Windows stalling regression tests on WinXP
In-Reply-To: <20080501225506.7gxpp2zh34w8ccgs@mail.elegosoft.com>
References: <495318.48565.qm@web27105.mail.ukl.yahoo.com>
	<20080501225506.7gxpp2zh34w8ccgs@mail.elegosoft.com>
Message-ID: 

Watch m3commit more closely :) -- the popup should be gone. You shouldn't have to twiddle any settings.
Admittedly, my testing was on AMD64 XP, which is really Server 2003, therefore could vary much from x86 XP.
I can try on x86 XP later (as in a day or two).
But really, based on the code before and after, I think it is gone everywhere.

 - Jay

> Date: Thu, 1 May 2008 22:55:06 +0200
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] Popup Windows stalling regression tests on WinXP
> 
> Quoting "Daniel Alejandro Benavides D." :
> 
> > Hi all:
> > Olaf, I don't have the Win box here (just a Kubuntu one). But even   
> > if you  don't want to send the file,  one can see the report file in  
> >  a window. Should be  with two steps: The first click on the blue   
> > label "Click here " in the first pop up window. That throws another   
> > window with a label that you can click-on and actually see it
> > Well I found with google the instruction to disable that error pop up:
> > http://pcsupport.about.com/od/windowsxp/ht/disableerror.htm
> > I hope this helps to you.
> 
> I now tried that, within a new VM (Win4BSD), and the tests ran
> until p204, and then crashed (without popup window, which is good).
> When I got home though, and had a look at the state of things, I had
> about ten seconds before the VM rebootet :-(
> 
> So there's no more information right now; it seems that I'll have to run
> this test within a debugger.
> 
> 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 jayk123 at hotmail.com  Fri May  2 11:33:50 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 2 May 2008 09:33:50 +0000
Subject: [M3devel] in search of decent editor for Mac/Linux?
In-Reply-To: <20080502090445.4496E10D495A@birch.elegosoft.com>
References: <20080502090445.4496E10D495A@birch.elegosoft.com>
Message-ID: 

Does anyone know of an IDE or editor on Linux or Mac OS Xwith a find-in-files feature anywhere nearly as goodas Visual C++ 5.0?
I have tried a bunch and they have all been disappointing.
It is very frustrating.
Monodevelop comes close, but it won't open .m3 files as text.
KDevelop -- can't navigate the results with the keyboard. I would prefer file path on every line, but ok I guess.
X Code -- no find-in-files feature at all that I could find!
NetBeans -- I forget, will have to try again, but I believe I was disappointed.
Eclipse -- ditto
Komodo -- promising, will have to try some more  I think maybe only forward nav through results, but ok  will have to see what the cost is 
JEdit -- I think it was this one, showed no results  until done. Results should appear as they are found.
Mac TextWrangler -- way too hard to specify directories to search in  as I recall, I forget if has keyboard nav.
 
MPW -- never seemed much good at all, despite avid following;
  doesn't run on current processors or operating systems, but it
  still works on mine
 
I'll have to again try:  NetBeans, Eclipse, Komodo, CodeWarrior, SlickEdit, search for other commercial ones.
  Though commercial ones won't tend to run on PPC_LINUX.
vi and emacs are not under consideration.I have tried them each many times and they are alwaysvery disappointing.
A really good file.open dialog would be nice too.
KDevelop is annoying in that it often beeps an error if I type a directory -- to go to it. It is case sensitive.
All the file.open dialogs I have seen on the Mac stink.
What do people use to actually be productive?Everything I've tried hasn't come close to Visual C++ 5.0.
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From wagner at elegosoft.com  Fri May  2 15:28:24 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Fri, 02 May 2008 15:28:24 +0200
Subject: [M3devel] Popup Windows stalling regression tests on WinXP
In-Reply-To: 
References: <495318.48565.qm@web27105.mail.ukl.yahoo.com>
	<20080501225506.7gxpp2zh34w8ccgs@mail.elegosoft.com>
	
Message-ID: <20080502152824.ltfkpvoy88cg0gc0@mail.elegosoft.com>

Quoting Jay :

> Watch m3commit more closely :) -- the popup should be gone. You   
> shouldn't have to twiddle any settings.
> Admittedly, my testing was on AMD64 XP, which is really Server 2003,  
>  therefore could vary much from x86 XP.
> I can try on x86 XP later (as in a day or two).
> But really, based on the code before and after, I think it is gone   
> everywhere.

Attached are my current results from NT386 m3tests. The popup is gone,
but the tests terminate at p204:

--- p204 --- IP address initializers
cd ..\src\p2\p204 && cm3 -build   -silent >NT386\stdout.build  
2>NT386\stderr.build
"h:\work\cm3\m3-sys\m3tests\src\m3makefile", line 248: quake runtime  
error: exit 1: cd ..\src\p2\p204 && cm3 -build   -silent  
 >NT386\stdout.build 2>NT386\stderr.build

--procedure--  -line-  -file---
exec               --  
run_test          248  h:\work\cm3\m3-sys\m3tests\src\m3makefile
p_test            292  h:\work\cm3\m3-sys\m3tests\src\m3makefile
include_dir       506  h:\work\cm3\m3-sys\m3tests\src\m3makefile
                     6  h:\work\cm3\m3-sys\m3tests\NT386\m3make.args

Fatal Error: package build failed

Not all tests in red are actually errors, as paths have changed
and expected results need to be adapted.

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 jayk123 at hotmail.com  Fri May  2 20:57:56 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 2 May 2008 18:57:56 +0000
Subject: [M3devel] Popup Windows stalling regression tests on WinXP
In-Reply-To: <20080502152824.ltfkpvoy88cg0gc0@mail.elegosoft.com>
References: <495318.48565.qm@web27105.mail.ukl.yahoo.com>
	<20080501225506.7gxpp2zh34w8ccgs@mail.elegosoft.com>
	 
	<20080502152824.ltfkpvoy88cg0gc0@mail.elegosoft.com>
Message-ID: 

 >but the tests terminate at p204:
fixed< exec("cm3")
> try_exec("cm3")
 
oh, maybe there had a minus sign before? I'll check..
 
-Jay



> Date: Fri, 2 May 2008 15:28:24 +0200> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: RE: [M3devel] Popup Windows stalling regression tests on WinXP> > Quoting Jay :> > > Watch m3commit more closely :) -- the popup should be gone. You > > shouldn't have to twiddle any settings.> > Admittedly, my testing was on AMD64 XP, which is really Server 2003, > > therefore could vary much from x86 XP.> > I can try on x86 XP later (as in a day or two).> > But really, based on the code before and after, I think it is gone > > everywhere.> > Attached are my current results from NT386 m3tests. The popup is gone,> but the tests terminate at p204:> > --- p204 --- IP address initializers> cd ..\src\p2\p204 && cm3 -build -silent >NT386\stdout.build > 2>NT386\stderr.build> "h:\work\cm3\m3-sys\m3tests\src\m3makefile", line 248: quake runtime > error: exit 1: cd ..\src\p2\p204 && cm3 -build -silent > >NT386\stdout.build 2>NT386\stderr.build> > --procedure-- -line- -file---> exec -- > run_test 248 h:\work\cm3\m3-sys\m3tests\src\m3makefile> p_test 292 h:\work\cm3\m3-sys\m3tests\src\m3makefile> include_dir 506 h:\work\cm3\m3-sys\m3tests\src\m3makefile> 6 h:\work\cm3\m3-sys\m3tests\NT386\m3make.args> > Fatal Error: package build failed> > Not all tests in red are actually errors, as paths have changed> and expected results need to be adapted.> > 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 jayk123 at hotmail.com  Sat May  3 10:11:35 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 3 May 2008 08:11:35 +0000
Subject: [M3devel] initializing with subarray(constant)
In-Reply-To: <20080503080455.80F4D70DA16@birch.elegosoft.com>
References: <20080503080455.80F4D70DA16@birch.elegosoft.com>
Message-ID: 

Anyone understand this and know how to fix?
 
Maybe the test passes with older/forked tools?
I'll try it with 3.6 and maybe 4.1.
 
It's very confusing that some of the "LV" and "LValue" functions take a parameter rhs : BOOLEAN.
We end up with
Variable.LoadLValue(p.obj) where p.obj is of type Constant.T
 
The fix reveals understanding of the problem and makes the specific case work, but I think a better fix must exist.
 
I think it'd be quite excellent for NARROW() failures to print the two types involved.
Currently there isn't "room" for the data -- we call abort("narrow failed").
I put in some RTIO calls in IsSubtype to get a better handle on what is happening.
Maybe m3gdb shows types well?
I'm too impatient to build it so I make do with cdb and gdb..
 
 - Jay



> Date: Sat, 3 May 2008 10:04:55 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/05/03 10:04:55> > Modified files:> cm3/m3-sys/m3front/src/exprs/: QualifyExpr.m3 > cm3/m3-sys/m3front/src/values/: Constant.i3 Constant.m3 > cm3/m3-sys/m3tests/src/: m3makefile > > Log message:> enough to fix test p2/p205, but needs more attention as the fix> seems to be at the wrong abstraction level and not cover every case> > in particular, confusion around lvalues vs. non-lvalues> in particular, read the comments in QualifyExpr.m3> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sat May  3 10:20:45 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 3 May 2008 08:20:45 +0000
Subject: [M3devel] FW: initializing with subarray(constant)
In-Reply-To: <20080503080455.80F4D70DA16@birch.elegosoft.com>
References: <20080503080455.80F4D70DA16@birch.elegosoft.com>
Message-ID: 

truncated again..


From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: initializing with subarray(constant)Date: Sat, 3 May 2008 08:11:35 +0000


Anyone understand this and know how to fix? Maybe the test passes with older/forked tools?I'll try it with 3.6 and maybe 4.1. It's very confusing that some of the "LV" and "LValue" functions take a parameter rhs : BOOLEAN.We end up withVariable.LoadLValue(p.obj) where p.obj is of type Constant.T The fix reveals understanding of the problem and makes the specific case work, but I think a better fix must exist. I think it'd be quite excellent for NARROW() failures to print the two types involved.Currently there isn't "room" for the data -- we call abort("narrow failed").I put in some RTIO calls in IsSubtype to get a better handle on what is happening.Maybe m3gdb shows types well?I'm too impatient to build it so I make do with cdb and gdb..  - Jay

> Date: Sat, 3 May 2008 10:04:55 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/05/03 10:04:55> > Modified files:> cm3/m3-sys/m3front/src/exprs/: QualifyExpr.m3 > cm3/m3-sys/m3front/src/values/: Constant.i3 Constant.m3 > cm3/m3-sys/m3tests/src/: m3makefile > > Log message:> enough to fix test p2/p205, but needs more attention as the fix> seems to be at the wrong abstraction level and not cover every case> > in particular, confusion around lvalues vs. non-lvalues> in particular, read the comments in QualifyExpr.m3> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sat May  3 10:47:31 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 3 May 2008 08:47:31 +0000
Subject: [M3devel] FW: tests vs. long-ago language change?
In-Reply-To: <20080503080455.80F4D70DA16@birch.elegosoft.com>
References: <20080503080455.80F4D70DA16@birch.elegosoft.com>
Message-ID: 






From: jayk123 at hotmail.comTo: jayk123 at hotmail.comSubject: tests vs. language changes?Date: Sat, 3 May 2008 08:45:59 +0000


Looking at tests p205, p206, p130p205 -- initialization involving subarray(constant open array)p206 -- initialization involving open arrayp130 -- use of type "UNSIGNED"I am led to believe that the language used to have an UNSIGNED type,but it was dropped long ago. p130 can just be thrown out.?Constant array constructors without index types couldarguably be considered fixed size with indices 0..n-1, butthey are in fact considered open, and this should remain asis.p206 is at least partly invalid.
The language definition and, barely, tutorial point to this.
I didn't check the green book.
 p205 suggests the same as p206 perhaps, perhaps thecompiler has this in mind, since there's a bunch of casesfor "types" of arrays -- open, fixed -- and the test goesdown an open path.Subarray.PrepLV is what I'm referring to in particular.The right fix for p205 might be for the case of "constant open"arrays to be implemented more like fixed arrays.In particular, avoid the call to CompileAddress.In particular, end up in case 3 instead of, I think 7.?
I'll maybe look into Subarray.PrepLV later, after some other tests..
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sat May  3 13:24:24 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 3 May 2008 11:24:24 +0000
Subject: [M3devel] FW: NT386 jmpbuf size?
In-Reply-To: <20080503111742.D803370DA16@birch.elegosoft.com>
References: <20080503111742.D803370DA16@birch.elegosoft.com>
Message-ID: 

Does anyone mind wasting an extra 32 bytes of stack in functions with a "try" on NT386?
jmpbuf is declared to be 64 bytes, but if you read the assembly, _setjmp doesn't use it all, and _setjmp3 might.
 
The difference is whether not a situation in which Modula-3 calls longjmp "past" C or C++ code, does the C __finally and C++ destructors run.
Presently I think with Modula-3, not.
Like, if Modula-3 passes some C/C++ a callback and the callback raises an exception and the C/C++ wanted to do some cleanup as the exception "goes by".
 
I think it's always been this and I guess nobody noticed, so maybe leave it alone and shrink the jmpbuf back to 32 bytes from 64?
 
Inflating from 8 to 13 also does get you some possible interop between NT386 and NT386GNU.
 
 - Jay



> Date: Sat, 3 May 2008 13:17:42 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/05/03 13:17:42> > Modified files:> cm3/m3-sys/m3middle/src/: Target.m3 > > Log message:> fix and unify NT386 jmpbuf/setjmp> > it APPEARS jmpbuf was understated for Visual C++> though it was probably ok> it appears if you compile C/C++, the compiler generates a call> to _setjmp3, which indeed uses more of the declared-16 jmpbuf> but that if we call _setjmp directly, it only uses 8> > Cygwin was overstated because their setjmp.h> appears to confuse bytes and ints, it only uses 13.> > So unify the former 8 and 13 to 16.> > As well, Cygwin provides aliased setjmp and _setjmp, so> unify on _setjmp> > NOTE that using _setjmp3 for Visual C++ is probably desirable> but cross that bridge another time, perhaps we'll just stop> using setjmp entirely> > therefore making the three NT386 flavors much more similar> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sat May  3 13:25:07 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 3 May 2008 11:25:07 +0000
Subject: [M3devel] FW: NT386 jmpbuf size?
In-Reply-To: <20080503111742.D803370DA16@birch.elegosoft.com>
References: <20080503111742.D803370DA16@birch.elegosoft.com>
Message-ID: 

truncated again...


From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: FW: NT386 jmpbuf size?Date: Sat, 3 May 2008 11:24:24 +0000


Does anyone mind wasting an extra 32 bytes of stack in functions with a "try" on NT386?jmpbuf is declared to be 64 bytes, but if you read the assembly, _setjmp doesn't use it all, and _setjmp3 might. The difference is whether not a situation in which Modula-3 calls longjmp "past" C or C++ code, does the C __finally and C++ destructors run.Presently I think with Modula-3, not.Like, if Modula-3 passes some C/C++ a callback and the callback raises an exception and the C/C++ wanted to do some cleanup as the exception "goes by". I think it's always been this and I guess nobody noticed, so maybe leave it alone and shrink the jmpbuf back to 32 bytes from 64? Inflating from 8 to 13 also does get you some possible interop between NT386 and NT386GNU.  - Jay

> Date: Sat, 3 May 2008 13:17:42 +0000> To: m3commit at elegosoft.com> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/05/03 13:17:42> > Modified files:> cm3/m3-sys/m3middle/src/: Target.m3 > > Log message:> fix and unify NT386 jmpbuf/setjmp> > it APPEARS jmpbuf was understated for Visual C++> though it was probably ok> it appears if you compile C/C++, the compiler generates a call> to _setjmp3, which indeed uses more of the declared-16 jmpbuf> but that if we call _setjmp directly, it only uses 8> > Cygwin was overstated because their setjmp.h> appears to confuse bytes and ints, it only uses 13.> > So unify the former 8 and 13 to 16.> > As well, Cygwin provides aliased setjmp and _setjmp, so> unify on _setjmp> > NOTE that using _setjmp3 for Visual C++ is probably desirable> but cross that bridge another time, perhaps we'll just stop> using setjmp entirely> > therefore making the three NT386 flavors much more similar> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From hosking at cs.purdue.edu  Sat May  3 15:33:12 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 3 May 2008 09:33:12 -0400
Subject: [M3devel] FW: initializing with subarray(constant)
In-Reply-To: 
References: <20080503080455.80F4D70DA16@birch.elegosoft.com>
	
Message-ID: 

This is on my list of things to do.  I have some idea what the fix is  
and just need to go in and do it.  Not enough time unfortunately.

On May 3, 2008, at 4:20 AM, Jay wrote:

> truncated again..
>
>
>
>
> From: jayk123 at hotmail.com
> To: m3devel at elegosoft.com
> Subject: initializing with subarray(constant)
> Date: Sat, 3 May 2008 08:11:35 +0000
>
> Anyone understand this and know how to fix?
>
> Maybe the test passes with older/forked tools?
> I'll try it with 3.6 and maybe 4.1.
>
> It's very confusing that some of the "LV" and "LValue" functions  
> take a parameter rhs : BOOLEAN.
> We end up with
> Variable.LoadLValue(p.obj) where p.obj is of type Constant.T
>
> The fix reveals understanding of the problem and makes the specific  
> case work, but I think a better fix must exist.
>
> I think it'd be quite excellent for NARROW() failures to print the  
> two types involved.
> Currently there isn't "room" for the data -- we call abort("narrow  
> failed").
> I put in some RTIO calls in IsSubtype to get a better handle on what  
> is happening.
> Maybe m3gdb shows types well?
> I'm too impatient to build it so I make do with cdb and gdb..
>
>  - Jay
>
>
>
> > Date: Sat, 3 May 2008 10:04:55 +0000
> > To: m3commit at elegosoft.com
> > From: jkrell at elego.de
> > Subject: [M3commit] CVS Update: cm3
> >
> > CVSROOT: /usr/cvs
> > Changes by: jkrell at birch. 08/05/03 10:04:55
> >
> > Modified files:
> > cm3/m3-sys/m3front/src/exprs/: QualifyExpr.m3
> > cm3/m3-sys/m3front/src/values/: Constant.i3 Constant.m3
> > cm3/m3-sys/m3tests/src/: m3makefile
> >
> > Log message:
> > enough to fix test p2/p205, but needs more attention as the fix
> > seems to be at the wrong abstraction level and not cover every case
> >
> > in particular, confusion around lvalues vs. non-lvalues
> > in particular, read the comments in QualifyExpr.m3
> >
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From wagner at elegosoft.com  Sat May  3 16:13:00 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Sat, 03 May 2008 16:13:00 +0200
Subject: [M3devel] m3tests reporting broken? was: Re: more m3tests changes
In-Reply-To: 
References: <20080502185151.B3DC110D4959@birch.elegosoft.com>
	
Message-ID: <20080503161300.3krg8bcfv0oo8w4k@mail.elegosoft.com>

Quoting Jay :

> Olaf, disable these for nt386?

Without having had a close look what the tests are about, I'd
say no; I'd rather have target-specific overrides for
expected values. I'd thought about it at least, but didn't get
round to implement it. Something like if sdtdout.build.TARGET
exists use that on TARGET.

BTW, almost all tests have turned to green in the tinderbox;
as I don't think somebody has fixed the underlying issues,
one of us must have broken the reporting :-/

Olaf

> - Jay
>
>> Date: Fri, 2 May 2008 20:51:51 +0000> To: m3commit at elegosoft.com>   
>> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> >   
>> CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/05/02 20:51:51> >   
>> Modified files:> cm3/m3-sys/m3tests/src/e0/e029/: stderr.build   
>> stdout.build > cm3/m3-sys/m3tests/src/p0/p004/: stdout.build >   
>> cm3/m3-sys/m3tests/src/p0/p051/: stdout.build >   
>> cm3/m3-sys/m3tests/src/p2/p204/: stderr.build stdout.build >   
>> cm3/m3-sys/m3tests/src/p2/p205/: stderr.build >   
>> cm3/m3-sys/m3tests/src/p2/p207/: stdout.build > > Log message:>   
>> where posix and win32 vary for now, take posix, from ppc_darwin>
-- 
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 jayk123 at hotmail.com  Sat May  3 16:37:04 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 3 May 2008 14:37:04 +0000
Subject: [M3devel] m3tests reporting broken? was: Re: more m3tests
	changes
In-Reply-To: <20080503161300.3krg8bcfv0oo8w4k@mail.elegosoft.com>
References: <20080502185151.B3DC110D4959@birch.elegosoft.com>
	 
	<20080503161300.3krg8bcfv0oo8w4k@mail.elegosoft.com>
Message-ID: 

Which is all green? Tinderbox and test status are both mixed.
I have to go for a bit. Maybe more later, but currently I don't know what's recently broken, only longer term problems with a small number of tests.
 
 - Jay



> Date: Sat, 3 May 2008 16:13:00 +0200> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: m3tests reporting broken? was: Re: more m3tests changes> > Quoting Jay :> > > Olaf, disable these for nt386?> > Without having had a close look what the tests are about, I'd> say no; I'd rather have target-specific overrides for> expected values. I'd thought about it at least, but didn't get> round to implement it. Something like if sdtdout.build.TARGET> exists use that on TARGET.> > BTW, almost all tests have turned to green in the tinderbox;> as I don't think somebody has fixed the underlying issues,> one of us must have broken the reporting :-/> > Olaf> > > - Jay> >> >> Date: Fri, 2 May 2008 20:51:51 +0000> To: m3commit at elegosoft.com> > >> From: jkrell at elego.de> Subject: [M3commit] CVS Update: cm3> > > >> CVSROOT: /usr/cvs> Changes by: jkrell at birch. 08/05/02 20:51:51> > > >> Modified files:> cm3/m3-sys/m3tests/src/e0/e029/: stderr.build > >> stdout.build > cm3/m3-sys/m3tests/src/p0/p004/: stdout.build > > >> cm3/m3-sys/m3tests/src/p0/p051/: stdout.build > > >> cm3/m3-sys/m3tests/src/p2/p204/: stderr.build stdout.build > > >> cm3/m3-sys/m3tests/src/p2/p205/: stderr.build > > >> cm3/m3-sys/m3tests/src/p2/p207/: stdout.build > > Log message:> > >> where posix and win32 vary for now, take posix, from ppc_darwin>> -- > 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  Sat May  3 16:55:51 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Sat, 03 May 2008 16:55:51 +0200
Subject: [M3devel] m3tests reporting broken? was: Re: more m3tests
	changes
In-Reply-To: 
References: <20080502185151.B3DC110D4959@birch.elegosoft.com>
	
	<20080503161300.3krg8bcfv0oo8w4k@mail.elegosoft.com>
	
Message-ID: <20080503165551.3qh7w25etcwkgk8c@mail.elegosoft.com>

Quoting Jay :

> Which is all green? Tinderbox and test status are both mixed.
> I have to go for a bit. Maybe more later, but currently I don't know  
>  what's recently broken, only longer term problems with a small   
> number of tests.

All the release builds should be orange (and were until yesterday)
as some of the tests fail. See one of

http://tinderbox.elegosoft.com/tinderbox/cm3/status.html
http://tinderbox.elegosoft.com/tinderbox/all_trees.panel.html
http://tinderbox.elegosoft.com/tinderbox/all_trees.express.html
http://tinderbox.elegosoft.com/tinderbox/all_trees.quickparse.html

The lastok columns are more or less standalone, they are usually green
and turn to red in case of an incompatible runtime change (which is
intended and OK).

The release-build columns combine bulding of cm3 from the last release
and running all available tests; as some of those usually fail, they
are really not expected to be green, but orange, which means: build
OK, tests failed.

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 May  3 17:00:47 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Sat, 03 May 2008 17:00:47 +0200
Subject: [M3devel] FW: NT386 jmpbuf size?
In-Reply-To: 
References: <20080503111742.D803370DA16@birch.elegosoft.com>
	
Message-ID: <20080503170047.ocn9oj5li8gscg88@mail.elegosoft.com>

If there is a chance that more bytes are actually used under
special circumstances, I'd vote to make the jmp_buf large enough
to avoid memory corruption. I'm not sure if the extra bytes
will have performance impacts on thread switching, but I think
a special instruction could be used for copying them so that
it should be not much difference. I'm no expert on the Intel
processors though...

Quoting Jay :

> truncated again...
>
> From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: FW: NT386  
>  jmpbuf size?Date: Sat, 3 May 2008 11:24:24 +0000
>
>
> Does anyone mind wasting an extra 32 bytes of stack in functions   
> with a "try" on NT386?jmpbuf is declared to be 64 bytes, but if you   
> read the assembly, _setjmp doesn't use it all, and _setjmp3 might.   
> The difference is whether not a situation in which Modula-3 calls   
> longjmp "past" C or C++ code, does the C __finally and C++   
> destructors run.Presently I think with Modula-3, not.Like, if   
> Modula-3 passes some C/C++ a callback and the callback raises an   
> exception and the C/C++ wanted to do some cleanup as the exception   
> "goes by". I think it's always been this and I guess nobody noticed,  
>  so maybe leave it alone and shrink the jmpbuf back to 32 bytes from  
>  64? Inflating from 8 to 13 also does get you some possible interop   
> between NT386 and NT386GNU.  - 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 jayk123 at hotmail.com  Sun May  4 06:02:25 2008
From: jayk123 at hotmail.com (Jay)
Date: Sun, 4 May 2008 04:02:25 +0000
Subject: [M3devel] test e020?
Message-ID: 

This is half just a sanity check that I am restoring my damage properly.
These can't both be right, right?
http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3tests/src/e0/e020/stdout.build?rev=1.2;content-type=text%2Fplain
Fatal Error: package build failed
http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3tests/src/e0/e020/stderr.pgm?rev=1.1;content-type=text%2Fplain
 
****** illegal cycle in super types:***    child  = [0x10000294  _t0xd6319321  typecode=   0  Main.W]***    parent = [0x1000022c  _t0x5a31ef26  typecode=   0  Main.V]***    parent = [0x10000294  _t0xd6319321  typecode=   0  Main.W]***
****** runtime error:***    unable to initialize runtime types***
 
Presumably neither is ideal, it should fail to build, with a better error message, but the currentbehavior is worse than both, it fails at runtime with what I suspect is stack overflow frominfinite recursion.
C:\dev2\cm3\m3-sys\m3tests\src\e0\e020>NT386\pgm.exe
****** runtime error:***    A runtime error occurred.***    pc = 0x1002050b = FindSlot + 0xb in ..\src\runtime\common\RTType.m3***
Stack trace:   FP         PC      Procedure---------  ---------  -------------------------------  0x32fec  0x1002679e  SystemError + 0x66 in ..\src\runtime\NT386\RTSignal.m3  0x3301c  0x1002050b  FindSlot + 0xb in ..\src\runtime\common\RTType.m3  0x3304c  0x1001f430  FindType + 0x28 in ..\src\runtime\common\RTType.m3  0x33088  0x1001f901  FinishTypecell + 0x67 in ..\src\runtime\common\RTType.m3  0x330b4  0x1001f489  FindType + 0x81 in ..\src\runtime\common\RTType.m3  0x330f0  0x1001f901  FinishTypecell + 0x67 in ..\src\runtime\common\RTType.m3  0x3311c  0x1001f489  FindType + 0x81 in ..\src\runtime\common\RTType.m3  0x33158  0x1001f901  FinishTypecell + 0x67 in ..\src\runtime\common\RTType.m3  0x33184  0x1001f489  FindType + 0x81 in ..\src\runtime\common\RTType.m3  0x331c0  0x1001f901  FinishTypecell + 0x67 in ..\src\runtime\common\RTType.m3.........  .........  ... more frames ...
 
agreed?
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sun May  4 08:27:00 2008
From: jayk123 at hotmail.com (Jay)
Date: Sun, 4 May 2008 06:27:00 +0000
Subject: [M3devel] FW: NT386 jmpbuf size?
In-Reply-To: <20080503170047.ocn9oj5li8gscg88@mail.elegosoft.com>
References: <20080503111742.D803370DA16@birch.elegosoft.com>
	 
	<20080503170047.ocn9oj5li8gscg88@mail.elegosoft.com>
Message-ID: 

I BELIEVE:
  It is statically knowable:
    msvcrt _setjmp uses 8 words
    msvcrt _setjmp3 uses 16 
    cygwin uses I think 13 -- their header is just wrong by a factor of 4 
   You can tell from a mix of disassembly and source -- disassembly for msvcrt, disassembly and source for cygwin.
 
It isn't runtime variables that make the difference.
(well, the 16 case might sometimes shrink, it appears)
 
What is less clear is if _setjmp or _setjmp3 should be used.
It appears that any use of setjmp in C or C++ uses _setjmp3.
 
The difference appears to be whether or not the generally expected interaction with C __finally and C++ destructors and exception handling occurs.
"generally expected' but also "generally unknown".
 
One might argue that if C/C++ can afford the extra 32 bytes, then so can Modula-3 BUT C/C++ have MUCH more efficient exception handling mechanisms available and so setjmp is much less used there. They get by with around 3 words for a frame with exception handling on x86, and with zero overheard everywhere else.
 
The C/C++ behavior might also be affected by command line options. I'd have to experiment more..
 
To clarify, imagine Modula-3 gave a callback function to some C++ and that C++ has a local with a destructor, and the Modula-3 raises an exception.
Does the C++ destructor run or not?
With _setjmp probably not, with _setjmp3 probably.
 
Similarly, imagine some C++ gives some Modula-3 a callback and the C++ raises an exception.
Do the Modula-3 FINALLY blocks run?
 
Similar dilemna really on all platforms.
There relatively recently an ABI for C++ exception handling that maybe Modula-3 should use.
 
 - Jay



> Date: Sat, 3 May 2008 17:00:47 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] FW: NT386 jmpbuf size?> > If there is a chance that more bytes are actually used under> special circumstances, I'd vote to make the jmp_buf large enough> to avoid memory corruption. I'm not sure if the extra bytes> will have performance impacts on thread switching, but I think> a special instruction could be used for copying them so that> it should be not much difference. I'm no expert on the Intel> processors though...> > Quoting Jay :> > > truncated again...> >> > From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: FW: NT386 > > jmpbuf size?Date: Sat, 3 May 2008 11:24:24 +0000> >> >> > Does anyone mind wasting an extra 32 bytes of stack in functions > > with a "try" on NT386?jmpbuf is declared to be 64 bytes, but if you > > read the assembly, _setjmp doesn't use it all, and _setjmp3 might. > > The difference is whether not a situation in which Modula-3 calls > > longjmp "past" C or C++ code, does the C __finally and C++ > > destructors run.Presently I think with Modula-3, not.Like, if > > Modula-3 passes some C/C++ a callback and the callback raises an > > exception and the C/C++ wanted to do some cleanup as the exception > > "goes by". I think it's always been this and I guess nobody noticed, > > so maybe leave it alone and shrink the jmpbuf back to 32 bytes from > > 64? Inflating from 8 to 13 also does get you some possible interop > > between NT386 and NT386GNU. - 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 jayk123 at hotmail.com  Sun May  4 13:17:23 2008
From: jayk123 at hotmail.com (Jay)
Date: Sun, 4 May 2008 11:17:23 +0000
Subject: [M3devel] order of warnings, or even to have any?
In-Reply-To: <20080503170047.ocn9oj5li8gscg88@mail.elegosoft.com>
References: <20080503111742.D803370DA16@birch.elegosoft.com>
	 
	<20080503170047.ocn9oj5li8gscg88@mail.elegosoft.com>
Message-ID: 

C:\dev2\cm3\m3-sys\m3tests\src\p0\p004>cm3--- building in NT386 ---
new source -> compiling Main.m3"..\Main.m3", line 35: warning: exception is never raised: Main.e"..\Main.m3", line 9: warning: exception is never raised: "..\Main.m3", line 59: warning: unreachable statement"..\Main.m3", line 68: warning: unreachable statement"..\Main.m3", line 71: warning: unreachable statement"..\Main.m3", line 82: warning: unreachable statement"..\Main.m3", line 86: warning: unreachable statement"..\Main.m3", line 64: warning: unreachable statement8 warnings encountered -> linking pgm.exelink @_m3responsefile0.txt 2>&1 > pgm.lstmt /nologo /manifest pgm.exe.manifest /outputresource:pgm.exe;1.\pgm.exe >stdout.pgm.raw 2>stderr.pgm.raw
 
 
Does the order of the warnings matter?
Does the test even care if they are printed?
The expected output and the actual output are in a different order.
Neither are in order by line number, though the expected output is closer.
The order is consistent on all platforms?
No. LINUXLIBC6 and NT386 output in a different order.
This doesn't seem all that important..
 
  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From wagner at elegosoft.com  Sun May  4 13:46:25 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Sun, 04 May 2008 13:46:25 +0200
Subject: [M3devel] FW: NT386 jmpbuf size?
In-Reply-To: 
References: <20080503111742.D803370DA16@birch.elegosoft.com>
	
	<20080503170047.ocn9oj5li8gscg88@mail.elegosoft.com>
	
Message-ID: <20080504134625.az0c3vdkgs8gwsgk@mail.elegosoft.com>

Quoting Jay :

> I BELIEVE:
>   It is statically knowable:
>     msvcrt _setjmp uses 8 words
>     msvcrt _setjmp3 uses 16
>     cygwin uses I think 13 -- their header is just wrong by a factor of 4
>    You can tell from a mix of disassembly and source -- disassembly   
> for msvcrt, disassembly and source for cygwin.
>
> It isn't runtime variables that make the difference.
> (well, the 16 case might sometimes shrink, it appears)
>
> What is less clear is if _setjmp or _setjmp3 should be used.
> It appears that any use of setjmp in C or C++ uses _setjmp3.
>
> The difference appears to be whether or not the generally expected   
> interaction with C __finally and C++ destructors and exception   
> handling occurs.
> "generally expected' but also "generally unknown".
>
> One might argue that if C/C++ can afford the extra 32 bytes, then so  
>  can Modula-3 BUT C/C++ have MUCH more efficient exception handling   
> mechanisms available and so setjmp is much less used there. They get  
>  by with around 3 words for a frame with exception handling on x86,   
> and with zero overheard everywhere else.
>
> The C/C++ behavior might also be affected by command line options.   
> I'd have to experiment more..
>
> To clarify, imagine Modula-3 gave a callback function to some C++   
> and that C++ has a local with a destructor, and the Modula-3 raises   
> an exception.
> Does the C++ destructor run or not?
> With _setjmp probably not, with _setjmp3 probably.

IMO it should.

> Similarly, imagine some C++ gives some Modula-3 a callback and the   
> C++ raises an exception.
> Do the Modula-3 FINALLY blocks run?

Dito.

> Similar dilemna really on all platforms.
> There relatively recently an ABI for C++ exception handling that   
> maybe Modula-3 should use.

I think we should start on the safe side and try to optimize later
if needed. So I'd vote for 16 bytes and use of _setjmp3.

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 May  4 13:49:37 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Sun, 04 May 2008 13:49:37 +0200
Subject: [M3devel] order of warnings, or even to have any?
In-Reply-To: 
References: <20080503111742.D803370DA16@birch.elegosoft.com>
	
	<20080503170047.ocn9oj5li8gscg88@mail.elegosoft.com>
	
Message-ID: <20080504134937.ejznr1mcqo0sw0ck@mail.elegosoft.com>

Quoting Jay :

> C:\dev2\cm3\m3-sys\m3tests\src\p0\p004>cm3--- building in NT386 ---
> new source -> compiling Main.m3"..\Main.m3", line 35: warning:   
> exception is never raised: Main.e"..\Main.m3", line 9: warning:   
> exception is never raised: "..\Main.m3", line 59: warning:   
> unreachable statement"..\Main.m3", line 68: warning: unreachable   
> statement"..\Main.m3", line 71: warning: unreachable   
> statement"..\Main.m3", line 82: warning: unreachable   
> statement"..\Main.m3", line 86: warning: unreachable   
> statement"..\Main.m3", line 64: warning: unreachable statement8   
> warnings encountered -> linking pgm.exelink @_m3responsefile0.txt   
> 2>&1 > pgm.lstmt /nologo /manifest pgm.exe.manifest   
> /outputresource:pgm.exe;1.\pgm.exe >stdout.pgm.raw 2>stderr.pgm.raw
>
> Does the order of the warnings matter?
> Does the test even care if they are printed?
> The expected output and the actual output are in a different order.
> Neither are in order by line number, though the expected output is closer.
> The order is consistent on all platforms?
> No. LINUXLIBC6 and NT386 output in a different order.
> This doesn't seem all that important..

I had noticed that, too, and postponed it at not important (enough)
now to look into, though it would be interesting _why_ the error
output is different between platforms.

If there is a reason for it and it cannot be fixed easily within the
compiler, this would be one case for a target-specific expect file.

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 jayk123 at hotmail.com  Sun May  4 15:06:29 2008
From: jayk123 at hotmail.com (Jay)
Date: Sun, 4 May 2008 13:06:29 +0000
Subject: [M3devel] tinderbox diff direction reversed
Message-ID: 

fyi, I reversed the diff direction in m3tests.
It seems more natural to me to
diff expected actual
and see what changed.
Obviously it's not a huge difference (!), it works either way and no diff is the goal, but in case anyone was used to the other way or insists on it.
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From wagner at elegosoft.com  Sun May  4 15:19:30 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Sun, 04 May 2008 15:19:30 +0200
Subject: [M3devel] tinderbox diff direction reversed
In-Reply-To: 
References: 
Message-ID: <20080504151930.mwlopiv400s4c8ok@mail.elegosoft.com>

Quoting Jay :

> fyi, I reversed the diff direction in m3tests.
> It seems more natural to me to
> diff expected actual
> and see what changed.
> Obviously it's not a huge difference (!), it works either way and no  
>  diff is the goal, but in case anyone was used to the other way or   
> insists on it.

That's OK.

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



From hosking at cs.purdue.edu  Sun May  4 15:19:48 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 4 May 2008 09:19:48 -0400
Subject: [M3devel] order of warnings, or even to have any?
In-Reply-To: 
References: <20080503111742.D803370DA16@birch.elegosoft.com>
	
	<20080503170047.ocn9oj5li8gscg88@mail.elegosoft.com>
	
Message-ID: 

Why the difference on different targets?

Antony Hosking | Associate 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 May 4, 2008, at 7:17 AM, Jay wrote:

> C:\dev2\cm3\m3-sys\m3tests\src\p0\p004>cm3
> --- building in NT386 ---
> new source -> compiling Main.m3
> "..\Main.m3", line 35: warning: exception is never raised: Main.e
> "..\Main.m3", line 9: warning: exception is never raised: 
> "..\Main.m3", line 59: warning: unreachable statement
> "..\Main.m3", line 68: warning: unreachable statement
> "..\Main.m3", line 71: warning: unreachable statement
> "..\Main.m3", line 82: warning: unreachable statement
> "..\Main.m3", line 86: warning: unreachable statement
> "..\Main.m3", line 64: warning: unreachable statement
> 8 warnings encountered
>  -> linking pgm.exe
> link @_m3responsefile0.txt 2>&1 > pgm.lst
> mt /nologo /manifest pgm.exe.manifest /outputresource:pgm.exe;1
> .\pgm.exe >stdout.pgm.raw 2>stderr.pgm.raw
>
>
> Does the order of the warnings matter?
> Does the test even care if they are printed?
> The expected output and the actual output are in a different order.
> Neither are in order by line number, though the expected output is  
> closer.
> The order is consistent on all platforms?
> No. LINUXLIBC6 and NT386 output in a different order.
> This doesn't seem all that important..
>
>   - Jay
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sun May  4 15:24:58 2008
From: jayk123 at hotmail.com (Jay)
Date: Sun, 4 May 2008 13:24:58 +0000
Subject: [M3devel] order of warnings, or even to have any?
In-Reply-To: 
References: <20080503111742.D803370DA16@birch.elegosoft.com>
	
	<20080503170047.ocn9oj5li8gscg88@mail.elegosoft.com>
	
	
Message-ID: 

not yet known..


CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] order of warnings, or even to have any?Date: Sun, 4 May 2008 09:19:48 -0400Why the difference on different targets?



Antony Hosking | Associate 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 May 4, 2008, at 7:17 AM, Jay wrote:

C:\dev2\cm3\m3-sys\m3tests\src\p0\p004>cm3--- building in NT386 ---new source -> compiling Main.m3"..\Main.m3", line 35: warning: exception is never raised: Main.e"..\Main.m3", line 9: warning: exception is never raised: "..\Main.m3", line 59: warning: unreachable statement"..\Main.m3", line 68: warning: unreachable statement"..\Main.m3", line 71: warning: unreachable statement"..\Main.m3", line 82: warning: unreachable statement"..\Main.m3", line 86: warning: unreachable statement"..\Main.m3", line 64: warning: unreachable statement8 warnings encountered -> linking pgm.exelink @_m3responsefile0.txt 2>&1 > pgm.lstmt /nologo /manifest pgm.exe.manifest /outputresource:pgm.exe;1.\pgm.exe >stdout.pgm.raw 2>stderr.pgm.raw  Does the order of the warnings matter?Does the test even care if they are printed?The expected output and the actual output are in a different order.Neither are in order by line number, though the expected output is closer.The order is consistent on all platforms?No. LINUXLIBC6 and NT386 output in a different order.This doesn't seem all that important..   - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From wagner at elegosoft.com  Sun May  4 15:30:40 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Sun, 04 May 2008 15:30:40 +0200
Subject: [M3devel] Tinderbox tests on NT386
Message-ID: <20080504153040.6jvrkwlkms80c8wc@mail.elegosoft.com>

In case anybody wonders about

http://www.opencm3.net/m3tests/m3tests-NT386-2008-05-03-22-37-30.html

and following reports, I'm currently trying to run the m3tests on
NT386 in an older version to get a usable reference for the current
problems. There have been so many changes that I'm unable to keep
up with them, and some things seem to be broken.

Except for the problems in m3tests, the rest of the tinderbox
regression test framework seems to be working now for regular
regression tests on Windows XP with Cygwin. Some initialization
scripts are needed for running them, but that was to be expected.

The m3tests reports for the last two days for all target platforms
in the tinderbox are not correct (at least, if they show no errors);
there have been some structural changes and more things need to be
adapted. Jay Krell is working on it.

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 jayk123 at hotmail.com  Sun May  4 16:17:28 2008
From: jayk123 at hotmail.com (Jay)
Date: Sun, 4 May 2008 14:17:28 +0000
Subject: [M3devel] Tinderbox tests on NT386
In-Reply-To: <20080504153040.6jvrkwlkms80c8wc@mail.elegosoft.com>
References: <20080504153040.6jvrkwlkms80c8wc@mail.elegosoft.com>
Message-ID: 

Here is a QUICK rundown.
p004 I /assume/ this is the same on all platforms     but didn't check
p051 extra print out when building specific to NT386,     fixed, but at great loss of diagnosability IF     there are errors in compiling C code
Specifically, given  cl -nologo -c foo.c bar.cthe compiler printsfoo.cbar.c
to the same channel as errors (stderr or stdout)So when running the tests, NT386.common has a hack to throwout all C compiler output.
p116b floating point issue, probably same on all platformsp126 dittop172 dittop186 ditto
p204 compiler bug I think this also fails on other platforms but obviously differently; needs investigation
p205 was failing but I put in a fix and then Tony put in a better fix
 p206 I think this fails the same on all platforms, but I      I think it behaves correctly and just update the     std{out,err}.{pgm,build} files; since it is a compilation     failure, it should be an 'e' instead of 'p', not     a big deal I think
p207 probably fall out from longint not being 64 bits     probably should disable just for this platform 
r001 This test works in general but is a problem for the     Tinderbox in general. LINUXLIBC6 and NT386 should be     passing, but I think probably it should be turned off.     In particular, the way programs exit when they     fail an assertion and/or have an unhandled exception     varies by platform, in terms of what they actually print.
r002 needs investigation; I think it's an infinite recursion     or just uses a lot of stack, and I THINK I saw it fail     on other platforms 
r003 I hadn't looked at this AT ALL but probably the same as r001,     except more interesting?     There is a test that catches an assertion failure, maybe     do that here?     As well, there is the annoying idea of making per-platform      std* files. Hard to maintain.
 
r004 ditto -- since there are four of these, and potentially more,     maybe worth coming up with something
Something I considered, but rejected, back when I thought r001was the only one, is a runtime switch M3 at consistentAbort orsomesuch that will just cleanly exit(0) or exit(1) in these cases,and not print a callstack. I don't want to foul up thesystem TOO much for the sake of testing, but testabilityis an expected design goal...
Again, this is an issue across platforms. LINUXLIBC6 seems to print something slightly differently every time you run these. Test.common has a gross workaround.
 The checked in std* files are from FreeBSD.
e020 unknown so far
e026 was a problem on all platforms and should be ok now;     was a compiler bug, I fixed
e029 unknown so far
I think p209 and p210 are the most important currently.And then maybe e020, e029.
I expect to be "out" all of Sunday.
The Tinderbox SHOULD be OK now.Sorry...
 
 - Jay



> Date: Sun, 4 May 2008 15:30:40 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] Tinderbox tests on NT386> > In case anybody wonders about> > http://www.opencm3.net/m3tests/m3tests-NT386-2008-05-03-22-37-30.html> > and following reports, I'm currently trying to run the m3tests on> NT386 in an older version to get a usable reference for the current> problems. There have been so many changes that I'm unable to keep> up with them, and some things seem to be broken.> > Except for the problems in m3tests, the rest of the tinderbox> regression test framework seems to be working now for regular> regression tests on Windows XP with Cygwin. Some initialization> scripts are needed for running them, but that was to be expected.> > The m3tests reports for the last two days for all target platforms> in the tinderbox are not correct (at least, if they show no errors);> there have been some structural changes and more things need to be> adapted. Jay Krell is working on it.> > 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 jayk123 at hotmail.com  Sun May  4 16:22:57 2008
From: jayk123 at hotmail.com (Jay)
Date: Sun, 4 May 2008 14:22:57 +0000
Subject: [M3devel] Tinderbox tests on NT386
In-Reply-To: 
References: <20080504153040.6jvrkwlkms80c8wc@mail.elegosoft.com>
	
Message-ID: 

I'm also seeing lots of failures in p137
 
--- p137 --- bit insert and extract
--- ../src/p1/p137/stderr.pgm 2008-05-04 00:10:01.925067200 -0700+++ ../src/p1/p137/NT386/stderr.pgm 2008-05-04 03:59:42.382247900 -0700@@ -1,3 +1,418 @@+************************ ERROR: 282863103 instead of 819734015+************************ ERROR: 14427647 instead of 819734015...
lotsYou never saw that Olaf?
I should have printed the test names below, it's too hard to read with just numbers..
Anyway, just looking busy I guess, no matter, we'll get around to them..
(And sorry about the Win32 bitmap stuff, I haven't forgotten...)
 
Hm..maybe related? Older version of m3tests statically links to libm3/m3core but current version dynamically links.
That'd be cool if it correlates -- if p137 and the bitmap stuff are the same problem.
I'll go try p137 again both ways.
 - Jay


From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Sun, 4 May 2008 14:17:28 +0000Subject: Re: [M3devel] Tinderbox tests on NT386


Here is a QUICK rundown.p004 I /assume/ this is the same on all platforms     but didn't checkp051 extra print out when building specific to NT386,     fixed, but at great loss of diagnosability IF     there are errors in compiling C codeSpecifically, given  cl -nologo -c foo.c bar.cthe compiler printsfoo.cbar.cto the same channel as errors (stderr or stdout)So when running the tests, NT386.common has a hack to throwout all C compiler output.p116b floating point issue, probably same on all platformsp126 dittop172 dittop186 dittop204 compiler bug I think this also fails on other platforms but obviously differently; needs investigationp205 was failing but I put in a fix and then Tony put in a better fix p206 I think this fails the same on all platforms, but I      I think it behaves correctly and just update the     std{out,err}.{pgm,build} files; since it is a compilation     failure, it should be an 'e' instead of 'p', not     a big deal I thinkp207 probably fall out from longint not being 64 bits     probably should disable just for this platform r001 This test works in general but is a problem for the     Tinderbox in general. LINUXLIBC6 and NT386 should be     passing, but I think probably it should be turned off.     In particular, the way programs exit when they     fail an assertion and/or have an unhandled exception     varies by platform, in terms of what they actually print.r002 needs investigation; I think it's an infinite recursion     or just uses a lot of stack, and I THINK I saw it fail     on other platforms r003 I hadn't looked at this AT ALL but probably the same as r001,     except more interesting?     There is a test that catches an assertion failure, maybe     do that here?     As well, there is the annoying idea of making per-platform      std* files. Hard to maintain. r004 ditto -- since there are four of these, and potentially more,     maybe worth coming up with somethingSomething I considered, but rejected, back when I thought r001was the only one, is a runtime switch M3 at consistentAbort orsomesuch that will just cleanly exit(0) or exit(1) in these cases,and not print a callstack. I don't want to foul up thesystem TOO much for the sake of testing, but testabilityis an expected design goal...Again, this is an issue across platforms. LINUXLIBC6 seems to print something slightly differently every time you run these. Test.common has a gross workaround. The checked in std* files are from FreeBSD.e020 unknown so fare026 was a problem on all platforms and should be ok now;     was a compiler bug, I fixede029 unknown so farI think p209 and p210 are the most important currently.And then maybe e020, e029.I expect to be "out" all of Sunday.The Tinderbox SHOULD be OK now.Sorry...  - Jay

> Date: Sun, 4 May 2008 15:30:40 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] Tinderbox tests on NT386> > In case anybody wonders about> > http://www.opencm3.net/m3tests/m3tests-NT386-2008-05-03-22-37-30.html> > and following reports, I'm currently trying to run the m3tests on> NT386 in an older version to get a usable reference for the current> problems. There have been so many changes that I'm unable to keep> up with them, and some things seem to be broken.> > Except for the problems in m3tests, the rest of the tinderbox> regression test framework seems to be working now for regular> regression tests on Windows XP with Cygwin. Some initialization> scripts are needed for running them, but that was to be expected.> > The m3tests reports for the last two days for all target platforms> in the tinderbox are not correct (at least, if they show no errors);> there have been some structural changes and more things need to be> adapted. Jay Krell is working on it.> > 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 jayk123 at hotmail.com  Sun May  4 16:25:26 2008
From: jayk123 at hotmail.com (Jay)
Date: Sun, 4 May 2008 14:25:26 +0000
Subject: [M3devel] Tinderbox tests on NT386
In-Reply-To: 
References: <20080504153040.6jvrkwlkms80c8wc@mail.elegosoft.com>
	 
Message-ID: 

 > That'd be cool if it correlates. 
 > I'll go try p137 again both ways.  It does!
Standalone p137 and dynamic p137 have very different results.
 
 - Jay


From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comSubject: RE: [M3devel] Tinderbox tests on NT386Date: Sun, 4 May 2008 14:22:57 +0000


I'm also seeing lots of failures in p137 --- p137 --- bit insert and extract--- ../src/p1/p137/stderr.pgm 2008-05-04 00:10:01.925067200 -0700+++ ../src/p1/p137/NT386/stderr.pgm 2008-05-04 03:59:42.382247900 -0700@@ -1,3 +1,418 @@+************************ ERROR: 282863103 instead of 819734015+************************ ERROR: 14427647 instead of 819734015...lotsYou never saw that Olaf?I should have printed the test names below, it's too hard to read with just numbers..Anyway, just looking busy I guess, no matter, we'll get around to them..(And sorry about the Win32 bitmap stuff, I haven't forgotten...) Hm..maybe related? Older version of m3tests statically links to libm3/m3core but current version dynamically links.That'd be cool if it correlates -- if p137 and the bitmap stuff are the same problem.I'll go try p137 again both ways. - Jay


From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Sun, 4 May 2008 14:17:28 +0000Subject: Re: [M3devel] Tinderbox tests on NT386

Here is a QUICK rundown.p004 I /assume/ this is the same on all platforms     but didn't checkp051 extra print out when building specific to NT386,     fixed, but at great loss of diagnosability IF     there are errors in compiling C codeSpecifically, given  cl -nologo -c foo.c bar.cthe compiler printsfoo.cbar.cto the same channel as errors (stderr or stdout)So when running the tests, NT386.common has a hack to throwout all C compiler output.p116b floating point issue, probably same on all platformsp126 dittop172 dittop186 dittop204 compiler bug I think this also fails on other platforms but obviously differently; needs investigationp205 was failing but I put in a fix and then Tony put in a better fix p206 I think this fails the same on all platforms, but I      I think it behaves correctly and just update the     std{out,err}.{pgm,build} files; since it is a compilation     failure, it should be an 'e' instead of 'p', not     a big deal I thinkp207 probably fall out from longint not being 64 bits     probably should disable just for this platform r001 This test works in general but is a problem for the     Tinderbox in general. LINUXLIBC6 and NT386 should be     passing, but I think probably it should be turned off.     In particular, the way programs exit when they     fail an assertion and/or have an unhandled exception     varies by platform, in terms of what they actually print.r002 needs investigation; I think it's an infinite recursion     or just uses a lot of stack, and I THINK I saw it fail     on other platforms r003 I hadn't looked at this AT ALL but probably the same as r001,     except more interesting?     There is a test that catches an assertion failure, maybe     do that here?     As well, there is the annoying idea of making per-platform      std* files. Hard to maintain. r004 ditto -- since there are four of these, and potentially more,     maybe worth coming up with somethingSomething I considered, but rejected, back when I thought r001was the only one, is a runtime switch M3 at consistentAbort orsomesuch that will just cleanly exit(0) or exit(1) in these cases,and not print a callstack. I don't want to foul up thesystem TOO much for the sake of testing, but testabilityis an expected design goal...Again, this is an issue across platforms. LINUXLIBC6 seems to print something slightly differently every time you run these. Test.common has a gross workaround. The checked in std* files are from FreeBSD.e020 unknown so fare026 was a problem on all platforms and should be ok now;     was a compiler bug, I fixede029 unknown so farI think p209 and p210 are the most important currently.And then maybe e020, e029.I expect to be "out" all of Sunday.The Tinderbox SHOULD be OK now.Sorry...  - Jay

> Date: Sun, 4 May 2008 15:30:40 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] Tinderbox tests on NT386> > In case anybody wonders about> > http://www.opencm3.net/m3tests/m3tests-NT386-2008-05-03-22-37-30.html> > and following reports, I'm currently trying to run the m3tests on> NT386 in an older version to get a usable reference for the current> problems. There have been so many changes that I'm unable to keep> up with them, and some things seem to be broken.> > Except for the problems in m3tests, the rest of the tinderbox> regression test framework seems to be working now for regular> regression tests on Windows XP with Cygwin. Some initialization> scripts are needed for running them, but that was to be expected.> > The m3tests reports for the last two days for all target platforms> in the tinderbox are not correct (at least, if they show no errors);> there have been some structural changes and more things need to be> adapted. Jay Krell is working on it.> > 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 jayk123 at hotmail.com  Sun May  4 16:38:03 2008
From: jayk123 at hotmail.com (Jay)
Date: Sun, 4 May 2008 14:38:03 +0000
Subject: [M3devel] Tinderbox tests on NT386
In-Reply-To: 
References: <20080504153040.6jvrkwlkms80c8wc@mail.elegosoft.com>
	  
	
Message-ID: 

I bet this is related to importing (dynamically linking) data -- _lowbits. _highbits and such.
Dynamically linking data is a bad idea -- the codegen pretty much must vary depending on if you are going to statically link or dynamically link, whereas with functions you can just pretend you always statically link and it works out well enough, just with small lost optimization.
I don't see getting to this today but should be within a few days.
 
There is a compromise in that you can make all data that might be dynamically linked pointers to what the data otherwise would have been.
And then static linking is what loses efficiency -- unnecessary pointer deref.
Replace all foo with *pfoo, essentially.
 
The next step would be to change foo to *GetFoo(), even slower, but normal for dynamic linking.
 
So, anyway, I'll change __lowbits and such to pointers, on NT386.
I think somehow dynamic linking on other systems copes with this, but I bet it is not pretty if so.
Dynamic linking on NT writes to generally one page for .so to update one copy of a pointer to all the relevant addresses.
No writing walk through the code is needed.
If you are willing to walk through the code and patch it up, then you can dynamically link data without varying the code.
Or maybe just with -fPIC, all data references are slowed down, in case they are dynamically linked.
 
I wouldn't be surprised if this has been broken since 4.1..anytime m3core was dynamically linked on NT. Anyone want to try that?
I should have noticed this earlier, as I did go hunting around for how some of this works.
 
Anyway, I could be wrong.
We'll known soon enough now.
 
 - Jay


From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Sun, 4 May 2008 14:25:26 +0000Subject: Re: [M3devel] Tinderbox tests on NT386


 > That'd be cool if it correlates.  > I'll go try p137 again both ways.  It does!Standalone p137 and dynamic p137 have very different results.  - Jay


From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comSubject: RE: [M3devel] Tinderbox tests on NT386Date: Sun, 4 May 2008 14:22:57 +0000

I'm also seeing lots of failures in p137 --- p137 --- bit insert and extract--- ../src/p1/p137/stderr.pgm 2008-05-04 00:10:01.925067200 -0700+++ ../src/p1/p137/NT386/stderr.pgm 2008-05-04 03:59:42.382247900 -0700@@ -1,3 +1,418 @@+************************ ERROR: 282863103 instead of 819734015+************************ ERROR: 14427647 instead of 819734015...lotsYou never saw that Olaf?I should have printed the test names below, it's too hard to read with just numbers..Anyway, just looking busy I guess, no matter, we'll get around to them..(And sorry about the Win32 bitmap stuff, I haven't forgotten...) Hm..maybe related? Older version of m3tests statically links to libm3/m3core but current version dynamically links.That'd be cool if it correlates -- if p137 and the bitmap stuff are the same problem.I'll go try p137 again both ways. - Jay


From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Sun, 4 May 2008 14:17:28 +0000Subject: Re: [M3devel] Tinderbox tests on NT386

Here is a QUICK rundown.p004 I /assume/ this is the same on all platforms     but didn't checkp051 extra print out when building specific to NT386,     fixed, but at great loss of diagnosability IF     there are errors in compiling C codeSpecifically, given  cl -nologo -c foo.c bar.cthe compiler printsfoo.cbar.cto the same channel as errors (stderr or stdout)So when running the tests, NT386.common has a hack to throwout all C compiler output.p116b floating point issue, probably same on all platformsp126 dittop172 dittop186 dittop204 compiler bug I think this also fails on other platforms but obviously differently; needs investigationp205 was failing but I put in a fix and then Tony put in a better fix p206 I think this fails the same on all platforms, but I      I think it behaves correctly and just update the     std{out,err}.{pgm,build} files; since it is a compilation     failure, it should be an 'e' instead of 'p', not     a big deal I thinkp207 probably fall out from longint not being 64 bits     probably should disable just for this platform r001 This test works in general but is a problem for the     Tinderbox in general. LINUXLIBC6 and NT386 should be     passing, but I think probably it should be turned off.     In particular, the way programs exit when they     fail an assertion and/or have an unhandled exception     varies by platform, in terms of what they actually print.r002 needs investigation; I think it's an infinite recursion     or just uses a lot of stack, and I THINK I saw it fail     on other platforms r003 I hadn't looked at this AT ALL but probably the same as r001,     except more interesting?     There is a test that catches an assertion failure, maybe     do that here?     As well, there is the annoying idea of making per-platform      std* files. Hard to maintain. r004 ditto -- since there are four of these, and potentially more,     maybe worth coming up with somethingSomething I considered, but rejected, back when I thought r001was the only one, is a runtime switch M3 at consistentAbort orsomesuch that will just cleanly exit(0) or exit(1) in these cases,and not print a callstack. I don't want to foul up thesystem TOO much for the sake of testing, but testabilityis an expected design goal...Again, this is an issue across platforms. LINUXLIBC6 seems to print something slightly differently every time you run these. Test.common has a gross workaround. The checked in std* files are from FreeBSD.e020 unknown so fare026 was a problem on all platforms and should be ok now;     was a compiler bug, I fixede029 unknown so farI think p209 and p210 are the most important currently.And then maybe e020, e029.I expect to be "out" all of Sunday.The Tinderbox SHOULD be OK now.Sorry...  - Jay

> Date: Sun, 4 May 2008 15:30:40 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] Tinderbox tests on NT386> > In case anybody wonders about> > http://www.opencm3.net/m3tests/m3tests-NT386-2008-05-03-22-37-30.html> > and following reports, I'm currently trying to run the m3tests on> NT386 in an older version to get a usable reference for the current> problems. There have been so many changes that I'm unable to keep> up with them, and some things seem to be broken.> > Except for the problems in m3tests, the rest of the tinderbox> regression test framework seems to be working now for regular> regression tests on Windows XP with Cygwin. Some initialization> scripts are needed for running them, but that was to be expected.> > The m3tests reports for the last two days for all target platforms> in the tinderbox are not correct (at least, if they show no errors);> there have been some structural changes and more things need to be> adapted. Jay Krell is working on it.> > 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  Sun May  4 16:49:26 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Sun, 04 May 2008 16:49:26 +0200
Subject: [M3devel] Tinderbox tests on NT386
In-Reply-To: 
References: <20080504153040.6jvrkwlkms80c8wc@mail.elegosoft.com>
	
	
Message-ID: <20080504164926.ufqus5lpcg0o84gg@mail.elegosoft.com>

Quoting Jay :

> I'm also seeing lots of failures in p137
>
> --- p137 --- bit insert and extract
> --- ../src/p1/p137/stderr.pgm 2008-05-04 00:10:01.925067200 -0700+++  
>  ../src/p1/p137/NT386/stderr.pgm 2008-05-04 03:59:42.382247900   
> -0700@@ -1,3 +1,418 @@+************************ ERROR: 282863103   
> instead of 819734015+************************ ERROR: 14427647   
> instead of 819734015...
> lotsYou never saw that Olaf?

p137 was OK on 2008-05-01. Use

   http://www.opencm3.net/m3tests/m3tests-NT386-2008-05-03-22-37-30.html

as a reference; I won't overwrite that anymore now.
Current results of m3tests will be reported to

   http://www.opencm3.net/m3tests/m3tests-NT386-2008-05-03-22-37-31.html

soon (sorry for the wrong dates, I'm re-using existing workspaces
here; it would take too long otherwise).

I'll be out soon, but will have another look later this evening how
things develop.

Olaf


> I should have printed the test names below, it's too hard to read   
> with just numbers..
> Anyway, just looking busy I guess, no matter, we'll get around to them..
> (And sorry about the Win32 bitmap stuff, I haven't forgotten...)
>
> Hm..maybe related? Older version of m3tests statically links to   
> libm3/m3core but current version dynamically links.
> That'd be cool if it correlates -- if p137 and the bitmap stuff are   
> the same problem.
> I'll go try p137 again both ways.
>  - Jay
>
>
> From: jayk123 at hotmail.comTo: wagner at elegosoft.com;   
> m3devel at elegosoft.comDate: Sun, 4 May 2008 14:17:28 +0000Subject:   
> Re: [M3devel] Tinderbox tests on NT386
>
>
> Here is a QUICK rundown.p004 I /assume/ this is the same on all   
> platforms     but didn't checkp051 extra print out when building   
> specific to NT386,     fixed, but at great loss of diagnosability IF  
>      there are errors in compiling C codeSpecifically, given  cl   
> -nologo -c foo.c bar.cthe compiler printsfoo.cbar.cto the same   
> channel as errors (stderr or stdout)So when running the tests,   
> NT386.common has a hack to throwout all C compiler output.p116b   
> floating point issue, probably same on all platformsp126 dittop172   
> dittop186 dittop204 compiler bug I think this also fails on other   
> platforms but obviously differently; needs investigationp205 was   
> failing but I put in a fix and then Tony put in a better fix p206 I   
> think this fails the same on all platforms, but I      I think it   
> behaves correctly and just update the     std{out,err}.{pgm,build}   
> files; since it is a compilation     failure, it should be an 'e'   
> instead of 'p', not     a big deal I thinkp207 probably fall out   
> from longint not being 64 bits     probably should disable just for   
> this platform r001 This test works in general but is a problem for   
> the     Tinderbox in general. LINUXLIBC6 and NT386 should be       
> passing, but I think probably it should be turned off.     In   
> particular, the way programs exit when they     fail an assertion   
> and/or have an unhandled exception     varies by platform, in terms   
> of what they actually print.r002 needs investigation; I think it's   
> an infinite recursion     or just uses a lot of stack, and I THINK I  
>  saw it fail     on other platforms r003 I hadn't looked at this AT   
> ALL but probably the same as r001,     except more interesting?       
> There is a test that catches an assertion failure, maybe     do that  
>  here?     As well, there is the annoying idea of making  
> per-platform       std* files. Hard to maintain. r004 ditto -- since  
> there are  four of these, and potentially more,     maybe worth  
> coming up with  somethingSomething I considered, but rejected, back  
> when I thought  r001was the only one, is a runtime switch  
> M3 at consistentAbort  orsomesuch that will just cleanly exit(0) or  
> exit(1) in these  cases,and not print a callstack. I don't want to  
> foul up thesystem  TOO much for the sake of testing, but  
> testabilityis an expected  design goal...Again, this is an issue  
> across platforms. LINUXLIBC6  seems to print something slightly  
> differently every time you run  these. Test.common has a gross  
> workaround. The checked in std* files  are from FreeBSD.e020 unknown  
> so fare026 was a problem on all  platforms and should be ok now;      
> was a compiler bug, I fixede029  unknown so farI think p209 and p210  
> are the most important  currently.And then maybe e020, e029.I expect  
> to be "out" all of  Sunday.The Tinderbox SHOULD be OK now.Sorry...   
> - Jay
>
>> Date: Sun, 4 May 2008 15:30:40 +0200> From: wagner at elegosoft.com>   
>> To: m3devel at elegosoft.com> Subject: [M3devel] Tinderbox tests on   
>> NT386> > In case anybody wonders about> >   
>> http://www.opencm3.net/m3tests/m3tests-NT386-2008-05-03-22-37-30.html> >   
>> and following reports, I'm currently trying to run the m3tests on>   
>> NT386 in an older version to get a usable reference for the   
>> current> problems. There have been so many changes that I'm unable   
>> to keep> up with them, and some things seem to be broken.> > Except  
>>  for the problems in m3tests, the rest of the tinderbox> regression  
>>  test framework seems to be working now for regular> regression   
>> tests on Windows XP with Cygwin. Some initialization> scripts are   
>> needed for running them, but that was to be expected.> > The   
>> m3tests reports for the last two days for all target platforms> in   
>> the tinderbox are not correct (at least, if they show no errors);>   
>> there have been some structural changes and more things need to be>  
>>  adapted. Jay Krell is working on it.> > Olaf> -- > Olaf Wagner --   
>> elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12,   
>> 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177   
>> 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com |   
>> Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister:   
>> Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194>



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



From jayk123 at hotmail.com  Sun May  4 17:46:57 2008
From: jayk123 at hotmail.com (Jay)
Date: Sun, 4 May 2008 15:46:57 +0000
Subject: [M3devel] pixmap problem
In-Reply-To: 
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu> 
	
Message-ID: 

Randy, Please try with /current/ source, as of this morning Sunday May 4 -- the changes are ALL in NT386.common, so you MUST use MY config files, which are checked in verbatim, or you should be able edit whatever config files you are using.
 
(It's not really a config file issue, don't blame the general confusion people have with them.)
 
I'll try to try later, but I don't have the source right now, gotta look on other machines, and I think it's on a machine on loan.
  Or send it to me again.
I'd also like to know if this worked with 4.1, or with any release that offered dynamic linking to m3core.dll, on Windows.
  I recall a claim that it did. If today's change fixes it, I should be able to investigate 4.1.
3.6 did not have such linking.
If today's change does not help, well, I still plan on debugging it at some point..
 
If you aren't current and getting so is difficult, just send the attachment again, it's easy for me to test.
 
Thanks,
 - Jay


From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rcoleburn at scires.comDate: Sat, 19 Jan 2008 08:52:08 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem


I can repro the two different behaviors on XP.I was going to try on PPC_DARWIN but I guess Tony's info suffices. I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. Debugging here is a big humungous pain.NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)And bundles look pretty simple, a bundle is just a generated source file with a constant in it.Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something. The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for? I have to say this is very surprising. I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so.The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: pointer to msvcrt!fopenpointer to msvcrt!fclosenullpointer to kernel32!Sleep But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo.But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo.That doesn't work for data though. There's no ability to intervenve like that.So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it.And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.However that would suck perf in order to make an uncommon case work.I hope Modula-3 doesn't do that either. :)Though I guess since this global data in question...maybe it is rare??? Later, - Jay

> From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 03:09:47 -0500> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] pixmap problem> > Looks fine to me on I386_DARWIN.> > On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:> > > > 

Need to know the score, the latest news, or you need your Hotmail?-get your "fix" Check it out. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sun May  4 18:06:25 2008
From: jayk123 at hotmail.com (Jay)
Date: Sun, 4 May 2008 16:06:25 +0000
Subject: [M3devel] Tinderbox tests on NT386
In-Reply-To: <20080504164926.ufqus5lpcg0o84gg@mail.elegosoft.com>
References: <20080504153040.6jvrkwlkms80c8wc@mail.elegosoft.com>
	
	 
	<20080504164926.ufqus5lpcg0o84gg@mail.elegosoft.com>
Message-ID: 

Olaf, You have p137 failing now, which is/was consistent with me.And still p051 failing for you. I fixed that, but  the fix is half in NT386.common, and half in m3tests. You take that  for each build? The situation there is/was kind of  unfortunate -- all compiler output is quashed, errors and all.
  If we could have per-platform std* files,  this would be one to do that for. You know,  if stdout.pgm.PLATFORM exists, use it, otherwise stdout.pgm.  Problem is whenever the output changes, updating them all.
 
 - Jay



> Date: Sun, 4 May 2008 16:49:26 +0200> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: RE: [M3devel] Tinderbox tests on NT386> > Quoting Jay :> > > I'm also seeing lots of failures in p137> >> > --- p137 --- bit insert and extract> > --- ../src/p1/p137/stderr.pgm 2008-05-04 00:10:01.925067200 -0700+++ > > ../src/p1/p137/NT386/stderr.pgm 2008-05-04 03:59:42.382247900 > > -0700@@ -1,3 +1,418 @@+************************ ERROR: 282863103 > > instead of 819734015+************************ ERROR: 14427647 > > instead of 819734015...> > lotsYou never saw that Olaf?> > p137 was OK on 2008-05-01. Use> > http://www.opencm3.net/m3tests/m3tests-NT386-2008-05-03-22-37-30.html> > as a reference; I won't overwrite that anymore now.> Current results of m3tests will be reported to> > http://www.opencm3.net/m3tests/m3tests-NT386-2008-05-03-22-37-31.html> > soon (sorry for the wrong dates, I'm re-using existing workspaces> here; it would take too long otherwise).> > I'll be out soon, but will have another look later this evening how> things develop.> > Olaf> > > > I should have printed the test names below, it's too hard to read > > with just numbers..> > Anyway, just looking busy I guess, no matter, we'll get around to them..> > (And sorry about the Win32 bitmap stuff, I haven't forgotten...)> >> > Hm..maybe related? Older version of m3tests statically links to > > libm3/m3core but current version dynamically links.> > That'd be cool if it correlates -- if p137 and the bitmap stuff are > > the same problem.> > I'll go try p137 again both ways.> > - Jay> >> >> > From: jayk123 at hotmail.comTo: wagner at elegosoft.com; > > m3devel at elegosoft.comDate: Sun, 4 May 2008 14:17:28 +0000Subject: > > Re: [M3devel] Tinderbox tests on NT386> >> >> > Here is a QUICK rundown.p004 I /assume/ this is the same on all > > platforms but didn't checkp051 extra print out when building > > specific to NT386, fixed, but at great loss of diagnosability IF > > there are errors in compiling C codeSpecifically, given cl > > -nologo -c foo.c bar.cthe compiler printsfoo.cbar.cto the same > > channel as errors (stderr or stdout)So when running the tests, > > NT386.common has a hack to throwout all C compiler output.p116b > > floating point issue, probably same on all platformsp126 dittop172 > > dittop186 dittop204 compiler bug I think this also fails on other > > platforms but obviously differently; needs investigationp205 was > > failing but I put in a fix and then Tony put in a better fix p206 I > > think this fails the same on all platforms, but I I think it > > behaves correctly and just update the std{out,err}.{pgm,build} > > files; since it is a compilation failure, it should be an 'e' > > instead of 'p', not a big deal I thinkp207 probably fall out > > from longint not being 64 bits probably should disable just for > > this platform r001 This test works in general but is a problem for > > the Tinderbox in general. LINUXLIBC6 and NT386 should be > > passing, but I think probably it should be turned off. In > > particular, the way programs exit when they fail an assertion > > and/or have an unhandled exception varies by platform, in terms > > of what they actually print.r002 needs investigation; I think it's > > an infinite recursion or just uses a lot of stack, and I THINK I > > saw it fail on other platforms r003 I hadn't looked at this AT > > ALL but probably the same as r001, except more interesting? > > There is a test that catches an assertion failure, maybe do that > > here? As well, there is the annoying idea of making > > per-platform std* files. Hard to maintain. r004 ditto -- since > > there are four of these, and potentially more, maybe worth > > coming up with somethingSomething I considered, but rejected, back > > when I thought r001was the only one, is a runtime switch > > M3 at consistentAbort orsomesuch that will just cleanly exit(0) or > > exit(1) in these cases,and not print a callstack. I don't want to > > foul up thesystem TOO much for the sake of testing, but > > testabilityis an expected design goal...Again, this is an issue > > across platforms. LINUXLIBC6 seems to print something slightly > > differently every time you run these. Test.common has a gross > > workaround. The checked in std* files are from FreeBSD.e020 unknown > > so fare026 was a problem on all platforms and should be ok now; > > was a compiler bug, I fixede029 unknown so farI think p209 and p210 > > are the most important currently.And then maybe e020, e029.I expect > > to be "out" all of Sunday.The Tinderbox SHOULD be OK now.Sorry... > > - Jay> >> >> Date: Sun, 4 May 2008 15:30:40 +0200> From: wagner at elegosoft.com> > >> To: m3devel at elegosoft.com> Subject: [M3devel] Tinderbox tests on > >> NT386> > In case anybody wonders about> > > >> http://www.opencm3.net/m3tests/m3tests-NT386-2008-05-03-22-37-30.html> > > >> and following reports, I'm currently trying to run the m3tests on> > >> NT386 in an older version to get a usable reference for the > >> current> problems. There have been so many changes that I'm unable > >> to keep> up with them, and some things seem to be broken.> > Except > >> for the problems in m3tests, the rest of the tinderbox> regression > >> test framework seems to be working now for regular> regression > >> tests on Windows XP with Cygwin. Some initialization> scripts are > >> needed for running them, but that was to be expected.> > The > >> m3tests reports for the last two days for all target platforms> in > >> the tinderbox are not correct (at least, if they show no errors);> > >> there have been some structural changes and more things need to be> > >> adapted. Jay Krell is working on it.> > Olaf> -- > Olaf Wagner -- > >> elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, > >> 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 > >> 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | > >> Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: > >> Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194>> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Mon May  5 16:59:27 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Mon, 05 May 2008 10:59:27 -0400
Subject: [M3devel] pixmap problem
In-Reply-To: 
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
Message-ID: <481EE888.1E75.00D7.1@scires.com>

Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files
or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy

>>> Jay  5/4/2008 11:46 AM >>>
Randy, Please try with /current/ source, as of this morning Sunday May
4 -- the changes are ALL in NT386.common, so you MUST use MY config
files, which are checked in verbatim, or you should be able edit
whatever config files you are using.
 
(It's not really a config file issue, don't blame the general confusion
people have with them.)
 
I'll try to try later, but I don't have the source right now, gotta
look on other machines, and I think it's on a machine on loan.
  Or send it to me again.
I'd also like to know if this worked with 4.1, or with any release that
offered dynamic linking to m3core.dll, on Windows.
  I recall a claim that it did. If today's change fixes it, I should be
able to investigate 4.1.
3.6 did not have such linking.
If today's change does not help, well, I still plan on debugging it at
some point..
 
If you aren't current and getting so is difficult, just send the
attachment again, it's easy for me to test.
 
Thanks,
 - Jay

From: jayk123 at hotmail.com 
To: hosking at cs.purdue.edu; rcoleburn at scires.com 
Date: Sat, 19 Jan 2008 08:52:08 +0000
CC: m3devel at elegosoft.com 
Subject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.
I was going to try on PPC_DARWIN but I guess Tony's info suffices.
 
I tried rolling hand.c back to before I changed (months/year ago),
since it is involved in bit twiddling, no change, phew.
 
Debugging here is a big humungous pain.
NT386 has good stacks and line numbers, but no locals or type info, I'd
really sometime like to get Codeview info into those .objs...I think it
is documented well enough, but still not necessarily easy, or maybe have
a C generating backend partly for this reason (and to bring up more
targets, using native tools), and function calls in disassembly I think
don't resolve; NT386GNU can't yet build this, though it will soon, but
I'm not familiar with gdb and there appears to be no type info. I'm
building m3gdb right now, I don't know if it will work, I hope it has
type info, and I'm not familiar with the relevant code. In gdb I
struggle just to view bytes in memory, add numbers to addresses and see
those, etc. I think for MY problem, I'm going to link in C code to dump
the structs. There is tracing code and I enabled it, but even it crashes
in Text_Length. At least MY problem crashes, hopefully near the problem,
whereas your problem goes all the way through to completion with no
stopping to hint where the problem is. Darn it. :) on the mock rudeness
and :( on the lack of a crash.
 
You write the bundle out and it matches, so that doesn't rule out
bundles as being the problem? (darn)
And bundles look pretty simple, a bundle is just a generated source
file with a constant in it.
Maybe newline problems? That wouldn't make sense. I just downloaded
some program that might let me separately view the ppm, maybe it'll
reveal something.
 
The bad behavior has like regularly spaced solid color veritical bars a
few pixels side across the whole picture, and regularly spaced vertical
stripes from the correct picture alternating with that. Perhaps someone
with ppm/bitmap/graphics experience has seen this behavior and it
results from some common pixmap mismanagement we could look for?
 
I have to say this is very surprising.
 
I always wondered, and now I pretty much assume -- Modula-3 never
imports/exports data in its dynamic linking, right? It alway
imports/exports functions, right?
On Windows, functions have an optional optimization, but data must be
handled differently at compile time if it is going to be dynamically
imported.
For functions, if you don't apply the optimization at compile time, the
linker will just generate a single instruction thunk instead.
 
That is, given a symbol Foo, there is a symbol __imp__Foo that is a
pointer to the actual foo in another .dll/.so.
The loader only patches pointers, one per import if you build your .dll
correctly, it doesn't patch instructions or code strewn throughout a
.dll, just one contiguous array of pointers. MAYBE they don't have to be
contiguous for each .dl you import from.
 
That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my
.dll/.exe typically has an array:
 
pointer to msvcrt!fopen
pointer to msvcrt!fclose
null
pointer to kernel32!Sleep
 
But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not
be adjacent.
 
So, going back, my point/question is that, if the compiler knows the
function is imported, it can call through __imp__Foo instead of calling
Foo.
But if it calls Foo and you import Foo, the linker will create the
function Foo that just jmps through __imp__Foo.
That doesn't work for data though. There's no ability to intervenve
like that.
So for imported data, the compiler must generated a read and
dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to
be imported.
Data imports may be faster when appropriate, but for this reason, I'd
say they aren't worth it.
And for this reason, I HOPE Modula-3 never imports/exports data.
 
Oh, you could, for data, always reference the pointer __imp_Foo, and if
non materializes, create one.
However that would suck perf in order to make an uncommon case work.
I hope Modula-3 doesn't do that either. :)
Though I guess since this global data in question...maybe it is
rare???
 
Later,
 - Jay



> From: hosking at cs.purdue.edu 
> Date: Sat, 19 Jan 2008 03:09:47 -0500
> To: rcoleburn at scires.com 
> CC: m3devel at elegosoft.com 
> Subject: Re: [M3devel] pixmap problem
> 
> Looks fine to me on I386_DARWIN.
> 
> On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:
> 
> > 
> 


Need to know the score, the latest news, or you need your Hotmail*-get
your "fix" Check it out. ( http://www.msnmobilefix.com/Default.aspx ) 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TestPixmap.zip
Type: application/x-zip-compressed
Size: 4870 bytes
Desc: not available
URL: 

From rcoleburn at scires.com  Mon May  5 21:10:33 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Mon, 05 May 2008 15:10:33 -0400
Subject: [M3devel] build fails on NT386
References: <481EFC54.1E75.00D7.1@scires.com>
Message-ID: <481F2363.1E75.00D7.1@scires.com>

I have done a CVS update and decided to rebuild everything.
 
I used the script in scripts\win\upgrade.cmd
 
Here is a snippet of the output where it fails:
 
..\src\values => c:\cm3\pkg\m3front\src\values
  Module.i3         Module.m3         Value.i3          Value.m3
  ValueRep.i3       Constant.i3       Constant.m3       Decl.m3
  Decl.i3           EnumElt.i3        EnumElt.m3        Exceptionz.i3
  Exceptionz.m3     External.i3       External.m3       Field.i3
  Field.m3          Formal.i3         Formal.m3         Ident.i3
  Ident.m3          Method.m3         Method.i3         Procedure.i3
  Procedure.m3      Revelation.m3     Revelation.i3     Tipe.i3
  Tipe.m3           Variable.i3       Variable.m3
=== package C:\CM3_Sandbox\cm3\m3-sys\m3quake ===
+++ "cm3 -build  -DROOT=C:\\CM3_Sandbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_VER
SION_NUMBER=050700 -DCM3_LAST_CHANGED=2008-03-16 && cm3 -ship -DROOT=C:\\CM3_San
dbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_VERSION_NUMBER=050700 -DCM3_LAST_CHANG
ED=2008-03-16" +++
--- building in NT386 ---
 
ignoring ..\src\m3overrides
 
"C:\CM3_Sandbox\cm3\m3-sys\m3quake\src\m3makefile", line 14: quake runtime error
: unable to open "c:\cm3\pkg\sysutils\NT386\.M3EXPORTS" for reading
 
--procedure--  -line-  -file---
import             --  
include_dir        14  C:\CM3_Sandbox\cm3\m3-sys\m3quake\src\m3makefile
                    8  C:\CM3_Sandbox\cm3\m3-sys\m3quake\NT386\m3make.args
 
Fatal Error: package build failed
ERROR: "cm3 -build  -DROOT=C:\\CM3_Sandbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_
VERSION_NUMBER=050700 -DCM3_LAST_CHANGED=2008-03-16 && cm3 -ship -DROOT=C:\\CM3_
Sandbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_VERSION_NUMBER=050700 -DCM3_LAST_CH
ANGED=2008-03-16"
ERROR: cd C:\CM3_Sandbox\cm3\m3-sys\m3quake
ERROR: set INSTALLROOT=C:\cm3
 
C:\CM3_Sandbox\cm3\scripts\win>
 
Please advise.
 
Regards,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Mon May  5 21:21:36 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Mon, 05 May 2008 15:21:36 -0400
Subject: [M3devel] build fails on NT386
In-Reply-To: <481F2363.1E75.00D7.1@scires.com>
References: <481EFC54.1E75.00D7.1@scires.com> <481F2363.1E75.00D7.1@scires.com>
Message-ID: <481F25FA.1E75.00D7.1@scires.com>

Update:
 
I tried to get around the problem by manually building & shipping the sysutils package, then running scripts\win\upgrade.cmd again.
 
Now the build fails as shown below:
 
=== package C:\CM3_Sandbox\cm3\m3-sys\m3quake ===
+++ "cm3 -build  -DROOT=C:\\CM3_Sandbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_VER
SION_NUMBER=050700 -DCM3_LAST_CHANGED=2008-03-16 && cm3 -ship -DROOT=C:\\CM3_San
dbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_VERSION_NUMBER=050700 -DCM3_LAST_CHANG
ED=2008-03-16" +++
--- building in NT386 ---
 
ignoring ..\src\m3overrides
 
new source -> compiling Quake.i3
new source -> compiling QCompiler.i3
new source -> compiling QCode.i3
new source -> compiling QValue.i3
new source -> compiling QVSeq.i3
new source -> compiling QVTbl.i3
new source -> compiling QVal.i3
new source -> compiling QMachine.i3
new source -> compiling QToken.i3
new source -> compiling QIdent.i3
new source -> compiling Quake.m3
new source -> compiling QToken.m3
new source -> compiling QIdent.m3
new source -> compiling QScanner.i3
new source -> compiling QScanner.m3
new source -> compiling QCode.m3
new source -> compiling QCompiler.m3
new source -> compiling QValue.m3
new source -> compiling QVTbl.m3
new source -> compiling QVSeqRep.i3
new source -> compiling QVSeq.m3
 
Fatal Error: bad version stamps: SystemWin32.m3
 
version stamp mismatch: WinSock.gethostname
  <4ccceffe6a8d6438> => SystemWin32.m3
  <0e719d1414b51c34> => WinSock.i3
SystemWin32.m3: missing imported type: _te9593bef
ERROR: "cm3 -build  -DROOT=C:\\CM3_Sandbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_
VERSION_NUMBER=050700 -DCM3_LAST_CHANGED=2008-03-16 && cm3 -ship -DROOT=C:\\CM3_
Sandbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_VERSION_NUMBER=050700 -DCM3_LAST_CH
ANGED=2008-03-16"
ERROR: cd C:\CM3_Sandbox\cm3\m3-sys\m3quake
ERROR: set INSTALLROOT=C:\cm3
 
C:\CM3_Sandbox\cm3\scripts\win>
 
Please advise.
 
Regards,
Randy

>>> "Randy Coleburn"  5/5/2008 3:10 PM >>>
I have done a CVS update and decided to rebuild everything.
 
I used the script in scripts\win\upgrade.cmd
 
Here is a snippet of the output where it fails:
 
..\src\values => c:\cm3\pkg\m3front\src\values
  Module.i3         Module.m3         Value.i3          Value.m3
  ValueRep.i3       Constant.i3       Constant.m3       Decl.m3
  Decl.i3           EnumElt.i3        EnumElt.m3        Exceptionz.i3
  Exceptionz.m3     External.i3       External.m3       Field.i3
  Field.m3          Formal.i3         Formal.m3         Ident.i3
  Ident.m3          Method.m3         Method.i3         Procedure.i3
  Procedure.m3      Revelation.m3     Revelation.i3     Tipe.i3
  Tipe.m3           Variable.i3       Variable.m3
=== package C:\CM3_Sandbox\cm3\m3-sys\m3quake ===
+++ "cm3 -build  -DROOT=C:\\CM3_Sandbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_VER
SION_NUMBER=050700 -DCM3_LAST_CHANGED=2008-03-16 && cm3 -ship -DROOT=C:\\CM3_San
dbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_VERSION_NUMBER=050700 -DCM3_LAST_CHANG
ED=2008-03-16" +++
--- building in NT386 ---
 
ignoring ..\src\m3overrides
 
"C:\CM3_Sandbox\cm3\m3-sys\m3quake\src\m3makefile", line 14: quake runtime error
: unable to open "c:\cm3\pkg\sysutils\NT386\.M3EXPORTS" for reading
 
--procedure--  -line-  -file---
import             --  
include_dir        14  C:\CM3_Sandbox\cm3\m3-sys\m3quake\src\m3makefile
                    8  C:\CM3_Sandbox\cm3\m3-sys\m3quake\NT386\m3make.args
 
Fatal Error: package build failed
ERROR: "cm3 -build  -DROOT=C:\\CM3_Sandbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_
VERSION_NUMBER=050700 -DCM3_LAST_CHANGED=2008-03-16 && cm3 -ship -DROOT=C:\\CM3_
Sandbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_VERSION_NUMBER=050700 -DCM3_LAST_CH
ANGED=2008-03-16"
ERROR: cd C:\CM3_Sandbox\cm3\m3-sys\m3quake
ERROR: set INSTALLROOT=C:\cm3
 
C:\CM3_Sandbox\cm3\scripts\win>
 
Please advise.
 
Regards,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Mon May  5 23:13:15 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Mon, 05 May 2008 17:13:15 -0400
Subject: [M3devel] problems rebuilding everything
Message-ID: <481F4025.1E75.00D7.1@scires.com>

I think I've traced the problem rebuilding everything on WindowsXP to the sysutils package.
 
I don't think this package is getting built in the correct order when running the scripts in the scripts\win folder.
 
Can someone tell me the purpose and format of the scripts\pkginfo.txt file?  It would appear that this file has something to do with defining the build order.  In this file the sysutils entry is defined as:  sysutils core std
 
In looking at the m3makefile for this package, it appears to depend on:  libm3
 
When I run the scripts\win\upgrade.cmd file, I get to a point where an error occurs because sysutils has not been built.  If you then build sysutils and run the upgrade.cmd script again, you later get a version stamp mismatch problem.
 
Please advise on how to repair this problem.
 
Regards,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From wagner at elegosoft.com  Tue May  6 00:48:15 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 06 May 2008 00:48:15 +0200
Subject: [M3devel] pixmap problem
In-Reply-To: <481EE888.1E75.00D7.1@scires.com>
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
Message-ID: <20080506004815.p4vfoausgkcggsk0@mail.elegosoft.com>

Quoting Randy Coleburn :

> Jay:
>
> The TestPixmap.zip is attached.
>
> I will attempt to update all my sources and try again.
>
> Not sure what you mean when you say that I must use your config files
> or edit what I am using.  Please elaborate.

I think he simply means that the fix is in the config files,
and you must use his latest commits (cminstall/src/config/NT386*).

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 jayk123 at hotmail.com  Tue May  6 01:01:22 2008
From: jayk123 at hotmail.com (Jay)
Date: Mon, 5 May 2008 23:01:22 +0000
Subject: [M3devel] problems rebuilding everything
In-Reply-To: <481F4025.1E75.00D7.1@scires.com>
References: <481F4025.1E75.00D7.1@scires.com>
Message-ID: 


This is all normal stuff, not indicative of any real problem.
Please try scripts/python/upgrade.py.
I don't use scripts/win any longer.
The format of pkginfo.txt is incredibly simple:
  1) it is in a particular order 
  2) package name followed by groups it is in 
  almost everything is in "std".

The order of the file isn't necessarily correct for "upgrade", since you have to skip building anything that uses LONGINT and first build a compiler that understands LONGINT. (I'm working on a small change with the opposite requirement, but will instead avoid it, else cause too painful bootstrapping; the change is to provide HOST and HOST_OSTYPE in quake, but that's a dependency from m3quake to m3core, if done the expected way; I'll clone Compiler.tmpl instead, and rename the interfade).

  - Jay


Date: Mon, 5 May 2008 17:13:15 -0400
From: rcoleburn at scires.com
To: m3-support at elego.de; m3devel at elegosoft.com
Subject: [M3devel] problems rebuilding everything







I think I've traced the problem rebuilding everything on WindowsXP to the sysutils package.
 
I don't think this package is getting built in the correct order when running the scripts in the scripts\win folder.
 
Can someone tell me the purpose and format of the scripts\pkginfo.txt file?  It would appear that this file has something to do with defining the build order.  In this file the sysutils entry is defined as:  sysutils core std
 
In looking at the m3makefile for this package, it appears to depend on:  libm3
 
When I run the scripts\win\upgrade.cmd file, I get to a point where an error occurs because sysutils has not been built.  If you then build sysutils and run the upgrade.cmd script again, you later get a version stamp mismatch problem.
 
Please advise on how to repair this problem.
 
Regards,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Tue May  6 01:04:33 2008
From: jayk123 at hotmail.com (Jay)
Date: Mon, 5 May 2008 23:04:33 +0000
Subject: [M3devel] pixmap problem
In-Reply-To: <481EE888.1E75.00D7.1@scires.com>
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	 
	<481EE888.1E75.00D7.1@scires.com>
Message-ID: 


Thanks. I'll look into this tonight probably, as well as with 4.1 assuming I can find my binaries and source for it (probably).

COULD BE the pixmap problem is something else and 4.1 also has the problem I fixed. We'll see. No need to speculate (unless I can't find my 4.1).

 - Jay


Date: Mon, 5 May 2008 10:59:27 -0400
From: rcoleburn at scires.com
To: jayk123 at hotmail.com
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] pixmap problem







Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy

>>> Jay  5/4/2008 11:46 AM >>>
Randy, Please try with /current/ source, as of this morning Sunday May 4 -- the changes are ALL in NT386.common, so you MUST use MY config files, which are checked in verbatim, or you should be able edit whatever config files you are using.
 
(It's not really a config file issue, don't blame the general confusion people have with them.)
 
I'll try to try later, but I don't have the source right now, gotta look on other machines, and I think it's on a machine on loan.
  Or send it to me again.
I'd also like to know if this worked with 4.1, or with any release that offered dynamic linking to m3core.dll, on Windows.
  I recall a claim that it did. If today's change fixes it, I should be able to investigate 4.1.
3.6 did not have such linking.
If today's change does not help, well, I still plan on debugging it at some point..
 
If you aren't current and getting so is difficult, just send the attachment again, it's easy for me to test.
 
Thanks,
 - Jay




From: jayk123 at hotmail.com
To: hosking at cs.purdue.edu; rcoleburn at scires.com
Date: Sat, 19 Jan 2008 08:52:08 +0000
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] pixmap problem




I can repro the two different behaviors on XP.
I was going to try on PPC_DARWIN but I guess Tony's info suffices.
 
I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew.
 
Debugging here is a big humungous pain.
NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash.
 
You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)
And bundles look pretty simple, a bundle is just a generated source file with a constant in it.
Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something.
 
The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for?
 
I have to say this is very surprising.
 
I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?
On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.
For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead.
 
That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so.
The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from.
 
That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array:
 
pointer to msvcrt!fopen
pointer to msvcrt!fclose
null
pointer to kernel32!Sleep
 
But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent.
 
So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo.
But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo.
That doesn't work for data though. There's no ability to intervenve like that.
So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.
Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it.
And for this reason, I HOPE Modula-3 never imports/exports data.
 
Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.
However that would suck perf in order to make an uncommon case work.
I hope Modula-3 doesn't do that either. :)
Though I guess since this global data in question...maybe it is rare???
 
Later,
 - Jay





> From: hosking at cs.purdue.edu
> Date: Sat, 19 Jan 2008 03:09:47 -0500
> To: rcoleburn at scires.com
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] pixmap problem
> 
> Looks fine to me on I386_DARWIN.
> 
> On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:
> 
> > 
> 




Need to know the score, the latest news, or you need your Hotmail?-get your "fix" Check it out. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Tue May  6 03:01:10 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Mon, 05 May 2008 21:01:10 -0400
Subject: [M3devel] new problem linking on NT386
Message-ID: <481F7590.1E75.00D7.1@scires.com>

I've rebuild my cm3 system using the latest sources.
 
I am now having a failure linking certain programs that used to build without problems.
 
I've listed the linker output from one of the programs below.  The issue seems to be an unresolved external symbol _WinMain at 16 .
 
Any ideas on what has changed and how to get this working again?
 
Microsoft (R) Incremental Linker Version 9.00.21022.08
Copyright (C) Microsoft Corporation.  All rights reserved.
 
/out:CV_MessageTool.exe 
/subsystem:windows 
/entry:WinMainCRTStartup 
/nodefaultlib 
/debug 
/incremental:no 
/opt:ref 
/delayload:wsock32.dll 
/delayload:advapi32.dll 
/delayload:gdi32.dll 
/delayload:netapi32.dll 
/delayload:user32.dll 
/delayload:comctl32.dll 
delayimp.lib 
_m3main.obj 
iconRes.obj 
Resources.io 
Resources.mo 
Main.mo 
C:\cm3\pkg\windowsResources\NT386\windowsResources.lib 
C:\cm3\pkg\libSciRes3\NT386\libSciRes3.lib 
C:\cm3\pkg\stable\NT386\stable.lib 
C:\cm3\pkg\serial2\NT386\serial2.lib 
C:\cm3\pkg\netobj\NT386\m3netobj.lib 
C:\cm3\pkg\parseparams\NT386\m3parseparams.lib 
C:\cm3\pkg\formsvbt\NT386\m3formsvbt.lib 
C:\cm3\pkg\videovbt\NT386\videovbt.lib 
C:\cm3\pkg\jvideo\NT386\jvideo.lib 
C:\cm3\pkg\web\NT386\web.lib 
C:\cm3\pkg\tcp\NT386\m3tcp.lib 
C:\cm3\pkg\formsvbtpixmaps\NT386\m3formsvbtpixmaps.lib 
C:\cm3\pkg\vbtkit\NT386\m3vbtkit.lib 
C:\cm3\pkg\ui\NT386\m3ui.lib 
C:\cm3\pkg\libm3\NT386\m3.lib 
C:\cm3\pkg\m3core\NT386\m3core.lib 
winspool.lib 
comctl32.lib 
wsock32.lib 
comdlg32.lib 
netapi32.lib 
gdi32.lib 
user32.lib 
advapi32.lib 
kernel32.lib 
msvcrt.lib 
LINK : warning LNK4199: /DELAYLOAD:wsock32.dll ignored; no imports found from wsock32.dll
LINK : warning LNK4199: /DELAYLOAD:advapi32.dll ignored; no imports found from advapi32.dll
LINK : warning LNK4199: /DELAYLOAD:gdi32.dll ignored; no imports found from gdi32.dll
LINK : warning LNK4199: /DELAYLOAD:netapi32.dll ignored; no imports found from netapi32.dll
LINK : warning LNK4199: /DELAYLOAD:user32.dll ignored; no imports found from user32.dll
LINK : warning LNK4199: /DELAYLOAD:comctl32.dll ignored; no imports found from comctl32.dll
msvcrt.lib(crtexew.obj) : error LNK2019: unresolved external symbol _WinMain at 16 referenced in function ___tmainCRTStartup
CV_MessageTool.exe : fatal error LNK1120: 1 unresolved externals
Regards,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Tue May  6 03:18:12 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Mon, 05 May 2008 21:18:12 -0400
Subject: [M3devel] pixmap problem
In-Reply-To: 
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
Message-ID: <481F798E.1E75.00D7.1@scires.com>

Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly
when the buildstandalone() directive is used.
 
Regards,
Randy

>>> Jay  5/5/2008 7:04 PM >>>
Thanks. I'll look into this tonight probably, as well as with 4.1
assuming I can find my binaries and source for it (probably).

COULD BE the pixmap problem is something else and 4.1 also has the
problem I fixed. We'll see. No need to speculate (unless I can't find my
4.1).

 - Jay


Date: Mon, 5 May 2008 10:59:27 -0400
From: rcoleburn at scires.com 
To: jayk123 at hotmail.com 
CC: m3devel at elegosoft.com 
Subject: RE: [M3devel] pixmap problem

Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files
or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy

>>> Jay  5/4/2008 11:46 AM >>>
Randy, Please try with /current/ source, as of this morning Sunday May
4 -- the changes are ALL in NT386.common, so you MUST use MY config
files, which are checked in verbatim, or you should be able edit
whatever config files you are using.
 
(It's not really a config file issue, don't blame the general confusion
people have with them.)
 
I'll try to try later, but I don't have the source right now, gotta
look on other machines, and I think it's on a machine on loan.
  Or send it to me again.
I'd also like to know if this worked with 4.1, or with any release that
offered dynamic linking to m3core.dll, on Windows.
  I recall a claim that it did. If today's change fixes it, I should be
able to investigate 4.1.
3.6 did not have such linking.
If today's change does not help, well, I still plan on debugging it at
some point..
 
If you aren't current and getting so is difficult, just send the
attachment again, it's easy for me to test.
 
Thanks,
 - Jay

From: jayk123 at hotmail.com 
To: hosking at cs.purdue.edu; rcoleburn at scires.com 
Date: Sat, 19 Jan 2008 08:52:08 +0000
CC: m3devel at elegosoft.com 
Subject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.
I was going to try on PPC_DARWIN but I guess Tony's info suffices.
 
I tried rolling hand.c back to before I changed (months/year ago),
since it is involved in bit twiddling, no change, phew.
 
Debugging here is a big humungous pain.
NT386 has good stacks and line numbers, but no locals or type info, I'd
really sometime like to get Codeview info into those .objs...I think it
is documented well enough, but still not necessarily easy, or maybe have
a C generating backend partly for this reason (and to bring up more
targets, using native tools), and function calls in disassembly I think
don't resolve; NT386GNU can't yet build this, though it will soon, but
I'm not familiar with gdb and there appears to be no type info. I'm
building m3gdb right now, I don't know if it will work, I hope it has
type info, and I'm not familiar with the relevant code. In gdb I
struggle just to view bytes in memory, add numbers to addresses and see
those, etc. I think for MY problem, I'm going to link in C code to dump
the structs. There is tracing code and I enabled it, but even it crashes
in Text_Length. At least MY problem crashes, hopefully near the problem,
whereas your problem goes all the way through to completion with no
stopping to hint where the problem is. Darn it. :) on the mock rudeness
and :( on the lack of a crash.
 
You write the bundle out and it matches, so that doesn't rule out
bundles as being the problem? (darn)
And bundles look pretty simple, a bundle is just a generated source
file with a constant in it.
Maybe newline problems? That wouldn't make sense. I just downloaded
some program that might let me separately view the ppm, maybe it'll
reveal something.
 
The bad behavior has like regularly spaced solid color veritical bars a
few pixels side across the whole picture, and regularly spaced vertical
stripes from the correct picture alternating with that. Perhaps someone
with ppm/bitmap/graphics experience has seen this behavior and it
results from some common pixmap mismanagement we could look for?
 
I have to say this is very surprising.
 
I always wondered, and now I pretty much assume -- Modula-3 never
imports/exports data in its dynamic linking, right? It alway
imports/exports functions, right?
On Windows, functions have an optional optimization, but data must be
handled differently at compile time if it is going to be dynamically
imported.
For functions, if you don't apply the optimization at compile time, the
linker will just generate a single instruction thunk instead.
 
That is, given a symbol Foo, there is a symbol __imp__Foo that is a
pointer to the actual foo in another .dll/.so.
The loader only patches pointers, one per import if you build your .dll
correctly, it doesn't patch instructions or code strewn throughout a
.dll, just one contiguous array of pointers. MAYBE they don't have to be
contiguous for each .dl you import from.
 
That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my
.dll/.exe typically has an array:
 
pointer to msvcrt!fopen
pointer to msvcrt!fclose
null
pointer to kernel32!Sleep
 
But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not
be adjacent.
 
So, going back, my point/question is that, if the compiler knows the
function is imported, it can call through __imp__Foo instead of calling
Foo.
But if it calls Foo and you import Foo, the linker will create the
function Foo that just jmps through __imp__Foo.
That doesn't work for data though. There's no ability to intervenve
like that.
So for imported data, the compiler must generated a read and
dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to
be imported.
Data imports may be faster when appropriate, but for this reason, I'd
say they aren't worth it.
And for this reason, I HOPE Modula-3 never imports/exports data.
 
Oh, you could, for data, always reference the pointer __imp_Foo, and if
non materializes, create one.
However that would suck perf in order to make an uncommon case work.
I hope Modula-3 doesn't do that either. :)
Though I guess since this global data in question...maybe it is
rare???
 
Later,
 - Jay



> From: hosking at cs.purdue.edu 
> Date: Sat, 19 Jan 2008 03:09:47 -0500
> To: rcoleburn at scires.com 
> CC: m3devel at elegosoft.com 
> Subject: Re: [M3devel] pixmap problem
> 
> Looks fine to me on I386_DARWIN.
> 
> On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:
> 
> > 
> 


Need to know the score, the latest news, or you need your Hotmail*-get
your "fix" Check it out. ( http://www.msnmobilefix.com/Default.aspx ) 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From dabenavidesd at yahoo.es  Tue May  6 03:46:27 2008
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 6 May 2008 03:46:27 +0200 (CEST)
Subject: [M3devel] www.opencm3.net/m3tests
Message-ID: <313767.59466.qm@web27115.mail.ukl.yahoo.com>

Dear developers:
Does the recent tests on NT386 seem broken because a recent change on the m3-sys tree, or is the HTML bad generated, I mean can you check the last tests Sunday, May 4th (p001 to p042) has a red background 
http://www.opencm3.net/m3tests/m3tests-NT386-2008-04-23-13-30-57.html
p002 Text
Comparing files P0\P002\stdout.build and ..\SRC\P0\P002\STDOUT.BUILD
***** P0\P002\stdout.build
link @_m3responsefile0.txt 2>&1 > pgm.lst
mt /nologo /manifest pgm.exe.manifest /outputresource:pgm.exe;1
***** ..\SRC\P0\P002\STDOUT.BUILD
*****

Comparing files P0\P002\stderr.build and ..\SRC\P0\P002\STDERR.BUILD
FC: no differences encountered

Comparing files P0\P002\stdout.pgm and ..\SRC\P0\P002\STDOUT.PGM
FC: no differences encountered

Comparing files P0\P002\stderr.pgm and ..\SRC\P0\P002\STDERR.PGM
FC: no differences encountered
and almost the same pattern in the above tests.

I would suggest if it is thinkable using NT386 variant with a complete dedicated machine/system, I can try to set up one this week and send the data back (the machine is behind a proxy), but I don't remember the mail explaining the set up, and also want to know if there is a chance of run the tests with one run script.
Also what is the best natural way to put a new tests, and the standard name it should have?


Thanks

       
---------------------------------

Enviado desde Correo Yahoo!
La bandeja de entrada m?s inteligente.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Tue May  6 03:47:17 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 6 May 2008 01:47:17 +0000
Subject: [M3devel] new problem linking on NT386
In-Reply-To: <481F7590.1E75.00D7.1@scires.com>
References: <481F7590.1E75.00D7.1@scires.com>
Message-ID: 

Sounds like you missed the "gui" switch on the cm3 command lineor in the m3makefile -- in the m3makefile really.Putting it on the command line imho is only reasonable for thosesimple cases that don't have an m3makefile
 link -dump -symbols NT386\_m3main.obj | findstr /i main 
?I expect you will have main or wmain, but not WinMain or wWinMain.
 
Is this meant to be a gui app or a command line app?
If it is meant to be a command line, then the problem is something else.
  And I don't even want to explain..
Can you send me the source?
 
Also you are missing hand.obj here, so you don't have the potential pixmap fix.
 - Jay


Date: Mon, 5 May 2008 21:01:10 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: [M3devel] new problem linking on NT386

I've rebuild my cm3 system using the latest sources.
 
I am now having a failure linking certain programs that used to build without problems.
 
I've listed the linker output from one of the programs below.  The issue seems to be an unresolved external symbol _WinMain at 16 .
 
Any ideas on what has changed and how to get this working again?
 
Microsoft (R) Incremental Linker Version 9.00.21022.08Copyright (C) Microsoft Corporation.  All rights reserved.
 
/out:CV_MessageTool.exe /subsystem:windows /entry:WinMainCRTStartup /nodefaultlib /debug /incremental:no /opt:ref /delayload:wsock32.dll /delayload:advapi32.dll /delayload:gdi32.dll /delayload:netapi32.dll /delayload:user32.dll /delayload:comctl32.dll delayimp.lib _m3main.obj iconRes.obj Resources.io Resources.mo Main.mo C:\cm3\pkg\windowsResources\NT386\windowsResources.lib C:\cm3\pkg\libSciRes3\NT386\libSciRes3.lib C:\cm3\pkg\stable\NT386\stable.lib C:\cm3\pkg\serial2\NT386\serial2.lib C:\cm3\pkg\netobj\NT386\m3netobj.lib C:\cm3\pkg\parseparams\NT386\m3parseparams.lib C:\cm3\pkg\formsvbt\NT386\m3formsvbt.lib C:\cm3\pkg\videovbt\NT386\videovbt.lib C:\cm3\pkg\jvideo\NT386\jvideo.lib C:\cm3\pkg\web\NT386\web.lib C:\cm3\pkg\tcp\NT386\m3tcp.lib C:\cm3\pkg\formsvbtpixmaps\NT386\m3formsvbtpixmaps.lib C:\cm3\pkg\vbtkit\NT386\m3vbtkit.lib C:\cm3\pkg\ui\NT386\m3ui.lib C:\cm3\pkg\libm3\NT386\m3.lib C:\cm3\pkg\m3core\NT386\m3core.lib winspool.lib comctl32.lib wsock32.lib comdlg32.lib netapi32.lib gdi32.lib user32.lib advapi32.lib kernel32.lib msvcrt.lib LINK : warning LNK4199: /DELAYLOAD:wsock32.dll ignored; no imports found from wsock32.dllLINK : warning LNK4199: /DELAYLOAD:advapi32.dll ignored; no imports found from advapi32.dllLINK : warning LNK4199: /DELAYLOAD:gdi32.dll ignored; no imports found from gdi32.dllLINK : warning LNK4199: /DELAYLOAD:netapi32.dll ignored; no imports found from netapi32.dllLINK : warning LNK4199: /DELAYLOAD:user32.dll ignored; no imports found from user32.dllLINK : warning LNK4199: /DELAYLOAD:comctl32.dll ignored; no imports found from comctl32.dllmsvcrt.lib(crtexew.obj) : error LNK2019: unresolved external symbol _WinMain at 16 referenced in function ___tmainCRTStartupCV_MessageTool.exe : fatal error LNK1120: 1 unresolved externals
Regards,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Tue May  6 03:54:52 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 6 May 2008 01:54:52 +0000
Subject: [M3devel] pixmap problem
In-Reply-To: <481F798E.1E75.00D7.1@scires.com>
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	 
	<481F798E.1E75.00D7.1@scires.com>
Message-ID: 

And you took the updated config file?
The way you can tell is that, roughly speaking, hand.obj should be in NT386\_m3responsefile0.txt.
Or _m3responsefile1.txt, or, well, somewhere.
Anyway, I think I saw the attachment, I can check later..and with 4.1 as I said..
 
I can see about making the fix not depend on config file changes...but it's not terrible asis, and I'd really like to merge more of the quake code into cm3.exe..
 
 - Jay


Date: Mon, 5 May 2008 21:18:12 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem

Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly when the buildstandalone() directive is used.
 
Regards,
Randy>>> Jay  5/5/2008 7:04 PM >>>Thanks. I'll look into this tonight probably, as well as with 4.1 assuming I can find my binaries and source for it (probably).COULD BE the pixmap problem is something else and 4.1 also has the problem I fixed. We'll see. No need to speculate (unless I can't find my 4.1). - Jay


Date: Mon, 5 May 2008 10:59:27 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problem
Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy>>> Jay  5/4/2008 11:46 AM >>>Randy, Please try with /current/ source, as of this morning Sunday May 4 -- the changes are ALL in NT386.common, so you MUST use MY config files, which are checked in verbatim, or you should be able edit whatever config files you are using. (It's not really a config file issue, don't blame the general confusion people have with them.) I'll try to try later, but I don't have the source right now, gotta look on other machines, and I think it's on a machine on loan.  Or send it to me again.I'd also like to know if this worked with 4.1, or with any release that offered dynamic linking to m3core.dll, on Windows.  I recall a claim that it did. If today's change fixes it, I should be able to investigate 4.1.3.6 did not have such linking.If today's change does not help, well, I still plan on debugging it at some point.. If you aren't current and getting so is difficult, just send the attachment again, it's easy for me to test. Thanks, - Jay


From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rcoleburn at scires.comDate: Sat, 19 Jan 2008 08:52:08 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.I was going to try on PPC_DARWIN but I guess Tony's info suffices. I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. Debugging here is a big humungous pain.NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)And bundles look pretty simple, a bundle is just a generated source file with a constant in it.Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something. The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for? I have to say this is very surprising. I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so.The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: pointer to msvcrt!fopenpointer to msvcrt!fclosenullpointer to kernel32!Sleep But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo.But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo.That doesn't work for data though. There's no ability to intervenve like that.So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it.And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.However that would suck perf in order to make an uncommon case work.I hope Modula-3 doesn't do that either. :)Though I guess since this global data in question...maybe it is rare??? Later, - Jay

> From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 03:09:47 -0500> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] pixmap problem> > Looks fine to me on I386_DARWIN.> > On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:> > > > 

Need to know the score, the latest news, or you need your Hotmail?-get your "fix" Check it out. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Tue May  6 04:01:17 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 6 May 2008 02:01:17 +0000
Subject: [M3devel] www.opencm3.net/m3tests
In-Reply-To: <313767.59466.qm@web27115.mail.ukl.yahoo.com>
References: <313767.59466.qm@web27115.mail.ukl.yahoo.com>
Message-ID: 

The "problem" here, a really really small one, is just that the link and mt commands got echoed.
Olaf made them not echoed. I then made them conditionally echoed.
  I made m3-sys\m3tests define M3TESTS so that NT386.common doesn't echo.
It's not a big deal either way.
Aha -- tests in other directories would have a problem, and I think there are some.
 
I like more echoing usually, so the system explains what is going on,
instead of the vaguer "linking foo" sort of message.
Granted, nobody bothers watching gcc run assembler commands, so I guess it is just quite gray.
 
I don't know how to run the Tinderbox either yet, sorry.
I tried.
 
For adding tests, well, there is m3-sys\m3tests.
That is where a lot of the tests are, but not all.
I am not sure where tests belong. I added a small number there.
They are named with just a letter and a number.
The letters have some meaning, explained in the m3makefile.
"p" is programs that are run and their stdout/stderr compared against expected
"e" is programs build and the errors from the compiler checked to be reasonable.
  I don't think in general they are expected to successfully compile or run, though the case of "warnings" may be unclear.
"c" is programs built so a human can look at the generated code.
There is another case I think for human checking.
The numbers are just 001, 002, 003, etc.
Each hundred tests are in a separate directory, like p0\p001, p0\p002, p1\p100, p1\101, etc. 
 
Something like this.
Wherever I have details wrong, just look in m3-sys\m3tests. It's pretty simple, obvious, and well commented.
 
The output is a little clearer if you have a working diff.exe on the path.
Then what you do is search for "@@" in the output.
 
 - Jay


Date: Tue, 6 May 2008 03:46:27 +0200From: dabenavidesd at yahoo.esTo: m3devel at elegosoft.comSubject: [M3devel] www.opencm3.net/m3testsDear developers:Does the recent tests on NT386 seem broken because a recent change on the m3-sys tree, or is the HTML bad generated, I mean can you check the last tests Sunday, May 4th (p001 to p042) has a red background http://www.opencm3.net/m3tests/m3tests-NT386-2008-04-23-13-30-57.html
p002 Text
Comparing files P0\P002\stdout.build and ..\SRC\P0\P002\STDOUT.BUILD***** P0\P002\stdout.buildlink @_m3responsefile0.txt 2>&1 > pgm.lstmt /nologo /manifest pgm.exe.manifest /outputresource:pgm.exe;1***** ..\SRC\P0\P002\STDOUT.BUILD*****Comparing files P0\P002\stderr.build and ..\SRC\P0\P002\STDERR.BUILDFC: no differences encounteredComparing files P0\P002\stdout.pgm and ..\SRC\P0\P002\STDOUT.PGMFC: no differences encounteredComparing files P0\P002\stderr.pgm and ..\SRC\P0\P002\STDERR.PGMFC: no differences encounteredand almost the same pattern in the above tests.I would suggest if it is thinkable using NT386 variant with a complete dedicated machine/system, I can try to set up one this week and send the data back (the machine is behind a proxy), but I don't remember the mail explaining the set up, and also want to know if there is a chance of run the tests with one run script.Also what is the best natural way to put a new tests, and the standard name it should have?Thanks


Enviado desde Correo Yahoo!La bandeja de entrada m?s inteligente.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Tue May  6 04:08:29 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Mon, 05 May 2008 22:08:29 -0400
Subject: [M3devel] new problem linking on NT386
In-Reply-To: 
References: <481F7590.1E75.00D7.1@scires.com>
	
Message-ID: <481F8557.1E75.00D7.1@scires.com>

Jay:
 
No, I am using the -gui option in the m3makefile.  It is a windows gui application.
 
Here is the output of the command you suggested:
 
Microsoft (R) COFF/PE Dumper Version 9.00.21022.08
Copyright (C) Microsoft Corporation.  All rights reserved.
 

Dump of file NT386\_m3main.obj
 
File Type: COFF OBJECT
 
COFF SYMBOL TABLE
000 00000000 DEBUG  notype       Filename     | .file
    _m3main.mc
002 00000000 SECT1  notype       Static       | .text
    Section length   50, #relocs    4, #linenums    7, checksum        0
004 00000000 SECT2  notype       Static       | .data
    Section length   10, #relocs    3, #linenums    0, checksum        0
006 00000000 SECT3  notype       Static       | .bss
    Section length    0, #relocs    0, #linenums    0, checksum        0
008 00000000 SECT1  notype ()    External     | _main
    tag index 0000000A size 00000050 lines 00000104 next function 00000000
00A 00000000 SECT1  notype       BeginFunction | .bf
    line# 0000 end 00000000
00C 00000007 SECT1  notype       .bf or.ef    | .lf
00D 00000050 SECT1  notype       EndFunction  | .ef
    line# 0006
00F 00000000 SECT1  notype       Static       | TextSegment
010 00000000 UNDEF  notype       External     | _Main_M3
011 00000000 UNDEF  notype       External     | _RTLinker__InitRuntime
012 00000000 UNDEF  notype       External     | _RTLinker__AddUnit
013 00000000 UNDEF  notype       External     | _RTProcess__Exit
014 00000004 SECT2  notype       Static       | T$14
 
String Table Size = 0x4B bytes
 
  Summary
 
           0 .bss
          10 .data
          50 .text
As you can see, I have an
   _main  and a
   _Main_M3
 
Not sure what you mean by saying I am missing hand.obj.  I have rebuilt everything using latest CVS update.  Please elaborate.
 
Regards,
Randy

>>> Jay  5/5/2008 9:47 PM >>>
Sounds like you missed the "gui" switch on the cm3 command line
or in the m3makefile -- in the m3makefile really.
Putting it on the command line imho is only reasonable for those
simple cases that don't have an m3makefile

 link -dump -symbols NT386\_m3main.obj | findstr /i main 

?
I expect you will have main or wmain, but not WinMain or wWinMain.
 
Is this meant to be a gui app or a command line app?
If it is meant to be a command line, then the problem is something else.
  And I don't even want to explain..
Can you send me the source?
 
Also you are missing hand.obj here, so you don't have the potential pixmap fix.

 - Jay

Date: Mon, 5 May 2008 21:01:10 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com 
Subject: [M3devel] new problem linking on NT386

I've rebuild my cm3 system using the latest sources.
 
I am now having a failure linking certain programs that used to build without problems.
 
I've listed the linker output from one of the programs below.  The issue seems to be an unresolved external symbol _WinMain at 16 .
 
Any ideas on what has changed and how to get this working again?
 
Microsoft (R) Incremental Linker Version 9.00.21022.08
Copyright (C) Microsoft Corporation.  All rights reserved.
 
/out:CV_MessageTool.exe 
/subsystem:windows 
/entry:WinMainCRTStartup 
/nodefaultlib 
/debug 
/incremental:no 
/opt:ref 
/delayload:wsock32.dll 
/delayload:advapi32.dll 
/delayload:gdi32.dll 
/delayload:netapi32.dll 
/delayload:user32.dll 
/delayload:comctl32.dll 
delayimp.lib 
_m3main.obj 
iconRes.obj 
Resources.io 
Resources.mo 
Main.mo 
C:\cm3\pkg\windowsResources\NT386\windowsResources.lib 
C:\cm3\pkg\libSciRes3\NT386\libSciRes3.lib 
C:\cm3\pkg\stable\NT386\stable.lib 
C:\cm3\pkg\serial2\NT386\serial2.lib 
C:\cm3\pkg\netobj\NT386\m3netobj.lib 
C:\cm3\pkg\parseparams\NT386\m3parseparams.lib 
C:\cm3\pkg\formsvbt\NT386\m3formsvbt.lib 
C:\cm3\pkg\videovbt\NT386\videovbt.lib 
C:\cm3\pkg\jvideo\NT386\jvideo.lib 
C:\cm3\pkg\web\NT386\web.lib 
C:\cm3\pkg\tcp\NT386\m3tcp.lib 
C:\cm3\pkg\formsvbtpixmaps\NT386\m3formsvbtpixmaps.lib 
C:\cm3\pkg\vbtkit\NT386\m3vbtkit.lib 
C:\cm3\pkg\ui\NT386\m3ui.lib 
C:\cm3\pkg\libm3\NT386\m3.lib 
C:\cm3\pkg\m3core\NT386\m3core.lib 
winspool.lib 
comctl32.lib 
wsock32.lib 
comdlg32.lib 
netapi32.lib 
gdi32.lib 
user32.lib 
advapi32.lib 
kernel32.lib 
msvcrt.lib 
LINK : warning LNK4199: /DELAYLOAD:wsock32.dll ignored; no imports found from wsock32.dll
LINK : warning LNK4199: /DELAYLOAD:advapi32.dll ignored; no imports found from advapi32.dll
LINK : warning LNK4199: /DELAYLOAD:gdi32.dll ignored; no imports found from gdi32.dll
LINK : warning LNK4199: /DELAYLOAD:netapi32.dll ignored; no imports found from netapi32.dll
LINK : warning LNK4199: /DELAYLOAD:user32.dll ignored; no imports found from user32.dll
LINK : warning LNK4199: /DELAYLOAD:comctl32.dll ignored; no imports found from comctl32.dll
msvcrt.lib(crtexew.obj) : error LNK2019: unresolved external symbol _WinMain at 16 referenced in function ___tmainCRTStartup
CV_MessageTool.exe : fatal error LNK1120: 1 unresolved externals
Regards,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Tue May  6 04:26:46 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 6 May 2008 02:26:46 +0000
Subject: [M3devel] new problem linking on NT386
In-Reply-To: <481F8557.1E75.00D7.1@scires.com>
References: <481F7590.1E75.00D7.1@scires.com>
	 
	<481F8557.1E75.00D7.1@scires.com>
Message-ID: 

-gui isn't quite working for you, for reasons I can't fully tell from here.
 
If -entry:WinMainCRTStartup, as you show, then link -dump -symbols _m3main.obj | findstr /i main should find WinMain, and not main. These two things must be altered together. Subsystem usually changes with them as well, but that's optional. WinMainCRTStartup calls WinMain, mainCRTStartup calls main, etc. (also with "w" prepended for Unicode/wide)
This is up to cm3 and cm3.cfg to cooperate on.
 
I can check tonight if it works for me. Could be some config file content missing.
It should generate WinMain instead of main.
 
You don't have the latest config because if you did, the link command you show below would list "hand.obj" among the list of files.
 
e.g.
 copy /y %cvsroot%\m3-sys\cminstall\src\config\nt386* \cm3\bin 
 copy /y \cm3\bin\NT386 \cm3\bin\cm3.cfg  
 
or:
 copy /y %cvsroot%\m3-sys\cminstall\src\config\* \cm3\bin 
 copy /y %cvsroot%\m3-sys\cminstall\src\config-no-install\* \cm3\bin 
 
The second form requires %cvsroot% to stick around and be findable by \cm3\bin\cm3.cfg, such as by setting CM3_ROOT.
The first form does not have such a requirement.
 
I'm really not super keen on supporting any config files other than the exact ones checked in.
Not even necessarily the ones produced by cminstall; I never use it.
I realize there are multiple reasonable modes of operation -- either using %PATH%, %INCLUDE%, and %LIB%, or using full paths in cm3.cfg. I use the first, so I can switch between toolsets more easily, and have no problem with spaces (which I don't have anyway), cminstall uses the second so that the result doesn't depend on the environment but it also has problems with spaces. Depending on short names like "progra~1" is just not the way imho.
 
 - Jay


Date: Mon, 5 May 2008 22:08:29 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] new problem linking on NT386

Jay:
 
No, I am using the -gui option in the m3makefile.  It is a windows gui application.
 
Here is the output of the command you suggested:
 
Microsoft (R) COFF/PE Dumper Version 9.00.21022.08Copyright (C) Microsoft Corporation.  All rights reserved.
 
Dump of file NT386\_m3main.obj
 
File Type: COFF OBJECT
 
COFF SYMBOL TABLE000 00000000 DEBUG  notype       Filename     | .file    _m3main.mc002 00000000 SECT1  notype       Static       | .text    Section length   50, #relocs    4, #linenums    7, checksum        0004 00000000 SECT2  notype       Static       | .data    Section length   10, #relocs    3, #linenums    0, checksum        0006 00000000 SECT3  notype       Static       | .bss    Section length    0, #relocs    0, #linenums    0, checksum        0008 00000000 SECT1  notype ()    External     | _main    tag index 0000000A size 00000050 lines 00000104 next function 0000000000A 00000000 SECT1  notype       BeginFunction | .bf    line# 0000 end 0000000000C 00000007 SECT1  notype       .bf or.ef    | .lf00D 00000050 SECT1  notype       EndFunction  | .ef    line# 000600F 00000000 SECT1  notype       Static       | TextSegment010 00000000 UNDEF  notype       External     | _Main_M3011 00000000 UNDEF  notype       External     | _RTLinker__InitRuntime012 00000000 UNDEF  notype       External     | _RTLinker__AddUnit013 00000000 UNDEF  notype       External     | _RTProcess__Exit014 00000004 SECT2  notype       Static       | T$14
 
String Table Size = 0x4B bytes
 
  Summary
 
           0 .bss          10 .data          50 .text
As you can see, I have an
   _main  and a
   _Main_M3
 
Not sure what you mean by saying I am missing hand.obj.  I have rebuilt everything using latest CVS update.  Please elaborate.
 
Regards,
Randy>>> Jay  5/5/2008 9:47 PM >>>Sounds like you missed the "gui" switch on the cm3 command lineor in the m3makefile -- in the m3makefile really.Putting it on the command line imho is only reasonable for thosesimple cases that don't have an m3makefile link -dump -symbols NT386\_m3main.obj | findstr /i main ?I expect you will have main or wmain, but not WinMain or wWinMain. Is this meant to be a gui app or a command line app?If it is meant to be a command line, then the problem is something else.  And I don't even want to explain..Can you send me the source? Also you are missing hand.obj here, so you don't have the potential pixmap fix. - Jay


Date: Mon, 5 May 2008 21:01:10 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: [M3devel] new problem linking on NT386
I've rebuild my cm3 system using the latest sources.
 
I am now having a failure linking certain programs that used to build without problems.
 
I've listed the linker output from one of the programs below.  The issue seems to be an unresolved external symbol _WinMain at 16 .
 
Any ideas on what has changed and how to get this working again?
 
Microsoft (R) Incremental Linker Version 9.00.21022.08Copyright (C) Microsoft Corporation.  All rights reserved.
 
/out:CV_MessageTool.exe /subsystem:windows /entry:WinMainCRTStartup /nodefaultlib /debug /incremental:no /opt:ref /delayload:wsock32.dll /delayload:advapi32.dll /delayload:gdi32.dll /delayload:netapi32.dll /delayload:user32.dll /delayload:comctl32.dll delayimp.lib _m3main.obj iconRes.obj Resources.io Resources.mo Main.mo C:\cm3\pkg\windowsResources\NT386\windowsResources.lib C:\cm3\pkg\libSciRes3\NT386\libSciRes3.lib C:\cm3\pkg\stable\NT386\stable.lib C:\cm3\pkg\serial2\NT386\serial2.lib C:\cm3\pkg\netobj\NT386\m3netobj.lib C:\cm3\pkg\parseparams\NT386\m3parseparams.lib C:\cm3\pkg\formsvbt\NT386\m3formsvbt.lib C:\cm3\pkg\videovbt\NT386\videovbt.lib C:\cm3\pkg\jvideo\NT386\jvideo.lib C:\cm3\pkg\web\NT386\web.lib C:\cm3\pkg\tcp\NT386\m3tcp.lib C:\cm3\pkg\formsvbtpixmaps\NT386\m3formsvbtpixmaps.lib C:\cm3\pkg\vbtkit\NT386\m3vbtkit.lib C:\cm3\pkg\ui\NT386\m3ui.lib C:\cm3\pkg\libm3\NT386\m3.lib C:\cm3\pkg\m3core\NT386\m3core.lib winspool.lib comctl32.lib wsock32.lib comdlg32.lib netapi32.lib gdi32.lib user32.lib advapi32.lib kernel32.lib msvcrt.lib LINK : warning LNK4199: /DELAYLOAD:wsock32.dll ignored; no imports found from wsock32.dllLINK : warning LNK4199: /DELAYLOAD:advapi32.dll ignored; no imports found from advapi32.dllLINK : warning LNK4199: /DELAYLOAD:gdi32.dll ignored; no imports found from gdi32.dllLINK : warning LNK4199: /DELAYLOAD:netapi32.dll ignored; no imports found from netapi32.dllLINK : warning LNK4199: /DELAYLOAD:user32.dll ignored; no imports found from user32.dllLINK : warning LNK4199: /DELAYLOAD:comctl32.dll ignored; no imports found from comctl32.dllmsvcrt.lib(crtexew.obj) : error LNK2019: unresolved external symbol _WinMain at 16 referenced in function ___tmainCRTStartupCV_MessageTool.exe : fatal error LNK1120: 1 unresolved externals
Regards,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Tue May  6 05:28:10 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Mon, 05 May 2008 23:28:10 -0400
Subject: [M3devel] pixmap problem
In-Reply-To: 
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	
Message-ID: <481F9804.1E75.00D7.1@scires.com>

Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've
copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad
news is that now I am getting a command window opening up in addition to
the GUI window when the program runs.  This behavior does not occur on
v4.1.  The command window seems to be the stdout/stderr of the GUI
program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which
needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy

>>> Jay  5/5/2008 10:47 PM >>>
Randy, Yes.
The NT386 config files are all checked in.
You can use them verbatim. You don't need cminstall, I never use it,
and you shouldn't need to edit the config files at all, any edits I
make, I check in, and should be usable on all machines.
As long as you set %PATH%/%INCLUDE%/%LIB%.
If I'm wrong, I'd like to know why and try to fix.
 
Consider the config files just part of cm3.exe.
Not generally to be changed locally. Unless, well, unless you intend
to, and you should strive to make one form that is usable by all.
 
 - Jay


Date: Mon, 5 May 2008 22:42:30 -0400
From: rcoleburn at scires.com 
To: jayk123 at hotmail.com 
Subject: RE: [M3devel] pixmap problem

Jay,
When you say "took the updated config file", what do you mean?  Are you
saying I need a different cm3.cfg file?
Regards,
Randy

>>> Jay  5/5/2008 9:54 PM >>>
And you took the updated config file?
The way you can tell is that, roughly speaking, hand.obj should be in
NT386\_m3responsefile0.txt.
Or _m3responsefile1.txt, or, well, somewhere.
Anyway, I think I saw the attachment, I can check later..and with 4.1
as I said..
 
I can see about making the fix not depend on config file changes...but
it's not terrible asis, and I'd really like to merge more of the quake
code into cm3.exe..
 
 - Jay

Date: Mon, 5 May 2008 21:18:12 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com 
Subject: Re: [M3devel] pixmap problem

Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly
when the buildstandalone() directive is used.
 
Regards,
Randy

>>> Jay  5/5/2008 7:04 PM >>>
Thanks. I'll look into this tonight probably, as well as with 4.1
assuming I can find my binaries and source for it (probably).

COULD BE the pixmap problem is something else and 4.1 also has the
problem I fixed. We'll see. No need to speculate (unless I can't find my
4.1).

 - Jay


Date: Mon, 5 May 2008 10:59:27 -0400
From: rcoleburn at scires.com 
To: jayk123 at hotmail.com 
CC: m3devel at elegosoft.com 
Subject: RE: [M3devel] pixmap problem

Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files
or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy

>>> Jay  5/4/2008 11:46 AM >>>
Randy, Please try with /current/ source, as of this morning Sunday May
4 -- the changes are ALL in NT386.common, so you MUST use MY config
files, which are checked in verbatim, or you should be able edit
whatever config files you are using.
 
(It's not really a config file issue, don't blame the general confusion
people have with them.)
 
I'll try to try later, but I don't have the source right now, gotta
look on other machines, and I think it's on a machine on loan.
  Or send it to me again.
I'd also like to know if this worked with 4.1, or with any release that
offered dynamic linking to m3core.dll, on Windows.
  I recall a claim that it did. If today's change fixes it, I should be
able to investigate 4.1.
3.6 did not have such linking.
If today's change does not help, well, I still plan on debugging it at
some point..
 
If you aren't current and getting so is difficult, just send the
attachment again, it's easy for me to test.
 
Thanks,
 - Jay

From: jayk123 at hotmail.com 
To: hosking at cs.purdue.edu; rcoleburn at scires.com 
Date: Sat, 19 Jan 2008 08:52:08 +0000
CC: m3devel at elegosoft.com 
Subject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.
I was going to try on PPC_DARWIN but I guess Tony's info suffices.
 
I tried rolling hand.c back to before I changed (months/year ago),
since it is involved in bit twiddling, no change, phew.
 
Debugging here is a big humungous pain.
NT386 has good stacks and line numbers, but no locals or type info, I'd
really sometime like to get Codeview info into those .objs...I think it
is documented well enough, but still not necessarily easy, or maybe have
a C generating backend partly for this reason (and to bring up more
targets, using native tools), and function calls in disassembly I think
don't resolve; NT386GNU can't yet build this, though it will soon, but
I'm not familiar with gdb and there appears to be no type info. I'm
building m3gdb right now, I don't know if it will work, I hope it has
type info, and I'm not familiar with the relevant code. In gdb I
struggle just to view bytes in memory, add numbers to addresses and see
those, etc. I think for MY problem, I'm going to link in C code to dump
the structs. There is tracing code and I enabled it, but even it crashes
in Text_Length. At least MY problem crashes, hopefully near the problem,
whereas your problem goes all the way through to completion with no
stopping to hint where the problem is. Darn it. :) on the mock rudeness
and :( on the lack of a crash.
 
You write the bundle out and it matches, so that doesn't rule out
bundles as being the problem? (darn)
And bundles look pretty simple, a bundle is just a generated source
file with a constant in it.
Maybe newline problems? That wouldn't make sense. I just downloaded
some program that might let me separately view the ppm, maybe it'll
reveal something.
 
The bad behavior has like regularly spaced solid color veritical bars a
few pixels side across the whole picture, and regularly spaced vertical
stripes from the correct picture alternating with that. Perhaps someone
with ppm/bitmap/graphics experience has seen this behavior and it
results from some common pixmap mismanagement we could look for?
 
I have to say this is very surprising.
 
I always wondered, and now I pretty much assume -- Modula-3 never
imports/exports data in its dynamic linking, right? It alway
imports/exports functions, right?
On Windows, functions have an optional optimization, but data must be
handled differently at compile time if it is going to be dynamically
imported.
For functions, if you don't apply the optimization at compile time, the
linker will just generate a single instruction thunk instead.
 
That is, given a symbol Foo, there is a symbol __imp__Foo that is a
pointer to the actual foo in another .dll/.so.
The loader only patches pointers, one per import if you build your .dll
correctly, it doesn't patch instructions or code strewn throughout a
.dll, just one contiguous array of pointers. MAYBE they don't have to be
contiguous for each .dl you import from.
 
That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my
.dll/.exe typically has an array:
 
pointer to msvcrt!fopen
pointer to msvcrt!fclose
null
pointer to kernel32!Sleep
 
But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not
be adjacent.
 
So, going back, my point/question is that, if the compiler knows the
function is imported, it can call through __imp__Foo instead of calling
Foo.
But if it calls Foo and you import Foo, the linker will create the
function Foo that just jmps through __imp__Foo.
That doesn't work for data though. There's no ability to intervenve
like that.
So for imported data, the compiler must generated a read and
dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to
be imported.
Data imports may be faster when appropriate, but for this reason, I'd
say they aren't worth it.
And for this reason, I HOPE Modula-3 never imports/exports data.
 
Oh, you could, for data, always reference the pointer __imp_Foo, and if
non materializes, create one.
However that would suck perf in order to make an uncommon case work.
I hope Modula-3 doesn't do that either. :)
Though I guess since this global data in question...maybe it is
rare???
 
Later,
 - Jay



> From: hosking at cs.purdue.edu 
> Date: Sat, 19 Jan 2008 03:09:47 -0500
> To: rcoleburn at scires.com 
> CC: m3devel at elegosoft.com 
> Subject: Re: [M3devel] pixmap problem
> 
> Looks fine to me on I386_DARWIN.
> 
> On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:
> 
> > 
> 


Need to know the score, the latest news, or you need your Hotmail*-get
your "fix" Check it out. ( http://www.msnmobilefix.com/Default.aspx ) 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Tue May  6 05:38:03 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 6 May 2008 03:38:03 +0000
Subject: [M3devel] pixmap problem
In-Reply-To: <481F9804.1E75.00D7.1@scires.com>
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	 
	<481F9804.1E75.00D7.1@scires.com>
Message-ID: 

Randy, don't worry.
Two of these problems are trivial to fix -- PKG_USE and popups.
The pixmap one will need debugging.
 
 - Jay


Date: Mon, 5 May 2008 23:28:10 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem

Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad news is that now I am getting a command window opening up in addition to the GUI window when the program runs.  This behavior does not occur on v4.1.  The command window seems to be the stdout/stderr of the GUI program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy>>> Jay  5/5/2008 10:47 PM >>>Randy, Yes.The NT386 config files are all checked in.You can use them verbatim. You don't need cminstall, I never use it, and you shouldn't need to edit the config files at all, any edits I make, I check in, and should be usable on all machines.As long as you set %PATH%/%INCLUDE%/%LIB%.If I'm wrong, I'd like to know why and try to fix. Consider the config files just part of cm3.exe.Not generally to be changed locally. Unless, well, unless you intend to, and you should strive to make one form that is usable by all.  - Jay


Date: Mon, 5 May 2008 22:42:30 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay,
When you say "took the updated config file", what do you mean?  Are you saying I need a different cm3.cfg file?
Regards,
Randy>>> Jay  5/5/2008 9:54 PM >>>And you took the updated config file?The way you can tell is that, roughly speaking, hand.obj should be in NT386\_m3responsefile0.txt.Or _m3responsefile1.txt, or, well, somewhere.Anyway, I think I saw the attachment, I can check later..and with 4.1 as I said.. I can see about making the fix not depend on config file changes...but it's not terrible asis, and I'd really like to merge more of the quake code into cm3.exe..  - Jay


Date: Mon, 5 May 2008 21:18:12 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem
Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly when the buildstandalone() directive is used.
 
Regards,
Randy>>> Jay  5/5/2008 7:04 PM >>>Thanks. I'll look into this tonight probably, as well as with 4.1 assuming I can find my binaries and source for it (probably).COULD BE the pixmap problem is something else and 4.1 also has the problem I fixed. We'll see. No need to speculate (unless I can't find my 4.1). - Jay


Date: Mon, 5 May 2008 10:59:27 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problem
Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy>>> Jay  5/4/2008 11:46 AM >>>Randy, Please try with /current/ source, as of this morning Sunday May 4 -- the changes are ALL in NT386.common, so you MUST use MY config files, which are checked in verbatim, or you should be able edit whatever config files you are using. (It's not really a config file issue, don't blame the general confusion people have with them.) I'll try to try later, but I don't have the source right now, gotta look on other machines, and I think it's on a machine on loan.  Or send it to me again.I'd also like to know if this worked with 4.1, or with any release that offered dynamic linking to m3core.dll, on Windows.  I recall a claim that it did. If today's change fixes it, I should be able to investigate 4.1.3.6 did not have such linking.If today's change does not help, well, I still plan on debugging it at some point.. If you aren't current and getting so is difficult, just send the attachment again, it's easy for me to test. Thanks, - Jay


From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rcoleburn at scires.comDate: Sat, 19 Jan 2008 08:52:08 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.I was going to try on PPC_DARWIN but I guess Tony's info suffices. I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. Debugging here is a big humungous pain.NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)And bundles look pretty simple, a bundle is just a generated source file with a constant in it.Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something. The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for? I have to say this is very surprising. I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so.The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: pointer to msvcrt!fopenpointer to msvcrt!fclosenullpointer to kernel32!Sleep But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo.But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo.That doesn't work for data though. There's no ability to intervenve like that.So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it.And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.However that would suck perf in order to make an uncommon case work.I hope Modula-3 doesn't do that either. :)Though I guess since this global data in question...maybe it is rare??? Later, - Jay

> From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 03:09:47 -0500> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] pixmap problem> > Looks fine to me on I386_DARWIN.> > On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:> > > > 

Need to know the score, the latest news, or you need your Hotmail?-get your "fix" Check it out. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From wagner at elegosoft.com  Tue May  6 07:57:54 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 06 May 2008 07:57:54 +0200
Subject: [M3devel] m3cc build fails on older MacOS X
Message-ID: <20080506075754.o24j7xhx4wgokwwo@mail.elegosoft.com>

On % uname -a
Darwin apple.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30  
20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC  Power  
Macintosh powerpc:

echo ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./alloca.o  
./argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./dyn-string.o  
./fdmatch.o ./fibheap.o ./filename_cmp.o ./floatformat.o ./fnmatch.o  
./fopen_unlocked.o ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o  
./hashtab.o ./hex.o ./lbasename.o ./lrealpath.o  
./make-relative-prefix.o ./make-temp-file.o ./objalloc.o ./obstack.o  
./partition.o ./pexecute.o ./physmem.o ./pex-common.o ./pex-one.o  
./pex-unix.o ./safe-ctype.o ./sort.o ./spaces.o ./splay-tree.o  
./strerror.o ./strsignal.o ./unlink-if-ordinary.o ./xatexit.o  
./xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o  
./xstrndup.o > required-list
make[2]: Nothing to be done for `all'.
Makefile:191: *** Insufficient number of arguments (2) to function  
`patsubst'.  Stop.
make: *** [all-libcpp] Error 2
/bin/sh: line 1: cd: gcc: No such file or directory
make: *** No rule to make target `s-modes'.  Stop.
"/Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile", line 314: quake  
runtime error: unable to copy "./gcc/m3cgc1" to "./cm3cg": errno=2

--procedure--  -line-  -file---
cp_if              --  
postcp            314  /Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile
include_dir       360  /Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile
                     9   
/Users/wagner/work/cm3/m3-sys/m3cc/PPC_DARWIN/m3make.args

Fatal Error: package build failed
  ==> m3-sys/m3cc done

Any ideas?

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  Tue May  6 08:16:13 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 06 May 2008 08:16:13 +0200
Subject: [M3devel] m3tests again
Message-ID: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>

Hi Jay,

after several small fixes to the regression scripts, the nightrun
now shows for me

  >>> test_m3tests error extract:
  >>> failed tests: p116b p172 p185 p204 p206 p207 p209 p210 r001 e020  
e026 e029
  >>> 12 in test_m3tests 2008-05-06-01-30-23  
/home/wagner/work/cm3-ws/luthien-2008-05-06-01-30-23

One week ago there were only 6. Could you have a closer look at this?
I'm still busy with other projects.

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  Tue May  6 09:48:30 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 06 May 2008 09:48:30 +0200
Subject: [M3devel] build fails on NT386
In-Reply-To: <481F25FA.1E75.00D7.1@scires.com>
References: <481EFC54.1E75.00D7.1@scires.com>
	<481F2363.1E75.00D7.1@scires.com> <481F25FA.1E75.00D7.1@scires.com>
Message-ID: <20080506094830.lsbh8osejkgcs0cg@mail.elegosoft.com>

Quoting Randy Coleburn :

> Update:
>
> I tried to get around the problem by manually building & shipping   
> the sysutils package, then running scripts\win\upgrade.cmd again.

Randy, this is a new package needed for several quake extensions.
It has been added some months ago. Obviously nobody has updated
the cmd scripts. Could you add sysutils as prerequisite to all
scripts building cm3?

Olaf

> Now the build fails as shown below:
>
> === package C:\CM3_Sandbox\cm3\m3-sys\m3quake ===
> +++ "cm3 -build  -DROOT=C:\\CM3_Sandbox\\cm3   
> -DCM3_VERSION_TEXT=d5.7.0 -DCM3_VER
> SION_NUMBER=050700 -DCM3_LAST_CHANGED=2008-03-16 && cm3 -ship   
> -DROOT=C:\\CM3_San
> dbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_VERSION_NUMBER=050700   
> -DCM3_LAST_CHANG
> ED=2008-03-16" +++
> --- building in NT386 ---
>
> ignoring ..\src\m3overrides
>
> new source -> compiling Quake.i3
> new source -> compiling QCompiler.i3
> new source -> compiling QCode.i3
> new source -> compiling QValue.i3
> new source -> compiling QVSeq.i3
> new source -> compiling QVTbl.i3
> new source -> compiling QVal.i3
> new source -> compiling QMachine.i3
> new source -> compiling QToken.i3
> new source -> compiling QIdent.i3
> new source -> compiling Quake.m3
> new source -> compiling QToken.m3
> new source -> compiling QIdent.m3
> new source -> compiling QScanner.i3
> new source -> compiling QScanner.m3
> new source -> compiling QCode.m3
> new source -> compiling QCompiler.m3
> new source -> compiling QValue.m3
> new source -> compiling QVTbl.m3
> new source -> compiling QVSeqRep.i3
> new source -> compiling QVSeq.m3
>
> Fatal Error: bad version stamps: SystemWin32.m3
>
> version stamp mismatch: WinSock.gethostname
>   <4ccceffe6a8d6438> => SystemWin32.m3
>   <0e719d1414b51c34> => WinSock.i3
> SystemWin32.m3: missing imported type: _te9593bef
> ERROR: "cm3 -build  -DROOT=C:\\CM3_Sandbox\\cm3   
> -DCM3_VERSION_TEXT=d5.7.0 -DCM3_
> VERSION_NUMBER=050700 -DCM3_LAST_CHANGED=2008-03-16 && cm3 -ship   
> -DROOT=C:\\CM3_
> Sandbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_VERSION_NUMBER=050700   
> -DCM3_LAST_CH
> ANGED=2008-03-16"
> ERROR: cd C:\CM3_Sandbox\cm3\m3-sys\m3quake
> ERROR: set INSTALLROOT=C:\cm3
>
> C:\CM3_Sandbox\cm3\scripts\win>
>
> Please advise.
>
> Regards,
> Randy
>
>>>> "Randy Coleburn"  5/5/2008 3:10 PM >>>
> I have done a CVS update and decided to rebuild everything.
>
> I used the script in scripts\win\upgrade.cmd
>
> Here is a snippet of the output where it fails:
>
> ..\src\values => c:\cm3\pkg\m3front\src\values
>   Module.i3         Module.m3         Value.i3          Value.m3
>   ValueRep.i3       Constant.i3       Constant.m3       Decl.m3
>   Decl.i3           EnumElt.i3        EnumElt.m3        Exceptionz.i3
>   Exceptionz.m3     External.i3       External.m3       Field.i3
>   Field.m3          Formal.i3         Formal.m3         Ident.i3
>   Ident.m3          Method.m3         Method.i3         Procedure.i3
>   Procedure.m3      Revelation.m3     Revelation.i3     Tipe.i3
>   Tipe.m3           Variable.i3       Variable.m3
> === package C:\CM3_Sandbox\cm3\m3-sys\m3quake ===
> +++ "cm3 -build  -DROOT=C:\\CM3_Sandbox\\cm3   
> -DCM3_VERSION_TEXT=d5.7.0 -DCM3_VER
> SION_NUMBER=050700 -DCM3_LAST_CHANGED=2008-03-16 && cm3 -ship   
> -DROOT=C:\\CM3_San
> dbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_VERSION_NUMBER=050700   
> -DCM3_LAST_CHANG
> ED=2008-03-16" +++
> --- building in NT386 ---
>
> ignoring ..\src\m3overrides
>
> "C:\CM3_Sandbox\cm3\m3-sys\m3quake\src\m3makefile", line 14: quake   
> runtime error
> : unable to open "c:\cm3\pkg\sysutils\NT386\.M3EXPORTS" for reading
>
> --procedure--  -line-  -file---
> import             --  
> include_dir        14  C:\CM3_Sandbox\cm3\m3-sys\m3quake\src\m3makefile
>                     8  C:\CM3_Sandbox\cm3\m3-sys\m3quake\NT386\m3make.args
>
> Fatal Error: package build failed
> ERROR: "cm3 -build  -DROOT=C:\\CM3_Sandbox\\cm3   
> -DCM3_VERSION_TEXT=d5.7.0 -DCM3_
> VERSION_NUMBER=050700 -DCM3_LAST_CHANGED=2008-03-16 && cm3 -ship   
> -DROOT=C:\\CM3_
> Sandbox\\cm3 -DCM3_VERSION_TEXT=d5.7.0 -DCM3_VERSION_NUMBER=050700   
> -DCM3_LAST_CH
> ANGED=2008-03-16"
> ERROR: cd C:\CM3_Sandbox\cm3\m3-sys\m3quake
> ERROR: set INSTALLROOT=C:\cm3
>
> C:\CM3_Sandbox\cm3\scripts\win>
>
> Please advise.
>
> Regards,
> Randy
>



-- 
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  Tue May  6 10:07:11 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 06 May 2008 10:07:11 +0200
Subject: [M3devel] www.opencm3.net/m3tests
In-Reply-To: 
References: <313767.59466.qm@web27115.mail.ukl.yahoo.com>
	
Message-ID: <20080506100711.d2rzqie6ow08csgs@mail.elegosoft.com>

Quoting Jay :

> The "problem" here, a really really small one, is just that the link  
>  and mt commands got echoed.
> Olaf made them not echoed. I then made them conditionally echoed.
>   I made m3-sys\m3tests define M3TESTS so that NT386.common doesn't echo.
> It's not a big deal either way.
> Aha -- tests in other directories would have a problem, and I think   
> there are some.
>
> I like more echoing usually, so the system explains what is going on,
> instead of the vaguer "linking foo" sort of message.
> Granted, nobody bothers watching gcc run assembler commands, so I   
> guess it is just quite gray.

Jay, cm3 needs to behave the same on all platforms. By default
commands should _not_ be echoed to stdout or stderr; that's what the
-commands switch is for: this gives you exactly the commands the
compiler issues to invoke other tools.

For more verbose output, you may also depend on the -verbose or the
-debug switches.

Please adapt the configuration files that bey default all echoing
of commands is off.

Olaf

> I don't know how to run the Tinderbox either yet, sorry.
> I tried.
>
> For adding tests, well, there is m3-sys\m3tests.
> That is where a lot of the tests are, but not all.
> I am not sure where tests belong. I added a small number there.
> They are named with just a letter and a number.
> The letters have some meaning, explained in the m3makefile.
> "p" is programs that are run and their stdout/stderr compared   
> against expected
> "e" is programs build and the errors from the compiler checked to be  
>  reasonable.
>   I don't think in general they are expected to successfully compile  
>  or run, though the case of "warnings" may be unclear.
> "c" is programs built so a human can look at the generated code.
> There is another case I think for human checking.
> The numbers are just 001, 002, 003, etc.
> Each hundred tests are in a separate directory, like p0\p001,   
> p0\p002, p1\p100, p1\101, etc.
>
> Something like this.
> Wherever I have details wrong, just look in m3-sys\m3tests. It's   
> pretty simple, obvious, and well commented.
>
> The output is a little clearer if you have a working diff.exe on the path.
> Then what you do is search for "@@" in the output.
>
>  - Jay
>
>
> Date: Tue, 6 May 2008 03:46:27 +0200From: dabenavidesd at yahoo.esTo:   
> m3devel at elegosoft.comSubject: [M3devel] www.opencm3.net/m3testsDear   
> developers:Does the recent tests on NT386 seem broken because a   
> recent change on the m3-sys tree, or is the HTML bad generated, I   
> mean can you check the last tests Sunday, May 4th (p001 to p042) has  
>  a red background   
> http://www.opencm3.net/m3tests/m3tests-NT386-2008-04-23-13-30-57.html
p002 Text
Comparing files P0\P002\stdout.build and ..\SRC\P0\P002\STDOUT.BUILD***** P0\P002\stdout.buildlink @_m3responsefile0.txt 2>&1 > pgm.lstmt /nologo /manifest pgm.exe.manifest /outputresource:pgm.exe;1***** ..\SRC\P0\P002\STDOUT.BUILD*****Comparing files P0\P002\stderr.build and ..\SRC\P0\P002\STDERR.BUILDFC: no differences encounteredComparing files P0\P002\stdout.pgm and ..\SRC\P0\P002\STDOUT.PGMFC: no differences encounteredComparing files P0\P002\stderr.pgm and ..\SRC\P0\P002\STDERR.PGMFC: no differences encounteredand almost the same pattern in the above tests.I would suggest if it is thinkable using NT386 variant with a complete dedicated machine/system, I can try to set up one this week and send the data back (the machine is behind a proxy), but I don't remember the mail explaining the set up, and also want to know if there is a chance of run the tests with one run script.Also what is the best natural way to put a new tests, and the standard name it should   
> have?Thanks
>
>
> Enviado desde Correo Yahoo!La bandeja de entrada m?s inteligente.



-- 
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 jayk123 at hotmail.com  Tue May  6 12:49:11 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 6 May 2008 10:49:11 +0000
Subject: [M3devel] m3cc build fails on older MacOS X
In-Reply-To: <20080506075754.o24j7xhx4wgokwwo@mail.elegosoft.com>
References: <20080506075754.o24j7xhx4wgokwwo@mail.elegosoft.com>
Message-ID: 

I don't know what these Darwin versions are.
Mac OSX 10.0? 10.1? 10.2? 10.3? 10.4? 10.5?
I used to run 10.2 and could perhaps bring it back (though I'd hate to lose my PPC_LINUX install.. :( )
 
> make[2]: Nothing to be done for `all'.> Makefile:191: *** Insufficient number of arguments (2) to function > `patsubst'. Stop.
Hopefully that's enough context though.
 
The rest is a cascade.
What happens if you remove all my m3makefile wierdness (which works everywhere else..) and just configure and make?
 
Can I ssh into this?
 
 - Jay



> Date: Tue, 6 May 2008 07:57:54 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] m3cc build fails on older MacOS X> > On % uname -a> Darwin apple.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 > 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power > Macintosh powerpc:> > echo ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./alloca.o > ./argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./dyn-string.o > ./fdmatch.o ./fibheap.o ./filename_cmp.o ./floatformat.o ./fnmatch.o > ./fopen_unlocked.o ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o > ./hashtab.o ./hex.o ./lbasename.o ./lrealpath.o > ./make-relative-prefix.o ./make-temp-file.o ./objalloc.o ./obstack.o > ./partition.o ./pexecute.o ./physmem.o ./pex-common.o ./pex-one.o > ./pex-unix.o ./safe-ctype.o ./sort.o ./spaces.o ./splay-tree.o > ./strerror.o ./strsignal.o ./unlink-if-ordinary.o ./xatexit.o > ./xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o > ./xstrndup.o > required-list> make[2]: Nothing to be done for `all'.> Makefile:191: *** Insufficient number of arguments (2) to function > `patsubst'. Stop.> make: *** [all-libcpp] Error 2> /bin/sh: line 1: cd: gcc: No such file or directory> make: *** No rule to make target `s-modes'. Stop.> "/Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile", line 314: quake > runtime error: unable to copy "./gcc/m3cgc1" to "./cm3cg": errno=2> > --procedure-- -line- -file---> cp_if -- > postcp 314 /Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile> include_dir 360 /Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile> 9 > /Users/wagner/work/cm3/m3-sys/m3cc/PPC_DARWIN/m3make.args> > Fatal Error: package build failed> ==> m3-sys/m3cc done> > Any ideas?> > 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 jayk123 at hotmail.com  Tue May  6 12:57:01 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 6 May 2008 10:57:01 +0000
Subject: [M3devel] www.opencm3.net/m3tests
In-Reply-To: <20080506100711.d2rzqie6ow08csgs@mail.elegosoft.com>
References: <313767.59466.qm@web27115.mail.ukl.yahoo.com>
	 
	<20080506100711.d2rzqie6ow08csgs@mail.elegosoft.com>
Message-ID: 

Olaf, I don't entirely agree.
The logs should be fairly informative without intervention.
Just not too verbose. I'd would rather remove the lines that say "compiling" and show the cm3cg invocations.
But more than one line per source file is too much.
-commands doesn't really work. Lots of bogus extra commands are echoed (rm .tmp), and not all the commands that are run are echoed.
 
I understand that stability for tests is also a goal, but information for the interactive user and for post mortem debugging via a log is also valuable, and these are contrary to stability-for-tests. Somehow contradictory goals need to be met.
 
How about a compromise?
How about we always log more stuff to TARGET/cm3.log?
 And then exactly what you want to stdout/stderr?
While, as I said, more than one line per file is overkill, as part of this compromise I'd be willing to include the cm3cg and as invocation.
 
Have folks used build.exe in the Windows NT DDK?
It's model is close to what you get here.
It has three sets of information:
  to the console/stdout 
  build.log, build.exe is a wrapper over make, and this includes all the make output -- all the command lines run 
  build.err, a small subset of console/stdout output
 
My "design" here has been to avoid over-verbosity. Link and mt run on the order of once, or a small number of times, per directory, so showing the full command line (response files...) isn't so verbose -- vs. say something shown once per compiled file.
 
There's another "problem" here that I have partly fixed.
Underlying errors are not shown on console/stdout/stderr.
They are often in like TARGET/m3core.lst.
 
I changed stuff to refer to that file, after having hunted the errors down myself slowly the first time.
 
We could change things to alway says "see TARGET/cm3.log" for more information, or somesuch.
 
 - Jay



> Date: Tue, 6 May 2008 10:07:11 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] www.opencm3.net/m3tests> > Quoting Jay :> > > The "problem" here, a really really small one, is just that the link > > and mt commands got echoed.> > Olaf made them not echoed. I then made them conditionally echoed.> > I made m3-sys\m3tests define M3TESTS so that NT386.common doesn't echo.> > It's not a big deal either way.> > Aha -- tests in other directories would have a problem, and I think > > there are some.> >> > I like more echoing usually, so the system explains what is going on,> > instead of the vaguer "linking foo" sort of message.> > Granted, nobody bothers watching gcc run assembler commands, so I > > guess it is just quite gray.> > Jay, cm3 needs to behave the same on all platforms. By default> commands should _not_ be echoed to stdout or stderr; that's what the> -commands switch is for: this gives you exactly the commands the> compiler issues to invoke other tools.> > For more verbose output, you may also depend on the -verbose or the> -debug switches.> > Please adapt the configuration files that bey default all echoing> of commands is off.> > Olaf> > > I don't know how to run the Tinderbox either yet, sorry.> > I tried.> >> > For adding tests, well, there is m3-sys\m3tests.> > That is where a lot of the tests are, but not all.> > I am not sure where tests belong. I added a small number there.> > They are named with just a letter and a number.> > The letters have some meaning, explained in the m3makefile.> > "p" is programs that are run and their stdout/stderr compared > > against expected> > "e" is programs build and the errors from the compiler checked to be > > reasonable.> > I don't think in general they are expected to successfully compile > > or run, though the case of "warnings" may be unclear.> > "c" is programs built so a human can look at the generated code.> > There is another case I think for human checking.> > The numbers are just 001, 002, 003, etc.> > Each hundred tests are in a separate directory, like p0\p001, > > p0\p002, p1\p100, p1\101, etc.> >> > Something like this.> > Wherever I have details wrong, just look in m3-sys\m3tests. It's > > pretty simple, obvious, and well commented.> >> > The output is a little clearer if you have a working diff.exe on the path.> > Then what you do is search for "@@" in the output.> >> > - Jay> >> >> > Date: Tue, 6 May 2008 03:46:27 +0200From: dabenavidesd at yahoo.esTo: > > m3devel at elegosoft.comSubject: [M3devel] www.opencm3.net/m3testsDear > > developers:Does the recent tests on NT386 seem broken because a > > recent change on the m3-sys tree, or is the HTML bad generated, I > > mean can you check the last tests Sunday, May 4th (p001 to p042) has > > a red background > > http://www.opencm3.net/m3tests/m3tests-NT386-2008-04-23-13-30-57.html
p002 Text
Comparing files P0\P002\stdout.build and ..\SRC\P0\P002\STDOUT.BUILD***** P0\P002\stdout.buildlink @_m3responsefile0.txt 2>&1 > pgm.lstmt /nologo /manifest pgm.exe.manifest /outputresource:pgm.exe;1***** ..\SRC\P0\P002\STDOUT.BUILD*****Comparing files P0\P002\stderr.build and ..\SRC\P0\P002\STDERR.BUILDFC: no differences encounteredComparing files P0\P002\stdout.pgm and ..\SRC\P0\P002\STDOUT.PGMFC: no differences encounteredComparing files P0\P002\stderr.pgm and ..\SRC\P0\P002\STDERR.PGMFC: no differences encounteredand almost the same pattern in the above tests.I would suggest if it is thinkable using NT386 variant with a complete dedicated machine/system, I can try to set up one this week and send the data back (the machine is behind a proxy), but I don't remember the mail explaining the set up, and also want to know if there is a chance of run the tests with one run script.Also what is the best natural way to put a new tests, and the standard name it should > > have?Thanks> >> >> > Enviado desde Correo Yahoo!La bandeja de entrada m?s inteligente.> > > > -- > 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  Tue May  6 13:02:47 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 06 May 2008 13:02:47 +0200
Subject: [M3devel] m3cc build fails on older MacOS X
In-Reply-To: 
References: <20080506075754.o24j7xhx4wgokwwo@mail.elegosoft.com>
	
Message-ID: <20080506130247.50uj68o11twcgkog@mail.elegosoft.com>

Quoting Jay :

> I don't know what these Darwin versions are.
> Mac OSX 10.0? 10.1? 10.2? 10.3? 10.4? 10.5?
> I used to run 10.2 and could perhaps bring it back (though I'd hate   
> to lose my PPC_LINUX install.. :( )
>
>> make[2]: Nothing to be done for `all'.> Makefile:191: ***   
>> Insufficient number of arguments (2) to function > `patsubst'. Stop.
> Hopefully that's enough context though.
>
> The rest is a cascade.
> What happens if you remove all my m3makefile wierdness (which works   
> everywhere else..) and just configure and make?
>
> Can I ssh into this?

Not currently, but I could arrange that sometime this evening (19:00-
24:00 CEST), if that suits you. I'll take this computer with me on
holidays in two days, so it will probably not be available then.
But you can peek into it today if you want.

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 jayk123 at hotmail.com  Tue May  6 13:17:53 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 6 May 2008 11:17:53 +0000
Subject: [M3devel] www.opencm3.net/m3tests
In-Reply-To: 
References: <313767.59466.qm@web27115.mail.ukl.yahoo.com>
	 
	<20080506100711.d2rzqie6ow08csgs@mail.elegosoft.com> 
	
Message-ID: 

When I say show cm3cg/as invocations, I mean in this new TARGET/cm3.log.
As I said, I propose exactly the stdout/stderr you want, but then some other output always, a log file.
Also, about -commands, I have also claimed that it does work -- talking out of both sides of my mouth. The extra commands it prints are obviously harmless. I forget what doesn't print, maybe exec vs. q_exec? Also the '@' character wasn't working with q_exec, but that isn't necessarily relevant here..I forgot where I use exec vs. q_exec..
And there plenty of other ways to debug than -commands and it is "just" a debugging facility..
 
 - Jay


From: jayk123 at hotmail.comTo: wagner at elegosoft.com; m3devel at elegosoft.comDate: Tue, 6 May 2008 10:57:01 +0000Subject: Re: [M3devel] www.opencm3.net/m3tests


Olaf, I don't entirely agree.The logs should be fairly informative without intervention.Just not too verbose. I'd would rather remove the lines that say "compiling" and show the cm3cg invocations.But more than one line per source file is too much.-commands doesn't really work. Lots of bogus extra commands are echoed (rm .tmp), and not all the commands that are run are echoed. I understand that stability for tests is also a goal, but information for the interactive user and for post mortem debugging via a log is also valuable, and these are contrary to stability-for-tests. Somehow contradictory goals need to be met. How about a compromise?How about we always log more stuff to TARGET/cm3.log? And then exactly what you want to stdout/stderr?While, as I said, more than one line per file is overkill, as part of this compromise I'd be willing to include the cm3cg and as invocation. Have folks used build.exe in the Windows NT DDK?It's model is close to what you get here.It has three sets of information:  to the console/stdout   build.log, build.exe is a wrapper over make, and this includes all the make output -- all the command lines run   build.err, a small subset of console/stdout output My "design" here has been to avoid over-verbosity. Link and mt run on the order of once, or a small number of times, per directory, so showing the full command line (response files...) isn't so verbose -- vs. say something shown once per compiled file. There's another "problem" here that I have partly fixed.Underlying errors are not shown on console/stdout/stderr.They are often in like TARGET/m3core.lst. I changed stuff to refer to that file, after having hunted the errors down myself slowly the first time. We could change things to alway says "see TARGET/cm3.log" for more information, or somesuch.  - Jay

> Date: Tue, 6 May 2008 10:07:11 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] www.opencm3.net/m3tests> > Quoting Jay :> > > The "problem" here, a really really small one, is just that the link > > and mt commands got echoed.> > Olaf made them not echoed. I then made them conditionally echoed.> > I made m3-sys\m3tests define M3TESTS so that NT386.common doesn't echo.> > It's not a big deal either way.> > Aha -- tests in other directories would have a problem, and I think > > there are some.> >> > I like more echoing usually, so the system explains what is going on,> > instead of the vaguer "linking foo" sort of message.> > Granted, nobody bothers watching gcc run assembler commands, so I > > guess it is just quite gray.> > Jay, cm3 needs to behave the same on all platforms. By default> commands should _not_ be echoed to stdout or stderr; that's what the> -commands switch is for: this gives you exactly the commands the> compiler issues to invoke other tools.> > For more verbose output, you may also depend on the -verbose or the> -debug switches.> > Please adapt the configuration files that bey default all echoing> of commands is off.> > Olaf> > > I don't know how to run the Tinderbox either yet, sorry.> > I tried.> >> > For adding tests, well, there is m3-sys\m3tests.> > That is where a lot of the tests are, but not all.> > I am not sure where tests belong. I added a small number there.> > They are named with just a letter and a number.> > The letters have some meaning, explained in the m3makefile.> > "p" is programs that are run and their stdout/stderr compared > > against expected> > "e" is programs build and the errors from the compiler checked to be > > reasonable.> > I don't think in general they are expected to successfully compile > > or run, though the case of "warnings" may be unclear.> > "c" is programs built so a human can look at the generated code.> > There is another case I think for human checking.> > The numbers are just 001, 002, 003, etc.> > Each hundred tests are in a separate directory, like p0\p001, > > p0\p002, p1\p100, p1\101, etc.> >> > Something like this.> > Wherever I have details wrong, just look in m3-sys\m3tests. It's > > pretty simple, obvious, and well commented.> >> > The output is a little clearer if you have a working diff.exe on the path.> > Then what you do is search for "@@" in the output.> >> > - Jay> >> >> > Date: Tue, 6 May 2008 03:46:27 +0200From: dabenavidesd at yahoo.esTo: > > m3devel at elegosoft.comSubject: [M3devel] www.opencm3.net/m3testsDear > > developers:Does the recent tests on NT386 seem broken because a > > recent change on the m3-sys tree, or is the HTML bad generated, I > > mean can you check the last tests Sunday, May 4th (p001 to p042) has > > a red background > > http://www.opencm3.net/m3tests/m3tests-NT386-2008-04-23-13-30-57.html
p002 Text
Comparing files P0\P002\stdout.build and ..\SRC\P0\P002\STDOUT.BUILD***** P0\P002\stdout.buildlink @_m3responsefile0.txt 2>&1 > pgm.lstmt /nologo /manifest pgm.exe.manifest /outputresource:pgm.exe;1***** ..\SRC\P0\P002\STDOUT.BUILD*****Comparing files P0\P002\stderr.build and ..\SRC\P0\P002\STDERR.BUILDFC: no differences encounteredComparing files P0\P002\stdout.pgm and ..\SRC\P0\P002\STDOUT.PGMFC: no differences encounteredComparing files P0\P002\stderr.pgm and ..\SRC\P0\P002\STDERR.PGMFC: no differences encounteredand almost the same pattern in the above tests.I would suggest if it is thinkable using NT386 variant with a complete dedicated machine/system, I can try to set up one this week and send the data back (the machine is behind a proxy), but I don't remember the mail explaining the set up, and also want to know if there is a chance of run the tests with one run script.Also what is the best natural way to put a new tests, and the standard name it should > > have?Thanks> >> >> > Enviado desde Correo Yahoo!La bandeja de entrada m?s inteligente.> > > > -- > 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 jayk123 at hotmail.com  Tue May  6 13:25:21 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 6 May 2008 11:25:21 +0000
Subject: [M3devel] m3cc build fails on older MacOS X
In-Reply-To: <20080506130247.50uj68o11twcgkog@mail.elegosoft.com>
References: <20080506075754.o24j7xhx4wgokwwo@mail.elegosoft.com>
	 
	<20080506130247.50uj68o11twcgkog@mail.elegosoft.com>
Message-ID: 

Olaf, can you try without my m3makefile wierdness, that works elsewhere?
 
  cd %CVSROOT%/m3-sys/m3cc    mkdir obj1     cd obj1   ../gcc/configure --disable-bootstrap --enable-languages=c,cm3cg    make 
 I'm not sure of "cm3cg", it might be "m3cg".  And you can just omit that anyway, I doubt the error is m3 related. 
(Tony: I don't believe --srcdir is needed. configure figures it out; granted, maybe not trivially.) 
?
 I expect you will get the same error.  Which isn't the final answer, just some relevant data.   And if I'm wrong, well, that suggests some fix. 
 
 
 - Jay



> Date: Tue, 6 May 2008 13:02:47 +0200> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: RE: [M3devel] m3cc build fails on older MacOS X> > Quoting Jay :> > > I don't know what these Darwin versions are.> > Mac OSX 10.0? 10.1? 10.2? 10.3? 10.4? 10.5?> > I used to run 10.2 and could perhaps bring it back (though I'd hate > > to lose my PPC_LINUX install.. :( )> >> >> make[2]: Nothing to be done for `all'.> Makefile:191: *** > >> Insufficient number of arguments (2) to function > `patsubst'. Stop.> > Hopefully that's enough context though.> >> > The rest is a cascade.> > What happens if you remove all my m3makefile wierdness (which works > > everywhere else..) and just configure and make?> >> > Can I ssh into this?> > Not currently, but I could arrange that sometime this evening (19:00-> 24:00 CEST), if that suits you. I'll take this computer with me on> holidays in two days, so it will probably not be available then.> But you can peek into it today if you want.> > 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  Tue May  6 15:33:18 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 06 May 2008 15:33:18 +0200
Subject: [M3devel] cm3 command line interface and output;
	was: RE: 	www.opencm3.net/m3tests
In-Reply-To: 
References: <313767.59466.qm@web27115.mail.ukl.yahoo.com>
	
	<20080506100711.d2rzqie6ow08csgs@mail.elegosoft.com>
	
	
Message-ID: <20080506153318.a50ttk23488ksk00@mail.elegosoft.com>

Quoting Jay :

> When I say show cm3cg/as invocations, I mean in this new TARGET/cm3.log.
> As I said, I propose exactly the stdout/stderr you want, but then   
> some other output always, a log file.
> Also, about -commands, I have also claimed that it does work --   
> talking out of both sides of my mouth. The extra commands it prints   
> are obviously harmless. I forget what doesn't print, maybe exec vs.   
> q_exec? Also the '@' character wasn't working with q_exec, but that   
> isn't necessarily relevant here..I forgot where I use exec vs.   
> q_exec..
> And there plenty of other ways to debug than -commands and it is   
> "just" a debugging facility..

I've got a rather definite opinion about the output behaviour of
cm3. It's like this, and I would like others to comment, too:

  o cm3 without any switches (-commands, -debug, -verbose) should
    not output any called commands, neither to stdout nor stderr.
    It may print what it is doing in an abstract, target independent
    (short) way. This output may refer to compilation units, interfaces,
    modules, and compilation phases, but not to target specific commands
    and files (unless there are errors, of course) Even then I'd like
    to abstract from differences.

  o cm3 -silent should suppress the normal output, except for warnings
    and error messages.

  o cm3 -commands should output exactly all invokations of externals
    commands so that they can be re-executed from the command line
    if necessary.

I realize that it might not be this way in every aspect, so that
we may need to adapt the code here and there. But in my experience
it has worked this way quite well. Here are some points to consider:

  o We need consistent behaviour and output across all target platforms.
    This is not just a requirement of regression testing, but also of
    a consistent user interface. I don't want different behaviour on
    different platforms.

  o If -commands does not work as expected for some use case,
    we need to fix it.

  o If q_exec or whatever quake function is still deficient in this
    respect, we need to fix/adapt it. It should not be much effort.

  o I find the options -commands, -verbose, -debug, -silent a very
    good categorization of information types, intuitively understandable
    and usable in practive (as I've never had any problems with it, but
    have used them efficiently for years). So I don't see the point
    in changing anything, unless there is a better concept.

  o I don't think it is a good idea to write any log files by default
    (apart from the stdout and stderr streams).

This is of course just my opinion, but unless there are others in
favour of changes (and I'd like some motivation for them) I'd insist
that we keep the existing design.

Olaf

> From: jayk123 at hotmail.comTo: wagner at elegosoft.com;   
> m3devel at elegosoft.comDate: Tue, 6 May 2008 10:57:01 +0000Subject:   
> Re: [M3devel] www.opencm3.net/m3tests
>
>
> Olaf, I don't entirely agree.The logs should be fairly informative   
> without intervention.Just not too verbose. I'd would rather remove   
> the lines that say "compiling" and show the cm3cg invocations.But   
> more than one line per source file is too much.-commands doesn't   
> really work. Lots of bogus extra commands are echoed (rm .tmp), and   
> not all the commands that are run are echoed. I understand that   
> stability for tests is also a goal, but information for the   
> interactive user and for post mortem debugging via a log is also   
> valuable, and these are contrary to stability-for-tests. Somehow   
> contradictory goals need to be met. How about a compromise?How about  
>  we always log more stuff to TARGET/cm3.log? And then exactly what   
> you want to stdout/stderr?While, as I said, more than one line per   
> file is overkill, as part of this compromise I'd be willing to   
> include the cm3cg and as invocation. Have folks used build.exe in   
> the Windows NT DDK?It's model is close to what you get here.It has   
> three sets of information:  to the console/stdout   build.log,   
> build.exe is a wrapper over make, and this includes all the make   
> output -- all the command lines run   build.err, a small subset of   
> console/stdout output My "design" here has been to avoid   
> over-verbosity. Link and mt run on the order of once, or a small   
> number of times, per directory, so showing the full command line   
> (response files...) isn't so verbose -- vs. say something shown once  
>  per compiled file. There's another "problem" here that I have  
> partly  fixed.Underlying errors are not shown on  
> console/stdout/stderr.They  are often in like TARGET/m3core.lst. I  
> changed stuff to refer to  that file, after having hunted the errors  
> down myself slowly the  first time. We could change things to alway  
> says "see  TARGET/cm3.log" for more information, or somesuch.  - Jay
>
>> Date: Tue, 6 May 2008 10:07:11 +0200> From: wagner at elegosoft.com>   
>> To: m3devel at elegosoft.com> Subject: Re: [M3devel]   
>> www.opencm3.net/m3tests> > Quoting Jay :> > >   
>> The "problem" here, a really really small one, is just that the   
>> link > > and mt commands got echoed.> > Olaf made them not echoed.   
>> I then made them conditionally echoed.> > I made m3-sys\m3tests   
>> define M3TESTS so that NT386.common doesn't echo.> > It's not a big  
>>  deal either way.> > Aha -- tests in other directories would have a  
>>  problem, and I think > > there are some.> >> > I like more echoing  
>>  usually, so the system explains what is going on,> > instead of  
>> the  vaguer "linking foo" sort of message.> > Granted, nobody  
>> bothers  watching gcc run assembler commands, so I > > guess it is  
>> just  quite gray.> > Jay, cm3 needs to behave the same on all  
>> platforms.  By default> commands should _not_ be echoed to stdout  
>> or stderr;  that's what the> -commands switch is for: this gives  
>> you exactly  the commands the> compiler issues to invoke other  
>> tools.> > For  more verbose output, you may also depend on the  
>> -verbose or the>  -debug switches.> > Please adapt the  
>> configuration files that bey  default all echoing> of commands is  
>> off.> > Olaf> > > I don't know  how to run the Tinderbox either  
>> yet, sorry.> > I tried.> >> > For  adding tests, well, there is  
>> m3-sys\m3tests.> > That is where a lot  of the tests are, but not  
>> all.> > I am not sure where tests belong.  I added a small number  
>> there.> > They are named with just a letter  and a number.> > The  
>> letters have some meaning, explained in the  m3makefile.> > "p" is  
>> programs that are run and their stdout/stderr  compared > > against  
>> expected> > "e" is programs build and the  errors from the compiler  
>> checked to be > > reasonable.> > I don't  think in general they are  
>> expected to successfully compile > > or  run, though the case of  
>> "warnings" may be unclear.> > "c" is  programs built so a human can  
>> look at the generated code.> > There  is another case I think for  
>> human checking.> > The numbers are just  001, 002, 003, etc.> >  
>> Each hundred tests are in a separate  directory, like p0\p001, > >  
>> p0\p002, p1\p100, p1\101, etc.> >> >  Something like this.> >  
>> Wherever I have details wrong, just look in  m3-sys\m3tests. It's >  
>> > pretty simple, obvious, and well  commented.> >> > The output is  
>> a little clearer if you have a  working diff.exe on the path.> >  
>> Then what you do is search for  "@@" in the output.> >> > - Jay> >>  
>> >> > Date: Tue, 6 May 2008  03:46:27 +0200From:  
>> dabenavidesd at yahoo.esTo: > >  m3devel at elegosoft.comSubject:  
>> [M3devel] www.opencm3.net/m3testsDear  > > developers:Does the  
>> recent tests on NT386 seem broken because a  > > recent change on  
>> the m3-sys tree, or is the HTML bad generated,  I > > mean can you  
>> check the last tests Sunday, May 4th (p001 to  p042) has > > a red  
>> background > >   
>> http://www.opencm3.net/m3tests/m3tests-NT386-2008-04-23-13-30-57.html
p002 Text
Comparing files P0\P002\stdout.build and ..\SRC\P0\P002\STDOUT.BUILD***** P0\P002\stdout.buildlink @_m3responsefile0.txt 2>&1 > pgm.lstmt /nologo /manifest pgm.exe.manifest /outputresource:pgm.exe;1***** ..\SRC\P0\P002\STDOUT.BUILD*****Comparing files P0\P002\stderr.build and ..\SRC\P0\P002\STDERR.BUILDFC: no differences encounteredComparing files P0\P002\stdout.pgm and ..\SRC\P0\P002\STDOUT.PGMFC: no differences encounteredComparing files P0\P002\stderr.pgm and ..\SRC\P0\P002\STDERR.PGMFC: no differences encounteredand almost the same pattern in the above tests.I would suggest if it is thinkable using NT386 variant with a complete dedicated machine/system, I can try to set up one this week and send the data back (the machine is behind a proxy), but I don't remember the mail explaining the set up, and also want to know if there is a chance of run the tests with one run script.Also what is the best natural way to put a new tests, and the standard name it should > > have?Thanks> >> >> > Enviado desde Correo Yahoo!La bandeja de entrada m?s inteligente.> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:   
>> DE163214194>



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



From hosking at cs.purdue.edu  Tue May  6 15:56:40 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 6 May 2008 09:56:40 -0400
Subject: [M3devel] m3cc build fails on older MacOS X
In-Reply-To: 
References: <20080506075754.o24j7xhx4wgokwwo@mail.elegosoft.com>
	
	<20080506130247.50uj68o11twcgkog@mail.elegosoft.com>
	
Message-ID: 

yes,  it should be m m3cg.  --srcdir is not needed.

On May 6, 2008, at 7:25 AM, Jay wrote:

> Olaf, can you try without my m3makefile wierdness, that works  
> elsewhere?
>
>   cd %CVSROOT%/m3-sys/m3cc
>   mkdir obj1
>   cd obj1
>   ../gcc/configure --disable-bootstrap --enable-languages=c,cm3cg
>   make
>  I'm not sure of "cm3cg", it might be "m3cg".
>  And you can just omit that anyway, I doubt the error is m3 related.
> (Tony: I don't believe --srcdir is needed. configure figures it out;  
> granted, maybe not trivially.)
>
> ?
>  I expect you will get the same error.
>  Which isn't the final answer, just some relevant data.
>  And if I'm wrong, well, that suggests some fix.
>
>
>  - Jay
>
>
>
> > Date: Tue, 6 May 2008 13:02:47 +0200
> > From: wagner at elegosoft.com
> > To: jayk123 at hotmail.com
> > CC: m3devel at elegosoft.com
> > Subject: RE: [M3devel] m3cc build fails on older MacOS X
> >
> > Quoting Jay :
> >
> > > I don't know what these Darwin versions are.
> > > Mac OSX 10.0? 10.1? 10.2? 10.3? 10.4? 10.5?
> > > I used to run 10.2 and could perhaps bring it back (though I'd  
> hate
> > > to lose my PPC_LINUX install.. :( )
> > >
> > >> make[2]: Nothing to be done for `all'.> Makefile:191: ***
> > >> Insufficient number of arguments (2) to function > `patsubst'.  
> Stop.
> > > Hopefully that's enough context though.
> > >
> > > The rest is a cascade.
> > > What happens if you remove all my m3makefile wierdness (which  
> works
> > > everywhere else..) and just configure and make?
> > >
> > > Can I ssh into this?
> >
> > Not currently, but I could arrange that sometime this evening  
> (19:00-
> > 24:00 CEST), if that suits you. I'll take this computer with me on
> > holidays in two days, so it will probably not be available then.
> > But you can peek into it today if you want.
> >
> > 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 jayk123 at hotmail.com  Tue May  6 16:02:48 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 6 May 2008 14:02:48 +0000
Subject: [M3devel] cm3 command line interface and output;
	was: RE: 	www.opencm3.net/m3tests
In-Reply-To: <20080506153318.a50ttk23488ksk00@mail.elegosoft.com>
References: <313767.59466.qm@web27115.mail.ukl.yahoo.com>
	
	<20080506100711.d2rzqie6ow08csgs@mail.elegosoft.com>
	
	 
	<20080506153318.a50ttk23488ksk00@mail.elegosoft.com>
Message-ID: 

Well, Olaf, I see your point, but I don't entirely agree.
I believe there are contradictory goals.
Which is partly to say, there will always be "problems" here, though I think producing a more detailed log file is a good compromise.
 
In particular, consider the role of "remote debugging", or even local debugging.
Wouldn't it be great if many situations could be debugged from merely looking at "m3.log" from the first and only run that failed? What if the problem is intermittent? You can't always rely on running again with different switches. I have to post-mortem debug lots of stuff and logs are indispensible. They don't always work, and they can't always work, but they can be extremely helpful.
 
To a large extent, you need to plan for failure. There will be errors. When there is an error, what is the design that allows quickest easiest diagnosis, some large percentage of the time? A nice friendly abstract stdout that hides details, or something with more information? Or somethin in between like a friendly stdout and a verbose log file?
 
The need for a cross-platform user experience is unclear -- I want file names printed in a form my editor understands, and my editors unfortunately are not consistent. Perhaps, as you allude, the "success" ui should be cross platform, and in the face of an error, the experience can devolve and contain platform specific details. Here you can see the tests already having problems, as the paths have forward or backward slashes, and "crashes" have different appearances. So far this has been mostly papered over (which reminds me, I need to get the darwin and bsd variants; currently only NT and Linux are handled).
 
For regression tests, yes I understand.
However, stdout/stderr is a very crude thing.
It'd be nice if the code could make, uh, like, "function calls" to indicate what happened instead of random text that is meant to be both human and machine consumable.
But I know that's just too high tech to happen any time soon..
 
(Similarly, "function calls" to drive a compiler are a good idea to. "Command lines" are also very crude and type-unsafe..the whole problem with spaces....)
 
A good example I think of something that doesn't work well today is what happens when there are link errors.
The problem here isn't so much the echoing of commands, but the appearance of the linker output.
All you get is cm3 checks the exit code and/or the existance of the output file and stdout indicates a boolean success/faliure. User has to dig into another file to find the actual error. Now, again, I am talking out of both sides. I argue for a log for the verbose information, and now complain about having to dig into that log. I would at least like to have there be one such log, not one for the link output and nothing else. That would be a little better. The inconvenience of having to dig into a log is a more difficult problem, I know very well, related again to the crudeness of stdout. Because the linker has no structured way to report errors, other than an exit code, whatever wraps it is left to some crude device like attempting to "parse" the stdout. This is a well traveled path, and it can work quite well, but it is also frought with peril, as different linkers and different versions of linkers output errors differently...
 
As well, on the other end of things, you know, if you assume success, you really want less output.
make-dist.cmd is really good this way, though make-dist.py is not yet.
In there I suppress a LOT of output, but I do keep it in logs in case of failure..
 
I don't have a conclusion.
I understand the goals.
I also believe logging, to stdout or to a file, greatly aids debugging.
I think producing a log file in the output directory is a good compromise, and one I have seen successfully used.
  Though you don't want the easy out of having a log file to lead to the log file becoming too verbose. I have seen log files that take a while for some editors to open..and people throwing in "verbose" switches and not realize the damage they are doing. I did it myself once. I threw in /verbose on the Visual C++ linker and the output of that is so voluminous that it slows things down. It's great for debugging certain problems, but too expensive to put in all the time "just in case".
 
 - Jay


> Date: Tue, 6 May 2008 15:33:18 +0200> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: cm3 command line interface and output; was: RE: [M3devel] www.opencm3.net/m3tests> > Quoting Jay :> > > When I say show cm3cg/as invocations, I mean in this new TARGET/cm3.log.> > As I said, I propose exactly the stdout/stderr you want, but then > > some other output always, a log file.> > Also, about -commands, I have also claimed that it does work -- > > talking out of both sides of my mouth. The extra commands it prints > > are obviously harmless. I forget what doesn't print, maybe exec vs. > > q_exec? Also the '@' character wasn't working with q_exec, but that > > isn't necessarily relevant here..I forgot where I use exec vs. > > q_exec..> > And there plenty of other ways to debug than -commands and it is > > "just" a debugging facility..> > I've got a rather definite opinion about the output behaviour of> cm3. It's like this, and I would like others to comment, too:> > o cm3 without any switches (-commands, -debug, -verbose) should> not output any called commands, neither to stdout nor stderr.> It may print what it is doing in an abstract, target independent> (short) way. This output may refer to compilation units, interfaces,> modules, and compilation phases, but not to target specific commands> and files (unless there are errors, of course) Even then I'd like> to abstract from differences.> > o cm3 -silent should suppress the normal output, except for warnings> and error messages.> > o cm3 -commands should output exactly all invokations of externals> commands so that they can be re-executed from the command line> if necessary.> > I realize that it might not be this way in every aspect, so that> we may need to adapt the code here and there. But in my experience> it has worked this way quite well. Here are some points to consider:> > o We need consistent behaviour and output across all target platforms.> This is not just a requirement of regression testing, but also of> a consistent user interface. I don't want different behaviour on> different platforms.> > o If -commands does not work as expected for some use case,> we need to fix it.> > o If q_exec or whatever quake function is still deficient in this> respect, we need to fix/adapt it. It should not be much effort.> > o I find the options -commands, -verbose, -debug, -silent a very> good categorization of information types, intuitively understandable> and usable in practive (as I've never had any problems with it, but> have used them efficiently for years). So I don't see the point> in changing anything, unless there is a better concept.> > o I don't think it is a good idea to write any log files by default> (apart from the stdout and stderr streams).> > This is of course just my opinion, but unless there are others in> favour of changes (and I'd like some motivation for them) I'd insist> that we keep the existing design.> > Olaf> > > From: jayk123 at hotmail.comTo: wagner at elegosoft.com; > > m3devel at elegosoft.comDate: Tue, 6 May 2008 10:57:01 +0000Subject: > > Re: [M3devel] www.opencm3.net/m3tests> >> >> > Olaf, I don't entirely agree.The logs should be fairly informative > > without intervention.Just not too verbose. I'd would rather remove > > the lines that say "compiling" and show the cm3cg invocations.But > > more than one line per source file is too much.-commands doesn't > > really work. Lots of bogus extra commands are echoed (rm .tmp), and > > not all the commands that are run are echoed. I understand that > > stability for tests is also a goal, but information for the > > interactive user and for post mortem debugging via a log is also > > valuable, and these are contrary to stability-for-tests. Somehow > > contradictory goals need to be met. How about a compromise?How about > > we always log more stuff to TARGET/cm3.log? And then exactly what > > you want to stdout/stderr?While, as I said, more than one line per > > file is overkill, as part of this compromise I'd be willing to > > include the cm3cg and as invocation. Have folks used build.exe in > > the Windows NT DDK?It's model is close to what you get here.It has > > three sets of information: to the console/stdout build.log, > > build.exe is a wrapper over make, and this includes all the make > > output -- all the command lines run build.err, a small subset of > > console/stdout output My "design" here has been to avoid > > over-verbosity. Link and mt run on the order of once, or a small > > number of times, per directory, so showing the full command line > > (response files...) isn't so verbose -- vs. say something shown once > > per compiled file. There's another "problem" here that I have > > partly fixed.Underlying errors are not shown on > > console/stdout/stderr.They are often in like TARGET/m3core.lst. I > > changed stuff to refer to that file, after having hunted the errors > > down myself slowly the first time. We could change things to alway > > says "see TARGET/cm3.log" for more information, or somesuch. - Jay> >> >> Date: Tue, 6 May 2008 10:07:11 +0200> From: wagner at elegosoft.com> > >> To: m3devel at elegosoft.com> Subject: Re: [M3devel] > >> www.opencm3.net/m3tests> > Quoting Jay :> > > > >> The "problem" here, a really really small one, is just that the > >> link > > and mt commands got echoed.> > Olaf made them not echoed. > >> I then made them conditionally echoed.> > I made m3-sys\m3tests > >> define M3TESTS so that NT386.common doesn't echo.> > It's not a big > >> deal either way.> > Aha -- tests in other directories would have a > >> problem, and I think > > there are some.> >> > I like more echoing > >> usually, so the system explains what is going on,> > instead of > >> the vaguer "linking foo" sort of message.> > Granted, nobody > >> bothers watching gcc run assembler commands, so I > > guess it is > >> just quite gray.> > Jay, cm3 needs to behave the same on all > >> platforms. By default> commands should _not_ be echoed to stdout > >> or stderr; that's what the> -commands switch is for: this gives > >> you exactly the commands the> compiler issues to invoke other > >> tools.> > For more verbose output, you may also depend on the > >> -verbose or the> -debug switches.> > Please adapt the > >> configuration files that bey default all echoing> of commands is > >> off.> > Olaf> > > I don't know how to run the Tinderbox either > >> yet, sorry.> > I tried.> >> > For adding tests, well, there is > >> m3-sys\m3tests.> > That is where a lot of the tests are, but not > >> all.> > I am not sure where tests belong. I added a small number > >> there.> > They are named with just a letter and a number.> > The > >> letters have some meaning, explained in the m3makefile.> > "p" is > >> programs that are run and their stdout/stderr compared > > against > >> expected> > "e" is programs build and the errors from the compiler > >> checked to be > > reasonable.> > I don't think in general they are > >> expected to successfully compile > > or run, though the case of > >> "warnings" may be unclear.> > "c" is programs built so a human can > >> look at the generated code.> > There is another case I think for > >> human checking.> > The numbers are just 001, 002, 003, etc.> > > >> Each hundred tests are in a separate directory, like p0\p001, > > > >> p0\p002, p1\p100, p1\101, etc.> >> > Something like this.> > > >> Wherever I have details wrong, just look in m3-sys\m3tests. It's > > >> > pretty simple, obvious, and well commented.> >> > The output is > >> a little clearer if you have a working diff.exe on the path.> > > >> Then what you do is search for "@@" in the output.> >> > - Jay> >> > >> >> > Date: Tue, 6 May 2008 03:46:27 +0200From: > >> dabenavidesd at yahoo.esTo: > > m3devel at elegosoft.comSubject: > >> [M3devel] www.opencm3.net/m3testsDear > > developers:Does the > >> recent tests on NT386 seem broken because a > > recent change on > >> the m3-sys tree, or is the HTML bad generated, I > > mean can you > >> check the last tests Sunday, May 4th (p001 to p042) has > > a red > >> background > > > >> http://www.opencm3.net/m3tests/m3tests-NT386-2008-04-23-13-30-57.html
p002 Text
Comparing files P0\P002\stdout.build and ..\SRC\P0\P002\STDOUT.BUILD***** P0\P002\stdout.buildlink @_m3responsefile0.txt 2>&1 > pgm.lstmt /nologo /manifest pgm.exe.manifest /outputresource:pgm.exe;1***** ..\SRC\P0\P002\STDOUT.BUILD*****Comparing files P0\P002\stderr.build and ..\SRC\P0\P002\STDERR.BUILDFC: no differences encounteredComparing files P0\P002\stdout.pgm and ..\SRC\P0\P002\STDOUT.PGMFC: no differences encounteredComparing files P0\P002\stderr.pgm and ..\SRC\P0\P002\STDERR.PGMFC: no differences encounteredand almost the same pattern in the above tests.I would suggest if it is thinkable using NT386 variant with a complete dedicated machine/system, I can try to set up one this week and send the data back (the machine is behind a proxy), but I don't remember the mail explaining the set up, and also want to know if there is a chance of run the tests with one run script.Also what is the best natural way to put a new tests, and the standard name it should > > have?Thanks> >> >> > Enviado desde Correo Yahoo!La bandeja de entrada m?s inteligente.> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > >> DE163214194>> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From hosking at cs.purdue.edu  Tue May  6 16:05:25 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 6 May 2008 10:05:25 -0400
Subject: [M3devel] www.opencm3.net/m3tests
In-Reply-To: 
References: <313767.59466.qm@web27115.mail.ukl.yahoo.com>
	
	<20080506100711.d2rzqie6ow08csgs@mail.elegosoft.com>
	
Message-ID: <48A1BCA0-B727-4777-A16C-BD0673AC4D28@cs.purdue.edu>

On May 6, 2008, at 6:57 AM, Jay wrote:

> Olaf, I don't entirely agree.
> The logs should be fairly informative without intervention.
> Just not too verbose. I'd would rather remove the lines that say  
> "compiling" and show the cm3cg invocations.
> But more than one line per source file is too much.
> -commands doesn't really work. Lots of bogus extra commands are  
> echoed (rm .tmp), and not all the commands that are run are echoed.

Not bogus - it does exactly what one would expect - showing all  
commands executed.   I'm  with  Olaf on this one.

> I understand that stability for tests is also a goal, but  
> information for the interactive user and for post mortem debugging  
> via a log is also valuable, and these are contrary to stability-for- 
> tests. Somehow contradictory goals need to be met.

I prefer terse output for tests  that complete normally.  On detailed   
investigation l can always turn on a verbose flag.

> How about a compromise?
> How about we always log more stuff to TARGET/cm3.log?
>  And then exactly what you want to stdout/stderr?
> While, as I said, more than one line per file is overkill, as part  
> of this compromise I'd be willing to include the cm3cg and as  
> invocation.
>
> Have folks used build.exe in the Windows NT DDK?
> It's model is close to what you get here.
> It has three sets of information:
>   to the console/stdout
>   build.log, build.exe is a wrapper over make, and this includes all  
> the make output -- all the command lines run
>   build.err, a small subset of console/stdout output
>
> My "design" here has been to avoid over-verbosity. Link and mt run  
> on the order of once, or a small number of times, per directory, so  
> showing the full command line (response files...) isn't so verbose  
> -- vs. say something shown once per compiled file.
>
> There's another "problem" here that I have partly fixed.
> Underlying errors are not shown on console/stdout/stderr.
> They are often in like TARGET/m3core.lst.
>
> I changed stuff to refer to that file, after having hunted the  
> errors down myself slowly the first time.
>
> We could change things to alway says "see TARGET/cm3.log" for more  
> information, or somesuch.
>
>  - Jay
>
>
>
> > Date: Tue, 6 May 2008 10:07:11 +0200
> > From: wagner at elegosoft.com
> > To: m3devel at elegosoft.com
> > Subject: Re: [M3devel] www.opencm3.net/m3tests
> >
> > Quoting Jay :
> >
> > > The "problem" here, a really really small one, is just that the  
> link
> > > and mt commands got echoed.
> > > Olaf made them not echoed. I then made them conditionally echoed.
> > > I made m3-sys\m3tests define M3TESTS so that NT386.common  
> doesn't echo.
> > > It's not a big deal either way.
> > > Aha -- tests in other directories would have a problem, and I  
> think
> > > there are some.
> > >
> > > I like more echoing usually, so the system explains what is  
> going on,
> > > instead of the vaguer "linking foo" sort of message.
> > > Granted, nobody bothers watching gcc run assembler commands, so I
> > > guess it is just quite gray.
> >
> > Jay, cm3 needs to behave the same on all platforms. By default
> > commands should _not_ be echoed to stdout or stderr; that's what the
> > -commands switch is for: this gives you exactly the commands the
> > compiler issues to invoke other tools.
> >
> > For more verbose output, you may also depend on the -verbose or the
> > -debug switches.
> >
> > Please adapt the configuration files that bey default all echoing
> > of commands is off.
> >
> > Olaf
> >
> > > I don't know how to run the Tinderbox either yet, sorry.
> > > I tried.
> > >
> > > For adding tests, well, there is m3-sys\m3tests.
> > > That is where a lot of the tests are, but not all.
> > > I am not sure where tests belong. I added a small number there.
> > > They are named with just a letter and a number.
> > > The letters have some meaning, explained in the m3makefile.
> > > "p" is programs that are run and their stdout/stderr compared
> > > against expected
> > > "e" is programs build and the errors from the compiler checked  
> to be
> > > reasonable.
> > > I don't think in general they are expected to successfully compile
> > > or run, though the case of "warnings" may be unclear.
> > > "c" is programs built so a human can look at the generated code.
> > > There is another case I think for human checking.
> > > The numbers are just 001, 002, 003, etc.
> > > Each hundred tests are in a separate directory, like p0\p001,
> > > p0\p002, p1\p100, p1\101, etc.
> > >
> > > Something like this.
> > > Wherever I have details wrong, just look in m3-sys\m3tests. It's
> > > pretty simple, obvious, and well commented.
> > >
> > > The output is a little clearer if you have a working diff.exe on  
> the path.
> > > Then what you do is search for "@@" in the output.
> > >
> > > - Jay
> > >
> > >
> > > Date: Tue, 6 May 2008 03:46:27 +0200From: dabenavidesd at yahoo.esTo:
> > > m3devel at elegosoft.comSubject: [M3devel] www.opencm3.net/ 
> m3testsDear
> > > developers:Does the recent tests on NT386 seem broken because a
> > > recent change on the m3-sys tree, or is the HTML bad generated, I
> > > mean can you check the last tests Sunday, May 4th (p001 to p042)  
> has
> > > a red background
> > > http://www.opencm3.net/m3tests/m3tests-NT386-2008-04-23-13-30-57.html 
>
p002 class="small" width="45%"> Text
Comparing  
> files P0\P002\stdout.build and ..\SRC\P0\P002\STDOUT.BUILD*****  
> P0\P002\stdout.buildlink @_m3responsefile0.txt 2>&1 > pgm.lstmt / 
> nologo /manifest pgm.exe.manifest /outputresource:pgm.exe;1***** .. 
> \SRC\P0\P002\STDOUT.BUILD*****Comparing files P0\P002\stderr.build  
> and ..\SRC\P0\P002\STDERR.BUILDFC: no differences  
> encounteredComparing files P0\P002\stdout.pgm and ..\SRC 
> \P0\P002\STDOUT.PGMFC: no differences encounteredComparing files  
> P0\P002\stderr.pgm and ..\SRC\P0\P002\STDERR.PGMFC: no differences  
> encounteredand almost the same pattern in the above tests.I would  
> suggest if it is thinkable using NT386 variant with a complete  
> dedicated machine/system, I can try to set up one this week and send  
> the data back (the machine is behind a proxy), but I don't remember  
> the mail explaining the set up, and also want to know if there is a  
> chance of run the tests with one run script.Also what is the best  
> natural way to put a new tests, and the standard name it should
> > > have?Thanks
> > >
> > >
> > > Enviado desde Correo Yahoo!La bandeja de entrada m?s inteligente.
> >
> >
> >
> > --
> > 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 hosking at cs.purdue.edu  Tue May  6 16:06:57 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 6 May 2008 10:06:57 -0400
Subject: [M3devel] cm3 command line interface and output;
	was: RE: 	www.opencm3.net/m3tests
In-Reply-To: <20080506153318.a50ttk23488ksk00@mail.elegosoft.com>
References: <313767.59466.qm@web27115.mail.ukl.yahoo.com>
	
	<20080506100711.d2rzqie6ow08csgs@mail.elegosoft.com>
	
	
	<20080506153318.a50ttk23488ksk00@mail.elegosoft.com>
Message-ID: <2D3BBD73-E273-4E9B-AC2D-DCF9A2CCBCAB@cs.purdue.edu>

I'm am strongly with Jay on this one.

On May 6, 2008, at 9:33 AM, Olaf Wagner wrote:

> Quoting Jay :
>
>> When I say show cm3cg/as invocations, I mean in this new TARGET/ 
>> cm3.log.
>> As I said, I propose exactly the stdout/stderr you want, but then   
>> some other output always, a log file.
>> Also, about -commands, I have also claimed that it does work --   
>> talking out of both sides of my mouth. The extra commands it  
>> prints  are obviously harmless. I forget what doesn't print, maybe  
>> exec vs.  q_exec? Also the '@' character wasn't working with  
>> q_exec, but that  isn't necessarily relevant here..I forgot where I  
>> use exec vs.  q_exec..
>> And there plenty of other ways to debug than -commands and it is   
>> "just" a debugging facility..
>
> I've got a rather definite opinion about the output behaviour of
> cm3. It's like this, and I would like others to comment, too:
>
> o cm3 without any switches (-commands, -debug, -verbose) should
>   not output any called commands, neither to stdout nor stderr.
>   It may print what it is doing in an abstract, target independent
>   (short) way. This output may refer to compilation units, interfaces,
>   modules, and compilation phases, but not to target specific commands
>   and files (unless there are errors, of course) Even then I'd like
>   to abstract from differences.
>
> o cm3 -silent should suppress the normal output, except for warnings
>   and error messages.
>
> o cm3 -commands should output exactly all invokations of externals
>   commands so that they can be re-executed from the command line
>   if necessary.
>
> I realize that it might not be this way in every aspect, so that
> we may need to adapt the code here and there. But in my experience
> it has worked this way quite well. Here are some points to consider:
>
> o We need consistent behaviour and output across all target platforms.
>   This is not just a requirement of regression testing, but also of
>   a consistent user interface. I don't want different behaviour on
>   different platforms.
>
> o If -commands does not work as expected for some use case,
>   we need to fix it.
>
> o If q_exec or whatever quake function is still deficient in this
>   respect, we need to fix/adapt it. It should not be much effort.
>
> o I find the options -commands, -verbose, -debug, -silent a very
>   good categorization of information types, intuitively understandable
>   and usable in practive (as I've never had any problems with it, but
>   have used them efficiently for years). So I don't see the point
>   in changing anything, unless there is a better concept.
>
> o I don't think it is a good idea to write any log files by default
>   (apart from the stdout and stderr streams).
>
> This is of course just my opinion, but unless there are others in
> favour of changes (and I'd like some motivation for them) I'd insist
> that we keep the existing design.
>
> Olaf
>
>> From: jayk123 at hotmail.comTo: wagner at elegosoft.com;  m3devel at elegosoft.comDate 
>> : Tue, 6 May 2008 10:57:01 +0000Subject:  Re: [M3devel] www.opencm3.net/m3tests
>>
>>
>> Olaf, I don't entirely agree.The logs should be fairly informative   
>> without intervention.Just not too verbose. I'd would rather remove   
>> the lines that say "compiling" and show the cm3cg invocations.But   
>> more than one line per source file is too much.-commands doesn't   
>> really work. Lots of bogus extra commands are echoed (rm .tmp),  
>> and  not all the commands that are run are echoed. I understand  
>> that  stability for tests is also a goal, but information for the   
>> interactive user and for post mortem debugging via a log is also   
>> valuable, and these are contrary to stability-for-tests. Somehow   
>> contradictory goals need to be met. How about a compromise?How  
>> about  we always log more stuff to TARGET/cm3.log? And then exactly  
>> what  you want to stdout/stderr?While, as I said, more than one  
>> line per  file is overkill, as part of this compromise I'd be  
>> willing to  include the cm3cg and as invocation. Have folks used  
>> build.exe in  the Windows NT DDK?It's model is close to what you  
>> get here.It has  three sets of information:  to the console/ 
>> stdout   build.log,  build.exe is a wrapper over make, and this  
>> includes all the make  output -- all the command lines run    
>> build.err, a small subset of  console/stdout output My "design"  
>> here has been to avoid  over-verbosity. Link and mt run on the  
>> order of once, or a small  number of times, per directory, so  
>> showing the full command line  (response files...) isn't so verbose  
>> -- vs. say something shown once  per compiled file. There's another  
>> "problem" here that I have partly  fixed.Underlying errors are not  
>> shown on console/stdout/stderr.They  are often in like TARGET/ 
>> m3core.lst. I changed stuff to refer to  that file, after having  
>> hunted the errors down myself slowly the  first time. We could  
>> change things to alway says "see  TARGET/cm3.log" for more  
>> information, or somesuch.  - Jay
>>
>>> Date: Tue, 6 May 2008 10:07:11 +0200> From: wagner at elegosoft.com>   
>>> To: m3devel at elegosoft.com> Subject: Re: [M3devel]  www.opencm3.net/m3tests 
>>> > > Quoting Jay :> > >  The "problem" here, a  
>>> really really small one, is just that the  link > > and mt  
>>> commands got echoed.> > Olaf made them not echoed.  I then made  
>>> them conditionally echoed.> > I made m3-sys\m3tests  define  
>>> M3TESTS so that NT386.common doesn't echo.> > It's not a big  deal  
>>> either way.> > Aha -- tests in other directories would have a   
>>> problem, and I think > > there are some.> >> > I like more  
>>> echoing  usually, so the system explains what is going on,> >  
>>> instead of the  vaguer "linking foo" sort of message.> > Granted,  
>>> nobody bothers  watching gcc run assembler commands, so I > >  
>>> guess it is just  quite gray.> > Jay, cm3 needs to behave the same  
>>> on all platforms.  By default> commands should _not_ be echoed to  
>>> stdout or stderr;  that's what the> -commands switch is for: this  
>>> gives you exactly  the commands the> compiler issues to invoke  
>>> other tools.> > For  more verbose output, you may also depend on  
>>> the -verbose or the>  -debug switches.> > Please adapt the  
>>> configuration files that bey  default all echoing> of commands is  
>>> off.> > Olaf> > > I don't know  how to run the Tinderbox either  
>>> yet, sorry.> > I tried.> >> > For  adding tests, well, there is m3- 
>>> sys\m3tests.> > That is where a lot  of the tests are, but not  
>>> all.> > I am not sure where tests belong.  I added a small number  
>>> there.> > They are named with just a letter  and a number.> > The  
>>> letters have some meaning, explained in the  m3makefile.> > "p" is  
>>> programs that are run and their stdout/stderr  compared > >  
>>> against expected> > "e" is programs build and the  errors from the  
>>> compiler checked to be > > reasonable.> > I don't  think in  
>>> general they are expected to successfully compile > > or  run,  
>>> though the case of "warnings" may be unclear.> > "c" is  programs  
>>> built so a human can look at the generated code.> > There  is  
>>> another case I think for human checking.> > The numbers are just   
>>> 001, 002, 003, etc.> > Each hundred tests are in a separate   
>>> directory, like p0\p001, > > p0\p002, p1\p100, p1\101, etc.> >> >   
>>> Something like this.> > Wherever I have details wrong, just look  
>>> in  m3-sys\m3tests. It's > > pretty simple, obvious, and well   
>>> commented.> >> > The output is a little clearer if you have a   
>>> working diff.exe on the path.> > Then what you do is search for   
>>> "@@" in the output.> >> > - Jay> >> >> > Date: Tue, 6 May 2008   
>>> 03:46:27 +0200From: dabenavidesd at yahoo.esTo: > >  m3devel at elegosoft.comSubject 
>>> : [M3devel] www.opencm3.net/m3testsDear  > > developers:Does the  
>>> recent tests on NT386 seem broken because a  > > recent change on  
>>> the m3-sys tree, or is the HTML bad generated,  I > > mean can you  
>>> check the last tests Sunday, May 4th (p001 to  p042) has > > a red  
>>> background > >  http://www.opencm3.net/m3tests/m3tests-NT386-2008-04-23-13-30-57.html 
>>>
p002 >> class="small" width="45%"> Text>> class="small">
Comparing files P0\P002\stdout.build and ..\SRC 
>>> \P0\P002\STDOUT.BUILD***** P0\P002\stdout.buildlink  
>>> @_m3responsefile0.txt 2>&1 > pgm.lstmt /nologo /manifest  
>>> pgm.exe.manifest /outputresource:pgm.exe;1***** ..\SRC 
>>> \P0\P002\STDOUT.BUILD*****Comparing files P0\P002\stderr.build  
>>> and ..\SRC\P0\P002\STDERR.BUILDFC: no differences  
>>> encounteredComparing files P0\P002\stdout.pgm and ..\SRC 
>>> \P0\P002\STDOUT.PGMFC: no differences encounteredComparing files  
>>> P0\P002\stderr.pgm and ..\SRC\P0\P002\STDERR.PGMFC: no differences  
>>> encounteredand almost the same pattern in the above tests.I would  
>>> suggest if it is thinkable using NT386 variant with a complete  
>>> dedicated machine/system, I can try to set up one this week and  
>>> send the data back (the machine is behind a proxy), but I don't  
>>> remember the mail explaining the set up, and also want to know if  
>>> there is a chance of run the tests with one run script.Also what  
>>> is the best natural way to put a new tests, and the standard name  
>>> it should > > have?Thanks> >> >> > Enviado desde Correo Yahoo!La  
>>> bandeja de entrada m?s inteligente.> > > > -- > Olaf Wagner --  
>>> elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12,  
>>> 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177  
>>> 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com |  
>>> Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister:  
>>> Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:  DE163214194>
>
>
>
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin,  
> Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23  
> 45 86 95
>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz:  
> Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:  
> DE163214194
>



From hosking at cs.purdue.edu  Tue May  6 16:07:56 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 6 May 2008 10:07:56 -0400
Subject: [M3devel] cm3 command line interface and output;
	was: RE: 	www.opencm3.net/m3tests
In-Reply-To: <2D3BBD73-E273-4E9B-AC2D-DCF9A2CCBCAB@cs.purdue.edu>
References: <313767.59466.qm@web27115.mail.ukl.yahoo.com>
	
	<20080506100711.d2rzqie6ow08csgs@mail.elegosoft.com>
	
	
	<20080506153318.a50ttk23488ksk00@mail.elegosoft.com>
	<2D3BBD73-E273-4E9B-AC2D-DCF9A2CCBCAB@cs.purdue.edu>
Message-ID: <5F69E624-4EFD-43D6-A852-6938AE62C9BC@cs.purdue.edu>

Oops I meant *Olaf* !

On May 6, 2008, at 10:06 AM, Tony Hosking wrote:

> I'm am strongly with Jay on this one.
>
> On May 6, 2008, at 9:33 AM, Olaf Wagner wrote:
>
>> Quoting Jay :
>>
>>> When I say show cm3cg/as invocations, I mean in this new TARGET/ 
>>> cm3.log.
>>> As I said, I propose exactly the stdout/stderr you want, but then   
>>> some other output always, a log file.
>>> Also, about -commands, I have also claimed that it does work --   
>>> talking out of both sides of my mouth. The extra commands it  
>>> prints  are obviously harmless. I forget what doesn't print, maybe  
>>> exec vs.  q_exec? Also the '@' character wasn't working with  
>>> q_exec, but that  isn't necessarily relevant here..I forgot where  
>>> I use exec vs.  q_exec..
>>> And there plenty of other ways to debug than -commands and it is   
>>> "just" a debugging facility..
>>
>> I've got a rather definite opinion about the output behaviour of
>> cm3. It's like this, and I would like others to comment, too:
>>
>> o cm3 without any switches (-commands, -debug, -verbose) should
>>  not output any called commands, neither to stdout nor stderr.
>>  It may print what it is doing in an abstract, target independent
>>  (short) way. This output may refer to compilation units, interfaces,
>>  modules, and compilation phases, but not to target specific commands
>>  and files (unless there are errors, of course) Even then I'd like
>>  to abstract from differences.
>>
>> o cm3 -silent should suppress the normal output, except for warnings
>>  and error messages.
>>
>> o cm3 -commands should output exactly all invokations of externals
>>  commands so that they can be re-executed from the command line
>>  if necessary.
>>
>> I realize that it might not be this way in every aspect, so that
>> we may need to adapt the code here and there. But in my experience
>> it has worked this way quite well. Here are some points to consider:
>>
>> o We need consistent behaviour and output across all target  
>> platforms.
>>  This is not just a requirement of regression testing, but also of
>>  a consistent user interface. I don't want different behaviour on
>>  different platforms.
>>
>> o If -commands does not work as expected for some use case,
>>  we need to fix it.
>>
>> o If q_exec or whatever quake function is still deficient in this
>>  respect, we need to fix/adapt it. It should not be much effort.
>>
>> o I find the options -commands, -verbose, -debug, -silent a very
>>  good categorization of information types, intuitively understandable
>>  and usable in practive (as I've never had any problems with it, but
>>  have used them efficiently for years). So I don't see the point
>>  in changing anything, unless there is a better concept.
>>
>> o I don't think it is a good idea to write any log files by default
>>  (apart from the stdout and stderr streams).
>>
>> This is of course just my opinion, but unless there are others in
>> favour of changes (and I'd like some motivation for them) I'd insist
>> that we keep the existing design.
>>
>> Olaf
>>
>>> From: jayk123 at hotmail.comTo: wagner at elegosoft.com;  m3devel at elegosoft.comDate 
>>> : Tue, 6 May 2008 10:57:01 +0000Subject:  Re: [M3devel] www.opencm3.net/m3tests
>>>
>>>
>>> Olaf, I don't entirely agree.The logs should be fairly  
>>> informative  without intervention.Just not too verbose. I'd would  
>>> rather remove  the lines that say "compiling" and show the cm3cg  
>>> invocations.But  more than one line per source file is too much.- 
>>> commands doesn't  really work. Lots of bogus extra commands are  
>>> echoed (rm .tmp), and  not all the commands that are run are  
>>> echoed. I understand that  stability for tests is also a goal, but  
>>> information for the  interactive user and for post mortem  
>>> debugging via a log is also  valuable, and these are contrary to  
>>> stability-for-tests. Somehow  contradictory goals need to be met.  
>>> How about a compromise?How about  we always log more stuff to  
>>> TARGET/cm3.log? And then exactly what  you want to stdout/stderr? 
>>> While, as I said, more than one line per  file is overkill, as  
>>> part of this compromise I'd be willing to  include the cm3cg and  
>>> as invocation. Have folks used build.exe in  the Windows NT DDK? 
>>> It's model is close to what you get here.It has  three sets of  
>>> information:  to the console/stdout   build.log,  build.exe is a  
>>> wrapper over make, and this includes all the make  output -- all  
>>> the command lines run   build.err, a small subset of  console/ 
>>> stdout output My "design" here has been to avoid  over-verbosity.  
>>> Link and mt run on the order of once, or a small  number of times,  
>>> per directory, so showing the full command line  (response  
>>> files...) isn't so verbose -- vs. say something shown once  per  
>>> compiled file. There's another "problem" here that I have partly   
>>> fixed.Underlying errors are not shown on console/stdout/ 
>>> stderr.They  are often in like TARGET/m3core.lst. I changed stuff  
>>> to refer to  that file, after having hunted the errors down myself  
>>> slowly the  first time. We could change things to alway says "see   
>>> TARGET/cm3.log" for more information, or somesuch.  - Jay
>>>
>>>> Date: Tue, 6 May 2008 10:07:11 +0200> From:  
>>>> wagner at elegosoft.com>  To: m3devel at elegosoft.com> Subject: Re:  
>>>> [M3devel]  www.opencm3.net/m3tests> > Quoting Jay >>> >:> > >  The "problem" here, a really really small one, is just  
>>>> that the  link > > and mt commands got echoed.> > Olaf made them  
>>>> not echoed.  I then made them conditionally echoed.> > I made m3- 
>>>> sys\m3tests  define M3TESTS so that NT386.common doesn't echo.> >  
>>>> It's not a big  deal either way.> > Aha -- tests in other  
>>>> directories would have a  problem, and I think > > there are  
>>>> some.> >> > I like more echoing  usually, so the system explains  
>>>> what is going on,> > instead of the  vaguer "linking foo" sort of  
>>>> message.> > Granted, nobody bothers  watching gcc run assembler  
>>>> commands, so I > > guess it is just  quite gray.> > Jay, cm3  
>>>> needs to behave the same on all platforms.  By default> commands  
>>>> should _not_ be echoed to stdout or stderr;  that's what the> - 
>>>> commands switch is for: this gives you exactly  the commands the>  
>>>> compiler issues to invoke other tools.> > For  more verbose  
>>>> output, you may also depend on the -verbose or the>  -debug  
>>>> switches.> > Please adapt the configuration files that bey   
>>>> default all echoing> of commands is off.> > Olaf> > > I don't  
>>>> know  how to run the Tinderbox either yet, sorry.> > I tried.> >>  
>>>> > For  adding tests, well, there is m3-sys\m3tests.> > That is  
>>>> where a lot  of the tests are, but not all.> > I am not sure  
>>>> where tests belong.  I added a small number there.> > They are  
>>>> named with just a letter  and a number.> > The letters have some  
>>>> meaning, explained in the  m3makefile.> > "p" is programs that  
>>>> are run and their stdout/stderr  compared > > against expected> >  
>>>> "e" is programs build and the  errors from the compiler checked  
>>>> to be > > reasonable.> > I don't  think in general they are  
>>>> expected to successfully compile > > or  run, though the case of  
>>>> "warnings" may be unclear.> > "c" is  programs built so a human  
>>>> can look at the generated code.> > There  is another case I think  
>>>> for human checking.> > The numbers are just  001, 002, 003, etc.>  
>>>> > Each hundred tests are in a separate  directory, like p0\p001,  
>>>> > > p0\p002, p1\p100, p1\101, etc.> >> >  Something like this.> >  
>>>> Wherever I have details wrong, just look in  m3-sys\m3tests. It's  
>>>> > > pretty simple, obvious, and well  commented.> >> > The output  
>>>> is a little clearer if you have a  working diff.exe on the path.>  
>>>> > Then what you do is search for  "@@" in the output.> >> > -  
>>>> Jay> >> >> > Date: Tue, 6 May 2008  03:46:27 +0200From: dabenavidesd at yahoo.esTo 
>>>> : > >  m3devel at elegosoft.comSubject: [M3devel] www.opencm3.net/m3testsDear 
>>>>   > > developers:Does the recent tests on NT386 seem broken  
>>>> because a  > > recent change on the m3-sys tree, or is the HTML  
>>>> bad generated,  I > > mean can you check the last tests Sunday,  
>>>> May 4th (p001 to  p042) has > > a red background > >  http://www.opencm3.net/m3tests/m3tests-NT386-2008-04-23-13-30-57.html 
>>>>
p002 >>> class="small" width="45%"> Text>>> class="small">
Comparing files P0\P002\stdout.build and ..\SRC 
>>>> \P0\P002\STDOUT.BUILD***** P0\P002\stdout.buildlink  
>>>> @_m3responsefile0.txt 2>&1 > pgm.lstmt /nologo /manifest  
>>>> pgm.exe.manifest /outputresource:pgm.exe;1***** ..\SRC 
>>>> \P0\P002\STDOUT.BUILD*****Comparing files P0\P002\stderr.build  
>>>> and ..\SRC\P0\P002\STDERR.BUILDFC: no differences  
>>>> encounteredComparing files P0\P002\stdout.pgm and ..\SRC 
>>>> \P0\P002\STDOUT.PGMFC: no differences encounteredComparing files  
>>>> P0\P002\stderr.pgm and ..\SRC\P0\P002\STDERR.PGMFC: no  
>>>> differences encounteredand almost the same pattern in the above  
>>>> tests.I would suggest if it is thinkable using NT386 variant with  
>>>> a complete dedicated machine/system, I can try to set up one this  
>>>> week and send the data back (the machine is behind a proxy), but  
>>>> I don't remember the mail explaining the set up, and also want to  
>>>> know if there is a chance of run the tests with one run  
>>>> script.Also what is the best natural way to put a new tests, and  
>>>> the standard name it should > > have?Thanks> >> >> > Enviado  
>>>> desde Correo Yahoo!La bandeja de entrada m?s inteligente.> > > >  
>>>> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer- 
>>>> Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45  
>>>> 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com 
>>>>  | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister:  
>>>> Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:  DE163214194>
>>
>>
>>
>> -- 
>> Olaf Wagner -- elego Software Solutions GmbH
>>              Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin,  
>> Germany
>> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23  
>> 45 86 95
>>  http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz:  
>> Berlin
>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:  
>> DE163214194
>>
>



From jayk123 at hotmail.com  Tue May  6 16:16:35 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 6 May 2008 14:16:35 +0000
Subject: [M3devel] www.opencm3.net/m3tests
In-Reply-To: <48A1BCA0-B727-4777-A16C-BD0673AC4D28@cs.purdue.edu>
References: <313767.59466.qm@web27115.mail.ukl.yahoo.com>
	
	<20080506100711.d2rzqie6ow08csgs@mail.elegosoft.com>
	
	<48A1BCA0-B727-4777-A16C-BD0673AC4D28@cs.purdue.edu>
Message-ID: 

The bogus commands are actually a "simulation" of what the code is doing, I think.
It isn't so dumb as to run little rm commands here it and there. It deletes files without running anything and prints stuff that if run will approximate what it did. It is indeed worthwhile I think, though it isn't "-commands" per se.
That's my vague understanding not having read the code closely.
The "strange" thing is to see "rm" commands on NT386.
 
Planning for success is arguably wrong.
There will be errors. They need to be debugged.
You can't always rerun the scenario.
 
I think a log file with a little more information is a reasonable compromise.
 
Even that is gray. For example, the log file should not contain the output of -trace.
That's just too low level, too voluminous, and fails too rarely to be interesting.
 
Echoing command lines always into a log seems good on the assumption that command lines are expensive, so the i/o to put them in a log should be ok. This isn't entirely true, what with stuff like mkdir and rm.
On the assumption that command lines are running "big" things that "often" fail.
Again this is mixed. Most systems that show command lines still hide many.
ie: invocations of gcc are often shown, but invocations of cc1 and as not so much.
 
Personally I debug a lot of stuff and I err in favor of debuggability, be it live or post-mortem.
Debugging is hard enough, I don't like the obvious easy powers taken away from me.
I know logging and printf is incredibly crude vs. stepping through code in a debugger, but I also had it be fantastically successful and fast too many times to discount. Esp. in data-intensive code where the same code runs successfully many times before the problem occurs.
 
I will grant that in my Modula-3 use, debugging has mostly been easy enough, the repro cases available enough, that optimizing for post-mortem debugging of one and only one instance of a problem is probably overkill.
But still, a log file seems reasonable..
(The debugging has actually been not easy, quite difficult at times, the NT386GNU X windows problem, the double aligment, the stat overflow...but the repro cases and ability to peel the onion in run after run after run has been good; like cm3cg -y for example..and the logging we are talking about only helps in the easiest of cases...)
 
 - Jay


CC: wagner at elegosoft.com; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] www.opencm3.net/m3testsDate: Tue, 6 May 2008 10:05:25 -0400

On May 6, 2008, at 6:57 AM, Jay wrote:


Olaf, I don't entirely agree.The logs should be fairly informative without intervention.Just not too verbose. I'd would rather remove the lines that say "compiling" and show the cm3cg invocations.But more than one line per source file is too much.-commands doesn't really work. Lots of bogus extra commands are echoed (rm .tmp), and not all the commands that are run are echoed.

Not bogus - it does exactly what one would expect - showing all commands executed.   I'm  with  Olaf on this one.


I understand that stability for tests is also a goal, but information for the interactive user and for post mortem debugging via a log is also valuable, and these are contrary to stability-for-tests. Somehow contradictory goals need to be met.

I prefer terse output for tests  that complete normally.  On detailed  investigation l can always turn on a verbose flag.

How about a compromise?How about we always log more stuff to TARGET/cm3.log? And then exactly what you want to stdout/stderr?While, as I said, more than one line per file is overkill, as part of this compromise I'd be willing to include the cm3cg and as invocation. Have folks used build.exe in the Windows NT DDK?It's model is close to what you get here.It has three sets of information:  to the console/stdout   build.log, build.exe is a wrapper over make, and this includes all the make output -- all the command lines run   build.err, a small subset of console/stdout output My "design" here has been to avoid over-verbosity. Link and mt run on the order of once, or a small number of times, per directory, so showing the full command line (response files...) isn't so verbose -- vs. say something shown once per compiled file. There's another "problem" here that I have partly fixed.Underlying errors are not shown on console/stdout/stderr.They are often in like TARGET/m3core.lst. I changed stuff to refer to that file, after having hunted the errors down myself slowly the first time. We could change things to alway says "see TARGET/cm3.log" for more information, or somesuch.  - Jay

> Date: Tue, 6 May 2008 10:07:11 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] www.opencm3.net/m3tests> > Quoting Jay :> > > The "problem" here, a really really small one, is just that the link > > and mt commands got echoed.> > Olaf made them not echoed. I then made them conditionally echoed.> > I made m3-sys\m3tests define M3TESTS so that NT386.common doesn't echo.> > It's not a big deal either way.> > Aha -- tests in other directories would have a problem, and I think > > there are some.> >> > I like more echoing usually, so the system explains what is going on,> > instead of the vaguer "linking foo" sort of message.> > Granted, nobody bothers watching gcc run assembler commands, so I > > guess it is just quite gray.> > Jay, cm3 needs to behave the same on all platforms. By default> commands should _not_ be echoed to stdout or stderr; that's what the> -commands switch is for: this gives you exactly the commands the> compiler issues to invoke other tools.> > For more verbose output, you may also depend on the -verbose or the> -debug switches.> > Please adapt the configuration files that bey default all echoing> of commands is off.> > Olaf> > > I don't know how to run the Tinderbox either yet, sorry.> > I tried.> >> > For adding tests, well, there is m3-sys\m3tests.> > That is where a lot of the tests are, but not all.> > I am not sure where tests belong. I added a small number there.> > They are named with just a letter and a number.> > The letters have some meaning, explained in the m3makefile.> > "p" is programs that are run and their stdout/stderr compared > > against expected> > "e" is programs build and the errors from the compiler checked to be > > reasonable.> > I don't think in general they are expected to successfully compile > > or run, though the case of "warnings" may be unclear.> > "c" is programs built so a human can look at the generated code.> > There is another case I think for human checking.> > The numbers are just 001, 002, 003, etc.> > Each hundred tests are in a separate directory, like p0\p001, > > p0\p002, p1\p100, p1\101, etc.> >> > Something like this.> > Wherever I have details wrong, just look in m3-sys\m3tests. It's > > pretty simple, obvious, and well commented.> >> > The output is a little clearer if you have a working diff.exe on the path.> > Then what you do is search for "@@" in the output.> >> > - Jay> >> >> > Date: Tue, 6 May 2008 03:46:27 +0200From: dabenavidesd at yahoo.esTo: > > m3devel at elegosoft.comSubject: [M3devel] www.opencm3.net/m3testsDear > > developers:Does the recent tests on NT386 seem broken because a > > recent change on the m3-sys tree, or is the HTML bad generated, I > > mean can you check the last tests Sunday, May 4th (p001 to p042) has > > a red background > > http://www.opencm3.net/m3tests/m3tests-NT386-2008-04-23-13-30-57.html
p002 Text
Comparing files P0\P002\stdout.build and ..\SRC\P0\P002\STDOUT.BUILD***** P0\P002\stdout.buildlink @_m3responsefile0.txt 2>&1 > pgm.lstmt /nologo /manifest pgm.exe.manifest /outputresource:pgm.exe;1***** ..\SRC\P0\P002\STDOUT.BUILD*****Comparing files P0\P002\stderr.build and ..\SRC\P0\P002\STDERR.BUILDFC: no differences encounteredComparing files P0\P002\stdout.pgm and ..\SRC\P0\P002\STDOUT.PGMFC: no differences encounteredComparing files P0\P002\stderr.pgm and ..\SRC\P0\P002\STDERR.PGMFC: no differences encounteredand almost the same pattern in the above tests.I would suggest if it is thinkable using NT386 variant with a complete dedicated machine/system, I can try to set up one this week and send the data back (the machine is behind a proxy), but I don't remember the mail explaining the set up, and also want to know if there is a chance of run the tests with one run script.Also what is the best natural way to put a new tests, and the standard name it should > > have?Thanks> >> >> > Enviado desde Correo Yahoo!La bandeja de entrada m?s inteligente.> > > > -- > 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  Tue May  6 23:07:36 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 06 May 2008 23:07:36 +0200
Subject: [M3devel] m3cc build fails on older MacOS X
In-Reply-To: 
References: <20080506075754.o24j7xhx4wgokwwo@mail.elegosoft.com>
	
	<20080506130247.50uj68o11twcgkog@mail.elegosoft.com>
	
Message-ID: <20080506230736.n106yopfkwooo4s0@mail.elegosoft.com>

Quoting Jay :

> Olaf, can you try without my m3makefile wierdness, that works elsewhere?
>
>   cd %CVSROOT%/m3-sys/m3cc    mkdir obj1     cd obj1     
> ../gcc/configure --disable-bootstrap --enable-languages=c,cm3cg      
> make
>  I'm not sure of "cm3cg", it might be "m3cg".  And you can just omit  
>  that anyway, I doubt the error is m3 related.
> (Tony: I don't believe --srcdir is needed. configure figures it out;  
>  granted, maybe not trivially.)
> ?
>  I expect you will get the same error.  Which isn't the final   
> answer, just some relevant data.   And if I'm wrong, well, that   
> suggests some fix.

I got home later than expected. The build now stops at a different
step:

/Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/xgcc  
-B/Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/  
-B/usr/local/powerpc-apple-darwin7.9.0/bin/  
-B/usr/local/powerpc-apple-darwin7.9.0/lib/ -isystem  
/usr/local/powerpc-apple-darwin7.9.0/include -isystem  
/usr/local/powerpc-apple-darwin7.9.0/sys-include -O2  -O2 -g -g -O2    
-DIN_GCC    -W -Wall -Wwrite-strings -Wstrict-prototypes  
-Wmissing-prototypes -Wold-style-definition  -isystem ./include   
-Wa,-force_cpusubtype_ALL -pipe -mmacosx-version-min=10.4 -g  
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -dynamiclib  
-nodefaultlibs -install_name /usr/local/lib/libgcc_s`if test . = ppc64  
; then echo _. ; fi`.1.dylib -single_module -o ./libgcc_s.1.dylib.tmp  
-Wl,-exported_symbols_list,libgcc.map -compatibility_version 1  
-current_version 1.0 -O2 -g -g -O2 -B./ _muldi3_s.o _negdi2_s.o  
_lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o  
_clear_cache_s.o _enable_execute_stack_s.o _trampoline_s.o __main_s.o  
_absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o  
_subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o  
_ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o  
_ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o  
_popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o  
_powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o _muldc3_s.o  
_mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o  
_divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _fixunssfsi_s.o  
_fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o  
_fixtfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o  
_fixunstfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o  
_floatditf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o  
_floatunditf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o  
_udiv_w_sdiv_s.o _udivmoddi4_s.o darwin-tramp_s.o ppc64-fp_s.o  
darwin-64_s.o darwin-ldouble_s.o darwin-world_s.o unwind-dw2_s.o  
unwind-dw2-fde-darwin_s.o unwind-sjlj_s.o unwind-c_s.o  
darwin-fallback_s.o emutls_s.o -lc
/usr/bin/ld: unknown flag: -macosx_version_min
collect2: ld returned 1 exit status
make[2]: *** [libgcc_s.dylib] Error 1
make[1]: *** [all-target-libgcc] Error 2
make: *** [all] Error 2

I'm too sleepy to investigate further now,

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



From jayk123 at hotmail.com  Tue May  6 23:18:14 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 6 May 2008 21:18:14 +0000
Subject: [M3devel] m3cc build fails on older MacOS X
In-Reply-To: <20080506230736.n106yopfkwooo4s0@mail.elegosoft.com>
References: <20080506075754.o24j7xhx4wgokwwo@mail.elegosoft.com>
	
	<20080506130247.50uj68o11twcgkog@mail.elegosoft.com>
	 
	<20080506230736.n106yopfkwooo4s0@mail.elegosoft.com>
Message-ID: 

Search the web...
http://projects.scipy.org/pipermail/scipy-user/2007-March/011372.html
 
"
I've got a Mac OSx 10.4.8 machine and am compilingscipy according to the instructions on the webpage.  I'vegot gcc 4.0.0 gfortran 4.3.0 fftw3.0 and svn versions of numpyand scipy.   My python is version 2.5.Building numpy goes smoothly, but when I try scipy I have an ld error....
 
I have gcc 4.0.1 and gfortran 4.3.0 installed on my system, and I do not seethis problem. Can you try upgrading to the latest version of Xcode (which shouldhave gcc 4.0.1)? It's not coming from Python but, I suspect, gfortran.
...
Indeed-- after an almost 1Gig download of XCode 2.4.1 to get gcc 4.0.1it compiled and runs. :)  The tests give me 4 failed, but these  already havebeen noted on the email list...."
1) Upgrade to 2.4.1/4.0.1
2) configure should sniff for this and remove it if not supported.
 
 - Jay



> Date: Tue, 6 May 2008 23:07:36 +0200> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: RE: [M3devel] m3cc build fails on older MacOS X> > Quoting Jay :> > > Olaf, can you try without my m3makefile wierdness, that works elsewhere?> >> > cd %CVSROOT%/m3-sys/m3cc mkdir obj1 cd obj1 > > ../gcc/configure --disable-bootstrap --enable-languages=c,cm3cg > > make> > I'm not sure of "cm3cg", it might be "m3cg". And you can just omit > > that anyway, I doubt the error is m3 related.> > (Tony: I don't believe --srcdir is needed. configure figures it out; > > granted, maybe not trivially.)> > ?> > I expect you will get the same error. Which isn't the final > > answer, just some relevant data. And if I'm wrong, well, that > > suggests some fix.> > I got home later than expected. The build now stops at a different> step:> > /Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/xgcc > -B/Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/ > -B/usr/local/powerpc-apple-darwin7.9.0/bin/ > -B/usr/local/powerpc-apple-darwin7.9.0/lib/ -isystem > /usr/local/powerpc-apple-darwin7.9.0/include -isystem > /usr/local/powerpc-apple-darwin7.9.0/sys-include -O2 -O2 -g -g -O2 > -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes > -Wmissing-prototypes -Wold-style-definition -isystem ./include > -Wa,-force_cpusubtype_ALL -pipe -mmacosx-version-min=10.4 -g > -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -dynamiclib > -nodefaultlibs -install_name /usr/local/lib/libgcc_s`if test . = ppc64 > ; then echo _. ; fi`.1.dylib -single_module -o ./libgcc_s.1.dylib.tmp > -Wl,-exported_symbols_list,libgcc.map -compatibility_version 1 > -current_version 1.0 -O2 -g -g -O2 -B./ _muldi3_s.o _negdi2_s.o > _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o > _clear_cache_s.o _enable_execute_stack_s.o _trampoline_s.o __main_s.o > _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o > _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o > _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o > _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o > _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o > _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o _muldc3_s.o > _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o > _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _fixunssfsi_s.o > _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o > _fixtfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o > _fixunstfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o > _floatditf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o > _floatunditf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o > _udiv_w_sdiv_s.o _udivmoddi4_s.o darwin-tramp_s.o ppc64-fp_s.o > darwin-64_s.o darwin-ldouble_s.o darwin-world_s.o unwind-dw2_s.o > unwind-dw2-fde-darwin_s.o unwind-sjlj_s.o unwind-c_s.o > darwin-fallback_s.o emutls_s.o -lc> /usr/bin/ld: unknown flag: -macosx_version_min> collect2: ld returned 1 exit status> make[2]: *** [libgcc_s.dylib] Error 1> make[1]: *** [all-target-libgcc] Error 2> make: *** [all] Error 2> > I'm too sleepy to investigate further now,> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From wagner at elegosoft.com  Wed May  7 07:58:30 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Wed, 07 May 2008 07:58:30 +0200
Subject: [M3devel] m3cc build fails on older MacOS X
In-Reply-To: 
References: <20080506075754.o24j7xhx4wgokwwo@mail.elegosoft.com>
	
	<20080506130247.50uj68o11twcgkog@mail.elegosoft.com>
	
Message-ID: <20080507075830.sbcaopz70kg000co@mail.elegosoft.com>

Quoting Jay :

> Olaf, can you try without my m3makefile wierdness, that works elsewhere?
>
>   cd %CVSROOT%/m3-sys/m3cc    mkdir obj1     cd obj1     
> ../gcc/configure --disable-bootstrap --enable-languages=c,cm3cg      
> make
>  I'm not sure of "cm3cg", it might be "m3cg".  And you can just omit  
>  that anyway, I doubt the error is m3 related.
> (Tony: I don't believe --srcdir is needed. configure figures it out;  
>  granted, maybe not trivially.)
> ?
>  I expect you will get the same error.  Which isn't the final   
> answer, just some relevant data.   And if I'm wrong, well, that   
> suggests some fix.

I already answered this late yesterday evening, but somehow the mail
seems to have got lost. The build now stops with a wrong linker
switch:

mv tmp-libgcc.map libgcc.map
# @multilib_flags@ is still needed because this may use
# /Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/xgcc  
-B/Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/  
-B/usr/local/powerpc-apple-darwin7.9.0/bin/  
-B/usr/local/powerpc-apple-darwin7.9.0/lib/ -isystem  
/usr/local/powerpc-apple-darwin7.9.0/include -isystem  
/usr/local/powerpc-apple-darwin7.9.0/sys-include and -O2  -O2 -g -g  
-O2   -DIN_GCC    -W -Wall -Wwrite-strings -Wstrict-prototypes  
-Wmissing-prototypes -Wold-style-definition  -isystem ./include   
-Wa,-force_cpusubtype_ALL -pipe -mmacosx-version-min=10.4 -g  
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  directly.
# @multilib_dir@ is not really necessary, but sometimes it has
# more uses than just a directory name.
/bin/sh ../../../gcc/libgcc/../mkinstalldirs .
/Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/xgcc  
-B/Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/  
-B/usr/local/powerpc-apple-darwin7.9.0/bin/  
-B/usr/local/powerpc-apple-darwin7.9.0/lib/ -isystem  
/usr/local/powerpc-apple-darwin7.9.0/include -isystem  
/usr/local/powerpc-apple-darwin7.9.0/sys-include -O2  -O2 -g -g -O2    
-DIN_GCC    -W -Wall -Wwrite-strings -Wstrict-prototypes  
-Wmissing-prototypes -Wold-style-definition  -isystem ./include   
-Wa,-force_cpusubtype_ALL -pipe -mmacosx-version-min=10.4 -g  
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -dynamiclib  
-nodefaultlibs -install_name /usr/local/lib/libgcc_s`if test . = ppc64  
; then echo _. ; fi`.1.dylib -single_module -o ./libgcc_s.1.dylib.tmp  
-Wl,-exported_symbols_list,libgcc.map -compatibility_version 1  
-current_version 1.0 -O2 -g -g -O2 -B./ _muldi3_s.o _negdi2_s.o  
_lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o  
_clear_cache_s.o _enable_execute_stack_s.o _trampoline_s.o __main_s.o  
_absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o  
_subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o  
_ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o  
_ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o  
_popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o  
_powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o _muldc3_s.o  
_mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o  
_divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _fixunssfsi_s.o  
_fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o  
_fixtfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o  
_fixunstfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o  
_floatditf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o  
_floatunditf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o  
_udiv_w_sdiv_s.o _udivmoddi4_s.o darwin-tramp_s.o ppc64-fp_s.o  
darwin-64_s.o darwin-ldouble_s.o darwin-world_s.o unwind-dw2_s.o  
unwind-dw2-fde-darwin_s.o unwind-sjlj_s.o unwind-c_s.o  
darwin-fallback_s.o emutls_s.o -lc
/usr/bin/ld: unknown flag: -macosx_version_min
collect2: ld returned 1 exit status
make[2]: *** [libgcc_s.dylib] Error 1
make[1]: *** [all-target-libgcc] Error 2
make: *** [all] Error 2

Probably nobody cares anymore for Mac OS X 10.3.9; I'll consider an
upgrade 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 jayk123 at hotmail.com  Wed May  7 08:15:24 2008
From: jayk123 at hotmail.com (Jay)
Date: Wed, 7 May 2008 06:15:24 +0000
Subject: [M3devel] m3cc build fails on older MacOS X
In-Reply-To: <20080507075830.sbcaopz70kg000co@mail.elegosoft.com>
References: <20080506075754.o24j7xhx4wgokwwo@mail.elegosoft.com>
	
	<20080506130247.50uj68o11twcgkog@mail.elegosoft.com>
	 
	<20080507075830.sbcaopz70kg000co@mail.elegosoft.com>
Message-ID: 

I "answered" this, sort of. The mail was truncated but the important point came through.
Someone else reported this circa gcc 4.0 and then fixed in gcc 4.0.1 or such.
 
 > Probably nobody cares anymore for Mac OS X 10.3.9; I'll consider an
I'll add bringing up 10.2 or maybe 10.1 back somewhere on my list..
This should probably handled "upstream" via "configure".
 
Olaf, is what changed my m3makefile-ness or not?
That is, it fails one way with cm3, but differently/later/better with "regular" configure+make?
Could be a flaw in my m3makefile shenanigans. But so far they otherwise work and do cut out unnecessary stuff.
 
I haven't had a chance to look into anything all Tuesday.
 
 - Jay



> Date: Wed, 7 May 2008 07:58:30 +0200> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: RE: [M3devel] m3cc build fails on older MacOS X> > Quoting Jay :> > > Olaf, can you try without my m3makefile wierdness, that works elsewhere?> >> > cd %CVSROOT%/m3-sys/m3cc mkdir obj1 cd obj1 > > ../gcc/configure --disable-bootstrap --enable-languages=c,cm3cg > > make> > I'm not sure of "cm3cg", it might be "m3cg". And you can just omit > > that anyway, I doubt the error is m3 related.> > (Tony: I don't believe --srcdir is needed. configure figures it out; > > granted, maybe not trivially.)> > ?> > I expect you will get the same error. Which isn't the final > > answer, just some relevant data. And if I'm wrong, well, that > > suggests some fix.> > I already answered this late yesterday evening, but somehow the mail> seems to have got lost. The build now stops with a wrong linker> switch:> > mv tmp-libgcc.map libgcc.map> # @multilib_flags@ is still needed because this may use> # /Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/xgcc > -B/Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/ > -B/usr/local/powerpc-apple-darwin7.9.0/bin/ > -B/usr/local/powerpc-apple-darwin7.9.0/lib/ -isystem > /usr/local/powerpc-apple-darwin7.9.0/include -isystem > /usr/local/powerpc-apple-darwin7.9.0/sys-include and -O2 -O2 -g -g > -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes > -Wmissing-prototypes -Wold-style-definition -isystem ./include > -Wa,-force_cpusubtype_ALL -pipe -mmacosx-version-min=10.4 -g > -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED directly.> # @multilib_dir@ is not really necessary, but sometimes it has> # more uses than just a directory name.> /bin/sh ../../../gcc/libgcc/../mkinstalldirs .> /Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/xgcc > -B/Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/ > -B/usr/local/powerpc-apple-darwin7.9.0/bin/ > -B/usr/local/powerpc-apple-darwin7.9.0/lib/ -isystem > /usr/local/powerpc-apple-darwin7.9.0/include -isystem > /usr/local/powerpc-apple-darwin7.9.0/sys-include -O2 -O2 -g -g -O2 > -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes > -Wmissing-prototypes -Wold-style-definition -isystem ./include > -Wa,-force_cpusubtype_ALL -pipe -mmacosx-version-min=10.4 -g > -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -dynamiclib > -nodefaultlibs -install_name /usr/local/lib/libgcc_s`if test . = ppc64 > ; then echo _. ; fi`.1.dylib -single_module -o ./libgcc_s.1.dylib.tmp > -Wl,-exported_symbols_list,libgcc.map -compatibility_version 1 > -current_version 1.0 -O2 -g -g -O2 -B./ _muldi3_s.o _negdi2_s.o > _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o > _clear_cache_s.o _enable_execute_stack_s.o _trampoline_s.o __main_s.o > _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o > _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o > _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o > _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o > _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o > _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o _muldc3_s.o > _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o > _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _fixunssfsi_s.o > _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o > _fixtfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o > _fixunstfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o > _floatditf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o > _floatunditf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o > _udiv_w_sdiv_s.o _udivmoddi4_s.o darwin-tramp_s.o ppc64-fp_s.o > darwin-64_s.o darwin-ldouble_s.o darwin-world_s.o unwind-dw2_s.o > unwind-dw2-fde-darwin_s.o unwind-sjlj_s.o unwind-c_s.o > darwin-fallback_s.o emutls_s.o -lc> /usr/bin/ld: unknown flag: -macosx_version_min> collect2: ld returned 1 exit status> make[2]: *** [libgcc_s.dylib] Error 1> make[1]: *** [all-target-libgcc] Error 2> make: *** [all] Error 2> > Probably nobody cares anymore for Mac OS X 10.3.9; I'll consider an> upgrade 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> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From wagner at elegosoft.com  Wed May  7 08:23:20 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Wed, 07 May 2008 08:23:20 +0200
Subject: [M3devel] m3cc build fails on older MacOS X
In-Reply-To: 
References: <20080506075754.o24j7xhx4wgokwwo@mail.elegosoft.com>
	
	<20080506130247.50uj68o11twcgkog@mail.elegosoft.com>
	
	<20080507075830.sbcaopz70kg000co@mail.elegosoft.com>
	
Message-ID: <20080507082320.iuho7zbpz4w8cw4g@mail.elegosoft.com>

Quoting Jay :

> I "answered" this, sort of. The mail was truncated but the important  
>  point came through.
> Someone else reported this circa gcc 4.0 and then fixed in gcc 4.0.1 or such.

I don't get you here. If there already is a fix or workaround, why
isn't it checked-in? Could you please point me to your corresponding
mail?

>  > Probably nobody cares anymore for Mac OS X 10.3.9; I'll consider an
> I'll add bringing up 10.2 or maybe 10.1 back somewhere on my list..
> This should probably handled "upstream" via "configure".
>
> Olaf, is what changed my m3makefile-ness or not?
> That is, it fails one way with cm3, but differently/later/better   
> with "regular" configure+make?

Yes, it fails differently. I haven't investigated why, though.

> Could be a flaw in my m3makefile shenanigans. But so far they   
> otherwise work and do cut out unnecessary stuff.
>
> I haven't had a chance to look into anything all Tuesday.

No problem, neither had I except for a few minutes.

Olaf

>  - Jay
>
>
>
>> Date: Wed, 7 May 2008 07:58:30 +0200> From: wagner at elegosoft.com>   
>> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: RE:   
>> [M3devel] m3cc build fails on older MacOS X> > Quoting Jay   
>> :> > > Olaf, can you try without my m3makefile  
>>  wierdness, that works elsewhere?> >> > cd %CVSROOT%/m3-sys/m3cc   
>> mkdir obj1 cd obj1 > > ../gcc/configure --disable-bootstrap   
>> --enable-languages=c,cm3cg > > make> > I'm not sure of "cm3cg", it   
>> might be "m3cg". And you can just omit > > that anyway, I doubt the  
>>  error is m3 related.> > (Tony: I don't believe --srcdir is needed.  
>>  configure figures it out; > > granted, maybe not trivially.)> > ?>  
>>  > I expect you will get the same error. Which isn't the final > >   
>> answer, just some relevant data. And if I'm wrong, well, that > >   
>> suggests some fix.> > I already answered this late yesterday   
>> evening, but somehow the mail> seems to have got lost. The build   
>> now stops with a wrong linker> switch:> > mv tmp-libgcc.map   
>> libgcc.map> # @multilib_flags@ is still needed because this may   
>> use> # /Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/xgcc >   
>> -B/Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/ >   
>> -B/usr/local/powerpc-apple-darwin7.9.0/bin/ >   
>> -B/usr/local/powerpc-apple-darwin7.9.0/lib/ -isystem >   
>> /usr/local/powerpc-apple-darwin7.9.0/include -isystem >   
>> /usr/local/powerpc-apple-darwin7.9.0/sys-include and -O2 -O2 -g -g   
>> > -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes >   
>> -Wmissing-prototypes -Wold-style-definition -isystem ./include >   
>> -Wa,-force_cpusubtype_ALL -pipe -mmacosx-version-min=10.4 -g >   
>> -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   
>> directly.> # @multilib_dir@ is not really necessary, but sometimes   
>> it has> # more uses than just a directory name.> /bin/sh   
>> ../../../gcc/libgcc/../mkinstalldirs .>   
>> /Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/xgcc >   
>> -B/Users/wagner/work/cm3/m3-sys/m3cc/derived/./gcc/ >   
>> -B/usr/local/powerpc-apple-darwin7.9.0/bin/ >   
>> -B/usr/local/powerpc-apple-darwin7.9.0/lib/ -isystem >   
>> /usr/local/powerpc-apple-darwin7.9.0/include -isystem >   
>> /usr/local/powerpc-apple-darwin7.9.0/sys-include -O2 -O2 -g -g -O2   
>> > -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes >   
>> -Wmissing-prototypes -Wold-style-definition -isystem ./include >   
>> -Wa,-force_cpusubtype_ALL -pipe -mmacosx-version-min=10.4 -g >   
>> -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   
>> -dynamiclib > -nodefaultlibs -install_name   
>> /usr/local/lib/libgcc_s`if test . = ppc64 > ; then echo _. ;   
>> fi`.1.dylib -single_module -o ./libgcc_s.1.dylib.tmp >   
>> -Wl,-exported_symbols_list,libgcc.map -compatibility_version 1 >   
>> -current_version 1.0 -O2 -g -g -O2 -B./ _muldi3_s.o _negdi2_s.o >   
>> _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o >   
>> _clear_cache_s.o _enable_execute_stack_s.o _trampoline_s.o   
>> __main_s.o > _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o   
>> _subvsi3_s.o > _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o   
>> _negvdi2_s.o > _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o   
>> _clzsi2_s.o _clzdi2_s.o > _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o  
>>  _popcountsi2_s.o > _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o   
>> _powisf2_s.o > _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o   
>> _muldc3_s.o > _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o   
>> _divxc3_s.o > _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o   
>> _fixunssfsi_s.o > _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o   
>> _fixdfdi_s.o _fixxfdi_s.o > _fixtfdi_s.o _fixunssfdi_s.o   
>> _fixunsdfdi_s.o _fixunsxfdi_s.o > _fixunstfdi_s.o _floatdisf_s.o   
>> _floatdidf_s.o _floatdixf_s.o > _floatditf_s.o _floatundisf_s.o   
>> _floatundidf_s.o _floatundixf_s.o > _floatunditf_s.o _divdi3_s.o   
>> _moddi3_s.o _udivdi3_s.o _umoddi3_s.o > _udiv_w_sdiv_s.o   
>> _udivmoddi4_s.o darwin-tramp_s.o ppc64-fp_s.o > darwin-64_s.o   
>> darwin-ldouble_s.o darwin-world_s.o unwind-dw2_s.o >   
>> unwind-dw2-fde-darwin_s.o unwind-sjlj_s.o unwind-c_s.o >   
>> darwin-fallback_s.o emutls_s.o -lc> /usr/bin/ld: unknown flag:   
>> -macosx_version_min> collect2: ld returned 1 exit status> make[2]:   
>> *** [libgcc_s.dylib] Error 1> make[1]: *** [all-target-libgcc]   
>> Error 2> make: *** [all] Error 2> > Probably nobody cares anymore   
>> for Mac OS X 10.3.9; I'll consider an> upgrade 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>



-- 
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 jayk123 at hotmail.com  Thu May  8 00:09:36 2008
From: jayk123 at hotmail.com (Jay)
Date: Wed, 7 May 2008 22:09:36 +0000
Subject: [M3devel] AMD64_LINUX snapshots available,
	without garbage collection
Message-ID: 


Now available at http://modula3.elegosoft.com/cm3/uploaded-archives/index.html


  cm3-min-POSIX-AMD64_LINUX-d5.7.0.tar.bz2
  cm3-min-POSIX-AMD64_LINUX-d5.7.0.tar.bz2


With some MAJOR caveats:


formsedit crashes
I haven't run most of the binaries.
Juno comes up.
Calculator comes up.
It builds itself -- cm3 works.
cm3cg is x86 hosted, can target x86 or AMD64 with -m32 or -m64.
cm3 is AMD64 hosted.


GARBAGE COLLECTION IS TURNED OFF via a one line hack in RTCollector.m3.
Turning it on crashes, not always in the same place.
This needs to be debugged.


This in a cminstall-less form, made with scripts/python/make-dist.py
  and manually patched to have Linux.common.


I have not yet tried m3tests.
I will shortly.


I also have TextLiteral.i3 locally changed to enable building from a 32 bit cm3.
Not a big deal, but if you are a stickler for binaries matching source..


If anyone else wants to debug the crashes with the garbage collector enabled, be my guest.
An easy repro is to build in m3-win/import-libs with cm3 -trace.
I assume -trace just causes more stuff to occur, more time to pass.


I didn't handle Uin.i3/Uucontext.i3 yet, hm.


This target is easily bootstrapped using x86 tools on an AMD64 system.
(ie: cm3; cm3cg as I said is still x86).
Hopefully soon I'll bring up platforms that don't have this 'cheat' available. :)

I do like:

 su
 cd /
 rm -rf /cm3
 tar xvf /cm3-min-POSIX-AMD64_LINUX-d5.7.0.tar.bz2
 cp -Rpv cm3-min-POSIX-AMD64_LINUX-d5.7.0 /cm3
 chown -R jay:jay /cm3
export PATH=$PATH:/cm3/bin
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/cm3/lib

However those are wrong if the paths are empty. They add the current working directory to the path if so, since "empty" is equivalent to ".", unfortunately. It should just be skipped/ignored but oh well.

I am using Ubuntu 8.4 Hardy Heron.
(Xubuntu, that was disappointing, so then apt-get-install kde or such)

 - Jay


From jayk123 at hotmail.com  Thu May  8 17:38:23 2008
From: jayk123 at hotmail.com (Jay)
Date: Thu, 8 May 2008 15:38:23 +0000
Subject: [M3devel] the matter of logging vs. NT386 C compilation
Message-ID: 

The Visual C++ compiler outputs source file name as they are compiled:
D:\dev2\cm3\m3-libs\m3core>cl -nologo -c nul.cnul.c
 
D:\dev2\cm3\m3-libs\m3core>cl -nologo -c nul.cnul.c
 
D:\dev2\cm3\m3-libs\m3core>cl -nologo -c nul.c nul.cnul.cnul.cGenerating Code...
I believe that suppressing this will suppress all other warning/error output.
See, they both go to stdout:
D:\dev2\cm3\m3-libs\m3core>echo error > foo.c
D:\dev2\cm3\m3-libs\m3core>cl -nologo -c foo.cfoo.cfoo.c(2) : fatal error C1004: unexpected end-of-file found
 
D:\dev2\cm3\m3-libs\m3core>cl -nologo -c foo.c >nul
 
D:\dev2\cm3\m3-libs\m3core>cl -nologo -c foo.c 2>nulfoo.cfoo.c(2) : fatal error C1004: unexpected end-of-file found
 
I tried something annoyingly expensive likecl -nologo -c foo.c | findstr /v /b /e foo.c 
 
which would only include lines that don't begin and end foo.c, but in normaluse, there are no such lines, there is just the one line, and so findstr fails, and so the overall command fails, not good.
 
You could do this:
 (echo. && cl -nologo -c foo.c)  | findstr /v /b /e foo.c 
Which nets you just a blank line output, but this seems to be heading to deep end, and even that blank line shouldn't be there.
Suggestions?
Maybe a change in cm3? Moving compile_c into it?My idea of moving Quake code into cm3 would be that cm3 has a definition of compile_c,but that if the user supplies compile_c, use that instead.
Doing that to solve just this is overkill, but it's not a bad idea anyway.
Smaller ideas could be considered, including:
1) Have all the compile_c implementations echo the source file, so they'd all have the same outputWhile is this is noisy in the user experience, there isn't much C.It does pollute all the platforms to cover up a small NT-specific problem.
2) What I suggested before, allow but to not encourage test cases to have per-platform results.This particular problem only affects test cases with C code, which is rare.There is one.
This would be very easy and solve the problem well.
It shouldn't be encouraged though, as it makes it more difficult to change the expected output of a test.
3) Currently if M3TESTS is defined, NT386.common redirects all C compiler output to nul.Good enough?
Related, in usage of GNU libtool, files are often compiled twice, once PIC, once not.The way it works, one invocation is directed to /dev/null, one is not.This would kinda sorta seem to set a precedent for redirecting C compiler output to /dev/null,except that they do run it both ways. It's not that errors are lost, just that they aren't doubled.
Also related, again, I suggest a log file.A detail hilighted here is that in fact ALL command would go to the log, and NONE would likelygo to stdout/stderr. Stdout/stderr would be strictly the domain of cm3.Perhaps cm3 could "sniff" for errors and pass them along, perhaps.
 
 
You know, really, the log file approach is already what is used for linking.
Why just linking? Why not everything run in the directory?
Ah, it looks like that isn't for all platforms though, just NT386.
 
I am half just making trouble here.
I think the logging should be more verbose, but even making it quiet is surprisingly difficult.
I guess the linking example shows the way though, I should just redirect C compiler output always to a file.
Maybe the same file as linking uses, maybe not.
The user experience in the face of error is, initially, badly degraded.
However there are ways to mitigate.
First, as with linking, upon error, we can tell the user about the file.
Second, upon error, we could just echo the file's contents to stdout.
It's just that for success, saying less is better.
 
I'll do that -- redirect to a file.
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Thu May  8 20:38:18 2008
From: jayk123 at hotmail.com (Jay)
Date: Thu, 8 May 2008 18:38:18 +0000
Subject: [M3devel] m3tests again
In-Reply-To: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
References: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
Message-ID: 

Olaf, sorry, not much here yet, except at least I do/did see problems where you see problems. Which ones are regressions?My numbers don't add up.I added one new failing test case, and I fixed one or two.
p116b floating pointp172  floating pointp185  floating point
--- p204 --- IP address initializers compiler crashes I think not new needs investigation
--- p206 --- ARRAY constructors in var decls using named open array types
 compiler gives reasonable error I think the compiler is correct. Updated expected outputs? Considering moving to category "e"?
 
--- p207 --- subrange declarations
 I think requires longint to really work. Disable for this platform?
--- p209 --- open array initializers compile failure
 compiler crashes (assertion failure) I think not new does need further investigation I changed the compiler to assert earlier for this
oh, also, I recently added this, knowing it doesn't pass yet
it is similar to p208 and/or p206.
 
--- p210 --- open array initializers runtime failure this is a new test I added I know it doesn't pass yet It shows a preexisting problem. And I messed up when I added it -- fixed now.
 
p209 and p210 are similar, but one fails an assertion in the compiler and one at runtime
--- r001 --- unhandled exception I believe this succeeds but possibly  the checking in the harness needs updated. I thought I had fixed it though. Darwin and FreeBSD need an update here though, simple.
--- e020 --- illegal recursive declaration builds and runs but is supposed to output a good error  and I think intead it infinitely recurses
--- e026 --- two types with the same brand I commited a fix in the compiler for this a few days ago.
 It was a simple error in yet another reinvention of linked lists.
--- e029 --- use type instead of value as an initializer fails assertion in compiler
 needs more investigation..
For most of these, I get no "@@" in the output,so maybe the test harness isn't working..But cd'ing around works.
sorry, I have to get going for nowmuch more hopefully later.
 - Jay


> Date: Tue, 6 May 2008 08:16:13 +0200> From: wagner at elegosoft.com> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: m3tests again> > Hi Jay,> > after several small fixes to the regression scripts, the nightrun> now shows for me> > >>> test_m3tests error extract:> >>> failed tests: p116b p172 p185 p204 p206 p207 p209 p210 r001 e020 > e026 e029> >>> 12 in test_m3tests 2008-05-06-01-30-23 > /home/wagner/work/cm3-ws/luthien-2008-05-06-01-30-23> > One week ago there were only 6. Could you have a closer look at this?> I'm still busy with other projects.> > 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 jayk123 at hotmail.com  Thu May  8 20:46:16 2008
From: jayk123 at hotmail.com (Jay)
Date: Thu, 8 May 2008 18:46:16 +0000
Subject: [M3devel] new NT386 snapshots
In-Reply-To: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
References: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
Message-ID: 

http://modula3.elegosoft.com/cm3/uploaded-archives/
 
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0.zip
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-WIN32-NT386-d5.7.0.zip
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0-symbols.zip
 
These should have:
  latest quake extensions 
  set relation fixes 
  other set fixes revealed through dynamic linking of one regression test 
  hypothetical ability to cross-build to AMD64_LINUX, AMD64_DARWIN  
  one jmpbuf size for all NT386 configurations (NT386, NT386GNU, NT386MINGNU) 
 
Built with Visual C++ 9.0 Express, so you'll want:
http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en
 
 
Still more work to do though, e.g. assertion failures in unit tests, pixmap..
 
Fuller disclosure:
Something is leaking memory on my system such that "everything" starts "failing" and I have to reboot.
This isn't Modula-3 related.
Hopefully these files aren't damaged as a result.
Must be some buggy driver or something..
 
Aside:
 The environment variable thingy has been bugging me a long time and I finally looked deeper at it.
It appears broken in CM3 4.x. I didn't check 3.x yet.
I'm still mulling a fix, and haven't run a repro of the break, but it's not a big deal either way.
Basically console apps use main that takes char** and gui apps use WinMain that doesn't get environment variables but the generated code calls GetEvironmentStrings() which returns null separated strings.
Must be that hardly anyone uses environment variables in Modula-3 on Win32 for this to have lingered so long, at least gui apps.
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Thu May  8 20:57:08 2008
From: jayk123 at hotmail.com (Jay)
Date: Thu, 8 May 2008 18:57:08 +0000
Subject: [M3devel] pixmap problem
In-Reply-To: <481F9804.1E75.00D7.1@scires.com>
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	 
	<481F9804.1E75.00D7.1@scires.com> 
Message-ID: 

Randy, At first very quick glance, this stuff looks ok.CM3-IDE probably doesn't really understand the config file, similar to m3cgcat's partial misunderstanding.
  (Which is why I keep TARGET declared in NT386* instead of just NT386.common.)
PKG_USE is defined I think, but it takes a really accurate understanding of Quake to get it.
 
The entry/subsystem stuff also seems complete but I didn't try examples yet.
Sorry, didn't give this all much time yet.
I did get me to look at the environment variable bug that's been sitting there forever, with a bogus fix..
 
Can CM3-IDE default PKG_USE to CM3_ROOT + "/pkg"? Or INSTALL_ROOT + "/pkg"? Or whatever?
That is what it always is, in anything that is checked in or that cminstall will give you.
It takes hand editing of cm3.cfg to get anything else I think.
 
Or CM3-IDE users can just edit the file some. Not a lot. But some.
Given an incomplete understanding of the config files, probably putting in CM3-IDE wants but under if FALSE will perhaps work.
Personally I wasn't impressed with Reactor... VC5 find-in-files gets me all I need. Anything besides plain text search doesn't scale..
 
 - Jay


From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problemDate: Tue, 6 May 2008 03:38:03 +0000


Randy, don't worry.Two of these problems are trivial to fix -- PKG_USE and popups.The pixmap one will need debugging.  - Jay


Date: Mon, 5 May 2008 23:28:10 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad news is that now I am getting a command window opening up in addition to the GUI window when the program runs.  This behavior does not occur on v4.1.  The command window seems to be the stdout/stderr of the GUI program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy>>> Jay  5/5/2008 10:47 PM >>>Randy, Yes.The NT386 config files are all checked in.You can use them verbatim. You don't need cminstall, I never use it, and you shouldn't need to edit the config files at all, any edits I make, I check in, and should be usable on all machines.As long as you set %PATH%/%INCLUDE%/%LIB%.If I'm wrong, I'd like to know why and try to fix. Consider the config files just part of cm3.exe.Not generally to be changed locally. Unless, well, unless you intend to, and you should strive to make one form that is usable by all.  - Jay


Date: Mon, 5 May 2008 22:42:30 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay,
When you say "took the updated config file", what do you mean?  Are you saying I need a different cm3.cfg file?
Regards,
Randy>>> Jay  5/5/2008 9:54 PM >>>And you took the updated config file?The way you can tell is that, roughly speaking, hand.obj should be in NT386\_m3responsefile0.txt.Or _m3responsefile1.txt, or, well, somewhere.Anyway, I think I saw the attachment, I can check later..and with 4.1 as I said.. I can see about making the fix not depend on config file changes...but it's not terrible asis, and I'd really like to merge more of the quake code into cm3.exe..  - Jay


Date: Mon, 5 May 2008 21:18:12 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem
Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly when the buildstandalone() directive is used.
 
Regards,
Randy>>> Jay  5/5/2008 7:04 PM >>>Thanks. I'll look into this tonight probably, as well as with 4.1 assuming I can find my binaries and source for it (probably).COULD BE the pixmap problem is something else and 4.1 also has the problem I fixed. We'll see. No need to speculate (unless I can't find my 4.1). - Jay


Date: Mon, 5 May 2008 10:59:27 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problem
Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy>>> Jay  5/4/2008 11:46 AM >>>Randy, Please try with /current/ source, as of this morning Sunday May 4 -- the changes are ALL in NT386.common, so you MUST use MY config files, which are checked in verbatim, or you should be able edit whatever config files you are using. (It's not really a config file issue, don't blame the general confusion people have with them.) I'll try to try later, but I don't have the source right now, gotta look on other machines, and I think it's on a machine on loan.  Or send it to me again.I'd also like to know if this worked with 4.1, or with any release that offered dynamic linking to m3core.dll, on Windows.  I recall a claim that it did. If today's change fixes it, I should be able to investigate 4.1.3.6 did not have such linking.If today's change does not help, well, I still plan on debugging it at some point.. If you aren't current and getting so is difficult, just send the attachment again, it's easy for me to test. Thanks, - Jay


From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rcoleburn at scires.comDate: Sat, 19 Jan 2008 08:52:08 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.I was going to try on PPC_DARWIN but I guess Tony's info suffices. I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. Debugging here is a big humungous pain.NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)And bundles look pretty simple, a bundle is just a generated source file with a constant in it.Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something. The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for? I have to say this is very surprising. I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so.The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: pointer to msvcrt!fopenpointer to msvcrt!fclosenullpointer to kernel32!Sleep But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo.But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo.That doesn't work for data though. There's no ability to intervenve like that.So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it.And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.However that would suck perf in order to make an uncommon case work.I hope Modula-3 doesn't do that either. :)Though I guess since this global data in question...maybe it is rare??? Later, - Jay

> From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 03:09:47 -0500> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] pixmap problem> > Looks fine to me on I386_DARWIN.> > On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:> > > > 

Need to know the score, the latest news, or you need your Hotmail?-get your "fix" Check it out. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Thu May  8 21:21:49 2008
From: jayk123 at hotmail.com (Jay)
Date: Thu, 8 May 2008 19:21:49 +0000
Subject: [M3devel] FW:  pixmap problem
In-Reply-To: <481F9804.1E75.00D7.1@scires.com>
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	 
	<481F9804.1E75.00D7.1@scires.com>  
Message-ID: 

truncated again...


From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problemDate: Thu, 8 May 2008 18:57:08 +0000


Randy, At first very quick glance, this stuff looks ok.CM3-IDE probably doesn't really understand the config file, similar to m3cgcat's partial misunderstanding.  (Which is why I keep TARGET declared in NT386* instead of just NT386.common.)PKG_USE is defined I think, but it takes a really accurate understanding of Quake to get it. The entry/subsystem stuff also seems complete but I didn't try examples yet.Sorry, didn't give this all much time yet.I did get me to look at the environment variable bug that's been sitting there forever, with a bogus fix.. Can CM3-IDE default PKG_USE to CM3_ROOT + "/pkg"? Or INSTALL_ROOT + "/pkg"? Or whatever?That is what it always is, in anything that is checked in or that cminstall will give you.It takes hand editing of cm3.cfg to get anything else I think. Or CM3-IDE users can just edit the file some. Not a lot. But some.Given an incomplete understanding of the config files, probably putting in CM3-IDE wants but under if FALSE will perhaps work.Personally I wasn't impressed with Reactor... VC5 find-in-files gets me all I need. Anything besides plain text search doesn't scale..  - Jay


From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problemDate: Tue, 6 May 2008 03:38:03 +0000

Randy, don't worry.Two of these problems are trivial to fix -- PKG_USE and popups.The pixmap one will need debugging.  - Jay


Date: Mon, 5 May 2008 23:28:10 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad news is that now I am getting a command window opening up in addition to the GUI window when the program runs.  This behavior does not occur on v4.1.  The command window seems to be the stdout/stderr of the GUI program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy>>> Jay  5/5/2008 10:47 PM >>>Randy, Yes.The NT386 config files are all checked in.You can use them verbatim. You don't need cminstall, I never use it, and you shouldn't need to edit the config files at all, any edits I make, I check in, and should be usable on all machines.As long as you set %PATH%/%INCLUDE%/%LIB%.If I'm wrong, I'd like to know why and try to fix. Consider the config files just part of cm3.exe.Not generally to be changed locally. Unless, well, unless you intend to, and you should strive to make one form that is usable by all.  - Jay


Date: Mon, 5 May 2008 22:42:30 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay,
When you say "took the updated config file", what do you mean?  Are you saying I need a different cm3.cfg file?
Regards,
Randy>>> Jay  5/5/2008 9:54 PM >>>And you took the updated config file?The way you can tell is that, roughly speaking, hand.obj should be in NT386\_m3responsefile0.txt.Or _m3responsefile1.txt, or, well, somewhere.Anyway, I think I saw the attachment, I can check later..and with 4.1 as I said.. I can see about making the fix not depend on config file changes...but it's not terrible asis, and I'd really like to merge more of the quake code into cm3.exe..  - Jay


Date: Mon, 5 May 2008 21:18:12 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem
Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly when the buildstandalone() directive is used.
 
Regards,
Randy>>> Jay  5/5/2008 7:04 PM >>>Thanks. I'll look into this tonight probably, as well as with 4.1 assuming I can find my binaries and source for it (probably).COULD BE the pixmap problem is something else and 4.1 also has the problem I fixed. We'll see. No need to speculate (unless I can't find my 4.1). - Jay


Date: Mon, 5 May 2008 10:59:27 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problem
Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy>>> Jay  5/4/2008 11:46 AM >>>Randy, Please try with /current/ source, as of this morning Sunday May 4 -- the changes are ALL in NT386.common, so you MUST use MY config files, which are checked in verbatim, or you should be able edit whatever config files you are using. (It's not really a config file issue, don't blame the general confusion people have with them.) I'll try to try later, but I don't have the source right now, gotta look on other machines, and I think it's on a machine on loan.  Or send it to me again.I'd also like to know if this worked with 4.1, or with any release that offered dynamic linking to m3core.dll, on Windows.  I recall a claim that it did. If today's change fixes it, I should be able to investigate 4.1.3.6 did not have such linking.If today's change does not help, well, I still plan on debugging it at some point.. If you aren't current and getting so is difficult, just send the attachment again, it's easy for me to test. Thanks, - Jay


From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rcoleburn at scires.comDate: Sat, 19 Jan 2008 08:52:08 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.I was going to try on PPC_DARWIN but I guess Tony's info suffices. I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. Debugging here is a big humungous pain.NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)And bundles look pretty simple, a bundle is just a generated source file with a constant in it.Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something. The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for? I have to say this is very surprising. I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so.The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: pointer to msvcrt!fopenpointer to msvcrt!fclosenullpointer to kernel32!Sleep But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo.But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo.That doesn't work for data though. There's no ability to intervenve like that.So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it.And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.However that would suck perf in order to make an uncommon case work.I hope Modula-3 doesn't do that either. :)Though I guess since this global data in question...maybe it is rare??? Later, - Jay

> From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 03:09:47 -0500> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] pixmap problem> > Looks fine to me on I386_DARWIN.> > On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:> > > > 

Need to know the score, the latest news, or you need your Hotmail?-get your "fix" Check it out. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Thu May  8 22:17:37 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Thu, 08 May 2008 16:17:37 -0400
Subject: [M3devel] new NT386 snapshots
In-Reply-To: 
References: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
	
Message-ID: <4823279D.1E75.00D7.1@scires.com>

Jay:
 
I have both console and gui programs built using 4.1 that do pull stuff out of the environment.  I've not noticed any problems with either mode.
 
>From my perspective, the old 4.1 seems more reliable than the current system in a number of respects.  I have a new project with a hard deadline that I would like to use the new cm3 system for, but until these problems (pixmaps, buildstandalone, environ vars, serial i/o, etc.) can be resolved, I'm going to keep using 4.1 for my production work.
 
Regards,
Randy

>>> Jay  5/8/2008 2:46 PM >>>
http://modula3.elegosoft.com/cm3/uploaded-archives/ 
 
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0.zip 
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-WIN32-NT386-d5.7.0.zip 
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0-symbols.zip 
 
These should have:
  latest quake extensions 
  set relation fixes 
  other set fixes revealed through dynamic linking of one regression test 
  hypothetical ability to cross-build to AMD64_LINUX, AMD64_DARWIN  
  one jmpbuf size for all NT386 configurations (NT386, NT386GNU, NT386MINGNU) 
 
Built with Visual C++ 9.0 Express, so you'll want:
http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en 
 
 
Still more work to do though, e.g. assertion failures in unit tests, pixmap..
 
Fuller disclosure:
Something is leaking memory on my system such that "everything" starts "failing" and I have to reboot.
This isn't Modula-3 related.
Hopefully these files aren't damaged as a result.
Must be some buggy driver or something..
 
Aside:
 The environment variable thingy has been bugging me a long time and I finally looked deeper at it.
It appears broken in CM3 4.x. I didn't check 3.x yet.
I'm still mulling a fix, and haven't run a repro of the break, but it's not a big deal either way.
Basically console apps use main that takes char** and gui apps use WinMain that doesn't get environment variables but the generated code calls GetEvironmentStrings() which returns null separated strings.
Must be that hardly anyone uses environment variables in Modula-3 on Win32 for this to have lingered so long, at least gui apps.
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Thu May  8 22:35:54 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Thu, 08 May 2008 16:35:54 -0400
Subject: [M3devel] FW:  pixmap problem
In-Reply-To: 
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	
	<481F9804.1E75.00D7.1@scires.com> <481F9804.1E75.00D7.1@scires.com>
	
Message-ID: <48232BE6.1E75.00D7.1@scires.com>

Jay:
 
I've made some changes to CM3IDE that seem to allow it to cope with
your new cm3.cfg file.  
 
[Aside:  I do not understand your insistence that we can no longer have
all of the variables defined that used to be there back in the 4.1 days.
 When you make these types of unilateral changes without making
provision for reliant code, you wind up breaking stuff that used to
work.]
 
Bottom line, I've got CM3IDE working now for me on WindowsXP using your
NT386/NT386.common for cm3.cfg.  Others will need to test on other
platforms once we get the final go-ahead to put the code in the
repository.
 
As for the difference in the console window startup for gui programs,
that will be real show-stopper for production code.  I can't deliver a
GUI program that is going to have a command shell window popped open for
stdout/stderr output.
 
The pixmap problem is another show-stopper for production code.
 
I can't use the new cm3 for production code until these major problems
are resolved.  Any help you can offer in resolving these is
appreciated.
 
[Aside:  What is the deal with your email program truncating your
messages?  This is very bothersome.]
 
Regards,
Randy

>>> Jay  5/8/2008 3:21 PM >>>
truncated again...




From: jayk123 at hotmail.com 
To: rcoleburn at scires.com; m3devel at elegosoft.com 
Subject: RE: [M3devel] pixmap problem
Date: Thu, 8 May 2008 18:57:08 +0000

Randy, At first very quick glance, this stuff looks ok.
CM3-IDE probably doesn't really understand the config file, similar to
m3cgcat's partial misunderstanding.
  (Which is why I keep TARGET declared in NT386* instead of just
NT386.common.)
PKG_USE is defined I think, but it takes a really accurate
understanding of Quake to get it.
 
The entry/subsystem stuff also seems complete but I didn't try examples
yet.
Sorry, didn't give this all much time yet.
I did get me to look at the environment variable bug that's been
sitting there forever, with a bogus fix..
 
Can CM3-IDE default PKG_USE to CM3_ROOT + "/pkg"? Or INSTALL_ROOT +
"/pkg"? Or whatever?
That is what it always is, in anything that is checked in or that
cminstall will give you.
It takes hand editing of cm3.cfg to get anything else I think.
 
Or CM3-IDE users can just edit the file some. Not a lot. But some.
Given an incomplete understanding of the config files, probably putting
in CM3-IDE wants but under if FALSE will perhaps work.
Personally I wasn't impressed with Reactor... VC5 find-in-files gets me
all I need. Anything besides plain text search doesn't scale..
 
 - Jay
From: jayk123 at hotmail.com 
To: rcoleburn at scires.com; m3devel at elegosoft.com 
Subject: RE: [M3devel] pixmap problem
Date: Tue, 6 May 2008 03:38:03 +0000

Randy, don't worry.
Two of these problems are trivial to fix -- PKG_USE and popups.
The pixmap one will need debugging.
 
 - Jay

Date: Mon, 5 May 2008 23:28:10 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com; jayk123 at hotmail.com 
Subject: RE: [M3devel] pixmap problem

Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've
copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad
news is that now I am getting a command window opening up in addition to
the GUI window when the program runs.  This behavior does not occur on
v4.1.  The command window seems to be the stdout/stderr of the GUI
program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which
needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy

>>> Jay  5/5/2008 10:47 PM >>>
Randy, Yes.
The NT386 config files are all checked in.
You can use them verbatim. You don't need cminstall, I never use it,
and you shouldn't need to edit the config files at all, any edits I
make, I check in, and should be usable on all machines.
As long as you set %PATH%/%INCLUDE%/%LIB%.
If I'm wrong, I'd like to know why and try to fix.
 
Consider the config files just part of cm3.exe.
Not generally to be changed locally. Unless, well, unless you intend
to, and you should strive to make one form that is usable by all.
 
 - Jay


Date: Mon, 5 May 2008 22:42:30 -0400
From: rcoleburn at scires.com 
To: jayk123 at hotmail.com 
Subject: RE: [M3devel] pixmap problem

Jay,
When you say "took the updated config file", what do you mean?  Are you
saying I need a different cm3.cfg file?
Regards,
Randy

>>> Jay  5/5/2008 9:54 PM >>>
And you took the updated config file?
The way you can tell is that, roughly speaking, hand.obj should be in
NT386\_m3responsefile0.txt.
Or _m3responsefile1.txt, or, well, somewhere.
Anyway, I think I saw the attachment, I can check later..and with 4.1
as I said..
 
I can see about making the fix not depend on config file changes...but
it's not terrible asis, and I'd really like to merge more of the quake
code into cm3.exe..
 
 - Jay

Date: Mon, 5 May 2008 21:18:12 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com 
Subject: Re: [M3devel] pixmap problem

Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly
when the buildstandalone() directive is used.
 
Regards,
Randy

>>> Jay  5/5/2008 7:04 PM >>>
Thanks. I'll look into this tonight probably, as well as with 4.1
assuming I can find my binaries and source for it (probably).

COULD BE the pixmap problem is something else and 4.1 also has the
problem I fixed. We'll see. No need to speculate (unless I can't find my
4.1).

 - Jay


Date: Mon, 5 May 2008 10:59:27 -0400
From: rcoleburn at scires.com 
To: jayk123 at hotmail.com 
CC: m3devel at elegosoft.com 
Subject: RE: [M3devel] pixmap problem

Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files
or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy

>>> Jay  5/4/2008 11:46 AM >>>
Randy, Please try with /current/ source, as of this morning Sunday May
4 -- the changes are ALL in NT386.common, so you MUST use MY config
files, which are checked in verbatim, or you should be able edit
whatever config files you are using.
 
(It's not really a config file issue, don't blame the general confusion
people have with them.)
 
I'll try to try later, but I don't have the source right now, gotta
look on other machines, and I think it's on a machine on loan.
  Or send it to me again.
I'd also like to know if this worked with 4.1, or with any release that
offered dynamic linking to m3core.dll, on Windows.
  I recall a claim that it did. If today's change fixes it, I should be
able to investigate 4.1.
3.6 did not have such linking.
If today's change does not help, well, I still plan on debugging it at
some point..
 
If you aren't current and getting so is difficult, just send the
attachment again, it's easy for me to test.
 
Thanks,
 - Jay

From: jayk123 at hotmail.com 
To: hosking at cs.purdue.edu; rcoleburn at scires.com 
Date: Sat, 19 Jan 2008 08:52:08 +0000
CC: m3devel at elegosoft.com 
Subject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.
I was going to try on PPC_DARWIN but I guess Tony's info suffices.
 
I tried rolling hand.c back to before I changed (months/year ago),
since it is involved in bit twiddling, no change, phew.
 
Debugging here is a big humungous pain.
NT386 has good stacks and line numbers, but no locals or type info, I'd
really sometime like to get Codeview info into those .objs...I think it
is documented well enough, but still not necessarily easy, or maybe have
a C generating backend partly for this reason (and to bring up more
targets, using native tools), and function calls in disassembly I think
don't resolve; NT386GNU can't yet build this, though it will soon, but
I'm not familiar with gdb and there appears to be no type info. I'm
building m3gdb right now, I don't know if it will work, I hope it has
type info, and I'm not familiar with the relevant code. In gdb I
struggle just to view bytes in memory, add numbers to addresses and see
those, etc. I think for MY problem, I'm going to link in C code to dump
the structs. There is tracing code and I enabled it, but even it crashes
in Text_Length. At least MY problem crashes, hopefully near the problem,
whereas your problem goes all the way through to completion with no
stopping to hint where the problem is. Darn it. :) on the mock rudeness
and :( on the lack of a crash.
 
You write the bundle out and it matches, so that doesn't rule out
bundles as being the problem? (darn)
And bundles look pretty simple, a bundle is just a generated source
file with a constant in it.
Maybe newline problems? That wouldn't make sense. I just downloaded
some program that might let me separately view the ppm, maybe it'll
reveal something.
 
The bad behavior has like regularly spaced solid color veritical bars a
few pixels side across the whole picture, and regularly spaced vertical
stripes from the correct picture alternating with that. Perhaps someone
with ppm/bitmap/graphics experience has seen this behavior and it
results from some common pixmap mismanagement we could look for?
 
I have to say this is very surprising.
 
I always wondered, and now I pretty much assume -- Modula-3 never
imports/exports data in its dynamic linking, right? It alway
imports/exports functions, right?
On Windows, functions have an optional optimization, but data must be
handled differently at compile time if it is going to be dynamically
imported.
For functions, if you don't apply the optimization at compile time, the
linker will just generate a single instruction thunk instead.
 
That is, given a symbol Foo, there is a symbol __imp__Foo that is a
pointer to the actual foo in another .dll/.so.
The loader only patches pointers, one per import if you build your .dll
correctly, it doesn't patch instructions or code strewn throughout a
.dll, just one contiguous array of pointers. MAYBE they don't have to be
contiguous for each .dl you import from.
 
That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my
.dll/.exe typically has an array:
 
pointer to msvcrt!fopen
pointer to msvcrt!fclose
null
pointer to kernel32!Sleep
 
But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not
be adjacent.
 
So, going back, my point/question is that, if the compiler knows the
function is imported, it can call through __imp__Foo instead of calling
Foo.
But if it calls Foo and you import Foo, the linker will create the
function Foo that just jmps through __imp__Foo.
That doesn't work for data though. There's no ability to intervenve
like that.
So for imported data, the compiler must generated a read and
dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to
be imported.
Data imports may be faster when appropriate, but for this reason, I'd
say they aren't worth it.
And for this reason, I HOPE Modula-3 never imports/exports data.
 
Oh, you could, for data, always reference the pointer __imp_Foo, and if
non materializes, create one.
However that would suck perf in order to make an uncommon case work.
I hope Modula-3 doesn't do that either. :)
Though I guess since this global data in question...maybe it is
rare???
 
Later,
 - Jay



> From: hosking at cs.purdue.edu 
> Date: Sat, 19 Jan 2008 03:09:47 -0500
> To: rcoleburn at scires.com 
> CC: m3devel at elegosoft.com 
> Subject: Re: [M3devel] pixmap problem
> 
> Looks fine to me on I386_DARWIN.
> 
> On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:
> 
> > 
> 


Need to know the score, the latest news, or you need your Hotmail*-get
your "fix" Check it out. ( http://www.msnmobilefix.com/Default.aspx ) 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Thu May  8 23:05:15 2008
From: jayk123 at hotmail.com (Jay)
Date: Thu, 8 May 2008 21:05:15 +0000
Subject: [M3devel] FW:  pixmap problem
In-Reply-To: <48232BE6.1E75.00D7.1@scires.com>
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	
	<481F9804.1E75.00D7.1@scires.com> <481F9804.1E75.00D7.1@scires.com>
	 
	<48232BE6.1E75.00D7.1@scires.com>
Message-ID: 

Randy, I don't insist on not having it -- it is in fact there. CM3IDE may have its own parser for quake files such that it doesn't understand it, but it is there. But indeed, variables that are either unused or almost never used, shouldn't stick around. Things get crufty when there is too much "just in case". Things get hard to change when some things depend on too many imlementation details.The gui problem is simple no matter what. There's just not much there. I'll look later.
 - Jay


Date: Thu, 8 May 2008 16:35:54 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] FW: pixmap problem

Jay:
 
I've made some changes to CM3IDE that seem to allow it to cope with your new cm3.cfg file.  
 
[Aside:  I do not understand your insistence that we can no longer have all of the variables defined that used to be there back in the 4.1 days.  When you make these types of unilateral changes without making provision for reliant code, you wind up breaking stuff that used to work.]
 
Bottom line, I've got CM3IDE working now for me on WindowsXP using your NT386/NT386.common for cm3.cfg.  Others will need to test on other platforms once we get the final go-ahead to put the code in the repository.
 
As for the difference in the console window startup for gui programs, that will be real show-stopper for production code.  I can't deliver a GUI program that is going to have a command shell window popped open for stdout/stderr output.
 
The pixmap problem is another show-stopper for production code.
 
I can't use the new cm3 for production code until these major problems are resolved.  Any help you can offer in resolving these is appreciated.
 
[Aside:  What is the deal with your email program truncating your messages?  This is very bothersome.]
 
Regards,
Randy>>> Jay  5/8/2008 3:21 PM >>>truncated again...


From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problemDate: Thu, 8 May 2008 18:57:08 +0000

Randy, At first very quick glance, this stuff looks ok.CM3-IDE probably doesn't really understand the config file, similar to m3cgcat's partial misunderstanding.  (Which is why I keep TARGET declared in NT386* instead of just NT386.common.)PKG_USE is defined I think, but it takes a really accurate understanding of Quake to get it. The entry/subsystem stuff also seems complete but I didn't try examples yet.Sorry, didn't give this all much time yet.I did get me to look at the environment variable bug that's been sitting there forever, with a bogus fix.. Can CM3-IDE default PKG_USE to CM3_ROOT + "/pkg"? Or INSTALL_ROOT + "/pkg"? Or whatever?That is what it always is, in anything that is checked in or that cminstall will give you.It takes hand editing of cm3.cfg to get anything else I think. Or CM3-IDE users can just edit the file some. Not a lot. But some.Given an incomplete understanding of the config files, probably putting in CM3-IDE wants but under if FALSE will perhaps work.Personally I wasn't impressed with Reactor... VC5 find-in-files gets me all I need. Anything besides plain text search doesn't scale..  - Jay


From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problemDate: Tue, 6 May 2008 03:38:03 +0000

Randy, don't worry.Two of these problems are trivial to fix -- PKG_USE and popups.The pixmap one will need debugging.  - Jay


Date: Mon, 5 May 2008 23:28:10 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad news is that now I am getting a command window opening up in addition to the GUI window when the program runs.  This behavior does not occur on v4.1.  The command window seems to be the stdout/stderr of the GUI program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy>>> Jay  5/5/2008 10:47 PM >>>Randy, Yes.The NT386 config files are all checked in.You can use them verbatim. You don't need cminstall, I never use it, and you shouldn't need to edit the config files at all, any edits I make, I check in, and should be usable on all machines.As long as you set %PATH%/%INCLUDE%/%LIB%.If I'm wrong, I'd like to know why and try to fix. Consider the config files just part of cm3.exe.Not generally to be changed locally. Unless, well, unless you intend to, and you should strive to make one form that is usable by all.  - Jay


Date: Mon, 5 May 2008 22:42:30 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay,
When you say "took the updated config file", what do you mean?  Are you saying I need a different cm3.cfg file?
Regards,
Randy>>> Jay  5/5/2008 9:54 PM >>>And you took the updated config file?The way you can tell is that, roughly speaking, hand.obj should be in NT386\_m3responsefile0.txt.Or _m3responsefile1.txt, or, well, somewhere.Anyway, I think I saw the attachment, I can check later..and with 4.1 as I said.. I can see about making the fix not depend on config file changes...but it's not terrible asis, and I'd really like to merge more of the quake code into cm3.exe..  - Jay


Date: Mon, 5 May 2008 21:18:12 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem
Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly when the buildstandalone() directive is used.
 
Regards,
Randy>>> Jay  5/5/2008 7:04 PM >>>Thanks. I'll look into this tonight probably, as well as with 4.1 assuming I can find my binaries and source for it (probably).COULD BE the pixmap problem is something else and 4.1 also has the problem I fixed. We'll see. No need to speculate (unless I can't find my 4.1). - Jay


Date: Mon, 5 May 2008 10:59:27 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problem
Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy>>> Jay  5/4/2008 11:46 AM >>>Randy, Please try with /current/ source, as of this morning Sunday May 4 -- the changes are ALL in NT386.common, so you MUST use MY config files, which are checked in verbatim, or you should be able edit whatever config files you are using. (It's not really a config file issue, don't blame the general confusion people have with them.) I'll try to try later, but I don't have the source right now, gotta look on other machines, and I think it's on a machine on loan.  Or send it to me again.I'd also like to know if this worked with 4.1, or with any release that offered dynamic linking to m3core.dll, on Windows.  I recall a claim that it did. If today's change fixes it, I should be able to investigate 4.1.3.6 did not have such linking.If today's change does not help, well, I still plan on debugging it at some point.. If you aren't current and getting so is difficult, just send the attachment again, it's easy for me to test. Thanks, - Jay


From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rcoleburn at scires.comDate: Sat, 19 Jan 2008 08:52:08 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.I was going to try on PPC_DARWIN but I guess Tony's info suffices. I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. Debugging here is a big humungous pain.NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)And bundles look pretty simple, a bundle is just a generated source file with a constant in it.Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something. The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for? I have to say this is very surprising. I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so.The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: pointer to msvcrt!fopenpointer to msvcrt!fclosenullpointer to kernel32!Sleep But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo.But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo.That doesn't work for data though. There's no ability to intervenve like that.So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it.And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.However that would suck perf in order to make an uncommon case work.I hope Modula-3 doesn't do that either. :)Though I guess since this global data in question...maybe it is rare??? Later, - Jay

> From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 03:09:47 -0500> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] pixmap problem> > Looks fine to me on I386_DARWIN.> > On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:> > > > 

Need to know the score, the latest news, or you need your Hotmail?-get your "fix" Check it out. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Thu May  8 23:18:04 2008
From: jayk123 at hotmail.com (Jay)
Date: Thu, 8 May 2008 21:18:04 +0000
Subject: [M3devel] new NT386 snapshots
In-Reply-To: <4823279D.1E75.00D7.1@scires.com>
References: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
	 
	<4823279D.1E75.00D7.1@scires.com>
Message-ID: 

The code in 4.1 in clearly, by inspection, incorrect. I'll have to test it out and debug it though. Inspection isn't enough.I have no idea why my mail gets truncated. I agree it is annoying.
 
F:\products\modula3\CONTRIB\SRC-M3\m3\m3core\src\runtime\WIN32\RTArgs.m3(7):(* In Windows/NT, "envp" points at a null-terminated block ofF:\products\modula3\CONTRIB\SRC-M3\m3\m3core\src\runtime\WIN32\RTArgs.m3(144):    envp : Ctypes.char_star := RTLinker.info.envp;
f:\products\modula3\CONTRIB\SRC-M3\m3\m3linker\src\MxGen.m3(117):    Out (s, "  _ADDRESS envp;", s.eol);f:\products\modula3\CONTRIB\SRC-M3\m3\m3linker\src\MxGen.m3(480):    Out (s, "  /* envp       */ 0,", s.eol);f:\products\modula3\CONTRIB\SRC-M3\m3\m3linker\src\MxGen.m3(498):      Out (s, "    _m3_link_info.envp = (_ADDRESS)GetEnvironmentStrings();", s.eol);f:\products\modula3\CONTRIB\SRC-M3\m3\m3linker\src\MxGen.m3(501):      Out (s, "int main (argc, argv, envp)", s.eol);f:\products\modula3\CONTRIB\SRC-M3\m3\m3linker\src\MxGen.m3(504):      Out (s, "char **envp;", s.eol);f:\products\modula3\CONTRIB\SRC-M3\m3\m3linker\src\MxGen.m3(512):      Out (s, "    _m3_link_info.envp = (_ADDRESS)(envp);", s.eol); > serial i/o?
 
I haven't touched it, looked it really, or heard of any problems.
I looked at it for purposes of NT386GNU but didn't really do anything.
 
Pixmaps need debugging, indeed.
 
I found my 4.1 CD. :)
 
- Jay


Date: Thu, 8 May 2008 16:17:37 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] new NT386 snapshots

Jay:
 
I have both console and gui programs built using 4.1 that do pull stuff out of the environment.  I've not noticed any problems with either mode.
 
>From my perspective, the old 4.1 seems more reliable than the current system in a number of respects.  I have a new project with a hard deadline that I would like to use the new cm3 system for, but until these problems (pixmaps, buildstandalone, environ vars, serial i/o, etc.) can be resolved, I'm going to keep using 4.1 for my production work.
 
Regards,
Randy>>> Jay  5/8/2008 2:46 PM >>>http://modula3.elegosoft.com/cm3/uploaded-archives/ http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0.ziphttp://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-WIN32-NT386-d5.7.0.ziphttp://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0-symbols.zip These should have:  latest quake extensions   set relation fixes   other set fixes revealed through dynamic linking of one regression test   hypothetical ability to cross-build to AMD64_LINUX, AMD64_DARWIN    one jmpbuf size for all NT386 configurations (NT386, NT386GNU, NT386MINGNU)  Built with Visual C++ 9.0 Express, so you'll want:http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en  Still more work to do though, e.g. assertion failures in unit tests, pixmap.. Fuller disclosure:Something is leaking memory on my system such that "everything" starts "failing" and I have to reboot.This isn't Modula-3 related.Hopefully these files aren't damaged as a result.Must be some buggy driver or something.. Aside: The environment variable thingy has been bugging me a long time and I finally looked deeper at it.It appears broken in CM3 4.x. I didn't check 3.x yet.I'm still mulling a fix, and haven't run a repro of the break, but it's not a big deal either way.Basically console apps use main that takes char** and gui apps use WinMain that doesn't get environment variables but the generated code calls GetEvironmentStrings() which returns null separated strings.Must be that hardly anyone uses environment variables in Modula-3 on Win32 for this to have lingered so long, at least gui apps.  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Thu May  8 23:53:26 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Thu, 08 May 2008 17:53:26 -0400
Subject: [M3devel] new NT386 snapshots
In-Reply-To: 
References: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
	
	<4823279D.1E75.00D7.1@scires.com>
	
Message-ID: <48233E12.1E75.00D7.1@scires.com>

Jay:
 
I have a working serial-I/O module for Windows and one for HPUX, so maybe I should compare it to what is out there now and make some fixes.
 
Regards,
Randy

>>> Jay  5/8/2008 5:18 PM >>>
The code in 4.1 in clearly, by inspection, incorrect. I'll have to test it out and debug it though. Inspection isn't enough.
I have no idea why my mail gets truncated. I agree it is annoying.
 
F:\products\modula3\CONTRIB\SRC-M3\m3\m3core\src\runtime\WIN32\RTArgs.m3(7):(* In Windows/NT, "envp" points at a null-terminated block of
F:\products\modula3\CONTRIB\SRC-M3\m3\m3core\src\runtime\WIN32\RTArgs.m3(144):    envp : Ctypes.char_star := RTLinker.info.envp;


f:\products\modula3\CONTRIB\SRC-M3\m3\m3linker\src\MxGen.m3(117):    Out (s, "  _ADDRESS envp;", s.eol);
f:\products\modula3\CONTRIB\SRC-M3\m3\m3linker\src\MxGen.m3(480):    Out (s, "  /* envp       */ 0,", s.eol);
f:\products\modula3\CONTRIB\SRC-M3\m3\m3linker\src\MxGen.m3(498):      Out (s, "    _m3_link_info.envp = (_ADDRESS)GetEnvironmentStrings();", s.eol);
f:\products\modula3\CONTRIB\SRC-M3\m3\m3linker\src\MxGen.m3(501):      Out (s, "int main (argc, argv, envp)", s.eol);
f:\products\modula3\CONTRIB\SRC-M3\m3\m3linker\src\MxGen.m3(504):      Out (s, "char **envp;", s.eol);
f:\products\modula3\CONTRIB\SRC-M3\m3\m3linker\src\MxGen.m3(512):      Out (s, "    _m3_link_info.envp = (_ADDRESS)(envp);", s.eol);

 > serial i/o?
 
I haven't touched it, looked it really, or heard of any problems.
I looked at it for purposes of NT386GNU but didn't really do anything.
 
Pixmaps need debugging, indeed.
 
I found my 4.1 CD. :)
 
- Jay

Date: Thu, 8 May 2008 16:17:37 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com 
Subject: Re: [M3devel] new NT386 snapshots

Jay:
 
I have both console and gui programs built using 4.1 that do pull stuff out of the environment.  I've not noticed any problems with either mode.
 
>From my perspective, the old 4.1 seems more reliable than the current system in a number of respects.  I have a new project with a hard deadline that I would like to use the new cm3 system for, but until these problems (pixmaps, buildstandalone, environ vars, serial i/o, etc.) can be resolved, I'm going to keep using 4.1 for my production work.
 
Regards,
Randy

>>> Jay  5/8/2008 2:46 PM >>>
http://modula3.elegosoft.com/cm3/uploaded-archives/ 
 
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0.zip 
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-WIN32-NT386-d5.7.0.zip 
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0-symbols.zip 
 
These should have:
  latest quake extensions 
  set relation fixes 
  other set fixes revealed through dynamic linking of one regression test 
  hypothetical ability to cross-build to AMD64_LINUX, AMD64_DARWIN  
  one jmpbuf size for all NT386 configurations (NT386, NT386GNU, NT386MINGNU) 
 
Built with Visual C++ 9.0 Express, so you'll want:
http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en 
 
 
Still more work to do though, e.g. assertion failures in unit tests, pixmap..
 
Fuller disclosure:
Something is leaking memory on my system such that "everything" starts "failing" and I have to reboot.
This isn't Modula-3 related.
Hopefully these files aren't damaged as a result.
Must be some buggy driver or something..
 
Aside:
 The environment variable thingy has been bugging me a long time and I finally looked deeper at it.
It appears broken in CM3 4.x. I didn't check 3.x yet.
I'm still mulling a fix, and haven't run a repro of the break, but it's not a big deal either way.
Basically console apps use main that takes char** and gui apps use WinMain that doesn't get environment variables but the generated code calls GetEvironmentStrings() which returns null separated strings.
Must be that hardly anyone uses environment variables in Modula-3 on Win32 for this to have lingered so long, at least gui apps.
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Fri May  9 07:43:08 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 9 May 2008 05:43:08 +0000
Subject: [M3devel] consoles appearing in gui apps (was pixmap...)
In-Reply-To: <481F9804.1E75.00D7.1@scires.com>
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	 
	<481F9804.1E75.00D7.1@scires.com>   
Message-ID: 

  > The bad news is that now I am getting a command window
  > opening up in addition to the GUI window when the program runs. 
  > This behavior does not occur on v4.1.  
 
Randy I've experimented with -gui. Just a few minutes, but I've covered all of the ground I can think of, except I only used -gui and not an m3makefile.
>From what I see, it all works as it should.
 
Here is my little program:
 
C:\dev2\j\m3\3>type Main.m3MODULE Main;IMPORT IO;IMPORT WinBase;
BEGIN  (* IO.Put("Hello\n"); *)  WinBase.Sleep(10000); (* 10 seconds *)
IF I uncomment out the IO.Put, and use -gui, then there is a "popup", and hello is printed there.
If I don't have the IO.Put however, no popup.
 
Is anything appearing in your console window? Or it is just empty?
Are you maybe running processes from your app? Or running them from Explorer?
I am running just one Modula-3 test app, from cmd.
 
It is possible that 4.1 does not bring up a console if you use stdout/stderr?
There is specific code in the current code to do this.
I don't have 4.1 handy..ok, I have 3.6.
 
This appears to have been a deliberate change.
 
 3.6
C:\net\modula3\m3\libm3\src\os\WIN32\ProcessWin32.m3(185):PROCEDURE GetFileHandle(hd: WinDef.DWORD; ds: FileWin32.DirectionSet): File.T =
PROCEDURE GetFileHandle(hd: WinDef.DWORD; ds: FileWin32.DirectionSet): File.T =  VAR h := WinBase.GetStdHandle(hd);  BEGIN    IF (h = NIL)      OR (h = LOOPHOLE (WinBase.INVALID_HANDLE_VALUE, WinDef.HANDLE)) THEN      RETURN NIL;    END;    TRY RETURN FileWin32.New(h, ds)    EXCEPT OSError.E => (* not available *)    END;    RETURN NIL;  END GetFileHandle;
 
vs.
 
current
 
C:\dev2\cm3\m3-libs\libm3\src\os\WIN32\ProcessWin32.m3(231):PROCEDURE GetFileHandle(hd: WinDef.DWORD; ds: FileWin32.DirectionSet): File.T =
PROCEDURE GetFileHandle(hd: WinDef.DWORD; ds: FileWin32.DirectionSet): File.T =  VAR h := WinBase.GetStdHandle(hd);  BEGIN    IF (h # NIL)      AND (h # LOOPHOLE (WinBase.INVALID_HANDLE_VALUE, WinDef.HANDLE)) THEN      TRY RETURN FileWin32.New(h, ds)      EXCEPT OSError.E => (* not available *)      END;    END;    (* if we can't get the standard handles, we might be a GUI program       so we'll lazily allocate a console if needed. *)    RETURN LazyConsole.New (hd, ds);  END GetFileHandle;
 
 
Ok, this change came in in the upgrade from Critical Mass 4.1 to 5.1.
4.1 being as I understand the actual one and only commercial release.
5.1 I guess being the then current but unreleated Critical Mass tree.
 
http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/WIN32/ProcessWin32.m3.diff?r1=1.1.1.1;r2=1.1.1.2;f=u
 
Please advise.
 
Also, to double check that things are working, run link -dump -headers foo.exe | findstr /i "subsystem entry"
 
GUI apps should show:
 
C:\dev2\j\m3\3>link -dump -headers NT386\prog.exe | findstr /i "subsystem entry"
            1C60 entry point (00401C60) _WinMainCRTStartup               2 subsystem (Windows GUI)
 
console apps should show:
 
C:\dev2\j\m3\3>link -dump -headers NT386\prog.exe | findstr /i "subsystem entry"
            1BE1 entry point (00401BE1) _mainCRTStartup               3 subsystem (Windows CUI)
C for console/commandline, G for gui/graphical.
 
If that is not what you are seeing, let's delve into that.
If my test program always brings up a popup, when compiled with -gui, with the IO.Put commented out, let's delve into that.
If your console is empty, let's look into that.
If you console has output in it, well, I'm inclined to say you are seeing improved correct behavior, but we can debate it, I guess.
 
 - Jay


From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: FW: [M3devel] pixmap problemDate: Thu, 8 May 2008 19:21:49 +0000


truncated again...


From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problemDate: Thu, 8 May 2008 18:57:08 +0000

Randy, At first very quick glance, this stuff looks ok.CM3-IDE probably doesn't really understand the config file, similar to m3cgcat's partial misunderstanding.  (Which is why I keep TARGET declared in NT386* instead of just NT386.common.)PKG_USE is defined I think, but it takes a really accurate understanding of Quake to get it. The entry/subsystem stuff also seems complete but I didn't try examples yet.Sorry, didn't give this all much time yet.I did get me to look at the environment variable bug that's been sitting there forever, with a bogus fix.. Can CM3-IDE default PKG_USE to CM3_ROOT + "/pkg"? Or INSTALL_ROOT + "/pkg"? Or whatever?That is what it always is, in anything that is checked in or that cminstall will give you.It takes hand editing of cm3.cfg to get anything else I think. Or CM3-IDE users can just edit the file some. Not a lot. But some.Given an incomplete understanding of the config files, probably putting in CM3-IDE wants but under if FALSE will perhaps work.Personally I wasn't impressed with Reactor... VC5 find-in-files gets me all I need. Anything besides plain text search doesn't scale..  - Jay


From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problemDate: Tue, 6 May 2008 03:38:03 +0000

Randy, don't worry.Two of these problems are trivial to fix -- PKG_USE and popups.The pixmap one will need debugging.  - Jay


Date: Mon, 5 May 2008 23:28:10 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad news is that now I am getting a command window opening up in addition to the GUI window when the program runs.  This behavior does not occur on v4.1.  The command window seems to be the stdout/stderr of the GUI program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy>>> Jay  5/5/2008 10:47 PM >>>Randy, Yes.The NT386 config files are all checked in.You can use them verbatim. You don't need cminstall, I never use it, and you shouldn't need to edit the config files at all, any edits I make, I check in, and should be usable on all machines.As long as you set %PATH%/%INCLUDE%/%LIB%.If I'm wrong, I'd like to know why and try to fix. Consider the config files just part of cm3.exe.Not generally to be changed locally. Unless, well, unless you intend to, and you should strive to make one form that is usable by all.  - Jay


Date: Mon, 5 May 2008 22:42:30 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay,
When you say "took the updated config file", what do you mean?  Are you saying I need a different cm3.cfg file?
Regards,
Randy>>> Jay  5/5/2008 9:54 PM >>>And you took the updated config file?The way you can tell is that, roughly speaking, hand.obj should be in NT386\_m3responsefile0.txt.Or _m3responsefile1.txt, or, well, somewhere.Anyway, I think I saw the attachment, I can check later..and with 4.1 as I said.. I can see about making the fix not depend on config file changes...but it's not terrible asis, and I'd really like to merge more of the quake code into cm3.exe..  - Jay


Date: Mon, 5 May 2008 21:18:12 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem
Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly when the buildstandalone() directive is used.
 
Regards,
Randy>>> Jay  5/5/2008 7:04 PM >>>Thanks. I'll look into this tonight probably, as well as with 4.1 assuming I can find my binaries and source for it (probably).COULD BE the pixmap problem is something else and 4.1 also has the problem I fixed. We'll see. No need to speculate (unless I can't find my 4.1). - Jay


Date: Mon, 5 May 2008 10:59:27 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problem
Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy>>> Jay  5/4/2008 11:46 AM >>>Randy, Please try with /current/ source, as of this morning Sunday May 4 -- the changes are ALL in NT386.common, so you MUST use MY config files, which are checked in verbatim, or you should be able edit whatever config files you are using. (It's not really a config file issue, don't blame the general confusion people have with them.) I'll try to try later, but I don't have the source right now, gotta look on other machines, and I think it's on a machine on loan.  Or send it to me again.I'd also like to know if this worked with 4.1, or with any release that offered dynamic linking to m3core.dll, on Windows.  I recall a claim that it did. If today's change fixes it, I should be able to investigate 4.1.3.6 did not have such linking.If today's change does not help, well, I still plan on debugging it at some point.. If you aren't current and getting so is difficult, just send the attachment again, it's easy for me to test. Thanks, - Jay


From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rcoleburn at scires.comDate: Sat, 19 Jan 2008 08:52:08 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.I was going to try on PPC_DARWIN but I guess Tony's info suffices. I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. Debugging here is a big humungous pain.NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)And bundles look pretty simple, a bundle is just a generated source file with a constant in it.Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something. The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for? I have to say this is very surprising. I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so.The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: pointer to msvcrt!fopenpointer to msvcrt!fclosenullpointer to kernel32!Sleep But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo.But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo.That doesn't work for data though. There's no ability to intervenve like that.So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it.And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.However that would suck perf in order to make an uncommon case work.I hope Modula-3 doesn't do that either. :)Though I guess since this global data in question...maybe it is rare??? Later, - Jay

> From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 03:09:47 -0500> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] pixmap problem> > Looks fine to me on I386_DARWIN.> > On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:> > > > 

Need to know the score, the latest news, or you need your Hotmail?-get your "fix" Check it out. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Fri May  9 09:44:09 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 9 May 2008 07:44:09 +0000
Subject: [M3devel] NT386 environment variables (new NT386 snapshots)
In-Reply-To: <4823279D.1E75.00D7.1@scires.com>
References: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
	 
	<4823279D.1E75.00D7.1@scires.com>
Message-ID: 

 > these problems (pixmaps, buildstandalone, environ vars, serial i/o, etc...
 
 Ok, here is the story with environment variables.
I tested 3.6 and current, gui and console.
This is the program:
C:\dev2\j\m3\3>type src\m3makefile
import ("m3core")import ("libm3")m3_option ("-gui")     twiddle this line in and out with a commentimplementation ("Main")program ("pgm")
 
C:\dev2\j\m3\3>type src\Main.m3
MODULE Main;IMPORT IO;IMPORT RTArgs;
 
BEGIN
(* IO.Put just crashes in 3.6 gui apps *)  IO.Put(RTArgs.GetArg(2));  IO.Put(RTArgs.GetEnv(2));
 
(* use this for gui apps *)  EVAL RTArgs.GetArg(2);  EVAL RTArgs.GetEnv(2);END Main.
In 3.6 console apps, RTArgs.GetEnv returns garbage. That makes sense from the code.
In current console apps, GetEnv works.In current gui apps, GetEnv access violates, or returns an invalid pointer.  This also makes sense from the code.
Randy, does this actually work for you?I'd be quite surprised.I haven't tried 4.1 yet, just 3.6 and current.
I will apply an easy fix.
 - Jay


Date: Thu, 8 May 2008 16:17:37 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] new NT386 snapshots

Jay:
 
I have both console and gui programs built using 4.1 that do pull stuff out of the environment.  I've not noticed any problems with either mode.
 
>From my perspective, the old 4.1 seems more reliable than the current system in a number of respects.  I have a new project with a hard deadline that I would like to use the new cm3 system for, but until these problems (pixmaps, buildstandalone, environ vars, serial i/o, etc.) can be resolved, I'm going to keep using 4.1 for my production work.
 
Regards,
Randy>>> Jay  5/8/2008 2:46 PM >>>http://modula3.elegosoft.com/cm3/uploaded-archives/ http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0.ziphttp://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-WIN32-NT386-d5.7.0.ziphttp://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0-symbols.zip These should have:  latest quake extensions   set relation fixes   other set fixes revealed through dynamic linking of one regression test   hypothetical ability to cross-build to AMD64_LINUX, AMD64_DARWIN    one jmpbuf size for all NT386 configurations (NT386, NT386GNU, NT386MINGNU)  Built with Visual C++ 9.0 Express, so you'll want:http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en  Still more work to do though, e.g. assertion failures in unit tests, pixmap.. Fuller disclosure:Something is leaking memory on my system such that "everything" starts "failing" and I have to reboot.This isn't Modula-3 related.Hopefully these files aren't damaged as a result.Must be some buggy driver or something.. Aside: The environment variable thingy has been bugging me a long time and I finally looked deeper at it.It appears broken in CM3 4.x. I didn't check 3.x yet.I'm still mulling a fix, and haven't run a repro of the break, but it's not a big deal either way.Basically console apps use main that takes char** and gui apps use WinMain that doesn't get environment variables but the generated code calls GetEvironmentStrings() which returns null separated strings.Must be that hardly anyone uses environment variables in Modula-3 on Win32 for this to have lingered so long, at least gui apps.  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Fri May  9 10:19:33 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 9 May 2008 08:19:33 +0000
Subject: [M3devel] FW:  NT386 environment variables (new NT386 snapshots)
In-Reply-To: <4823279D.1E75.00D7.1@scires.com>
References: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
	 
	<4823279D.1E75.00D7.1@scires.com> 
Message-ID: 

truncated again...
m3support -- nothing interesting in any logs regarding my mail?
And nobody else uses hotmail, right?
 
> I will apply an easy fix.
done


From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] NT386 environment variables (new NT386 snapshots)Date: Fri, 9 May 2008 07:44:09 +0000


 > these problems (pixmaps, buildstandalone, environ vars, serial i/o, etc...  Ok, here is the story with environment variables.I tested 3.6 and current, gui and console.This is the program:C:\dev2\j\m3\3>type src\m3makefileimport ("m3core")import ("libm3")m3_option ("-gui")     twiddle this line in and out with a commentimplementation ("Main")program ("pgm") C:\dev2\j\m3\3>type src\Main.m3MODULE Main;IMPORT IO;IMPORT RTArgs; BEGIN(* IO.Put just crashes in 3.6 gui apps *)  IO.Put(RTArgs.GetArg(2));  IO.Put(RTArgs.GetEnv(2)); (* use this for gui apps *)  EVAL RTArgs.GetArg(2);  EVAL RTArgs.GetEnv(2);END Main.In 3.6 console apps, RTArgs.GetEnv returns garbage. That makes sense from the code.In current console apps, GetEnv works.In current gui apps, GetEnv access violates, or returns an invalid pointer.  This also makes sense from the code.Randy, does this actually work for you?I'd be quite surprised.I haven't tried 4.1 yet, just 3.6 and current.I will apply an easy fix. - Jay


Date: Thu, 8 May 2008 16:17:37 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] new NT386 snapshots
Jay:
 
I have both console and gui programs built using 4.1 that do pull stuff out of the environment.  I've not noticed any problems with either mode.
 
>From my perspective, the old 4.1 seems more reliable than the current system in a number of respects.  I have a new project with a hard deadline that I would like to use the new cm3 system for, but until these problems (pixmaps, buildstandalone, environ vars, serial i/o, etc.) can be resolved, I'm going to keep using 4.1 for my production work.
 
Regards,
Randy>>> Jay  5/8/2008 2:46 PM >>>http://modula3.elegosoft.com/cm3/uploaded-archives/ http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0.ziphttp://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-WIN32-NT386-d5.7.0.ziphttp://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0-symbols.zip These should have:  latest quake extensions   set relation fixes   other set fixes revealed through dynamic linking of one regression test   hypothetical ability to cross-build to AMD64_LINUX, AMD64_DARWIN    one jmpbuf size for all NT386 configurations (NT386, NT386GNU, NT386MINGNU)  Built with Visual C++ 9.0 Express, so you'll want:http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en  Still more work to do though, e.g. assertion failures in unit tests, pixmap.. Fuller disclosure:Something is leaking memory on my system such that "everything" starts "failing" and I have to reboot.This isn't Modula-3 related.Hopefully these files aren't damaged as a result.Must be some buggy driver or something.. Aside: The environment variable thingy has been bugging me a long time and I finally looked deeper at it.It appears broken in CM3 4.x. I didn't check 3.x yet.I'm still mulling a fix, and haven't run a repro of the break, but it's not a big deal either way.Basically console apps use main that takes char** and gui apps use WinMain that doesn't get environment variables but the generated code calls GetEvironmentStrings() which returns null separated strings.Must be that hardly anyone uses environment variables in Modula-3 on Win32 for this to have lingered so long, at least gui apps.  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Fri May  9 11:10:36 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 9 May 2008 09:10:36 +0000
Subject: [M3devel] pixmap problem
In-Reply-To: <481F9804.1E75.00D7.1@scires.com>
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	 
	<481F9804.1E75.00D7.1@scires.com>
Message-ID: 

 > Also, more bad news, the pixmap problem is not solved.
 
Randy, this DOES actually fix it, but you have to rebuild more.
 
Try:
   cd scripts\python  
  .\do-cm3-std.py realclean  
  .\upgrade.py   (probably not needed) 
   do-cm3-std.py buildship  
 
Make sure "hand.obj" occurs in the various NT386\foo.lst files.
 
I think the fix should be restated to have the code reference *__imp__highbits instead of highbits, and go back to dynamic linking the data.
But ok for now.
 
The std distribution I put yesterday should work, though it is missing the RTArgs fix.
I'll see about making another.
 
  - Jay


Date: Mon, 5 May 2008 23:28:10 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem

Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad news is that now I am getting a command window opening up in addition to the GUI window when the program runs.  This behavior does not occur on v4.1.  The command window seems to be the stdout/stderr of the GUI program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy>>> Jay  5/5/2008 10:47 PM >>>Randy, Yes.The NT386 config files are all checked in.You can use them verbatim. You don't need cminstall, I never use it, and you shouldn't need to edit the config files at all, any edits I make, I check in, and should be usable on all machines.As long as you set %PATH%/%INCLUDE%/%LIB%.If I'm wrong, I'd like to know why and try to fix. Consider the config files just part of cm3.exe.Not generally to be changed locally. Unless, well, unless you intend to, and you should strive to make one form that is usable by all.  - Jay


Date: Mon, 5 May 2008 22:42:30 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay,
When you say "took the updated config file", what do you mean?  Are you saying I need a different cm3.cfg file?
Regards,
Randy>>> Jay  5/5/2008 9:54 PM >>>And you took the updated config file?The way you can tell is that, roughly speaking, hand.obj should be in NT386\_m3responsefile0.txt.Or _m3responsefile1.txt, or, well, somewhere.Anyway, I think I saw the attachment, I can check later..and with 4.1 as I said.. I can see about making the fix not depend on config file changes...but it's not terrible asis, and I'd really like to merge more of the quake code into cm3.exe..  - Jay


Date: Mon, 5 May 2008 21:18:12 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem
Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly when the buildstandalone() directive is used.
 
Regards,
Randy>>> Jay  5/5/2008 7:04 PM >>>Thanks. I'll look into this tonight probably, as well as with 4.1 assuming I can find my binaries and source for it (probably).COULD BE the pixmap problem is something else and 4.1 also has the problem I fixed. We'll see. No need to speculate (unless I can't find my 4.1). - Jay


Date: Mon, 5 May 2008 10:59:27 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problem
Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy>>> Jay  5/4/2008 11:46 AM >>>Randy, Please try with /current/ source, as of this morning Sunday May 4 -- the changes are ALL in NT386.common, so you MUST use MY config files, which are checked in verbatim, or you should be able edit whatever config files you are using. (It's not really a config file issue, don't blame the general confusion people have with them.) I'll try to try later, but I don't have the source right now, gotta look on other machines, and I think it's on a machine on loan.  Or send it to me again.I'd also like to know if this worked with 4.1, or with any release that offered dynamic linking to m3core.dll, on Windows.  I recall a claim that it did. If today's change fixes it, I should be able to investigate 4.1.3.6 did not have such linking.If today's change does not help, well, I still plan on debugging it at some point.. If you aren't current and getting so is difficult, just send the attachment again, it's easy for me to test. Thanks, - Jay


From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rcoleburn at scires.comDate: Sat, 19 Jan 2008 08:52:08 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.I was going to try on PPC_DARWIN but I guess Tony's info suffices. I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. Debugging here is a big humungous pain.NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)And bundles look pretty simple, a bundle is just a generated source file with a constant in it.Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something. The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for? I have to say this is very surprising. I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so.The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: pointer to msvcrt!fopenpointer to msvcrt!fclosenullpointer to kernel32!Sleep But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo.But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo.That doesn't work for data though. There's no ability to intervenve like that.So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it.And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.However that would suck perf in order to make an uncommon case work.I hope Modula-3 doesn't do that either. :)Though I guess since this global data in question...maybe it is rare??? Later, - Jay

> From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 03:09:47 -0500> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] pixmap problem> > Looks fine to me on I386_DARWIN.> > On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:> > > > 

Need to know the score, the latest news, or you need your Hotmail?-get your "fix" Check it out. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Sat May 10 10:31:04 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Sat, 10 May 2008 04:31:04 -0400
Subject: [M3devel] consoles appearing in gui apps (was pixmap...)
In-Reply-To: 
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	
	<481F9804.1E75.00D7.1@scires.com> <481F9804.1E75.00D7.1@scires.com>
	
Message-ID: <48252503.1E75.00D7.1@scires.com>

Jay:
 
Here are my results using your test program.  In all cases I have
created a desktop shortcut to the EXE and double-click this shortcut to
start the program:
 
1.  cm3 v4.1, VS 2005, with IO.Put commented out, no pop-up.
 
2.  cm3 v4.1, VS 2005, using IO.Put, I have to put "@M3novm" on command
line, but then get a pop-up showing a crash "runtime error, illegal
memory access, LockMutexx in ThreadWin32.m3"
 
3.  cm3 v.d5.7.0, VS 2008, with IO.Put commented out, no pop-up
 
4.  cm3 v.d5.7.0, VS 2008, using IO.Put, I get a pop-up window with the
word "Hello".
 
Also, I checked the "link dump" for GUI vs. CUI on both versions and it
appears to be working correctly.
 
Regards,
Randy

>>> Jay  5/9/2008 1:43 AM >>>
  > The bad news is that now I am getting a command window
  > opening up in addition to the GUI window when the program runs. 
  > This behavior does not occur on v4.1.  
 
Randy I've experimented with -gui. Just a few minutes, but I've covered
all of the ground I can think of, except I only used -gui and not an
m3makefile.
>From what I see, it all works as it should.
 
Here is my little program:
 
C:\dev2\j\m3\3>type Main.m3
MODULE Main;
IMPORT IO;
IMPORT WinBase;
BEGIN
  (* IO.Put("Hello\n"); *)
  WinBase.Sleep(10000); (* 10 seconds *)


IF I uncomment out the IO.Put, and use -gui, then there is a "popup",
and hello is printed there.
If I don't have the IO.Put however, no popup.
 
Is anything appearing in your console window? Or it is just empty?
Are you maybe running processes from your app? Or running them from
Explorer?
I am running just one Modula-3 test app, from cmd.
 
It is possible that 4.1 does not bring up a console if you use
stdout/stderr?
There is specific code in the current code to do this.
I don't have 4.1 handy..ok, I have 3.6.
 
This appears to have been a deliberate change.
 
 3.6
C:\net\modula3\m3\libm3\src\os\WIN32\ProcessWin32.m3(185):PROCEDURE
GetFileHandle(hd: WinDef.DWORD; ds: FileWin32.DirectionSet): File.T =

PROCEDURE GetFileHandle(hd: WinDef.DWORD; ds: FileWin32.DirectionSet):
File.T =
  VAR h := WinBase.GetStdHandle(hd);
  BEGIN
    IF (h = NIL)
      OR (h = LOOPHOLE (WinBase.INVALID_HANDLE_VALUE, WinDef.HANDLE))
THEN
      RETURN NIL;
    END;
    TRY RETURN FileWin32.New(h, ds)
    EXCEPT OSError.E => (* not available *)
    END;
    RETURN NIL;
  END GetFileHandle;

 
vs.
 
current
 
C:\dev2\cm3\m3-libs\libm3\src\os\WIN32\ProcessWin32.m3(231):PROCEDURE
GetFileHandle(hd: WinDef.DWORD; ds: FileWin32.DirectionSet): File.T =

PROCEDURE GetFileHandle(hd: WinDef.DWORD; ds: FileWin32.DirectionSet):
File.T =
  VAR h := WinBase.GetStdHandle(hd);
  BEGIN
    IF (h # NIL)
      AND (h # LOOPHOLE (WinBase.INVALID_HANDLE_VALUE, WinDef.HANDLE))
THEN
      TRY RETURN FileWin32.New(h, ds)
      EXCEPT OSError.E => (* not available *)
      END;
    END;
    (* if we can't get the standard handles, we might be a GUI program
       so we'll lazily allocate a console if needed. *)
    RETURN LazyConsole.New (hd, ds);
  END GetFileHandle;
 
 
Ok, this change came in in the upgrade from Critical Mass 4.1 to 5.1.
4.1 being as I understand the actual one and only commercial release.
5.1 I guess being the then current but unreleated Critical Mass tree.
 
http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/WIN32/ProcessWin32.m3.diff?r1=1.1.1.1;r2=1.1.1.2;f=u

 
Please advise.
 
Also, to double check that things are working, run link -dump -headers
foo.exe | findstr /i "subsystem entry"
 
GUI apps should show:
 

C:\dev2\j\m3\3>link -dump -headers NT386\prog.exe | findstr /i
"subsystem entry"
            1C60 entry point (00401C60) _WinMainCRTStartup
               2 subsystem (Windows GUI)
 
console apps should show:
 
C:\dev2\j\m3\3>link -dump -headers NT386\prog.exe | findstr /i
"subsystem entry"
            1BE1 entry point (00401BE1) _mainCRTStartup
               3 subsystem (Windows CUI)

C for console/commandline, G for gui/graphical.
 
If that is not what you are seeing, let's delve into that.
If my test program always brings up a popup, when compiled with -gui,
with the IO.Put commented out, let's delve into that.
If your console is empty, let's look into that.
If you console has output in it, well, I'm inclined to say you are
seeing improved correct behavior, but we can debate it, I guess.
 
 - Jay

From: jayk123 at hotmail.com 
To: rcoleburn at scires.com; m3devel at elegosoft.com 
Subject: FW: [M3devel] pixmap problem
Date: Thu, 8 May 2008 19:21:49 +0000

truncated again...




From: jayk123 at hotmail.com 
To: rcoleburn at scires.com; m3devel at elegosoft.com 
Subject: RE: [M3devel] pixmap problem
Date: Thu, 8 May 2008 18:57:08 +0000

Randy, At first very quick glance, this stuff looks ok.
CM3-IDE probably doesn't really understand the config file, similar to
m3cgcat's partial misunderstanding.
  (Which is why I keep TARGET declared in NT386* instead of just
NT386.common.)
PKG_USE is defined I think, but it takes a really accurate
understanding of Quake to get it.
 
The entry/subsystem stuff also seems complete but I didn't try examples
yet.
Sorry, didn't give this all much time yet.
I did get me to look at the environment variable bug that's been
sitting there forever, with a bogus fix..
 
Can CM3-IDE default PKG_USE to CM3_ROOT + "/pkg"? Or INSTALL_ROOT +
"/pkg"? Or whatever?
That is what it always is, in anything that is checked in or that
cminstall will give you.
It takes hand editing of cm3.cfg to get anything else I think.
 
Or CM3-IDE users can just edit the file some. Not a lot. But some.
Given an incomplete understanding of the config files, probably putting
in CM3-IDE wants but under if FALSE will perhaps work.
Personally I wasn't impressed with Reactor... VC5 find-in-files gets me
all I need. Anything besides plain text search doesn't scale..
 
 - Jay
From: jayk123 at hotmail.com 
To: rcoleburn at scires.com; m3devel at elegosoft.com 
Subject: RE: [M3devel] pixmap problem
Date: Tue, 6 May 2008 03:38:03 +0000

Randy, don't worry.
Two of these problems are trivial to fix -- PKG_USE and popups.
The pixmap one will need debugging.
 
 - Jay

Date: Mon, 5 May 2008 23:28:10 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com; jayk123 at hotmail.com 
Subject: RE: [M3devel] pixmap problem

Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've
copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad
news is that now I am getting a command window opening up in addition to
the GUI window when the program runs.  This behavior does not occur on
v4.1.  The command window seems to be the stdout/stderr of the GUI
program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which
needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy

>>> Jay  5/5/2008 10:47 PM >>>
Randy, Yes.
The NT386 config files are all checked in.
You can use them verbatim. You don't need cminstall, I never use it,
and you shouldn't need to edit the config files at all, any edits I
make, I check in, and should be usable on all machines.
As long as you set %PATH%/%INCLUDE%/%LIB%.
If I'm wrong, I'd like to know why and try to fix.
 
Consider the config files just part of cm3.exe.
Not generally to be changed locally. Unless, well, unless you intend
to, and you should strive to make one form that is usable by all.
 
 - Jay


Date: Mon, 5 May 2008 22:42:30 -0400
From: rcoleburn at scires.com 
To: jayk123 at hotmail.com 
Subject: RE: [M3devel] pixmap problem

Jay,
When you say "took the updated config file", what do you mean?  Are you
saying I need a different cm3.cfg file?
Regards,
Randy

>>> Jay  5/5/2008 9:54 PM >>>
And you took the updated config file?
The way you can tell is that, roughly speaking, hand.obj should be in
NT386\_m3responsefile0.txt.
Or _m3responsefile1.txt, or, well, somewhere.
Anyway, I think I saw the attachment, I can check later..and with 4.1
as I said..
 
I can see about making the fix not depend on config file changes...but
it's not terrible asis, and I'd really like to merge more of the quake
code into cm3.exe..
 
 - Jay

Date: Mon, 5 May 2008 21:18:12 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com 
Subject: Re: [M3devel] pixmap problem

Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly
when the buildstandalone() directive is used.
 
Regards,
Randy

>>> Jay  5/5/2008 7:04 PM >>>
Thanks. I'll look into this tonight probably, as well as with 4.1
assuming I can find my binaries and source for it (probably).

COULD BE the pixmap problem is something else and 4.1 also has the
problem I fixed. We'll see. No need to speculate (unless I can't find my
4.1).

 - Jay


Date: Mon, 5 May 2008 10:59:27 -0400
From: rcoleburn at scires.com 
To: jayk123 at hotmail.com 
CC: m3devel at elegosoft.com 
Subject: RE: [M3devel] pixmap problem

Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files
or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy

>>> Jay  5/4/2008 11:46 AM >>>
Randy, Please try with /current/ source, as of this morning Sunday May
4 -- the changes are ALL in NT386.common, so you MUST use MY config
files, which are checked in verbatim, or you should be able edit
whatever config files you are using.
 
(It's not really a config file issue, don't blame the general confusion
people have with them.)
 
I'll try to try later, but I don't have the source right now, gotta
look on other machines, and I think it's on a machine on loan.
  Or send it to me again.
I'd also like to know if this worked with 4.1, or with any release that
offered dynamic linking to m3core.dll, on Windows.
  I recall a claim that it did. If today's change fixes it, I should be
able to investigate 4.1.
3.6 did not have such linking.
If today's change does not help, well, I still plan on debugging it at
some point..
 
If you aren't current and getting so is difficult, just send the
attachment again, it's easy for me to test.
 
Thanks,
 - Jay

From: jayk123 at hotmail.com 
To: hosking at cs.purdue.edu; rcoleburn at scires.com 
Date: Sat, 19 Jan 2008 08:52:08 +0000
CC: m3devel at elegosoft.com 
Subject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.
I was going to try on PPC_DARWIN but I guess Tony's info suffices.
 
I tried rolling hand.c back to before I changed (months/year ago),
since it is involved in bit twiddling, no change, phew.
 
Debugging here is a big humungous pain.
NT386 has good stacks and line numbers, but no locals or type info, I'd
really sometime like to get Codeview info into those .objs...I think it
is documented well enough, but still not necessarily easy, or maybe have
a C generating backend partly for this reason (and to bring up more
targets, using native tools), and function calls in disassembly I think
don't resolve; NT386GNU can't yet build this, though it will soon, but
I'm not familiar with gdb and there appears to be no type info. I'm
building m3gdb right now, I don't know if it will work, I hope it has
type info, and I'm not familiar with the relevant code. In gdb I
struggle just to view bytes in memory, add numbers to addresses and see
those, etc. I think for MY problem, I'm going to link in C code to dump
the structs. There is tracing code and I enabled it, but even it crashes
in Text_Length. At least MY problem crashes, hopefully near the problem,
whereas your problem goes all the way through to completion with no
stopping to hint where the problem is. Darn it. :) on the mock rudeness
and :( on the lack of a crash.
 
You write the bundle out and it matches, so that doesn't rule out
bundles as being the problem? (darn)
And bundles look pretty simple, a bundle is just a generated source
file with a constant in it.
Maybe newline problems? That wouldn't make sense. I just downloaded
some program that might let me separately view the ppm, maybe it'll
reveal something.
 
The bad behavior has like regularly spaced solid color veritical bars a
few pixels side across the whole picture, and regularly spaced vertical
stripes from the correct picture alternating with that. Perhaps someone
with ppm/bitmap/graphics experience has seen this behavior and it
results from some common pixmap mismanagement we could look for?
 
I have to say this is very surprising.
 
I always wondered, and now I pretty much assume -- Modula-3 never
imports/exports data in its dynamic linking, right? It alway
imports/exports functions, right?
On Windows, functions have an optional optimization, but data must be
handled differently at compile time if it is going to be dynamically
imported.
For functions, if you don't apply the optimization at compile time, the
linker will just generate a single instruction thunk instead.
 
That is, given a symbol Foo, there is a symbol __imp__Foo that is a
pointer to the actual foo in another .dll/.so.
The loader only patches pointers, one per import if you build your .dll
correctly, it doesn't patch instructions or code strewn throughout a
.dll, just one contiguous array of pointers. MAYBE they don't have to be
contiguous for each .dl you import from.
 
That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my
.dll/.exe typically has an array:
 
pointer to msvcrt!fopen
pointer to msvcrt!fclose
null
pointer to kernel32!Sleep
 
But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not
be adjacent.
 
So, going back, my point/question is that, if the compiler knows the
function is imported, it can call through __imp__Foo instead of calling
Foo.
But if it calls Foo and you import Foo, the linker will create the
function Foo that just jmps through __imp__Foo.
That doesn't work for data though. There's no ability to intervenve
like that.
So for imported data, the compiler must generated a read and
dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to
be imported.
Data imports may be faster when appropriate, but for this reason, I'd
say they aren't worth it.
And for this reason, I HOPE Modula-3 never imports/exports data.
 
Oh, you could, for data, always reference the pointer __imp_Foo, and if
non materializes, create one.
However that would suck perf in order to make an uncommon case work.
I hope Modula-3 doesn't do that either. :)
Though I guess since this global data in question...maybe it is
rare???
 
Later,
 - Jay



> From: hosking at cs.purdue.edu 
> Date: Sat, 19 Jan 2008 03:09:47 -0500
> To: rcoleburn at scires.com 
> CC: m3devel at elegosoft.com 
> Subject: Re: [M3devel] pixmap problem
> 
> Looks fine to me on I386_DARWIN.
> 
> On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:
> 
> > 
> 


Need to know the score, the latest news, or you need your Hotmail*-get
your "fix" Check it out. ( http://www.msnmobilefix.com/Default.aspx ) 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Sat May 10 10:51:23 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Sat, 10 May 2008 04:51:23 -0400
Subject: [M3devel] pixmap problem
In-Reply-To: 
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	
	<481F9804.1E75.00D7.1@scires.com><481F9804.1E75.00D7.1@scires.com>
	
Message-ID: <482529C7.1E75.00D7.1@scires.com>

Jay:
 
I do not have python installed on my computer, so I can't run your
scripts.
 
I used the scripts in scripts\win to upgrade a few days ago.
 
I am not seeing hand.obj in the .lst file.
 
I will do a CVS update and try the upgrade again followed by
do-cm3-standard.
 
Regards,
Randy

>>> Jay  5/9/2008 5:10 AM >>>
 > Also, more bad news, the pixmap problem is not solved.
 
Randy, this DOES actually fix it, but you have to rebuild more.
 
Try:
   cd scripts\python  
  .\do-cm3-std.py realclean  
  .\upgrade.py   (probably not needed) 
   do-cm3-std.py buildship  
 
Make sure "hand.obj" occurs in the various NT386\foo.lst files.
 
I think the fix should be restated to have the code reference
*__imp__highbits instead of highbits, and go back to dynamic linking the
data.
But ok for now.
 
The std distribution I put yesterday should work, though it is missing
the RTArgs fix.
I'll see about making another.
 
  - Jay

Date: Mon, 5 May 2008 23:28:10 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com; jayk123 at hotmail.com 
Subject: RE: [M3devel] pixmap problem

Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've
copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad
news is that now I am getting a command window opening up in addition to
the GUI window when the program runs.  This behavior does not occur on
v4.1.  The command window seems to be the stdout/stderr of the GUI
program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which
needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy

>>> Jay  5/5/2008 10:47 PM >>>
Randy, Yes.
The NT386 config files are all checked in.
You can use them verbatim. You don't need cminstall, I never use it,
and you shouldn't need to edit the config files at all, any edits I
make, I check in, and should be usable on all machines.
As long as you set %PATH%/%INCLUDE%/%LIB%.
If I'm wrong, I'd like to know why and try to fix.
 
Consider the config files just part of cm3.exe.
Not generally to be changed locally. Unless, well, unless you intend
to, and you should strive to make one form that is usable by all.
 
 - Jay


Date: Mon, 5 May 2008 22:42:30 -0400
From: rcoleburn at scires.com 
To: jayk123 at hotmail.com 
Subject: RE: [M3devel] pixmap problem

Jay,
When you say "took the updated config file", what do you mean?  Are you
saying I need a different cm3.cfg file?
Regards,
Randy

>>> Jay  5/5/2008 9:54 PM >>>
And you took the updated config file?
The way you can tell is that, roughly speaking, hand.obj should be in
NT386\_m3responsefile0.txt.
Or _m3responsefile1.txt, or, well, somewhere.
Anyway, I think I saw the attachment, I can check later..and with 4.1
as I said..
 
I can see about making the fix not depend on config file changes...but
it's not terrible asis, and I'd really like to merge more of the quake
code into cm3.exe..
 
 - Jay

Date: Mon, 5 May 2008 21:18:12 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com 
Subject: Re: [M3devel] pixmap problem

Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly
when the buildstandalone() directive is used.
 
Regards,
Randy

>>> Jay  5/5/2008 7:04 PM >>>
Thanks. I'll look into this tonight probably, as well as with 4.1
assuming I can find my binaries and source for it (probably).

COULD BE the pixmap problem is something else and 4.1 also has the
problem I fixed. We'll see. No need to speculate (unless I can't find my
4.1).

 - Jay


Date: Mon, 5 May 2008 10:59:27 -0400
From: rcoleburn at scires.com 
To: jayk123 at hotmail.com 
CC: m3devel at elegosoft.com 
Subject: RE: [M3devel] pixmap problem

Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files
or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy

>>> Jay  5/4/2008 11:46 AM >>>
Randy, Please try with /current/ source, as of this morning Sunday May
4 -- the changes are ALL in NT386.common, so you MUST use MY config
files, which are checked in verbatim, or you should be able edit
whatever config files you are using.
 
(It's not really a config file issue, don't blame the general confusion
people have with them.)
 
I'll try to try later, but I don't have the source right now, gotta
look on other machines, and I think it's on a machine on loan.
  Or send it to me again.
I'd also like to know if this worked with 4.1, or with any release that
offered dynamic linking to m3core.dll, on Windows.
  I recall a claim that it did. If today's change fixes it, I should be
able to investigate 4.1.
3.6 did not have such linking.
If today's change does not help, well, I still plan on debugging it at
some point..
 
If you aren't current and getting so is difficult, just send the
attachment again, it's easy for me to test.
 
Thanks,
 - Jay

From: jayk123 at hotmail.com 
To: hosking at cs.purdue.edu; rcoleburn at scires.com 
Date: Sat, 19 Jan 2008 08:52:08 +0000
CC: m3devel at elegosoft.com 
Subject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.
I was going to try on PPC_DARWIN but I guess Tony's info suffices.
 
I tried rolling hand.c back to before I changed (months/year ago),
since it is involved in bit twiddling, no change, phew.
 
Debugging here is a big humungous pain.
NT386 has good stacks and line numbers, but no locals or type info, I'd
really sometime like to get Codeview info into those .objs...I think it
is documented well enough, but still not necessarily easy, or maybe have
a C generating backend partly for this reason (and to bring up more
targets, using native tools), and function calls in disassembly I think
don't resolve; NT386GNU can't yet build this, though it will soon, but
I'm not familiar with gdb and there appears to be no type info. I'm
building m3gdb right now, I don't know if it will work, I hope it has
type info, and I'm not familiar with the relevant code. In gdb I
struggle just to view bytes in memory, add numbers to addresses and see
those, etc. I think for MY problem, I'm going to link in C code to dump
the structs. There is tracing code and I enabled it, but even it crashes
in Text_Length. At least MY problem crashes, hopefully near the problem,
whereas your problem goes all the way through to completion with no
stopping to hint where the problem is. Darn it. :) on the mock rudeness
and :( on the lack of a crash.
 
You write the bundle out and it matches, so that doesn't rule out
bundles as being the problem? (darn)
And bundles look pretty simple, a bundle is just a generated source
file with a constant in it.
Maybe newline problems? That wouldn't make sense. I just downloaded
some program that might let me separately view the ppm, maybe it'll
reveal something.
 
The bad behavior has like regularly spaced solid color veritical bars a
few pixels side across the whole picture, and regularly spaced vertical
stripes from the correct picture alternating with that. Perhaps someone
with ppm/bitmap/graphics experience has seen this behavior and it
results from some common pixmap mismanagement we could look for?
 
I have to say this is very surprising.
 
I always wondered, and now I pretty much assume -- Modula-3 never
imports/exports data in its dynamic linking, right? It alway
imports/exports functions, right?
On Windows, functions have an optional optimization, but data must be
handled differently at compile time if it is going to be dynamically
imported.
For functions, if you don't apply the optimization at compile time, the
linker will just generate a single instruction thunk instead.
 
That is, given a symbol Foo, there is a symbol __imp__Foo that is a
pointer to the actual foo in another .dll/.so.
The loader only patches pointers, one per import if you build your .dll
correctly, it doesn't patch instructions or code strewn throughout a
.dll, just one contiguous array of pointers. MAYBE they don't have to be
contiguous for each .dl you import from.
 
That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my
.dll/.exe typically has an array:
 
pointer to msvcrt!fopen
pointer to msvcrt!fclose
null
pointer to kernel32!Sleep
 
But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not
be adjacent.
 
So, going back, my point/question is that, if the compiler knows the
function is imported, it can call through __imp__Foo instead of calling
Foo.
But if it calls Foo and you import Foo, the linker will create the
function Foo that just jmps through __imp__Foo.
That doesn't work for data though. There's no ability to intervenve
like that.
So for imported data, the compiler must generated a read and
dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to
be imported.
Data imports may be faster when appropriate, but for this reason, I'd
say they aren't worth it.
And for this reason, I HOPE Modula-3 never imports/exports data.
 
Oh, you could, for data, always reference the pointer __imp_Foo, and if
non materializes, create one.
However that would suck perf in order to make an uncommon case work.
I hope Modula-3 doesn't do that either. :)
Though I guess since this global data in question...maybe it is
rare???
 
Later,
 - Jay



> From: hosking at cs.purdue.edu 
> Date: Sat, 19 Jan 2008 03:09:47 -0500
> To: rcoleburn at scires.com 
> CC: m3devel at elegosoft.com 
> Subject: Re: [M3devel] pixmap problem
> 
> Looks fine to me on I386_DARWIN.
> 
> On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:
> 
> > 
> 


Need to know the score, the latest news, or you need your Hotmail*-get
your "fix" Check it out. ( http://www.msnmobilefix.com/Default.aspx ) 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sat May 10 11:01:22 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 10 May 2008 09:01:22 +0000
Subject: [M3devel] consoles appearing in gui apps (was pixmap...)
In-Reply-To: <48252503.1E75.00D7.1@scires.com>
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	
	<481F9804.1E75.00D7.1@scires.com> <481F9804.1E75.00D7.1@scires.com>
	 
	<48252503.1E75.00D7.1@scires.com>
Message-ID: 

Randy, this is about what I expect. I only tried 3.6 so far; will try 4.1 later.
Are you satisfied now or not?
Or is your larger actual program showing a popup without output?
 
Or you want output to stderr/stdout in gui apps to just disappear as in 4.1?
 
There definitely is a change from 4.1, and it came in with the Critical Mass code in 5.1.
 
We could I guess put in an @M3 switch to either disappear stdout/stderr in gui apps, or specify a file or files for them to go to. We could also export a function that you'd call to change the global behavior. That's better. It wouldn't do anything on Unix (unless there is a way...?)
 
"Regular" C/C++ stdout/stderr in Windows gui apps does just disappear, but the Modula-3 libraries don't necessarily have to be "the same".
 
There isn't as far as I know an analog on Unix.
I think if you launch something from a typical gui (KDE Kicker, GNOME panels, etc.), stdout/stderr is lost.
If you launch from a console, it is not. I see quite a bit of stdout/stderr spew in gui apps like Kate, KDevelop, etc., seems like bugs (kind of like Windows's OutputDebugString?)
 
 - Jay


Date: Sat, 10 May 2008 04:31:04 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] consoles appearing in gui apps (was pixmap...)

Jay:
 
Here are my results using your test program.  In all cases I have created a desktop shortcut to the EXE and double-click this shortcut to start the program:
 
1.  cm3 v4.1, VS 2005, with IO.Put commented out, no pop-up.
 
2.  cm3 v4.1, VS 2005, using IO.Put, I have to put "@M3novm" on command line, but then get a pop-up showing a crash "runtime error, illegal memory access, LockMutexx in ThreadWin32.m3"
 
3.  cm3 v.d5.7.0, VS 2008, with IO.Put commented out, no pop-up
 
4.  cm3 v.d5.7.0, VS 2008, using IO.Put, I get a pop-up window with the word "Hello".
 
Also, I checked the "link dump" for GUI vs. CUI on both versions and it appears to be working correctly.
 
Regards,
Randy>>> Jay  5/9/2008 1:43 AM >>>  > The bad news is that now I am getting a command window  > opening up in addition to the GUI window when the program runs.   > This behavior does not occur on v4.1.   Randy I've experimented with -gui. Just a few minutes, but I've covered all of the ground I can think of, except I only used -gui and not an m3makefile.From what I see, it all works as it should. Here is my little program: C:\dev2\j\m3\3>type Main.m3MODULE Main;IMPORT IO;IMPORT WinBase;BEGIN  (* IO.Put("Hello\n"); *)  WinBase.Sleep(10000); (* 10 seconds *)IF I uncomment out the IO.Put, and use -gui, then there is a "popup", and hello is printed there.If I don't have the IO.Put however, no popup. Is anything appearing in your console window? Or it is just empty?Are you maybe running processes from your app? Or running them from Explorer?I am running just one Modula-3 test app, from cmd. It is possible that 4.1 does not bring up a console if you use stdout/stderr?There is specific code in the current code to do this.I don't have 4.1 handy..ok, I have 3.6. This appears to have been a deliberate change.  3.6C:\net\modula3\m3\libm3\src\os\WIN32\ProcessWin32.m3(185):PROCEDURE GetFileHandle(hd: WinDef.DWORD; ds: FileWin32.DirectionSet): File.T =PROCEDURE GetFileHandle(hd: WinDef.DWORD; ds: FileWin32.DirectionSet): File.T =  VAR h := WinBase.GetStdHandle(hd);  BEGIN    IF (h = NIL)      OR (h = LOOPHOLE (WinBase.INVALID_HANDLE_VALUE, WinDef.HANDLE)) THEN      RETURN NIL;    END;    TRY RETURN FileWin32.New(h, ds)    EXCEPT OSError.E => (* not available *)    END;    RETURN NIL;  END GetFileHandle; vs. current C:\dev2\cm3\m3-libs\libm3\src\os\WIN32\ProcessWin32.m3(231):PROCEDURE GetFileHandle(hd: WinDef.DWORD; ds: FileWin32.DirectionSet): File.T =PROCEDURE GetFileHandle(hd: WinDef.DWORD; ds: FileWin32.DirectionSet): File.T =  VAR h := WinBase.GetStdHandle(hd);  BEGIN    IF (h # NIL)      AND (h # LOOPHOLE (WinBase.INVALID_HANDLE_VALUE, WinDef.HANDLE)) THEN      TRY RETURN FileWin32.New(h, ds)      EXCEPT OSError.E => (* not available *)      END;    END;    (* if we can't get the standard handles, we might be a GUI program       so we'll lazily allocate a console if needed. *)    RETURN LazyConsole.New (hd, ds);  END GetFileHandle;  Ok, this change came in in the upgrade from Critical Mass 4.1 to 5.1.4.1 being as I understand the actual one and only commercial release.5.1 I guess being the then current but unreleated Critical Mass tree. http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/WIN32/ProcessWin32.m3.diff?r1=1.1.1.1;r2=1.1.1.2;f=u Please advise. Also, to double check that things are working, run link -dump -headers foo.exe | findstr /i "subsystem entry" GUI apps should show: C:\dev2\j\m3\3>link -dump -headers NT386\prog.exe | findstr /i "subsystem entry"            1C60 entry point (00401C60) _WinMainCRTStartup               2 subsystem (Windows GUI) console apps should show: C:\dev2\j\m3\3>link -dump -headers NT386\prog.exe | findstr /i "subsystem entry"            1BE1 entry point (00401BE1) _mainCRTStartup               3 subsystem (Windows CUI)C for console/commandline, G for gui/graphical. If that is not what you are seeing, let's delve into that.If my test program always brings up a popup, when compiled with -gui, with the IO.Put commented out, let's delve into that.If your console is empty, let's look into that.If you console has output in it, well, I'm inclined to say you are seeing improved correct behavior, but we can debate it, I guess.  - Jay


From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: FW: [M3devel] pixmap problemDate: Thu, 8 May 2008 19:21:49 +0000

truncated again...


From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problemDate: Thu, 8 May 2008 18:57:08 +0000

Randy, At first very quick glance, this stuff looks ok.CM3-IDE probably doesn't really understand the config file, similar to m3cgcat's partial misunderstanding.  (Which is why I keep TARGET declared in NT386* instead of just NT386.common.)PKG_USE is defined I think, but it takes a really accurate understanding of Quake to get it. The entry/subsystem stuff also seems complete but I didn't try examples yet.Sorry, didn't give this all much time yet.I did get me to look at the environment variable bug that's been sitting there forever, with a bogus fix.. Can CM3-IDE default PKG_USE to CM3_ROOT + "/pkg"? Or INSTALL_ROOT + "/pkg"? Or whatever?That is what it always is, in anything that is checked in or that cminstall will give you.It takes hand editing of cm3.cfg to get anything else I think. Or CM3-IDE users can just edit the file some. Not a lot. But some.Given an incomplete understanding of the config files, probably putting in CM3-IDE wants but under if FALSE will perhaps work.Personally I wasn't impressed with Reactor... VC5 find-in-files gets me all I need. Anything besides plain text search doesn't scale..  - Jay


From: jayk123 at hotmail.comTo: rcoleburn at scires.com; m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problemDate: Tue, 6 May 2008 03:38:03 +0000

Randy, don't worry.Two of these problems are trivial to fix -- PKG_USE and popups.The pixmap one will need debugging.  - Jay


Date: Mon, 5 May 2008 23:28:10 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad news is that now I am getting a command window opening up in addition to the GUI window when the program runs.  This behavior does not occur on v4.1.  The command window seems to be the stdout/stderr of the GUI program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy>>> Jay  5/5/2008 10:47 PM >>>Randy, Yes.The NT386 config files are all checked in.You can use them verbatim. You don't need cminstall, I never use it, and you shouldn't need to edit the config files at all, any edits I make, I check in, and should be usable on all machines.As long as you set %PATH%/%INCLUDE%/%LIB%.If I'm wrong, I'd like to know why and try to fix. Consider the config files just part of cm3.exe.Not generally to be changed locally. Unless, well, unless you intend to, and you should strive to make one form that is usable by all.  - Jay


Date: Mon, 5 May 2008 22:42:30 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay,
When you say "took the updated config file", what do you mean?  Are you saying I need a different cm3.cfg file?
Regards,
Randy>>> Jay  5/5/2008 9:54 PM >>>And you took the updated config file?The way you can tell is that, roughly speaking, hand.obj should be in NT386\_m3responsefile0.txt.Or _m3responsefile1.txt, or, well, somewhere.Anyway, I think I saw the attachment, I can check later..and with 4.1 as I said.. I can see about making the fix not depend on config file changes...but it's not terrible asis, and I'd really like to merge more of the quake code into cm3.exe..  - Jay


Date: Mon, 5 May 2008 21:18:12 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem
Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly when the buildstandalone() directive is used.
 
Regards,
Randy>>> Jay  5/5/2008 7:04 PM >>>Thanks. I'll look into this tonight probably, as well as with 4.1 assuming I can find my binaries and source for it (probably).COULD BE the pixmap problem is something else and 4.1 also has the problem I fixed. We'll see. No need to speculate (unless I can't find my 4.1). - Jay


Date: Mon, 5 May 2008 10:59:27 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problem
Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy>>> Jay  5/4/2008 11:46 AM >>>Randy, Please try with /current/ source, as of this morning Sunday May 4 -- the changes are ALL in NT386.common, so you MUST use MY config files, which are checked in verbatim, or you should be able edit whatever config files you are using. (It's not really a config file issue, don't blame the general confusion people have with them.) I'll try to try later, but I don't have the source right now, gotta look on other machines, and I think it's on a machine on loan.  Or send it to me again.I'd also like to know if this worked with 4.1, or with any release that offered dynamic linking to m3core.dll, on Windows.  I recall a claim that it did. If today's change fixes it, I should be able to investigate 4.1.3.6 did not have such linking.If today's change does not help, well, I still plan on debugging it at some point.. If you aren't current and getting so is difficult, just send the attachment again, it's easy for me to test. Thanks, - Jay


From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rcoleburn at scires.comDate: Sat, 19 Jan 2008 08:52:08 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.I was going to try on PPC_DARWIN but I guess Tony's info suffices. I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. Debugging here is a big humungous pain.NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)And bundles look pretty simple, a bundle is just a generated source file with a constant in it.Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something. The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for? I have to say this is very surprising. I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so.The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: pointer to msvcrt!fopenpointer to msvcrt!fclosenullpointer to kernel32!Sleep But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo.But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo.That doesn't work for data though. There's no ability to intervenve like that.So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it.And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.However that would suck perf in order to make an uncommon case work.I hope Modula-3 doesn't do that either. :)Though I guess since this global data in question...maybe it is rare??? Later, - Jay

> From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 03:09:47 -0500> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] pixmap problem> > Looks fine to me on I386_DARWIN.> > On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:> > > > 

Need to know the score, the latest news, or you need your Hotmail?-get your "fix" Check it out. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sat May 10 11:19:59 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 10 May 2008 09:19:59 +0000
Subject: [M3devel] pixmap problem
In-Reply-To: <482529C7.1E75.00D7.1@scires.com>
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	
	<481F9804.1E75.00D7.1@scires.com><481F9804.1E75.00D7.1@scires.com>
	 
	<482529C7.1E75.00D7.1@scires.com>
Message-ID: 

Randy, I strongly recommend you install Python. It is trivial, and gives you something good.
"Try it. You'll like it."
It is WAY more pleasant than dealing with sh or cmd or Perl, and I've spent quite a while fighting with cmd and Perl.
 
scripts\win\do-cm3-std buildship will probably work too.
I'm hoping to find some excuse to delete that directory, like some grand new important feature in the *.sh and *.py files.
 
I put up an updated distribution, and cleaned out older ones.
 
I do consider it a bit of a flaw that cm3 has a "builder", but not a "multi directory builder".
As well, it should be easy to put the build intermediates outside of the source tree.
As well, it should be possible to build outputs directly into the install, for the very optimistic scenario.
I went to build distributions with make-dist.cmd and make-dist.py at the same time and that fails because they fight over intermediate directories.
 
 > I am not seeing hand.obj in the .lst file.
 
You REALLY need to fix that, besides building std.
Linking to hand.obj is THE FIX, at least the current form of it.
My config files always link to it.
You do have to rebuild m3core in order to produce and ship it, which do-cm3-std will do, and upgrade will do.
 
The .lst file I speak of..oh, I guess there's others now, but the main one is the linker output.
  Which is really to say, it is the linker dumping the response file contents.
Or you can check the _m3response0.txt, _m3response1.txt files.
There are now a few more .lst files where there is a C compilation, in order to quash the C compiler output that upsets Olaf and Tony. But these are rare, hand.lst, dtoa.lst, RTLinkerC.lst, we could remove two of them.
 
I can probably remove hand.obj, but a reason to push people away from wierdo heavily customized config files is a good thing.
 
I am certain this bug is fixed.
 
 - Jay



Date: Sat, 10 May 2008 04:51:23 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem


Jay:
 
I do not have python installed on my computer, so I can't run your scripts.
 
I used the scripts in scripts\win to upgrade a few days ago.
 
I am not seeing hand.obj in the .lst file.
 
I will do a CVS update and try the upgrade again followed by do-cm3-standard.
 
Regards,
Randy>>> Jay  5/9/2008 5:10 AM >>>
 > Also, more bad news, the pixmap problem is not solved. Randy, this DOES actually fix it, but you have to rebuild more. Try:   cd scripts\python    .\do-cm3-std.py realclean    .\upgrade.py   (probably not needed)    do-cm3-std.py buildship   Make sure "hand.obj" occurs in the various NT386\foo.lst files. I think the fix should be restated to have the code reference *__imp__highbits instead of highbits, and go back to dynamic linking the data.But ok for now. The std distribution I put yesterday should work, though it is missing the RTArgs fix.I'll see about making another.   - Jay


Date: Mon, 5 May 2008 23:28:10 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad news is that now I am getting a command window opening up in addition to the GUI window when the program runs.  This behavior does not occur on v4.1.  The command window seems to be the stdout/stderr of the GUI program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy>>> Jay  5/5/2008 10:47 PM >>>Randy, Yes.The NT386 config files are all checked in.You can use them verbatim. You don't need cminstall, I never use it, and you shouldn't need to edit the config files at all, any edits I make, I check in, and should be usable on all machines.As long as you set %PATH%/%INCLUDE%/%LIB%.If I'm wrong, I'd like to know why and try to fix. Consider the config files just part of cm3.exe.Not generally to be changed locally. Unless, well, unless you intend to, and you should strive to make one form that is usable by all.  - Jay


Date: Mon, 5 May 2008 22:42:30 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay,
When you say "took the updated config file", what do you mean?  Are you saying I need a different cm3.cfg file?
Regards,
Randy>>> Jay  5/5/2008 9:54 PM >>>And you took the updated config file?The way you can tell is that, roughly speaking, hand.obj should be in NT386\_m3responsefile0.txt.Or _m3responsefile1.txt, or, well, somewhere.Anyway, I think I saw the attachment, I can check later..and with 4.1 as I said.. I can see about making the fix not depend on config file changes...but it's not terrible asis, and I'd really like to merge more of the quake code into cm3.exe..  - Jay


Date: Mon, 5 May 2008 21:18:12 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem
Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly when the buildstandalone() directive is used.
 
Regards,
Randy>>> Jay  5/5/2008 7:04 PM >>>Thanks. I'll look into this tonight probably, as well as with 4.1 assuming I can find my binaries and source for it (probably).COULD BE the pixmap problem is something else and 4.1 also has the problem I fixed. We'll see. No need to speculate (unless I can't find my 4.1). - Jay


Date: Mon, 5 May 2008 10:59:27 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problem
Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy>>> Jay  5/4/2008 11:46 AM >>>Randy, Please try with /current/ source, as of this morning Sunday May 4 -- the changes are ALL in NT386.common, so you MUST use MY config files, which are checked in verbatim, or you should be able edit whatever config files you are using. (It's not really a config file issue, don't blame the general confusion people have with them.) I'll try to try later, but I don't have the source right now, gotta look on other machines, and I think it's on a machine on loan.  Or send it to me again.I'd also like to know if this worked with 4.1, or with any release that offered dynamic linking to m3core.dll, on Windows.  I recall a claim that it did. If today's change fixes it, I should be able to investigate 4.1.3.6 did not have such linking.If today's change does not help, well, I still plan on debugging it at some point.. If you aren't current and getting so is difficult, just send the attachment again, it's easy for me to test. Thanks, - Jay


From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rcoleburn at scires.comDate: Sat, 19 Jan 2008 08:52:08 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.I was going to try on PPC_DARWIN but I guess Tony's info suffices. I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. Debugging here is a big humungous pain.NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)And bundles look pretty simple, a bundle is just a generated source file with a constant in it.Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something. The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for? I have to say this is very surprising. I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so.The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: pointer to msvcrt!fopenpointer to msvcrt!fclosenullpointer to kernel32!Sleep But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo.But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo.That doesn't work for data though. There's no ability to intervenve like that.So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it.And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.However that would suck perf in order to make an uncommon case work.I hope Modula-3 doesn't do that either. :)Though I guess since this global data in question...maybe it is rare??? Later, - Jay

> From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 03:09:47 -0500> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] pixmap problem> > Looks fine to me on I386_DARWIN.> > On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:> > > > 

Need to know the score, the latest news, or you need your Hotmail?-get your "fix" Check it out. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Sat May 10 11:23:35 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Sat, 10 May 2008 05:23:35 -0400
Subject: [M3devel] pixmap problem
In-Reply-To: <482529C7.1E75.00D7.1@scires.com>
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	
	<481F9804.1E75.00D7.1@scires.com><481F9804.1E75.00D7.1@scires.com>
	
	<482529C7.1E75.00D7.1@scires.com>
Message-ID: <48253152.1E75.00D7.1@scires.com>

Jay:
 
I've performed the following and it seems to have fixed the problem
with the TestPixmap program when built standalone:
 
1.  performed CVS update
2.  updated cm3.cfg and NT386* in \cm3\bin based on sources in
cminstall\config
3.  scripts\win\upgrade
4.  scripts\win\do-cm3-std buildship
 
I checked the .lst file and I am now seeing "hand.obj"
 
Regards,
Randy

>>> "Randy Coleburn"  5/10/2008 4:51 AM >>>
Jay:
 
I do not have python installed on my computer, so I can't run your
scripts.
 
I used the scripts in scripts\win to upgrade a few days ago.
 
I am not seeing hand.obj in the .lst file.
 
I will do a CVS update and try the upgrade again followed by
do-cm3-standard.
 
Regards,
Randy

>>> Jay  5/9/2008 5:10 AM >>>
 > Also, more bad news, the pixmap problem is not solved.
 
Randy, this DOES actually fix it, but you have to rebuild more.
 
Try:
   cd scripts\python  
  .\do-cm3-std.py realclean  
  .\upgrade.py   (probably not needed) 
   do-cm3-std.py buildship  
 
Make sure "hand.obj" occurs in the various NT386\foo.lst files.
 
I think the fix should be restated to have the code reference
*__imp__highbits instead of highbits, and go back to dynamic linking the
data.
But ok for now.
 
The std distribution I put yesterday should work, though it is missing
the RTArgs fix.
I'll see about making another.
 
  - Jay

Date: Mon, 5 May 2008 23:28:10 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com; jayk123 at hotmail.com 
Subject: RE: [M3devel] pixmap problem

Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've
copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad
news is that now I am getting a command window opening up in addition to
the GUI window when the program runs.  This behavior does not occur on
v4.1.  The command window seems to be the stdout/stderr of the GUI
program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which
needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy

>>> Jay  5/5/2008 10:47 PM >>>
Randy, Yes.
The NT386 config files are all checked in.
You can use them verbatim. You don't need cminstall, I never use it,
and you shouldn't need to edit the config files at all, any edits I
make, I check in, and should be usable on all machines.
As long as you set %PATH%/%INCLUDE%/%LIB%.
If I'm wrong, I'd like to know why and try to fix.
 
Consider the config files just part of cm3.exe.
Not generally to be changed locally. Unless, well, unless you intend
to, and you should strive to make one form that is usable by all.
 
 - Jay


Date: Mon, 5 May 2008 22:42:30 -0400
From: rcoleburn at scires.com 
To: jayk123 at hotmail.com 
Subject: RE: [M3devel] pixmap problem

Jay,
When you say "took the updated config file", what do you mean?  Are you
saying I need a different cm3.cfg file?
Regards,
Randy

>>> Jay  5/5/2008 9:54 PM >>>
And you took the updated config file?
The way you can tell is that, roughly speaking, hand.obj should be in
NT386\_m3responsefile0.txt.
Or _m3responsefile1.txt, or, well, somewhere.
Anyway, I think I saw the attachment, I can check later..and with 4.1
as I said..
 
I can see about making the fix not depend on config file changes...but
it's not terrible asis, and I'd really like to merge more of the quake
code into cm3.exe..
 
 - Jay

Date: Mon, 5 May 2008 21:18:12 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com 
Subject: Re: [M3devel] pixmap problem

Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly
when the buildstandalone() directive is used.
 
Regards,
Randy

>>> Jay  5/5/2008 7:04 PM >>>
Thanks. I'll look into this tonight probably, as well as with 4.1
assuming I can find my binaries and source for it (probably).

COULD BE the pixmap problem is something else and 4.1 also has the
problem I fixed. We'll see. No need to speculate (unless I can't find my
4.1).

 - Jay


Date: Mon, 5 May 2008 10:59:27 -0400
From: rcoleburn at scires.com 
To: jayk123 at hotmail.com 
CC: m3devel at elegosoft.com 
Subject: RE: [M3devel] pixmap problem

Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files
or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy

>>> Jay  5/4/2008 11:46 AM >>>
Randy, Please try with /current/ source, as of this morning Sunday May
4 -- the changes are ALL in NT386.common, so you MUST use MY config
files, which are checked in verbatim, or you should be able edit
whatever config files you are using.
 
(It's not really a config file issue, don't blame the general confusion
people have with them.)
 
I'll try to try later, but I don't have the source right now, gotta
look on other machines, and I think it's on a machine on loan.
  Or send it to me again.
I'd also like to know if this worked with 4.1, or with any release that
offered dynamic linking to m3core.dll, on Windows.
  I recall a claim that it did. If today's change fixes it, I should be
able to investigate 4.1.
3.6 did not have such linking.
If today's change does not help, well, I still plan on debugging it at
some point..
 
If you aren't current and getting so is difficult, just send the
attachment again, it's easy for me to test.
 
Thanks,
 - Jay

From: jayk123 at hotmail.com 
To: hosking at cs.purdue.edu; rcoleburn at scires.com 
Date: Sat, 19 Jan 2008 08:52:08 +0000
CC: m3devel at elegosoft.com 
Subject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.
I was going to try on PPC_DARWIN but I guess Tony's info suffices.
 
I tried rolling hand.c back to before I changed (months/year ago),
since it is involved in bit twiddling, no change, phew.
 
Debugging here is a big humungous pain.
NT386 has good stacks and line numbers, but no locals or type info, I'd
really sometime like to get Codeview info into those .objs...I think it
is documented well enough, but still not necessarily easy, or maybe have
a C generating backend partly for this reason (and to bring up more
targets, using native tools), and function calls in disassembly I think
don't resolve; NT386GNU can't yet build this, though it will soon, but
I'm not familiar with gdb and there appears to be no type info. I'm
building m3gdb right now, I don't know if it will work, I hope it has
type info, and I'm not familiar with the relevant code. In gdb I
struggle just to view bytes in memory, add numbers to addresses and see
those, etc. I think for MY problem, I'm going to link in C code to dump
the structs. There is tracing code and I enabled it, but even it crashes
in Text_Length. At least MY problem crashes, hopefully near the problem,
whereas your problem goes all the way through to completion with no
stopping to hint where the problem is. Darn it. :) on the mock rudeness
and :( on the lack of a crash.
 
You write the bundle out and it matches, so that doesn't rule out
bundles as being the problem? (darn)
And bundles look pretty simple, a bundle is just a generated source
file with a constant in it.
Maybe newline problems? That wouldn't make sense. I just downloaded
some program that might let me separately view the ppm, maybe it'll
reveal something.
 
The bad behavior has like regularly spaced solid color veritical bars a
few pixels side across the whole picture, and regularly spaced vertical
stripes from the correct picture alternating with that. Perhaps someone
with ppm/bitmap/graphics experience has seen this behavior and it
results from some common pixmap mismanagement we could look for?
 
I have to say this is very surprising.
 
I always wondered, and now I pretty much assume -- Modula-3 never
imports/exports data in its dynamic linking, right? It alway
imports/exports functions, right?
On Windows, functions have an optional optimization, but data must be
handled differently at compile time if it is going to be dynamically
imported.
For functions, if you don't apply the optimization at compile time, the
linker will just generate a single instruction thunk instead.
 
That is, given a symbol Foo, there is a symbol __imp__Foo that is a
pointer to the actual foo in another .dll/.so.
The loader only patches pointers, one per import if you build your .dll
correctly, it doesn't patch instructions or code strewn throughout a
.dll, just one contiguous array of pointers. MAYBE they don't have to be
contiguous for each .dl you import from.
 
That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my
.dll/.exe typically has an array:
 
pointer to msvcrt!fopen
pointer to msvcrt!fclose
null
pointer to kernel32!Sleep
 
But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not
be adjacent.
 
So, going back, my point/question is that, if the compiler knows the
function is imported, it can call through __imp__Foo instead of calling
Foo.
But if it calls Foo and you import Foo, the linker will create the
function Foo that just jmps through __imp__Foo.
That doesn't work for data though. There's no ability to intervenve
like that.
So for imported data, the compiler must generated a read and
dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to
be imported.
Data imports may be faster when appropriate, but for this reason, I'd
say they aren't worth it.
And for this reason, I HOPE Modula-3 never imports/exports data.
 
Oh, you could, for data, always reference the pointer __imp_Foo, and if
non materializes, create one.
However that would suck perf in order to make an uncommon case work.
I hope Modula-3 doesn't do that either. :)
Though I guess since this global data in question...maybe it is
rare???
 
Later,
 - Jay



> From: hosking at cs.purdue.edu 
> Date: Sat, 19 Jan 2008 03:09:47 -0500
> To: rcoleburn at scires.com 
> CC: m3devel at elegosoft.com 
> Subject: Re: [M3devel] pixmap problem
> 
> Looks fine to me on I386_DARWIN.
> 
> On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:
> 
> > 
> 


Need to know the score, the latest news, or you need your Hotmail*-get
your "fix" Check it out. ( http://www.msnmobilefix.com/Default.aspx ) 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Sat May 10 11:24:31 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Sat, 10 May 2008 05:24:31 -0400
Subject: [M3devel] NT386 environment variables (new NT386	snapshots)
References: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
	
	<4823279D.1E75.00D7.1@scires.com>
	
	<482528BA.1E75.00D7.1@scires.com>
Message-ID: <4825318A.1E75.00D7.1@scires.com>

Jay:
 
Here are my results using the program you supplied:
 
1.  cm3 v4.1, VS 2005, GUI mode, get a pop-up dos window, but program crashes
 
2.  cm3 v4.1, VS 2005, console mode, program crashes
 
3.  cm3 v.d5.7.0, VS 2008 GUI mode, get a pop-up window but it disappears too fast to see any contents
 
4.  cm3 v.d5.7.0, VS 2008 console mode, program crashes
 
Regards,
Randy

>>> Jay  5/9/2008 3:44 AM >>>
 > these problems (pixmaps, buildstandalone, environ vars, serial i/o, etc...
 
 Ok, here is the story with environment variables.

I tested 3.6 and current, gui and console.

This is the program:

C:\dev2\j\m3\3>type src\m3makefile

import ("m3core")
import ("libm3")
m3_option ("-gui")     twiddle this line in and out with a comment
implementation ("Main")
program ("pgm")
 
C:\dev2\j\m3\3>type src\Main.m3
MODULE Main;
IMPORT IO;
IMPORT RTArgs;
 
BEGIN
(* IO.Put just crashes in 3.6 gui apps *)
  IO.Put(RTArgs.GetArg(2));
  IO.Put(RTArgs.GetEnv(2));
 
(* use this for gui apps *)
  EVAL RTArgs.GetArg(2);
  EVAL RTArgs.GetEnv(2);
END Main.

In 3.6 console apps, RTArgs.GetEnv returns garbage. That makes sense from the code.
In current console apps, GetEnv works.
In current gui apps, GetEnv access violates, or returns an invalid pointer.
  This also makes sense from the code.

Randy, does this actually work for you?
I'd be quite surprised.
I haven't tried 4.1 yet, just 3.6 and current.

I will apply an easy fix.

 - Jay

Date: Thu, 8 May 2008 16:17:37 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com 
Subject: Re: [M3devel] new NT386 snapshots

Jay:
 
I have both console and gui programs built using 4.1 that do pull stuff out of the environment.  I've not noticed any problems with either mode.
 
>From my perspective, the old 4.1 seems more reliable than the current system in a number of respects.  I have a new project with a hard deadline that I would like to use the new cm3 system for, but until these problems (pixmaps, buildstandalone, environ vars, serial i/o, etc.) can be resolved, I'm going to keep using 4.1 for my production work.
 
Regards,
Randy

>>> Jay  5/8/2008 2:46 PM >>>
http://modula3.elegosoft.com/cm3/uploaded-archives/ 
 
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0.zip 
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-WIN32-NT386-d5.7.0.zip 
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0-symbols.zip 
 
These should have:
  latest quake extensions 
  set relation fixes 
  other set fixes revealed through dynamic linking of one regression test 
  hypothetical ability to cross-build to AMD64_LINUX, AMD64_DARWIN  
  one jmpbuf size for all NT386 configurations (NT386, NT386GNU, NT386MINGNU) 
 
Built with Visual C++ 9.0 Express, so you'll want:
http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en 
 
 
Still more work to do though, e.g. assertion failures in unit tests, pixmap..
 
Fuller disclosure:
Something is leaking memory on my system such that "everything" starts "failing" and I have to reboot.
This isn't Modula-3 related.
Hopefully these files aren't damaged as a result.
Must be some buggy driver or something..
 
Aside:
 The environment variable thingy has been bugging me a long time and I finally looked deeper at it.
It appears broken in CM3 4.x. I didn't check 3.x yet.
I'm still mulling a fix, and haven't run a repro of the break, but it's not a big deal either way.
Basically console apps use main that takes char** and gui apps use WinMain that doesn't get environment variables but the generated code calls GetEvironmentStrings() which returns null separated strings.
Must be that hardly anyone uses environment variables in Modula-3 on Win32 for this to have lingered so long, at least gui apps.
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sat May 10 11:38:30 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 10 May 2008 09:38:30 +0000
Subject: [M3devel] pixmap problem
In-Reply-To: <48253152.1E75.00D7.1@scires.com>
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	
	<481F9804.1E75.00D7.1@scires.com><481F9804.1E75.00D7.1@scires.com>
	
	<482529C7.1E75.00D7.1@scires.com>  <48253152.1E75.00D7.1@scires.com>
Message-ID: 

Randy, clarification, the bug occured when NOT building standalone.
You must know that, since you reproed it recently.
Just try both ways, both should work.
 
(You don't have to take my cm3.cfg, but you do need NT386.common, and then either copy NT386 to cm3.cfg, or take NT386 and have cm3.cfg be just one line, include("NT386"))
 
Any reason left for you to stick with 4.1? :)
Something with serialio?
 
At least one question does remain -- the TestPixmap behavior and why on 4.1.
I'll look into that shortly.
3.6 isn't relevant, since it didn't have .dlls.
 
Thanks,
 - Jay


Date: Sat, 10 May 2008 05:23:35 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem

Jay:
 
I've performed the following and it seems to have fixed the problem with the TestPixmap program when built standalone:
 
1.  performed CVS update
2.  updated cm3.cfg and NT386* in \cm3\bin based on sources in cminstall\config
3.  scripts\win\upgrade
4.  scripts\win\do-cm3-std buildship
 
I checked the .lst file and I am now seeing "hand.obj"
 
Regards,
Randy>>> "Randy Coleburn"  5/10/2008 4:51 AM >>>
Jay:
 
I do not have python installed on my computer, so I can't run your scripts.
 
I used the scripts in scripts\win to upgrade a few days ago.
 
I am not seeing hand.obj in the .lst file.
 
I will do a CVS update and try the upgrade again followed by do-cm3-standard.
 
Regards,
Randy>>> Jay  5/9/2008 5:10 AM >>>
 > Also, more bad news, the pixmap problem is not solved. Randy, this DOES actually fix it, but you have to rebuild more. Try:   cd scripts\python    .\do-cm3-std.py realclean    .\upgrade.py   (probably not needed)    do-cm3-std.py buildship   Make sure "hand.obj" occurs in the various NT386\foo.lst files. I think the fix should be restated to have the code reference *__imp__highbits instead of highbits, and go back to dynamic linking the data.But ok for now. The std distribution I put yesterday should work, though it is missing the RTArgs fix.I'll see about making another.   - Jay


Date: Mon, 5 May 2008 23:28:10 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad news is that now I am getting a command window opening up in addition to the GUI window when the program runs.  This behavior does not occur on v4.1.  The command window seems to be the stdout/stderr of the GUI program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy>>> Jay  5/5/2008 10:47 PM >>>Randy, Yes.The NT386 config files are all checked in.You can use them verbatim. You don't need cminstall, I never use it, and you shouldn't need to edit the config files at all, any edits I make, I check in, and should be usable on all machines.As long as you set %PATH%/%INCLUDE%/%LIB%.If I'm wrong, I'd like to know why and try to fix. Consider the config files just part of cm3.exe.Not generally to be changed locally. Unless, well, unless you intend to, and you should strive to make one form that is usable by all.  - Jay


Date: Mon, 5 May 2008 22:42:30 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay,
When you say "took the updated config file", what do you mean?  Are you saying I need a different cm3.cfg file?
Regards,
Randy>>> Jay  5/5/2008 9:54 PM >>>And you took the updated config file?The way you can tell is that, roughly speaking, hand.obj should be in NT386\_m3responsefile0.txt.Or _m3responsefile1.txt, or, well, somewhere.Anyway, I think I saw the attachment, I can check later..and with 4.1 as I said.. I can see about making the fix not depend on config file changes...but it's not terrible asis, and I'd really like to merge more of the quake code into cm3.exe..  - Jay


Date: Mon, 5 May 2008 21:18:12 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem
Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly when the buildstandalone() directive is used.
 
Regards,
Randy>>> Jay  5/5/2008 7:04 PM >>>Thanks. I'll look into this tonight probably, as well as with 4.1 assuming I can find my binaries and source for it (probably).COULD BE the pixmap problem is something else and 4.1 also has the problem I fixed. We'll see. No need to speculate (unless I can't find my 4.1). - Jay


Date: Mon, 5 May 2008 10:59:27 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problem
Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy>>> Jay  5/4/2008 11:46 AM >>>Randy, Please try with /current/ source, as of this morning Sunday May 4 -- the changes are ALL in NT386.common, so you MUST use MY config files, which are checked in verbatim, or you should be able edit whatever config files you are using. (It's not really a config file issue, don't blame the general confusion people have with them.) I'll try to try later, but I don't have the source right now, gotta look on other machines, and I think it's on a machine on loan.  Or send it to me again.I'd also like to know if this worked with 4.1, or with any release that offered dynamic linking to m3core.dll, on Windows.  I recall a claim that it did. If today's change fixes it, I should be able to investigate 4.1.3.6 did not have such linking.If today's change does not help, well, I still plan on debugging it at some point.. If you aren't current and getting so is difficult, just send the attachment again, it's easy for me to test. Thanks, - Jay


From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rcoleburn at scires.comDate: Sat, 19 Jan 2008 08:52:08 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.I was going to try on PPC_DARWIN but I guess Tony's info suffices. I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. Debugging here is a big humungous pain.NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)And bundles look pretty simple, a bundle is just a generated source file with a constant in it.Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something. The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for? I have to say this is very surprising. I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so.The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: pointer to msvcrt!fopenpointer to msvcrt!fclosenullpointer to kernel32!Sleep But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo.But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo.That doesn't work for data though. There's no ability to intervenve like that.So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it.And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.However that would suck perf in order to make an uncommon case work.I hope Modula-3 doesn't do that either. :)Though I guess since this global data in question...maybe it is rare??? Later, - Jay

> From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 03:09:47 -0500> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] pixmap problem> > Looks fine to me on I386_DARWIN.> > On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:> > > > 

Need to know the score, the latest news, or you need your Hotmail?-get your "fix" Check it out. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sat May 10 11:43:45 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 10 May 2008 09:43:45 +0000
Subject: [M3devel] NT386 environment variables (new NT386	snapshots)
In-Reply-To: <4825318A.1E75.00D7.1@scires.com>
References: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
	
	<4823279D.1E75.00D7.1@scires.com>
	
	<482528BA.1E75.00D7.1@scires.com>  <4825318A.1E75.00D7.1@scires.com>
Message-ID: 

Randy,You can make the popup stick around easily enough, put in WinBase.Sleep(10000), or maybe run under a debugger.
For 5.7 to work, you need the very recent fix to RTArgs.m3 AND you need to pass a few parameters to the test program, like
NT386\pgm abc def ghi
 
 - Jay


Date: Sat, 10 May 2008 05:24:31 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] NT386 environment variables (new NT386 snapshots)

Jay:
 
Here are my results using the program you supplied:
 
1.  cm3 v4.1, VS 2005, GUI mode, get a pop-up dos window, but program crashes
 
2.  cm3 v4.1, VS 2005, console mode, program crashes
 
3.  cm3 v.d5.7.0, VS 2008 GUI mode, get a pop-up window but it disappears too fast to see any contents
 
4.  cm3 v.d5.7.0, VS 2008 console mode, program crashes
 
Regards,
Randy>>> Jay  5/9/2008 3:44 AM >>> > these problems (pixmaps, buildstandalone, environ vars, serial i/o, etc...  Ok, here is the story with environment variables.I tested 3.6 and current, gui and console.This is the program:C:\dev2\j\m3\3>type src\m3makefileimport ("m3core")import ("libm3")m3_option ("-gui")     twiddle this line in and out with a commentimplementation ("Main")program ("pgm") C:\dev2\j\m3\3>type src\Main.m3MODULE Main;IMPORT IO;IMPORT RTArgs; BEGIN(* IO.Put just crashes in 3.6 gui apps *)  IO.Put(RTArgs.GetArg(2));  IO.Put(RTArgs.GetEnv(2)); (* use this for gui apps *)  EVAL RTArgs.GetArg(2);  EVAL RTArgs.GetEnv(2);END Main.In 3.6 console apps, RTArgs.GetEnv returns garbage. That makes sense from the code.In current console apps, GetEnv works.In current gui apps, GetEnv access violates, or returns an invalid pointer.  This also makes sense from the code.Randy, does this actually work for you?I'd be quite surprised.I haven't tried 4.1 yet, just 3.6 and current.I will apply an easy fix. - Jay


Date: Thu, 8 May 2008 16:17:37 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] new NT386 snapshots
Jay:
 
I have both console and gui programs built using 4.1 that do pull stuff out of the environment.  I've not noticed any problems with either mode.
 
>From my perspective, the old 4.1 seems more reliable than the current system in a number of respects.  I have a new project with a hard deadline that I would like to use the new cm3 system for, but until these problems (pixmaps, buildstandalone, environ vars, serial i/o, etc.) can be resolved, I'm going to keep using 4.1 for my production work.
 
Regards,
Randy>>> Jay  5/8/2008 2:46 PM >>>http://modula3.elegosoft.com/cm3/uploaded-archives/ http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0.ziphttp://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-WIN32-NT386-d5.7.0.ziphttp://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0-symbols.zip These should have:  latest quake extensions   set relation fixes   other set fixes revealed through dynamic linking of one regression test   hypothetical ability to cross-build to AMD64_LINUX, AMD64_DARWIN    one jmpbuf size for all NT386 configurations (NT386, NT386GNU, NT386MINGNU)  Built with Visual C++ 9.0 Express, so you'll want:http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en  Still more work to do though, e.g. assertion failures in unit tests, pixmap.. Fuller disclosure:Something is leaking memory on my system such that "everything" starts "failing" and I have to reboot.This isn't Modula-3 related.Hopefully these files aren't damaged as a result.Must be some buggy driver or something.. Aside: The environment variable thingy has been bugging me a long time and I finally looked deeper at it.It appears broken in CM3 4.x. I didn't check 3.x yet.I'm still mulling a fix, and haven't run a repro of the break, but it's not a big deal either way.Basically console apps use main that takes char** and gui apps use WinMain that doesn't get environment variables but the generated code calls GetEvironmentStrings() which returns null separated strings.Must be that hardly anyone uses environment variables in Modula-3 on Win32 for this to have lingered so long, at least gui apps.  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Sat May 10 11:46:16 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Sat, 10 May 2008 05:46:16 -0400
Subject: [M3devel] NT386 environment variables (new	NT386	snapshots)
In-Reply-To: 
References: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
	
	<4823279D.1E75.00D7.1@scires.com>
	
	<482528BA.1E75.00D7.1@scires.com>
	
Message-ID: <482536A3.1E75.00D7.1@scires.com>

Jay:
 
Ok, I've added the sleep.
Here are the new results using my newly rebuilt cm3 and my old v4.1:
 
v4.1:  pgm.exe @M3novm abc def ghi
v5.7:  pgm.exe abc def ghi
 
1.  cm3 4.1, VS 2005, GUI mode, popup with runtime error crash message
 
2.  cm3 4.1, VS 2005, console mode, no popup, output shows "def*5;"
 
3.  cm3 d5.7.0, VS 2008, GUI mode, popup with output shows
"def=ExitCode=00000000"
 
4.  cm3 d5.7.0, VS 2008, console mode, no popup with output shows
"def=ExitCode=00000000"
 
Regards,
Randy

>>> Jay  5/10/2008 5:04 AM >>>
Randy,
You can make the popup stick around, put in WinBase.Sleep(10000), or
run under a debugger.
Since 5.7 is crashing, I assume you don't have the fix I very recently
commited? Or the last point.
I assume if 5.7 doesn't crash, you are satisfied.
 
I forgot to tell you -- make sure you pass a few command line options
to the program, like
 
NT386\pgm.exe abc def ghi.
 
 - Jay

Date: Sat, 10 May 2008 04:46:54 -0400
From: rcoleburn at scires.com 
To: jayk123 at hotmail.com 
Subject: RE: [M3devel] NT386 environment variables (new NT386
snapshots)

Jay:
 
Here are my results using the program you supplied:
 
1.  cm3 v4.1, VS 2005, GUI mode, get a pop-up dos window, but program
crashes
 
2.  cm3 v4.1, VS 2005, console mode, program crashes
 
3.  cm3 v.d5.7.0, VS 2008 GUI mode, get a pop-up window but it
disappears too fast to see any contents
 
4.  cm3 v.d5.7.0, VS 2008 console mode, program crashes
 
Regards,
Randy

>>> Jay  5/9/2008 3:44 AM >>>
 > these problems (pixmaps, buildstandalone, environ vars, serial i/o,
etc...
 
 Ok, here is the story with environment variables.

I tested 3.6 and current, gui and console.

This is the program:

C:\dev2\j\m3\3>type src\m3makefile

import ("m3core")
import ("libm3")
m3_option ("-gui")     twiddle this line in and out with a comment
implementation ("Main")
program ("pgm")
 
C:\dev2\j\m3\3>type src\Main.m3
MODULE Main;
IMPORT IO;
IMPORT RTArgs;
 
BEGIN
(* IO.Put just crashes in 3.6 gui apps *)
  IO.Put(RTArgs.GetArg(2));
  IO.Put(RTArgs.GetEnv(2));
 
(* use this for gui apps *)
  EVAL RTArgs.GetArg(2);
  EVAL RTArgs.GetEnv(2);
END Main.

In 3.6 console apps, RTArgs.GetEnv returns garbage. That makes sense
from the code.
In current console apps, GetEnv works.
In current gui apps, GetEnv access violates, or returns an invalid
pointer.
  This also makes sense from the code.

Randy, does this actually work for you?
I'd be quite surprised.
I haven't tried 4.1 yet, just 3.6 and current.

I will apply an easy fix.

 - Jay

Date: Thu, 8 May 2008 16:17:37 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com 
Subject: Re: [M3devel] new NT386 snapshots

Jay:
 
I have both console and gui programs built using 4.1 that do pull stuff
out of the environment.  I've not noticed any problems with either
mode.
 
>From my perspective, the old 4.1 seems more reliable than the current
system in a number of respects.  I have a new project with a hard
deadline that I would like to use the new cm3 system for, but until
these problems (pixmaps, buildstandalone, environ vars, serial i/o,
etc.) can be resolved, I'm going to keep using 4.1 for my production
work.
 
Regards,
Randy

>>> Jay  5/8/2008 2:46 PM >>>
http://modula3.elegosoft.com/cm3/uploaded-archives/ 
 
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0.zip

http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-WIN32-NT386-d5.7.0.zip

http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0-symbols.zip

 
These should have:
  latest quake extensions 
  set relation fixes 
  other set fixes revealed through dynamic linking of one regression
test 
  hypothetical ability to cross-build to AMD64_LINUX, AMD64_DARWIN  
  one jmpbuf size for all NT386 configurations (NT386, NT386GNU,
NT386MINGNU) 
 
Built with Visual C++ 9.0 Express, so you'll want:
http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en

 
 
Still more work to do though, e.g. assertion failures in unit tests,
pixmap..
 
Fuller disclosure:
Something is leaking memory on my system such that "everything" starts
"failing" and I have to reboot.
This isn't Modula-3 related.
Hopefully these files aren't damaged as a result.
Must be some buggy driver or something..
 
Aside:
 The environment variable thingy has been bugging me a long time and I
finally looked deeper at it.
It appears broken in CM3 4.x. I didn't check 3.x yet.
I'm still mulling a fix, and haven't run a repro of the break, but it's
not a big deal either way.
Basically console apps use main that takes char** and gui apps use
WinMain that doesn't get environment variables but the generated code
calls GetEvironmentStrings() which returns null separated strings.
Must be that hardly anyone uses environment variables in Modula-3 on
Win32 for this to have lingered so long, at least gui apps.
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sat May 10 12:01:09 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 10 May 2008 10:01:09 +0000
Subject: [M3devel] NT386 environment variables (new	NT386	snapshots)
In-Reply-To: <482536A3.1E75.00D7.1@scires.com>
References: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
	
	<4823279D.1E75.00D7.1@scires.com>
	
	<482528BA.1E75.00D7.1@scires.com>
	 
	<482536A3.1E75.00D7.1@scires.com>
Message-ID: 

 > I have both console and gui programs built using 4.1 that do pull stuff out of the environment.
I assume you weren't using RTArgs?
 
Everything good, move along?
 
(Not "everything", there are still m3tests failures..though I guess -- maybe also try them with 3.6, 4.1, 5.1...)
 
 - Jay


Date: Sat, 10 May 2008 05:46:16 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] NT386 environment variables (new NT386 snapshots)

Jay:
 
Ok, I've added the sleep.
Here are the new results using my newly rebuilt cm3 and my old v4.1:
 
v4.1:  pgm.exe @M3novm abc def ghi

v5.7:  pgm.exe abc def ghi
 
1.  cm3 4.1, VS 2005, GUI mode, popup with runtime error crash message
 
2.  cm3 4.1, VS 2005, console mode, no popup, output shows "def?5;"
 
3.  cm3 d5.7.0, VS 2008, GUI mode, popup with output shows "def=ExitCode=00000000"
 
4.  cm3 d5.7.0, VS 2008, console mode, no popup with output shows "def=ExitCode=00000000"
 
Regards,
Randy>>> Jay  5/10/2008 5:04 AM >>>Randy,You can make the popup stick around, put in WinBase.Sleep(10000), or run under a debugger.Since 5.7 is crashing, I assume you don't have the fix I very recently commited? Or the last point.I assume if 5.7 doesn't crash, you are satisfied. I forgot to tell you -- make sure you pass a few command line options to the program, like NT386\pgm.exe abc def ghi.  - Jay


Date: Sat, 10 May 2008 04:46:54 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comSubject: RE: [M3devel] NT386 environment variables (new NT386 snapshots)
Jay:
 
Here are my results using the program you supplied:
 
1.  cm3 v4.1, VS 2005, GUI mode, get a pop-up dos window, but program crashes
 
2.  cm3 v4.1, VS 2005, console mode, program crashes
 
3.  cm3 v.d5.7.0, VS 2008 GUI mode, get a pop-up window but it disappears too fast to see any contents
 
4.  cm3 v.d5.7.0, VS 2008 console mode, program crashes
 
Regards,
Randy>>> Jay  5/9/2008 3:44 AM >>> > these problems (pixmaps, buildstandalone, environ vars, serial i/o, etc...  Ok, here is the story with environment variables.I tested 3.6 and current, gui and console.This is the program:C:\dev2\j\m3\3>type src\m3makefileimport ("m3core")import ("libm3")m3_option ("-gui")     twiddle this line in and out with a commentimplementation ("Main")program ("pgm") C:\dev2\j\m3\3>type src\Main.m3MODULE Main;IMPORT IO;IMPORT RTArgs; BEGIN(* IO.Put just crashes in 3.6 gui apps *)  IO.Put(RTArgs.GetArg(2));  IO.Put(RTArgs.GetEnv(2)); (* use this for gui apps *)  EVAL RTArgs.GetArg(2);  EVAL RTArgs.GetEnv(2);END Main.In 3.6 console apps, RTArgs.GetEnv returns garbage. That makes sense from the code.In current console apps, GetEnv works.In current gui apps, GetEnv access violates, or returns an invalid pointer.  This also makes sense from the code.Randy, does this actually work for you?I'd be quite surprised.I haven't tried 4.1 yet, just 3.6 and current.I will apply an easy fix. - Jay


Date: Thu, 8 May 2008 16:17:37 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] new NT386 snapshots
Jay:
 
I have both console and gui programs built using 4.1 that do pull stuff out of the environment.  I've not noticed any problems with either mode.
 
>From my perspective, the old 4.1 seems more reliable than the current system in a number of respects.  I have a new project with a hard deadline that I would like to use the new cm3 system for, but until these problems (pixmaps, buildstandalone, environ vars, serial i/o, etc.) can be resolved, I'm going to keep using 4.1 for my production work.
 
Regards,
Randy>>> Jay  5/8/2008 2:46 PM >>>http://modula3.elegosoft.com/cm3/uploaded-archives/ http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0.ziphttp://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-WIN32-NT386-d5.7.0.ziphttp://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0-symbols.zip These should have:  latest quake extensions   set relation fixes   other set fixes revealed through dynamic linking of one regression test   hypothetical ability to cross-build to AMD64_LINUX, AMD64_DARWIN    one jmpbuf size for all NT386 configurations (NT386, NT386GNU, NT386MINGNU)  Built with Visual C++ 9.0 Express, so you'll want:http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en  Still more work to do though, e.g. assertion failures in unit tests, pixmap.. Fuller disclosure:Something is leaking memory on my system such that "everything" starts "failing" and I have to reboot.This isn't Modula-3 related.Hopefully these files aren't damaged as a result.Must be some buggy driver or something.. Aside: The environment variable thingy has been bugging me a long time and I finally looked deeper at it.It appears broken in CM3 4.x. I didn't check 3.x yet.I'm still mulling a fix, and haven't run a repro of the break, but it's not a big deal either way.Basically console apps use main that takes char** and gui apps use WinMain that doesn't get environment variables but the generated code calls GetEvironmentStrings() which returns null separated strings.Must be that hardly anyone uses environment variables in Modula-3 on Win32 for this to have lingered so long, at least gui apps.  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Sat May 10 12:05:02 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Sat, 10 May 2008 06:05:02 -0400
Subject: [M3devel] pixmap problem
In-Reply-To: 
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	
	<481F9804.1E75.00D7.1@scires.com><481F9804.1E75.00D7.1@scires.com>
	
	<482529C7.1E75.00D7.1@scires.com>
	<48253152.1E75.00D7.1@scires.com><48253152.1E75.00D7.1@scires.com>
	
Message-ID: <48253B09.1E75.00D7.1@scires.com>

Jay:
 
I get correct behavior now for TestPixmap on d5.7 when built either
way, with or without standalone option.
THANKS!
 
On 4.1, TestPixmap also works both ways.  The problem was occurring
before your fix on d5.7 (and on earlier releases after 4.1).  Not sure
what your fix does or what changed from 4.1 to d5.7 that made your fix
necessary.
 
I am using your NT386 stuff for cm3.cfg now.
 
I don't have 3.6.
 
I will need to run tests now with d5.7 against my programs to see if
they are working correctly before I can abandon 4.1.  Also, we will need
to drive a stake in the ground at some point soon to create an official
5.7 release.  My company will want to be able to point to a given
development environment for future support of the product I'm working
on.  They won't accept a "d5.7" release that is in a state of flux.
 
Also, the other issue I'll have to work is getting all the GUI changes
incorporated into this edition.  We will need the custom look&feel that
CMass put together for us.  I'll check into it.  If I am successful, I
can create a branch on CVS with this edition in case anyone else wants
it.
 
Regards,
Randy

>>> Jay  5/10/2008 5:38 AM >>>
Randy, clarification, the bug occured when NOT building standalone.
You must know that, since you reproed it recently.
Just try both ways, both should work.
 
(You don't have to take my cm3.cfg, but you do need NT386.common, and
then either copy NT386 to cm3.cfg, or take NT386 and have cm3.cfg be
just one line, include("NT386"))
 
Any reason left for you to stick with 4.1? :)
Something with serialio?
 
At least one question does remain -- the TestPixmap behavior and why on
4.1.
I'll look into that shortly.
3.6 isn't relevant, since it didn't have .dlls.
 
Thanks,
 - Jay
Date: Sat, 10 May 2008 05:23:35 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com 
Subject: Re: [M3devel] pixmap problem

Jay:
 
I've performed the following and it seems to have fixed the problem
with the TestPixmap program when built standalone:
 
1.  performed CVS update
2.  updated cm3.cfg and NT386* in \cm3\bin based on sources in
cminstall\config
3.  scripts\win\upgrade
4.  scripts\win\do-cm3-std buildship
 
I checked the .lst file and I am now seeing "hand.obj"
 
Regards,
Randy

>>> "Randy Coleburn"  5/10/2008 4:51 AM >>>
Jay:
 
I do not have python installed on my computer, so I can't run your
scripts.
 
I used the scripts in scripts\win to upgrade a few days ago.
 
I am not seeing hand.obj in the .lst file.
 
I will do a CVS update and try the upgrade again followed by
do-cm3-standard.
 
Regards,
Randy

>>> Jay  5/9/2008 5:10 AM >>>
 > Also, more bad news, the pixmap problem is not solved.
 
Randy, this DOES actually fix it, but you have to rebuild more.
 
Try:
   cd scripts\python  
  .\do-cm3-std.py realclean  
  .\upgrade.py   (probably not needed) 
   do-cm3-std.py buildship  
 
Make sure "hand.obj" occurs in the various NT386\foo.lst files.
 
I think the fix should be restated to have the code reference
*__imp__highbits instead of highbits, and go back to dynamic linking the
data.
But ok for now.
 
The std distribution I put yesterday should work, though it is missing
the RTArgs fix.
I'll see about making another.
 
  - Jay

Date: Mon, 5 May 2008 23:28:10 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com; jayk123 at hotmail.com 
Subject: RE: [M3devel] pixmap problem

Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've
copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad
news is that now I am getting a command window opening up in addition to
the GUI window when the program runs.  This behavior does not occur on
v4.1.  The command window seems to be the stdout/stderr of the GUI
program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which
needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy

>>> Jay  5/5/2008 10:47 PM >>>
Randy, Yes.
The NT386 config files are all checked in.
You can use them verbatim. You don't need cminstall, I never use it,
and you shouldn't need to edit the config files at all, any edits I
make, I check in, and should be usable on all machines.
As long as you set %PATH%/%INCLUDE%/%LIB%.
If I'm wrong, I'd like to know why and try to fix.
 
Consider the config files just part of cm3.exe.
Not generally to be changed locally. Unless, well, unless you intend
to, and you should strive to make one form that is usable by all.
 
 - Jay


Date: Mon, 5 May 2008 22:42:30 -0400
From: rcoleburn at scires.com 
To: jayk123 at hotmail.com 
Subject: RE: [M3devel] pixmap problem

Jay,
When you say "took the updated config file", what do you mean?  Are you
saying I need a different cm3.cfg file?
Regards,
Randy

>>> Jay  5/5/2008 9:54 PM >>>
And you took the updated config file?
The way you can tell is that, roughly speaking, hand.obj should be in
NT386\_m3responsefile0.txt.
Or _m3responsefile1.txt, or, well, somewhere.
Anyway, I think I saw the attachment, I can check later..and with 4.1
as I said..
 
I can see about making the fix not depend on config file changes...but
it's not terrible asis, and I'd really like to merge more of the quake
code into cm3.exe..
 
 - Jay

Date: Mon, 5 May 2008 21:18:12 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com 
Subject: Re: [M3devel] pixmap problem

Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly
when the buildstandalone() directive is used.
 
Regards,
Randy

>>> Jay  5/5/2008 7:04 PM >>>
Thanks. I'll look into this tonight probably, as well as with 4.1
assuming I can find my binaries and source for it (probably).

COULD BE the pixmap problem is something else and 4.1 also has the
problem I fixed. We'll see. No need to speculate (unless I can't find my
4.1).

 - Jay


Date: Mon, 5 May 2008 10:59:27 -0400
From: rcoleburn at scires.com 
To: jayk123 at hotmail.com 
CC: m3devel at elegosoft.com 
Subject: RE: [M3devel] pixmap problem

Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files
or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy

>>> Jay  5/4/2008 11:46 AM >>>
Randy, Please try with /current/ source, as of this morning Sunday May
4 -- the changes are ALL in NT386.common, so you MUST use MY config
files, which are checked in verbatim, or you should be able edit
whatever config files you are using.
 
(It's not really a config file issue, don't blame the general confusion
people have with them.)
 
I'll try to try later, but I don't have the source right now, gotta
look on other machines, and I think it's on a machine on loan.
  Or send it to me again.
I'd also like to know if this worked with 4.1, or with any release that
offered dynamic linking to m3core.dll, on Windows.
  I recall a claim that it did. If today's change fixes it, I should be
able to investigate 4.1.
3.6 did not have such linking.
If today's change does not help, well, I still plan on debugging it at
some point..
 
If you aren't current and getting so is difficult, just send the
attachment again, it's easy for me to test.
 
Thanks,
 - Jay

From: jayk123 at hotmail.com 
To: hosking at cs.purdue.edu; rcoleburn at scires.com 
Date: Sat, 19 Jan 2008 08:52:08 +0000
CC: m3devel at elegosoft.com 
Subject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.
I was going to try on PPC_DARWIN but I guess Tony's info suffices.
 
I tried rolling hand.c back to before I changed (months/year ago),
since it is involved in bit twiddling, no change, phew.
 
Debugging here is a big humungous pain.
NT386 has good stacks and line numbers, but no locals or type info, I'd
really sometime like to get Codeview info into those .objs...I think it
is documented well enough, but still not necessarily easy, or maybe have
a C generating backend partly for this reason (and to bring up more
targets, using native tools), and function calls in disassembly I think
don't resolve; NT386GNU can't yet build this, though it will soon, but
I'm not familiar with gdb and there appears to be no type info. I'm
building m3gdb right now, I don't know if it will work, I hope it has
type info, and I'm not familiar with the relevant code. In gdb I
struggle just to view bytes in memory, add numbers to addresses and see
those, etc. I think for MY problem, I'm going to link in C code to dump
the structs. There is tracing code and I enabled it, but even it crashes
in Text_Length. At least MY problem crashes, hopefully near the problem,
whereas your problem goes all the way through to completion with no
stopping to hint where the problem is. Darn it. :) on the mock rudeness
and :( on the lack of a crash.
 
You write the bundle out and it matches, so that doesn't rule out
bundles as being the problem? (darn)
And bundles look pretty simple, a bundle is just a generated source
file with a constant in it.
Maybe newline problems? That wouldn't make sense. I just downloaded
some program that might let me separately view the ppm, maybe it'll
reveal something.
 
The bad behavior has like regularly spaced solid color veritical bars a
few pixels side across the whole picture, and regularly spaced vertical
stripes from the correct picture alternating with that. Perhaps someone
with ppm/bitmap/graphics experience has seen this behavior and it
results from some common pixmap mismanagement we could look for?
 
I have to say this is very surprising.
 
I always wondered, and now I pretty much assume -- Modula-3 never
imports/exports data in its dynamic linking, right? It alway
imports/exports functions, right?
On Windows, functions have an optional optimization, but data must be
handled differently at compile time if it is going to be dynamically
imported.
For functions, if you don't apply the optimization at compile time, the
linker will just generate a single instruction thunk instead.
 
That is, given a symbol Foo, there is a symbol __imp__Foo that is a
pointer to the actual foo in another .dll/.so.
The loader only patches pointers, one per import if you build your .dll
correctly, it doesn't patch instructions or code strewn throughout a
.dll, just one contiguous array of pointers. MAYBE they don't have to be
contiguous for each .dl you import from.
 
That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my
.dll/.exe typically has an array:
 
pointer to msvcrt!fopen
pointer to msvcrt!fclose
null
pointer to kernel32!Sleep
 
But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not
be adjacent.
 
So, going back, my point/question is that, if the compiler knows the
function is imported, it can call through __imp__Foo instead of calling
Foo.
But if it calls Foo and you import Foo, the linker will create the
function Foo that just jmps through __imp__Foo.
That doesn't work for data though. There's no ability to intervenve
like that.
So for imported data, the compiler must generated a read and
dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to
be imported.
Data imports may be faster when appropriate, but for this reason, I'd
say they aren't worth it.
And for this reason, I HOPE Modula-3 never imports/exports data.
 
Oh, you could, for data, always reference the pointer __imp_Foo, and if
non materializes, create one.
However that would suck perf in order to make an uncommon case work.
I hope Modula-3 doesn't do that either. :)
Though I guess since this global data in question...maybe it is
rare???
 
Later,
 - Jay



> From: hosking at cs.purdue.edu 
> Date: Sat, 19 Jan 2008 03:09:47 -0500
> To: rcoleburn at scires.com 
> CC: m3devel at elegosoft.com 
> Subject: Re: [M3devel] pixmap problem
> 
> Looks fine to me on I386_DARWIN.
> 
> On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:
> 
> > 
> 


Need to know the score, the latest news, or you need your Hotmail*-get
your "fix" Check it out. ( http://www.msnmobilefix.com/Default.aspx ) 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Sat May 10 12:14:46 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Sat, 10 May 2008 06:14:46 -0400
Subject: [M3devel] NT386 environment variables	(new	NT386	snapshots)
In-Reply-To: 
References: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
	
	<4823279D.1E75.00D7.1@scires.com>
	
	<482528BA.1E75.00D7.1@scires.com>
	
	<482536A3.1E75.00D7.1@scires.com><482536A3.1E75.00D7.1@scires.com>
	
Message-ID: <48253D51.1E75.00D7.1@scires.com>

Jay:
 
No, I don't think I was using RTArgs.  I was using Env.Get().
 
Regards,
Randy

>>> Jay  5/10/2008 6:01 AM >>>
 > I have both console and gui programs built using 4.1 that do pull
stuff out of the environment.

I assume you weren't using RTArgs?
 
Everything good, move along?
 
(Not "everything", there are still m3tests failures..though I guess --
maybe also try them with 3.6, 4.1, 5.1...)
 
 - Jay

Date: Sat, 10 May 2008 05:46:16 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com 
Subject: Re: [M3devel] NT386 environment variables (new NT386
snapshots)

Jay:
 
Ok, I've added the sleep.
Here are the new results using my newly rebuilt cm3 and my old v4.1:
 
v4.1:  pgm.exe @M3novm abc def ghi
v5.7:  pgm.exe abc def ghi
 
1.  cm3 4.1, VS 2005, GUI mode, popup with runtime error crash message
 
2.  cm3 4.1, VS 2005, console mode, no popup, output shows "def*5;"
 
3.  cm3 d5.7.0, VS 2008, GUI mode, popup with output shows
"def=ExitCode=00000000"
 
4.  cm3 d5.7.0, VS 2008, console mode, no popup with output shows
"def=ExitCode=00000000"
 
Regards,
Randy

>>> Jay  5/10/2008 5:04 AM >>>
Randy,
You can make the popup stick around, put in WinBase.Sleep(10000), or
run under a debugger.
Since 5.7 is crashing, I assume you don't have the fix I very recently
commited? Or the last point.
I assume if 5.7 doesn't crash, you are satisfied.
 
I forgot to tell you -- make sure you pass a few command line options
to the program, like
 
NT386\pgm.exe abc def ghi.
 
 - Jay

Date: Sat, 10 May 2008 04:46:54 -0400
From: rcoleburn at scires.com 
To: jayk123 at hotmail.com 
Subject: RE: [M3devel] NT386 environment variables (new NT386
snapshots)

Jay:
 
Here are my results using the program you supplied:
 
1.  cm3 v4.1, VS 2005, GUI mode, get a pop-up dos window, but program
crashes
 
2.  cm3 v4.1, VS 2005, console mode, program crashes
 
3.  cm3 v.d5.7.0, VS 2008 GUI mode, get a pop-up window but it
disappears too fast to see any contents
 
4.  cm3 v.d5.7.0, VS 2008 console mode, program crashes
 
Regards,
Randy

>>> Jay  5/9/2008 3:44 AM >>>
 > these problems (pixmaps, buildstandalone, environ vars, serial i/o,
etc...
 
 Ok, here is the story with environment variables.

I tested 3.6 and current, gui and console.

This is the program:

C:\dev2\j\m3\3>type src\m3makefile

import ("m3core")
import ("libm3")
m3_option ("-gui")     twiddle this line in and out with a comment
implementation ("Main")
program ("pgm")
 
C:\dev2\j\m3\3>type src\Main.m3
MODULE Main;
IMPORT IO;
IMPORT RTArgs;
 
BEGIN
(* IO.Put just crashes in 3.6 gui apps *)
  IO.Put(RTArgs.GetArg(2));
  IO.Put(RTArgs.GetEnv(2));
 
(* use this for gui apps *)
  EVAL RTArgs.GetArg(2);
  EVAL RTArgs.GetEnv(2);
END Main.

In 3.6 console apps, RTArgs.GetEnv returns garbage. That makes sense
from the code.
In current console apps, GetEnv works.
In current gui apps, GetEnv access violates, or returns an invalid
pointer.
  This also makes sense from the code.

Randy, does this actually work for you?
I'd be quite surprised.
I haven't tried 4.1 yet, just 3.6 and current.

I will apply an easy fix.

 - Jay

Date: Thu, 8 May 2008 16:17:37 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com 
Subject: Re: [M3devel] new NT386 snapshots

Jay:
 
I have both console and gui programs built using 4.1 that do pull stuff
out of the environment.  I've not noticed any problems with either
mode.
 
>From my perspective, the old 4.1 seems more reliable than the current
system in a number of respects.  I have a new project with a hard
deadline that I would like to use the new cm3 system for, but until
these problems (pixmaps, buildstandalone, environ vars, serial i/o,
etc.) can be resolved, I'm going to keep using 4.1 for my production
work.
 
Regards,
Randy

>>> Jay  5/8/2008 2:46 PM >>>
http://modula3.elegosoft.com/cm3/uploaded-archives/ 
 
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0.zip

http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-WIN32-NT386-d5.7.0.zip

http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0-symbols.zip

 
These should have:
  latest quake extensions 
  set relation fixes 
  other set fixes revealed through dynamic linking of one regression
test 
  hypothetical ability to cross-build to AMD64_LINUX, AMD64_DARWIN  
  one jmpbuf size for all NT386 configurations (NT386, NT386GNU,
NT386MINGNU) 
 
Built with Visual C++ 9.0 Express, so you'll want:
http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en

 
 
Still more work to do though, e.g. assertion failures in unit tests,
pixmap..
 
Fuller disclosure:
Something is leaking memory on my system such that "everything" starts
"failing" and I have to reboot.
This isn't Modula-3 related.
Hopefully these files aren't damaged as a result.
Must be some buggy driver or something..
 
Aside:
 The environment variable thingy has been bugging me a long time and I
finally looked deeper at it.
It appears broken in CM3 4.x. I didn't check 3.x yet.
I'm still mulling a fix, and haven't run a repro of the break, but it's
not a big deal either way.
Basically console apps use main that takes char** and gui apps use
WinMain that doesn't get environment variables but the generated code
calls GetEvironmentStrings() which returns null separated strings.
Must be that hardly anyone uses environment variables in Modula-3 on
Win32 for this to have lingered so long, at least gui apps.
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sat May 10 12:48:08 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 10 May 2008 10:48:08 +0000
Subject: [M3devel] pixmap problem
In-Reply-To: <48253B09.1E75.00D7.1@scires.com>
References: <479144D6.1E75.00D7.1@scires.com>
	<0CF197B5-1ADA-4955-904A-7B4ABACE7652@cs.purdue.edu>
	
	
	<481EE888.1E75.00D7.1@scires.com>
	
	<481F798E.1E75.00D7.1@scires.com><481F798E.1E75.00D7.1@scires.com>
	
	<481F8D50.1E75.00D7.1@scires.com><481F8D50.1E75.00D7.1@scires.com>
	
	<481F9804.1E75.00D7.1@scires.com><481F9804.1E75.00D7.1@scires.com>
	
	<482529C7.1E75.00D7.1@scires.com>
	<48253152.1E75.00D7.1@scires.com><48253152.1E75.00D7.1@scires.com>
	 
	<48253B09.1E75.00D7.1@scires.com>
Message-ID: 

Randy, 3.6 is still available for download on the web, and it still works.
 
I know exactly what my fix does and why it wasn't working before in the immediate past -- some set operations are dependent on data in m3core, in hand.c, and importing data from a .dll requires dereferencing a pointer to get the data. Whereas getting data from a static .lib does not. The pointer for data "foo" is usually called "__imp__foo", though that is just a convention implemented by the linker. So, let's say foo is a function. The generated code to call foo can be, and in Modula-3 always is, merely "call foo", or maybe "call _foo". x86 Windows tends to put a leading underscore on everything. That's a different matter. Now, again, foo is a function let's say, and the code says "call foo". Now, if foo ends up being imported from a .dll, what the linker does is generate a one instruction function like so:
 
foo:
  jmp dword ptr [__imp__foo]
 
And then __imp__foo is also special. __imp__foo is created such that at runtime, at load time, it is overwritten with the address of the actual location of the actual foo function in another .dll. All the __imp__ symbols are adjacent, so these writes aren't scattered around and written pages are kept to a minimum, at least in this regard.
 
Now, if you KNOW you are going to import foo, you can give the compiler a small optimization hint, and the compiler can "call dword ptr [__imp__foo]" directly, skipping the one instruction -- said instruction also having poor locality. As well, the Visual C++ compiler is smart enough to prefetch the instruction, and if you make repeated calls to an imported function, even keep it around in a register. There is no way to get this in Modula-3 today, and really it doesn't seem like a big deal to me. See, you know, if you don't know if foo will be dynamically linked or statically linked, "call foo" is reasonable efficient generic code. If you think it will be imported, you can generate "call dword ptr [__imp__foo]" instead, but then if you are wrong, either a) you get a link error, or b) you can go ahead and generate the pointer that points to the function, and you will pay an extra pointer dereference in the function calls, but at least not an extra instruction. As I wildly guess, calls to statically linked functions are more common than calls to dynamically linked functions, so erring toward making the static call more efficient seems better. On the other hand, it appears to me that Windows is alone here. My brief look into the Linux and Darwin calling conventions indicates they use big inefficient methods, worse than the "worst case" Windows uses, when you take either of the deoptimizations I describe. Granted, everyone else tends to get actually position independent code, and Windows does not. Windows get relocatable code, but not position independent, and the cost of the relocation can be high (every page written, loss of physical memory sharing, dirty pages backed by pagefile instead of the original .exe/.dll).
AMD64 Windows has mostly position independent code via the new RIP-relative addressing mode, but not fully. What often bites you is pointers in your data, like vtables. I do wish Windows had fully position independent code and I don't know if that would result in exactly the inefficient sequences I see on Linux and Darwin or not.
 
 
Ok now. That only mentioned functions. There was no mention of data.
You must pay close attention to particular details. In particular, the code always says "call foo" and if foo is imported, the linker generates a single instruction function, named foo, just like expected, that indirects through a pointer. You must indirect through a pointer for dynamic linking. And since there is a function call involved, a function can be generated to fit.
There's some saying here, like, you know that "any problem can be solved by an extra level of indirection", well, there's some corralary like "give me a function call and I can add indirection afterward".
 
But if you think about data, compiler generates something like "mov eax, foo" -- there's no way for the linker to intercede there -- there is no function call. It actually should fail to link. That is a different related matter. If you make the kind of error in C code that we have in Modula-3, you would get a link error. I'll show you in a sec. What happens in Modula-3, is, well, something, like mklib, doesn't know foo is data instead of a function, and goes ahead and generates foo that jmps through __imp__foo. That function foo is what these data references end up using, with fairly "random" results.
 
What my fix does is statically link in foo (_highbits, _lowbits). So the regular "mov eax, foo" works. No pointer derefence is needed for static linking, no __imp__ foo. I should go and fix the compiler to reference __imp__foo, and if we end up statically linked, like for standalone, there can be an extra pointer __imp_foo = &foo, and standalone will pay an extra, unnecessary, pointer deref.
 
Here is how you can see this problem in C.
 
  dll.c  
  __declspec(dllexport) int foo;  
   
  exe.c  
  extern int foo;   
  int main()  
 {  
   printf("%d\n", foo);    
  return 0;     }  
 
 cl -LD dll.c -link -noentry -nodefaultlib 
 rem really that's all it takes to make a .dll 
 cl exe.c dll.lib 
 rem really, that's it takes to build an .exe that uses the .dll 
 
 >> exe.obj : error LNK2019: unresolved external symbol foo referenced in function main 
 
But if you change it to:
 
  __declspec(dllimport) extern int foo;  
 
then it works. I don't fully understand this -- something somewhere knows that foo is data and doesn't generate the function for it. If you use a .def file, you mark the symbol as "data".
 
The GNU tools, ld --help, suggests some workaround here. That they let you generate the "wrong" code and the linker somehow makes it work. I don't know what it is..the only thing I can think of might not work and would look really ugly. I think link -dump crashes on ld output so I stopped looking..
 
I will look into 4.1 to determine what changed and why it worked.
 
The result in 5.x is actually not guaranteeably wrong, just very very difficult to predict the outcome of.
Instead of referencing the correct data, some fairly arbitrary data is used. But of course not every bit matters.
Could be the 4.1 code doesn't use the set operations here even, avoiding this problem.
We'll see. "There is no need to speculate; just debug it and know." :)
That's my own saying. I see so much unnecessary speculation and metaphorical throwing of hands in the air, and not enough debugging. :)  (Granted, something is screwy on my XP AMD64 machine and I'm more likely to reinstall than debug it...and maybe if it recurs then I'll debug some...can't do much without source and symbols though...that's where my debugging skills rapidly fall off...(which is a complaint I have about Modula-3, there's a certain lack of symbols for global data I believe, probably should be fixed...)) 
 
 - Jay


Date: Sat, 10 May 2008 06:05:02 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem

Jay:
 
I get correct behavior now for TestPixmap on d5.7 when built either way, with or without standalone option.
THANKS!
 
On 4.1, TestPixmap also works both ways.  The problem was occurring before your fix on d5.7 (and on earlier releases after 4.1).  Not sure what your fix does or what changed from 4.1 to d5.7 that made your fix necessary.
 
I am using your NT386 stuff for cm3.cfg now.
 
I don't have 3.6.
 
I will need to run tests now with d5.7 against my programs to see if they are working correctly before I can abandon 4.1.  Also, we will need to drive a stake in the ground at some point soon to create an official 5.7 release.  My company will want to be able to point to a given development environment for future support of the product I'm working on.  They won't accept a "d5.7" release that is in a state of flux.
 
Also, the other issue I'll have to work is getting all the GUI changes incorporated into this edition.  We will need the custom look&feel that CMass put together for us.  I'll check into it.  If I am successful, I can create a branch on CVS with this edition in case anyone else wants it.
 
Regards,
Randy>>> Jay  5/10/2008 5:38 AM >>>Randy, clarification, the bug occured when NOT building standalone.You must know that, since you reproed it recently.Just try both ways, both should work. (You don't have to take my cm3.cfg, but you do need NT386.common, and then either copy NT386 to cm3.cfg, or take NT386 and have cm3.cfg be just one line, include("NT386")) Any reason left for you to stick with 4.1? :)Something with serialio? At least one question does remain -- the TestPixmap behavior and why on 4.1.I'll look into that shortly.3.6 isn't relevant, since it didn't have .dlls. Thanks, - Jay


Date: Sat, 10 May 2008 05:23:35 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem
Jay:
 
I've performed the following and it seems to have fixed the problem with the TestPixmap program when built standalone:
 
1.  performed CVS update
2.  updated cm3.cfg and NT386* in \cm3\bin based on sources in cminstall\config
3.  scripts\win\upgrade
4.  scripts\win\do-cm3-std buildship
 
I checked the .lst file and I am now seeing "hand.obj"
 
Regards,
Randy>>> "Randy Coleburn"  5/10/2008 4:51 AM >>>
Jay:
 
I do not have python installed on my computer, so I can't run your scripts.
 
I used the scripts in scripts\win to upgrade a few days ago.
 
I am not seeing hand.obj in the .lst file.
 
I will do a CVS update and try the upgrade again followed by do-cm3-standard.
 
Regards,
Randy>>> Jay  5/9/2008 5:10 AM >>>
 > Also, more bad news, the pixmap problem is not solved. Randy, this DOES actually fix it, but you have to rebuild more. Try:   cd scripts\python    .\do-cm3-std.py realclean    .\upgrade.py   (probably not needed)    do-cm3-std.py buildship   Make sure "hand.obj" occurs in the various NT386\foo.lst files. I think the fix should be restated to have the code reference *__imp__highbits instead of highbits, and go back to dynamic linking the data.But ok for now. The std distribution I put yesterday should work, though it is missing the RTArgs fix.I'll see about making another.   - Jay


Date: Mon, 5 May 2008 23:28:10 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay:
 
Ok, I've copied your NT386 config stuff into the bin folder and I've copied NT386 to bin\cm3.cfg.
 
The good news is that my -gui mode programs now link and run.  The bad news is that now I am getting a command window opening up in addition to the GUI window when the program runs.  This behavior does not occur on v4.1.  The command window seems to be the stdout/stderr of the GUI program.
 
Also, more bad news, the pixmap problem is not solved.
 
And more bad news, your config stuff breaks the CM3-IDE program which needs to find certain definitions in cm3.cfg like PKG_USE, etc.
 
Regards,
Randy>>> Jay  5/5/2008 10:47 PM >>>Randy, Yes.The NT386 config files are all checked in.You can use them verbatim. You don't need cminstall, I never use it, and you shouldn't need to edit the config files at all, any edits I make, I check in, and should be usable on all machines.As long as you set %PATH%/%INCLUDE%/%LIB%.If I'm wrong, I'd like to know why and try to fix. Consider the config files just part of cm3.exe.Not generally to be changed locally. Unless, well, unless you intend to, and you should strive to make one form that is usable by all.  - Jay


Date: Mon, 5 May 2008 22:42:30 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comSubject: RE: [M3devel] pixmap problem
Jay,
When you say "took the updated config file", what do you mean?  Are you saying I need a different cm3.cfg file?
Regards,
Randy>>> Jay  5/5/2008 9:54 PM >>>And you took the updated config file?The way you can tell is that, roughly speaking, hand.obj should be in NT386\_m3responsefile0.txt.Or _m3responsefile1.txt, or, well, somewhere.Anyway, I think I saw the attachment, I can check later..and with 4.1 as I said.. I can see about making the fix not depend on config file changes...but it's not terrible asis, and I'd really like to merge more of the quake code into cm3.exe..  - Jay


Date: Mon, 5 May 2008 21:18:12 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem
Jay:
 
I've updated my sandbox via CVS and I've rebuilt everything.
 
I rebuilt the TestPixmap program, but it still does not work properly when the buildstandalone() directive is used.
 
Regards,
Randy>>> Jay  5/5/2008 7:04 PM >>>Thanks. I'll look into this tonight probably, as well as with 4.1 assuming I can find my binaries and source for it (probably).COULD BE the pixmap problem is something else and 4.1 also has the problem I fixed. We'll see. No need to speculate (unless I can't find my 4.1). - Jay


Date: Mon, 5 May 2008 10:59:27 -0400From: rcoleburn at scires.comTo: jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] pixmap problem
Jay:
 
The TestPixmap.zip is attached.
 
I will attempt to update all my sources and try again.
 
Not sure what you mean when you say that I must use your config files or edit what I am using.  Please elaborate.
 
The pixmap problem does not occur on 4.1.
 
Regards,
Randy>>> Jay  5/4/2008 11:46 AM >>>Randy, Please try with /current/ source, as of this morning Sunday May 4 -- the changes are ALL in NT386.common, so you MUST use MY config files, which are checked in verbatim, or you should be able edit whatever config files you are using. (It's not really a config file issue, don't blame the general confusion people have with them.) I'll try to try later, but I don't have the source right now, gotta look on other machines, and I think it's on a machine on loan.  Or send it to me again.I'd also like to know if this worked with 4.1, or with any release that offered dynamic linking to m3core.dll, on Windows.  I recall a claim that it did. If today's change fixes it, I should be able to investigate 4.1.3.6 did not have such linking.If today's change does not help, well, I still plan on debugging it at some point.. If you aren't current and getting so is difficult, just send the attachment again, it's easy for me to test. Thanks, - Jay


From: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; rcoleburn at scires.comDate: Sat, 19 Jan 2008 08:52:08 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] pixmap problem

I can repro the two different behaviors on XP.I was going to try on PPC_DARWIN but I guess Tony's info suffices. I tried rolling hand.c back to before I changed (months/year ago), since it is involved in bit twiddling, no change, phew. Debugging here is a big humungous pain.NT386 has good stacks and line numbers, but no locals or type info, I'd really sometime like to get Codeview info into those .objs...I think it is documented well enough, but still not necessarily easy, or maybe have a C generating backend partly for this reason (and to bring up more targets, using native tools), and function calls in disassembly I think don't resolve; NT386GNU can't yet build this, though it will soon, but I'm not familiar with gdb and there appears to be no type info. I'm building m3gdb right now, I don't know if it will work, I hope it has type info, and I'm not familiar with the relevant code. In gdb I struggle just to view bytes in memory, add numbers to addresses and see those, etc. I think for MY problem, I'm going to link in C code to dump the structs. There is tracing code and I enabled it, but even it crashes in Text_Length. At least MY problem crashes, hopefully near the problem, whereas your problem goes all the way through to completion with no stopping to hint where the problem is. Darn it. :) on the mock rudeness and :( on the lack of a crash. You write the bundle out and it matches, so that doesn't rule out bundles as being the problem? (darn)And bundles look pretty simple, a bundle is just a generated source file with a constant in it.Maybe newline problems? That wouldn't make sense. I just downloaded some program that might let me separately view the ppm, maybe it'll reveal something. The bad behavior has like regularly spaced solid color veritical bars a few pixels side across the whole picture, and regularly spaced vertical stripes from the correct picture alternating with that. Perhaps someone with ppm/bitmap/graphics experience has seen this behavior and it results from some common pixmap mismanagement we could look for? I have to say this is very surprising. I always wondered, and now I pretty much assume -- Modula-3 never imports/exports data in its dynamic linking, right? It alway imports/exports functions, right?On Windows, functions have an optional optimization, but data must be handled differently at compile time if it is going to be dynamically imported.For functions, if you don't apply the optimization at compile time, the linker will just generate a single instruction thunk instead. That is, given a symbol Foo, there is a symbol __imp__Foo that is a pointer to the actual foo in another .dll/.so.The loader only patches pointers, one per import if you build your .dll correctly, it doesn't patch instructions or code strewn throughout a .dll, just one contiguous array of pointers. MAYBE they don't have to be contiguous for each .dl you import from. That is, if call msvcrt!fopen, msvcrt!fclose, kernel32!Sleep, my .dll/.exe typically has an array: pointer to msvcrt!fopenpointer to msvcrt!fclosenullpointer to kernel32!Sleep But perhaps kernel32.dll's pointers and msvcrt.dll's pointers need not be adjacent. So, going back, my point/question is that, if the compiler knows the function is imported, it can call through __imp__Foo instead of calling Foo.But if it calls Foo and you import Foo, the linker will create the function Foo that just jmps through __imp__Foo.That doesn't work for data though. There's no ability to intervenve like that.So for imported data, the compiler must generated a read and dereference of the pointer __imp__Foo for accesses to Foo, if Foo is to be imported.Data imports may be faster when appropriate, but for this reason, I'd say they aren't worth it.And for this reason, I HOPE Modula-3 never imports/exports data. Oh, you could, for data, always reference the pointer __imp_Foo, and if non materializes, create one.However that would suck perf in order to make an uncommon case work.I hope Modula-3 doesn't do that either. :)Though I guess since this global data in question...maybe it is rare??? Later, - Jay

> From: hosking at cs.purdue.edu> Date: Sat, 19 Jan 2008 03:09:47 -0500> To: rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] pixmap problem> > Looks fine to me on I386_DARWIN.> > On Jan 19, 2008, at 12:31 AM, Randy Coleburn wrote:> > > > 

Need to know the score, the latest news, or you need your Hotmail?-get your "fix" Check it out. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sat May 10 17:40:40 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 10 May 2008 15:40:40 +0000
Subject: [M3devel] _lowbits / _highbits (Pixmap bug-- 4.1 vs. buggy 5.x)
Message-ID: 

There is SOME evidence that this lowbits/highbitsproblem is a regression introduced in Critical Mass 5.1.And there are inconsistent data.
(I believe 5.1 is the name given to the Critical Mass tree at the time it was open-sourced, vs. 4.1 which was commercially released, and some source withheld.)
 
The source history is a little incomplete.Critical Mass 4.1 did not ship with complete source.In particular, the compiler source is missing.Libraries are there.
 
Aside: I wonder if the 4.1 release can be made more widelyavailable, for purposes such as this. For one thing, I can contributehow to trivially patch the NT386 binary to not care about the registration key.I did buy it, but finding the key is..difficult.
 
The Elegosoft repository claims to have an import of 4.1 followed by an update to 5.1, but it is suspicious.
 
3.6 Stackx86.m3 -- no reference to  _lowbits / _highbits3.6 hand.c -- no implementation of ditto3.6 didn't offer dynamic linking, so it would have been ok.
 
The 4.1 CD includes the 3.6 source in "contrib" and some of the4.1 source in "source". That confused me at first, to have two of everything.I merely ASSUME what is what. I didn't look in detail.
 
4.1 CD hand.c -- no implementation of _lowbits / _highbits4.1 CD Stackx86.m3 -- source not available, darn it
 
4.1 in repository hand.c -- no implementation of ditto4.1 in repositoy Stackx86.m3 -- references _lowbits / _highbits
 
5.1 in repository hand.c -- implementation of ditto5.1 in repositoy Stackx86.m3 -- no change
 
The supposed 4.1 to 5.1 lack of diff (not that I understand CVS revision numbers or anything...) http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3back/src/Stackx86.m3.diff?r1=1.1;r2=1.1.1.1
 
introduction of _lowbits / _highbits in a more belieable 4.1 to 5.1 diff: http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/Csupport/Common/hand.c.diff?r1=1.1.1.1;r2=1.1.1.2
 
This is all a bit tedious so someone please double check me.
 
The 4.1 source in the repository is not self consistent.I contend it is wrong.I contend that the 4.1 Stackx86.m3 is more like the 3.6 -- no use of highbits / lowbits.
Since the symbols are not exported from the 4.1 CD m3core.dll nor are in the 4.1 CD hand.c source.
 
5.1 in the repository is self consistent, and I contend has the bug.
 
The 4.1 m3core.dll does export HiBits / LoBits -- different spelling, different casing,  and none of the .dlls in the system import them.
  Several versions have LoBits / HiBits be file-level static, further    implying they aren't used outside of hand.c.
  It is difficult for me to browse the old version of the tree however.  I guess I should try something like checkout -revision 1 and then search that locally?
  Inspection says that HiBits / LoBits went static in 2003 here:
 
 http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/Csupport/Common/hand.c
 
  and then later, I made them non-static FOR 32 BIT TARGETS, as part of merging them with  _lowbits / _highbits. This is a bit tangential, but the point is to exonerate  LoBits / HiBits of any involvement. _lowbits / _highbits are the relevant party.  They are nearly identical. See hand.c for how they relate. There is an extra  entry in one pair or the other, either at the start or the end, and one is uint and the  other ulong, when sizeof(uint) == sizeof(ulong), they share storage, my doing.  The NT386 compiler references _lowbits / _highbits. LoBits / HiBits are only used internally to hand.c.
  The gcc backend does not reference _lowbits / _highbits.
So obviously another fix is to go back to the 3.6 code and remove the symbols entirely.And make sure m3tests passes with that.I didn't look at the code yet.In general the code quality is not super high so it probably matters little.
Also obviously it would be prudent to review the code here to make sure it is correct,or to look at the relevant unit test and see if it seems comprhensive.
 
 
Thoughts?
 
 
Presume Critical Mass introduced the regression in 5.1, and give up attaining accurate 4.1 source??
I should findstr (grep) against the 4.1 cm3, but the lack of the symbols in its m3core is pretty conclusive.
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sun May 11 07:08:22 2008
From: jayk123 at hotmail.com (Jay)
Date: Sun, 11 May 2008 05:08:22 +0000
Subject: [M3devel] _lowbits / _highbits (Pixmap bug-- 4.1 vs. buggy 5.x)
Message-ID: 

Clarification: I now see that 3.6 did have these tables. They had different names. It appears they were generated for every ...I don't know, every source file or every .dll/.exe. That would work. That is similar to what we have now with my fix, though my fix statically links more than this -- everything in hand.obj.
 
D:\cm3-4.1\CONTRIB\SRC-M3\m3\m3back\src\Codex86.m3(2033):PROCEDURE init_intvar (t: T; size: ByteSize; f_lit: FLiteral; abscall: AbsCall;
D:\cm3-4.1\CONTRIB\SRC-M3\m3\m3back\src\Codex86.i3(96):TYPE IntnlVar = { Lowset_table, Highset_table };D:\cm3-4.1\CONTRIB\SRC-M3\m3\m3back\src\Codex86.m3(2077):      IntnlVar.Lowset_table =>D:\cm3-4.1\CONTRIB\SRC-M3\m3\m3back\src\Stackx86.m3(1953):                             o := ORD(IntnlVar.Lowset_table),
D:\cm3-4.1\CONTRIB\SRC-M3\m3\m3back\src\Stackx86.m3(34):        lowset_table  : MVar;D:\cm3-4.1\CONTRIB\SRC-M3\m3\m3back\src\Stackx86.m3(1298):        t.cg.tableOp(Op.oAND, stop2, stop0, 4, t.lowset_table);D:\cm3-4.1\CONTRIB\SRC-M3\m3\m3back\src\Stackx86.m3(1430):      t.cg.tableOp(Op.oMOV, t.cg.reg[maskreg], stop0, 4, t.lowset_table);D:\cm3-4.1\CONTRIB\SRC-M3\m3\m3back\src\Stackx86.m3(1443):      t.cg.tableOp(Op.oMOV, t.cg.reg[maskreg], stop0, 4, t.lowset_table);D:\cm3-4.1\CONTRIB\SRC-M3\m3\m3back\src\Stackx86.m3(1495):      intable := t.lowset_table;D:\cm3-4.1\CONTRIB\SRC-M3\m3\m3back\src\Stackx86.m3(1952):    t.lowset_table := MVar { var := t.cg.internalvar,
That at least clarifies there wasn't likely an older less efficient table-less codegen, just that the tables were gotten differently.
 
 - Jay


From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: _lowbits / _highbits (Pixmap bug-- 4.1 vs. buggy 5.x)Date: Sat, 10 May 2008 15:40:40 +0000


There is SOME evidence that this lowbits/highbitsproblem is a regression introduced in Critical Mass 5.1.And there are inconsistent data.(I believe 5.1 is the name given to the Critical Mass tree at the time it was open-sourced, vs. 4.1 which was commercially released, and some source withheld.) The source history is a little incomplete.Critical Mass 4.1 did not ship with complete source.In particular, the compiler source is missing.Libraries are there. Aside: I wonder if the 4.1 release can be made more widelyavailable, for purposes such as this. For one thing, I can contributehow to trivially patch the NT386 binary to not care about the registration key.I did buy it, but finding the key is..difficult. The Elegosoft repository claims to have an import of 4.1 followed by an update to 5.1, but it is suspicious. 3.6 Stackx86.m3 -- no reference to  _lowbits / _highbits3.6 hand.c -- no implementation of ditto3.6 didn't offer dynamic linking, so it would have been ok. The 4.1 CD includes the 3.6 source in "contrib" and some of the4.1 source in "source". That confused me at first, to have two of everything.I merely ASSUME what is what. I didn't look in detail. 4.1 CD hand.c -- no implementation of _lowbits / _highbits4.1 CD Stackx86.m3 -- source not available, darn it 4.1 in repository hand.c -- no implementation of ditto4.1 in repositoy Stackx86.m3 -- references _lowbits / _highbits 5.1 in repository hand.c -- implementation of ditto5.1 in repositoy Stackx86.m3 -- no change The supposed 4.1 to 5.1 lack of diff (not that I understand CVS revision numbers or anything...) http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3back/src/Stackx86.m3.diff?r1=1.1;r2=1.1.1.1 introduction of _lowbits / _highbits in a more belieable 4.1 to 5.1 diff: http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/Csupport/Common/hand.c.diff?r1=1.1.1.1;r2=1.1.1.2 This is all a bit tedious so someone please double check me. The 4.1 source in the repository is not self consistent.I contend it is wrong.I contend that the 4.1 Stackx86.m3 is more like the 3.6 -- no use of highbits / lowbits.Since the symbols are not exported from the 4.1 CD m3core.dll nor are in the 4.1 CD hand.c source. 5.1 in the repository is self consistent, and I contend has the bug. The 4.1 m3core.dll does export HiBits / LoBits -- different spelling, different casing,  and none of the .dlls in the system import them.  Several versions have LoBits / HiBits be file-level static, further    implying they aren't used outside of hand.c.  It is difficult for me to browse the old version of the tree however.  I guess I should try something like checkout -revision 1 and then search that locally?  Inspection says that HiBits / LoBits went static in 2003 here:  http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/Csupport/Common/hand.c   and then later, I made them non-static FOR 32 BIT TARGETS, as part of merging them with  _lowbits / _highbits. This is a bit tangential, but the point is to exonerate  LoBits / HiBits of any involvement. _lowbits / _highbits are the relevant party.  They are nearly identical. See hand.c for how they relate. There is an extra  entry in one pair or the other, either at the start or the end, and one is uint and the  other ulong, when sizeof(uint) == sizeof(ulong), they share storage, my doing.  The NT386 compiler references _lowbits / _highbits. LoBits / HiBits are only used internally to hand.c.  The gcc backend does not reference _lowbits / _highbits.So obviously another fix is to go back to the 3.6 code and remove the symbols entirely.And make sure m3tests passes with that.I didn't look at the code yet.In general the code quality is not super high so it probably matters little.Also obviously it would be prudent to review the code here to make sure it is correct,or to look at the relevant unit test and see if it seems comprhensive.  Thoughts?  Presume Critical Mass introduced the regression in 5.1, and give up attaining accurate 4.1 source??I should findstr (grep) against the 4.1 cm3, but the lack of the symbols in its m3core is pretty conclusive.  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sun May 11 07:45:31 2008
From: jayk123 at hotmail.com (Jay)
Date: Sun, 11 May 2008 05:45:31 +0000
Subject: [M3devel] RTLinker/RTArgs breaking change
Message-ID: 

RTLinker/RTArgs breaking change
I would like to cleanup my RTArgs change.
In particular, the interface among main <=> RTLinker <=> RTArgs
will change, on Windows.Posix should be unchanged.(Ok, at least Posix main <=> RTLinker unchanged, RTLinker <=> RTArgs maybe not).
One of the things holding me back is the knowledge thata current compiler must work against an old runtime,and the code did sometimes work.
However, m3-sys has no references to RTArgs,  nor to ".envp", so I am fairly confident that this can  be changed without breaking bootstrapping.
  My own near future experience implementing it should prove it one way or the other.
The change would be that for Win32 targets, MxGen.m3will always pass NIL for the envp parameter to RTLinker.InitRuntime.The parameter is ignored in current RTLinker with my recent change anyway.And then Win32/RTArgs will always just call GetEnvironmentStringsitself, ignoring RTLinker.envp.
RTLinker.envp should probably just go away, since it had no easily portable use.And then, RTLinker.InitRuntime should probably call a new functionRTArgs.SetEnv that would do nothing on Win32 and would set an internal variablein Posix/RTArgs.
That is, partly, since RTLinker.envp was fairly broken, remove it.RTArgs.GetEnv was also fairly broken, but repair it (it is already repaired).
As well, interfaces should have more functions and less data.
That is, as well, leverage that RTArgs is already platform-split, so use it  for "all" platform-specificity here. Well, as much as is reasonale.  MxGen would have a platform-switch as to what it is targeting.  My new RTLinkerC.c would go away. It could have been Modula-3 in the first place,   but it would have been platform-split.
ok?
This is really not a big deal actually.But I don't want to break bootstrapping a new compiler with an old runtime.My current fix, while a bit ugly, definitely does not break that, as  it avoided this change.
 
Another avenue is to clarify whether or not "envp" is always available from the C runtime,
such as via char** environ. I suspect it is. "But data imports are bad".
Win32 GUI and console apps could perhaps just use that.
 
Ah -- http://msdn.microsoft.com/en-us/library/aa246422(VS.60).aspx
Calling getenv("") forces environ to be initialized. Maybe reasonable.
There is an issue as to just how many copies of the environment there are..
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Tue May 13 01:35:16 2008
From: jayk123 at hotmail.com (Jay)
Date: Mon, 12 May 2008 23:35:16 +0000
Subject: [M3devel] eliminate Target.Global_handler_stack?
In-Reply-To: <20080511164932.GA4829@fuseki.my.domain>
References: 
	<20080511164932.GA4829@fuseki.my.domain> 
Message-ID: 

Target.Global_handler_stack is FALSE for targets that ever use kernel threads.Target.Global_handler_stack is TRUE for targets that never use kernel threads.
Targets that can go either way set it to FALSE.
 
When Global_handler_stack is TRUE, inline code is generated to,  I guess, manipulate a per-thread linked list of stack frames.
 
When Global_handler_stack is FALSE, function calls are generated  to do same.
 
That is, Global_handler_stack is TRUE is a little more efficient.
 
Given that Global_handler_stack is TRUE for all "recent", "active", "interesting"  targets, with the presumably temporary exception of PPC_LINUX, how about  we remove Global_handler_stack as a variable and just act as if it is always FALSE?
 
(I have some suspicion that this linked list is absent on targets with a stack walker, so it'd make no difference on them. I'll check later..NT386 ought use fs:0 but it doesn't.)
 
I figure target-specificity should be minimized.
Make it easier to bring up new targets -- not that the code isn't pretty
  well commented and easy to understand, so it's really no easier without this.
 
The counterpoints would be:  Even if it is target-specific, it does work and isn't complicated, so leave it alone.  If those old targets are alive, and lack pthreads, it is slightly faster this way.  If people want current/new targets to have a "faster" single threaded mode, this    could be part of that. Note though that single threaded apps can't/don't exist,
   unless maybe if you never heap allocate, since the heap allocator/garbage collector
   creates a thread at initialization (shouldn't it wait for a heap allocation? Maybe.
   If there really is a chance it won't occur or won't occur for a while).
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From hosking at cs.purdue.edu  Tue May 13 01:43:35 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 12 May 2008 19:43:35 -0400
Subject: [M3devel] eliminate Target.Global_handler_stack?
In-Reply-To: 
References: 
	<20080511164932.GA4829@fuseki.my.domain>
	
Message-ID: 


On May 12, 2008, at 7:35 PM, Jay wrote:

> Target.Global_handler_stack is FALSE for targets that ever use  
> kernel threads.
> Target.Global_handler_stack is TRUE for targets that never use  
> kernel threads.
> Targets that can go either way set it to FALSE.
>
>
> When Global_handler_stack is TRUE, inline code is generated to,
>   I guess, manipulate a per-thread linked list of stack frames.
>
>
> When Global_handler_stack is FALSE, function calls are generated
>   to do same.
>
>
> That is, Global_handler_stack is TRUE is a little more efficient.
>
>
> Given that Global_handler_stack is TRUE for all "recent", "active",  
> "interesting"
>   targets, with the presumably temporary exception of PPC_LINUX, how  
> about
>   we remove Global_handler_stack as a variable and just act as if it  
> is always FALSE?

Don't you mean "false" for all current targets (i.e., using threads)?

> (I have some suspicion that this linked list is absent on targets
> with a stack walker, so it'd make no difference on them. I'll check  
> later..
> NT386 ought use fs:0 but it doesn't.)

Indeed, the list is absent on such targets.

> I figure target-specificity should be minimized.
> Make it easier to bring up new targets -- not that the code isn't  
> pretty
>   well commented and easy to understand, so it's really no easier  
> without this.

I have no  objection.

> The counterpoints would be:
>   Even if it is target-specific, it does work and isn't complicated,  
> so leave it alone.
>   If those old targets are alive, and lack pthreads, it is slightly  
> faster this way.
>   If people want current/new targets to have a "faster" single  
> threaded mode, this
>    could be part of that. Note though that single threaded apps  
> can't/don't exist,
>    unless maybe if you never heap allocate, since the heap allocator/ 
> garbage collector
>    creates a thread at initialization (shouldn't it wait for a heap  
> allocation? Maybe.
>    If there really is a chance it won't occur or won't occur for a  
> while).

When does the GC currently create a thread?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Tue May 13 02:23:43 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 13 May 2008 00:23:43 +0000
Subject: [M3devel] eliminate Target.Global_handler_stack?
In-Reply-To: 
References: 
	<20080511164932.GA4829@fuseki.my.domain>
	
	
Message-ID: 

Tony, Yep, I got my true/false backwards at least once.
 
 > I have no  objection. 
 
Thanks. Expect a few deleted lines "soon".
 
 > When does the GC currently create a thread?
 
I'd have to double check. I thought it was in RTAllocator's module initialization. But maybe not.
No mystery here, just that I'm out of Modula-3 mode for a few hours.
It might be on-demand actually -- which would then have to be synchronized -- so doing it early might be preferable..er...well...actually..problem either way I now realize, depending..
 
There is this interesting useful but problematic aspect of .dlls on Windows.
.dlls have an "entry point", a "main" if you will. Usually called DllMain, but the name can be anything. It isn't exported, it's a field in the file format. The signature is
BOOLEAN DlMain(int reason, ADDRESS opaqueHandleToSelf, ADDRESS additionalBit);
 
The reasons are
  process attach, process detach, thread attach, thread detach 
  the opaqueHandleToSelf can be used for example to load "resources" from yourself
  additionalBit has a null vs. non-null meaning
    when reason == process detach, the nullness indicates if the .dll is being unloaded because the process is going away, or it is being unloaded but the process is staying around -- if the process is going away, basically nothing should be done, if the process is not going away, cleanup any process-global resources 
 
Process attach means the .dll was "just" loaded.
 
If you return false for failure from process attach, then the process will fail to launch or the LoadLibrary (dlopen) will fail, depending on if you are a static dependency of the .exe, or dynamically loaded via LoadLibrary (dlopen).
 
I believe the return values from all the other reasons are ignored.
 
There are many oddities here. Including the fact that threads can be created before the .dll loads and destroyed after it unloads, so the interface of thread attach/detach isn't what it seems -- you don't necessarily get the calls, you only get the calls for threads created/destroyed while you are already loaded (and perhaps one extra when you get loaded/unloaded?)
 
Folks who think they can do their per-thread cleanup in thread detach are sorely wrong.
What you have to do is keep all your thread-locals in a global list and free them in process detach.
Or just don't have any, that's the best policy.
 
Now, the important aspect here is that there is a lock around all DllMain calls, be they the process or thread ones.
 
This is "useful" because it means you can initialize your globals without worrying about synchronization.
Now, because of the lock, there isn't much you can do without risking deadlock.
But you would typically limit your activities to heap allocation, TlsAlloc (pthread_threadspecific_allocate_key or such), and critical section initialization. Win32 critical sections sadly require an initialization call, rather than just being initialized to all zeros. There's an API in Vista to allow static initialization.
(Cygwin's pthreads stuff also doesn't have zero initialization, but at least static).
 
On-demand initialization outside of DllMain must be synchronized, as threads can be created fairly arbitrarily early.
If you create a thread in DllMain, it essentially won't start until all the DllMains return.
It is possible though to have multiple threads running concurrently with "main".
 
And just because "you" don't create a thread in your app/.exe, doesn't mean some .dll you loaded didn't create some.
There's no such thing as a single-threaded process.
 
I suspect there is therefore a problem here in Modula-3. Or at least some double checking needed -- around the thread safety of various initialization.
 
A common pattern in Win32 is /ROUGHLY/:
 
T* g_pt; // global pointer to a T
 
T* GetTheT(void)
{
  if (g_pt != NULL)
    return g_pt;
  T* pt = new T();
  MemoryBarrier(); // ensure T's constructor finished before storing the global pointer
  if (InterlockedCompareExchangePointer(&g_pt, pt, NULL) != NULL)
   {
     // somebody else won the race
    delete pt;
   }
   return g_pt;
}
 
This way, initialization is done on-demand and thread safely.
This code assumes that race conditions will be rare vs. the expense of creating a T that is thrown away, and that creating, multiple T's in the event of a race, only to cleanup all but one right away, is ok.
 
If you must not ever create more than one T, then other code is needed.
Easiest is to initialize a critical section in DllMain and then just use that.
 
Or implement a little spin lock, assuming initialization of T is cheap.
 
In Vista there is a "once" synchronization object for handling this.
It is very disappointing that this wasn't introduced 10+ years ago.
As well as statically initializable locks and reader/writer locks.
 
I keep tending to think that Modula-3 module intializers have this same lock, at least on Windows.
But that is definitely NOT necessariiy true, at least in the face of static linking, and probably even with dynamic linking, since Modula-3 implements this stuff itself.
 
I'll have to review the code. Maybe it is just fine already.
 
If it isn't, well, there are a few easy solutions.
As well, this could be a problem on all platforms.
So it might make sense for the runtime to recognize when it is calling module initializers and endeavor to "not start" any threads while they are running.
 
Corrallary, on Win32, and in this scheme, that if you create  a thread in DllMain/thread initializer and then wait for it to make progress, you deadlock.
 
Gotta run,
 - Jay


CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] eliminate Target.Global_handler_stack?Date: Mon, 12 May 2008 19:43:35 -0400

On May 12, 2008, at 7:35 PM, Jay wrote:

Target.Global_handler_stack is FALSE for targets that ever use kernel threads.Target.Global_handler_stack is TRUE for targets that never use kernel threads.Targets that can go either way set it to FALSE. When Global_handler_stack is TRUE, inline code is generated to,  I guess, manipulate a per-thread linked list of stack frames. When Global_handler_stack is FALSE, function calls are generated  to do same. That is, Global_handler_stack is TRUE is a little more efficient. Given that Global_handler_stack is TRUE for all "recent", "active", "interesting"  targets, with the presumably temporary exception of PPC_LINUX, how about  we remove Global_handler_stack as a variable and just act as if it is always FALSE?
Don't you mean "false" for all current targets (i.e., using threads)?


(I have some suspicion that this linked list is absent on targets with a stack walker, so it'd make no difference on them. I'll check later..NT386 ought use fs:0 but it doesn't.)

Indeed, the list is absent on such targets.

I figure target-specificity should be minimized.Make it easier to bring up new targets -- not that the code isn't pretty  well commented and easy to understand, so it's really no easier without this.
I have no  objection. 


The counterpoints would be:  Even if it is target-specific, it does work and isn't complicated, so leave it alone.  If those old targets are alive, and lack pthreads, it is slightly faster this way.  If people want current/new targets to have a "faster" single threaded mode, this    could be part of that. Note though that single threaded apps can't/don't exist,   unless maybe if you never heap allocate, since the heap allocator/garbage collector   creates a thread at initialization (shouldn't it wait for a heap allocation? Maybe.   If there really is a chance it won't occur or won't occur for a while).

When does the GC currently create a thread?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Tue May 13 03:09:12 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 13 May 2008 01:09:12 +0000
Subject: [M3devel] FW:  eliminate Target.Global_handler_stack?
In-Reply-To: 
References: 
	<20080511164932.GA4829@fuseki.my.domain>
	
	 
Message-ID: 

 truncated yet again..
Olaf is there anything in any mail log on your end?
 
 - Jay


From: jayk123 at hotmail.comTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] eliminate Target.Global_handler_stack?Date: Tue, 13 May 2008 00:23:43 +0000


Tony, Yep, I got my true/false backwards at least once.  > I have no  objection.  Thanks. Expect a few deleted lines "soon". 
 > When does the GC currently create a thread? I'd have to double check. I thought it was in RTAllocator's module initialization. But maybe not.No mystery here, just that I'm out of Modula-3 mode for a few hours.It might be on-demand actually -- which would then have to be synchronized -- so doing it early might be preferable..er...well...actually..problem either way I now realize, depending.. There is this interesting useful but problematic aspect of .dlls on Windows..dlls have an "entry point", a "main" if you will. Usually called DllMain, but the name can be anything. It isn't exported, it's a field in the file format. The signature isBOOLEAN DlMain(int reason, ADDRESS opaqueHandleToSelf, ADDRESS additionalBit); The reasons are  process attach, process detach, thread attach, thread detach   the opaqueHandleToSelf can be used for example to load "resources" from yourself  additionalBit has a null vs. non-null meaning    when reason == process detach, the nullness indicates if the .dll is being unloaded because the process is going away, or it is being unloaded but the process is staying around -- if the process is going away, basically nothing should be done, if the process is not going away, cleanup any process-global resources  Process attach means the .dll was "just" loaded. If you return false for failure from process attach, then the process will fail to launch or the LoadLibrary (dlopen) will fail, depending on if you are a static dependency of the .exe, or dynamically loaded via LoadLibrary (dlopen). I believe the return values from all the other reasons are ignored. There are many oddities here. Including the fact that threads can be created before the .dll loads and destroyed after it unloads, so the interface of thread attach/detach isn't what it seems -- you don't necessarily get the calls, you only get the calls for threads created/destroyed while you are already loaded (and perhaps one extra when you get loaded/unloaded?) Folks who think they can do their per-thread cleanup in thread detach are sorely wrong.What you have to do is keep all your thread-locals in a global list and free them in process detach.Or just don't have any, that's the best policy. Now, the important aspect here is that there is a lock around all DllMain calls, be they the process or thread ones. This is "useful" because it means you can initialize your globals without worrying about synchronization.Now, because of the lock, there isn't much you can do without risking deadlock.But you would typically limit your activities to heap allocation, TlsAlloc (pthread_threadspecific_allocate_key or such), and critical section initialization. Win32 critical sections sadly require an initialization call, rather than just being initialized to all zeros. There's an API in Vista to allow static initialization.(Cygwin's pthreads stuff also doesn't have zero initialization, but at least static). On-demand initialization outside of DllMain must be synchronized, as threads can be created fairly arbitrarily early.If you create a thread in DllMain, it essentially won't start until all the DllMains return.It is possible though to have multiple threads running concurrently with "main". And just because "you" don't create a thread in your app/.exe, doesn't mean some .dll you loaded didn't create some.There's no such thing as a single-threaded process. I suspect there is therefore a problem here in Modula-3. Or at least some double checking needed -- around the thread safety of various initialization. A common pattern in Win32 is /ROUGHLY/: T* g_pt; // global pointer to a T T* GetTheT(void){  if (g_pt != NULL)    return g_pt;  T* pt = new T();  MemoryBarrier(); // ensure T's constructor finished before storing the global pointer  if (InterlockedCompareExchangePointer(&g_pt, pt, NULL) != NULL)   {     // somebody else won the race    delete pt;   }   return g_pt;} This way, initialization is done on-demand and thread safely.This code assumes that race conditions will be rare vs. the expense of creating a T that is thrown away, and that creating, multiple T's in the event of a race, only to cleanup all but one right away, is ok. If you must not ever create more than one T, then other code is needed.Easiest is to initialize a critical section in DllMain and then just use that. Or implement a little spin lock, assuming initialization of T is cheap. In Vista there is a "once" synchronization object for handling this.It is very disappointing that this wasn't introduced 10+ years ago.As well as statically initializable locks and reader/writer locks. I keep tending to think that Modula-3 module intializers have this same lock, at least on Windows.But that is definitely NOT necessariiy true, at least in the face of static linking, and probably even with dynamic linking, since Modula-3 implements this stuff itself. I'll have to review the code. Maybe it is just fine already. If it isn't, well, there are a few easy solutions.As well, this could be a problem on all platforms.So it might make sense for the runtime to recognize when it is calling module initializers and endeavor to "not start" any threads while they are running. Corrallary, on Win32, and in this scheme, that if you create  a thread in DllMain/thread initializer and then wait for it to make progress, you deadlock. Gotta run, - Jay


CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] eliminate Target.Global_handler_stack?Date: Mon, 12 May 2008 19:43:35 -0400

On May 12, 2008, at 7:35 PM, Jay wrote:

Target.Global_handler_stack is FALSE for targets that ever use kernel threads.Target.Global_handler_stack is TRUE for targets that never use kernel threads.Targets that can go either way set it to FALSE. When Global_handler_stack is TRUE, inline code is generated to,  I guess, manipulate a per-thread linked list of stack frames. When Global_handler_stack is FALSE, function calls are generated  to do same. That is, Global_handler_stack is TRUE is a little more efficient. Given that Global_handler_stack is TRUE for all "recent", "active", "interesting"  targets, with the presumably temporary exception of PPC_LINUX, how about  we remove Global_handler_stack as a variable and just act as if it is always FALSE?
Don't you mean "false" for all current targets (i.e., using threads)?


(I have some suspicion that this linked list is absent on targets with a stack walker, so it'd make no difference on them. I'll check later..NT386 ought use fs:0 but it doesn't.)

Indeed, the list is absent on such targets.

I figure target-specificity should be minimized.Make it easier to bring up new targets -- not that the code isn't pretty  well commented and easy to understand, so it's really no easier without this.
I have no  objection. 


The counterpoints would be:  Even if it is target-specific, it does work and isn't complicated, so leave it alone.  If those old targets are alive, and lack pthreads, it is slightly faster this way.  If people want current/new targets to have a "faster" single threaded mode, this    could be part of that. Note though that single threaded apps can't/don't exist,   unless maybe if you never heap allocate, since the heap allocator/garbage collector   creates a thread at initialization (shouldn't it wait for a heap allocation? Maybe.   If there really is a chance it won't occur or won't occur for a while).

When does the GC currently create a thread?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Tue May 13 15:52:08 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 13 May 2008 13:52:08 +0000
Subject: [M3devel] open vs. fixed arrays?
Message-ID: 




I'm being a bit lazy here. I could experiment more with the compiler and check the green book.  The compiler does not correctly implement:    VAR a : ARRAY [0..0] OF CHAR := ARRAY OF CHAR {'a'};  at least for reasons of alignment.  What is this code supposed to mean?  Is ARRAY OF CHAR {'a'} a constant fixed array with a deduced size of 1?Or a constant open array with a deduced size of 1?I believe it is supposed to be a constant open array.  And then, what is the difference?What are the visible differences?  Between  VAR a : ARRAY [0..0] OF CHAR := ARRAY OF CHAR {'a'};and  VAR a : ARRAY [0..0] OF CHAR := ARRAY [0..0] OF CHAR {'a'}; Can I act on "a" different at runtime between the two?Given that its static type is the same, I doubt it. But I haven't really thought about it.  If there is no visible difference, should the compiler implement it as the second -- probably saving a tiny bit of space.  And if not, is it supposed to generate an open array, and an initializer to do the copy?  A constant likeCONST a = ARRAY OF CHAR{'a'}  is an open array I believe, with visible differences, I think, not sure,so in the unlikely even that a "bigger" change is ok here, it has to be careful of this and other scenarios.  Really, I'm just being a bit slow. I bet these should remain open arrays but somewhere the compiler gets confused and computes the alignment and perhaps size as a fixed array, leading to assertion failures in the compiler, depending on the actual sizes, e.g.:  MODULE Main;<*UNUSED*> VAR a : ARRAY [0..0] OF CHAR := ARRAY OF CHAR {'a'};<*UNUSED*> VAR b : ARRAY OF CHAR := ARRAY OF CHAR {'a'};BEGINEND.  fails an assertion in the compiler, depending on the target -- but I expect all x86/AMD64 targets. Thanks,  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From hosking at cs.purdue.edu  Tue May 13 17:28:24 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 13 May 2008 11:28:24 -0400
Subject: [M3devel] open vs. fixed arrays?
In-Reply-To: 
References: 
Message-ID: 


On May 13, 2008, at 9:52 AM, Jay wrote:

> I'm being a bit lazy here. I could experiment more with the compiler  
> and check the green book.
>
>
> The compiler does not correctly implement:
>
>
>
>  VAR a : ARRAY [0..0] OF CHAR := ARRAY OF CHAR {'a'};
>
> at least for reasons of alignment.
>
>
> What is this code supposed to mean?
It should assign the elements of the open array to those of the fixed  
array.
>
>
>
> Is ARRAY OF CHAR {'a'} a constant fixed array with a deduced size of  
> 1?

No, it is open.

>
> Or a constant open array with a deduced size of 1?
No.
> I believe it is supposed to be a constant open array.
Yes.

>
>
> And then, what is the difference?
> What are the visible differences?
>
>
> Between
>
>  VAR a : ARRAY [0..0] OF CHAR := ARRAY OF CHAR {'a'};
> and
>   VAR a : ARRAY [0..0] OF CHAR := ARRAY [0..0] OF CHAR {'a'};
>
> Can I act on "a" different at runtime between the two?
> Given that its static type is the same, I doubt it. But I haven't  
> really thought about it.
>
>
> If there is no visible difference, should the compiler implement it  
> as the second -- probably saving a tiny bit of space.
>
>
> And if not, is it supposed to generate an open array, and an  
> initializer to do the copy?
Probably should.

>
>
>
> A constant like
> CONST a = ARRAY OF CHAR{'a'}
>
>
> is an open array I believe, with visible differences, I think, not  
> sure,
> so in the unlikely even that a "bigger" change is ok here, it has to  
> be careful of this and other scenarios.
>
>
> Really, I'm just being a bit slow. I bet these should remain open  
> arrays but somewhere the compiler gets confused and computes the  
> alignment and perhaps size as a fixed array, leading to assertion  
> failures in the compiler, depending on the actual sizes, e.g.:
>
>
> MODULE Main;
> <*UNUSED*> VAR a : ARRAY [0..0] OF CHAR := ARRAY OF CHAR {'a'};
> <*UNUSED*> VAR b : ARRAY OF CHAR := ARRAY OF CHAR {'a'};
> BEGIN
> END.
>
>
> fails an assertion in the compiler, depending on the target -- but I  
> expect all x86/AMD64 targets.
>
> Thanks,
>  - Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Wed May 14 19:18:54 2008
From: jayk123 at hotmail.com (Jay)
Date: Wed, 14 May 2008 17:18:54 +0000
Subject: [M3devel] _lowbits / _highbits (Pixmap bug-- 4.1 vs. buggy 5.x)
In-Reply-To: 
References: 
Message-ID: 

1) Just fyi, NT386GNU didn't build with my fix, so it is disabled there only, and the bug could very well be present there.
Er, then again, this stuff works differently for the gcc backend, so I don't know, I'll have to look, and run the tests, not today.
Which reminds me also, these symbols should be static hand.c, except for NT386 -- the source can't tell, so it'll have to be a define from the m3makefile.
 
2) Can anyone confirm my history and the missing source?
ie: Confirm that what is marked as 4.1 and 5.1 in CVS really is 4.1 and 5.1? I don't think 4.1 is accurately marked.
In particular, I don't think the 4.1 Stackx86.m3  is what 4.1 actually shipped.
 
3) Or confirm my analysis that leads to the "accusation"? It was tedious.
 
 - Jay


From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Sat, 10 May 2008 15:40:40 +0000Subject: [M3devel] _lowbits / _highbits (Pixmap bug-- 4.1 vs. buggy 5.x)


There is SOME evidence that this lowbits/highbitsproblem is a regression introduced in Critical Mass 5.1.And there are inconsistent data.(I believe 5.1 is the name given to the Critical Mass tree at the time it was open-sourced, vs. 4.1 which was commercially released, and some source withheld.) The source history is a little incomplete.Critical Mass 4.1 did not ship with complete source.In particular, the compiler source is missing.Libraries are there. Aside: I wonder if the 4.1 release can be made more widelyavailable, for purposes such as this. For one thing, I can contributehow to trivially patch the NT386 binary to not care about the registration key.I did buy it, but finding the key is..difficult. The Elegosoft repository claims to have an import of 4.1 followed by an update to 5.1, but it is suspicious. 3.6 Stackx86.m3 -- no reference to  _lowbits / _highbits3.6 hand.c -- no implementation of ditto3.6 didn't offer dynamic linking, so it would have been ok. The 4.1 CD includes the 3.6 source in "contrib" and some of the4.1 source in "source". That confused me at first, to have two of everything.I merely ASSUME what is what. I didn't look in detail. 4.1 CD hand.c -- no implementation of _lowbits / _highbits4.1 CD Stackx86.m3 -- source not available, darn it 4.1 in repository hand.c -- no implementation of ditto4.1 in repositoy Stackx86.m3 -- references _lowbits / _highbits 5.1 in repository hand.c -- implementation of ditto5.1 in repositoy Stackx86.m3 -- no change The supposed 4.1 to 5.1 lack of diff (not that I understand CVS revision numbers or anything...) http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3back/src/Stackx86.m3.diff?r1=1.1;r2=1.1.1.1 introduction of _lowbits / _highbits in a more belieable 4.1 to 5.1 diff: http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/Csupport/Common/hand.c.diff?r1=1.1.1.1;r2=1.1.1.2 This is all a bit tedious so someone please double check me. The 4.1 source in the repository is not self consistent.I contend it is wrong.I contend that the 4.1 Stackx86.m3 is more like the 3.6 -- no use of highbits / lowbits.Since the symbols are not exported from the 4.1 CD m3core.dll nor are in the 4.1 CD hand.c source. 5.1 in the repository is self consistent, and I contend has the bug. The 4.1 m3core.dll does export HiBits / LoBits -- different spelling, different casing,  and none of the .dlls in the system import them.  Several versions have LoBits / HiBits be file-level static, further    implying they aren't used outside of hand.c.  It is difficult for me to browse the old version of the tree however.  I guess I should try something like checkout -revision 1 and then search that locally?  Inspection says that HiBits / LoBits went static in 2003 here:  http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/Csupport/Common/hand.c   and then later, I made them non-static FOR 32 BIT TARGETS, as part of merging them with  _lowbits / _highbits. This is a bit tangential, but the point is to exonerate  LoBits / HiBits of any involvement. _lowbits / _highbits are the relevant party.  They are nearly identical. See hand.c for how they relate. There is an extra  entry in one pair or the other, either at the start or the end, and one is uint and the  other ulong, when sizeof(uint) == sizeof(ulong), they share storage, my doing.  The NT386 compiler references _lowbits / _highbits. LoBits / HiBits are only used internally to hand.c.  The gcc backend does not reference _lowbits / _highbits.So obviously another fix is to go back to the 3.6 code and remove the symbols entirely.And make sure m3tests passes with that.I didn't look at the code yet.In general the code quality is not super high so it probably matters little.Also obviously it would be prudent to review the code here to make sure it is correct,or to look at the relevant unit test and see if it seems comprhensive.  Thoughts?  Presume Critical Mass introduced the regression in 5.1, and give up attaining accurate 4.1 source??I should findstr (grep) against the 4.1 cm3, but the lack of the symbols in its m3core is pretty conclusive.  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Wed May 14 19:25:38 2008
From: jayk123 at hotmail.com (Jay)
Date: Wed, 14 May 2008 17:25:38 +0000
Subject: [M3devel] which platforms?
In-Reply-To: 
References: 
Message-ID: 

What do people run?In particular: NetBSD? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN? I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM_WINCE? AMD64_NT?
 
Just curious, I'll probably bring up whatever I can, it's fun, and yes, get back and fix AMD64_LINUX to have
garbage collection, NT386GNU and NT386 tests, cross-platform sets, setup some Tinderboxes, etc...
 
(AMD64_NT: the gcc available for this includes a bunch of patches, so I'm inclined to either wait for them to go upstream,
or seek an alternate route such as "port" the in-proc backend, llvm, generate C, or maybe write an interpreter for the IL;
and "porting" the backend is probably best preceded by a) x86 LONGINT support b) other x86 targets "for practise", at least one,
though regarding .obj file formats, that would be tangential.)
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Wed May 14 19:46:15 2008
From: jayk123 at hotmail.com (Jay)
Date: Wed, 14 May 2008 17:46:15 +0000
Subject: [M3devel] SPARC32_LINUX
In-Reply-To: 
References: 
Message-ID: 





  I was having some hardware/network problem and as an indirect result, am not running Linux/sparc for a bit.         I was going to make distributions and bring up SPARC64_LINUX, but it'll wait some.          If anyone can help me a bit with Sun-specific problems, please ping me privately.       In the meantime, there is:       http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-base-POSIX-SPARC32_LINUX-1.tar.bz2       It should be called "boot", but something didn't like that.       roughly:       wget http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-base-POSIX-SPARC32_LINUX-1.tar.bz2    tar xf cm3-base-POSIX-SPARC32_LINUX-1.tar.bz2    cd cm3-boot-POSIX-SPARC32_LINUX-1    . ./1.sh    mkdir -p /cm3/bin   cp exe/cm3 /cm3/bin   export PATH=/cm3/bin:$PATH   cd $CVSROOT/scripts/python      ./upgrade.py    and then optionally ./make-dist.py    
 
or, I'm not sure upgrade ships/installs/copies cm3cg, so:
  cd $CVSROOT/scripts/python      ./do-pkg.py m3cc 
  cp ../../m3-sys/m3cc/SPARC32_LINUX/cm3cg /cm3/bin    OMIT_GCC=yes ./upgrade.py         SHOULD work. /usr/local/cm3 should work, but I find that rather long.Actually I never built beyond "front".   And dynamic linking and garbage collection are both off, for now.      Then again, I suspect nobody runs Linux on SPARC, esp. not here.   It was educational though to bring up a platform on which I couldnot rely on an existing ability to run cm3.
I'll TRY to get back and tie up a bunch of loose ends, there are a lot now, I know..
    - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From hosking at cs.purdue.edu  Thu May 15 17:44:21 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 15 May 2008 11:44:21 -0400
Subject: [M3devel] which platforms?
In-Reply-To: 
References: 
	
Message-ID: <6AF85D14-364B-4155-A186-840119342DF7@cs.purdue.edu>


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



On May 14, 2008, at 1:25 PM, Jay wrote:

> What do people run?
> In particular: NetBSD? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN?  
> I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM_WINCE? AMD64_NT?
>
> Just curious, I'll probably bring up whatever I can, it's fun, and  
> yes, get back and fix AMD64_LINUX to have
> garbage collection, NT386GNU and NT386 tests, cross-platform sets,  
> setup some Tinderboxes, etc...
>
> (AMD64_NT: the gcc available for this includes a bunch of patches,  
> so I'm inclined to either wait for them to go upstream,
> or seek an alternate route such as "port" the in-proc backend, llvm,  
> generate C, or maybe write an interpreter for the IL;
> and "porting" the backend is probably best preceded by a) x86  
> LONGINT support b) other x86 targets "for practise", at least one,
> though regarding .obj file formats, that would be tangential.)
>
>  - Jay
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From hosking at cs.purdue.edu  Thu May 15 17:47:41 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 15 May 2008 11:47:41 -0400
Subject: [M3devel] which platforms?
In-Reply-To: 
References: 
	
Message-ID: <948C63CA-8763-46AE-9FDB-54DAF01CC28D@cs.purdue.edu>

SOLgnu
PPC_DARWIN
I386_DARWIN
AMD64_DARWIN
LINUXLIBC6
I'd like AMD64_LINUX, SPARC64_SOLARISN but no time right now to devote  
to them.

On May 14, 2008, at 1:25 PM, Jay wrote:

> What do people run?
> In particular: NetBSD? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN?  
> I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM_WINCE? AMD64_NT?
>
> Just curious, I'll probably bring up whatever I can, it's fun, and  
> yes, get back and fix AMD64_LINUX to have
> garbage collection, NT386GNU and NT386 tests, cross-platform sets,  
> setup some Tinderboxes, etc...
>
> (AMD64_NT: the gcc available for this includes a bunch of patches,  
> so I'm inclined to either wait for them to go upstream,
> or seek an alternate route such as "port" the in-proc backend, llvm,  
> generate C, or maybe write an interpreter for the IL;
> and "porting" the backend is probably best preceded by a) x86  
> LONGINT support b) other x86 targets "for practise", at least one,
> though regarding .obj file formats, that would be tangential.)
>
>  - Jay
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From darko at darko.org  Thu May 15 21:50:31 2008
From: darko at darko.org (Darko)
Date: Thu, 15 May 2008 21:50:31 +0200
Subject: [M3devel] which platforms?
In-Reply-To: 
References: 
	
Message-ID: <4599968C-BCFA-4A5E-B50A-7E1A589B7C30@darko.org>

I'd really like to see some ARM backends in particular ARM_DARWIN  
(iPod Touch, iPhone), ARM_NOKIA (on their Open C API) and ARM_WINCE.  
This would have CM3 the gamut from servers to small handheld devices.


On 14/05/2008, at 7:25 PM, Jay wrote:

> What do people run?
> In particular: NetBSD? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN?  
> I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM_WINCE? AMD64_NT?
>
> Just curious, I'll probably bring up whatever I can, it's fun, and  
> yes, get back and fix AMD64_LINUX to have
> garbage collection, NT386GNU and NT386 tests, cross-platform sets,  
> setup some Tinderboxes, etc...
>
> (AMD64_NT: the gcc available for this includes a bunch of patches,  
> so I'm inclined to either wait for them to go upstream,
> or seek an alternate route such as "port" the in-proc backend, llvm,  
> generate C, or maybe write an interpreter for the IL;
> and "porting" the backend is probably best preceded by a) x86  
> LONGINT support b) other x86 targets "for practise", at least one,
> though regarding .obj file formats, that would be tangential.)
>
>  - Jay
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Thu May 15 22:19:16 2008
From: jayk123 at hotmail.com (Jay)
Date: Thu, 15 May 2008 20:19:16 +0000
Subject: [M3devel] which platforms?
In-Reply-To: <4599968C-BCFA-4A5E-B50A-7E1A589B7C30@darko.org>
References: 
	
	<4599968C-BCFA-4A5E-B50A-7E1A589B7C30@darko.org>
Message-ID: 

Oh -- iPod Touch -- iPhone hardware/software without a service plan. Clever. :)
I don't know about Nokia but definitely CE and somewhat iPhone "intrigue" me (as in, I never use this stuff, but a port sounds interesting).
I'm hoping CE can be done with free beer emulators but I don't have anything up and running dev tool wise there, other than older command line compilers (for a bunch of CE -- arm, mips, powepc, sh, x86). I'm not confident gcc will move so easily to new Windows platforms, without significant patches, so C or LLVM might be good.
Yeah I wasn't sure ARM_IPHONE or ARM_DARWIN. :)
I'd still like to call it ARCH_MACOSX or ARCH_MACX oh well too late.
 
None of these things have X servers, right?
And gui is hard anyway on small screens, "less portable".
Port to Qt??
I'm not going there any time soon, very little familiarity with either Trestle or the underlying systems..
Headless servers and command line apps on phones for now. :)
 
 - Jay
 



CC: m3devel at elegosoft.comFrom: darko at darko.orgTo: jayk123 at hotmail.comSubject: Re: [M3devel] which platforms?Date: Thu, 15 May 2008 21:50:31 +0200

I'd really like to see some ARM backends in particular ARM_DARWIN (iPod Touch, iPhone), ARM_NOKIA (on their Open C API) and ARM_WINCE. This would have CM3 the gamut from servers to small handheld devices.


On 14/05/2008, at 7:25 PM, Jay wrote:

What do people run?In particular: NetBSD? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN? I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM_WINCE? AMD64_NT? Just curious, I'll probably bring up whatever I can, it's fun, and yes, get back and fix AMD64_LINUX to havegarbage collection, NT386GNU and NT386 tests, cross-platform sets, setup some Tinderboxes, etc... (AMD64_NT: the gcc available for this includes a bunch of patches, so I'm inclined to either wait for them to go upstream,or seek an alternate route such as "port" the in-proc backend, llvm, generate C, or maybe write an interpreter for the IL;and "porting" the backend is probably best preceded by a) x86 LONGINT support b) other x86 targets "for practise", at least one,though regarding .obj file formats, that would be tangential.)  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From darko at darko.org  Thu May 15 22:55:58 2008
From: darko at darko.org (Darko)
Date: Thu, 15 May 2008 22:55:58 +0200
Subject: [M3devel] which platforms?
In-Reply-To: 
References: 
	
	<4599968C-BCFA-4A5E-B50A-7E1A589B7C30@darko.org>
	
Message-ID: <21F3FBDA-3DE6-4DA0-951A-E5F4BE999F52@darko.org>

I haven't seen X for any of them but I guess its not beyond the realm  
of possibility. I'm mostly interested in native user interfaces and  
porting the native APIs for M3. Darwin is the name of lower levels of  
the OS of the Mac and iPhone and is open source, so its appropriate.

Apple provide a GCC for the ARM and Darwin. There is GCC for ARM under  
WinCE platforms. I would have though the issues are mainly with the M3  
runtime on these platforms.



On 15/05/2008, at 10:19 PM, Jay wrote:

> Oh -- iPod Touch -- iPhone hardware/software without a service plan.  
> Clever. :)
> I don't know about Nokia but definitely CE and somewhat iPhone  
> "intrigue" me (as in, I never use this stuff, but a port sounds  
> interesting).
> I'm hoping CE can be done with free beer emulators but I don't have  
> anything up and running dev tool wise there, other than older  
> command line compilers (for a bunch of CE -- arm, mips, powepc, sh,  
> x86). I'm not confident gcc will move so easily to new Windows  
> platforms, without significant patches, so C or LLVM might be good.
> Yeah I wasn't sure ARM_IPHONE or ARM_DARWIN. :)
> I'd still like to call it ARCH_MACOSX or ARCH_MACX oh well too late.
>
> None of these things have X servers, right?
> And gui is hard anyway on small screens, "less portable".
> Port to Qt??
> I'm not going there any time soon, very little familiarity with  
> either Trestle or the underlying systems..
> Headless servers and command line apps on phones for now. :)
>
>  - Jay
>
>
>
> CC: m3devel at elegosoft.com
> From: darko at darko.org
> To: jayk123 at hotmail.com
> Subject: Re: [M3devel] which platforms?
> Date: Thu, 15 May 2008 21:50:31 +0200
>
>
> I'd really like to see some ARM backends in particular ARM_DARWIN  
> (iPod Touch, iPhone), ARM_NOKIA (on their Open C API) and ARM_WINCE.  
> This would have CM3 the gamut from servers to small handheld devices.
>
>
> On 14/05/2008, at 7:25 PM, Jay wrote:
>
> What do people run?
> In particular: NetBSD? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN?  
> I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM_WINCE? AMD64_NT?
>
> Just curious, I'll probably bring up whatever I can, it's fun, and  
> yes, get back and fix AMD64_LINUX to have
> garbage collection, NT386GNU and NT386 tests, cross-platform sets,  
> setup some Tinderboxes, etc...
>
> (AMD64_NT: the gcc available for this includes a bunch of patches,  
> so I'm inclined to either wait for them to go upstream,
> or seek an alternate route such as "port" the in-proc backend, llvm,  
> generate C, or maybe write an interpreter for the IL;
> and "porting" the backend is probably best preceded by a) x86  
> LONGINT support b) other x86 targets "for practise", at least one,
> though regarding .obj file formats, that would be tangential.)
>
>  - Jay
>
>
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mika at async.caltech.edu  Thu May 15 23:30:36 2008
From: mika at async.caltech.edu (Mika Nystrom)
Date: Thu, 15 May 2008 14:30:36 -0700
Subject: [M3devel] which platforms?
In-Reply-To: Your message of "Thu, 15 May 2008 11:47:41 EDT."
	<948C63CA-8763-46AE-9FDB-54DAF01CC28D@cs.purdue.edu> 
Message-ID: <200805152130.m4FLUa9B060478@camembert.async.caltech.edu>

here it is:

FreeBSD4
PPC_DARWIN
NT386GNU
LINUXLIBC6

I386_DARWIN coming soon

Tony Hosking writes:
>
>--Apple-Mail-4-631028010
>Content-Type: text/plain;
>	charset=US-ASCII;
>	format=flowed;
>	delsp=yes
>Content-Transfer-Encoding: 7bit
>
>SOLgnu
>PPC_DARWIN
>I386_DARWIN
>AMD64_DARWIN
>LINUXLIBC6
>I'd like AMD64_LINUX, SPARC64_SOLARISN but no time right now to devote  
>to them.
>
>On May 14, 2008, at 1:25 PM, Jay wrote:
>
>> What do people run?
>> In particular: NetBSD? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN?  
>> I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM_WINCE? AMD64_NT?
>>
>> Just curious, I'll probably bring up whatever I can, it's fun, and  
>> yes, get back and fix AMD64_LINUX to have
>> garbage collection, NT386GNU and NT386 tests, cross-platform sets,  
>> setup some Tinderboxes, etc...
>>
>> (AMD64_NT: the gcc available for this includes a bunch of patches,  
>> so I'm inclined to either wait for them to go upstream,
>> or seek an alternate route such as "port" the in-proc backend, llvm,  
>> generate C, or maybe write an interpreter for the IL;
>> and "porting" the backend is probably best preceded by a) x86  
>> LONGINT support b) other x86 targets "for practise", at least one,
>> though regarding .obj file formats, that would be tangential.)
>>
>>  - Jay
>>
>>
>>
>>
>
>
>--Apple-Mail-4-631028010
>Content-Type: text/html;
>	charset=US-ASCII
>Content-Transfer-Encoding: quoted-printable
>
>-webkit-line-break: after-white-space; ">
apple-content-edited=3D"true">style=3D"border-collapse: separate; border-spacing: 0px 0px; color: =
>rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
>normal; font-variant: normal; font-weight: normal; letter-spacing: =
>normal; line-height: normal; text-align: auto; =
>-khtml-text-decorations-in-effect: none; text-indent: 0px; =
>-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; ">
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
>-khtml-line-break: after-white-space; ">style=3D"border-collapse: separate; border-spacing: 0px 0px; color: =
>rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
>normal; font-variant: normal; font-weight: normal; letter-spacing: =
>normal; line-height: normal; text-align: auto; =
>-khtml-text-decorations-in-effect: none; text-indent: 0px; =
>-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; =
>">SOLgnu
-khtml-nbsp-mode: space; -khtml-line-break: after-white-space; =
>">PPC_DARWIN
space; -khtml-line-break: after-white-space; ">I386_DARWIN
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
>-khtml-line-break: after-white-space; ">AMD64_DARWIN
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
>-khtml-line-break: after-white-space; ">LINUXLIBC6
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
>-khtml-line-break: after-white-space; ">I'd like AMD64_LINUX, class=3D"Apple-style-span" style=3D"font-family: Tahoma; font-size: =
>13px; ">SPARC64_SOLARISN but no time right now to devote to =
>them.

On May 14, 2008, at 1:25 =
>PM, Jay wrote:

type=3D"cite">separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; orphans: 2; text-align: =
>auto; text-indent: 0px; text-transform: none; white-space: normal; =
>widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
>-webkit-border-vertical-spacing: 0px; =
>-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
>auto; -webkit-text-stroke-width: 0; ">
style=3D"font-size: 10pt; font-family: Tahoma; ">What do people =
>run?
In particular: NetBSD? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN? =
>I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM_WINCE? =
>AMD64_NT?
 
Just curious, I'll probably bring up whatever I =
>can, it's fun, and yes, get back and fix AMD64_LINUX to have
garbage =
>collection, NT386GNU and NT386 tests, cross-platform sets, setup =
>some Tinderboxes, etc...
 
(AMD64_NT: the gcc available for =
>this includes a bunch of patches, so I'm inclined to either wait for =
>them to go upstream,
or seek an alternate route such as "port" the =
>in-proc backend, llvm, generate C, or maybe write an interpreter for the =
>IL;
and "porting" the backend is probably best preceded by a) x86 =
>LONGINT support b) other x86 targets "for practise", at least =
>one,
though regarding .obj file formats, that would be =
>tangential.)
 
 - =
>Jay





=
>
>--Apple-Mail-4-631028010--


From jayk123 at hotmail.com  Fri May 16 00:43:30 2008
From: jayk123 at hotmail.com (Jay)
Date: Thu, 15 May 2008 22:43:30 +0000
Subject: [M3devel] which platforms? and questions about FreeBSD
 versioning
In-Reply-To: <200805152130.m4FLUa9B060478@camembert.async.caltech.edu>
References: Your message of "Thu, 15 May 2008 11:47:41 EDT."
	<948C63CA-8763-46AE-9FDB-54DAF01CC28D@cs.purdue.edu>  
	<200805152130.m4FLUa9B060478@camembert.async.caltech.edu>
Message-ID: 

Mika, ok, this is tangential: Have you tried the current NT386GNU cm3?
 
I meant, more about what "operating systems" that Modula-3 does not support do people here use, would like to see Modula-3 on. Or maybe I meant both.
 
Speaking of the "4" in FreeBSD4:
 
Has FreeBSD, and the other BSDs, really broken backward compat?
They really change interfaces a lot such that binaries built with current headers/libs won't run on older versions?
And there isn't an easy way on current platforms to build something using older tools to run on older and newer platforms?
Look at Windows for example. If you call a "new" function directly, you will fail to load on older platforms. So either don't call them, or use LoadLibrary/GetProcAddress. Structures almost never change size, though there is some screwiness there, stuff like:
 
struct FOO {  size_t Size;
  int Field1;
#if VERSION > 1234
  int Field2;
#endif
};
 
I think it should be more like:
 
struct FOO {  size_t Size;
  int Field1;
#if VERSION > 1234
  int Field2;
#endif
};
 
struct FOO_V1{  size_t Size;
  int Field1;
};
 
struct FOO_V2 {  size_t Size;
  int Field1;
  int Field2;
};
 
#if VERSION > 1234
typedef FOO_V2 FOO;
#else
typedef FOO_V1 FOO;
#endif
 
I understand that binaries built on the older platform will continue to work on the newer platform.
That is one thing.
But it is also useful to be able to build binaries on the newer platform that will on the older platform.
Apple also invests a bunch here.
 
Well, ok, if it was really "bad", there'd be FreeBSD5, 6, 7.
I guess maybe they broke this stuff sometimes but haven't in a while?
That you can build FreeBSD4 binaries on FreeBSD7 and the run down to 4?
 
And then, same questions about OpenBSD and NetBSD.
I understand -- I could/must go and install a bajillion operating systems and test and find out, but I don't expect to spend the time that way and push comes to shove, any BSD (and Linux, Solaris, NT, CE, etc.) variants I introduce will have no version number in them, will be built on whatever I have, and it will be unknown if they work on older. And maybe something will materialize to be more portable, like interfacing to the Posix via C instead of cloned headers.
 
 - Jay



> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] which platforms? > Date: Thu, 15 May 2008 14:30:36 -0700> From: mika at async.caltech.edu> > here it is:> > FreeBSD4> PPC_DARWIN> NT386GNU> LINUXLIBC6> > I386_DARWIN coming soon> > Tony Hosking writes:> >> >--Apple-Mail-4-631028010> >Content-Type: text/plain;> > charset=US-ASCII;> > format=flowed;> > delsp=yes> >Content-Transfer-Encoding: 7bit> >> >SOLgnu> >PPC_DARWIN> >I386_DARWIN> >AMD64_DARWIN> >LINUXLIBC6> >I'd like AMD64_LINUX, SPARC64_SOLARISN but no time right now to devote > >to them.> >> >On May 14, 2008, at 1:25 PM, Jay wrote:> >> >> What do people run?> >> In particular: NetBSD? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN? > >> I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM_WINCE? AMD64_NT?> >>> >> Just curious, I'll probably bring up whatever I can, it's fun, and > >> yes, get back and fix AMD64_LINUX to have> >> garbage collection, NT386GNU and NT386 tests, cross-platform sets, > >> setup some Tinderboxes, etc...> >>> >> (AMD64_NT: the gcc available for this includes a bunch of patches, > >> so I'm inclined to either wait for them to go upstream,> >> or seek an alternate route such as "port" the in-proc backend, llvm, > >> generate C, or maybe write an interpreter for the IL;> >> and "porting" the backend is probably best preceded by a) x86 > >> LONGINT support b) other x86 targets "for practise", at least one,> >> though regarding .obj file formats, that would be tangential.)> >>> >> - Jay> >>> >>> >>> >>> >> >> >--Apple-Mail-4-631028010> >Content-Type: text/html;> > charset=US-ASCII> >Content-Transfer-Encoding: quoted-printable> >> > >-webkit-line-break: after-white-space; ">
 >apple-content-edited=3D"true"> >style=3D"border-collapse: separate; border-spacing: 0px 0px; color: => >rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: => >normal; font-variant: normal; font-weight: normal; letter-spacing: => >normal; line-height: normal; text-align: auto; => >-khtml-text-decorations-in-effect: none; text-indent: 0px; => >-apple-text-size-adjust: auto; text-transform: none; orphans: 2; => >white-space: normal; widows: 2; word-spacing: 0px; ">
 >style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; => >-khtml-line-break: after-white-space; "> >style=3D"border-collapse: separate; border-spacing: 0px 0px; color: => >rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: => >normal; font-variant: normal; font-weight: normal; letter-spacing: => >normal; line-height: normal; text-align: auto; => >-khtml-text-decorations-in-effect: none; text-indent: 0px; => >-apple-text-size-adjust: auto; text-transform: none; orphans: 2; => >white-space: normal; widows: 2; word-spacing: 0px; => >">SOLgnu
 >-khtml-nbsp-mode: space; -khtml-line-break: after-white-space; => >">PPC_DARWIN
 >space; -khtml-line-break: after-white-space; ">I386_DARWIN
 >style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; => >-khtml-line-break: after-white-space; ">AMD64_DARWIN
 >style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; => >-khtml-line-break: after-white-space; ">LINUXLIBC6
 >style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; => >-khtml-line-break: after-white-space; ">I'd like AMD64_LINUX,  >class=3D"Apple-style-span" style=3D"font-family: Tahoma; font-size: => >13px; ">SPARC64_SOLARISN but no time right now to devote to => >them.

On May 14, 2008, at 1:25 => >PM, Jay wrote:

 >type=3D"cite"> >separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; => >font-style: normal; font-variant: normal; font-weight: normal; => >letter-spacing: normal; line-height: normal; orphans: 2; text-align: => >auto; text-indent: 0px; text-transform: none; white-space: normal; => >widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; => >-webkit-border-vertical-spacing: 0px; => >-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: => >auto; -webkit-text-stroke-width: 0; ">
 >style=3D"font-size: 10pt; font-family: Tahoma; ">What do people => >run?
In particular: NetBSD? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN? => >I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM_WINCE? => >AMD64_NT?
 
Just curious, I'll probably bring up whatever I => >can, it's fun, and yes, get back and fix AMD64_LINUX to have
garbage => >collection, NT386GNU and NT386 tests, cross-platform sets, setup => >some Tinderboxes, etc...
 
(AMD64_NT: the gcc available for => >this includes a bunch of patches, so I'm inclined to either wait for => >them to go upstream,
or seek an alternate route such as "port" the => >in-proc backend, llvm, generate C, or maybe write an interpreter for the => >IL;
and "porting" the backend is probably best preceded by a) x86 => >LONGINT support b) other x86 targets "for practise", at least => >one,
though regarding .obj file formats, that would be => >tangential.)
 
 - => >Jay





=> >> >--Apple-Mail-4-631028010--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mika at async.caltech.edu  Fri May 16 07:54:28 2008
From: mika at async.caltech.edu (Mika Nystrom)
Date: Thu, 15 May 2008 22:54:28 -0700
Subject: [M3devel] which platforms? and questions about FreeBSD
	versioning
In-Reply-To: Your message of "Thu, 15 May 2008 22:43:30 -0000."
	 
Message-ID: <200805160554.m4G5sShX067480@camembert.async.caltech.edu>


No, sorry, haven't gotten around to testing the current NT386GNU
cm3... I have a lot of version synchronizing to do, unfortunately :(

Yes, FreeBSD is backwards-compatible, *not* forwards-compatible.
That is, you can build even fairly complex software packages on an old
FreeBSD system and expect it to run on the latest release.  You cannot,
as a general rule, build anything on a newer system and expect it to work
on an older one.  There must be "some" way of doing it that way, but
I don't know what it is, and I don't know if it's very well supported.
I keep FreeBSD 4.x systems around for precisely this reason: the binaries
compiled there work fine on 5.x and 6.x (as far as I have tested).  Not
the other way around!  In fact it has never worked the other way, as 
long as I can remember, with FreeBSD.

This is also why I suggest that a "FreeBSD4" bootstrap should actually
be built on FreeBSD 4.x and not 5.x, 6.x, or 7.x!

    Mika

Jay writes:
>--_14c076c4-fb7c-48b0-b705-2e38d4b4a333_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>Mika, ok, this is tangential: Have you tried the current NT386GNU cm3?
>=20
>I meant, more about what "operating systems" that Modula-3 does not support=
> do people here use, would like to see Modula-3 on. Or maybe I meant both.
>=20
>Speaking of the "4" in FreeBSD4:
>=20
>Has FreeBSD, and the other BSDs, really broken backward compat?
>They really change interfaces a lot such that binaries built with current h=
>eaders/libs won't run on older versions?
>And there isn't an easy way on current platforms to build something using o=
>lder tools to run on older and newer platforms?
>Look at Windows for example. If you call a "new" function directly, you wil=
>l fail to load on older platforms. So either don't call them, or use LoadLi=
>brary/GetProcAddress. Structures almost never change size, though there is =
>some screwiness there, stuff like:
>=20
>struct FOO {  size_t Size;
>  int Field1;
>#if VERSION > 1234
>  int Field2;
>#endif
>};
>=20
>I think it should be more like:
>=20
>struct FOO {  size_t Size;
>  int Field1;
>#if VERSION > 1234
>  int Field2;
>#endif
>};
>=20
>struct FOO_V1{  size_t Size;
>  int Field1;
>};
>=20
>struct FOO_V2 {  size_t Size;
>  int Field1;
>  int Field2;
>};
>=20
>#if VERSION > 1234
>typedef FOO_V2 FOO;
>#else
>typedef FOO_V1 FOO;
>#endif
>=20
>I understand that binaries built on the older platform will continue to wor=
>k on the newer platform.
>That is one thing.
>But it is also useful to be able to build binaries on the newer platform th=
>at will on the older platform.
>Apple also invests a bunch here.
>=20
>Well, ok, if it was really "bad", there'd be FreeBSD5, 6, 7.
>I guess maybe they broke this stuff sometimes but haven't in a while?
>That you can build FreeBSD4 binaries on FreeBSD7 and the run down to 4?
>=20
>And then, same questions about OpenBSD and NetBSD.
>I understand -- I could/must go and install a bajillion operating systems a=
>nd test and find out, but I don't expect to spend the time that way and pus=
>h comes to shove, any BSD (and Linux, Solaris, NT, CE, etc.) variants I int=
>roduce will have no version number in them, will be built on whatever I hav=
>e, and it will be unknown if they work on older. And maybe something will m=
>aterialize to be more portable, like interfacing to the Posix via C instead=
> of cloned headers.
>=20
> - Jay
>
>
>
>> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel=
>] which platforms? > Date: Thu, 15 May 2008 14:30:36 -0700> From: mika at asyn=
>c.caltech.edu> > here it is:> > FreeBSD4> PPC_DARWIN> NT386GNU> LINUXLIBC6>=
> > I386_DARWIN coming soon> > Tony Hosking writes:> >> >--Apple-Mail-4-6310=
>28010> >Content-Type: text/plain;> > charset=3DUS-ASCII;> > format=3Dflowed=
>;> > delsp=3Dyes> >Content-Transfer-Encoding: 7bit> >> >SOLgnu> >PPC_DARWIN=
>> >I386_DARWIN> >AMD64_DARWIN> >LINUXLIBC6> >I'd like AMD64_LINUX, SPARC64_=
>SOLARISN but no time right now to devote > >to them.> >> >On May 14, 2008, =
>at 1:25 PM, Jay wrote:> >> >> What do people run?> >> In particular: NetBSD=
>? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN? > >> I386_SOLARIS? AMD64_SOLARIS=
>? SPARC64_SOLARIS? ARM_WINCE? AMD64_NT?> >>> >> Just curious, I'll probably=
> bring up whatever I can, it's fun, and > >> yes, get back and fix AMD64_LI=
>NUX to have> >> garbage collection, NT386GNU and NT386 tests, cross-platfor=
>m sets, > >> setup some Tinderboxes, etc...> >>> >> (AMD64_NT: the gcc avai=
>lable for this includes a bunch of patches, > >> so I'm inclined to either =
>wait for them to go upstream,> >> or seek an alternate route such as "port"=
> the in-proc backend, llvm, > >> generate C, or maybe write an interpreter =
>for the IL;> >> and "porting" the backend is probably best preceded by a) x=
>86 > >> LONGINT support b) other x86 targets "for practise", at least one,>=
> >> though regarding .obj file formats, that would be tangential.)> >>> >> =
>- Jay> >>> >>> >>> >>> >> >> >--Apple-Mail-4-631028010> >Content-Type: text=
>/html;> > charset=3DUS-ASCII> >Content-Transfer-Encoding: quoted-printable>=
> >> >; =3D> >-webkit-line-break: after-white-space; ">
 >apple-content-e=
>dited=3D3D"true"> >style=3D3D"border=
>-collapse: separate; border-spacing: 0px 0px; color: =3D> >rgb(0, 0, 0); fo=
>nt-family: Helvetica; font-size: 12px; font-style: =3D> >normal; font-varia=
>nt: normal; font-weight: normal; letter-spacing: =3D> >normal; line-height:=
> normal; text-align: auto; =3D> >-khtml-text-decorations-in-effect: none; t=
>ext-indent: 0px; =3D> >-apple-text-size-adjust: auto; text-transform: none;=
> orphans: 2; =3D> >white-space: normal; widows: 2; word-spacing: 0px; ">v =3D> >style=3D3D"word-wrap: break-word; -khtml-nbsp-mode: space; =3D> >-k=
>html-line-break: after-white-space; ">=3D> >style=3D3D"border-collapse: separate; border-spacing: 0px 0px; color:=
> =3D> >rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
>=3D> >normal; font-variant: normal; font-weight: normal; letter-spacing: =
>=3D> >normal; line-height: normal; text-align: auto; =3D> >-khtml-text-deco=
>rations-in-effect: none; text-indent: 0px; =3D> >-apple-text-size-adjust: a=
>uto; text-transform: none; orphans: 2; =3D> >white-space: normal; widows: 2=
>; word-spacing: 0px; =3D> >">SOLgnu
break-word; =3D> >-khtml-nbsp-mode: space; -khtml-line-break: after-white-s=
>pace; =3D> >">PPC_DARWIN
-nbsp-mode: =3D> >space; -khtml-line-break: after-white-space; ">I386_DARWI=
>N
 >style=3D3D"word-wrap: break-word; -khtml-nbsp-mode: space=
>; =3D> >-khtml-line-break: after-white-space; ">AMD64_DARWIN
=
> >style=3D3D"word-wrap: break-word; -khtml-nbsp-mode: space; =3D> >-khtml-l=
>ine-break: after-white-space; ">LINUXLIBC6
 >style=3D3D"word-=
>wrap: break-word; -khtml-nbsp-mode: space; =3D> >-khtml-line-break: after-w=
>hite-space; ">I'd like AMD64_LINUX,  >class=3D3D"Apple-style=
>-span" style=3D3D"font-family: Tahoma; font-size: =3D> >13px; ">SPARC64_SOL=
>ARISN but no time right now to devote to =3D> >them.
iv>
On May 14, 2008, at 1:25 =3D> >PM, Jay wrote:

ss=3D3D"Apple-interchange-newline">
 >type=3D3D"cite">class=3D3D"Apple-style-span" style=3D3D"border-collapse: =3D> >separate; co=
>lor: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =3D> >font-styl=
>e: normal; font-variant: normal; font-weight: normal; =3D> >letter-spacing:=
> normal; line-height: normal; orphans: 2; text-align: =3D> >auto; text-inde=
>nt: 0px; text-transform: none; white-space: normal; =3D> >widows: 2; word-s=
>pacing: 0px; -webkit-border-horizontal-spacing: 0px; =3D> >-webkit-border-v=
>ertical-spacing: 0px; =3D> >-webkit-text-decorations-in-effect: none; -webk=
>it-text-size-adjust: =3D> >auto; -webkit-text-stroke-width: 0; ">
=3D3D"hmmessage" =3D> >style=3D3D"font-size: 10pt; font-family: Tahoma; ">W=
>hat do people =3D> >run?
In particular: NetBSD? OpenBSD? Sparc32? Sparc6=
>4? PPC64_DARWIN? =3D> >I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM_WI=
>NCE? =3D> >AMD64_NT?
 
Just curious, I'll probably bring up what=
>ever I =3D> >can, it's fun, and yes, get back and fix AMD64_LINUX to haver>garbage =3D> >collection, NT386GNU and NT386 tests, cross-platform s=
>ets, setup =3D> >some Tinderboxes, etc...
 
(AMD64_NT: the gcc a=
>vailable for =3D> >this includes a bunch of patches, so I'm inclined to eit=
>her wait for =3D> >them to go upstream,
or seek an alternate route such =
>as "port" the =3D> >in-proc backend, llvm, generate C, or maybe write an in=
>terpreter for the =3D> >IL;
and "porting" the backend is probably best p=
>receded by a) x86 =3D> >LONGINT support b) other x86 targets "for practise"=
>, at least =3D> >one,
though regarding .obj file formats, that would be =
>=3D> >tangential.)
 
 - =3D> >Jay




=
>

=3D> >> >--Apple-Mail-4-6310280=
>10--=
>
>--_14c076c4-fb7c-48b0-b705-2e38d4b4a333_
>Content-Type: text/html; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>
>
>
>
>Mika, ok, this is tangential: Have you =
>tried the current NT386GNU cm3?

> 

>I meant, more about what "operating systems" that Modula-3 does not support=
> do people here use, would like to see Modula-3 on. Or maybe I meant both.<=
>BR>
> 

>Speaking of the "4" in FreeBSD4:

> 

>Has FreeBSD, and the other BSDs, really broken backward compat?

>They really change interfaces a lot such that binaries built with current h=
>eaders/libs won't run on older versions?

>And there isn't an easy way on current platforms to build something using o=
>lder tools to run on older and newer platforms?

>Look at Windows for example. If you call a "new" function directly, you wil=
>l fail to load on older platforms. So either don't call them, or use LoadLi=
>brary/GetProcAddress. Structures almost never change size, though there is =
>some screwiness there, stuff like:

> 

>struct FOO {
  size_t Size;

>  int Field1;

>#if VERSION > 1234

>  int Field2;

>#endif

>};

> 

>I think it should be more like:

> 

>struct FOO {
  size_t Size;

>  int Field1;

>#if VERSION > 1234

>  int Field2;

>#endif

>};

> 

>struct FOO_V1{
  size_t Size;

>  int Field1;

>};

> 

>struct FOO_V2 {
  size_t Size;

>  int Field1;

>  int Field2;

>};

> 

>#if VERSION > 1234

>typedef FOO_V2 FOO;

>#else

>typedef FOO_V1 FOO;

>#endif

> 

>I understand that binaries built on the older platform will continue to wor=
>k on the newer platform.

>That is one thing.

>But it is also useful to be able to build binaries on the newer platform th=
>at will on the older platform.

>Apple also invests a bunch here.

> 

>Well, ok, if it was really "bad", there'd be FreeBSD5, 6, 7.

>I guess maybe they broke this stuff sometimes but haven't in a while?

>That you can build FreeBSD4 binaries on FreeBSD7 and the run down to 4?

> 

>And then, same questions about OpenBSD and NetBSD.

>I understand -- I could/must go and install a bajillion operating systems a=
>nd test and find out, but I don't expect to spend the time that way and pus=
>h comes to shove, any BSD (and Linux, Solaris, NT, CE, etc.) variants I int=
>roduce will have no version number in them, will be built on whatever I hav=
>e, and it will be unknown if they work on older. And maybe something will m=
>aterialize to be more portable, like interfacing to the Posix via C instead=
> of cloned headers.

> 

> - Jay



>
>

>

>> To: jayk123 at hotmail.com
> CC: m3devel at elegosoft.com
> Subj=
>ect: Re: [M3devel] which platforms? 
> Date: Thu, 15 May 2008 14:30:3=
>6 -0700
> From: mika at async.caltech.edu
> 
> here it is:R>> 
> FreeBSD4
> PPC_DARWIN
> NT386GNU
> LINUXL=
>IBC6
> 
> I386_DARWIN coming soon
> 
> Tony Hosking=
> writes:
> >
> >--Apple-Mail-4-631028010
> >Cont=
>ent-Type: text/plain;
> > charset=3DUS-ASCII;
> > format=
>=3Dflowed;
> > delsp=3Dyes
> >Content-Transfer-Encoding: =
>7bit
> >
> >SOLgnu
> >PPC_DARWIN
> >I38=
>6_DARWIN
> >AMD64_DARWIN
> >LINUXLIBC6
> >I'd li=
>ke AMD64_LINUX, SPARC64_SOLARISN but no time right now to devote 
> &=
>gt;to them.
> >
> >On May 14, 2008, at 1:25 PM, Jay wrote=
>:
> >
> >> What do people run?
> >> In par=
>ticular: NetBSD? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN? 
> >>=
> I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM_WINCE? AMD64_NT?
>=
> >>
> >> Just curious, I'll probably bring up whatever I =
>can, it's fun, and 
> >> yes, get back and fix AMD64_LINUX to h=
>ave
> >> garbage collection, NT386GNU and NT386 tests, cross-pl=
>atform sets, 
> >> setup some Tinderboxes, etc...
> >&=
>gt;
> >> (AMD64_NT: the gcc available for this includes a bunch=
> of patches, 
> >> so I'm inclined to either wait for them to g=
>o upstream,
> >> or seek an alternate route such as "port" the =
>in-proc backend, llvm, 
> >> generate C, or maybe write an inte=
>rpreter for the IL;
> >> and "porting" the backend is probably =
>best preceded by a) x86 
> >> LONGINT support b) other x86 targ=
>ets "for practise", at least one,
> >> though regarding .obj fi=
>le formats, that would be tangential.)
> >>
> >> - =
>Jay
> >>
> >>
> >>
> >>
=
>> >
> >
> >--Apple-Mail-4-631028010
> >Con=
>tent-Type: text/html;
> > charset=3DUS-ASCII
> >Content-T=
>ransfer-Encoding: quoted-printable
> >
> ><html><=
>;body style=3D3D"word-wrap: break-word; -webkit-nbsp-mode: space; =3D
&g=
>t; >-webkit-line-break: after-white-space; "><div =3D
> >=
>apple-content-edited=3D3D"true"><span class=3D3D"Apple-style-span" =
>=3D
> >style=3D3D"border-collapse: separate; border-spacing: 0px 0=
>px; color: =3D
> >rgb(0, 0, 0); font-family: Helvetica; font-size:=
> 12px; font-style: =3D
> >normal; font-variant: normal; font-weigh=
>t: normal; letter-spacing: =3D
> >normal; line-height: normal; tex=
>t-align: auto; =3D
> >-khtml-text-decorations-in-effect: none; tex=
>t-indent: 0px; =3D
> >-apple-text-size-adjust: auto; text-transfor=
>m: none; orphans: 2; =3D
> >white-space: normal; widows: 2; word-s=
>pacing: 0px; "><div =3D
> >style=3D3D"word-wrap: break-word;=
> -khtml-nbsp-mode: space; =3D
> >-khtml-line-break: after-white-sp=
>ace; "><span class=3D3D"Apple-style-span" =3D
> >style=3D3D"=
>border-collapse: separate; border-spacing: 0px 0px; color: =3D
> >=
>rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =3D
&=
>gt; >normal; font-variant: normal; font-weight: normal; letter-spacing: =
>=3D
> >normal; line-height: normal; text-align: auto; =3D
> =
>>-khtml-text-decorations-in-effect: none; text-indent: 0px; =3D
> =
>>-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =3D>> >white-space: normal; widows: 2; word-spacing: 0px; =3D
> &g=
>t;">SOLgnu</span></div><div style=3D3D"word-wrap: break-w=
>ord; =3D
> >-khtml-nbsp-mode: space; -khtml-line-break: after-whit=
>e-space; =3D
> >">PPC_DARWIN</div><div style=3D3D"word=
>-wrap: break-word; -khtml-nbsp-mode: =3D
> >space; -khtml-line-bre=
>ak: after-white-space; ">I386_DARWIN</div><div =3D
> >=
>style=3D3D"word-wrap: break-word; -khtml-nbsp-mode: space; =3D
> >=
>-khtml-line-break: after-white-space; ">AMD64_DARWIN</div><div =
>=3D
> >style=3D3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
>=3D
> >-khtml-line-break: after-white-space; ">LINUXLIBC6</d=
>iv><div =3D
> >style=3D3D"word-wrap: break-word; -khtml-nbsp=
>-mode: space; =3D
> >-khtml-line-break: after-white-space; ">I'=
>d like AMD64_LINUX,&nbsp;<span =3D
> >class=3D3D"Apple-styl=
>e-span" style=3D3D"font-family: Tahoma; font-size: =3D
> >13px; "&=
>gt;SPARC64_SOLARISN but no time right now to devote to =3D
> >them=
>.</span></div></span></div><br><div><=
>;div>On May 14, 2008, at 1:25 =3D
> >PM, Jay wrote:</div>=
><br class=3D3D"Apple-interchange-newline"><blockquote =3D
> =
>>type=3D3D"cite"><span class=3D3D"Apple-style-span" style=3D3D"bor=
>der-collapse: =3D
> >separate; color: rgb(0, 0, 0); font-family: H=
>elvetica; font-size: 12px; =3D
> >font-style: normal; font-variant=
>: normal; font-weight: normal; =3D
> >letter-spacing: normal; line=
>-height: normal; orphans: 2; text-align: =3D
> >auto; text-indent:=
> 0px; text-transform: none; white-space: normal; =3D
> >widows: 2;=
> word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =3D
> >=
>;-webkit-border-vertical-spacing: 0px; =3D
> >-webkit-text-decorat=
>ions-in-effect: none; -webkit-text-size-adjust: =3D
> >auto; -webk=
>it-text-stroke-width: 0; "><div class=3D3D"hmmessage" =3D
> >=
>;style=3D3D"font-size: 10pt; font-family: Tahoma; ">What do people =3DR>> >run?<br>In particular: NetBSD? OpenBSD? Sparc32? Sparc64? =
>PPC64_DARWIN? =3D
> >I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS?=
> ARM_WINCE? =3D
> >AMD64_NT?<br>&nbsp;<br>Just cur=
>ious, I'll probably bring up whatever I =3D
> >can, it's fun, and =
>yes, get back and fix AMD64_LINUX to have<br>garbage =3D
> >=
>collection, NT386GNU and NT386 tests,&nbsp;cross-platform sets, setup =
>=3D
> >some Tinderboxes, etc...<br>&nbsp;<br>(AMD6=
>4_NT: the gcc available for =3D
> >this includes a bunch of patche=
>s, so I'm inclined to either wait for =3D
> >them to go upstream,&=
>lt;br>or seek an alternate route such as "port" the =3D
> >in-p=
>roc backend, llvm, generate C, or maybe write an interpreter for the =3D>> >IL;<br>and "porting" the backend is probably best preceded =
>by a) x86 =3D
> >LONGINT support b) other x86 targets "for practis=
>e", at least =3D
> >one,<br>though regarding .obj file forma=
>ts, that would be =3D
> >tangential.)<br>&nbsp;<br>=
>;&nbsp;- =3D
> >Jay<br><br><br><br><=
>;br></div></span></blockquote></div><br>&l=
>t;/body></html>=3D
> >
> >--Apple-Mail-4-6310280=
>10--


>=
>
>--_14c076c4-fb7c-48b0-b705-2e38d4b4a333_--


From jayk123 at hotmail.com  Fri May 16 08:40:49 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 16 May 2008 06:40:49 +0000
Subject: [M3devel] which platforms? and questions about FreeBSD
 versioning
In-Reply-To: <200805160554.m4G5sShX067480@camembert.async.caltech.edu>
References: Your message of "Thu, 15 May 2008 22:43:30 -0000."
	  
	<200805160554.m4G5sShX067480@camembert.async.caltech.edu>
Message-ID: 

Wow that is crazy.
The "OS" is backwards compatible.
The tools -- or at least the headers/libs -- are not backwards compatible.
They apparently don't produce binaries that run on older systems.
 
Hm, so I did some diffing amongm3-libs\m3core\src\unix\freebsd-*
they are all amost identical.and almost all compatible.Freebsd-1 to -2 is the least compatible.otherwise the only actual difference I see is in Usignal sa_flags and sa_mask getting reversed. and sigcontext changed.
Otherwise it's mostly things like long vs. unsigned_long,int64_t vs. quad_t, short vs. int16_t.
The DIR record grew, but as long as it is not implementedin Modula-3 and the new fields not access, no matter.
Oh one errno value changed.
Sometimes some types or functions got added, but that is ok.
 
Maybe more research at a might later date...
 
 - Jay



> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] which platforms? and questions about FreeBSD versioning > Date: Thu, 15 May 2008 22:54:28 -0700> From: mika at async.caltech.edu> > > No, sorry, haven't gotten around to testing the current NT386GNU> cm3... I have a lot of version synchronizing to do, unfortunately :(> > Yes, FreeBSD is backwards-compatible, *not* forwards-compatible.> That is, you can build even fairly complex software packages on an old> FreeBSD system and expect it to run on the latest release. You cannot,> as a general rule, build anything on a newer system and expect it to work> on an older one. There must be "some" way of doing it that way, but> I don't know what it is, and I don't know if it's very well supported.> I keep FreeBSD 4.x systems around for precisely this reason: the binaries> compiled there work fine on 5.x and 6.x (as far as I have tested). Not> the other way around! In fact it has never worked the other way, as > long as I can remember, with FreeBSD.> > This is also why I suggest that a "FreeBSD4" bootstrap should actually> be built on FreeBSD 4.x and not 5.x, 6.x, or 7.x!> > Mika> > Jay writes:> >--_14c076c4-fb7c-48b0-b705-2e38d4b4a333_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >Mika, ok, this is tangential: Have you tried the current NT386GNU cm3?> >=20> >I meant, more about what "operating systems" that Modula-3 does not support=> > do people here use, would like to see Modula-3 on. Or maybe I meant both.> >=20> >Speaking of the "4" in FreeBSD4:> >=20> >Has FreeBSD, and the other BSDs, really broken backward compat?> >They really change interfaces a lot such that binaries built with current h=> >eaders/libs won't run on older versions?> >And there isn't an easy way on current platforms to build something using o=> >lder tools to run on older and newer platforms?> >Look at Windows for example. If you call a "new" function directly, you wil=> >l fail to load on older platforms. So either don't call them, or use LoadLi=> >brary/GetProcAddress. Structures almost never change size, though there is => >some screwiness there, stuff like:> >=20> >struct FOO { size_t Size;> > int Field1;> >#if VERSION > 1234> > int Field2;> >#endif> >};> >=20> >I think it should be more like:> >=20> >struct FOO { size_t Size;> > int Field1;> >#if VERSION > 1234> > int Field2;> >#endif> >};> >=20> >struct FOO_V1{ size_t Size;> > int Field1;> >};> >=20> >struct FOO_V2 { size_t Size;> > int Field1;> > int Field2;> >};> >=20> >#if VERSION > 1234> >typedef FOO_V2 FOO;> >#else> >typedef FOO_V1 FOO;> >#endif> >=20> >I understand that binaries built on the older platform will continue to wor=> >k on the newer platform.> >That is one thing.> >But it is also useful to be able to build binaries on the newer platform th=> >at will on the older platform.> >Apple also invests a bunch here.> >=20> >Well, ok, if it was really "bad", there'd be FreeBSD5, 6, 7.> >I guess maybe they broke this stuff sometimes but haven't in a while?> >That you can build FreeBSD4 binaries on FreeBSD7 and the run down to 4?> >=20> >And then, same questions about OpenBSD and NetBSD.> >I understand -- I could/must go and install a bajillion operating systems a=> >nd test and find out, but I don't expect to spend the time that way and pus=> >h comes to shove, any BSD (and Linux, Solaris, NT, CE, etc.) variants I int=> >roduce will have no version number in them, will be built on whatever I hav=> >e, and it will be unknown if they work on older. And maybe something will m=> >aterialize to be more portable, like interfacing to the Posix via C instead=> > of cloned headers.> >=20> > - Jay> >> >> >> >> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel=> >] which platforms? > Date: Thu, 15 May 2008 14:30:36 -0700> From: mika at asyn=> >c.caltech.edu> > here it is:> > FreeBSD4> PPC_DARWIN> NT386GNU> LINUXLIBC6>=> > > I386_DARWIN coming soon> > Tony Hosking writes:> >> >--Apple-Mail-4-6310=> >28010> >Content-Type: text/plain;> > charset=3DUS-ASCII;> > format=3Dflowed=> >;> > delsp=3Dyes> >Content-Transfer-Encoding: 7bit> >> >SOLgnu> >PPC_DARWIN=> >> >I386_DARWIN> >AMD64_DARWIN> >LINUXLIBC6> >I'd like AMD64_LINUX, SPARC64_=> >SOLARISN but no time right now to devote > >to them.> >> >On May 14, 2008, => >at 1:25 PM, Jay wrote:> >> >> What do people run?> >> In particular: NetBSD=> >? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN? > >> I386_SOLARIS? AMD64_SOLARIS=> >? SPARC64_SOLARIS? ARM_WINCE? AMD64_NT?> >>> >> Just curious, I'll probably=> > bring up whatever I can, it's fun, and > >> yes, get back and fix AMD64_LI=> >NUX to have> >> garbage collection, NT386GNU and NT386 tests, cross-platfor=> >m sets, > >> setup some Tinderboxes, etc...> >>> >> (AMD64_NT: the gcc avai=> >lable for this includes a bunch of patches, > >> so I'm inclined to either => >wait for them to go upstream,> >> or seek an alternate route such as "port"=> > the in-proc backend, llvm, > >> generate C, or maybe write an interpreter => >for the IL;> >> and "porting" the backend is probably best preceded by a) x=> >86 > >> LONGINT support b) other x86 targets "for practise", at least one,>=> > >> though regarding .obj file formats, that would be tangential.)> >>> >> => >- Jay> >>> >>> >>> >>> >> >> >--Apple-Mail-4-631028010> >Content-Type: text=> >/html;> > charset=3DUS-ASCII> >Content-Transfer-Encoding: quoted-printable>=> > >> > >; =3D> >-webkit-line-break: after-white-space; ">
 >apple-content-e=> >dited=3D3D"true"> >style=3D3D"border=> >-collapse: separate; border-spacing: 0px 0px; color: =3D> >rgb(0, 0, 0); fo=> >nt-family: Helvetica; font-size: 12px; font-style: =3D> >normal; font-varia=> >nt: normal; font-weight: normal; letter-spacing: =3D> >normal; line-height:=> > normal; text-align: auto; =3D> >-khtml-text-decorations-in-effect: none; t=> >ext-indent: 0px; =3D> >-apple-text-size-adjust: auto; text-transform: none;=> > orphans: 2; =3D> >white-space: normal; widows: 2; word-spacing: 0px; "> >v =3D> >style=3D3D"word-wrap: break-word; -khtml-nbsp-mode: space; =3D> >-k=> >html-line-break: after-white-space; "> >=3D> >style=3D3D"border-collapse: separate; border-spacing: 0px 0px; color:=> > =3D> >rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: => >=3D> >normal; font-variant: normal; font-weight: normal; letter-spacing: => >=3D> >normal; line-height: normal; text-align: auto; =3D> >-khtml-text-deco=> >rations-in-effect: none; text-indent: 0px; =3D> >-apple-text-size-adjust: a=> >uto; text-transform: none; orphans: 2; =3D> >white-space: normal; widows: 2=> >; word-spacing: 0px; =3D> >">SOLgnu
 >break-word; =3D> >-khtml-nbsp-mode: space; -khtml-line-break: after-white-s=> >pace; =3D> >">PPC_DARWIN
 >-nbsp-mode: =3D> >space; -khtml-line-break: after-white-space; ">I386_DARWI=> >N
 >style=3D3D"word-wrap: break-word; -khtml-nbsp-mode: space=> >; =3D> >-khtml-line-break: after-white-space; ">AMD64_DARWIN
=> > >style=3D3D"word-wrap: break-word; -khtml-nbsp-mode: space; =3D> >-khtml-l=> >ine-break: after-white-space; ">LINUXLIBC6
 >style=3D3D"word-=> >wrap: break-word; -khtml-nbsp-mode: space; =3D> >-khtml-line-break: after-w=> >hite-space; ">I'd like AMD64_LINUX,  >class=3D3D"Apple-style=> >-span" style=3D3D"font-family: Tahoma; font-size: =3D> >13px; ">SPARC64_SOL=> >ARISN but no time right now to devote to =3D> >them.
 >iv>
On May 14, 2008, at 1:25 =3D> >PM, Jay wrote:

 >ss=3D3D"Apple-interchange-newline">
 >type=3D3D"cite"> >class=3D3D"Apple-style-span" style=3D3D"border-collapse: =3D> >separate; co=> >lor: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =3D> >font-styl=> >e: normal; font-variant: normal; font-weight: normal; =3D> >letter-spacing:=> > normal; line-height: normal; orphans: 2; text-align: =3D> >auto; text-inde=> >nt: 0px; text-transform: none; white-space: normal; =3D> >widows: 2; word-s=> >pacing: 0px; -webkit-border-horizontal-spacing: 0px; =3D> >-webkit-border-v=> >ertical-spacing: 0px; =3D> >-webkit-text-decorations-in-effect: none; -webk=> >it-text-size-adjust: =3D> >auto; -webkit-text-stroke-width: 0; ">
 >=3D3D"hmmessage" =3D> >style=3D3D"font-size: 10pt; font-family: Tahoma; ">W=> >hat do people =3D> >run?
In particular: NetBSD? OpenBSD? Sparc32? Sparc6=> >4? PPC64_DARWIN? =3D> >I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM_WI=> >NCE? =3D> >AMD64_NT?
 
Just curious, I'll probably bring up what=> >ever I =3D> >can, it's fun, and yes, get back and fix AMD64_LINUX to have >r>garbage =3D> >collection, NT386GNU and NT386 tests, cross-platform s=> >ets, setup =3D> >some Tinderboxes, etc...
 
(AMD64_NT: the gcc a=> >vailable for =3D> >this includes a bunch of patches, so I'm inclined to eit=> >her wait for =3D> >them to go upstream,
or seek an alternate route such => >as "port" the =3D> >in-proc backend, llvm, generate C, or maybe write an in=> >terpreter for the =3D> >IL;
and "porting" the backend is probably best p=> >receded by a) x86 =3D> >LONGINT support b) other x86 targets "for practise"=> >, at least =3D> >one,
though regarding .obj file formats, that would be => >=3D> >tangential.)
 
 - =3D> >Jay




=> >

=3D> >> >--Apple-Mail-4-6310280=> >10--=> >> >--_14c076c4-fb7c-48b0-b705-2e38d4b4a333_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >> >> >> >> >Mika, ok, this is tangential: Have you => >tried the current NT386GNU cm3?
> > 
> >I meant, more about what "operating systems" that Modula-3 does not support=> > do people here use, would like to see Modula-3 on. Or maybe I meant both.<=> >BR>> > 
> >Speaking of the "4" in FreeBSD4:
> > 
> >Has FreeBSD, and the other BSDs, really broken backward compat?
> >They really change interfaces a lot such that binaries built with current h=> >eaders/libs won't run on older versions?
> >And there isn't an easy way on current platforms to build something using o=> >lder tools to run on older and newer platforms?
> >Look at Windows for example. If you call a "new" function directly, you wil=> >l fail to load on older platforms. So either don't call them, or use LoadLi=> >brary/GetProcAddress. Structures almost never change size, though there is => >some screwiness there, stuff like:
> > 
> >struct FOO {
  size_t Size;
> >  int Field1;
> >#if VERSION > 1234
> >  int Field2;
> >#endif
> >};
> > 
> >I think it should be more like:
> > 
> >struct FOO {
  size_t Size;
> >  int Field1;
> >#if VERSION > 1234
> >  int Field2;
> >#endif
> >};
> > 
> >struct FOO_V1{
  size_t Size;
> >  int Field1;
> >};
> > 
> >struct FOO_V2 {
  size_t Size;
> >  int Field1;
> >  int Field2;
> >};
> > 
> >#if VERSION > 1234
> >typedef FOO_V2 FOO;
> >#else
> >typedef FOO_V1 FOO;
> >#endif
> > 
> >I understand that binaries built on the older platform will continue to wor=> >k on the newer platform.
> >That is one thing.
> >But it is also useful to be able to build binaries on the newer platform th=> >at will on the older platform.
> >Apple also invests a bunch here.
> > 
> >Well, ok, if it was really "bad", there'd be FreeBSD5, 6, 7.
> >I guess maybe they broke this stuff sometimes but haven't in a while?
> >That you can build FreeBSD4 binaries on FreeBSD7 and the run down to 4?
> > 
> >And then, same questions about OpenBSD and NetBSD.
> >I understand -- I could/must go and install a bajillion operating systems a=> >nd test and find out, but I don't expect to spend the time that way and pus=> >h comes to shove, any BSD (and Linux, Solaris, NT, CE, etc.) variants I int=> >roduce will have no version number in them, will be built on whatever I hav=> >e, and it will be unknown if they work on older. And maybe something will m=> >aterialize to be more portable, like interfacing to the Posix via C instead=> > of cloned headers.
> > 
> > - Jay


> >> >
> >
> >> To: jayk123 at hotmail.com
> CC: m3devel at elegosoft.com
> Subj=> >ect: Re: [M3devel] which platforms? 
> Date: Thu, 15 May 2008 14:30:3=> >6 -0700
> From: mika at async.caltech.edu
> 
> here it is: >R>> 
> FreeBSD4
> PPC_DARWIN
> NT386GNU
> LINUXL=> >IBC6
> 
> I386_DARWIN coming soon
> 
> Tony Hosking=> > writes:
> >
> >--Apple-Mail-4-631028010
> >Cont=> >ent-Type: text/plain;
> > charset=3DUS-ASCII;
> > format=> >=3Dflowed;
> > delsp=3Dyes
> >Content-Transfer-Encoding: => >7bit
> >
> >SOLgnu
> >PPC_DARWIN
> >I38=> >6_DARWIN
> >AMD64_DARWIN
> >LINUXLIBC6
> >I'd li=> >ke AMD64_LINUX, SPARC64_SOLARISN but no time right now to devote 
> &=> >gt;to them.
> >
> >On May 14, 2008, at 1:25 PM, Jay wrote=> >:
> >
> >> What do people run?
> >> In par=> >ticular: NetBSD? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN? 
> >>=> > I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM_WINCE? AMD64_NT?
>=> > >>
> >> Just curious, I'll probably bring up whatever I => >can, it's fun, and 
> >> yes, get back and fix AMD64_LINUX to h=> >ave
> >> garbage collection, NT386GNU and NT386 tests, cross-pl=> >atform sets, 
> >> setup some Tinderboxes, etc...
> >&=> >gt;
> >> (AMD64_NT: the gcc available for this includes a bunch=> > of patches, 
> >> so I'm inclined to either wait for them to g=> >o upstream,
> >> or seek an alternate route such as "port" the => >in-proc backend, llvm, 
> >> generate C, or maybe write an inte=> >rpreter for the IL;
> >> and "porting" the backend is probably => >best preceded by a) x86 
> >> LONGINT support b) other x86 targ=> >ets "for practise", at least one,
> >> though regarding .obj fi=> >le formats, that would be tangential.)
> >>
> >> - => >Jay
> >>
> >>
> >>
> >>
=> >> >
> >
> >--Apple-Mail-4-631028010
> >Con=> >tent-Type: text/html;
> > charset=3DUS-ASCII
> >Content-T=> >ransfer-Encoding: quoted-printable
> >
> ><html><=> >;body style=3D3D"word-wrap: break-word; -webkit-nbsp-mode: space; =3D
&g=> >t; >-webkit-line-break: after-white-space; "><div =3D
> >=> >apple-content-edited=3D3D"true"><span class=3D3D"Apple-style-span" => >=3D
> >style=3D3D"border-collapse: separate; border-spacing: 0px 0=> >px; color: =3D
> >rgb(0, 0, 0); font-family: Helvetica; font-size:=> > 12px; font-style: =3D
> >normal; font-variant: normal; font-weigh=> >t: normal; letter-spacing: =3D
> >normal; line-height: normal; tex=> >t-align: auto; =3D
> >-khtml-text-decorations-in-effect: none; tex=> >t-indent: 0px; =3D
> >-apple-text-size-adjust: auto; text-transfor=> >m: none; orphans: 2; =3D
> >white-space: normal; widows: 2; word-s=> >pacing: 0px; "><div =3D
> >style=3D3D"word-wrap: break-word;=> > -khtml-nbsp-mode: space; =3D
> >-khtml-line-break: after-white-sp=> >ace; "><span class=3D3D"Apple-style-span" =3D
> >style=3D3D"=> >border-collapse: separate; border-spacing: 0px 0px; color: =3D
> >=> >rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =3D
&=> >gt; >normal; font-variant: normal; font-weight: normal; letter-spacing: => >=3D
> >normal; line-height: normal; text-align: auto; =3D
> => >>-khtml-text-decorations-in-effect: none; text-indent: 0px; =3D
> => >>-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =3D >>> >white-space: normal; widows: 2; word-spacing: 0px; =3D
> &g=> >t;">SOLgnu</span></div><div style=3D3D"word-wrap: break-w=> >ord; =3D
> >-khtml-nbsp-mode: space; -khtml-line-break: after-whit=> >e-space; =3D
> >">PPC_DARWIN</div><div style=3D3D"word=> >-wrap: break-word; -khtml-nbsp-mode: =3D
> >space; -khtml-line-bre=> >ak: after-white-space; ">I386_DARWIN</div><div =3D
> >=> >style=3D3D"word-wrap: break-word; -khtml-nbsp-mode: space; =3D
> >=> >-khtml-line-break: after-white-space; ">AMD64_DARWIN</div><div => >=3D
> >style=3D3D"word-wrap: break-word; -khtml-nbsp-mode: space; => >=3D
> >-khtml-line-break: after-white-space; ">LINUXLIBC6</d=> >iv><div =3D
> >style=3D3D"word-wrap: break-word; -khtml-nbsp=> >-mode: space; =3D
> >-khtml-line-break: after-white-space; ">I'=> >d like AMD64_LINUX,&nbsp;<span =3D
> >class=3D3D"Apple-styl=> >e-span" style=3D3D"font-family: Tahoma; font-size: =3D
> >13px; "&=> >gt;SPARC64_SOLARISN but no time right now to devote to =3D
> >them=> >.</span></div></span></div><br><div><=> >;div>On May 14, 2008, at 1:25 =3D
> >PM, Jay wrote:</div>=> ><br class=3D3D"Apple-interchange-newline"><blockquote =3D
> => >>type=3D3D"cite"><span class=3D3D"Apple-style-span" style=3D3D"bor=> >der-collapse: =3D
> >separate; color: rgb(0, 0, 0); font-family: H=> >elvetica; font-size: 12px; =3D
> >font-style: normal; font-variant=> >: normal; font-weight: normal; =3D
> >letter-spacing: normal; line=> >-height: normal; orphans: 2; text-align: =3D
> >auto; text-indent:=> > 0px; text-transform: none; white-space: normal; =3D
> >widows: 2;=> > word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =3D
> >=> >;-webkit-border-vertical-spacing: 0px; =3D
> >-webkit-text-decorat=> >ions-in-effect: none; -webkit-text-size-adjust: =3D
> >auto; -webk=> >it-text-stroke-width: 0; "><div class=3D3D"hmmessage" =3D
> >=> >;style=3D3D"font-size: 10pt; font-family: Tahoma; ">What do people =3D >R>> >run?<br>In particular: NetBSD? OpenBSD? Sparc32? Sparc64? => >PPC64_DARWIN? =3D
> >I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS?=> > ARM_WINCE? =3D
> >AMD64_NT?<br>&nbsp;<br>Just cur=> >ious, I'll probably bring up whatever I =3D
> >can, it's fun, and => >yes, get back and fix AMD64_LINUX to have<br>garbage =3D
> >=> >collection, NT386GNU and NT386 tests,&nbsp;cross-platform sets, setup => >=3D
> >some Tinderboxes, etc...<br>&nbsp;<br>(AMD6=> >4_NT: the gcc available for =3D
> >this includes a bunch of patche=> >s, so I'm inclined to either wait for =3D
> >them to go upstream,&=> >lt;br>or seek an alternate route such as "port" the =3D
> >in-p=> >roc backend, llvm, generate C, or maybe write an interpreter for the =3D >>> >IL;<br>and "porting" the backend is probably best preceded => >by a) x86 =3D
> >LONGINT support b) other x86 targets "for practis=> >e", at least =3D
> >one,<br>though regarding .obj file forma=> >ts, that would be =3D
> >tangential.)<br>&nbsp;<br>=> >;&nbsp;- =3D
> >Jay<br><br><br><br><=> >;br></div></span></blockquote></div><br>&l=> >t;/body></html>=3D
> >
> >--Apple-Mail-4-6310280=> >10--

> >=> >> >--_14c076c4-fb7c-48b0-b705-2e38d4b4a333_--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mika at async.caltech.edu  Fri May 16 08:46:35 2008
From: mika at async.caltech.edu (Mika Nystrom)
Date: Thu, 15 May 2008 23:46:35 -0700
Subject: [M3devel] which platforms? and questions about FreeBSD
	versioning
In-Reply-To: Your message of "Fri, 16 May 2008 06:40:49 -0000."
	 
Message-ID: <200805160646.m4G6kZTb068480@camembert.async.caltech.edu>


Did you check the system call numbers?  I often get ... "unknown
system call", I think, when I try to do what you are describing.

By the way I have had far less trouble using binaries across versions
of FreeBSD than trying the same trick on Linux... maybe I just know
better what I am doing on FreeBSD?  I have some very very old programs
that still work fine.  Even the compiler tends to keep working when
upgrading from one major version to the next.  (But yes you do need
to have the compatibility libraries installed on the new system.)

     Mika

Jay writes:
>--_a9d87328-63f1-414c-abcb-03c34a9cee30_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>Wow that is crazy.
>The "OS" is backwards compatible.
>The tools -- or at least the headers/libs -- are not backwards compatible.
>They apparently don't produce binaries that run on older systems.
>=20
>Hm, so I did some diffing amongm3-libs\m3core\src\unix\freebsd-*
>they are all amost identical.and almost all compatible.Freebsd-1 to -2 is t=
>he least compatible.otherwise the only actual difference I see is in Usigna=
>l sa_flags and sa_mask getting reversed. and sigcontext changed.
>Otherwise it's mostly things like long vs. unsigned_long,int64_t vs. quad_t=
>, short vs. int16_t.
>The DIR record grew, but as long as it is not implementedin Modula-3 and th=
>e new fields not access, no matter.
>Oh one errno value changed.
>Sometimes some types or functions got added, but that is ok.
>=20
>Maybe more research at a might later date...
>=20
> - Jay
>
>
>
>> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel=
>] which platforms? and questions about FreeBSD versioning > Date: Thu, 15 M=
>ay 2008 22:54:28 -0700> From: mika at async.caltech.edu> > > No, sorry, haven'=
>t gotten around to testing the current NT386GNU> cm3... I have a lot of ver=
>sion synchronizing to do, unfortunately :(> > Yes, FreeBSD is backwards-com=
>patible, *not* forwards-compatible.> That is, you can build even fairly com=
>plex software packages on an old> FreeBSD system and expect it to run on th=
>e latest release. You cannot,> as a general rule, build anything on a newer=
> system and expect it to work> on an older one. There must be "some" way of=
> doing it that way, but> I don't know what it is, and I don't know if it's =
>very well supported.> I keep FreeBSD 4.x systems around for precisely this =
>reason: the binaries> compiled there work fine on 5.x and 6.x (as far as I =
>have tested). Not> the other way around! In fact it has never worked the ot=
>her way, as > long as I can remember, with FreeBSD.> > This is also why I s=
>uggest that a "FreeBSD4" bootstrap should actually> be built on FreeBSD 4.x=
> and not 5.x, 6.x, or 7.x!> > Mika> > Jay writes:> >--_14c076c4-fb7c-48b0-b=
>705-2e38d4b4a333_> >Content-Type: text/plain; charset=3D"iso-8859-1"> >Cont=
>ent-Transfer-Encoding: quoted-printable> >> >Mika, ok, this is tangential: =
>Have you tried the current NT386GNU cm3?> >=3D20> >I meant, more about what=
> "operating systems" that Modula-3 does not support=3D> > do people here us=
>e, would like to see Modula-3 on. Or maybe I meant both.> >=3D20> >Speaking=
> of the "4" in FreeBSD4:> >=3D20> >Has FreeBSD, and the other BSDs, really =
>broken backward compat?> >They really change interfaces a lot such that bin=
>aries built with current h=3D> >eaders/libs won't run on older versions?> >=
>And there isn't an easy way on current platforms to build something using o=
>=3D> >lder tools to run on older and newer platforms?> >Look at Windows for=
> example. If you call a "new" function directly, you wil=3D> >l fail to loa=
>d on older platforms. So either don't call them, or use LoadLi=3D> >brary/G=
>etProcAddress. Structures almost never change size, though there is =3D> >s=
>ome screwiness there, stuff like:> >=3D20> >struct FOO { size_t Size;> > in=
>t Field1;> >#if VERSION > 1234> > int Field2;> >#endif> >};> >=3D20> >I thi=
>nk it should be more like:> >=3D20> >struct FOO { size_t Size;> > int Field=
>1;> >#if VERSION > 1234> > int Field2;> >#endif> >};> >=3D20> >struct FOO_V=
>1{ size_t Size;> > int Field1;> >};> >=3D20> >struct FOO_V2 { size_t Size;>=
> > int Field1;> > int Field2;> >};> >=3D20> >#if VERSION > 1234> >typedef F=
>OO_V2 FOO;> >#else> >typedef FOO_V1 FOO;> >#endif> >=3D20> >I understand th=
>at binaries built on the older platform will continue to wor=3D> >k on the =
>newer platform.> >That is one thing.> >But it is also useful to be able to =
>build binaries on the newer platform th=3D> >at will on the older platform.=
>> >Apple also invests a bunch here.> >=3D20> >Well, ok, if it was really "b=
>ad", there'd be FreeBSD5, 6, 7.> >I guess maybe they broke this stuff somet=
>imes but haven't in a while?> >That you can build FreeBSD4 binaries on Free=
>BSD7 and the run down to 4?> >=3D20> >And then, same questions about OpenBS=
>D and NetBSD.> >I understand -- I could/must go and install a bajillion ope=
>rating systems a=3D> >nd test and find out, but I don't expect to spend the=
> time that way and pus=3D> >h comes to shove, any BSD (and Linux, Solaris, =
>NT, CE, etc.) variants I int=3D> >roduce will have no version number in the=
>m, will be built on whatever I hav=3D> >e, and it will be unknown if they w=
>ork on older. And maybe something will m=3D> >aterialize to be more portabl=
>e, like interfacing to the Posix via C instead=3D> > of cloned headers.> >=
>=3D20> > - Jay> >> >> >> >> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.=
>com> Subject: Re: [M3devel=3D> >] which platforms? > Date: Thu, 15 May 2008=
> 14:30:36 -0700> From: mika at asyn=3D> >c.caltech.edu> > here it is:> > FreeB=
>SD4> PPC_DARWIN> NT386GNU> LINUXLIBC6>=3D> > > I386_DARWIN coming soon> > T=
>ony Hosking writes:> >> >--Apple-Mail-4-6310=3D> >28010> >Content-Type: tex=
>t/plain;> > charset=3D3DUS-ASCII;> > format=3D3Dflowed=3D> >;> > delsp=3D3D=
>yes> >Content-Transfer-Encoding: 7bit> >> >SOLgnu> >PPC_DARWIN=3D> >> >I386=
>_DARWIN> >AMD64_DARWIN> >LINUXLIBC6> >I'd like AMD64_LINUX, SPARC64_=3D> >S=
>OLARISN but no time right now to devote > >to them.> >> >On May 14, 2008, =
>=3D> >at 1:25 PM, Jay wrote:> >> >> What do people run?> >> In particular: =
>NetBSD=3D> >? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN? > >> I386_SOLARIS? A=
>MD64_SOLARIS=3D> >? SPARC64_SOLARIS? ARM_WINCE? AMD64_NT?> >>> >> Just curi=
>ous, I'll probably=3D> > bring up whatever I can, it's fun, and > >> yes, g=
>et back and fix AMD64_LI=3D> >NUX to have> >> garbage collection, NT386GNU =
>and NT386 tests, cross-platfor=3D> >m sets, > >> setup some Tinderboxes, et=
>c...> >>> >> (AMD64_NT: the gcc avai=3D> >lable for this includes a bunch o=
>f patches, > >> so I'm inclined to either =3D> >wait for them to go upstrea=
>m,> >> or seek an alternate route such as "port"=3D> > the in-proc backend,=
> llvm, > >> generate C, or maybe write an interpreter =3D> >for the IL;> >>=
> and "porting" the backend is probably best preceded by a) x=3D> >86 > >> L=
>ONGINT support b) other x86 targets "for practise", at least one,>=3D> > >>=
> though regarding .obj file formats, that would be tangential.)> >>> >> =3D=
>> >- Jay> >>> >>> >>> >>> >> >> >--Apple-Mail-4-631028010> >Content-Type: t=
>ext=3D> >/html;> > charset=3D3DUS-ASCII> >Content-Transfer-Encoding: quoted=
-printable>=3D> > >> >it-nbsp-mode: space=3D> >; =3D3D> >-webkit-line-break: after-white-space; "=
>>
 >apple-content-e=3D> >dited=3D3D3D"true">ple-style-span" =3D3D> >style=3D3D3D"border=3D> >-collapse: separate; borde=
>r-spacing: 0px 0px; color: =3D3D> >rgb(0, 0, 0); fo=3D> >nt-family: Helveti=
>ca; font-size: 12px; font-style: =3D3D> >normal; font-varia=3D> >nt: normal=
>; font-weight: normal; letter-spacing: =3D3D> >normal; line-height:=3D> > n=
>ormal; text-align: auto; =3D3D> >-khtml-text-decorations-in-effect: none; t=
>=3D> >ext-indent: 0px; =3D3D> >-apple-text-size-adjust: auto; text-transfor=
>m: none;=3D> > orphans: 2; =3D3D> >white-space: normal; widows: 2; word-spa=
>cing: 0px; "> >v =3D3D> >style=3D3D3D"word-wrap: break-word; -khtml-=
>nbsp-mode: space; =3D3D> >-k=3D> >html-line-break: after-white-space; ">an class=3D3D3D"Apple-style-span" =3D> >=3D3D> >style=3D3D3D"border-collaps=
>e: separate; border-spacing: 0px 0px; color:=3D> > =3D3D> >rgb(0, 0, 0); fo=
>nt-family: Helvetica; font-size: 12px; font-style: =3D> >=3D3D> >normal; fo=
>nt-variant: normal; font-weight: normal; letter-spacing: =3D> >=3D3D> >norm=
>al; line-height: normal; text-align: auto; =3D3D> >-khtml-text-deco=3D> >ra=
>tions-in-effect: none; text-indent: 0px; =3D3D> >-apple-text-size-adjust: a=
>=3D> >uto; text-transform: none; orphans: 2; =3D3D> >white-space: normal; w=
>idows: 2=3D> >; word-spacing: 0px; =3D3D> >">SOLgnu
=3D3D3D"word-wrap: =3D> >break-word; =3D3D> >-khtml-nbsp-mode: space; -khtm=
>l-line-break: after-white-s=3D> >pace; =3D3D> >">PPC_DARWIN
=3D3D3D"word-wrap: break-word; -khtml=3D> >-nbsp-mode: =3D3D> >space; -khtm=
>l-line-break: after-white-space; ">I386_DARWI=3D> >N
 >styl=
>e=3D3D3D"word-wrap: break-word; -khtml-nbsp-mode: space=3D> >; =3D3D> >-kht=
>ml-line-break: after-white-space; ">AMD64_DARWIN
=3D> > >st=
>yle=3D3D3D"word-wrap: break-word; -khtml-nbsp-mode: space; =3D3D> >-khtml-l=
>=3D> >ine-break: after-white-space; ">LINUXLIBC6
 >style=3D=
>3D3D"word-=3D> >wrap: break-word; -khtml-nbsp-mode: space; =3D3D> >-khtml-l=
>ine-break: after-w=3D> >hite-space; ">I'd like AMD64_LINUX, D> >class=3D3D3D"Apple-style=3D> >-span" style=3D3D3D"font-family: Tahoma; =
>font-size: =3D3D> >13px; ">SPARC64_SOL=3D> >ARISN but no time right now to =
>devote to =3D3D> >them.
 >iv>
On May=
> 14, 2008, at 1:25 =3D3D> >PM, Jay wrote:

 >ss=3D3D3D"Apple=
>-interchange-newline">
 >type=3D3D3D"cite"> >cla=
>ss=3D3D3D"Apple-style-span" style=3D3D3D"border-collapse: =3D3D> >separate;=
> co=3D> >lor: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =3D3D>=
> >font-styl=3D> >e: normal; font-variant: normal; font-weight: normal; =3D3=
>D> >letter-spacing:=3D> > normal; line-height: normal; orphans: 2; text-ali=
>gn: =3D3D> >auto; text-inde=3D> >nt: 0px; text-transform: none; white-space=
>: normal; =3D3D> >widows: 2; word-s=3D> >pacing: 0px; -webkit-border-horizo=
>ntal-spacing: 0px; =3D3D> >-webkit-border-v=3D> >ertical-spacing: 0px; =3D3=
>D> >-webkit-text-decorations-in-effect: none; -webk=3D> >it-text-size-adjus=
>t: =3D3D> >auto; -webkit-text-stroke-width: 0; ">
 >=3D3D3D"hm=
>message" =3D3D> >style=3D3D3D"font-size: 10pt; font-family: Tahoma; ">W=3D>=
> >hat do people =3D3D> >run?
In particular: NetBSD? OpenBSD? Sparc32? Sp=
>arc6=3D> >4? PPC64_DARWIN? =3D3D> >I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOL=
>ARIS? ARM_WI=3D> >NCE? =3D3D> >AMD64_NT?
 
Just curious, I'll pr=
>obably bring up what=3D> >ever I =3D3D> >can, it's fun, and yes, get back a=
>nd fix AMD64_LINUX to have >r>garbage =3D3D> >collection, NT386GNU an=
>d NT386 tests, cross-platform s=3D> >ets, setup =3D3D> >some Tinderbox=
>es, etc...
 
(AMD64_NT: the gcc a=3D> >vailable for =3D3D> >this=
> includes a bunch of patches, so I'm inclined to eit=3D> >her wait for =3D3=
>D> >them to go upstream,
or seek an alternate route such =3D> >as "port"=
> the =3D3D> >in-proc backend, llvm, generate C, or maybe write an in=3D> >t=
>erpreter for the =3D3D> >IL;
and "porting" the backend is probably best =
>p=3D> >receded by a) x86 =3D3D> >LONGINT support b) other x86 targets "for =
>practise"=3D> >, at least =3D3D> >one,
though regarding .obj file format=
>s, that would be =3D> >=3D3D> >tangential.)
 
 - =3D3D> >Ja=
>y




=3D> >

l>=3D3D> >> >--Apple-Mail-4-6310280=3D> >10--=3D> >> >--_14c076c4-fb7c-48b0=
>-b705-2e38d4b4a333_> >Content-Type: text/html; charset=3D"iso-8859-1"> >Con=
>tent-Transfer-Encoding: quoted-printable> >> >> >> >> >> >3D'hmmessage'>Mika, ok, this is tangential: Have you =3D> >tried =
>the current NT386GNU cm3?
> > 
> >I meant, more about what "oper=
>ating systems" that Modula-3 does not support=3D> > do people here use, wou=
>ld like to see Modula-3 on. Or maybe I meant both.<=3D> >BR>> > 
> =
>>Speaking of the "4" in FreeBSD4:
> > 
> >Has FreeBSD, and the o=
>ther BSDs, really broken backward compat?
> >They really change int=
>erfaces a lot such that binaries built with current h=3D> >eaders/libs won'=
>t run on older versions?
> >And there isn't an easy way on current platf=
>orms to build something using o=3D> >lder tools to run on older and newer p=
>latforms?
> >Look at Windows for example. If you call a "new" function d=
>irectly, you wil=3D> >l fail to load on older platforms. So either don't ca=
>ll them, or use LoadLi=3D> >brary/GetProcAddress. Structures almost never c=
>hange size, though there is =3D> >some screwiness there, stuff like:
> >=
> 
> >struct FOO {
  size_t Size;
> >  int Field1;R>> >#if VERSION > 1234
> >  int Field2;
> >#endif
> >};R>> > 
> >I think it should be more like:
> > 
> >struct=
> FOO {
  size_t Size;
> >  int Field1;
> >#if VERSION &g=
>t; 1234
> >  int Field2;
> >#endif
> >};
> > 
> >s=
>truct FOO_V1{
  size_t Size;
> >  int Field1;
> >};
>=
> > 
> >struct FOO_V2 {
  size_t Size;
> >  int Fiel=
>d1;
> >  int Field2;
> >};
> > 
> >#if VERSION > 1=
>234
> >typedef FOO_V2 FOO;
> >#else
> >typedef FOO_V1 FOO;
> >#=
>endif
> > 
> >I understand that binaries built on the older plat=
>form will continue to wor=3D> >k on the newer platform.
> >That is one t=
>hing.
> >But it is also useful to be able to build binaries on the newer=
> platform th=3D> >at will on the older platform.
> >Apple also invests a=
> bunch here.
> > 
> >Well, ok, if it was really "bad", there'd b=
>e FreeBSD5, 6, 7.
> >I guess maybe they broke this stuff sometimes but h=
>aven't in a while?
> >That you can build FreeBSD4 binaries on FreeBSD7 a=
>nd the run down to 4?
> > 
> >And then, same questions about Ope=
>nBSD and NetBSD.
> >I understand -- I could/must go and install a bajill=
>ion operating systems a=3D> >nd test and find out, but I don't expect to sp=
>end the time that way and pus=3D> >h comes to shove, any BSD (and Linux, So=
>laris, NT, CE, etc.) variants I int=3D> >roduce will have no version number=
> in them, will be built on whatever I hav=3D> >e, and it will be unknown if=
> they work on older. And maybe something will m=3D> >aterialize to be more =
>portable, like interfacing to the Posix via C instead=3D> > of cloned heade=
>rs.
> > 
> > - Jay


> >> >
>> >
> >> To: jayk123 at hotmail.com
> CC: m3devel at elegosoft.comR>> Subj=3D> >ect: Re: [M3devel] which platforms? 
> Date: Thu, 15=
> May 2008 14:30:3=3D> >6 -0700
> From: mika at async.caltech.edu
>=
> 
> here it is: >R>> 
> FreeBSD4
> PPC_DARWIN>> NT386GNU
> LINUXL=3D> >IBC6
> 
> I386_DARWIN coming=
> soon
> 
> Tony Hosking=3D> > writes:
> >
> >=
>--Apple-Mail-4-631028010
> >Cont=3D> >ent-Type: text/plain;
>=
>; > charset=3D3DUS-ASCII;
> > format=3D> >=3D3Dflowed;
> =
>> delsp=3D3Dyes
> >Content-Transfer-Encoding: =3D> >7bit
>=
>; >
> >SOLgnu
> >PPC_DARWIN
> >I38=3D> >6_DAR=
>WIN
> >AMD64_DARWIN
> >LINUXLIBC6
> >I'd li=3D> =
>>ke AMD64_LINUX, SPARC64_SOLARISN but no time right now to devote 
> =
>&=3D> >gt;to them.
> >
> >On May 14, 2008, at 1:25 PM, Ja=
>y wrote=3D> >:
> >
> >> What do people run?
> &g=
>t;> In par=3D> >ticular: NetBSD? OpenBSD? Sparc32? Sparc64? PPC64_DARWIN=
>? 
> >>=3D> > I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM=
>_WINCE? AMD64_NT?
>=3D> > >>
> >> Just curious, I'l=
>l probably bring up whatever I =3D> >can, it's fun, and 
> >> y=
>es, get back and fix AMD64_LINUX to h=3D> >ave
> >> garbage col=
>lection, NT386GNU and NT386 tests, cross-pl=3D> >atform sets, 
> >=
>> setup some Tinderboxes, etc...
> >&=3D> >gt;
> >>=
> (AMD64_NT: the gcc available for this includes a bunch=3D> > of patches, <=
>BR>> >> so I'm inclined to either wait for them to g=3D> >o upstre=
>am,
> >> or seek an alternate route such as "port" the =3D> >in=
>-proc backend, llvm, 
> >> generate C, or maybe write an inte=
>=3D> >rpreter for the IL;
> >> and "porting" the backend is pro=
>bably =3D> >best preceded by a) x86 
> >> LONGINT support b) ot=
>her x86 targ=3D> >ets "for practise", at least one,
> >> though=
> regarding .obj fi=3D> >le formats, that would be tangential.)
> >=
>>
> >> - =3D> >Jay
> >>
> >>
>=
> >>
> >>
=3D> >> >
> >
> >--Ap=
>ple-Mail-4-631028010
> >Con=3D> >tent-Type: text/html;
> >=
>; charset=3D3DUS-ASCII
> >Content-T=3D> >ransfer-Encoding: quoted-=
>printable
> >
> ><html><=3D> >;body style=3D3D3D"=
>word-wrap: break-word; -webkit-nbsp-mode: space; =3D3D
&g=3D> >t; >-w=
>ebkit-line-break: after-white-space; "><div =3D3D
> >=3D> >a=
>pple-content-edited=3D3D3D"true"><span class=3D3D3D"Apple-style-span"=
> =3D> >=3D3D
> >style=3D3D3D"border-collapse: separate; border-spa=
>cing: 0px 0=3D> >px; color: =3D3D
> >rgb(0, 0, 0); font-family: He=
>lvetica; font-size:=3D> > 12px; font-style: =3D3D
> >normal; font-=
>variant: normal; font-weigh=3D> >t: normal; letter-spacing: =3D3D
> &=
>gt;normal; line-height: normal; tex=3D> >t-align: auto; =3D3D
> >-=
>khtml-text-decorations-in-effect: none; tex=3D> >t-indent: 0px; =3D3D
&g=
>t; >-apple-text-size-adjust: auto; text-transfor=3D> >m: none; orphans: =
>2; =3D3D
> >white-space: normal; widows: 2; word-s=3D> >pacing: 0p=
>x; "><div =3D3D
> >style=3D3D3D"word-wrap: break-word;=3D> >=
> -khtml-nbsp-mode: space; =3D3D
> >-khtml-line-break: after-white-=
>sp=3D> >ace; "><span class=3D3D3D"Apple-style-span" =3D3D
> >=
>;style=3D3D3D"=3D> >border-collapse: separate; border-spacing: 0px 0px; col=
>or: =3D3D
> >=3D> >rgb(0, 0, 0); font-family: Helvetica; font-size=
>: 12px; font-style: =3D3D
&=3D> >gt; >normal; font-variant: normal; f=
>ont-weight: normal; letter-spacing: =3D> >=3D3D
> >normal; line-he=
>ight: normal; text-align: auto; =3D3D
> =3D> >>-khtml-text-decorat=
>ions-in-effect: none; text-indent: 0px; =3D3D
> =3D> >>-apple-text=
>-size-adjust: auto; text-transform: none; orphans: 2; =3D3D >>> &=
>gt;white-space: normal; widows: 2; word-spacing: 0px; =3D3D
> &g=3D> =
>>t;">SOLgnu</span></div><div style=3D3D3D"word-wrap: brea=
>k-w=3D> >ord; =3D3D
> >-khtml-nbsp-mode: space; -khtml-line-break:=
> after-whit=3D> >e-space; =3D3D
> >">PPC_DARWIN</div><=
>div style=3D3D3D"word=3D> >-wrap: break-word; -khtml-nbsp-mode: =3D3D
&g=
>t; >space; -khtml-line-bre=3D> >ak: after-white-space; ">I386_DARWIN&=
>lt;/div><div =3D3D
> >=3D> >style=3D3D3D"word-wrap: break-wo=
>rd; -khtml-nbsp-mode: space; =3D3D
> >=3D> >-khtml-line-break: aft=
>er-white-space; ">AMD64_DARWIN</div><div =3D> >=3D3D
> &g=
>t;style=3D3D3D"word-wrap: break-word; -khtml-nbsp-mode: space; =3D> >=3D3D<=
>BR>> >-khtml-line-break: after-white-space; ">LINUXLIBC6</d=3D>=
> >iv><div =3D3D
> >style=3D3D3D"word-wrap: break-word; -khtm=
>l-nbsp=3D> >-mode: space; =3D3D
> >-khtml-line-break: after-white-=
>space; ">I'=3D> >d like AMD64_LINUX,&nbsp;<span =3D3D
> >=
>;class=3D3D3D"Apple-styl=3D> >e-span" style=3D3D3D"font-family: Tahoma; fon=
>t-size: =3D3D
> >13px; "&=3D> >gt;SPARC64_SOLARISN but no time rig=
>ht now to devote to =3D3D
> >them=3D> >.</span></div>&=
>lt;/span></div><br><div><=3D> >;div>On May 14, 20=
>08, at 1:25 =3D3D
> >PM, Jay wrote:</div>=3D> ><br class=
>=3D3D3D"Apple-interchange-newline"><blockquote =3D3D
> =3D> >&g=
>t;type=3D3D3D"cite"><span class=3D3D3D"Apple-style-span" style=3D3D3D=
>"bor=3D> >der-collapse: =3D3D
> >separate; color: rgb(0, 0, 0); fo=
>nt-family: H=3D> >elvetica; font-size: 12px; =3D3D
> >font-style: =
>normal; font-variant=3D> >: normal; font-weight: normal; =3D3D
> >=
>letter-spacing: normal; line=3D> >-height: normal; orphans: 2; text-align: =
>=3D3D
> >auto; text-indent:=3D> > 0px; text-transform: none; white=
>-space: normal; =3D3D
> >widows: 2;=3D> > word-spacing: 0px; -webk=
>it-border-horizontal-spacing: 0px; =3D3D
> >=3D> >;-webkit-border-v=
>ertical-spacing: 0px; =3D3D
> >-webkit-text-decorat=3D> >ions-in-e=
>ffect: none; -webkit-text-size-adjust: =3D3D
> >auto; -webk=3D> >i=
>t-text-stroke-width: 0; "><div class=3D3D3D"hmmessage" =3D3D
> =
>>=3D> >;style=3D3D3D"font-size: 10pt; font-family: Tahoma; ">What do p=
>eople =3D3D >R>> >run?<br>In particular: NetBSD? OpenBSD?=
> Sparc32? Sparc64? =3D> >PPC64_DARWIN? =3D3D
> >I386_SOLARIS? AMD6=
>4_SOLARIS? SPARC64_SOLARIS?=3D> > ARM_WINCE? =3D3D
> >AMD64_NT?<=
>;br>&nbsp;<br>Just cur=3D> >ious, I'll probably bring up whate=
>ver I =3D3D
> >can, it's fun, and =3D> >yes, get back and fix AMD6=
>4_LINUX to have<br>garbage =3D3D
> >=3D> >collection, NT386G=
>NU and NT386 tests,&nbsp;cross-platform sets, setup =3D> >=3D3D
>=
> >some Tinderboxes, etc...<br>&nbsp;<br>(AMD6=3D> >4_NT:=
> the gcc available for =3D3D
> >this includes a bunch of patche=3D=
>> >s, so I'm inclined to either wait for =3D3D
> >them to go upstr=
>eam,&=3D> >lt;br>or seek an alternate route such as "port" the =3D3D
=
>> >in-p=3D> >roc backend, llvm, generate C, or maybe write an interpr=
>eter for the =3D3D >>> >IL;<br>and "porting" the backend=
> is probably best preceded =3D> >by a) x86 =3D3D
> >LONGINT suppor=
>t b) other x86 targets "for practis=3D> >e", at least =3D3D
> >one=
>,<br>though regarding .obj file forma=3D> >ts, that would be =3D3D>> >tangential.)<br>&nbsp;<br>=3D> >;&nbsp;- =3D3D=
>
> >Jay<br><br><br><br><=3D> >;br><=
>;/div></span></blockquote></div><br>&l=3D> >t;/b=
>ody></html>=3D3D
> >
> >--Apple-Mail-4-6310280=
>=3D> >10--

> >=3D> >> >--_14c076c4-fb7c-48b0-b705-2e38=
>d4b4a333_--=
>
>--_a9d87328-63f1-414c-abcb-03c34a9cee30_
>Content-Type: text/html; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>
>
>
>
>Wow that is crazy.

>The "OS" is backwards compatible.

>The tools -- or at least the headers/libs -- are not backwards compati=
>ble.

>They apparently don't produce binaries that run on older systems.

> 

>Hm, so I did some diffing among
m3-libs\m3core\src\unix\freebsd-*

>they are all amost identical.
and almost all compatible.
Freebsd-1 to=
> -2 is the least compatible.
otherwise the only actual difference I see =
>is
 in Usignal sa_flags and sa_mask getting reversed.
 and =
>sigcontext changed.

>
Otherwise it's mostly things like long vs. unsigned_long,
int64_t vs=
>. quad_t, short vs. int16_t.

>
The DIR record grew, but as long as it is not implemented
in Modula-=
>3 and the new fields not access, no matter.

>Oh one errno value changed.

>Sometimes some types or functions got added, but
 that is ok.

> 

>Maybe more research at a might later date...

> 

> - Jay



>
>

>

>> To: jayk123 at hotmail.com
> CC: m3devel at elegosoft.com
> Subj=
>ect: Re: [M3devel] which platforms? and questions about FreeBSD versioning =
>
> Date: Thu, 15 May 2008 22:54:28 -0700
> From: mika at async.cal=
>tech.edu
> 
> 
> No, sorry, haven't gotten around to test=
>ing the current NT386GNU
> cm3... I have a lot of version synchronizi=
>ng to do, unfortunately :(
> 
> Yes, FreeBSD is backwards-compa=
>tible, *not* forwards-compatible.
> That is, you can build even fairl=
>y complex software packages on an old
> FreeBSD system and expect it =
>to run on the latest release. You cannot,
> as a general rule, build =
>anything on a newer system and expect it to work
> on an older one. T=
>here must be "some" way of doing it that way, but
> I don't know what=
> it is, and I don't know if it's very well supported.
> I keep FreeBS=
>D 4.x systems around for precisely this reason: the binaries
> compil=
>ed there work fine on 5.x and 6.x (as far as I have tested). Not
> th=
>e other way around! In fact it has never worked the other way, as 
> =
>long as I can remember, with FreeBSD.
> 
> This is also why I s=
>uggest that a "FreeBSD4" bootstrap should actually
> be built on Free=
>BSD 4.x and not 5.x, 6.x, or 7.x!
> 
> Mika
> 
> Ja=
>y writes:
> >--_14c076c4-fb7c-48b0-b705-2e38d4b4a333_
> >=
>Content-Type: text/plain; charset=3D"iso-8859-1"
> >Content-Transf=
>er-Encoding: quoted-printable
> >
> >Mika, ok, this is ta=
>ngential: Have you tried the current NT386GNU cm3?
> >=3D20
>=
>; >I meant, more about what "operating systems" that Modula-3 does not s=
>upport=3D
> > do people here use, would like to see Modula-3 on. O=
>r maybe I meant both.
> >=3D20
> >Speaking of the "4" in =
>FreeBSD4:
> >=3D20
> >Has FreeBSD, and the other BSDs, re=
>ally broken backward compat?
> >They really change interfaces a lo=
>t such that binaries built with current h=3D
> >eaders/libs won't =
>run on older versions?
> >And there isn't an easy way on current p=
>latforms to build something using o=3D
> >lder tools to run on old=
>er and newer platforms?
> >Look at Windows for example. If you cal=
>l a "new" function directly, you wil=3D
> >l fail to load on older=
> platforms. So either don't call them, or use LoadLi=3D
> >brary/G=
>etProcAddress. Structures almost never change size, though there is =3D
=
>> >some screwiness there, stuff like:
> >=3D20
> >s=
>truct FOO { size_t Size;
> > int Field1;
> >#if VERSION &=
>gt; 1234
> > int Field2;
> >#endif
> >};
>=
> >=3D20
> >I think it should be more like:
> >=3D20>> >struct FOO { size_t Size;
> > int Field1;
> >#i=
>f VERSION > 1234
> > int Field2;
> >#endif
> >=
>;};
> >=3D20
> >struct FOO_V1{ size_t Size;
> > =
>int Field1;
> >};
> >=3D20
> >struct FOO_V2 { si=
>ze_t Size;
> > int Field1;
> > int Field2;
> >};=
>
> >=3D20
> >#if VERSION > 1234
> >typedef FO=
>O_V2 FOO;
> >#else
> >typedef FOO_V1 FOO;
> >#en=
>dif
> >=3D20
> >I understand that binaries built on the o=
>lder platform will continue to wor=3D
> >k on the newer platform.<=
>BR>> >That is one thing.
> >But it is also useful to be able=
> to build binaries on the newer platform th=3D
> >at will on the o=
>lder platform.
> >Apple also invests a bunch here.
> >=3D=
>20
> >Well, ok, if it was really "bad", there'd be FreeBSD5, 6, 7.=
>
> >I guess maybe they broke this stuff sometimes but haven't in a=
> while?
> >That you can build FreeBSD4 binaries on FreeBSD7 and th=
>e run down to 4?
> >=3D20
> >And then, same questions abo=
>ut OpenBSD and NetBSD.
> >I understand -- I could/must go and inst=
>all a bajillion operating systems a=3D
> >nd test and find out, bu=
>t I don't expect to spend the time that way and pus=3D
> >h comes =
>to shove, any BSD (and Linux, Solaris, NT, CE, etc.) variants I int=3D
&=
>gt; >roduce will have no version number in them, will be built on whatev=
>er I hav=3D
> >e, and it will be unknown if they work on older. An=
>d maybe something will m=3D
> >aterialize to be more portable, lik=
>e interfacing to the Posix via C instead=3D
> > of cloned headers.=
>
> >=3D20
> > - Jay
> >
> >
> >=
>;
> >> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com>=
>; Subject: Re: [M3devel=3D
> >] which platforms? > Date: Thu, 1=
>5 May 2008 14:30:36 -0700> From: mika at asyn=3D
> >c.caltech.edu&=
>gt; > here it is:> > FreeBSD4> PPC_DARWIN> NT386GNU> LINU=
>XLIBC6>=3D
> > > I386_DARWIN coming soon> > Tony Hoski=
>ng writes:> >> >--Apple-Mail-4-6310=3D
> >28010> &g=
>t;Content-Type: text/plain;> > charset=3D3DUS-ASCII;> > format=
>=3D3Dflowed=3D
> >;> > delsp=3D3Dyes> >Content-Transfe=
>r-Encoding: 7bit> >> >SOLgnu> >PPC_DARWIN=3D
> >=
>> >I386_DARWIN> >AMD64_DARWIN> >LINUXLIBC6> >I'd li=
>ke AMD64_LINUX, SPARC64_=3D
> >SOLARISN but no time right now to d=
>evote > >to them.> >> >On May 14, 2008, =3D
> >a=
>t 1:25 PM, Jay wrote:> >> >> What do people run?> >>=
>; In particular: NetBSD=3D
> >? OpenBSD? Sparc32? Sparc64? PPC64_D=
>ARWIN? > >> I386_SOLARIS? AMD64_SOLARIS=3D
> >? SPARC64_S=
>OLARIS? ARM_WINCE? AMD64_NT?> >>> >> Just curious, I'll p=
>robably=3D
> > bring up whatever I can, it's fun, and > >>=
>; yes, get back and fix AMD64_LI=3D
> >NUX to have> >> ga=
>rbage collection, NT386GNU and NT386 tests, cross-platfor=3D
> >m =
>sets, > >> setup some Tinderboxes, etc...> >>> >>=
>; (AMD64_NT: the gcc avai=3D
> >lable for this includes a bunch of=
> patches, > >> so I'm inclined to either =3D
> >wait for =
>them to go upstream,> >> or seek an alternate route such as "port"=
>=3D
> > the in-proc backend, llvm, > >> generate C, or ma=
>ybe write an interpreter =3D
> >for the IL;> >> and "port=
>ing" the backend is probably best preceded by a) x=3D
> >86 > &=
>gt;> LONGINT support b) other x86 targets "for practise", at least one,&=
>gt;=3D
> > >> though regarding .obj file formats, that would=
> be tangential.)> >>> >> =3D
> >- Jay> >&g=
>t;> >>> >>> >>> >> >> >--Apple=
>-Mail-4-631028010> >Content-Type: text=3D
> >/html;> >=
> charset=3D3DUS-ASCII> >Content-Transfer-Encoding: quoted-printable&g=
>t;=3D
> > >> ><html><body style=3D3D3D"word-wrap=
>: break-word; -webkit-nbsp-mode: space=3D
> >; =3D3D> >-webk=
>it-line-break: after-white-space; "><div =3D3D> >apple-content-=
>e=3D
> >dited=3D3D3D"true"><span class=3D3D3D"Apple-style-sp=
>an" =3D3D> >style=3D3D3D"border=3D
> >-collapse: separate; b=
>order-spacing: 0px 0px; color: =3D3D> >rgb(0, 0, 0); fo=3D
> &g=
>t;nt-family: Helvetica; font-size: 12px; font-style: =3D3D> >normal; =
>font-varia=3D
> >nt: normal; font-weight: normal; letter-spacing: =
>=3D3D> >normal; line-height:=3D
> > normal; text-align: auto=
>; =3D3D> >-khtml-text-decorations-in-effect: none; t=3D
> >e=
>xt-indent: 0px; =3D3D> >-apple-text-size-adjust: auto; text-transform=
>: none;=3D
> > orphans: 2; =3D3D> >white-space: normal; wido=
>ws: 2; word-spacing: 0px; "><di=3D
> >v =3D3D> >style=
>=3D3D3D"word-wrap: break-word; -khtml-nbsp-mode: space; =3D3D> >-k=3D=
>
> >html-line-break: after-white-space; "><span class=3D3D3D=
>"Apple-style-span" =3D
> >=3D3D> >style=3D3D3D"border-collap=
>se: separate; border-spacing: 0px 0px; color:=3D
> > =3D3D> >=
>;rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =3D
=
>> >=3D3D> >normal; font-variant: normal; font-weight: normal; l=
>etter-spacing: =3D
> >=3D3D> >normal; line-height: normal; t=
>ext-align: auto; =3D3D> >-khtml-text-deco=3D
> >rations-in-e=
>ffect: none; text-indent: 0px; =3D3D> >-apple-text-size-adjust: a=3D<=
>BR>> >uto; text-transform: none; orphans: 2; =3D3D> >white-spac=
>e: normal; widows: 2=3D
> >; word-spacing: 0px; =3D3D> >">=
>;SOLgnu</span></div><div style=3D3D3D"word-wrap: =3D
>=
> >break-word; =3D3D> >-khtml-nbsp-mode: space; -khtml-line-break: =
>after-white-s=3D
> >pace; =3D3D> >">PPC_DARWIN</div>=
>;<div style=3D3D3D"word-wrap: break-word; -khtml=3D
> >-nbsp-mo=
>de: =3D3D> >space; -khtml-line-break: after-white-space; ">I386_DA=
>RWI=3D
> >N</div><div =3D3D> >style=3D3D3D"word-wra=
>p: break-word; -khtml-nbsp-mode: space=3D
> >; =3D3D> >-khtm=
>l-line-break: after-white-space; ">AMD64_DARWIN</div><div =3D3D=
>>=3D
> > >style=3D3D3D"word-wrap: break-word; -khtml-nbsp-mo=
>de: space; =3D3D> >-khtml-l=3D
> >ine-break: after-white-spa=
>ce; ">LINUXLIBC6</div><div =3D3D> >style=3D3D3D"word-=3D<=
>BR>> >wrap: break-word; -khtml-nbsp-mode: space; =3D3D> >-khtml=
>-line-break: after-w=3D
> >hite-space; ">I'd like AMD64_LINUX,&=
>amp;nbsp;<span =3D3D> >class=3D3D3D"Apple-style=3D
> >-sp=
>an" style=3D3D3D"font-family: Tahoma; font-size: =3D3D> >13px; ">S=
>PARC64_SOL=3D
> >ARISN but no time right now to devote to =3D3D>=
>; >them.</span></div></span></d=3D
> >iv&g=
>t;<br><div><div>On May 14, 2008, at 1:25 =3D3D> >PM=
>, Jay wrote:</div><br cla=3D
> >ss=3D3D3D"Apple-interchan=
>ge-newline"><blockquote =3D3D> >type=3D3D3D"cite"><span =
>=3D
> >class=3D3D3D"Apple-style-span" style=3D3D3D"border-collapse=
>: =3D3D> >separate; co=3D
> >lor: rgb(0, 0, 0); font-family:=
> Helvetica; font-size: 12px; =3D3D> >font-styl=3D
> >e: norm=
>al; font-variant: normal; font-weight: normal; =3D3D> >letter-spacing=
>:=3D
> > normal; line-height: normal; orphans: 2; text-align: =3D3=
>D> >auto; text-inde=3D
> >nt: 0px; text-transform: none; whi=
>te-space: normal; =3D3D> >widows: 2; word-s=3D
> >pacing: 0p=
>x; -webkit-border-horizontal-spacing: 0px; =3D3D> >-webkit-border-v=
>=3D
> >ertical-spacing: 0px; =3D3D> >-webkit-text-decoration=
>s-in-effect: none; -webk=3D
> >it-text-size-adjust: =3D3D> >=
>auto; -webkit-text-stroke-width: 0; "><div class=3D
> >=3D3D=
>3D"hmmessage" =3D3D> >style=3D3D3D"font-size: 10pt; font-family: Taho=
>ma; ">W=3D
> >hat do people =3D3D> >run?<br>In part=
>icular: NetBSD? OpenBSD? Sparc32? Sparc6=3D
> >4? PPC64_DARWIN? =
>=3D3D> >I386_SOLARIS? AMD64_SOLARIS? SPARC64_SOLARIS? ARM_WI=3D
&g=
>t; >NCE? =3D3D> >AMD64_NT?<br>&nbsp;<br>Just curio=
>us, I'll probably bring up what=3D
> >ever I =3D3D> >can, it=
>'s fun, and yes, get back and fix AMD64_LINUX to have<b=3D
> >r=
>>garbage =3D3D> >collection, NT386GNU and NT386 tests,&nbsp;cr=
>oss-platform s=3D
> >ets, setup =3D3D> >some Tinderboxes, et=
>c...<br>&nbsp;<br>(AMD64_NT: the gcc a=3D
> >vaila=
>ble for =3D3D> >this includes a bunch of patches, so I'm inclined to =
>eit=3D
> >her wait for =3D3D> >them to go upstream,<br>=
>;or seek an alternate route such =3D
> >as "port" the =3D3D> &g=
>t;in-proc backend, llvm, generate C, or maybe write an in=3D
> >te=
>rpreter for the =3D3D> >IL;<br>and "porting" the backend is pro=
>bably best p=3D
> >receded by a) x86 =3D3D> >LONGINT support=
> b) other x86 targets "for practise"=3D
> >, at least =3D3D> &g=
>t;one,<br>though regarding .obj file formats, that would be =3D
&g=
>t; >=3D3D> >tangential.)<br>&nbsp;<br>&nbsp;- =
>=3D3D> >Jay<br><br><br><br><br></div=
>>=3D
> ></span></blockquote></div><br>&=
>lt;/body></html>=3D3D> >> >--Apple-Mail-4-6310280=3DR>> >10--=3D
> >
> >--_14c076c4-fb7c-48b0-b705-2e38=
>d4b4a333_
> >Content-Type: text/html; charset=3D"iso-8859-1"
&g=
>t; >Content-Transfer-Encoding: quoted-printable
> >
> >=
>;<html>
> ><head>
> ><style>
> &g=
>t;.hmmessage P
> >{
> >margin:0px;
> >padding:0p=
>x
> >}
> >body.hmmessage
> >{
> >FONT-S=
>IZE: 10pt;
> >FONT-FAMILY:Tahoma
> >}
> ></st=
>yle>
> ></head>
> ><body class=3D3D'hmmessage=
>'>Mika, ok, this is&nbsp;tangential:&nbsp;Have you =3D
> &=
>gt;tried the current NT386GNU cm3?<BR>
> >&nbsp;<BR&g=
>t;
> >I meant, more about what "operating systems" that Modula-3 d=
>oes not support=3D
> > do people here use, would like to see Modul=
>a-3 on. Or maybe I meant both.<=3D
> >BR>
> >&n=
>bsp;<BR>
> >Speaking of the "4" in FreeBSD4:<BR>
&g=
>t; >&nbsp;<BR>
> >Has FreeBSD, and the other BSDs, re=
>ally broken&nbsp;backward compat?<BR>
> >They really cha=
>nge interfaces a lot such that binaries built with current h=3D
> >=
>;eaders/libs won't run on older versions?<BR>
> >And there i=
>sn't an easy way on current platforms to build something using o=3D
>=
> >lder tools to run on older and newer platforms?<BR>
> >=
>Look at Windows for example. If you call a "new" function directly, you wil=
>=3D
> >l fail to load on older platforms. So either don't call the=
>m, or use LoadLi=3D
> >brary/GetProcAddress. Structures almost nev=
>er change size, though there is =3D
> >some screwiness there, stuf=
>f like:<BR>
> >&nbsp;<BR>
> >struct FOO {=
><BR>&nbsp; size_t Size;<BR>
> >&nbsp; int Fiel=
>d1;<BR>
> >#if VERSION &gt; 1234<BR>
> >&=
>amp;nbsp; int Field2;<BR>
> >#endif<BR>
> >};=
><BR>
> >&nbsp;<BR>
> >I think it should b=
>e more like:<BR>
> >&nbsp;<BR>
> >struct =
>FOO {<BR>&nbsp; size_t Size;<BR>
> >&nbsp; int=
> Field1;<BR>
> >#if VERSION &gt; 1234<BR>
> =
>>&nbsp; int Field2;<BR>
> >#endif<BR>
> &=
>gt;};<BR>
> >&nbsp;<BR>
> >struct FOO_V1{=
><BR>&nbsp; size_t Size;<BR>
> >&nbsp; int Fiel=
>d1;<BR>
> >};<BR>
> >&nbsp;<BR>
=
>> >struct FOO_V2 {<BR>&nbsp; size_t Size;<BR>
>=
> >&nbsp; int Field1;<BR>
> >&nbsp; int Field2;<=
>;BR>
> >};<BR>
> >&nbsp;<BR>
> &=
>gt;#if VERSION &gt; 1234<BR>
> >typedef FOO_V2 FOO;<B=
>R>
> >#else<BR>
> >typedef FOO_V1 FOO;<BR>=
>
> >#endif<BR>
> >&nbsp;<BR>
> >=
>I understand that binaries built on the older platform will continue to wor=
>=3D
> >k on the newer platform.<BR>
> >That is one =
>thing.<BR>
> >But it is also useful to be able to build bina=
>ries on the newer platform th=3D
> >at will on the older platform.=
><BR>
> >Apple also invests a bunch here.<BR>
> &=
>gt;&nbsp;<BR>
> >Well, ok, if it was really "bad", there=
>'d be FreeBSD5, 6, 7.<BR>
> >I guess maybe they broke this s=
>tuff sometimes but haven't in a while?<BR>
> >That you can b=
>uild FreeBSD4 binaries on FreeBSD7 and the run down to 4?<BR>
>=
> >&nbsp;<BR>
> >And then, same questions about OpenBS=
>D and NetBSD.<BR>
> >I understand -- I could/must go and ins=
>tall a bajillion operating systems a=3D
> >nd test and find out, b=
>ut I don't expect to spend the time that way and pus=3D
> >h comes=
> to shove, any BSD (and Linux, Solaris, NT, CE, etc.) variants I int=3D
=
>> >roduce will have no version number in them, will be built on whate=
>ver I hav=3D
> >e, and it will be unknown if they work on older. A=
>nd maybe something will m=3D
> >aterialize to be more portable, li=
>ke interfacing to the Posix via C instead=3D
> > of cloned headers=
>.<BR>
> >&nbsp;<BR>
> >&nbsp;- Jay<=
>;BR><BR><BR>
> >
> ><HR id=3D3DstopSpel=
>ling>
> ><BR>
> >&gt; To: jayk123 at hotmail.co=
>m<BR>&gt; CC: m3devel at elegosoft.com<BR>&gt; Subj=3D
=
>> >ect: Re: [M3devel] which platforms? <BR>&gt; Date: Thu, =
>15 May 2008 14:30:3=3D
> >6 -0700<BR>&gt; From: mika at asy=
>nc.caltech.edu<BR>&gt; <BR>&gt; here it is:<B=3D
=
>> >R>&gt; <BR>&gt; FreeBSD4<BR>&gt; PPC_DA=
>RWIN<BR>&gt; NT386GNU<BR>&gt; LINUXL=3D
> >IBC=
>6<BR>&gt; <BR>&gt; I386_DARWIN coming soon<BR>&am=
>p;gt; <BR>&gt; Tony Hosking=3D
> > writes:<BR>&=
>;gt; &gt;<BR>&gt; &gt;--Apple-Mail-4-631028010<BR>&=
>amp;gt; &gt;Cont=3D
> >ent-Type: text/plain;<BR>&gt;=
> &gt; charset=3D3DUS-ASCII;<BR>&gt; &gt; format=3D
>=
>; >=3D3Dflowed;<BR>&gt; &gt; delsp=3D3Dyes<BR>&g=
>t; &gt;Content-Transfer-Encoding: =3D
> >7bit<BR>&gt=
>; &gt;<BR>&gt; &gt;SOLgnu<BR>&gt; &gt;PPC_D=
>ARWIN<BR>&gt; &gt;I38=3D
> >6_DARWIN<BR>&g=
>t; &gt;AMD64_DARWIN<BR>&gt; &gt;LINUXLIBC6<BR>&=
>gt; &gt;I'd li=3D
> >ke AMD64_LINUX, SPARC64_SOLARISN but no t=
>ime right now to devote <BR>&gt; &=3D
> >gt;to them.=
><BR>&gt; &gt;<BR>&gt; &gt;On May 14, 2008, at 1=
>:25 PM, Jay wrote=3D
> >:<BR>&gt; &gt;<BR>&=
>;gt; &gt;&gt; What do people run?<BR>&gt; &gt;&gt=
>; In par=3D
> >ticular: NetBSD? OpenBSD? Sparc32? Sparc64? PPC64_D=
>ARWIN? <BR>&gt; &gt;&gt;=3D
> > I386_SOLARIS? AM=
>D64_SOLARIS? SPARC64_SOLARIS? ARM_WINCE? AMD64_NT?<BR>&gt;=3D
=
>> > &gt;&gt;<BR>&gt; &gt;&gt; Just curious,=
> I'll probably bring up whatever I =3D
> >can, it's fun, and <B=
>R>&gt; &gt;&gt; yes, get back and fix AMD64_LINUX to h=3D>> >ave<BR>&gt; &gt;&gt; garbage collection, NT386G=
>NU and NT386 tests, cross-pl=3D
> >atform sets, <BR>&gt;=
> &gt;&gt; setup some Tinderboxes, etc...<BR>&gt; &gt;=
>&=3D
> >gt;<BR>&gt; &gt;&gt; (AMD64_NT: the =
>gcc available for this includes a bunch=3D
> > of patches, <BR&=
>gt;&gt; &gt;&gt; so I'm inclined to either wait for them to g=
>=3D
> >o upstream,<BR>&gt; &gt;&gt; or seek an a=
>lternate route such as "port" the =3D
> >in-proc backend, llvm, &l=
>t;BR>&gt; &gt;&gt; generate C, or maybe write an inte=3D
=
>> >rpreter for the IL;<BR>&gt; &gt;&gt; and "portin=
>g" the backend is probably =3D
> >best preceded by a) x86 <BR&g=
>t;&gt; &gt;&gt; LONGINT support b) other x86 targ=3D
> &g=
>t;ets "for practise", at least one,<BR>&gt; &gt;&gt; thou=
>gh regarding .obj fi=3D
> >le formats, that would be tangential.)&=
>lt;BR>&gt; &gt;&gt;<BR>&gt; &gt;&gt; - =3D=
>
> >Jay<BR>&gt; &gt;&gt;<BR>&gt; &=
>gt;&gt;<BR>&gt; &gt;&gt;<BR>&gt; &gt;&a=
>mp;gt;<BR>=3D
> >&gt; &gt;<BR>&gt; &gt=
>;<BR>&gt; &gt;--Apple-Mail-4-631028010<BR>&gt; &=
>;gt;Con=3D
> >tent-Type: text/html;<BR>&gt; &gt; cha=
>rset=3D3DUS-ASCII<BR>&gt; &gt;Content-T=3D
> >ransfe=
>r-Encoding: quoted-printable<BR>&gt; &gt;<BR>&gt; &=
>amp;gt;&lt;html&gt;&lt=3D
> >;body style=3D3D3D"word-w=
>rap: break-word; -webkit-nbsp-mode: space; =3D3D<BR>&g=3D
>=
> >t; &gt;-webkit-line-break: after-white-space; "&gt;&lt;div=
> =3D3D<BR>&gt; &gt;=3D
> >apple-content-edited=3D3D3=
>D"true"&gt;&lt;span class=3D3D3D"Apple-style-span" =3D
> >=
>=3D3D<BR>&gt; &gt;style=3D3D3D"border-collapse: separate; bor=
>der-spacing: 0px 0=3D
> >px; color: =3D3D<BR>&gt; &g=
>t;rgb(0, 0, 0); font-family: Helvetica; font-size:=3D
> > 12px; fo=
>nt-style: =3D3D<BR>&gt; &gt;normal; font-variant: normal; fon=
>t-weigh=3D
> >t: normal; letter-spacing: =3D3D<BR>&gt; &=
>amp;gt;normal; line-height: normal; tex=3D
> >t-align: auto; =3D3D=
><BR>&gt; &gt;-khtml-text-decorations-in-effect: none; tex=3D<=
>BR>> >t-indent: 0px; =3D3D<BR>&gt; &gt;-apple-text-size=
>-adjust: auto; text-transfor=3D
> >m: none; orphans: 2; =3D3D<B=
>R>&gt; &gt;white-space: normal; widows: 2; word-s=3D
> >=
>;pacing: 0px; "&gt;&lt;div =3D3D<BR>&gt; &gt;style=3D=
>3D3D"word-wrap: break-word;=3D
> > -khtml-nbsp-mode: space; =3D3D&=
>lt;BR>&gt; &gt;-khtml-line-break: after-white-sp=3D
> >=
>ace; "&gt;&lt;span class=3D3D3D"Apple-style-span" =3D3D<BR>&a=
>mp;gt; &gt;style=3D3D3D"=3D
> >border-collapse: separate; bord=
>er-spacing: 0px 0px; color: =3D3D<BR>&gt; &gt;=3D
> >=
>;rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =3D3D&l=
>t;BR>&=3D
> >gt; &gt;normal; font-variant: normal; font=
>-weight: normal; letter-spacing: =3D
> >=3D3D<BR>&gt; &a=
>mp;gt;normal; line-height: normal; text-align: auto; =3D3D<BR>&gt=
>; =3D
> >&gt;-khtml-text-decorations-in-effect: none; text-ind=
>ent: 0px; =3D3D<BR>&gt; =3D
> >&gt;-apple-text-size-=
>adjust: auto; text-transform: none; orphans: 2; =3D3D<BR=3D
> >=
>>&gt; &gt;white-space: normal; widows: 2; word-spacing: 0px; =3D=
>3D<BR>&gt; &g=3D
> >t;"&gt;SOLgnu&lt;/span&a=
>mp;gt;&lt;/div&gt;&lt;div style=3D3D3D"word-wrap: break-w=3D>> >ord; =3D3D<BR>&gt; &gt;-khtml-nbsp-mode: space; -kh=
>tml-line-break: after-whit=3D
> >e-space; =3D3D<BR>&gt; =
>&gt;"&gt;PPC_DARWIN&lt;/div&gt;&lt;div style=3D3D3D"wor=
>d=3D
> >-wrap: break-word; -khtml-nbsp-mode: =3D3D<BR>&g=
>t; &gt;space; -khtml-line-bre=3D
> >ak: after-white-space; "&a=
>mp;gt;I386_DARWIN&lt;/div&gt;&lt;div =3D3D<BR>&gt; &a=
>mp;gt;=3D
> >style=3D3D3D"word-wrap: break-word; -khtml-nbsp-mode:=
> space; =3D3D<BR>&gt; &gt;=3D
> >-khtml-line-break: =
>after-white-space; "&gt;AMD64_DARWIN&lt;/div&gt;&lt;div =3D=
>
> >=3D3D<BR>&gt; &gt;style=3D3D3D"word-wrap: break-=
>word; -khtml-nbsp-mode: space; =3D
> >=3D3D<BR>&gt; &=
>;gt;-khtml-line-break: after-white-space; "&gt;LINUXLIBC6&lt;/d=3D<=
>BR>> >iv&gt;&lt;div =3D3D<BR>&gt; &gt;style=3D3=
>D3D"word-wrap: break-word; -khtml-nbsp=3D
> >-mode: space; =3D3D&l=
>t;BR>&gt; &gt;-khtml-line-break: after-white-space; "&gt;I'=
>=3D
> >d like AMD64_LINUX,&amp;nbsp;&lt;span =3D3D<BR&g=
>t;&gt; &gt;class=3D3D3D"Apple-styl=3D
> >e-span" style=3D3=
>D3D"font-family: Tahoma; font-size: =3D3D<BR>&gt; &gt;13px; "=
>&=3D
> >gt;SPARC64_SOLARISN but no time right now to devote to=
> =3D3D<BR>&gt; &gt;them=3D
> >.&lt;/span&gt;=
>&lt;/div&gt;&lt;/span&gt;&lt;/div&gt;&lt;br&=
>;gt;&lt;div&gt;&lt=3D
> >;div&gt;On May 14, 2008, =
>at 1:25 =3D3D<BR>&gt; &gt;PM, Jay wrote:&lt;/div&gt;=
>=3D
> >&lt;br class=3D3D3D"Apple-interchange-newline"&gt;&=
>amp;lt;blockquote =3D3D<BR>&gt; =3D
> >&gt;type=3D3D=
>3D"cite"&gt;&lt;span class=3D3D3D"Apple-style-span" style=3D3D3D"bo=
>r=3D
> >der-collapse: =3D3D<BR>&gt; &gt;separate; co=
>lor: rgb(0, 0, 0); font-family: H=3D
> >elvetica; font-size: 12px;=
> =3D3D<BR>&gt; &gt;font-style: normal; font-variant=3D
>=
>; >: normal; font-weight: normal; =3D3D<BR>&gt; &gt;letter=
>-spacing: normal; line=3D
> >-height: normal; orphans: 2; text-ali=
>gn: =3D3D<BR>&gt; &gt;auto; text-indent:=3D
> > 0px;=
> text-transform: none; white-space: normal; =3D3D<BR>&gt; &gt=
>;widows: 2;=3D
> > word-spacing: 0px; -webkit-border-horizontal-sp=
>acing: 0px; =3D3D<BR>&gt; &gt=3D
> >;-webkit-border-=
>vertical-spacing: 0px; =3D3D<BR>&gt; &gt;-webkit-text-decorat=
>=3D
> >ions-in-effect: none; -webkit-text-size-adjust: =3D3D<BR=
>>&gt; &gt;auto; -webk=3D
> >it-text-stroke-width: 0; "&=
>amp;gt;&lt;div class=3D3D3D"hmmessage" =3D3D<BR>&gt; &gt=
>=3D
> >;style=3D3D3D"font-size: 10pt; font-family: Tahoma; "&g=
>t;What do people =3D3D<B=3D
> >R>&gt; &gt;run?&l=
>t;br&gt;In particular: NetBSD? OpenBSD? Sparc32? Sparc64? =3D
> &=
>gt;PPC64_DARWIN? =3D3D<BR>&gt; &gt;I386_SOLARIS? AMD64_SOLARI=
>S? SPARC64_SOLARIS?=3D
> > ARM_WINCE? =3D3D<BR>&gt; &=
>;gt;AMD64_NT?&lt;br&gt;&amp;nbsp;&lt;br&gt;Just cur=3D<=
>BR>> >ious, I'll probably bring up whatever I =3D3D<BR>&gt;=
> &gt;can, it's fun, and =3D
> >yes, get back and fix AMD64_LIN=
>UX to have&lt;br&gt;garbage =3D3D<BR>&gt; &gt;=3D
=
>> >collection, NT386GNU and NT386 tests,&amp;nbsp;cross-platform =
>sets, setup =3D
> >=3D3D<BR>&gt; &gt;some Tinderboxe=
>s, etc...&lt;br&gt;&amp;nbsp;&lt;br&gt;(AMD6=3D
>=
> >4_NT: the gcc available for =3D3D<BR>&gt; &gt;this inclu=
>des a bunch of patche=3D
> >s, so I'm inclined to either wait for =
>=3D3D<BR>&gt; &gt;them to go upstream,&=3D
> >lt=
>;br&gt;or seek an alternate route such as "port" the =3D3D<BR>&am=
>p;gt; &gt;in-p=3D
> >roc backend, llvm, generate C, or maybe w=
>rite an interpreter for the =3D3D<BR=3D
> >>&gt; &gt=
>;IL;&lt;br&gt;and "porting" the backend is probably best preceded =
>=3D
> >by a) x86 =3D3D<BR>&gt; &gt;LONGINT support b=
>) other x86 targets "for practis=3D
> >e", at least =3D3D<BR>=
>;&gt; &gt;one,&lt;br&gt;though regarding .obj file forma=3D=
>
> >ts, that would be =3D3D<BR>&gt; &gt;tangential.)=
>&lt;br&gt;&amp;nbsp;&lt;br&gt=3D
> >;&amp;=
>nbsp;- =3D3D<BR>&gt; &gt;Jay&lt;br&gt;&lt;br&=
>gt;&lt;br&gt;&lt;br&gt;&lt=3D
> >;br&gt;&a=
>mp;lt;/div&gt;&lt;/span&gt;&lt;/blockquote&gt;&lt;/=
>div&gt;&lt;br&gt;&l=3D
> >t;/body&gt;&lt;/=
>html&gt;=3D3D<BR>&gt; &gt;<BR>&gt; &gt;--Ap=
>ple-Mail-4-6310280=3D
> >10--<BR><BR></body>
=
>> ></html>=3D
> >
> >--_14c076c4-fb7c-48b0-b7=
>05-2e38d4b4a333_--


>=
>
>--_a9d87328-63f1-414c-abcb-03c34a9cee30_--


From jayk123 at hotmail.com  Sun May 18 20:54:41 2008
From: jayk123 at hotmail.com (Jay)
Date: Sun, 18 May 2008 18:54:41 +0000
Subject: [M3devel] modula-3/pthreads
In-Reply-To: <20080518162217.GA27882@schlund.de>
References: 
	<20080518162217.GA27882@schlund.de>
Message-ID: 

Given that pthreads has all of mutex, rwlock, and most importantly condition variables, couldn't ThreadPThread.m3 be very much thinner?
Like, not do any of its own scheduling?
Also, shouldn;t the attr for stack size be destroyed? Else leak on some platforms? Is it even needed at all?
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From ndantam at purdue.edu  Sun May 18 22:08:20 2008
From: ndantam at purdue.edu (Neil T. Dantam)
Date: Sun, 18 May 2008 16:08:20 -0400
Subject: [M3devel] modula-3/pthreads
In-Reply-To: 
References: 	<20080518162217.GA27882@schlund.de>
	
Message-ID: <48308CB4.1050902@purdue.edu>

Jay wrote:
> Given that pthreads has all of mutex, rwlock, and most importantly
> condition variables, couldn't ThreadPThread.m3 be very much thinner?

Much of that is Object wrappers around the pthread primitives.
This is necessary so that we can garbage collect these types.

Also, RWLocks aren't really standard pthreads, but they seem to be
implemented on the platforms we currently care about.

> Like, not do any of its own scheduling?

The condition variable implementation does seem to do more than
necessary.  Perhaps this is so that it will do the right thing on
pthreads implementations that don't?

We also need to wrap pthread_create to maintain some thread local state
used for GC and probably other things as well.  It may be possible to
achieve this another way (ie using gcc's thread-local builtins), but
that would be a nontrivial change.

> Also, shouldn;t the attr for stack size be destroyed? Else leak on
> some platforms?

Probably.

> Is it even needed at all?

Not on linux, at least.

--
Neil


From dabenavidesd at yahoo.es  Mon May 19 00:39:58 2008
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sun, 18 May 2008 22:39:58 +0000 (GMT)
Subject: [M3devel] garbage collection problem on LINUXLIBC6?
Message-ID: <509246.28438.qm@web27102.mail.ukl.yahoo.com>

An HTML attachment was scrubbed...
URL: 

From hosking at cs.purdue.edu  Mon May 19 13:16:23 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 19 May 2008 07:16:23 -0400
Subject: [M3devel] modula-3/pthreads
In-Reply-To: 
References: 
	<20080518162217.GA27882@schlund.de>
	
Message-ID: 

Jay,

Indeed, I originally tried something slightly thinner (see the logs  
for the gory evolution...) but it only happened to work with Linux  
threads.  What we have now is about as thin as it can be, given the  
constraints imposed by the need to schedule thread alerts, etc.  For  
example, on some systems one cannot reliably wake up a specific thread  
from among many that are waiting on a condition.  Hence the need for  
every M3 thread too have its own private condition variable on which  
it will park itself pending alerts and conditions.


-- Tony

On May 18, 2008, at 2:54 PM, Jay wrote:

> Given that pthreads has all of mutex, rwlock, and most importantly  
> condition variables, couldn't ThreadPThread.m3 be very much thinner?
> Like, not do any of its own scheduling?
>
> Also, shouldn;t the attr for stack size be destroyed? Else leak on  
> some platforms? Is it even needed at all?
>
>  - Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Mon May 19 14:04:10 2008
From: jayk123 at hotmail.com (Jay)
Date: Mon, 19 May 2008 12:04:10 +0000
Subject: [M3devel] modula-3/pthreads
In-Reply-To: 
References: 
	<20080518162217.GA27882@schlund.de>
	
	
Message-ID: 

Tony, does Posix say that? Or testing? Esp. if this behavior is "substandard", should we have GoodPThread.m3 and BadPThread.m3?
And the "attr" is leaked, and perhaps unnecessary?
I'll be running a loop "soon" to see if the attr is leaked, but can't yet.
 
 - Jay


CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] modula-3/pthreadsDate: Mon, 19 May 2008 07:16:23 -0400


Jay,

Indeed, I originally tried something slightly thinner (see the logs for the gory evolution...) but it only happened to work with Linux threads.  What we have now is about as thin as it can be, given the constraints imposed by the need to schedule thread alerts, etc.  For example, on some systems one cannot reliably wake up a specific thread from among many that are waiting on a condition.  Hence the need for every M3 thread too have its own private condition variable on which it will park itself pending alerts and conditions.


-- Tony

On May 18, 2008, at 2:54 PM, Jay wrote:

Given that pthreads has all of mutex, rwlock, and most importantly condition variables, couldn't ThreadPThread.m3 be very much thinner?Like, not do any of its own scheduling?Also, shouldn;t the attr for stack size be destroyed? Else leak on some platforms? Is it even needed at all? - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From hosking at cs.purdue.edu  Mon May 19 14:31:56 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 19 May 2008 08:31:56 -0400
Subject: [M3devel] modula-3/pthreads
In-Reply-To: 
References: 
	<20080518162217.GA27882@schlund.de>
	
	
	
Message-ID: <54B5F97D-35EC-4902-804D-158F3FDE1650@cs.purdue.edu>

POSIX is *very* liberal in what behaviors it allows.  I don't think it  
makes any sense to further divide thread subsystems into good/bad  
based on behaviors that are undefined by the SPEC.

On May 19, 2008, at 8:04 AM, Jay wrote:

> Tony, does Posix say that? Or testing? Esp. if this behavior is  
> "substandard", should we have GoodPThread.m3 and BadPThread.m3?
> And the "attr" is leaked, and perhaps unnecessary?
> I'll be running a loop "soon" to see if the attr is leaked, but  
> can't yet.
>
>  - Jay
>
> CC: m3devel at elegosoft.com
> From: hosking at cs.purdue.edu
> To: jayk123 at hotmail.com
> Subject: Re: [M3devel] modula-3/pthreads
> Date: Mon, 19 May 2008 07:16:23 -0400
>
> Jay,
>
> Indeed, I originally tried something slightly thinner (see the logs  
> for the gory evolution...) but it only happened to work with Linux  
> threads.  What we have now is about as thin as it can be, given the  
> constraints imposed by the need to schedule thread alerts, etc.  For  
> example, on some systems one cannot reliably wake up a specific  
> thread from among many that are waiting on a condition.  Hence the  
> need for every M3 thread too have its own private condition variable  
> on which it will park itself pending alerts and conditions.
>
>
> -- Tony
>
> On May 18, 2008, at 2:54 PM, Jay wrote:
>
> Given that pthreads has all of mutex, rwlock, and most importantly  
> condition variables, couldn't ThreadPThread.m3 be very much thinner?
> Like, not do any of its own scheduling?
>
> Also, shouldn;t the attr for stack size be destroyed? Else leak on  
> some platforms? Is it even needed at all?
>
>  - Jay
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Mon May 19 14:47:46 2008
From: jayk123 at hotmail.com (Jay)
Date: Mon, 19 May 2008 12:47:46 +0000
Subject: [M3devel] gcc/m3cc/cm3c for OpenBSD?
Message-ID: 

What is the right way to handle these: http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/gcc/4.3/patches/
I imagine: 1) import them m3-sys/m3cc/src/patches/openbsd 2) perhaps use a vendor branch for the import   however they haven't changed in 14 months   and HOPEFULLY they get ported upstream 3) apply patches at build time
Seems kind of bad, but I figure also too much to manage to checkin the patch results?I realize it stinks largely due to the risk of accidentally doing what is avoided.Maybe there is like "VPATH" and the to-be-patched files can be copied in the outputdirectory and patched there?
 They aren't all needed, by far, but definitely some of them are needed.
 
 not needed, roughly:    *objc*, *ada*, *lib*
 needed, roughly:   *config* 
 unclear:  all the NULL to (void*) 0 diffs, which are a lot of it
 I kinda'thunk:  #ifdef __cplusplus  #define NULL 0 /* would perhaps need patch, depending on what calling conventions
  do with parameters and return values smaller than a word */   #else  #define NULL ((void*) 0) /* no need for patch */   #endif
in particular because in C++ a cast from void* to another* is needed, but not in C.
In fact I see this on OpenBSD:
 #ifndef NULL #ifdef  __GNUG__ #define NULL    __null #else #define NULL    0L #endif
Similar question for the AMD64_NT gcc patches, though these are newer, apparentlystill need testing, and since they are new, more hope they will go upstream.I don't know why the OpenBSD patches linger, I didn't ask.
I'll proceed as my suggest takes but presumably won't be read to commit  till after broader judgement/consensus rendered.
  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Mon May 19 17:08:05 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Mon, 19 May 2008 11:08:05 -0400
Subject: [M3devel] garbage collection problem on LINUXLIBC6?
In-Reply-To: <509246.28438.qm@web27102.mail.ukl.yahoo.com>
References: <509246.28438.qm@web27102.mail.ukl.yahoo.com>
Message-ID: <48315F96.1E75.00D7.1@scires.com>

Daniel, I have this same problem on GUI applications created on cm3
v4.1.  If I don't put "@M3novm" on the command line, the programs crash
during startup.  It has something to do with the garbage collector.  In
my testing of cm3 d5.7.0 on Windows XP, I have not run into the problem
yet, so I think Tony has fixed it with his new garbage collector, at
least on Windows.
Regards,
Randy

>>> "Daniel Alejandro Benavides D."  5/18/2008
6:39 PM >>>

Dear developers:
I'm running a new installed cm3 on an ubuntu 8.04 32 bits, and I can't
run anything with gui if I don't use @M3nogc
The rest of the applications, the compiler, and m3browser seem to work
without problems *?
I'm debugging mentor but I just got this until now:
Breakpoint 5, Init () at ../src/color/ColorName.m3:207
207           IF table.put (NormalizeName (Basic [i].name), i) THEN
(m3gdb) where
#0  Init () at ../src/color/ColorName.m3:207
#1  0xb7c7b7ff in ColorName (mode=1) at ../src/color/ColorName.m3:214
#2  0xb70e2389 in RunMainBody (m=16_b7ca2fa0) at
../src/runtime/common/RTLinker.m3:399
#3  0xb70e2055 in RunMainBody (m=16_b7d38100) at
../src/runtime/common/RTLinker.m3:379
#4  0xb70e2055 in RunMainBody (m=16_b7d2fe20) at
../src/runtime/common/RTLinker.m3:379
#5  0xb70e2055 in RunMainBody (m=16_b7d34480) at
../src/runtime/common/RTLinker.m3:379
#6  0xb70e2055 in RunMainBody (m=16_b7d30d60) at
../src/runtime/common/RTLinker.m3:379
#7  0xb70e2055 in RunMainBody (m=16_b7d4d620) at
../src/runtime/common/RTLinker.m3:379
#8  0xb70e2055 in RunMainBody (m=16_b7e31d80) at
../src/runtime/common/RTLinker.m3:379
#9  0xb70e2055 in RunMainBody (m=16_b7e33220) at
../src/runtime/common/RTLinker.m3:379
#10 0xb70e2055 in RunMainBody (m=16_b7e36d40) at
../src/runtime/common/RTLinker.m3:379
#11 0xb70e2055 in RunMainBody (m=16_b7e364e0) at
../src/runtime/common/RTLinker.m3:379
#12 0xb70e2055 in RunMainBody (m=16_b7e36ba0) at
../src/runtime/common/RTLinker.m3:379
#13 0xb70e2055 in RunMainBody (m=16_b7e32cc0) at
../src/runtime/common/RTLinker.m3:379
#14 0xb70e2055 in RunMainBody (m=16_b7e32900) at
../src/runtime/common/RTLinker.m3:379
#15 0xb70e2055 in RunMainBody (m=16_08255600) at
../src/runtime/common/RTLinker.m3:379
#16 0xb70e2055 in RunMainBody (m=16_08256040) at
../src/runtime/common/RTLinker.m3:379
#17 0xb70e2055 in RunMainBody (m=16_08312aa0) at
../src/runtime/common/RTLinker.m3:379
#18 0xb70e0dff in AddUnitI (m=16_08312aa0) at
../src/runtime/common/RTLinker.m3:113
#19 0xb70e0e8d in AddUnit (b={"Main_M3", Declared at:
../src/Main.m3:164}) at ../src/runtime/common/RTLinker.m3:122
#20 0x0806df1e in main (argc=3, argv=0xbfa03774, envp=0xbfa03784) at
_m3main.mc:4
#21 0xb6d44450 in __libc_start_main () from
/lib/tls/i686/cmov/libc.so.6
#22 0x0806de71 in _start ()
(m3gdb) cont
Continuando.

Breakpoint 5, Init () at ../src/color/ColorName.m3:207
207           IF table.put (NormalizeName (Basic [i].name), i) THEN
(m3gdb) cont
and the process hangs there when debugging mentor.

I have checked  Juno under m3gdb after have killed it and got:

(m3gdb) where
#0  0xb7fb0410 in __kernel_vsyscall ()
#1  0xb7018ae7 in pthread_kill () from
/lib/tls/i686/cmov/libpthread.so.0
#2  0xb728c397 in SignalThread (act=16_0813c120, state=Stopping) at
../src/thread/PTHREAD/ThreadPThread.m3:1058
#3  0xb728c55e in StopWorld () at
../src/thread/PTHREAD/ThreadPThread.m3:1116
#4  0xb728b9e7 in SuspendOthers () at
../src/thread/PTHREAD/ThreadPThread.m3:905
#5  0xb7265244 in CollectSomeInStateZero () at
../src/runtime/common/RTCollector.m3:755
#6  0xb7265203 in CollectSome () at
../src/runtime/common/RTCollector.m3:729
#7  0xb7264c24 in CollectEnough () at
../src/runtime/common/RTCollector.m3:656
#8  0xb72686c1 in AllocTraced (def=16_b7be1400, dataSize=12,
dataAlignment=4, initProc=NIL)
    at ../src/runtime/common/RTCollector.m3:1462
#9  0xb725ad8f in GetTracedRef (def=16_b7be1400) at
../src/runtime/common/RTAllocator.m3:191
#10 0xb725a987 in AllocateTracedRef (defn=16_b7be1400) at
../src/runtime/common/RTAllocator.m3:126
#11 0xb7b5d8fb in Put (tbl=16_b6e50438, key=8047, val=244) at
../LINUXLIBC6/IntIntTbl.m3 => ../src/table/Table.mg:127
#12 0xb7dd4e2c in Set (a='>', b='o', c=244, bothCases=FALSE,
reversed=TRUE) at ../src/etext/KeyFilter.m3:288
#13 0xb7dd521c in Set (a='o', b='>', c=244, bothCases=FALSE,
reversed=FALSE) at ../src/etext/KeyFilter.m3:304
#14 0xb7dd5882 in KeyFilter (mode=1) at ../src/etext/KeyFilter.m3:437
#15 0xb7273389 in RunMainBody (m=16_b7e51da0) at
../src/runtime/common/RTLinker.m3:399
#16 0xb7273055 in RunMainBody (m=16_b7e547e0) at
../src/runtime/common/RTLinker.m3:379
#17 0xb7273055 in RunMainBody (m=16_b7e56c00) at
../src/runtime/common/RTLinker.m3:379
#18 0xb7273055 in RunMainBody (m=16_b7e54240) at
../src/runtime/common/RTLinker.m3:379
#19 0xb7273055 in RunMainBody (m=16_b7e537e0) at
../src/runtime/common/RTLinker.m3:379
#20 0xb7273055 in RunMainBody (m=16_080b85a0) at
../src/runtime/common/RTLinker.m3:379
#21 0xb7271dff in AddUnitI (m=16_080b85a0) at
../src/runtime/common/RTLinker.m3:113
#22 0xb7271e8d in AddUnit (b={"Juno_M3", Declared at:
../src/Juno.m3:1974}) at ../src/runtime/common/RTLinker.m3:122
#23 0x0805120e in main (argc=1, argv=0xbf96ff14, envp=0xbf96ff1c) at
_m3main.mc:4
#24 0xb6ed5450 in __libc_start_main () from
/lib/tls/i686/cmov/libc.so.6
#25 0x08051161 in _start ()


When killing mentor under m3gdb it shows like the same back trace:
(m3gdb) where
#0  0xb70fb39a in SignalThread (act=16_0834ff08, state=Stopping) at
../src/thread/PTHREAD/ThreadPThread.m3:1058
#1  0xb70fb6dc in StopWorld () at
../src/thread/PTHREAD/ThreadPThread.m3:1142
#2  0xb70fa9e7 in SuspendOthers () at
../src/thread/PTHREAD/ThreadPThread.m3:905
#3  0xb70d4244 in CollectSomeInStateZero () at
../src/runtime/common/RTCollector.m3:755
#4  0xb70d4203 in CollectSome () at
../src/runtime/common/RTCollector.m3:729
#5  0xb70d3c24 in CollectEnough () at
../src/runtime/common/RTCollector.m3:656
#6  0xb70d76c1 in AllocTraced (def=16_b712d934, dataSize=24,
dataAlignment=4, initProc=Static link does not lead to a valid frame.
)
    at ../src/runtime/common/RTCollector.m3:1462
#7  0xb70c9f25 in GetTracedObj (def=16_b712d934) at
../src/runtime/common/RTAllocator.m3:206
#8  0xb70c99b0 in AllocateTracedObj (defn=16_b712d934) at
../src/runtime/common/RTAllocator.m3:131
#9  0xb710d586 in New (a={'a','z','u','r','e','4'}) at
../src/text/Text8Short.m3:16
#10 0xb710ce87 in New (a={'a','z','u','r','e','4'}) at
../src/text/Text8.m3:18
#11 0xb710ba9d in FromChars (a={'a','z','u','r','e','4'}) at
../src/text/Text.m3:206
#12 0xb7c7a62f in NormalizeName (a=16_b7ca378c) at
../src/color/ColorName.m3:83
#13 0xb7c7b789 in Init () at ../src/color/ColorName.m3:207
#14 0xb7c7b7ff in ColorName (mode=1) at ../src/color/ColorName.m3:214
#15 0xb70e2389 in RunMainBody (m=16_b7ca2fa0) at
../src/runtime/common/RTLinker.m3:399
#16 0xb70e2055 in RunMainBody (m=16_b7d38100) at
../src/runtime/common/RTLinker.m3:379
#17 0xb70e2055 in RunMainBody (m=16_b7d2fe20) at
../src/runtime/common/RTLinker.m3:379
#18 0xb70e2055 in RunMainBody (m=16_b7d34480) at
../src/runtime/common/RTLinker.m3:379
#19 0xb70e2055 in RunMainBody (m=16_b7d30d60) at
../src/runtime/common/RTLinker.m3:379
#20 0xb70e2055 in RunMainBody (m=16_b7d4d620) at
../src/runtime/common/RTLinker.m3:379
#21 0xb70e2055 in RunMainBody (m=16_b7e31d80) at
../src/runtime/common/RTLinker.m3:379
#22 0xb70e2055 in RunMainBody (m=16_b7e33220) at
../src/runtime/common/RTLinker.m3:379
#23 0xb70e2055 in RunMainBody (m=16_b7e36d40) at
../src/runtime/common/RTLinker.m3:379
#24 0xb70e2055 in RunMainBody (m=16_b7e364e0) at
../src/runtime/common/RTLinker.m3:379
#25 0xb70e2055 in RunMainBody (m=16_b7e36ba0) at
../src/runtime/common/RTLinker.m3:379
#26 0xb70e2055 in RunMainBody (m=16_b7e32cc0) at
../src/runtime/common/RTLinker.m3:379
#27 0xb70e2055 in RunMainBody (m=16_b7e32900) at
../src/runtime/common/RTLinker.m3:379
#28 0xb70e2055 in RunMainBody (m=16_08255600) at
../src/runtime/common/RTLinker.m3:379
#29 0xb70e2055 in RunMainBody (m=16_08256040) at
../src/runtime/common/RTLinker.m3:379
#30 0xb70e2055 in RunMainBody (m=16_08312aa0) at
../src/runtime/common/RTLinker.m3:379
#31 0xb70e0dff in AddUnitI (m=16_08312aa0) at
../src/runtime/common/RTLinker.m3:113
#32 0xb70e0e8d in AddUnit (b={"Main_M3", Declared at:
../src/Main.m3:164}) at ../src/runtime/common/RTLinker.m3:122
#33 0x0806df1e in main (argc=3, argv=0xbfa03774, envp=0xbfa03784) at
_m3main.mc:4
#34 0xb6d44450 in __libc_start_main () from
/lib/tls/i686/cmov/libc.so.6
#35 0x0806de71 in _start ()

Thanks in advance


Enviado desde Correo Yahoo! (
http://us.rd.yahoo.com/mailuk/taglines/isp/control/*http://us.rd.yahoo.com/evt=52431/*http://es.docs.yahoo.com/mail/overview/index.html
)
La bandeja de entrada m?s inteligente.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From dabenavidesd at yahoo.es  Mon May 19 18:52:09 2008
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 19 May 2008 16:52:09 +0000 (GMT)
Subject: [M3devel] garbage collection problem on LINUXLIBC6?
In-Reply-To: <48315F96.1E75.00D7.1@scires.com>
Message-ID: <735107.82429.qm@web27103.mail.ukl.yahoo.com>

An HTML attachment was scrubbed...
URL: 

From dabenavidesd at yahoo.es  Mon May 19 19:02:00 2008
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 19 May 2008 17:02:00 +0000 (GMT)
Subject: [M3devel] garbage collection problem on LINUXLIBC6?
In-Reply-To: <735107.82429.qm@web27103.mail.ukl.yahoo.com>
Message-ID: <163131.36279.qm@web27101.mail.ukl.yahoo.com>

An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sat May 24 07:11:50 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 24 May 2008 05:11:50 +0000
Subject: [M3devel] new platform names (for actual new platforms)
Message-ID: 

Do people object to new platform names like:
  PPC32_OPENBSD    SPARC32_OPENBSD    SPARC32_LINUX  
 
?
For that matter, anyone consider spelling out POWERPC32_OPENBSD?
?
Seriously I am far along on PPC32_OPENBSD and SPARC64_OPENBSDand once those work, I figure I'll try to flesh out Linux, NetBSD,FreeBSD on ppc32/sparc/sparc64. So this isn't just hypothetical
debate about platform names.
 
At some point it almost seems like there's a 2 dimensional matrixand the support should be processor and OS, somewhat independent..well, it is kind of like in parts already.
 
Should I really stick more like:  PPC_OPENBSD   SPARC_LINUX   SPARC64_LINUX    etc.?
64bits isn't so unusual now, that 32bits isn't so automatically implied???
That's kind of my point. Not putting in "32" or "64" used to imply "32" but
now seems almost ambiguous. ?
(Linux doesn't really still support 32 bit SPARC kernels, butdefinitely 32 bit userland; in fact it looks like SPARC Linuxis mostly 32 bit userland, and SPARC64 OpenBSD is purely 64 bit,not even gcc -m32)
I'd still kind of like to rename stuff like to  I386_NT, I386_LINUX, I386_CYGWIN, I386_MINGWIN, SPARC_SOLARIS_SUN,  SPARC_SOLARIS_GNU, alas...  
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sat May 24 11:49:57 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 24 May 2008 09:49:57 +0000
Subject: [M3devel] stat file types?
In-Reply-To: 
References: 
Message-ID: 

It SEEMS:
 
S_IFPIPE appears to be made up by Modula-3.S_IFPORT appears to be made up by Modula-3 as a synonym for S_IFIFO.
 
PROPOSED:
This code:
D:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX\FilePosix.i3(36):   error if "fd" is not "S_IFPIPE", "S_IFPORT", or "S_IFSOCK". *)D:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX\FilePosix.m3(47):    | Ustat.S_IFPIPE, Ustat.S_IFPORT, Ustat.S_IFSOCK =>
 
should check for S_IFSOCK and S_IFIFO.
all references to and definitions of S_IFPORT and S_IFPIPE should go away.
 
Or did some actual systems actually define either of these?
 
Most of the *.i3 files set S_IFPORT = S_IFIFO and S_IFPIPE = 0.
Many of them say that there is no S_IFPIPE in their .h file.
Irix has them reversed but the same result: S_IFPORT = 0 and S_IFPIPE = S_IFIFO.
 
Any objections?
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sat May 24 11:50:50 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 24 May 2008 09:50:50 +0000
Subject: [M3devel] stat file types?
In-Reply-To: 
References: 
Message-ID: 

It SEEMS:
 
S_IFPIPE appears to be made up by Modula-3.S_IFPORT appears to be made up by Modula-3 as a synonym for S_IFIFO.
 
PROPOSED:
This code:
D:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX\FilePosix.i3(36):   error if "fd" is not "S_IFPIPE", "S_IFPORT", or "S_IFSOCK". *)D:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX\FilePosix.m3(47):    | Ustat.S_IFPIPE, Ustat.S_IFPORT, Ustat.S_IFSOCK =>
 
should check for S_IFSOCK and S_IFIFO.
all references to and definitions of S_IFPORT and S_IFPIPE should go away.
 
Or did some actual systems actually define either of these?
 
Most of the *.i3 files set S_IFPORT = S_IFIFO and S_IFPIPE = 0.
Many of them say that there is no S_IFPIPE in their .h file.
Irix has them reversed but the same result: S_IFPORT = 0 and S_IFPIPE = S_IFIFO.
 
Any objections?
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From dabenavidesd at yahoo.es  Sat May 24 19:29:27 2008
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sat, 24 May 2008 17:29:27 +0000 (GMT)
Subject: [M3devel] garbage collection problem on LINUXLIBC6?
In-Reply-To: <163131.36279.qm@web27101.mail.ukl.yahoo.com>
Message-ID: <406663.93255.qm@web27103.mail.ukl.yahoo.com>

Hi:
I recently have compiled the cm3 system with good results on a 2-core machine on LINUXLIBC6, kubuntu of 32 bits. It runs gui applications of cm3 with no problems at all.
I think maybe the issue is related with something about the operating system, or at least the machine, I didn't check this until now.

Thanks

--- 19/5/08, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> wrote:
De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] garbage collection problem on LINUXLIBC6?
Para: m3devel at elegosoft.com, "Randy Coleburn" <rcoleburn at scires.com>
Fecha: lunes, 19 mayo, 2008 12:02

Hi again:
and the process is using the cpu very much (using top command)

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 9758 daniel    20   0 33644 3836 2684 R 60.0  0.7   1:05.17 draw

Thanks in advance.


--- 19/5/08, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> wrote:
De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] garbage collection problem on LINUXLIBC6?
Para: m3devel at elegosoft.com, "Randy Coleburn" <rcoleburn at scires.com>
Fecha: lunes, 19 mayo, 2008 11:52

Hi Randy:
In my case, the program just doesn't start, maybe after some minutes yes, but obviously this is abnormal.
When I start mentor @M3tracelinker, I got after a lot of output the following lines and it just doesn't start after it:
  ../src/color/Color.i3(3)
  ../src/runtime/common/RTHooks.i3(3)
RunMainBody: exec: ../src/color/ColorNameTable.i3(3)
RunMainBody: exec: ../src/color/ColorNameF.i3(3)
RunMainBody: exec: ../src/color/ColorNa

But if I put @M3nogc @M3tracelinker the program starts and the output is:
RunMainBody: ../LINUXLIBC6/MentorBundle.m3(2)
  ../LINUXLIBC6/MentorBundle.i3(5)
  ../src/rw/TextWr.i3(3)
  ../src/rw/Wr.i3(3)
 
 ../src/thread/Common/Thread.i3(3)
  ../src/text/Text.i3(3)
  ../src/bundleintf/BundleRep.i3(3)
  ../src/bundleintf/Bundle.i3(3)
 
 ../src/runtime/common/RTHooks.i3(3)
RunMainBody: exec: ../LINUXLIBC6/MentorBundle.m3(3)
RunMainBody: exec: ../LINUXLIBC6/MentorBundle.i3(3)
RunMainBody: exec: ../src/Main.m3(3)

However when examining a simple gui program, the stdout shows the same  out for @M3tracelinker with or without garbage collection

  ../src/split/TextVBT.i3(5)
  ../src/runtime/common/RTHooks.i3(3)
RunMainBody: exec: ../src/split/TextVBTClass.i3(3)
RunMainBody: exec: ../src/split/TextVBT.m3(3)
RunMainBody: exec: ../src/split/TextVBT.i3(3)
RunMainBody: exec: ../src/Draw.m3(3)

If I run the program under m3gdb without parametres, breaking on RTLinker.RunMainBody, I got:
Breakpoint 3, RunMainBody (m=16_b7e108c0)
    at ../src/runtime/common/RTLinker.m3:349
349       VAR desc, desc2: InitPtr;  imp: RT0.ImportPtr;  m2:
 RT0.ModulePtr;
(m3gdb)
Continuando.

Breakpoint 3, RunMainBody (m=16_b7e10ba0)
    at ../src/runtime/common/RTLinker.m3:349
349       VAR desc, desc2: InitPtr;  imp: RT0.ImportPtr;  m2: RT0.ModulePtr;
(m3gdb)
Continuando.

Breakpoint 3, RunMainBody (m=16_b7e0b660)
    at ../src/runtime/common/RTLinker.m3:349
349       VAR desc, desc2: InitPtr;  imp: RT0.ImportPtr;  m2: RT0.ModulePtr;
(m3gdb)
Continuando.


[Nuevo Thread -1234015344 (LWP 9706)]
[Thread -1234015344 (LWP 9706) exited]

And the program hangs there.
And again the same situation on the stack trace when killing the process inside m3gdb (also got a segment violation on m3gdb):

(m3gdb) where
#0  0xb7fbf410 in __kernel_vsyscall ()
#1  0xb7108ae7 in pthread_kill () from
 /lib/tls/i686/cmov/libpthread.so.0
#2  0xb737c397 in SignalThread (act=16_08055d88, state=Stopping)
    at ../src/thread/PTHREAD/ThreadPThread.m3:1058
#3  0xb737c6dc in StopWorld () at ../src/thread/PTHREAD/ThreadPThread.m3:1142
#4  0xb737b9e7 in SuspendOthers ()
    at ../src/thread/PTHREAD/ThreadPThread.m3:905
#5  0xb7355244 in CollectSomeInStateZero ()
    at ../src/runtime/common/RTCollector.m3:755
#6  0xb7355203 in CollectSome () at ../src/runtime/common/RTCollector.m3:729
#7  0xb7354c24 in CollectEnough () at ../src/runtime/common/RTCollector.m3:656
#8  0xb73586c1 in AllocTraced (def=16_b7dfbfb4, dataSize=456, dataAlignment=4,
    initProc=Static link does not lead to a valid frame.
) at ../src/runtime/common/RTCollector.m3:1462
#9  0xb734af25 in GetTracedObj (def=16_b7dfbfb4)
    at
 ../src/runtime/common/RTAllocator.m3:206
#10 0xb734a9b0 in AllocateTracedObj (defn=16_b7dfbfb4)
    at ../src/runtime/common/RTAllocator.m3:131
#11 0xb7d63df5 in Connect (inst=NIL, trsl=NIL) at ../src/xvbt/XClientF.m3:495
#12 0xb7d66717 in DoConnect (self=16_b6f41d5c, inst=NIL, localOnly=FALSE,
    t=NIL) at ../src/xvbt/XClientF.m3:637
#13 0xb7d46c23 in DoConnect (self=16_b6f41d5c, inst=NIL, localOnly=FALSE,
    t=NIL) at ../src/xvbt/XClient.m3:1495
#14 0xb7d9962c in Connect (inst=NIL, localOnly=FALSE)
---Type <return> to continue, or q <return> to quit---
    at ../src/vbt/TrestleClass.m3:30
#15 0xb7df2117 in Default () at ../src/trestle/Trestle.m3:838
#16 0xb7ded789 in PreAttach (v=16_b6f41cf8, trsl=NIL)
    at ../src/trestle/Trestle.m3:264
#17 0xb7deb95b in Install (v=16_b6f41cf8, applName=NIL, inst=NIL,
Fallo de
 segmentaci?n


Maybe could be some gcc backend issue?
I would like to know if others have the same problem.
Thanks.
  
--- 19/5/08, Randy Coleburn <rcoleburn at scires.com> wrote:
De: Randy Coleburn <rcoleburn at scires.com>
Asunto: Re: [M3devel] garbage collection problem on LINUXLIBC6?
Para: m3devel at elegosoft.com
Fecha: lunes, 19 mayo, 2008 10:08


 
Daniel, I have this same problem on GUI applications created on cm3 v4.1.  If I don't put "@M3novm" on the command line, the programs crash during startup.  It has something to do with the garbage collector.  In my testing of cm3 d5.7.0 on Windows XP, I have not run into the problem yet, so I think Tony has fixed it with his new garbage collector, at least on Windows.
Regards,
Randy

>>> "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> 5/18/2008 6:39 PM >>>




Dear developers:
I'm running a new installed cm3 on an ubuntu 8.04 32 bits, and I can't run anything with gui if I don't use @M3nogc
The rest of the applications, the compiler, and m3browser seem to work without problems ??
I'm debugging mentor but I just got this until now:
Breakpoint 5, Init () at ../src/color/ColorName.m3:207
207           IF table.put (NormalizeName (Basic [i].name), i) THEN
(m3gdb) where
#0  Init () at ../src/color/ColorName.m3:207
#1  0xb7c7b7ff in ColorName (mode=1) at ../src/color/ColorName.m3:214
#2  0xb70e2389 in RunMainBody (m=16_b7ca2fa0) at ../src/runtime/common/RTLinker.m3:399
#3  0xb70e2055 in RunMainBody (m=16_b7d38100) at ../src/runtime/common/RTLinker.m3:379
#4  0xb70e2055 in RunMainBody (m=16_b7d2fe20) at ../src/runtime/common/RTLinker.m3:379
#5  0xb70e2055 in RunMainBody (m=16_b7d34480) at
 ../src/runtime/common/RTLinker.m3:379
#6  0xb70e2055 in RunMainBody (m=16_b7d30d60) at ../src/runtime/common/RTLinker.m3:379
#7  0xb70e2055 in RunMainBody (m=16_b7d4d620) at ../src/runtime/common/RTLinker.m3:379
#8  0xb70e2055 in RunMainBody (m=16_b7e31d80) at ../src/runtime/common/RTLinker.m3:379
#9  0xb70e2055 in RunMainBody (m=16_b7e33220) at ../src/runtime/common/RTLinker.m3:379
#10 0xb70e2055 in RunMainBody (m=16_b7e36d40) at ../src/runtime/common/RTLinker.m3:379
#11 0xb70e2055 in RunMainBody (m=16_b7e364e0) at ../src/runtime/common/RTLinker.m3:379
#12 0xb70e2055 in RunMainBody (m=16_b7e36ba0) at ../src/runtime/common/RTLinker.m3:379
#13 0xb70e2055 in RunMainBody (m=16_b7e32cc0) at ../src/runtime/common/RTLinker.m3:379
#14 0xb70e2055 in RunMainBody (m=16_b7e32900) at ../src/runtime/common/RTLinker.m3:379
#15 0xb70e2055 in RunMainBody (m=16_08255600) at ../src/runtime/common/RTLinker.m3:379
#16
 0xb70e2055 in RunMainBody (m=16_08256040) at ../src/runtime/common/RTLinker.m3:379
#17 0xb70e2055 in RunMainBody (m=16_08312aa0) at ../src/runtime/common/RTLinker.m3:379
#18 0xb70e0dff in AddUnitI (m=16_08312aa0) at ../src/runtime/common/RTLinker.m3:113
#19 0xb70e0e8d in AddUnit (b={"Main_M3", Declared at: ../src/Main.m3:164}) at ../src/runtime/common/RTLinker.m3:122
#20 0x0806df1e in main (argc=3, argv=0xbfa03774, envp=0xbfa03784) at _m3main.mc:4
#21 0xb6d44450 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#22 0x0806de71 in _start ()
(m3gdb) cont
Continuando.

Breakpoint 5, Init () at ../src/color/ColorName.m3:207
207           IF table.put (NormalizeName (Basic [i].name), i) THEN
(m3gdb) cont
and the process hangs there when debugging mentor.

I have checked  Juno under m3gdb after have killed it and got:

(m3gdb) where
#0 
 0xb7fb0410 in __kernel_vsyscall ()
#1  0xb7018ae7 in pthread_kill () from /lib/tls/i686/cmov/libpthread.so.0
#2  0xb728c397 in SignalThread (act=16_0813c120, state=Stopping) at ../src/thread/PTHREAD/ThreadPThread.m3:1058
#3  0xb728c55e in StopWorld () at ../src/thread/PTHREAD/ThreadPThread.m3:1116
#4  0xb728b9e7 in SuspendOthers () at ../src/thread/PTHREAD/ThreadPThread.m3:905
#5  0xb7265244 in CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:755
#6  0xb7265203 in CollectSome () at ../src/runtime/common/RTCollector.m3:729
#7  0xb7264c24 in CollectEnough () at ../src/runtime/common/RTCollector.m3:656
#8  0xb72686c1 in AllocTraced (def=16_b7be1400, dataSize=12, dataAlignment=4, initProc=NIL)
    at ../src/runtime/common/RTCollector.m3:1462
#9  0xb725ad8f in GetTracedRef (def=16_b7be1400) at ../src/runtime/common/RTAllocator.m3:191
#10 0xb725a987
 in AllocateTracedRef (defn=16_b7be1400) at ../src/runtime/common/RTAllocator.m3:126
#11 0xb7b5d8fb in Put (tbl=16_b6e50438, key=8047, val=244) at ../LINUXLIBC6/IntIntTbl.m3 => ../src/table/Table.mg:127
#12 0xb7dd4e2c in Set (a='>', b='o', c=244, bothCases=FALSE, reversed=TRUE) at ../src/etext/KeyFilter.m3:288
#13 0xb7dd521c in Set (a='o', b='>', c=244, bothCases=FALSE, reversed=FALSE) at ../src/etext/KeyFilter.m3:304
#14 0xb7dd5882 in KeyFilter (mode=1) at ../src/etext/KeyFilter.m3:437
#15 0xb7273389 in RunMainBody (m=16_b7e51da0) at ../src/runtime/common/RTLinker.m3:399
#16 0xb7273055 in RunMainBody (m=16_b7e547e0) at ../src/runtime/common/RTLinker.m3:379
#17 0xb7273055 in RunMainBody (m=16_b7e56c00) at ../src/runtime/common/RTLinker.m3:379
#18 0xb7273055 in RunMainBody (m=16_b7e54240) at ../src/runtime/common/RTLinker.m3:379
#19 0xb7273055 in RunMainBody (m=16_b7e537e0) at
 ../src/runtime/common/RTLinker.m3:379
#20 0xb7273055 in RunMainBody (m=16_080b85a0) at ../src/runtime/common/RTLinker.m3:379
#21 0xb7271dff in AddUnitI (m=16_080b85a0) at ../src/runtime/common/RTLinker.m3:113
#22 0xb7271e8d in AddUnit (b={"Juno_M3", Declared at: ../src/Juno.m3:1974}) at ../src/runtime/common/RTLinker.m3:122
#23 0x0805120e in main (argc=1, argv=0xbf96ff14, envp=0xbf96ff1c) at _m3main.mc:4
#24 0xb6ed5450 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#25 0x08051161 in _start ()


When killing mentor under m3gdb it shows like the same back trace:
(m3gdb) where
#0  0xb70fb39a in SignalThread (act=16_0834ff08, state=Stopping) at ../src/thread/PTHREAD/ThreadPThread.m3:1058
#1  0xb70fb6dc in StopWorld () at ../src/thread/PTHREAD/ThreadPThread.m3:1142
#2  0xb70fa9e7 in SuspendOthers () at ../src/thread/PTHREAD/ThreadPThread.m3:905
#3  0xb70d4244 in CollectSomeInStateZero
 () at ../src/runtime/common/RTCollector.m3:755
#4  0xb70d4203 in CollectSome () at ../src/runtime/common/RTCollector.m3:729
#5  0xb70d3c24 in CollectEnough () at ../src/runtime/common/RTCollector.m3:656
#6  0xb70d76c1 in AllocTraced (def=16_b712d934, dataSize=24, dataAlignment=4, initProc=Static link does not lead to a valid frame.
)
    at ../src/runtime/common/RTCollector.m3:1462
#7  0xb70c9f25 in GetTracedObj (def=16_b712d934) at ../src/runtime/common/RTAllocator.m3:206
#8  0xb70c99b0 in AllocateTracedObj (defn=16_b712d934) at ../src/runtime/common/RTAllocator.m3:131
#9  0xb710d586 in New (a={'a','z','u','r','e','4'}) at ../src/text/Text8Short.m3:16
#10 0xb710ce87 in New (a={'a','z','u','r','e','4'}) at ../src/text/Text8.m3:18
#11 0xb710ba9d in FromChars (a={'a','z','u','r','e','4'}) at ../src/text/Text.m3:206
#12 0xb7c7a62f in NormalizeName (a=16_b7ca378c) at
 ../src/color/ColorName.m3:83
#13 0xb7c7b789 in Init () at ../src/color/ColorName.m3:207
#14 0xb7c7b7ff in ColorName (mode=1) at ../src/color/ColorName.m3:214
#15 0xb70e2389 in RunMainBody (m=16_b7ca2fa0) at ../src/runtime/common/RTLinker.m3:399
#16 0xb70e2055 in RunMainBody (m=16_b7d38100) at ../src/runtime/common/RTLinker.m3:379
#17 0xb70e2055 in RunMainBody (m=16_b7d2fe20) at ../src/runtime/common/RTLinker.m3:379
#18 0xb70e2055 in RunMainBody (m=16_b7d34480) at ../src/runtime/common/RTLinker.m3:379
#19 0xb70e2055 in RunMainBody (m=16_b7d30d60) at ../src/runtime/common/RTLinker.m3:379
#20 0xb70e2055 in RunMainBody (m=16_b7d4d620) at ../src/runtime/common/RTLinker.m3:379
#21 0xb70e2055 in RunMainBody (m=16_b7e31d80) at ../src/runtime/common/RTLinker.m3:379
#22 0xb70e2055 in RunMainBody (m=16_b7e33220) at ../src/runtime/common/RTLinker.m3:379
#23 0xb70e2055 in RunMainBody (m=16_b7e36d40) at
 ../src/runtime/common/RTLinker.m3:379
#24 0xb70e2055 in RunMainBody (m=16_b7e364e0) at ../src/runtime/common/RTLinker.m3:379
#25 0xb70e2055 in RunMainBody (m=16_b7e36ba0) at ../src/runtime/common/RTLinker.m3:379
#26 0xb70e2055 in RunMainBody (m=16_b7e32cc0) at ../src/runtime/common/RTLinker.m3:379
#27 0xb70e2055 in RunMainBody (m=16_b7e32900) at ../src/runtime/common/RTLinker.m3:379
#28 0xb70e2055 in RunMainBody (m=16_08255600) at ../src/runtime/common/RTLinker.m3:379
#29 0xb70e2055 in RunMainBody (m=16_08256040) at ../src/runtime/common/RTLinker.m3:379
#30 0xb70e2055 in RunMainBody (m=16_08312aa0) at ../src/runtime/common/RTLinker.m3:379
#31 0xb70e0dff in AddUnitI (m=16_08312aa0) at ../src/runtime/common/RTLinker.m3:113
#32 0xb70e0e8d in AddUnit (b={"Main_M3", Declared at: ../src/Main.m3:164}) at ../src/runtime/common/RTLinker.m3:122
#33 0x0806df1e in main (argc=3, argv=0xbfa03774, envp=0xbfa03784) at _m3main.mc:4
#34
 0xb6d44450 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#35 0x0806de71 in _start ()

Thanks in advance




Enviado desde Correo Yahoo!
La bandeja de entrada m?s inteligente.








      
Enviado desde Correo Yahoo!
La bandeja de entrada m?s inteligente.









      
Enviado desde Correo Yahoo!
La bandeja de entrada m?s inteligente.




      ______________________________________________ 
Enviado desde Correo Yahoo! La bandeja de entrada m?s inteligente.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Sun May 25 00:48:25 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Sat, 24 May 2008 18:48:25 -0400
Subject: [M3devel] new problems
Message-ID: <483862F4.1E75.00D7.1@scires.com>

I'm having some new problems crop up with the cm3ide program.
 
Have there been any recent changes to quake or the QMachine that have not been thoroughly checked out?  That is where I suspect the problems are coming from.
 
Regards,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sun May 25 01:33:14 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 24 May 2008 23:33:14 +0000
Subject: [M3devel] new problems
In-Reply-To: <483862F4.1E75.00D7.1@scires.com>
References: <483862F4.1E75.00D7.1@scires.com>
Message-ID: 

Randy, can you describe the problems more?
 
"Something is wrong."?
 
Can the problems be made debuggable by others?
 
When did the problems start?
 
 - Jay


Date: Sat, 24 May 2008 18:48:25 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: [M3devel] new problems

I'm having some new problems crop up with the cm3ide program.
 
Have there been any recent changes to quake or the QMachine that have not been thoroughly checked out?  That is where I suspect the problems are coming from.
 
Regards,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sun May 25 02:16:01 2008
From: jayk123 at hotmail.com (Jay)
Date: Sun, 25 May 2008 00:16:01 +0000
Subject: [M3devel] function pointers and comparison to nil? mis-typed
 function pointers?
In-Reply-To: <483862F4.1E75.00D7.1@scires.com>
References: <483862F4.1E75.00D7.1@scires.com>
Message-ID: 

I'm being lazy...
Tony can you explain this stuff?
Comparison of function pointers..What are the various representations and rules?
What does it mean to compare nested functions?
What does it mean to compare a function to NIL?
I'll poke around more.
What I am seeing is that comparison of function pointers to NIL is surprisinglyexpensive, and probably somewhat buggy. Or at least some of the runtimegenerated "metadata-ish" stuff is produced or typed incorrectly.
In particular, RTLinker.m3:
PROCEDURE AddUnit (b: RT0.Binder) =  VAR m: RT0.ModulePtr;  BEGIN    IF (b = NIL) THEN RETURN END;   line 119    m := b(0);                      line 120    IF (m = NIL) THEN RETURN END;   line 121    AddUnitI(m);                    line 122   END AddUnit;
generates a lot of code, just for the first line:
  (556) set_source_line      source line  119    (557) load      m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb    (558) load_nil    (559) if_eq    (560) load      m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb    (561) load_indirect      load address offset 0x0 src_t 0x5 dst_t 0x5    (562) load_integer      integer n_bytes 0x0 hi 0x0 low 0x1 sign -1    (563) if_eq    (564) set_label    (565) load_nil    (566) load      m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb    (567) if_ne    (568) set_label    (569) exit_proc    (570) set_label    (571) set_source_line      source line  120  
The details on the load_integer trace might not be completely correct. I will test a fix shortly.Esp. that n_bytes gets decremented to zero before the trace.
Ok, I see now why some of the bloat -- because the "then return end" is on the same line.If it were written as:  if (b = NIL THEN      return   end   
It probably wouldn't look so bad. That took me a while to realize.
The following is generated for SPARC64_OPENBSD:
 
 line 119 
 .stabn 68,0,119,.LLM61-.LLFBB4 .LLM61: ldx [%fp+2175], %g1 brz %g1, .LL26  nop ldx [%fp+2175], %g1 ldx [%g1], %g1            bus error here? yes, probably this one cmp %g1, -1 be %xcc, .LL27  nop.LL26: ldx [%fp+2175], %g1 brz %g1, .LL33  nop.LL27:
 line 120 
 .stabn 68,0,120,.LLM62-.LLFBB4.LLM62:
 ldx [%fp+2175], %g1 stx %g1, [%fp+2007] ldx [%fp+2007], %g1 brz %g1, .LL30  nop ldx [%fp+2007], %g1 ldx [%g1], %g1            or here ? cmp %g1, -1 bne %xcc, .LL30  nop ldx [%fp+2007], %g1 add %g1, 16, %g1 ldx [%g1], %g1           or here?  stx %g1, [%fp+2015] ldx [%fp+2007], %g1 add %g1, 8, %g1 ldx [%g1], %g1 stx %g1, [%fp+2007].LL30: ldx [%fp+2007], %g1 ldx [%fp+2015], %g5 mov 0, %o0 call %g1, 0  nop mov %o0, %g1 stx %g1, [%fp+2023] ldx [%fp+2023], %g1 stx %g1, [%fp+1999]   line 121 
 .stabn 68,0,121,.LLM63-.LLFBB4.LLM63: ldx [%fp+1999], %g1 brz %g1, .LL33  nop.LL32: .stabn 68,0,122,.LLM64-.LLFBB4.LLM64:
g1 points to RTSignal_I3
(gdb) x/i $pc0x3ff0a8 :        ldx  [ %g1 ], %g1
(gdb) x/i $g10x4021f4 : save  %sp, -208, %sp
I am willing to accept that a "function pointer" is a pair of pointers, or even three pointers.A pointer to code, a pointer to globals for position independent code, a frame pointer to locals.That equality comparison of function pointers requires comparing two (or three) pointers.
  (Though the global pointer shouldn't need comparing.)At least for nested functions. Less so for non-nested. ?Much less for comparison to NIL. ?
And either way, this code is reading bogus data.There isn't a pointer at the function address, there is code.
Something doesn't add up.
I'm going to try setting "aligned procedures" but that's quite bogus I think.
EqualExpr.m3 says
       Note: procedures pointers are always aligned!
but maybe not?
Yeah yeah I'm being lazy. I'll read more code..
I also wonder if a "function pointer" can be optimized for the case of not being to a nested function.It looks like calling a function pointer is very inefficient.It looks like..am I reading that correctly?.. that if the pointer points to -1, then it is nested anda pair of pointers, and not otherwise. That -1 is treated specially as the first bytes of a function?
Is that a Modula-3-ism or a SPARC-ism?It looks like a Modula-3-ism. And it seems dubious.But I'll have to read more..
 
NT386GNU does the same sort of wrong looking thing:
 
LFBB4: pushl %ebp movl %esp, %ebp subl $24, %espLBB5: .stabn 68,0,117,LM60-LFBB4LM60: movl $0, -16(%ebp) .stabn 68,0,119,LM61-LFBB4LM61: movl 8(%ebp), %eax testl %eax, %eax je L26 movl 8(%ebp), %eax movl (%eax), %eax                  BAD  cmpl $-1, %eax                       BAD  je L27L26: movl 8(%ebp), %eax testl %eax, %eax je L33L27: .stabn 68,0,120,LM62-LFBB4LM62:
 
and NT386:
 
0:000> ucm3!RTLinker__AddUnit:00607864 55              push    ebp00607865 8bec            mov     ebp,esp00607867 81ec0c000000    sub     esp,0Ch0060786d 53              push    ebx0060786e 56              push    esi0060786f 57              push    edi00607870 c745fc00000000  mov     dword ptr [ebp-4],000607877 837d0800        cmp     dword ptr [ebp+8],00:000> ucm3!RTLinker__AddUnit+0x17:0060787b 0f840f000000    je      cm3!RTLinker__AddUnit+0x2c (00607890)00607881 8b7508          mov     esi,dword ptr [ebp+8]00607884 8b5e00          mov     ebx,dword ptr [esi]                            BAD  00607887 83fbff          cmp     ebx,0FFFFFFFFh                                  BAD 0060788a 0f840f000000    je      cm3!RTLinker__AddUnit+0x3b (0060789f)00607890 837d0800        cmp     dword ptr [ebp+8],000607894 0f8505000000    jne     cm3!RTLinker__AddUnit+0x3b (0060789f)0060789a e969000000      jmp     cm3!RTLinker__AddUnit+0xa4 (00607908)
 
cm3!RTLinker__AddUnit+0x20:00607884 8b5e00          mov     ebx,dword ptr [esi]  ds:002b:0062c950=81ec8b550:000> u @esicm3!RTLinker_I3:0062c950 55              push    ebp0062c951 8bec            mov     ebp,esp0062c953 81ec00000000    sub     esp,00062c959 53              push    ebx0062c95a 56              push    esi0062c95b 57              push    edi0062c95c 837d0800        cmp     dword ptr [ebp+8],00062c960 0f8400000000    je      cm3!RTLinker_I3+0x16 (0062c966)
 
This is just wrong.
Comparing bytes of code to -1.
 
I think the likely fix is for the "I3" code to be laid out as a "constant function pointer", a pointer to a pair of pointers where one points to the code and one is to -1. Something like that. That can't be quite correct given that the existing data is callable.
  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sun May 25 02:48:32 2008
From: jayk123 at hotmail.com (Jay)
Date: Sun, 25 May 2008 00:48:32 +0000
Subject: [M3devel] function pointers and comparison to nil? mis-typed
 function pointers?
In-Reply-To: 
References: <483862F4.1E75.00D7.1@scires.com>
	
Message-ID: 

I see somewhat.
It's stuff around "closure".
The comparison of code bytes to -1 comes from If_closure for example.
 
The problem is presumably to come up with a unified representation of pointers to functions that may or may not be nested, while avoiding runtime codegen, even just a little bit, and for Modula-3 and C function pointers to use the same representation.
I don't think the present solution is really valid, and I am skeptical that there is a solution.
One of the requirements has to be dropped.
Sniffing code bytes and trying to decide if they are code or not as appears to currently happen is bogus.
 
I think the solution is to remove the requirement that a Modula-3 function pointer and a C function pointer are the same.
Except, well, that probably doesn't work -- it means you need two types of function pointers.
 
Darn this is a hard problem.
 
The runtime codegen required can be exceedingly simple, fast, and small IF it were allowed to be on the stack. But that's a killer these days.
 
I think you have to give up unification of "closures" and "function pointers".
If you take the address of a nested function and call it, you cannot access the locals of the enclosing scopes.
So in affect, you end up with "two types of function pointers".
Regular stateless ones and "closures" with some captured state.
 
Thoughts?
 
I'm kind of stumped. It's a desirable problem to solve, and there is a purported solution in place, but the solution that is there is completely bogus, despite appearing to work for a long time, and there is no solution. That is my understanding. I could be wrong on any number of points but I'm pretty sure.
 
I think you have to separate out function pointers and closures.
Sniffing what it pointed to is dubous esp. as currently implemented.
If this is really the way to go, then signature bytes need to be worked out for all architectures that are guaranteed to not look like code.
Or vice versa -- signature bytes worked out that all functions start with, which is viable for Modula-3 but not for interop with C.
Currently -1 is used, of pointer-size.
That appears to be reasonable for x86:
 
0:000> eb . ff ff ff ff0:000> u .ntdll32!DbgBreakPoint:7d61002d ff              ???7d61002e ff              ???7d61002f ff              ???7d610030 ffc3            inc     ebx
 
but the instruction encodings or disassembly on other architectures would have to be checked.
 
 - Jay


From: jayk123 at hotmail.comTo: m3devel at elegosoft.comDate: Sun, 25 May 2008 00:16:01 +0000Subject: [M3devel] function pointers and comparison to nil? mis-typed function pointers?


I'm being lazy...Tony can you explain this stuff?Comparison of function pointers..What are the various representations and rules?What does it mean to compare nested functions?What does it mean to compare a function to NIL?I'll poke around more.What I am seeing is that comparison of function pointers to NIL is surprisinglyexpensive, and probably somewhat buggy. Or at least some of the runtimegenerated "metadata-ish" stuff is produced or typed incorrectly.In particular, RTLinker.m3:PROCEDURE AddUnit (b: RT0.Binder) =  VAR m: RT0.ModulePtr;  BEGIN    IF (b = NIL) THEN RETURN END;   line 119    m := b(0);                      line 120    IF (m = NIL) THEN RETURN END;   line 121    AddUnitI(m);                    line 122   END AddUnit;generates a lot of code, just for the first line:  (556) set_source_line      source line  119    (557) load      m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb    (558) load_nil    (559) if_eq    (560) load      m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb    (561) load_indirect      load address offset 0x0 src_t 0x5 dst_t 0x5    (562) load_integer      integer n_bytes 0x0 hi 0x0 low 0x1 sign -1    (563) if_eq    (564) set_label    (565) load_nil    (566) load      m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb    (567) if_ne    (568) set_label    (569) exit_proc    (570) set_label    (571) set_source_line      source line  120  The details on the load_integer trace might not be completely correct. I will test a fix shortly.Esp. that n_bytes gets decremented to zero before the trace.Ok, I see now why some of the bloat -- because the "then return end" is on the same line.If it were written as:  if (b = NIL THEN      return   end   It probably wouldn't look so bad. That took me a while to realize.The following is generated for SPARC64_OPENBSD:  line 119  .stabn 68,0,119,.LLM61-.LLFBB4 .LLM61: ldx [%fp+2175], %g1 brz %g1, .LL26  nop ldx [%fp+2175], %g1 ldx [%g1], %g1            bus error here? yes, probably this one cmp %g1, -1 be %xcc, .LL27  nop.LL26: ldx [%fp+2175], %g1 brz %g1, .LL33  nop.LL27: line 120  .stabn 68,0,120,.LLM62-.LLFBB4.LLM62: ldx [%fp+2175], %g1 stx %g1, [%fp+2007] ldx [%fp+2007], %g1 brz %g1, .LL30  nop ldx [%fp+2007], %g1 ldx [%g1], %g1            or here ? cmp %g1, -1 bne %xcc, .LL30  nop ldx [%fp+2007], %g1 add %g1, 16, %g1 ldx [%g1], %g1           or here?  stx %g1, [%fp+2015] ldx [%fp+2007], %g1 add %g1, 8, %g1 ldx [%g1], %g1 stx %g1, [%fp+2007].LL30: ldx [%fp+2007], %g1 ldx [%fp+2015], %g5 mov 0, %o0 call %g1, 0  nop mov %o0, %g1 stx %g1, [%fp+2023] ldx [%fp+2023], %g1 stx %g1, [%fp+1999]   line 121  .stabn 68,0,121,.LLM63-.LLFBB4.LLM63: ldx [%fp+1999], %g1 brz %g1, .LL33  nop.LL32: .stabn 68,0,122,.LLM64-.LLFBB4.LLM64:g1 points to RTSignal_I3(gdb) x/i $pc0x3ff0a8 :        ldx  [ %g1 ], %g1(gdb) x/i $g10x4021f4 : save  %sp, -208, %spI am willing to accept that a "function pointer" is a pair of pointers, or even three pointers.A pointer to code, a pointer to globals for position independent code, a frame pointer to locals.That equality comparison of function pointers requires comparing two (or three) pointers.  (Though the global pointer shouldn't need comparing.)At least for nested functions. Less so for non-nested. ?Much less for comparison to NIL. ?And either way, this code is reading bogus data.There isn't a pointer at the function address, there is code.Something doesn't add up.I'm going to try setting "aligned procedures" but that's quite bogus I think.EqualExpr.m3 says       Note: procedures pointers are always aligned!but maybe not?Yeah yeah I'm being lazy. I'll read more code..I also wonder if a "function pointer" can be optimized for the case of not being to a nested function.It looks like calling a function pointer is very inefficient.It looks like..am I reading that correctly?.. that if the pointer points to -1, then it is nested anda pair of pointers, and not otherwise. That -1 is treated specially as the first bytes of a function?Is that a Modula-3-ism or a SPARC-ism?It looks like a Modula-3-ism. And it seems dubious.But I'll have to read more.. NT386GNU does the same sort of wrong looking thing: LFBB4: pushl %ebp movl %esp, %ebp subl $24, %espLBB5: .stabn 68,0,117,LM60-LFBB4LM60: movl $0, -16(%ebp) .stabn 68,0,119,LM61-LFBB4LM61: movl 8(%ebp), %eax testl %eax, %eax je L26 movl 8(%ebp), %eax movl (%eax), %eax                  BAD  cmpl $-1, %eax                       BAD  je L27L26: movl 8(%ebp), %eax testl %eax, %eax je L33L27: .stabn 68,0,120,LM62-LFBB4LM62: and NT386: 0:000> ucm3!RTLinker__AddUnit:00607864 55              push    ebp00607865 8bec            mov     ebp,esp00607867 81ec0c000000    sub     esp,0Ch0060786d 53              push    ebx0060786e 56              push    esi0060786f 57              push    edi00607870 c745fc00000000  mov     dword ptr [ebp-4],000607877 837d0800        cmp     dword ptr [ebp+8],00:000> ucm3!RTLinker__AddUnit+0x17:0060787b 0f840f000000    je      cm3!RTLinker__AddUnit+0x2c (00607890)00607881 8b7508          mov     esi,dword ptr [ebp+8]00607884 8b5e00          mov     ebx,dword ptr [esi]                            BAD  00607887 83fbff          cmp     ebx,0FFFFFFFFh                                  BAD 0060788a 0f840f000000    je      cm3!RTLinker__AddUnit+0x3b (0060789f)00607890 837d0800        cmp     dword ptr [ebp+8],000607894 0f8505000000    jne     cm3!RTLinker__AddUnit+0x3b (0060789f)0060789a e969000000      jmp     cm3!RTLinker__AddUnit+0xa4 (00607908) cm3!RTLinker__AddUnit+0x20:00607884 8b5e00          mov     ebx,dword ptr [esi]  ds:002b:0062c950=81ec8b550:000> u @esicm3!RTLinker_I3:0062c950 55              push    ebp0062c951 8bec            mov     ebp,esp0062c953 81ec00000000    sub     esp,00062c959 53              push    ebx0062c95a 56              push    esi0062c95b 57              push    edi0062c95c 837d0800        cmp     dword ptr [ebp+8],00062c960 0f8400000000    je      cm3!RTLinker_I3+0x16 (0062c966) This is just wrong.Comparing bytes of code to -1. I think the likely fix is for the "I3" code to be laid out as a "constant function pointer", a pointer to a pair of pointers where one points to the code and one is to -1. Something like that. That can't be quite correct given that the existing data is callable.  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Sun May 25 08:42:35 2008
From: jayk123 at hotmail.com (Jay)
Date: Sun, 25 May 2008 06:42:35 +0000
Subject: [M3devel] cstdio.i3?
In-Reply-To: 
References: <483862F4.1E75.00D7.1@scires.com>
	
Message-ID: 

I'm wondering about Cstdio.i3..
 
It bugs me to see duplicated code/declarations, code I can't easily verify the correctness of, code that duplicates internal details either that aren't necessary and/or are subject to change (ie: it *might* be useful to know the size of a FILE, but knowing the internal makeup is not generally useful, as well the size can be abstracted away behind a tiny bit of portable C), etc.
 
interface Cstdio seems
 
- almost not used at all within the "std" packages
I realize folks out there with other code could be using it.
The only use I see is related to the next:
 
 - to offer little in the way of a portable interface
About the main portable thing is presents is that there is a type FILE_star, though even that isn't quite universial across them all; conceptually it is of course
However, a medium sized very portable interface is easy to expose, though it isn't necessarily easy to make much use of.
 
So:
 - do nothing?
 - reduce it all down to just a common two-liner TYPE FILE = RECORD END; FILE_star = UNTRACED REF FILE ?
 - bulk it up slightly to a very portable (target-independent) interface?
   NT386/Cstdio.i3 is close to what that would be.
 
And no, I'm not forgetful. I know I brought this up a few months ago when I introduced NT386/Cstdio.i3.
 
Does anyone find the knowledge built up in the myriad Cstdio.i3 files useful?
One thing to do is leave all the per-platform files but not put them in the m3makefile, only actually compile the two line or medium sized portable version.
 
 ?
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rodney.bates at wichita.edu  Mon May 26 05:50:15 2008
From: rodney.bates at wichita.edu (Rodney M. Bates)
Date: Sun, 25 May 2008 22:50:15 -0500
Subject: [M3devel] function pointers and comparison to nil? mis-typed
 function pointers?
In-Reply-To: 
References: <483862F4.1E75.00D7.1@scires.com>
	
	
Message-ID: <483A3377.7070801@wichita.edu>

I think I can shed some light on this, having spent some time making
m3gdb handle the various operations on nested procedures.  As for code
that mixes M3 and C, I believe the following are true:

- Within M3 code only, the closure system works correctly in all cases.
   This answers one of Jay's worries.

- For values of M3 procedure/C function pointer that are top-level
   (nonnested) procedures/functions, M3 and C code (generated by gcc,
   at least) are interchangeable.  This answers another of Jay's worries.
   This will cover that great majority of cases.

- Standard C has no nested functions.  Gcc adds them as a language
   extension.  Thus, only in gcc-compiled C code do we need to worry
   about nested procedures/functions between languages.  (Do any other
   C compilers exist that also have nested functions?)

- M3 code should be able to call the value of a procedure variable
   that was originally produced by C code as a pointer to a nested
   function, and get the environment set up right, so its nonlocal
   variable references will work, _if_ the nested function's
   environment has not disappeared.  This partially answers another
   of Jay's worries.  But:

- M3's normal runtime check that precludes assigning a nonlocal
   procedure value will not detect a C-code-produced nonlocal value,
   thus the environment could indeed have disappeared if the programmer
   was not careful.  However, gcc-extended C's nested functions have
   no protection against this bug when only C code is involved, so
   perhaps not detecting it in mixed M3/C is to be expected.

- C code that attempts to call a function pointer value that was
   originally produced by M3 code as a nested procedure value will
   almost certainly crash at the time of the call.  This is the only
   case that presents a significant problem.  M3 code will not be
   able to give a nested procedure as a callback to a C library.

M3's mechanism:  A value of procedure type is a pointer to either
1) the first byte of the procedure's machine code, if it is top level, or
2) A closure.

A closure is a block of 3 words.  The first word contains -1.  Assuming
a word of all one bits is not valid machine code on any target machine
(or at least doesn't occur as the first code of any procedure), this can
be used at runtime to detect that this is indeed a closure and not code.
The remaining two words hold the code address and the environment address.

So, an assignment of a procedure value has to check that it is not a closure,
and raise a runtime error if it is.  A call on a procedure value has to check,
and if it is a closure, load/copy its environment pointer value into wherever
the calling convention expects it, then branch to the code address.  Passing
a nested procedure constant as a parameter involves constructing a closure for
it and passing its address.

gcc-C's mechanism:  A value of type pointer to function is a pointer to either
1) the first byte of the function's machine code, if it is top level,
    (the same as with M3), or
2) A trampoline.

A trampoline is a bit of code that loads/copies an environment pointer (hard
coded into the trampoline) and then branches to the function code.

Trampolines probably have a small constant-time speed advantage for _calls_,
but would be slower for some of the other operations, and the runtime check
could be tricky.  Probably it could be fooled into failing when it shouldn't.
Moreover, trampolines are highly target-machine-dependent.  Switching to them
would create a really big problem for m3gdb, which would have to have
different code for each target for each of the nested procedure operations.

Jay wrote:
> I see somewhat.
> It's stuff around "closure".
> The comparison of code bytes to -1 comes from If_closure for example.
>  
> The problem is presumably to come up with a unified representation of 
> pointers to functions that may or may not be nested, while avoiding 
> runtime codegen, even just a little bit, and for Modula-3 and C function 
> pointers to use the same representation.
> I don't think the present solution is really valid, and I am skeptical 
> that there is a solution.
> One of the requirements has to be dropped.
> Sniffing code bytes and trying to decide if they are code or not as 
> appears to currently happen is bogus.
>  
> I think the solution is to remove the requirement that a Modula-3 
> function pointer and a C function pointer are the same.
> Except, well, that probably doesn't work -- it means you need two types 
> of function pointers.
>  
> Darn this is a hard problem.
>  
> The runtime codegen required can be exceedingly simple, fast, and small 
> IF it were allowed to be on the stack. But that's a killer these days.
>  
> I think you have to give up unification of "closures" and "function 
> pointers".
> If you take the address of a nested function and call it, you cannot 
> access the locals of the enclosing scopes.
> So in affect, you end up with "two types of function pointers".
> Regular stateless ones and "closures" with some captured state.
>  
> Thoughts?
>  
> I'm kind of stumped. It's a desirable problem to solve, and there is a 
> purported solution in place, but the solution that is there is 
> completely bogus, despite appearing to work for a long time, and there 
> is no solution. That is my understanding. I could be wrong on any number 
> of points but I'm pretty sure.
>  
> I think you have to separate out function pointers and closures.
> Sniffing what it pointed to is dubous esp. as currently implemented.
> If this is really the way to go, then signature bytes need to be worked 
> out for all architectures that are guaranteed to not look like code.
> Or vice versa -- signature bytes worked out that all functions start 
> with, which is viable for Modula-3 but not for interop with C.
> Currently -1 is used, of pointer-size.
> That appears to be reasonable for x86:
>  
> 0:000> eb . ff ff ff ff
> 0:000> u .
> ntdll32!DbgBreakPoint:
> 7d61002d ff              ???
> 7d61002e ff              ???
> 7d61002f ff              ???
> 7d610030 ffc3            inc     ebx
>  
> but the instruction encodings or disassembly on other architectures 
> would have to be checked.
>  
>  - Jay
> 
>     ------------------------------------------------------------------------
>     From: jayk123 at hotmail.com
>     To: m3devel at elegosoft.com
>     Date: Sun, 25 May 2008 00:16:01 +0000
>     Subject: [M3devel] function pointers and comparison to nil?
>     mis-typed function pointers?
> 
>     I'm being lazy...
> 
>     Tony can you explain this stuff?
> 
>     Comparison of function pointers..
>     What are the various representations and rules?
> 
>     What does it mean to compare nested functions?
> 
>     What does it mean to compare a function to NIL?
> 
>     I'll poke around more.
> 
>     What I am seeing is that comparison of function pointers to NIL is
>     surprisingly
>     expensive, and probably somewhat buggy. Or at least some of the runtime
>     generated "metadata-ish" stuff is produced or typed incorrectly.
> 
>     In particular, RTLinker.m3:
> 
>     PROCEDURE AddUnit (b: RT0.Binder) =
>       VAR m: RT0.ModulePtr;
>       BEGIN
>         IF (b = NIL) THEN RETURN END;   line 119
>         m := b(0);                      line 120
>         IF (m = NIL) THEN RETURN END;   line 121
>         AddUnitI(m);                    line 122
>       END AddUnit;
> 
>     generates a lot of code, just for the first line:
>       (556) set_source_line 
>         source line  119 
>       (557) load 
>         m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb 
>       (558) load_nil 
>       (559) if_eq 
>       (560) load 
>         m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb 
>       (561) load_indirect 
>         load address offset 0x0 src_t 0x5 dst_t 0x5 
>       (562) load_integer 
>         integer n_bytes 0x0 hi 0x0 low 0x1 sign -1 
>       (563) if_eq 
>       (564) set_label 
>       (565) load_nil 
>       (566) load 
>         m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb 
>       (567) if_ne 
>       (568) set_label 
>       (569) exit_proc 
>       (570) set_label 
>       (571) set_source_line 
>         source line  120 
> 
>     The details on the load_integer trace might not be completely
>     correct. I will test a fix shortly.
>     Esp. that n_bytes gets decremented to zero before the trace.
> 
>     Ok, I see now why some of the bloat -- because the "then return end"
>     is on the same line.
>     If it were written as:
>       if (b = NIL THEN 
>         return
>       end  
>     It probably wouldn't look so bad. That took me a while to realize.
> 
>     The following is generated for SPARC64_OPENBSD:
>      
>      line 119
>      .stabn 68,0,119,.LLM61-.LLFBB4
>     .LLM61:
>      ldx [%fp+2175], %g1
>      brz %g1, .LL26
>       nop
>      ldx [%fp+2175], %g1
>      ldx [%g1], %g1            bus error here? yes, probably this one
>      cmp %g1, -1
>      be %xcc, .LL27
>       nop
>     .LL26:
>      ldx [%fp+2175], %g1
>      brz %g1, .LL33
>       nop
>     .LL27:
>      line 120
>      .stabn 68,0,120,.LLM62-.LLFBB4
>     .LLM62:
>      ldx [%fp+2175], %g1
>      stx %g1, [%fp+2007]
>      ldx [%fp+2007], %g1
>      brz %g1, .LL30
>       nop
>      ldx [%fp+2007], %g1
>      ldx [%g1], %g1            or here ?
>      cmp %g1, -1
>      bne %xcc, .LL30
>       nop
>      ldx [%fp+2007], %g1
>      add %g1, 16, %g1
>      ldx [%g1], %g1           or here?
>      stx %g1, [%fp+2015]
>      ldx [%fp+2007], %g1
>      add %g1, 8, %g1
>      ldx [%g1], %g1
>      stx %g1, [%fp+2007]
>     .LL30:
>      ldx [%fp+2007], %g1
>      ldx [%fp+2015], %g5
>      mov 0, %o0
>      call %g1, 0
>       nop
>      mov %o0, %g1
>      stx %g1, [%fp+2023]
>      ldx [%fp+2023], %g1
>      stx %g1, [%fp+1999]
>      
>      line 121
> 
>      .stabn 68,0,121,.LLM63-.LLFBB4
>     .LLM63:
>      ldx [%fp+1999], %g1
>      brz %g1, .LL33
>       nop
>     .LL32:
>      .stabn 68,0,122,.LLM64-.LLFBB4
>     .LLM64:
> 
>     g1 points to RTSignal_I3
> 
>     (gdb) x/i $pc
>     0x3ff0a8 :        ldx  [ %g1 ], %g1
>     (gdb) x/i $g1
>     0x4021f4 : save  %sp, -208, %sp
> 
>     I am willing to accept that a "function pointer" is a pair of
>     pointers, or even three pointers.
>     A pointer to code, a pointer to globals for position independent
>     code, a frame pointer to locals.
>     That equality comparison of function pointers requires comparing two
>     (or three) pointers.
>       (Though the global pointer shouldn't need comparing.)
>     At least for nested functions. Less so for non-nested. ?
>     Much less for comparison to NIL. ?
> 
>     And either way, this code is reading bogus data.
>     There isn't a pointer at the function address, there is code.
> 
>     Something doesn't add up.
> 
>     I'm going to try setting "aligned procedures" but that's quite bogus
>     I think.
> 
>     EqualExpr.m3 says
> 
>            Note: procedures pointers are always aligned!
> 
>     but maybe not?
> 
>     Yeah yeah I'm being lazy. I'll read more code..
> 
>     I also wonder if a "function pointer" can be optimized for the case
>     of not being to a nested function.
>     It looks like calling a function pointer is very inefficient.
>     It looks like..am I reading that correctly?.. that if the pointer
>     points to -1, then it is nested and
>     a pair of pointers, and not otherwise. That -1 is treated specially
>     as the first bytes of a function?
>     Is that a Modula-3-ism or a SPARC-ism?
>     It looks like a Modula-3-ism. And it seems dubious.
>     But I'll have to read more..
>      
>     NT386GNU does the same sort of wrong looking thing:
>      
>     LFBB4:
>      pushl %ebp
>      movl %esp, %ebp
>      subl $24, %esp
>     LBB5:
>      .stabn 68,0,117,LM60-LFBB4
>     LM60:
>      movl $0, -16(%ebp)
>      .stabn 68,0,119,LM61-LFBB4
>     LM61:
>      movl 8(%ebp), %eax
>      testl %eax, %eax
>      je L26
>      movl 8(%ebp), %eax
>      movl (%eax), %eax                  BAD
>      cmpl $-1, %eax                       BAD
>      je L27
>     L26:
>      movl 8(%ebp), %eax
>      testl %eax, %eax
>      je L33
>     L27:
>      .stabn 68,0,120,LM62-LFBB4
>     LM62:
> 
>      
>     and NT386:
>      
>     0:000> u
>     cm3!RTLinker__AddUnit:
>     00607864 55              push    ebp
>     00607865 8bec            mov     ebp,esp
>     00607867 81ec0c000000    sub     esp,0Ch
>     0060786d 53              push    ebx
>     0060786e 56              push    esi
>     0060786f 57              push    edi
>     00607870 c745fc00000000  mov     dword ptr [ebp-4],0
>     00607877 837d0800        cmp     dword ptr [ebp+8],0
>     0:000> u
>     cm3!RTLinker__AddUnit+0x17:
>     0060787b 0f840f000000    je      cm3!RTLinker__AddUnit+0x2c (00607890)
>     00607881 8b7508          mov     esi,dword ptr [ebp+8]
>     00607884 8b5e00          mov     ebx,dword ptr
>     [esi]                            BAD 
>     00607887 83fbff          cmp    
>     ebx,0FFFFFFFFh                                  BAD
>     0060788a 0f840f000000    je      cm3!RTLinker__AddUnit+0x3b (0060789f)
>     00607890 837d0800        cmp     dword ptr [ebp+8],0
>     00607894 0f8505000000    jne     cm3!RTLinker__AddUnit+0x3b (0060789f)
>     0060789a e969000000      jmp     cm3!RTLinker__AddUnit+0xa4 (00607908)
>      
>     cm3!RTLinker__AddUnit+0x20:
>     00607884 8b5e00          mov     ebx,dword ptr [esi] 
>     ds:002b:0062c950=81ec8b55
>     0:000> u @esi
>     cm3!RTLinker_I3:
>     0062c950 55              push    ebp
>     0062c951 8bec            mov     ebp,esp
>     0062c953 81ec00000000    sub     esp,0
>     0062c959 53              push    ebx
>     0062c95a 56              push    esi
>     0062c95b 57              push    edi
>     0062c95c 837d0800        cmp     dword ptr [ebp+8],0
>     0062c960 0f8400000000    je      cm3!RTLinker_I3+0x16 (0062c966)
>      
>     This is just wrong.
>     Comparing bytes of code to -1.
>      
>     I think the likely fix is for the "I3" code to be laid out as a
>     "constant function pointer", a pointer to a pair of pointers where
>     one points to the code and one is to -1. Something like that. That
>     can't be quite correct given that the existing data is callable.
> 
>       - Jay

-- 
-------------------------------------------------------------
Rodney M. Bates, retired assistant professor
Dept. of Computer Science, Wichita State University
Wichita, KS 67260-0083
316-978-3922
rodney.bates at wichita.edu


From jayk123 at hotmail.com  Mon May 26 07:26:41 2008
From: jayk123 at hotmail.com (Jay)
Date: Mon, 26 May 2008 05:26:41 +0000
Subject: [M3devel] function pointers and comparison to nil? mis-typed
 function pointers?
In-Reply-To: <483A3377.7070801@wichita.edu>
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
Message-ID: 

Rodney, this agrees with much of what I figured out and guessed. I did not think of or look into some of what you point out though:
  - what gcc's nested functions look like, and if you can take the address, and what that does 
  - calling Modula-3 nested functions as callbacks from C 
 
Now, regarding trampolines.
I alluded to them. It should be easy enough to generate them, and this would solve a few problems, but I believe also bring up a new big problem.
Generating trampolines solves at least two problems: 
 - it allows Modula-3 nested function pointers ("closures") to be called from C 
 - it enables removing the check for -1 
 
I contend that the check for -1 is not good. It is a somewhat risky assumption, that "-1" is not valid code.
You do bring up a nice mitigation -- the assumption that it doesn't begin any functions, which is much narrower than it being valid code anywhere.
 
For SPARC64_OPENBSD I figured out what the original authors meant to be the fix.
You declare functions as not aligned, leading to the check for -1 first checking alignment (bigger code).
Any pointer not aligned on an integer-sized address is presumed not a closure and not checked for the -1.
This lets SPARC64_OPENBSD get further. Both it and PPC32_OPENBSD now for some reason suffer from an inability to heap allocate anything, failing around the attempt to create a new thread like in RTAllocator_M or so. I'll look into this more later.
Now, the problem of trampolines..I consider the platform-dependent-ness to be surmountable.
But where do you put the generated code? Putting it on the stack is counter to modern (and possibly old) "security" mechanisms.
The stack is not generally executable, and even when it is, best just not do use that imho.
 
That means, potentially/obviously, the need to heap allocate executable memory, for very small short lived data, quite inefficient.
 
Is there some other way/place to produce trampolines, efficiently?
 
In the absence of any good solution, I have to resign myself to assuming that -1 isn't the valid start of a function, and perhaps moving the marker into Target.i3, Target.m3 so that "more obvious" values get chosen. Like a breakpoint. Or "an epilogue", or "a trap instruction". I realize this needs details and is easily seen as "wrong". In particular, a function that does nothing could be termed as only having an "an epilogue".
 
I know that other systems are "forced" to create "trampolines" so I should look into how they do that.
I know that ATL, a Windows-specific library, is forced to heap allocate small executable chunks of memory and uses an efficient cache to optimize it.
 
I do find this dependence on -1 not being the valid start of a function rather sleazy and at risk of being wrong.
 
 - Jay



> Date: Sun, 25 May 2008 22:50:15 -0500> From: rodney.bates at wichita.edu> To: m3devel at elegosoft.com> Subject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?> > I think I can shed some light on this, having spent some time making> m3gdb handle the various operations on nested procedures. As for code> that mixes M3 and C, I believe the following are true:> > - Within M3 code only, the closure system works correctly in all cases.> This answers one of Jay's worries.> > - For values of M3 procedure/C function pointer that are top-level> (nonnested) procedures/functions, M3 and C code (generated by gcc,> at least) are interchangeable. This answers another of Jay's worries.> This will cover that great majority of cases.> > - Standard C has no nested functions. Gcc adds them as a language> extension. Thus, only in gcc-compiled C code do we need to worry> about nested procedures/functions between languages. (Do any other> C compilers exist that also have nested functions?)> > - M3 code should be able to call the value of a procedure variable> that was originally produced by C code as a pointer to a nested> function, and get the environment set up right, so its nonlocal> variable references will work, _if_ the nested function's> environment has not disappeared. This partially answers another> of Jay's worries. But:> > - M3's normal runtime check that precludes assigning a nonlocal> procedure value will not detect a C-code-produced nonlocal value,> thus the environment could indeed have disappeared if the programmer> was not careful. However, gcc-extended C's nested functions have> no protection against this bug when only C code is involved, so> perhaps not detecting it in mixed M3/C is to be expected.> > - C code that attempts to call a function pointer value that was> originally produced by M3 code as a nested procedure value will> almost certainly crash at the time of the call. This is the only> case that presents a significant problem. M3 code will not be> able to give a nested procedure as a callback to a C library.> > M3's mechanism: A value of procedure type is a pointer to either> 1) the first byte of the procedure's machine code, if it is top level, or> 2) A closure.> > A closure is a block of 3 words. The first word contains -1. Assuming> a word of all one bits is not valid machine code on any target machine> (or at least doesn't occur as the first code of any procedure), this can> be used at runtime to detect that this is indeed a closure and not code.> The remaining two words hold the code address and the environment address.> > So, an assignment of a procedure value has to check that it is not a closure,> and raise a runtime error if it is. A call on a procedure value has to check,> and if it is a closure, load/copy its environment pointer value into wherever> the calling convention expects it, then branch to the code address. Passing> a nested procedure constant as a parameter involves constructing a closure for> it and passing its address.> > gcc-C's mechanism: A value of type pointer to function is a pointer to either> 1) the first byte of the function's machine code, if it is top level,> (the same as with M3), or> 2) A trampoline.> > A trampoline is a bit of code that loads/copies an environment pointer (hard> coded into the trampoline) and then branches to the function code.> > Trampolines probably have a small constant-time speed advantage for _calls_,> but would be slower for some of the other operations, and the runtime check> could be tricky. Probably it could be fooled into failing when it shouldn't.> Moreover, trampolines are highly target-machine-dependent. Switching to them> would create a really big problem for m3gdb, which would have to have> different code for each target for each of the nested procedure operations.> > Jay wrote:> > I see somewhat.> > It's stuff around "closure".> > The comparison of code bytes to -1 comes from If_closure for example.> > > > The problem is presumably to come up with a unified representation of > > pointers to functions that may or may not be nested, while avoiding > > runtime codegen, even just a little bit, and for Modula-3 and C function > > pointers to use the same representation.> > I don't think the present solution is really valid, and I am skeptical > > that there is a solution.> > One of the requirements has to be dropped.> > Sniffing code bytes and trying to decide if they are code or not as > > appears to currently happen is bogus.> > > > I think the solution is to remove the requirement that a Modula-3 > > function pointer and a C function pointer are the same.> > Except, well, that probably doesn't work -- it means you need two types > > of function pointers.> > > > Darn this is a hard problem.> > > > The runtime codegen required can be exceedingly simple, fast, and small > > IF it were allowed to be on the stack. But that's a killer these days.> > > > I think you have to give up unification of "closures" and "function > > pointers".> > If you take the address of a nested function and call it, you cannot > > access the locals of the enclosing scopes.> > So in affect, you end up with "two types of function pointers".> > Regular stateless ones and "closures" with some captured state.> > > > Thoughts?> > > > I'm kind of stumped. It's a desirable problem to solve, and there is a > > purported solution in place, but the solution that is there is > > completely bogus, despite appearing to work for a long time, and there > > is no solution. That is my understanding. I could be wrong on any number > > of points but I'm pretty sure.> > > > I think you have to separate out function pointers and closures.> > Sniffing what it pointed to is dubous esp. as currently implemented.> > If this is really the way to go, then signature bytes need to be worked > > out for all architectures that are guaranteed to not look like code.> > Or vice versa -- signature bytes worked out that all functions start > > with, which is viable for Modula-3 but not for interop with C.> > Currently -1 is used, of pointer-size.> > That appears to be reasonable for x86:> > > > 0:000> eb . ff ff ff ff> > 0:000> u .> > ntdll32!DbgBreakPoint:> > 7d61002d ff ???> > 7d61002e ff ???> > 7d61002f ff ???> > 7d610030 ffc3 inc ebx> > > > but the instruction encodings or disassembly on other architectures > > would have to be checked.> > > > - Jay> > > > ------------------------------------------------------------------------> > From: jayk123 at hotmail.com> > To: m3devel at elegosoft.com> > Date: Sun, 25 May 2008 00:16:01 +0000> > Subject: [M3devel] function pointers and comparison to nil?> > mis-typed function pointers?> > > > I'm being lazy...> > > > Tony can you explain this stuff?> > > > Comparison of function pointers..> > What are the various representations and rules?> > > > What does it mean to compare nested functions?> > > > What does it mean to compare a function to NIL?> > > > I'll poke around more.> > > > What I am seeing is that comparison of function pointers to NIL is> > surprisingly> > expensive, and probably somewhat buggy. Or at least some of the runtime> > generated "metadata-ish" stuff is produced or typed incorrectly.> > > > In particular, RTLinker.m3:> > > > PROCEDURE AddUnit (b: RT0.Binder) => > VAR m: RT0.ModulePtr;> > BEGIN> > IF (b = NIL) THEN RETURN END; line 119> > m := b(0); line 120> > IF (m = NIL) THEN RETURN END; line 121> > AddUnitI(m); line 122> > END AddUnit;> > > > generates a lot of code, just for the first line:> > (556) set_source_line > > source line 119 > > (557) load > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb > > (558) load_nil > > (559) if_eq > > (560) load > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb > > (561) load_indirect > > load address offset 0x0 src_t 0x5 dst_t 0x5 > > (562) load_integer > > integer n_bytes 0x0 hi 0x0 low 0x1 sign -1 > > (563) if_eq > > (564) set_label > > (565) load_nil > > (566) load > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb > > (567) if_ne > > (568) set_label > > (569) exit_proc > > (570) set_label > > (571) set_source_line > > source line 120 > > > > The details on the load_integer trace might not be completely> > correct. I will test a fix shortly.> > Esp. that n_bytes gets decremented to zero before the trace.> > > > Ok, I see now why some of the bloat -- because the "then return end"> > is on the same line.> > If it were written as:> > if (b = NIL THEN > > return> > end > > It probably wouldn't look so bad. That took me a while to realize.> > > > The following is generated for SPARC64_OPENBSD:> > > > line 119> > .stabn 68,0,119,.LLM61-.LLFBB4> > .LLM61:> > ldx [%fp+2175], %g1> > brz %g1, .LL26> > nop> > ldx [%fp+2175], %g1> > ldx [%g1], %g1 bus error here? yes, probably this one> > cmp %g1, -1> > be %xcc, .LL27> > nop> > .LL26:> > ldx [%fp+2175], %g1> > brz %g1, .LL33> > nop> > .LL27:> > line 120> > .stabn 68,0,120,.LLM62-.LLFBB4> > .LLM62:> > ldx [%fp+2175], %g1> > stx %g1, [%fp+2007]> > ldx [%fp+2007], %g1> > brz %g1, .LL30> > nop> > ldx [%fp+2007], %g1> > ldx [%g1], %g1 or here ?> > cmp %g1, -1> > bne %xcc, .LL30> > nop> > ldx [%fp+2007], %g1> > add %g1, 16, %g1> > ldx [%g1], %g1 or here?> > stx %g1, [%fp+2015]> > ldx [%fp+2007], %g1> > add %g1, 8, %g1> > ldx [%g1], %g1> > stx %g1, [%fp+2007]> > .LL30:> > ldx [%fp+2007], %g1> > ldx [%fp+2015], %g5> > mov 0, %o0> > call %g1, 0> > nop> > mov %o0, %g1> > stx %g1, [%fp+2023]> > ldx [%fp+2023], %g1> > stx %g1, [%fp+1999]> > > > line 121> > > > .stabn 68,0,121,.LLM63-.LLFBB4> > .LLM63:> > ldx [%fp+1999], %g1> > brz %g1, .LL33> > nop> > .LL32:> > .stabn 68,0,122,.LLM64-.LLFBB4> > .LLM64:> > > > g1 points to RTSignal_I3> > > > (gdb) x/i $pc> > 0x3ff0a8 : ldx [ %g1 ], %g1> > (gdb) x/i $g1> > 0x4021f4 : save %sp, -208, %sp> > > > I am willing to accept that a "function pointer" is a pair of> > pointers, or even three pointers.> > A pointer to code, a pointer to globals for position independent> > code, a frame pointer to locals.> > That equality comparison of function pointers requires comparing two> > (or three) pointers.> > (Though the global pointer shouldn't need comparing.)> > At least for nested functions. Less so for non-nested. ?> > Much less for comparison to NIL. ?> > > > And either way, this code is reading bogus data.> > There isn't a pointer at the function address, there is code.> > > > Something doesn't add up.> > > > I'm going to try setting "aligned procedures" but that's quite bogus> > I think.> > > > EqualExpr.m3 says> > > > Note: procedures pointers are always aligned!> > > > but maybe not?> > > > Yeah yeah I'm being lazy. I'll read more code..> > > > I also wonder if a "function pointer" can be optimized for the case> > of not being to a nested function.> > It looks like calling a function pointer is very inefficient.> > It looks like..am I reading that correctly?.. that if the pointer> > points to -1, then it is nested and> > a pair of pointers, and not otherwise. That -1 is treated specially> > as the first bytes of a function?> > Is that a Modula-3-ism or a SPARC-ism?> > It looks like a Modula-3-ism. And it seems dubious.> > But I'll have to read more..> > > > NT386GNU does the same sort of wrong looking thing:> > > > LFBB4:> > pushl %ebp> > movl %esp, %ebp> > subl $24, %esp> > LBB5:> > .stabn 68,0,117,LM60-LFBB4> > LM60:> > movl $0, -16(%ebp)> > .stabn 68,0,119,LM61-LFBB4> > LM61:> > movl 8(%ebp), %eax> > testl %eax, %eax> > je L26> > movl 8(%ebp), %eax> > movl (%eax), %eax BAD> > cmpl $-1, %eax BAD> > je L27> > L26:> > movl 8(%ebp), %eax> > testl %eax, %eax> > je L33> > L27:> > .stabn 68,0,120,LM62-LFBB4> > LM62:> > > > > > and NT386:> > > > 0:000> u> > cm3!RTLinker__AddUnit:> > 00607864 55 push ebp> > 00607865 8bec mov ebp,esp> > 00607867 81ec0c000000 sub esp,0Ch> > 0060786d 53 push ebx> > 0060786e 56 push esi> > 0060786f 57 push edi> > 00607870 c745fc00000000 mov dword ptr [ebp-4],0> > 00607877 837d0800 cmp dword ptr [ebp+8],0> > 0:000> u> > cm3!RTLinker__AddUnit+0x17:> > 0060787b 0f840f000000 je cm3!RTLinker__AddUnit+0x2c (00607890)> > 00607881 8b7508 mov esi,dword ptr [ebp+8]> > 00607884 8b5e00 mov ebx,dword ptr> > [esi] BAD > > 00607887 83fbff cmp > > ebx,0FFFFFFFFh BAD> > 0060788a 0f840f000000 je cm3!RTLinker__AddUnit+0x3b (0060789f)> > 00607890 837d0800 cmp dword ptr [ebp+8],0> > 00607894 0f8505000000 jne cm3!RTLinker__AddUnit+0x3b (0060789f)> > 0060789a e969000000 jmp cm3!RTLinker__AddUnit+0xa4 (00607908)> > > > cm3!RTLinker__AddUnit+0x20:> > 00607884 8b5e00 mov ebx,dword ptr [esi] > > ds:002b:0062c950=81ec8b55> > 0:000> u @esi> > cm3!RTLinker_I3:> > 0062c950 55 push ebp> > 0062c951 8bec mov ebp,esp> > 0062c953 81ec00000000 sub esp,0> > 0062c959 53 push ebx> > 0062c95a 56 push esi> > 0062c95b 57 push edi> > 0062c95c 837d0800 cmp dword ptr [ebp+8],0> > 0062c960 0f8400000000 je cm3!RTLinker_I3+0x16 (0062c966)> > > > This is just wrong.> > Comparing bytes of code to -1.> > > > I think the likely fix is for the "I3" code to be laid out as a> > "constant function pointer", a pointer to a pair of pointers where> > one points to the code and one is to -1. Something like that. That> > can't be quite correct given that the existing data is callable.> > > > - Jay> > -- > -------------------------------------------------------------> Rodney M. Bates, retired assistant professor> Dept. of Computer Science, Wichita State University> Wichita, KS 67260-0083> 316-978-3922> rodney.bates at wichita.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Mon May 26 12:04:56 2008
From: jayk123 at hotmail.com (Jay)
Date: Mon, 26 May 2008 10:04:56 +0000
Subject: [M3devel] function pointers and comparison to nil? mis-typed
 function pointers?
In-Reply-To: 
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
	
Message-ID: 

Cygwin gcc clearly generates code on the stack for nested functions.
And then search the web..that's how it works in general.
Nested functions have been deprecated on Mac OS X, in anticipation of possibly making the stack not executable.
 
OpenBSD doesn't allow execution on the stack.
They use mprotect to let trampolines run:
  http://gcc.gnu.org/ml/gcc/2004-01/msg00742.html 
and
  http://resin.csoft.net/cgi-bin/man.cgi?section=1&topic=gcc-local 
 
Even though nested functions are a gcc extension to the C language, email threads out there discuss Ada, Pascal, and even ! Modula-3 as having nested functions, and that therefore deprecating the C language feature doesn't "solve" the "problem".
 
I remain uncertain what, if anything, to do here.
 - keep the -1 hack, do nothing 
    generalize it slightly to let targets pick "better" markers 
 - use gcc's supported for nested functions 
   (plus the integrated backend, not difficult) 
 
Clearly this is a dilemna to more than just me. :)
 
 - Jay


From: jayk123 at hotmail.comTo: rodney.bates at wichita.edu; m3devel at elegosoft.comDate: Mon, 26 May 2008 05:26:41 +0000Subject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?


Rodney, this agrees with much of what I figured out and guessed. I did not think of or look into some of what you point out though:  - what gcc's nested functions look like, and if you can take the address, and what that does   - calling Modula-3 nested functions as callbacks from C  Now, regarding trampolines.I alluded to them. It should be easy enough to generate them, and this would solve a few problems, but I believe also bring up a new big problem.Generating trampolines solves at least two problems:  - it allows Modula-3 nested function pointers ("closures") to be called from C  - it enables removing the check for -1  I contend that the check for -1 is not good. It is a somewhat risky assumption, that "-1" is not valid code.You do bring up a nice mitigation -- the assumption that it doesn't begin any functions, which is much narrower than it being valid code anywhere. For SPARC64_OPENBSD I figured out what the original authors meant to be the fix.You declare functions as not aligned, leading to the check for -1 first checking alignment (bigger code).Any pointer not aligned on an integer-sized address is presumed not a closure and not checked for the -1.This lets SPARC64_OPENBSD get further. Both it and PPC32_OPENBSD now for some reason suffer from an inability to heap allocate anything, failing around the attempt to create a new thread like in RTAllocator_M or so. I'll look into this more later.Now, the problem of trampolines..I consider the platform-dependent-ness to be surmountable.But where do you put the generated code? Putting it on the stack is counter to modern (and possibly old) "security" mechanisms.The stack is not generally executable, and even when it is, best just not do use that imho. That means, potentially/obviously, the need to heap allocate executable memory, for very small short lived data, quite inefficient. Is there some other way/place to produce trampolines, efficiently? In the absence of any good solution, I have to resign myself to assuming that -1 isn't the valid start of a function, and perhaps moving the marker into Target.i3, Target.m3 so that "more obvious" values get chosen. Like a breakpoint. Or "an epilogue", or "a trap instruction". I realize this needs details and is easily seen as "wrong". In particular, a function that does nothing could be termed as only having an "an epilogue". I know that other systems are "forced" to create "trampolines" so I should look into how they do that.I know that ATL, a Windows-specific library, is forced to heap allocate small executable chunks of memory and uses an efficient cache to optimize it. I do find this dependence on -1 not being the valid start of a function rather sleazy and at risk of being wrong.  - Jay

> Date: Sun, 25 May 2008 22:50:15 -0500> From: rodney.bates at wichita.edu> To: m3devel at elegosoft.com> Subject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?> > I think I can shed some light on this, having spent some time making> m3gdb handle the various operations on nested procedures. As for code> that mixes M3 and C, I believe the following are true:> > - Within M3 code only, the closure system works correctly in all cases.> This answers one of Jay's worries.> > - For values of M3 procedure/C function pointer that are top-level> (nonnested) procedures/functions, M3 and C code (generated by gcc,> at least) are interchangeable. This answers another of Jay's worries.> This will cover that great majority of cases.> > - Standard C has no nested functions. Gcc adds them as a language> extension. Thus, only in gcc-compiled C code do we need to worry> about nested procedures/functions between languages. (Do any other> C compilers exist that also have nested functions?)> > - M3 code should be able to call the value of a procedure variable> that was originally produced by C code as a pointer to a nested> function, and get the environment set up right, so its nonlocal> variable references will work, _if_ the nested function's> environment has not disappeared. This partially answers another> of Jay's worries. But:> > - M3's normal runtime check that precludes assigning a nonlocal> procedure value will not detect a C-code-produced nonlocal value,> thus the environment could indeed have disappeared if the programmer> was not careful. However, gcc-extended C's nested functions have> no protection against this bug when only C code is involved, so> perhaps not detecting it in mixed M3/C is to be expected.> > - C code that attempts to call a function pointer value that was> originally produced by M3 code as a nested procedure value will> almost certainly crash at the time of the call. This is the only> case that presents a significant problem. M3 code will not be> able to give a nested procedure as a callback to a C library.> > M3's mechanism: A value of procedure type is a pointer to either> 1) the first byte of the procedure's machine code, if it is top level, or> 2) A closure.> > A closure is a block of 3 words. The first word contains -1. Assuming> a word of all one bits is not valid machine code on any target machine> (or at least doesn't occur as the first code of any procedure), this can> be used at runtime to detect that this is indeed a closure and not code.> The remaining two words hold the code address and the environment address.> > So, an assignment of a procedure value has to check that it is not a closure,> and raise a runtime error if it is. A call on a procedure value has to check,> and if it is a closure, load/copy its environment pointer value into wherever> the calling convention expects it, then branch to the code address. Passing> a nested procedure constant as a parameter involves constructing a closure for> it and passing its address.> > gcc-C's mechanism: A value of type pointer to function is a pointer to either> 1) the first byte of the function's machine code, if it is top level,> (the same as with M3), or> 2) A trampoline.> > A trampoline is a bit of code that loads/copies an environment pointer (hard> coded into the trampoline) and then branches to the function code.> > Trampolines probably have a small constant-time speed advantage for _calls_,> but would be slower for some of the other operations, and the runtime check> could be tricky. Probably it could be fooled into failing when it shouldn't.> Moreover, trampolines are highly target-machine-dependent. Switching to them> would create a really big problem for m3gdb, which would have to have> different code for each target for each of the nested procedure operations.> > Jay wrote:> > I see somewhat.> > It's stuff around "closure".> > The comparison of code bytes to -1 comes from If_closure for example.> > > > The problem is presumably to come up with a unified representation of > > pointers to functions that may or may not be nested, while avoiding > > runtime codegen, even just a little bit, and for Modula-3 and C function > > pointers to use the same representation.> > I don't think the present solution is really valid, and I am skeptical > > that there is a solution.> > One of the requirements has to be dropped.> > Sniffing code bytes and trying to decide if they are code or not as > > appears to currently happen is bogus.> > > > I think the solution is to remove the requirement that a Modula-3 > > function pointer and a C function pointer are the same.> > Except, well, that probably doesn't work -- it means you need two types > > of function pointers.> > > > Darn this is a hard problem.> > > > The runtime codegen required can be exceedingly simple, fast, and small > > IF it were allowed to be on the stack. But that's a killer these days.> > > > I think you have to give up unification of "closures" and "function > > pointers".> > If you take the address of a nested function and call it, you cannot > > access the locals of the enclosing scopes.> > So in affect, you end up with "two types of function pointers".> > Regular stateless ones and "closures" with some captured state.> > > > Thoughts?> > > > I'm kind of stumped. It's a desirable problem to solve, and there is a > > purported solution in place, but the solution that is there is > > completely bogus, despite appearing to work for a long time, and there > > is no solution. That is my understanding. I could be wrong on any number > > of points but I'm pretty sure.> > > > I think you have to separate out function pointers and closures.> > Sniffing what it pointed to is dubous esp. as currently implemented.> > If this is really the way to go, then signature bytes need to be worked > > out for all architectures that are guaranteed to not look like code.> > Or vice versa -- signature bytes worked out that all functions start > > with, which is viable for Modula-3 but not for interop with C.> > Currently -1 is used, of pointer-size.> > That appears to be reasonable for x86:> > > > 0:000> eb . ff ff ff ff> > 0:000> u .> > ntdll32!DbgBreakPoint:> > 7d61002d ff ???> > 7d61002e ff ???> > 7d61002f ff ???> > 7d610030 ffc3 inc ebx> > > > but the instruction encodings or disassembly on other architectures > > would have to be checked.> > > > - Jay> > > > ------------------------------------------------------------------------> > From: jayk123 at hotmail.com> > To: m3devel at elegosoft.com> > Date: Sun, 25 May 2008 00:16:01 +0000> > Subject: [M3devel] function pointers and comparison to nil?> > mis-typed function pointers?> > > > I'm being lazy...> > > > Tony can you explain this stuff?> > > > Comparison of function pointers..> > What are the various representations and rules?> > > > What does it mean to compare nested functions?> > > > What does it mean to compare a function to NIL?> > > > I'll poke around more.> > > > What I am seeing is that comparison of function pointers to NIL is> > surprisingly> > expensive, and probably somewhat buggy. Or at least some of the runtime> > generated "metadata-ish" stuff is produced or typed incorrectly.> > > > In particular, RTLinker.m3:> > > > PROCEDURE AddUnit (b: RT0.Binder) => > VAR m: RT0.ModulePtr;> > BEGIN> > IF (b = NIL) THEN RETURN END; line 119> > m := b(0); line 120> > IF (m = NIL) THEN RETURN END; line 121> > AddUnitI(m); line 122> > END AddUnit;> > > > generates a lot of code, just for the first line:> > (556) set_source_line > > source line 119 > > (557) load > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb > > (558) load_nil > > (559) if_eq > > (560) load > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb > > (561) load_indirect > > load address offset 0x0 src_t 0x5 dst_t 0x5 > > (562) load_integer > > integer n_bytes 0x0 hi 0x0 low 0x1 sign -1 > > (563) if_eq > > (564) set_label > > (565) load_nil > > (566) load > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb > > (567) if_ne > > (568) set_label > > (569) exit_proc > > (570) set_label > > (571) set_source_line > > source line 120 > > > > The details on the load_integer trace might not be completely> > correct. I will test a fix shortly.> > Esp. that n_bytes gets decremented to zero before the trace.> > > > Ok, I see now why some of the bloat -- because the "then return end"> > is on the same line.> > If it were written as:> > if (b = NIL THEN > > return> > end > > It probably wouldn't look so bad. That took me a while to realize.> > > > The following is generated for SPARC64_OPENBSD:> > > > line 119> > .stabn 68,0,119,.LLM61-.LLFBB4> > .LLM61:> > ldx [%fp+2175], %g1> > brz %g1, .LL26> > nop> > ldx [%fp+2175], %g1> > ldx [%g1], %g1 bus error here? yes, probably this one> > cmp %g1, -1> > be %xcc, .LL27> > nop> > .LL26:> > ldx [%fp+2175], %g1> > brz %g1, .LL33> > nop> > .LL27:> > line 120> > .stabn 68,0,120,.LLM62-.LLFBB4> > .LLM62:> > ldx [%fp+2175], %g1> > stx %g1, [%fp+2007]> > ldx [%fp+2007], %g1> > brz %g1, .LL30> > nop> > ldx [%fp+2007], %g1> > ldx [%g1], %g1 or here ?> > cmp %g1, -1> > bne %xcc, .LL30> > nop> > ldx [%fp+2007], %g1> > add %g1, 16, %g1> > ldx [%g1], %g1 or here?> > stx %g1, [%fp+2015]> > ldx [%fp+2007], %g1> > add %g1, 8, %g1> > ldx [%g1], %g1> > stx %g1, [%fp+2007]> > .LL30:> > ldx [%fp+2007], %g1> > ldx [%fp+2015], %g5> > mov 0, %o0> > call %g1, 0> > nop> > mov %o0, %g1> > stx %g1, [%fp+2023]> > ldx [%fp+2023], %g1> > stx %g1, [%fp+1999]> > > > line 121> > > > .stabn 68,0,121,.LLM63-.LLFBB4> > .LLM63:> > ldx [%fp+1999], %g1> > brz %g1, .LL33> > nop> > .LL32:> > .stabn 68,0,122,.LLM64-.LLFBB4> > .LLM64:> > > > g1 points to RTSignal_I3> > > > (gdb) x/i $pc> > 0x3ff0a8 : ldx [ %g1 ], %g1> > (gdb) x/i $g1> > 0x4021f4 : save %sp, -208, %sp> > > > I am willing to accept that a "function pointer" is a pair of> > pointers, or even three pointers.> > A pointer to code, a pointer to globals for position independent> > code, a frame pointer to locals.> > That equality comparison of function pointers requires comparing two> > (or three) pointers.> > (Though the global pointer shouldn't need comparing.)> > At least for nested functions. Less so for non-nested. ?> > Much less for comparison to NIL. ?> > > > And either way, this code is reading bogus data.> > There isn't a pointer at the function address, there is code.> > > > Something doesn't add up.> > > > I'm going to try setting "aligned procedures" but that's quite bogus> > I think.> > > > EqualExpr.m3 says> > > > Note: procedures pointers are always aligned!> > > > but maybe not?> > > > Yeah yeah I'm being lazy. I'll read more code..> > > > I also wonder if a "function pointer" can be optimized for the case> > of not being to a nested function.> > It looks like calling a function pointer is very inefficient.> > It looks like..am I reading that correctly?.. that if the pointer> > points to -1, then it is nested and> > a pair of pointers, and not otherwise. That -1 is treated specially> > as the first bytes of a function?> > Is that a Modula-3-ism or a SPARC-ism?> > It looks like a Modula-3-ism. And it seems dubious.> > But I'll have to read more..> > > > NT386GNU does the same sort of wrong looking thing:> > > > LFBB4:> > pushl %ebp> > movl %esp, %ebp> > subl $24, %esp> > LBB5:> > .stabn 68,0,117,LM60-LFBB4> > LM60:> > movl $0, -16(%ebp)> > .stabn 68,0,119,LM61-LFBB4> > LM61:> > movl 8(%ebp), %eax> > testl %eax, %eax> > je L26> > movl 8(%ebp), %eax> > movl (%eax), %eax BAD> > cmpl $-1, %eax BAD> > je L27> > L26:> > movl 8(%ebp), %eax> > testl %eax, %eax> > je L33> > L27:> > .stabn 68,0,120,LM62-LFBB4> > LM62:> > > > > > and NT386:> > > > 0:000> u> > cm3!RTLinker__AddUnit:> > 00607864 55 push ebp> > 00607865 8bec mov ebp,esp> > 00607867 81ec0c000000 sub esp,0Ch> > 0060786d 53 push ebx> > 0060786e 56 push esi> > 0060786f 57 push edi> > 00607870 c745fc00000000 mov dword ptr [ebp-4],0> > 00607877 837d0800 cmp dword ptr [ebp+8],0> > 0:000> u> > cm3!RTLinker__AddUnit+0x17:> > 0060787b 0f840f000000 je cm3!RTLinker__AddUnit+0x2c (00607890)> > 00607881 8b7508 mov esi,dword ptr [ebp+8]> > 00607884 8b5e00 mov ebx,dword ptr> > [esi] BAD > > 00607887 83fbff cmp > > ebx,0FFFFFFFFh BAD> > 0060788a 0f840f000000 je cm3!RTLinker__AddUnit+0x3b (0060789f)> > 00607890 837d0800 cmp dword ptr [ebp+8],0> > 00607894 0f8505000000 jne cm3!RTLinker__AddUnit+0x3b (0060789f)> > 0060789a e969000000 jmp cm3!RTLinker__AddUnit+0xa4 (00607908)> > > > cm3!RTLinker__AddUnit+0x20:> > 00607884 8b5e00 mov ebx,dword ptr [esi] > > ds:002b:0062c950=81ec8b55> > 0:000> u @esi> > cm3!RTLinker_I3:> > 0062c950 55 push ebp> > 0062c951 8bec mov ebp,esp> > 0062c953 81ec00000000 sub esp,0> > 0062c959 53 push ebx> > 0062c95a 56 push esi> > 0062c95b 57 push edi> > 0062c95c 837d0800 cmp dword ptr [ebp+8],0> > 0062c960 0f8400000000 je cm3!RTLinker_I3+0x16 (0062c966)> > > > This is just wrong.> > Comparing bytes of code to -1.> > > > I think the likely fix is for the "I3" code to be laid out as a> > "constant function pointer", a pointer to a pair of pointers where> > one points to the code and one is to -1. Something like that. That> > can't be quite correct given that the existing data is callable.> > > > - Jay> > -- > -------------------------------------------------------------> Rodney M. Bates, retired assistant professor> Dept. of Computer Science, Wichita State University> Wichita, KS 67260-0083> 316-978-3922> rodney.bates at wichita.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From hosking at cs.purdue.edu  Mon May 26 15:35:17 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 26 May 2008 14:35:17 +0100
Subject: [M3devel] function pointers and comparison to nil? mis-typed
	function pointers?
In-Reply-To: <483A3377.7070801@wichita.edu>
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
Message-ID: <3A6D6696-338C-4DB3-80B0-1F6EE2021E49@cs.purdue.edu>

Great summary Rodney.

Plus, trampolines typically require executable code on the stack which  
is disallowed by some OSs.

On May 26, 2008, at 4:50 AM, Rodney M. Bates wrote:

> I think I can shed some light on this, having spent some time making
> m3gdb handle the various operations on nested procedures.  As for code
> that mixes M3 and C, I believe the following are true:
>
> - Within M3 code only, the closure system works correctly in all  
> cases.
>  This answers one of Jay's worries.
>
> - For values of M3 procedure/C function pointer that are top-level
>  (nonnested) procedures/functions, M3 and C code (generated by gcc,
>  at least) are interchangeable.  This answers another of Jay's  
> worries.
>  This will cover that great majority of cases.
>
> - Standard C has no nested functions.  Gcc adds them as a language
>  extension.  Thus, only in gcc-compiled C code do we need to worry
>  about nested procedures/functions between languages.  (Do any other
>  C compilers exist that also have nested functions?)
>
> - M3 code should be able to call the value of a procedure variable
>  that was originally produced by C code as a pointer to a nested
>  function, and get the environment set up right, so its nonlocal
>  variable references will work, _if_ the nested function's
>  environment has not disappeared.  This partially answers another
>  of Jay's worries.  But:
>
> - M3's normal runtime check that precludes assigning a nonlocal
>  procedure value will not detect a C-code-produced nonlocal value,
>  thus the environment could indeed have disappeared if the programmer
>  was not careful.  However, gcc-extended C's nested functions have
>  no protection against this bug when only C code is involved, so
>  perhaps not detecting it in mixed M3/C is to be expected.
>
> - C code that attempts to call a function pointer value that was
>  originally produced by M3 code as a nested procedure value will
>  almost certainly crash at the time of the call.  This is the only
>  case that presents a significant problem.  M3 code will not be
>  able to give a nested procedure as a callback to a C library.
>
> M3's mechanism:  A value of procedure type is a pointer to either
> 1) the first byte of the procedure's machine code, if it is top  
> level, or
> 2) A closure.
>
> A closure is a block of 3 words.  The first word contains -1.   
> Assuming
> a word of all one bits is not valid machine code on any target machine
> (or at least doesn't occur as the first code of any procedure), this  
> can
> be used at runtime to detect that this is indeed a closure and not  
> code.
> The remaining two words hold the code address and the environment  
> address.
>
> So, an assignment of a procedure value has to check that it is not a  
> closure,
> and raise a runtime error if it is.  A call on a procedure value has  
> to check,
> and if it is a closure, load/copy its environment pointer value into  
> wherever
> the calling convention expects it, then branch to the code address.   
> Passing
> a nested procedure constant as a parameter involves constructing a  
> closure for
> it and passing its address.
>
> gcc-C's mechanism:  A value of type pointer to function is a pointer  
> to either
> 1) the first byte of the function's machine code, if it is top level,
>   (the same as with M3), or
> 2) A trampoline.
>
> A trampoline is a bit of code that loads/copies an environment  
> pointer (hard
> coded into the trampoline) and then branches to the function code.
>
> Trampolines probably have a small constant-time speed advantage for  
> _calls_,
> but would be slower for some of the other operations, and the  
> runtime check
> could be tricky.  Probably it could be fooled into failing when it  
> shouldn't.
> Moreover, trampolines are highly target-machine-dependent.   
> Switching to them
> would create a really big problem for m3gdb, which would have to have
> different code for each target for each of the nested procedure  
> operations.
>
> Jay wrote:
>> I see somewhat.
>> It's stuff around "closure".
>> The comparison of code bytes to -1 comes from If_closure for example.
>> The problem is presumably to come up with a unified representation  
>> of pointers to functions that may or may not be nested, while  
>> avoiding runtime codegen, even just a little bit, and for Modula-3  
>> and C function pointers to use the same representation.
>> I don't think the present solution is really valid, and I am  
>> skeptical that there is a solution.
>> One of the requirements has to be dropped.
>> Sniffing code bytes and trying to decide if they are code or not as  
>> appears to currently happen is bogus.
>> I think the solution is to remove the requirement that a Modula-3  
>> function pointer and a C function pointer are the same.
>> Except, well, that probably doesn't work -- it means you need two  
>> types of function pointers.
>> Darn this is a hard problem.
>> The runtime codegen required can be exceedingly simple, fast, and  
>> small IF it were allowed to be on the stack. But that's a killer  
>> these days.
>> I think you have to give up unification of "closures" and "function  
>> pointers".
>> If you take the address of a nested function and call it, you  
>> cannot access the locals of the enclosing scopes.
>> So in affect, you end up with "two types of function pointers".
>> Regular stateless ones and "closures" with some captured state.
>> Thoughts?
>> I'm kind of stumped. It's a desirable problem to solve, and there  
>> is a purported solution in place, but the solution that is there is  
>> completely bogus, despite appearing to work for a long time, and  
>> there is no solution. That is my understanding. I could be wrong on  
>> any number of points but I'm pretty sure.
>> I think you have to separate out function pointers and closures.
>> Sniffing what it pointed to is dubous esp. as currently implemented.
>> If this is really the way to go, then signature bytes need to be  
>> worked out for all architectures that are guaranteed to not look  
>> like code.
>> Or vice versa -- signature bytes worked out that all functions  
>> start with, which is viable for Modula-3 but not for interop with C.
>> Currently -1 is used, of pointer-size.
>> That appears to be reasonable for x86:
>> 0:000> eb . ff ff ff ff
>> 0:000> u .
>> ntdll32!DbgBreakPoint:
>> 7d61002d ff              ???
>> 7d61002e ff              ???
>> 7d61002f ff              ???
>> 7d610030 ffc3            inc     ebx
>> but the instruction encodings or disassembly on other architectures  
>> would have to be checked.
>>  - Jay
>>     
>> ------------------------------------------------------------------------
>>    From: jayk123 at hotmail.com
>>    To: m3devel at elegosoft.com
>>    Date: Sun, 25 May 2008 00:16:01 +0000
>>    Subject: [M3devel] function pointers and comparison to nil?
>>    mis-typed function pointers?
>>    I'm being lazy...
>>    Tony can you explain this stuff?
>>    Comparison of function pointers..
>>    What are the various representations and rules?
>>    What does it mean to compare nested functions?
>>    What does it mean to compare a function to NIL?
>>    I'll poke around more.
>>    What I am seeing is that comparison of function pointers to NIL is
>>    surprisingly
>>    expensive, and probably somewhat buggy. Or at least some of the  
>> runtime
>>    generated "metadata-ish" stuff is produced or typed incorrectly.
>>    In particular, RTLinker.m3:
>>    PROCEDURE AddUnit (b: RT0.Binder) =
>>      VAR m: RT0.ModulePtr;
>>      BEGIN
>>        IF (b = NIL) THEN RETURN END;   line 119
>>        m := b(0);                      line 120
>>        IF (m = NIL) THEN RETURN END;   line 121
>>        AddUnitI(m);                    line 122
>>      END AddUnit;
>>    generates a lot of code, just for the first line:
>>      (556) set_source_line         source line  119       (557)  
>> load         m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb ->  
>> 0xb       (558) load_nil       (559) if_eq       (560) load          
>> m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb       (561)  
>> load_indirect         load address offset 0x0 src_t 0x5 dst_t  
>> 0x5       (562) load_integer         integer n_bytes 0x0 hi 0x0 low  
>> 0x1 sign -1       (563) if_eq       (564) set_label       (565)  
>> load_nil       (566) load         m3cg_load (M3_DjPxE5_b): offset  
>> 0x0, convert 0xb -> 0xb       (567) if_ne       (568)  
>> set_label       (569) exit_proc       (570) set_label       (571)  
>> set_source_line         source line  120     The details on the  
>> load_integer trace might not be completely
>>    correct. I will test a fix shortly.
>>    Esp. that n_bytes gets decremented to zero before the trace.
>>    Ok, I see now why some of the bloat -- because the "then return  
>> end"
>>    is on the same line.
>>    If it were written as:
>>      if (b = NIL THEN         return
>>      end      It probably wouldn't look so bad. That took me a  
>> while to realize.
>>    The following is generated for SPARC64_OPENBSD:
>>          line 119
>>     .stabn 68,0,119,.LLM61-.LLFBB4
>>    .LLM61:
>>     ldx [%fp+2175], %g1
>>     brz %g1, .LL26
>>      nop
>>     ldx [%fp+2175], %g1
>>     ldx [%g1], %g1            bus error here? yes, probably this one
>>     cmp %g1, -1
>>     be %xcc, .LL27
>>      nop
>>    .LL26:
>>     ldx [%fp+2175], %g1
>>     brz %g1, .LL33
>>      nop
>>    .LL27:
>>     line 120
>>     .stabn 68,0,120,.LLM62-.LLFBB4
>>    .LLM62:
>>     ldx [%fp+2175], %g1
>>     stx %g1, [%fp+2007]
>>     ldx [%fp+2007], %g1
>>     brz %g1, .LL30
>>      nop
>>     ldx [%fp+2007], %g1
>>     ldx [%g1], %g1            or here ?
>>     cmp %g1, -1
>>     bne %xcc, .LL30
>>      nop
>>     ldx [%fp+2007], %g1
>>     add %g1, 16, %g1
>>     ldx [%g1], %g1           or here?
>>     stx %g1, [%fp+2015]
>>     ldx [%fp+2007], %g1
>>     add %g1, 8, %g1
>>     ldx [%g1], %g1
>>     stx %g1, [%fp+2007]
>>    .LL30:
>>     ldx [%fp+2007], %g1
>>     ldx [%fp+2015], %g5
>>     mov 0, %o0
>>     call %g1, 0
>>      nop
>>     mov %o0, %g1
>>     stx %g1, [%fp+2023]
>>     ldx [%fp+2023], %g1
>>     stx %g1, [%fp+1999]
>>          line 121
>>     .stabn 68,0,121,.LLM63-.LLFBB4
>>    .LLM63:
>>     ldx [%fp+1999], %g1
>>     brz %g1, .LL33
>>      nop
>>    .LL32:
>>     .stabn 68,0,122,.LLM64-.LLFBB4
>>    .LLM64:
>>    g1 points to RTSignal_I3
>>    (gdb) x/i $pc
>>    0x3ff0a8 :        ldx  [ %g1 ], %g1
>>    (gdb) x/i $g1
>>    0x4021f4 : save  %sp, -208, %sp
>>    I am willing to accept that a "function pointer" is a pair of
>>    pointers, or even three pointers.
>>    A pointer to code, a pointer to globals for position independent
>>    code, a frame pointer to locals.
>>    That equality comparison of function pointers requires comparing  
>> two
>>    (or three) pointers.
>>      (Though the global pointer shouldn't need comparing.)
>>    At least for nested functions. Less so for non-nested. ?
>>    Much less for comparison to NIL. ?
>>    And either way, this code is reading bogus data.
>>    There isn't a pointer at the function address, there is code.
>>    Something doesn't add up.
>>    I'm going to try setting "aligned procedures" but that's quite  
>> bogus
>>    I think.
>>    EqualExpr.m3 says
>>           Note: procedures pointers are always aligned!
>>    but maybe not?
>>    Yeah yeah I'm being lazy. I'll read more code..
>>    I also wonder if a "function pointer" can be optimized for the  
>> case
>>    of not being to a nested function.
>>    It looks like calling a function pointer is very inefficient.
>>    It looks like..am I reading that correctly?.. that if the pointer
>>    points to -1, then it is nested and
>>    a pair of pointers, and not otherwise. That -1 is treated  
>> specially
>>    as the first bytes of a function?
>>    Is that a Modula-3-ism or a SPARC-ism?
>>    It looks like a Modula-3-ism. And it seems dubious.
>>    But I'll have to read more..
>>         NT386GNU does the same sort of wrong looking thing:
>>         LFBB4:
>>     pushl %ebp
>>     movl %esp, %ebp
>>     subl $24, %esp
>>    LBB5:
>>     .stabn 68,0,117,LM60-LFBB4
>>    LM60:
>>     movl $0, -16(%ebp)
>>     .stabn 68,0,119,LM61-LFBB4
>>    LM61:
>>     movl 8(%ebp), %eax
>>     testl %eax, %eax
>>     je L26
>>     movl 8(%ebp), %eax
>>     movl (%eax), %eax                  BAD
>>     cmpl $-1, %eax                       BAD
>>     je L27
>>    L26:
>>     movl 8(%ebp), %eax
>>     testl %eax, %eax
>>     je L33
>>    L27:
>>     .stabn 68,0,120,LM62-LFBB4
>>    LM62:
>>         and NT386:
>>         0:000> u
>>    cm3!RTLinker__AddUnit:
>>    00607864 55              push    ebp
>>    00607865 8bec            mov     ebp,esp
>>    00607867 81ec0c000000    sub     esp,0Ch
>>    0060786d 53              push    ebx
>>    0060786e 56              push    esi
>>    0060786f 57              push    edi
>>    00607870 c745fc00000000  mov     dword ptr [ebp-4],0
>>    00607877 837d0800        cmp     dword ptr [ebp+8],0
>>    0:000> u
>>    cm3!RTLinker__AddUnit+0x17:
>>    0060787b 0f840f000000    je      cm3!RTLinker__AddUnit+0x2c  
>> (00607890)
>>    00607881 8b7508          mov     esi,dword ptr [ebp+8]
>>    00607884 8b5e00          mov     ebx,dword ptr
>>    [esi]                            BAD     00607887  
>> 83fbff          cmp        ebx, 
>> 0FFFFFFFFh                                  BAD
>>    0060788a 0f840f000000    je      cm3!RTLinker__AddUnit+0x3b  
>> (0060789f)
>>    00607890 837d0800        cmp     dword ptr [ebp+8],0
>>    00607894 0f8505000000    jne     cm3!RTLinker__AddUnit+0x3b  
>> (0060789f)
>>    0060789a e969000000      jmp     cm3!RTLinker__AddUnit+0xa4  
>> (00607908)
>>         cm3!RTLinker__AddUnit+0x20:
>>    00607884 8b5e00          mov     ebx,dword ptr [esi]     ds:002b: 
>> 0062c950=81ec8b55
>>    0:000> u @esi
>>    cm3!RTLinker_I3:
>>    0062c950 55              push    ebp
>>    0062c951 8bec            mov     ebp,esp
>>    0062c953 81ec00000000    sub     esp,0
>>    0062c959 53              push    ebx
>>    0062c95a 56              push    esi
>>    0062c95b 57              push    edi
>>    0062c95c 837d0800        cmp     dword ptr [ebp+8],0
>>    0062c960 0f8400000000    je      cm3!RTLinker_I3+0x16 (0062c966)
>>         This is just wrong.
>>    Comparing bytes of code to -1.
>>         I think the likely fix is for the "I3" code to be laid out  
>> as a
>>    "constant function pointer", a pointer to a pair of pointers where
>>    one points to the code and one is to -1. Something like that. That
>>    can't be quite correct given that the existing data is callable.
>>      - Jay
>
> -- 
> -------------------------------------------------------------
> Rodney M. Bates, retired assistant professor
> Dept. of Computer Science, Wichita State University
> Wichita, KS 67260-0083
> 316-978-3922
> rodney.bates at wichita.edu



From hosking at cs.purdue.edu  Mon May 26 15:38:53 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 26 May 2008 14:38:53 +0100
Subject: [M3devel] function pointers and comparison to nil? mis-typed
	function pointers?
In-Reply-To: 
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
	
	
Message-ID: 

Moving away from the current implementation would be a portability  
disaster because of the fact that gcc requires an executable stack for  
its nested function implementation which is non-portable.

On May 26, 2008, at 11:04 AM, Jay wrote:

> Cygwin gcc clearly generates code on the stack for nested functions.
> And then search the web..that's how it works in general.
> Nested functions have been deprecated on Mac OS X, in anticipation  
> of possibly making the stack not executable.
>
> OpenBSD doesn't allow execution on the stack.
> They use mprotect to let trampolines run:
>   http://gcc.gnu.org/ml/gcc/2004-01/msg00742.html
> and
>   http://resin.csoft.net/cgi-bin/man.cgi?section=1&topic=gcc-local
>
> Even though nested functions are a gcc extension to the C language,  
> email threads out there discuss Ada, Pascal, and even ! Modula-3 as  
> having nested functions, and that therefore deprecating the C  
> language feature doesn't "solve" the "problem".
>
> I remain uncertain what, if anything, to do here.
>  - keep the -1 hack, do nothing
>     generalize it slightly to let targets pick "better" markers
>  - use gcc's supported for nested functions
>    (plus the integrated backend, not difficult)
>
> Clearly this is a dilemna to more than just me. :)
>
>  - Jay
> From: jayk123 at hotmail.com
> To: rodney.bates at wichita.edu; m3devel at elegosoft.com
> Date: Mon, 26 May 2008 05:26:41 +0000
> Subject: Re: [M3devel] function pointers and comparison to nil? mis- 
> typed function pointers?
>
> Rodney, this agrees with much of what I figured out and guessed. I  
> did not think of or look into some of what you point out though:
>   - what gcc's nested functions look like, and if you can take the  
> address, and what that does
>   - calling Modula-3 nested functions as callbacks from C
>
> Now, regarding trampolines.
> I alluded to them. It should be easy enough to generate them, and  
> this would solve a few problems, but I believe also bring up a new  
> big problem.
> Generating trampolines solves at least two problems:
>  - it allows Modula-3 nested function pointers ("closures") to be  
> called from C
>  - it enables removing the check for -1
>
> I contend that the check for -1 is not good. It is a somewhat risky  
> assumption, that "-1" is not valid code.
> You do bring up a nice mitigation -- the assumption that it doesn't  
> begin any functions, which is much narrower than it being valid code  
> anywhere.
>
> For SPARC64_OPENBSD I figured out what the original authors meant to  
> be the fix.
> You declare functions as not aligned, leading to the check for -1  
> first checking alignment (bigger code).
> Any pointer not aligned on an integer-sized address is presumed not  
> a closure and not checked for the -1.
> This lets SPARC64_OPENBSD get further. Both it and PPC32_OPENBSD now  
> for some reason suffer from an inability to heap allocate anything,  
> failing around the attempt to create a new thread like in  
> RTAllocator_M or so. I'll look into this more later.
>
> Now, the problem of trampolines..I consider the platform-dependent- 
> ness to be surmountable.
> But where do you put the generated code? Putting it on the stack is  
> counter to modern (and possibly old) "security" mechanisms.
> The stack is not generally executable, and even when it is, best  
> just not do use that imho.
>
> That means, potentially/obviously, the need to heap allocate  
> executable memory, for very small short lived data, quite inefficient.
>
> Is there some other way/place to produce trampolines, efficiently?
>
> In the absence of any good solution, I have to resign myself to  
> assuming that -1 isn't the valid start of a function, and perhaps  
> moving the marker into Target.i3, Target.m3 so that "more obvious"  
> values get chosen. Like a breakpoint. Or "an epilogue", or "a trap  
> instruction". I realize this needs details and is easily seen as  
> "wrong". In particular, a function that does nothing could be termed  
> as only having an "an epilogue".
>
> I know that other systems are "forced" to create "trampolines" so I  
> should look into how they do that.
> I know that ATL, a Windows-specific library, is forced to heap  
> allocate small executable chunks of memory and uses an efficient  
> cache to optimize it.
>
> I do find this dependence on -1 not being the valid start of a  
> function rather sleazy and at risk of being wrong.
>
>  - Jay
>
>
>
>
> > Date: Sun, 25 May 2008 22:50:15 -0500
> > From: rodney.bates at wichita.edu
> > To: m3devel at elegosoft.com
> > Subject: Re: [M3devel] function pointers and comparison to nil?  
> mis-typed function pointers?
> >
> > I think I can shed some light on this, having spent some time making
> > m3gdb handle the various operations on nested procedures. As for  
> code
> > that mixes M3 and C, I believe the following are true:
> >
> > - Within M3 code only, the closure system works correctly in all  
> cases.
> > This answers one of Jay's worries.
> >
> > - For values of M3 procedure/C function pointer that are top-level
> > (nonnested) procedures/functions, M3 and C code (generated by gcc,
> > at least) are interchangeable. This answers another of Jay's  
> worries.
> > This will cover that great majority of cases.
> >
> > - Standard C has no nested functions. Gcc adds them as a language
> > extension. Thus, only in gcc-compiled C code do we need to worry
> > about nested procedures/functions between languages. (Do any other
> > C compilers exist that also have nested functions?)
> >
> > - M3 code should be able to call the value of a procedure variable
> > that was originally produced by C code as a pointer to a nested
> > function, and get the environment set up right, so its nonlocal
> > variable references will work, _if_ the nested function's
> > environment has not disappeared. This partially answers another
> > of Jay's worries. But:
> >
> > - M3's normal runtime check that precludes assigning a nonlocal
> > procedure value will not detect a C-code-produced nonlocal value,
> > thus the environment could indeed have disappeared if the programmer
> > was not careful. However, gcc-extended C's nested functions have
> > no protection against this bug when only C code is involved, so
> > perhaps not detecting it in mixed M3/C is to be expected.
> >
> > - C code that attempts to call a function pointer value that was
> > originally produced by M3 code as a nested procedure value will
> > almost certainly crash at the time of the call. This is the only
> > case that presents a significant problem. M3 code will not be
> > able to give a nested procedure as a callback to a C library.
> >
> > M3's mechanism: A value of procedure type is a pointer to either
> > 1) the first byte of the procedure's machine code, if it is top  
> level, or
> > 2) A closure.
> >
> > A closure is a block of 3 words. The first word contains -1.  
> Assuming
> > a word of all one bits is not valid machine code on any target  
> machine
> > (or at least doesn't occur as the first code of any procedure),  
> this can
> > be used at runtime to detect that this is indeed a closure and not  
> code.
> > The remaining two words hold the code address and the environment  
> address.
> >
> > So, an assignment of a procedure value has to check that it is not  
> a closure,
> > and raise a runtime error if it is. A call on a procedure value  
> has to check,
> > and if it is a closure, load/copy its environment pointer value  
> into wherever
> > the calling convention expects it, then branch to the code  
> address. Passing
> > a nested procedure constant as a parameter involves constructing a  
> closure for
> > it and passing its address.
> >
> > gcc-C's mechanism: A value of type pointer to function is a  
> pointer to either
> > 1) the first byte of the function's machine code, if it is top  
> level,
> > (the same as with M3), or
> > 2) A trampoline.
> >
> > A trampoline is a bit of code that loads/copies an environment  
> pointer (hard
> > coded into the trampoline) and then branches to the function code.
> >
> > Trampolines probably have a small constant-time speed advantage  
> for _calls_,
> > but would be slower for some of the other operations, and the  
> runtime check
> > could be tricky. Probably it could be fooled into failing when it  
> shouldn't.
> > Moreover, trampolines are highly target-machine-dependent.  
> Switching to them
> > would create a really big problem for m3gdb, which would have to  
> have
> > different code for each target for each of the nested procedure  
> operations.
> >
> > Jay wrote:
> > > I see somewhat.
> > > It's stuff around "closure".
> > > The comparison of code bytes to -1 comes from If_closure for  
> example.
> > >
> > > The problem is presumably to come up with a unified  
> representation of
> > > pointers to functions that may or may not be nested, while  
> avoiding
> > > runtime codegen, even just a little bit, and for Modula-3 and C  
> function
> > > pointers to use the same representation.
> > > I don't think the present solution is really valid, and I am  
> skeptical
> > > that there is a solution.
> > > One of the requirements has to be dropped.
> > > Sniffing code bytes and trying to decide if they are code or not  
> as
> > > appears to currently happen is bogus.
> > >
> > > I think the solution is to remove the requirement that a Modula-3
> > > function pointer and a C function pointer are the same.
> > > Except, well, that probably doesn't work -- it means you need  
> two types
> > > of function pointers.
> > >
> > > Darn this is a hard problem.
> > >
> > > The runtime codegen required can be exceedingly simple, fast,  
> and small
> > > IF it were allowed to be on the stack. But that's a killer these  
> days.
> > >
> > > I think you have to give up unification of "closures" and  
> "function
> > > pointers".
> > > If you take the address of a nested function and call it, you  
> cannot
> > > access the locals of the enclosing scopes.
> > > So in affect, you end up with "two types of function pointers".
> > > Regular stateless ones and "closures" with some captured state.
> > >
> > > Thoughts?
> > >
> > > I'm kind of stumped. It's a desirable problem to solve, and  
> there is a
> > > purported solution in place, but the solution that is there is
> > > completely bogus, despite appearing to work for a long time, and  
> there
> > > is no solution. That is my understanding. I could be wrong on  
> any number
> > > of points but I'm pretty sure.
> > >
> > > I think you have to separate out function pointers and closures.
> > > Sniffing what it pointed to is dubous esp. as currently  
> implemented.
> > > If this is really the way to go, then signature bytes need to be  
> worked
> > > out for all architectures that are guaranteed to not look like  
> code.
> > > Or vice versa -- signature bytes worked out that all functions  
> start
> > > with, which is viable for Modula-3 but not for interop with C.
> > > Currently -1 is used, of pointer-size.
> > > That appears to be reasonable for x86:
> > >
> > > 0:000> eb . ff ff ff ff
> > > 0:000> u .
> > > ntdll32!DbgBreakPoint:
> > > 7d61002d ff ???
> > > 7d61002e ff ???
> > > 7d61002f ff ???
> > > 7d610030 ffc3 inc ebx
> > >
> > > but the instruction encodings or disassembly on other  
> architectures
> > > would have to be checked.
> > >
> > > - Jay
> > >
> > >  
> ------------------------------------------------------------------------
> > > From: jayk123 at hotmail.com
> > > To: m3devel at elegosoft.com
> > > Date: Sun, 25 May 2008 00:16:01 +0000
> > > Subject: [M3devel] function pointers and comparison to nil?
> > > mis-typed function pointers?
> > >
> > > I'm being lazy...
> > >
> > > Tony can you explain this stuff?
> > >
> > > Comparison of function pointers..
> > > What are the various representations and rules?
> > >
> > > What does it mean to compare nested functions?
> > >
> > > What does it mean to compare a function to NIL?
> > >
> > > I'll poke around more.
> > >
> > > What I am seeing is that comparison of function pointers to NIL is
> > > surprisingly
> > > expensive, and probably somewhat buggy. Or at least some of the  
> runtime
> > > generated "metadata-ish" stuff is produced or typed incorrectly.
> > >
> > > In particular, RTLinker.m3:
> > >
> > > PROCEDURE AddUnit (b: RT0.Binder) =
> > > VAR m: RT0.ModulePtr;
> > > BEGIN
> > > IF (b = NIL) THEN RETURN END; line 119
> > > m := b(0); line 120
> > > IF (m = NIL) THEN RETURN END; line 121
> > > AddUnitI(m); line 122
> > > END AddUnit;
> > >
> > > generates a lot of code, just for the first line:
> > > (556) set_source_line
> > > source line 119
> > > (557) load
> > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb
> > > (558) load_nil
> > > (559) if_eq
> > > (560) load
> > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb
> > > (561) load_indirect
> > > load address offset 0x0 src_t 0x5 dst_t 0x5
> > > (562) load_integer
> > > integer n_bytes 0x0 hi 0x0 low 0x1 sign -1
> > > (563) if_eq
> > > (564) set_label
> > > (565) load_nil
> > > (566) load
> > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb
> > > (567) if_ne
> > > (568) set_label
> > > (569) exit_proc
> > > (570) set_label
> > > (571) set_source_line
> > > source line 120
> > >
> > > The details on the load_integer trace might not be completely
> > > correct. I will test a fix shortly.
> > > Esp. that n_bytes gets decremented to zero before the trace.
> > >
> > > Ok, I see now why some of the bloat -- because the "then return  
> end"
> > > is on the same line.
> > > If it were written as:
> > > if (b = NIL THEN
> > > return
> > > end
> > > It probably wouldn't look so bad. That took me a while to realize.
> > >
> > > The following is generated for SPARC64_OPENBSD:
> > >
> > > line 119
> > > .stabn 68,0,119,.LLM61-.LLFBB4
> > > .LLM61:
> > > ldx [%fp+2175], %g1
> > > brz %g1, .LL26
> > > nop
> > > ldx [%fp+2175], %g1
> > > ldx [%g1], %g1 bus error here? yes, probably this one
> > > cmp %g1, -1
> > > be %xcc, .LL27
> > > nop
> > > .LL26:
> > > ldx [%fp+2175], %g1
> > > brz %g1, .LL33
> > > nop
> > > .LL27:
> > > line 120
> > > .stabn 68,0,120,.LLM62-.LLFBB4
> > > .LLM62:
> > > ldx [%fp+2175], %g1
> > > stx %g1, [%fp+2007]
> > > ldx [%fp+2007], %g1
> > > brz %g1, .LL30
> > > nop
> > > ldx [%fp+2007], %g1
> > > ldx [%g1], %g1 or here ?
> > > cmp %g1, -1
> > > bne %xcc, .LL30
> > > nop
> > > ldx [%fp+2007], %g1
> > > add %g1, 16, %g1
> > > ldx [%g1], %g1 or here?
> > > stx %g1, [%fp+2015]
> > > ldx [%fp+2007], %g1
> > > add %g1, 8, %g1
> > > ldx [%g1], %g1
> > > stx %g1, [%fp+2007]
> > > .LL30:
> > > ldx [%fp+2007], %g1
> > > ldx [%fp+2015], %g5
> > > mov 0, %o0
> > > call %g1, 0
> > > nop
> > > mov %o0, %g1
> > > stx %g1, [%fp+2023]
> > > ldx [%fp+2023], %g1
> > > stx %g1, [%fp+1999]
> > >
> > > line 121
> > >
> > > .stabn 68,0,121,.LLM63-.LLFBB4
> > > .LLM63:
> > > ldx [%fp+1999], %g1
> > > brz %g1, .LL33
> > > nop
> > > .LL32:
> > > .stabn 68,0,122,.LLM64-.LLFBB4
> > > .LLM64:
> > >
> > > g1 points to RTSignal_I3
> > >
> > > (gdb) x/i $pc
> > > 0x3ff0a8 : ldx [ %g1 ], %g1
> > > (gdb) x/i $g1
> > > 0x4021f4 : save %sp, -208, %sp
> > >
> > > I am willing to accept that a "function pointer" is a pair of
> > > pointers, or even three pointers.
> > > A pointer to code, a pointer to globals for position independent
> > > code, a frame pointer to locals.
> > > That equality comparison of function pointers requires comparing  
> two
> > > (or three) pointers.
> > > (Though the global pointer shouldn't need comparing.)
> > > At least for nested functions. Less so for non-nested. ?
> > > Much less for comparison to NIL. ?
> > >
> > > And either way, this code is reading bogus data.
> > > There isn't a pointer at the function address, there is code.
> > >
> > > Something doesn't add up.
> > >
> > > I'm going to try setting "aligned procedures" but that's quite  
> bogus
> > > I think.
> > >
> > > EqualExpr.m3 says
> > >
> > > Note: procedures pointers are always aligned!
> > >
> > > but maybe not?
> > >
> > > Yeah yeah I'm being lazy. I'll read more code..
> > >
> > > I also wonder if a "function pointer" can be optimized for the  
> case
> > > of not being to a nested function.
> > > It looks like calling a function pointer is very inefficient.
> > > It looks like..am I reading that correctly?.. that if the pointer
> > > points to -1, then it is nested and
> > > a pair of pointers, and not otherwise. That -1 is treated  
> specially
> > > as the first bytes of a function?
> > > Is that a Modula-3-ism or a SPARC-ism?
> > > It looks like a Modula-3-ism. And it seems dubious.
> > > But I'll have to read more..
> > >
> > > NT386GNU does the same sort of wrong looking thing:
> > >
> > > LFBB4:
> > > pushl %ebp
> > > movl %esp, %ebp
> > > subl $24, %esp
> > > LBB5:
> > > .stabn 68,0,117,LM60-LFBB4
> > > LM60:
> > > movl $0, -16(%ebp)
> > > .stabn 68,0,119,LM61-LFBB4
> > > LM61:
> > > movl 8(%ebp), %eax
> > > testl %eax, %eax
> > > je L26
> > > movl 8(%ebp), %eax
> > > movl (%eax), %eax BAD
> > > cmpl $-1, %eax BAD
> > > je L27
> > > L26:
> > > movl 8(%ebp), %eax
> > > testl %eax, %eax
> > > je L33
> > > L27:
> > > .stabn 68,0,120,LM62-LFBB4
> > > LM62:
> > >
> > >
> > > and NT386:
> > >
> > > 0:000> u
> > > cm3!RTLinker__AddUnit:
> > > 00607864 55 push ebp
> > > 00607865 8bec mov ebp,esp
> > > 00607867 81ec0c000000 sub esp,0Ch
> > > 0060786d 53 push ebx
> > > 0060786e 56 push esi
> > > 0060786f 57 push edi
> > > 00607870 c745fc00000000 mov dword ptr [ebp-4],0
> > > 00607877 837d0800 cmp dword ptr [ebp+8],0
> > > 0:000> u
> > > cm3!RTLinker__AddUnit+0x17:
> > > 0060787b 0f840f000000 je cm3!RTLinker__AddUnit+0x2c (00607890)
> > > 00607881 8b7508 mov esi,dword ptr [ebp+8]
> > > 00607884 8b5e00 mov ebx,dword ptr
> > > [esi] BAD
> > > 00607887 83fbff cmp
> > > ebx,0FFFFFFFFh BAD
> > > 0060788a 0f840f000000 je cm3!RTLinker__AddUnit+0x3b (0060789f)
> > > 00607890 837d0800 cmp dword ptr [ebp+8],0
> > > 00607894 0f8505000000 jne cm3!RTLinker__AddUnit+0x3b (0060789f)
> > > 0060789a e969000000 jmp cm3!RTLinker__AddUnit+0xa4 (00607908)
> > >
> > > cm3!RTLinker__AddUnit+0x20:
> > > 00607884 8b5e00 mov ebx,dword ptr [esi]
> > > ds:002b:0062c950=81ec8b55
> > > 0:000> u @esi
> > > cm3!RTLinker_I3:
> > > 0062c950 55 push ebp
> > > 0062c951 8bec mov ebp,esp
> > > 0062c953 81ec00000000 sub esp,0
> > > 0062c959 53 push ebx
> > > 0062c95a 56 push esi
> > > 0062c95b 57 push edi
> > > 0062c95c 837d0800 cmp dword ptr [ebp+8],0
> > > 0062c960 0f8400000000 je cm3!RTLinker_I3+0x16 (0062c966)
> > >
> > > This is just wrong.
> > > Comparing bytes of code to -1.
> > >
> > > I think the likely fix is for the "I3" code to be laid out as a
> > > "constant function pointer", a pointer to a pair of pointers where
> > > one points to the code and one is to -1. Something like that. That
> > > can't be quite correct given that the existing data is callable.
> > >
> > > - Jay
> >
> > --
> > -------------------------------------------------------------
> > Rodney M. Bates, retired assistant professor
> > Dept. of Computer Science, Wichita State University
> > Wichita, KS 67260-0083
> > 316-978-3922
> > rodney.bates at wichita.edu
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rcoleburn at scires.com  Mon May 26 15:54:18 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Mon, 26 May 2008 09:54:18 -0400
Subject: [M3devel] function pointers and comparison to nil?	mis-typed
	function pointers?
In-Reply-To: <483A3377.7070801@wichita.edu>
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
Message-ID: <483A88C5.1E75.00D7.1@scires.com>

I'm just "listening" here, but it would seem that much of what Rodney has stated would make for an excellent set of comments to be added to the code source file so that folks reading the code will better understand the reasoning behind what is going on.
--Randy

>>> "Rodney M. Bates"  5/25/2008 11:50 PM >>>
I think I can shed some light on this, having spent some time making
m3gdb handle the various operations on nested procedures.  As for code
that mixes M3 and C, I believe the following are true:

- Within M3 code only, the closure system works correctly in all cases.
   This answers one of Jay's worries.

- For values of M3 procedure/C function pointer that are top-level
   (nonnested) procedures/functions, M3 and C code (generated by gcc,
   at least) are interchangeable.  This answers another of Jay's worries.
   This will cover that great majority of cases.

- Standard C has no nested functions.  Gcc adds them as a language
   extension.  Thus, only in gcc-compiled C code do we need to worry
   about nested procedures/functions between languages.  (Do any other
   C compilers exist that also have nested functions?)

- M3 code should be able to call the value of a procedure variable
   that was originally produced by C code as a pointer to a nested
   function, and get the environment set up right, so its nonlocal
   variable references will work, _if_ the nested function's
   environment has not disappeared.  This partially answers another
   of Jay's worries.  But:

- M3's normal runtime check that precludes assigning a nonlocal
   procedure value will not detect a C-code-produced nonlocal value,
   thus the environment could indeed have disappeared if the programmer
   was not careful.  However, gcc-extended C's nested functions have
   no protection against this bug when only C code is involved, so
   perhaps not detecting it in mixed M3/C is to be expected.

- C code that attempts to call a function pointer value that was
   originally produced by M3 code as a nested procedure value will
   almost certainly crash at the time of the call.  This is the only
   case that presents a significant problem.  M3 code will not be
   able to give a nested procedure as a callback to a C library.

M3's mechanism:  A value of procedure type is a pointer to either
1) the first byte of the procedure's machine code, if it is top level, or
2) A closure.

A closure is a block of 3 words.  The first word contains -1.  Assuming
a word of all one bits is not valid machine code on any target machine
(or at least doesn't occur as the first code of any procedure), this can
be used at runtime to detect that this is indeed a closure and not code.
The remaining two words hold the code address and the environment address.

So, an assignment of a procedure value has to check that it is not a closure,
and raise a runtime error if it is.  A call on a procedure value has to check,
and if it is a closure, load/copy its environment pointer value into wherever
the calling convention expects it, then branch to the code address.  Passing
a nested procedure constant as a parameter involves constructing a closure for
it and passing its address.

gcc-C's mechanism:  A value of type pointer to function is a pointer to either
1) the first byte of the function's machine code, if it is top level,
    (the same as with M3), or
2) A trampoline.

A trampoline is a bit of code that loads/copies an environment pointer (hard
coded into the trampoline) and then branches to the function code.

Trampolines probably have a small constant-time speed advantage for _calls_,
but would be slower for some of the other operations, and the runtime check
could be tricky.  Probably it could be fooled into failing when it shouldn't.
Moreover, trampolines are highly target-machine-dependent.  Switching to them
would create a really big problem for m3gdb, which would have to have
different code for each target for each of the nested procedure operations.

Jay wrote:
> I see somewhat.
> It's stuff around "closure".
> The comparison of code bytes to -1 comes from If_closure for example.
>  
> The problem is presumably to come up with a unified representation of 
> pointers to functions that may or may not be nested, while avoiding 
> runtime codegen, even just a little bit, and for Modula-3 and C function 
> pointers to use the same representation.
> I don't think the present solution is really valid, and I am skeptical 
> that there is a solution.
> One of the requirements has to be dropped.
> Sniffing code bytes and trying to decide if they are code or not as 
> appears to currently happen is bogus.
>  
> I think the solution is to remove the requirement that a Modula-3 
> function pointer and a C function pointer are the same.
> Except, well, that probably doesn't work -- it means you need two types 
> of function pointers.
>  
> Darn this is a hard problem.
>  
> The runtime codegen required can be exceedingly simple, fast, and small 
> IF it were allowed to be on the stack. But that's a killer these days.
>  
> I think you have to give up unification of "closures" and "function 
> pointers".
> If you take the address of a nested function and call it, you cannot 
> access the locals of the enclosing scopes.
> So in affect, you end up with "two types of function pointers".
> Regular stateless ones and "closures" with some captured state.
>  
> Thoughts?
>  
> I'm kind of stumped. It's a desirable problem to solve, and there is a 
> purported solution in place, but the solution that is there is 
> completely bogus, despite appearing to work for a long time, and there 
> is no solution. That is my understanding. I could be wrong on any number 
> of points but I'm pretty sure.
>  
> I think you have to separate out function pointers and closures.
> Sniffing what it pointed to is dubous esp. as currently implemented.
> If this is really the way to go, then signature bytes need to be worked 
> out for all architectures that are guaranteed to not look like code.
> Or vice versa -- signature bytes worked out that all functions start 
> with, which is viable for Modula-3 but not for interop with C.
> Currently -1 is used, of pointer-size.
> That appears to be reasonable for x86:
>  
> 0:000> eb . ff ff ff ff
> 0:000> u .
> ntdll32!DbgBreakPoint:
> 7d61002d ff              ???
> 7d61002e ff              ???
> 7d61002f ff              ???
> 7d610030 ffc3            inc     ebx
>  
> but the instruction encodings or disassembly on other architectures 
> would have to be checked.
>  
>  - Jay
> 
>     ------------------------------------------------------------------------
>     From: jayk123 at hotmail.com 
>     To: m3devel at elegosoft.com 
>     Date: Sun, 25 May 2008 00:16:01 +0000
>     Subject: [M3devel] function pointers and comparison to nil?
>     mis-typed function pointers?
> 
>     I'm being lazy...
> 
>     Tony can you explain this stuff?
> 
>     Comparison of function pointers..
>     What are the various representations and rules?
> 
>     What does it mean to compare nested functions?
> 
>     What does it mean to compare a function to NIL?
> 
>     I'll poke around more.
> 
>     What I am seeing is that comparison of function pointers to NIL is
>     surprisingly
>     expensive, and probably somewhat buggy. Or at least some of the runtime
>     generated "metadata-ish" stuff is produced or typed incorrectly.
> 
>     In particular, RTLinker.m3:
> 
>     PROCEDURE AddUnit (b: RT0.Binder) =
>       VAR m: RT0.ModulePtr;
>       BEGIN
>         IF (b = NIL) THEN RETURN END;   line 119
>         m := b(0);                      line 120
>         IF (m = NIL) THEN RETURN END;   line 121
>         AddUnitI(m);                    line 122
>       END AddUnit;
> 
>     generates a lot of code, just for the first line:
>       (556) set_source_line 
>         source line  119 
>       (557) load 
>         m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb 
>       (558) load_nil 
>       (559) if_eq 
>       (560) load 
>         m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb 
>       (561) load_indirect 
>         load address offset 0x0 src_t 0x5 dst_t 0x5 
>       (562) load_integer 
>         integer n_bytes 0x0 hi 0x0 low 0x1 sign -1 
>       (563) if_eq 
>       (564) set_label 
>       (565) load_nil 
>       (566) load 
>         m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb 
>       (567) if_ne 
>       (568) set_label 
>       (569) exit_proc 
>       (570) set_label 
>       (571) set_source_line 
>         source line  120 
> 
>     The details on the load_integer trace might not be completely
>     correct. I will test a fix shortly.
>     Esp. that n_bytes gets decremented to zero before the trace.
> 
>     Ok, I see now why some of the bloat -- because the "then return end"
>     is on the same line.
>     If it were written as:
>       if (b = NIL THEN 
>         return
>       end  
>     It probably wouldn't look so bad. That took me a while to realize.
> 
>     The following is generated for SPARC64_OPENBSD:
>      
>      line 119
>      .stabn 68,0,119,.LLM61-.LLFBB4
>     .LLM61:
>      ldx [%fp+2175], %g1
>      brz %g1, .LL26
>       nop
>      ldx [%fp+2175], %g1
>      ldx [%g1], %g1            bus error here? yes, probably this one
>      cmp %g1, -1
>      be %xcc, .LL27
>       nop
>     .LL26:
>      ldx [%fp+2175], %g1
>      brz %g1, .LL33
>       nop
>     .LL27:
>      line 120
>      .stabn 68,0,120,.LLM62-.LLFBB4
>     .LLM62:
>      ldx [%fp+2175], %g1
>      stx %g1, [%fp+2007]
>      ldx [%fp+2007], %g1
>      brz %g1, .LL30
>       nop
>      ldx [%fp+2007], %g1
>      ldx [%g1], %g1            or here ?
>      cmp %g1, -1
>      bne %xcc, .LL30
>       nop
>      ldx [%fp+2007], %g1
>      add %g1, 16, %g1
>      ldx [%g1], %g1           or here?
>      stx %g1, [%fp+2015]
>      ldx [%fp+2007], %g1
>      add %g1, 8, %g1
>      ldx [%g1], %g1
>      stx %g1, [%fp+2007]
>     .LL30:
>      ldx [%fp+2007], %g1
>      ldx [%fp+2015], %g5
>      mov 0, %o0
>      call %g1, 0
>       nop
>      mov %o0, %g1
>      stx %g1, [%fp+2023]
>      ldx [%fp+2023], %g1
>      stx %g1, [%fp+1999]
>      
>      line 121
> 
>      .stabn 68,0,121,.LLM63-.LLFBB4
>     .LLM63:
>      ldx [%fp+1999], %g1
>      brz %g1, .LL33
>       nop
>     .LL32:
>      .stabn 68,0,122,.LLM64-.LLFBB4
>     .LLM64:
> 
>     g1 points to RTSignal_I3
> 
>     (gdb) x/i $pc
>     0x3ff0a8 :        ldx  [ %g1 ], %g1
>     (gdb) x/i $g1
>     0x4021f4 : save  %sp, -208, %sp
> 
>     I am willing to accept that a "function pointer" is a pair of
>     pointers, or even three pointers.
>     A pointer to code, a pointer to globals for position independent
>     code, a frame pointer to locals.
>     That equality comparison of function pointers requires comparing two
>     (or three) pointers.
>       (Though the global pointer shouldn't need comparing.)
>     At least for nested functions. Less so for non-nested. ?
>     Much less for comparison to NIL. ?
> 
>     And either way, this code is reading bogus data.
>     There isn't a pointer at the function address, there is code.
> 
>     Something doesn't add up.
> 
>     I'm going to try setting "aligned procedures" but that's quite bogus
>     I think.
> 
>     EqualExpr.m3 says
> 
>            Note: procedures pointers are always aligned!
> 
>     but maybe not?
> 
>     Yeah yeah I'm being lazy. I'll read more code..
> 
>     I also wonder if a "function pointer" can be optimized for the case
>     of not being to a nested function.
>     It looks like calling a function pointer is very inefficient.
>     It looks like..am I reading that correctly?.. that if the pointer
>     points to -1, then it is nested and
>     a pair of pointers, and not otherwise. That -1 is treated specially
>     as the first bytes of a function?
>     Is that a Modula-3-ism or a SPARC-ism?
>     It looks like a Modula-3-ism. And it seems dubious.
>     But I'll have to read more..
>      
>     NT386GNU does the same sort of wrong looking thing:
>      
>     LFBB4:
>      pushl %ebp
>      movl %esp, %ebp
>      subl $24, %esp
>     LBB5:
>      .stabn 68,0,117,LM60-LFBB4
>     LM60:
>      movl $0, -16(%ebp)
>      .stabn 68,0,119,LM61-LFBB4
>     LM61:
>      movl 8(%ebp), %eax
>      testl %eax, %eax
>      je L26
>      movl 8(%ebp), %eax
>      movl (%eax), %eax                  BAD
>      cmpl $-1, %eax                       BAD
>      je L27
>     L26:
>      movl 8(%ebp), %eax
>      testl %eax, %eax
>      je L33
>     L27:
>      .stabn 68,0,120,LM62-LFBB4
>     LM62:
> 
>      
>     and NT386:
>      
>     0:000> u
>     cm3!RTLinker__AddUnit:
>     00607864 55              push    ebp
>     00607865 8bec            mov     ebp,esp
>     00607867 81ec0c000000    sub     esp,0Ch
>     0060786d 53              push    ebx
>     0060786e 56              push    esi
>     0060786f 57              push    edi
>     00607870 c745fc00000000  mov     dword ptr [ebp-4],0
>     00607877 837d0800        cmp     dword ptr [ebp+8],0
>     0:000> u
>     cm3!RTLinker__AddUnit+0x17:
>     0060787b 0f840f000000    je      cm3!RTLinker__AddUnit+0x2c (00607890)
>     00607881 8b7508          mov     esi,dword ptr [ebp+8]
>     00607884 8b5e00          mov     ebx,dword ptr
>     [esi]                            BAD 
>     00607887 83fbff          cmp    
>     ebx,0FFFFFFFFh                                  BAD
>     0060788a 0f840f000000    je      cm3!RTLinker__AddUnit+0x3b (0060789f)
>     00607890 837d0800        cmp     dword ptr [ebp+8],0
>     00607894 0f8505000000    jne     cm3!RTLinker__AddUnit+0x3b (0060789f)
>     0060789a e969000000      jmp     cm3!RTLinker__AddUnit+0xa4 (00607908)
>      
>     cm3!RTLinker__AddUnit+0x20:
>     00607884 8b5e00          mov     ebx,dword ptr [esi] 
>     ds:002b:0062c950=81ec8b55
>     0:000> u @esi
>     cm3!RTLinker_I3:
>     0062c950 55              push    ebp
>     0062c951 8bec            mov     ebp,esp
>     0062c953 81ec00000000    sub     esp,0
>     0062c959 53              push    ebx
>     0062c95a 56              push    esi
>     0062c95b 57              push    edi
>     0062c95c 837d0800        cmp     dword ptr [ebp+8],0
>     0062c960 0f8400000000    je      cm3!RTLinker_I3+0x16 (0062c966)
>      
>     This is just wrong.
>     Comparing bytes of code to -1.
>      
>     I think the likely fix is for the "I3" code to be laid out as a
>     "constant function pointer", a pointer to a pair of pointers where
>     one points to the code and one is to -1. Something like that. That
>     can't be quite correct given that the existing data is callable.
> 
>       - Jay

-- 
-------------------------------------------------------------
Rodney M. Bates, retired assistant professor
Dept. of Computer Science, Wichita State University
Wichita, KS 67260-0083
316-978-3922
rodney.bates at wichita.edu 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Mon May 26 21:45:37 2008
From: jayk123 at hotmail.com (Jay)
Date: Mon, 26 May 2008 19:45:37 +0000
Subject: [M3devel] function pointers and comparison to nil? mis-typed
 function pointers?
In-Reply-To: 
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
	
	
	
Message-ID: 

It stinks either way imho.
The portability is handled, somehow or another, by gcc's support for nested functions.
For example on OpenBSD, they call mprotect to make the trampoline executable -- expensive! and leaves a bit of a security hole.
On Linux you can sometimes mark the .exe as needing an executable stack or not. Similarly on Windows, linker has /nxcompat, /nxcompat:no switch.
ATL on Windows puts trampolines in the heap and specifically makes them executable -- since the heap isn't necessarily executable either.
The -1 marker is also a bit of a portability problem but I guess in practise it works out.
I'd be curious to see how it decodes on various processors.
 
 - Jay


CC: rodney.bates at wichita.edu; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?Date: Mon, 26 May 2008 14:38:53 +0100

Moving away from the current implementation would be a portability disaster because of the fact that gcc requires an executable stack for its nested function implementation which is non-portable.

On May 26, 2008, at 11:04 AM, Jay wrote:

Cygwin gcc clearly generates code on the stack for nested functions.And then search the web..that's how it works in general.Nested functions have been deprecated on Mac OS X, in anticipation of possibly making the stack not executable. OpenBSD doesn't allow execution on the stack.They use mprotect to let trampolines run:  http://gcc.gnu.org/ml/gcc/2004-01/msg00742.html and  http://resin.csoft.net/cgi-bin/man.cgi?section=1&topic=gcc-local  Even though nested functions are a gcc extension to the C language, email threads out there discuss Ada, Pascal, and even ! Modula-3 as having nested functions, and that therefore deprecating the C language feature doesn't "solve" the "problem". I remain uncertain what, if anything, to do here. - keep the -1 hack, do nothing     generalize it slightly to let targets pick "better" markers  - use gcc's supported for nested functions    (plus the integrated backend, not difficult)  Clearly this is a dilemna to more than just me. :)  - Jay


From: jayk123 at hotmail.comTo: rodney.bates at wichita.edu; m3devel at elegosoft.comDate: Mon, 26 May 2008 05:26:41 +0000Subject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?Rodney, this agrees with much of what I figured out and guessed. I did not think of or look into some of what you point out though:  - what gcc's nested functions look like, and if you can take the address, and what that does   - calling Modula-3 nested functions as callbacks from C  Now, regarding trampolines.I alluded to them. It should be easy enough to generate them, and this would solve a few problems, but I believe also bring up a new big problem.Generating trampolines solves at least two problems:  - it allows Modula-3 nested function pointers ("closures") to be called from C  - it enables removing the check for -1  I contend that the check for -1 is not good. It is a somewhat risky assumption, that "-1" is not valid code.You do bring up a nice mitigation -- the assumption that it doesn't begin any functions, which is much narrower than it being valid code anywhere. For SPARC64_OPENBSD I figured out what the original authors meant to be the fix.You declare functions as not aligned, leading to the check for -1 first checking alignment (bigger code).Any pointer not aligned on an integer-sized address is presumed not a closure and not checked for the -1.This lets SPARC64_OPENBSD get further. Both it and PPC32_OPENBSD now for some reason suffer from an inability to heap allocate anything, failing around the attempt to create a new thread like in RTAllocator_M or so. I'll look into this more later.Now, the problem of trampolines..I consider the platform-dependent-ness to be surmountable.But where do you put the generated code? Putting it on the stack is counter to modern (and possibly old) "security" mechanisms.The stack is not generally executable, and even when it is, best just not do use that imho. That means, potentially/obviously, the need to heap allocate executable memory, for very small short lived data, quite inefficient. Is there some other way/place to produce trampolines, efficiently? In the absence of any good solution, I have to resign myself to assuming that -1 isn't the valid start of a function, and perhaps moving the marker into Target.i3, Target.m3 so that "more obvious" values get chosen. Like a breakpoint. Or "an epilogue", or "a trap instruction". I realize this needs details and is easily seen as "wrong". In particular, a function that does nothing could be termed as only having an "an epilogue". I know that other systems are "forced" to create "trampolines" so I should look into how they do that.I know that ATL, a Windows-specific library, is forced to heap allocate small executable chunks of memory and uses an efficient cache to optimize it. I do find this dependence on -1 not being the valid start of a function rather sleazy and at risk of being wrong.  - Jay

> Date: Sun, 25 May 2008 22:50:15 -0500> From: rodney.bates at wichita.edu> To: m3devel at elegosoft.com> Subject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?> > I think I can shed some light on this, having spent some time making> m3gdb handle the various operations on nested procedures. As for code> that mixes M3 and C, I believe the following are true:> > - Within M3 code only, the closure system works correctly in all cases.> This answers one of Jay's worries.> > - For values of M3 procedure/C function pointer that are top-level> (nonnested) procedures/functions, M3 and C code (generated by gcc,> at least) are interchangeable. This answers another of Jay's worries.> This will cover that great majority of cases.> > - Standard C has no nested functions. Gcc adds them as a language> extension. Thus, only in gcc-compiled C code do we need to worry> about nested procedures/functions between languages. (Do any other> C compilers exist that also have nested functions?)> > - M3 code should be able to call the value of a procedure variable> that was originally produced by C code as a pointer to a nested> function, and get the environment set up right, so its nonlocal> variable references will work, _if_ the nested function's> environment has not disappeared. This partially answers another> of Jay's worries. But:> > - M3's normal runtime check that precludes assigning a nonlocal> procedure value will not detect a C-code-produced nonlocal value,> thus the environment could indeed have disappeared if the programmer> was not careful. However, gcc-extended C's nested functions have> no protection against this bug when only C code is involved, so> perhaps not detecting it in mixed M3/C is to be expected.> > - C code that attempts to call a function pointer value that was> originally produced by M3 code as a nested procedure value will> almost certainly crash at the time of the call. This is the only> case that presents a significant problem. M3 code will not be> able to give a nested procedure as a callback to a C library.> > M3's mechanism: A value of procedure type is a pointer to either> 1) the first byte of the procedure's machine code, if it is top level, or> 2) A closure.> > A closure is a block of 3 words. The first word contains -1. Assuming> a word of all one bits is not valid machine code on any target machine> (or at least doesn't occur as the first code of any procedure), this can> be used at runtime to detect that this is indeed a closure and not code.> The remaining two words hold the code address and the environment address.> > So, an assignment of a procedure value has to check that it is not a closure,> and raise a runtime error if it is. A call on a procedure value has to check,> and if it is a closure, load/copy its environment pointer value into wherever> the calling convention expects it, then branch to the code address. Passing> a nested procedure constant as a parameter involves constructing a closure for> it and passing its address.> > gcc-C's mechanism: A value of type pointer to function is a pointer to either> 1) the first byte of the function's machine code, if it is top level,> (the same as with M3), or> 2) A trampoline.> > A trampoline is a bit of code that loads/copies an environment pointer (hard> coded into the trampoline) and then branches to the function code.> > Trampolines probably have a small constant-time speed advantage for _calls_,> but would be slower for some of the other operations, and the runtime check> could be tricky. Probably it could be fooled into failing when it shouldn't.> Moreover, trampolines are highly target-machine-dependent. Switching to them> would create a really big problem for m3gdb, which would have to have> different code for each target for each of the nested procedure operations.> > Jay wrote:> > I see somewhat.> > It's stuff around "closure".> > The comparison of code bytes to -1 comes from If_closure for example.> > > > The problem is presumably to come up with a unified representation of > > pointers to functions that may or may not be nested, while avoiding > > runtime codegen, even just a little bit, and for Modula-3 and C function > > pointers to use the same representation.> > I don't think the present solution is really valid, and I am skeptical > > that there is a solution.> > One of the requirements has to be dropped.> > Sniffing code bytes and trying to decide if they are code or not as > > appears to currently happen is bogus.> > > > I think the solution is to remove the requirement that a Modula-3 > > function pointer and a C function pointer are the same.> > Except, well, that probably doesn't work -- it means you need two types > > of function pointers.> > > > Darn this is a hard problem.> > > > The runtime codegen required can be exceedingly simple, fast, and small > > IF it were allowed to be on the stack. But that's a killer these days.> > > > I think you have to give up unification of "closures" and "function > > pointers".> > If you take the address of a nested function and call it, you cannot > > access the locals of the enclosing scopes.> > So in affect, you end up with "two types of function pointers".> > Regular stateless ones and "closures" with some captured state.> > > > Thoughts?> > > > I'm kind of stumped. It's a desirable problem to solve, and there is a > > purported solution in place, but the solution that is there is > > completely bogus, despite appearing to work for a long time, and there > > is no solution. That is my understanding. I could be wrong on any number > > of points but I'm pretty sure.> > > > I think you have to separate out function pointers and closures.> > Sniffing what it pointed to is dubous esp. as currently implemented.> > If this is really the way to go, then signature bytes need to be worked > > out for all architectures that are guaranteed to not look like code.> > Or vice versa -- signature bytes worked out that all functions start > > with, which is viable for Modula-3 but not for interop with C.> > Currently -1 is used, of pointer-size.> > That appears to be reasonable for x86:> > > > 0:000> eb . ff ff ff ff> > 0:000> u .> > ntdll32!DbgBreakPoint:> > 7d61002d ff ???> > 7d61002e ff ???> > 7d61002f ff ???> > 7d610030 ffc3 inc ebx> > > > but the instruction encodings or disassembly on other architectures > > would have to be checked.> > > > - Jay> > > > ------------------------------------------------------------------------> > From: jayk123 at hotmail.com> > To: m3devel at elegosoft.com> > Date: Sun, 25 May 2008 00:16:01 +0000> > Subject: [M3devel] function pointers and comparison to nil?> > mis-typed function pointers?> > > > I'm being lazy...> > > > Tony can you explain this stuff?> > > > Comparison of function pointers..> > What are the various representations and rules?> > > > What does it mean to compare nested functions?> > > > What does it mean to compare a function to NIL?> > > > I'll poke around more.> > > > What I am seeing is that comparison of function pointers to NIL is> > surprisingly> > expensive, and probably somewhat buggy. Or at least some of the runtime> > generated "metadata-ish" stuff is produced or typed incorrectly.> > > > In particular, RTLinker.m3:> > > > PROCEDURE AddUnit (b: RT0.Binder) => > VAR m: RT0.ModulePtr;> > BEGIN> > IF (b = NIL) THEN RETURN END; line 119> > m := b(0); line 120> > IF (m = NIL) THEN RETURN END; line 121> > AddUnitI(m); line 122> > END AddUnit;> > > > generates a lot of code, just for the first line:> > (556) set_source_line > > source line 119 > > (557) load > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb > > (558) load_nil > > (559) if_eq > > (560) load > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb > > (561) load_indirect > > load address offset 0x0 src_t 0x5 dst_t 0x5 > > (562) load_integer > > integer n_bytes 0x0 hi 0x0 low 0x1 sign -1 > > (563) if_eq > > (564) set_label > > (565) load_nil > > (566) load > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb > > (567) if_ne > > (568) set_label > > (569) exit_proc > > (570) set_label > > (571) set_source_line > > source line 120 > > > > The details on the load_integer trace might not be completely> > correct. I will test a fix shortly.> > Esp. that n_bytes gets decremented to zero before the trace.> > > > Ok, I see now why some of the bloat -- because the "then return end"> > is on the same line.> > If it were written as:> > if (b = NIL THEN > > return> > end > > It probably wouldn't look so bad. That took me a while to realize.> > > > The following is generated for SPARC64_OPENBSD:> > > > line 119> > .stabn 68,0,119,.LLM61-.LLFBB4> > .LLM61:> > ldx [%fp+2175], %g1> > brz %g1, .LL26> > nop> > ldx [%fp+2175], %g1> > ldx [%g1], %g1 bus error here? yes, probably this one> > cmp %g1, -1> > be %xcc, .LL27> > nop> > .LL26:> > ldx [%fp+2175], %g1> > brz %g1, .LL33> > nop> > .LL27:> > line 120> > .stabn 68,0,120,.LLM62-.LLFBB4> > .LLM62:> > ldx [%fp+2175], %g1> > stx %g1, [%fp+2007]> > ldx [%fp+2007], %g1> > brz %g1, .LL30> > nop> > ldx [%fp+2007], %g1> > ldx [%g1], %g1 or here ?> > cmp %g1, -1> > bne %xcc, .LL30> > nop> > ldx [%fp+2007], %g1> > add %g1, 16, %g1> > ldx [%g1], %g1 or here?> > stx %g1, [%fp+2015]> > ldx [%fp+2007], %g1> > add %g1, 8, %g1> > ldx [%g1], %g1> > stx %g1, [%fp+2007]> > .LL30:> > ldx [%fp+2007], %g1> > ldx [%fp+2015], %g5> > mov 0, %o0> > call %g1, 0> > nop> > mov %o0, %g1> > stx %g1, [%fp+2023]> > ldx [%fp+2023], %g1> > stx %g1, [%fp+1999]> > > > line 121> > > > .stabn 68,0,121,.LLM63-.LLFBB4> > .LLM63:> > ldx [%fp+1999], %g1> > brz %g1, .LL33> > nop> > .LL32:> > .stabn 68,0,122,.LLM64-.LLFBB4> > .LLM64:> > > > g1 points to RTSignal_I3> > > > (gdb) x/i $pc> > 0x3ff0a8 : ldx [ %g1 ], %g1> > (gdb) x/i $g1> > 0x4021f4 : save %sp, -208, %sp> > > > I am willing to accept that a "function pointer" is a pair of> > pointers, or even three pointers.> > A pointer to code, a pointer to globals for position independent> > code, a frame pointer to locals.> > That equality comparison of function pointers requires comparing two> > (or three) pointers.> > (Though the global pointer shouldn't need comparing.)> > At least for nested functions. Less so for non-nested. ?> > Much less for comparison to NIL. ?> > > > And either way, this code is reading bogus data.> > There isn't a pointer at the function address, there is code.> > > > Something doesn't add up.> > > > I'm going to try setting "aligned procedures" but that's quite bogus> > I think.> > > > EqualExpr.m3 says> > > > Note: procedures pointers are always aligned!> > > > but maybe not?> > > > Yeah yeah I'm being lazy. I'll read more code..> > > > I also wonder if a "function pointer" can be optimized for the case> > of not being to a nested function.> > It looks like calling a function pointer is very inefficient.> > It looks like..am I reading that correctly?.. that if the pointer> > points to -1, then it is nested and> > a pair of pointers, and not otherwise. That -1 is treated specially> > as the first bytes of a function?> > Is that a Modula-3-ism or a SPARC-ism?> > It looks like a Modula-3-ism. And it seems dubious.> > But I'll have to read more..> > > > NT386GNU does the same sort of wrong looking thing:> > > > LFBB4:> > pushl %ebp> > movl %esp, %ebp> > subl $24, %esp> > LBB5:> > .stabn 68,0,117,LM60-LFBB4> > LM60:> > movl $0, -16(%ebp)> > .stabn 68,0,119,LM61-LFBB4> > LM61:> > movl 8(%ebp), %eax> > testl %eax, %eax> > je L26> > movl 8(%ebp), %eax> > movl (%eax), %eax BAD> > cmpl $-1, %eax BAD> > je L27> > L26:> > movl 8(%ebp), %eax> > testl %eax, %eax> > je L33> > L27:> > .stabn 68,0,120,LM62-LFBB4> > LM62:> > > > > > and NT386:> > > > 0:000> u> > cm3!RTLinker__AddUnit:> > 00607864 55 push ebp> > 00607865 8bec mov ebp,esp> > 00607867 81ec0c000000 sub esp,0Ch> > 0060786d 53 push ebx> > 0060786e 56 push esi> > 0060786f 57 push edi> > 00607870 c745fc00000000 mov dword ptr [ebp-4],0> > 00607877 837d0800 cmp dword ptr [ebp+8],0> > 0:000> u> > cm3!RTLinker__AddUnit+0x17:> > 0060787b 0f840f000000 je cm3!RTLinker__AddUnit+0x2c (00607890)> > 00607881 8b7508 mov esi,dword ptr [ebp+8]> > 00607884 8b5e00 mov ebx,dword ptr> > [esi] BAD > > 00607887 83fbff cmp > > ebx,0FFFFFFFFh BAD> > 0060788a 0f840f000000 je cm3!RTLinker__AddUnit+0x3b (0060789f)> > 00607890 837d0800 cmp dword ptr [ebp+8],0> > 00607894 0f8505000000 jne cm3!RTLinker__AddUnit+0x3b (0060789f)> > 0060789a e969000000 jmp cm3!RTLinker__AddUnit+0xa4 (00607908)> > > > cm3!RTLinker__AddUnit+0x20:> > 00607884 8b5e00 mov ebx,dword ptr [esi] > > ds:002b:0062c950=81ec8b55> > 0:000> u @esi> > cm3!RTLinker_I3:> > 0062c950 55 push ebp> > 0062c951 8bec mov ebp,esp> > 0062c953 81ec00000000 sub esp,0> > 0062c959 53 push ebx> > 0062c95a 56 push esi> > 0062c95b 57 push edi> > 0062c95c 837d0800 cmp dword ptr [ebp+8],0> > 0062c960 0f8400000000 je cm3!RTLinker_I3+0x16 (0062c966)> > > > This is just wrong.> > Comparing bytes of code to -1.> > > > I think the likely fix is for the "I3" code to be laid out as a> > "constant function pointer", a pointer to a pair of pointers where> > one points to the code and one is to -1. Something like that. That> > can't be quite correct given that the existing data is callable.> > > > - Jay> > -- > -------------------------------------------------------------> Rodney M. Bates, retired assistant professor> Dept. of Computer Science, Wichita State University> Wichita, KS 67260-0083> 316-978-3922> rodney.bates at wichita.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rodney.bates at wichita.edu  Mon May 26 22:47:53 2008
From: rodney.bates at wichita.edu (Rodney M. Bates)
Date: Mon, 26 May 2008 15:47:53 -0500
Subject: [M3devel] function pointers and comparison to nil? mis-typed
 function pointers?
In-Reply-To: 
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
	
	
	
	
Message-ID: <483B21F9.6070205@wichita.edu>



Jay wrote:
> It stinks either way imho.
> The portability is handled, somehow or another, by gcc's support for 
> nested functions.
> For example on OpenBSD, they call mprotect to make the trampoline 
> executable -- expensive! and leaves a bit of a security hole.
> On Linux you can sometimes mark the .exe as needing an executable stack 
> or not. Similarly on Windows, linker has /nxcompat, /nxcompat:no switch.
> ATL on Windows puts trampolines in the heap and specifically makes them 
> executable -- since the heap isn't necessarily executable either.
> The -1 marker is also a bit of a portability problem but I guess in 
> practise it works out.

Using trampolines would make this problem worse, perhaps much worse.
Mistaking the function's real code for a closure is a lot less likely
than mistaking the function's real code for a trampoline.  A trampoline
is, after all, always valid machine code on the executing processor.
Not necessarily so for -1.

> I'd be curious to see how it decodes on various processors.
>  
>  - Jay
>
-- 
-------------------------------------------------------------
Rodney M. Bates, retired assistant professor
Dept. of Computer Science, Wichita State University
Wichita, KS 67260-0083
316-978-3922
rodney.bates at wichita.edu


From jayk123 at hotmail.com  Mon May 26 23:33:21 2008
From: jayk123 at hotmail.com (Jay)
Date: Mon, 26 May 2008 21:33:21 +0000
Subject: [M3devel] function pointers and comparison to nil? mis-typed
 function pointers?
In-Reply-To: <483B21F9.6070205@wichita.edu>
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
	
	
	
	 
	<483B21F9.6070205@wichita.edu>
Message-ID: 

 > Mistaking the function's real code for a closure is a lot less likely  > than mistaking the function's real code for a trampoline. A trampoline 
What is the danger in "mistaking" "real code" for a "trampoline"?
They are both "real code".
The differences are:
  - trampoline has limited lifetime -- unless it is heap allocated and garbage collected 
    ("real code" also has "limited lifetime", but relatively much longer, if code can be unloaded, which it can be in many environments) 
  - the "real code" of nested functions has a different calling convention than "real code" for non nested functions; it has an extra parameter "somewhere", for the "static link"; in gcc C nested functions on Cygwin/x86, this is in ecx 
 
What do folks think about putting trampolines in executable garbage collected heap?
I think that's inefficient but I'm usually in the minority here regarding the heap being inefficient.
 
One way or another, gcc makes C nested functions fairly portable, except Apple's gcc on Darwin.
Portability of -1 as a marker denoting "not code" is also dubious.
 
I think it stinks either way.
 
Anyone think coming up with "better" per-architecture markers is reasonable?
 
 - Jay



> Date: Mon, 26 May 2008 15:47:53 -0500> From: rodney.bates at wichita.edu> To: m3devel at elegosoft.com> Subject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?> > > > Jay wrote:> > It stinks either way imho.> > The portability is handled, somehow or another, by gcc's support for > > nested functions.> > For example on OpenBSD, they call mprotect to make the trampoline > > executable -- expensive! and leaves a bit of a security hole.> > On Linux you can sometimes mark the .exe as needing an executable stack > > or not. Similarly on Windows, linker has /nxcompat, /nxcompat:no switch.> > ATL on Windows puts trampolines in the heap and specifically makes them > > executable -- since the heap isn't necessarily executable either.> > The -1 marker is also a bit of a portability problem but I guess in > > practise it works out.> > Using trampolines would make this problem worse, perhaps much worse.> Mistaking the function's real code for a closure is a lot less likely> than mistaking the function's real code for a trampoline. A trampoline> is, after all, always valid machine code on the executing processor.> Not necessarily so for -1.> > > I'd be curious to see how it decodes on various processors.> > > > - Jay> >> -- > -------------------------------------------------------------> Rodney M. Bates, retired assistant professor> Dept. of Computer Science, Wichita State University> Wichita, KS 67260-0083> 316-978-3922> rodney.bates at wichita.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Tue May 27 07:14:11 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 27 May 2008 05:14:11 +0000
Subject: [M3devel] stat file types?
In-Reply-To: 
References: 
Message-ID: 

Hm. I was about to commit this and then I found:
 
 http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/sys/stat.h  http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libbc/inc/include/sys/stat.h 
 
One of these defines S_IFPORT, and it isn't equal to S_IFIFO.
The Modula-3 implementation is *perhaps* incorrect.
 
I don't yet have a Solaris install to see which of these is /usr/include/sys/stat.h and/or to determine what "the other" is.
 
I still haven't found any systems that define S_IFPIPE.
 
 - Jay


From: jayk123 at hotmail.comTo: m3devel at elegosoft.comSubject: stat file types?Date: Sat, 24 May 2008 09:50:50 +0000


It SEEMS: S_IFPIPE appears to be made up by Modula-3.S_IFPORT appears to be made up by Modula-3 as a synonym for S_IFIFO. PROPOSED:This code:D:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX\FilePosix.i3(36):   error if "fd" is not "S_IFPIPE", "S_IFPORT", or "S_IFSOCK". *)D:\dev2\cm3.2\m3-libs\libm3\src\os\POSIX\FilePosix.m3(47):    | Ustat.S_IFPIPE, Ustat.S_IFPORT, Ustat.S_IFSOCK => should check for S_IFSOCK and S_IFIFO.all references to and definitions of S_IFPORT and S_IFPIPE should go away. Or did some actual systems actually define either of these? Most of the *.i3 files set S_IFPORT = S_IFIFO and S_IFPIPE = 0.Many of them say that there is no S_IFPIPE in their .h file.Irix has them reversed but the same result: S_IFPORT = 0 and S_IFPIPE = S_IFIFO. Any objections? - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From hosking at cs.purdue.edu  Tue May 27 10:48:37 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 27 May 2008 09:48:37 +0100
Subject: [M3devel] function pointers and comparison to nil? mis-typed
	function pointers?
In-Reply-To: 
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
	
	
	
	
Message-ID: <7F087A94-FCF4-487C-8744-530F82B95F95@cs.purdue.edu>

gcc just allows computation of the static link.

I think there is an alternate compilation mode supported by the front- 
end for other platforms (like the integrated back end) but I have not  
looked at that closely.



On May 26, 2008, at 8:45 PM, Jay wrote:

> It stinks either way imho.
> The portability is handled, somehow or another, by gcc's support for  
> nested functions.
> For example on OpenBSD, they call mprotect to make the trampoline  
> executable -- expensive! and leaves a bit of a security hole.
> On Linux you can sometimes mark the .exe as needing an executable  
> stack or not. Similarly on Windows, linker has /nxcompat, / 
> nxcompat:no switch.
> ATL on Windows puts trampolines in the heap and specifically makes  
> them executable -- since the heap isn't necessarily executable either.
> The -1 marker is also a bit of a portability problem but I guess in  
> practise it works out.
> I'd be curious to see how it decodes on various processors.
>
>  - Jay
>
> CC: rodney.bates at wichita.edu; m3devel at elegosoft.com
> From: hosking at cs.purdue.edu
> To: jayk123 at hotmail.com
> Subject: Re: [M3devel] function pointers and comparison to nil? mis- 
> typed function pointers?
> Date: Mon, 26 May 2008 14:38:53 +0100
>
> Moving away from the current implementation would be a portability  
> disaster because of the fact that gcc requires an executable stack  
> for its nested function implementation which is non-portable.
>
> On May 26, 2008, at 11:04 AM, Jay wrote:
>
> Cygwin gcc clearly generates code on the stack for nested functions.
> And then search the web..that's how it works in general.
> Nested functions have been deprecated on Mac OS X, in anticipation  
> of possibly making the stack not executable.
>
> OpenBSD doesn't allow execution on the stack.
> They use mprotect to let trampolines run:
>   http://gcc.gnu.org/ml/gcc/2004-01/msg00742.html
> and
>   http://resin.csoft.net/cgi-bin/man.cgi?section=1&topic=gcc-local
>
> Even though nested functions are a gcc extension to the C language,  
> email threads out there discuss Ada, Pascal, and even ! Modula-3 as  
> having nested functions, and that therefore deprecating the C  
> language feature doesn't "solve" the "problem".
>
> I remain uncertain what, if anything, to do here.
>  - keep the -1 hack, do nothing
>     generalize it slightly to let targets pick "better" markers
>  - use gcc's supported for nested functions
>    (plus the integrated backend, not difficult)
>
> Clearly this is a dilemna to more than just me. :)
>
>  - Jay
> From: jayk123 at hotmail.com
> To: rodney.bates at wichita.edu; m3devel at elegosoft.com
> Date: Mon, 26 May 2008 05:26:41 +0000
> Subject: Re: [M3devel] function pointers and comparison to nil? mis- 
> typed function pointers?
>
> Rodney, this agrees with much of what I figured out and guessed. I  
> did not think of or look into some of what you point out though:
>   - what gcc's nested functions look like, and if you can take the  
> address, and what that does
>   - calling Modula-3 nested functions as callbacks from C
>
> Now, regarding trampolines.
> I alluded to them. It should be easy enough to generate them, and  
> this would solve a few problems, but I believe also bring up a new  
> big problem.
> Generating trampolines solves at least two problems:
>  - it allows Modula-3 nested function pointers ("closures") to be  
> called from C
>  - it enables removing the check for -1
>
> I contend that the check for -1 is not good. It is a somewhat risky  
> assumption, that "-1" is not valid code.
> You do bring up a nice mitigation -- the assumption that it doesn't  
> begin any functions, which is much narrower than it being valid code  
> anywhere.
>
> For SPARC64_OPENBSD I figured out what the original authors meant to  
> be the fix.
> You declare functions as not aligned, leading to the check for -1  
> first checking alignment (bigger code).
> Any pointer not aligned on an integer-sized address is presumed not  
> a closure and not checked for the -1.
> This lets SPARC64_OPENBSD get further. Both it and PPC32_OPENBSD now  
> for some reason suffer from an inability to heap allocate anything,  
> failing around the attempt to create a new thread like in  
> RTAllocator_M or so. I'll look into this more later.
>
> Now, the problem of trampolines..I consider the platform-dependent- 
> ness to be surmountable.
> But where do you put the generated code? Putting it on the stack is  
> counter to modern (and possibly old) "security" mechanisms.
> The stack is not generally executable, and even when it is, best  
> just not do use that imho.
>
> That means, potentially/obviously, the need to heap allocate  
> executable memory, for very small short lived data, quite inefficient.
>
> Is there some other way/place to produce trampolines, efficiently?
>
> In the absence of any good solution, I have to resign myself to  
> assuming that -1 isn't the valid start of a function, and perhaps  
> moving the marker into Target.i3, Target.m3 so that "more obvious"  
> values get chosen. Like a breakpoint. Or "an epilogue", or "a trap  
> instruction". I realize this needs details and is easily seen as  
> "wrong". In particular, a function that does nothing could be termed  
> as only having an "an epilogue".
>
> I know that other systems are "forced" to create "trampolines" so I  
> should look into how they do that.
> I know that ATL, a Windows-specific library, is forced to heap  
> allocate small executable chunks of memory and uses an efficient  
> cache to optimize it.
>
> I do find this dependence on -1 not being the valid start of a  
> function rather sleazy and at risk of being wrong.
>
>  - Jay
>
>
>
>
> > Date: Sun, 25 May 2008 22:50:15 -0500
> > From: rodney.bates at wichita.edu
> > To: m3devel at elegosoft.com
> > Subject: Re: [M3devel] function pointers and comparison to nil?  
> mis-typed function pointers?
> >
> > I think I can shed some light on this, having spent some time making
> > m3gdb handle the various operations on nested procedures. As for  
> code
> > that mixes M3 and C, I believe the following are true:
> >
> > - Within M3 code only, the closure system works correctly in all  
> cases.
> > This answers one of Jay's worries.
> >
> > - For values of M3 procedure/C function pointer that are top-level
> > (nonnested) procedures/functions, M3 and C code (generated by gcc,
> > at least) are interchangeable. This answers another of Jay's  
> worries.
> > This will cover that great majority of cases.
> >
> > - Standard C has no nested functions. Gcc adds them as a language
> > extension. Thus, only in gcc-compiled C code do we need to worry
> > about nested procedures/functions between languages. (Do any other
> > C compilers exist that also have nested functions?)
> >
> > - M3 code should be able to call the value of a procedure variable
> > that was originally produced by C code as a pointer to a nested
> > function, and get the environment set up right, so its nonlocal
> > variable references will work, _if_ the nested function's
> > environment has not disappeared. This partially answers another
> > of Jay's worries. But:
> >
> > - M3's normal runtime check that precludes assigning a nonlocal
> > procedure value will not detect a C-code-produced nonlocal value,
> > thus the environment could indeed have disappeared if the programmer
> > was not careful. However, gcc-extended C's nested functions have
> > no protection against this bug when only C code is involved, so
> > perhaps not detecting it in mixed M3/C is to be expected.
> >
> > - C code that attempts to call a function pointer value that was
> > originally produced by M3 code as a nested procedure value will
> > almost certainly crash at the time of the call. This is the only
> > case that presents a significant problem. M3 code will not be
> > able to give a nested procedure as a callback to a C library.
> >
> > M3's mechanism: A value of procedure type is a pointer to either
> > 1) the first byte of the procedure's machine code, if it is top  
> level, or
> > 2) A closure.
> >
> > A closure is a block of 3 words. The first word contains -1.  
> Assuming
> > a word of all one bits is not valid machine code on any target  
> machine
> > (or at least doesn't occur as the first code of any procedure),  
> this can
> > be used at runtime to detect that this is indeed a closure and not  
> code.
> > The remaining two words hold the code address and the environment  
> address.
> >
> > So, an assignment of a procedure value has to check that it is not  
> a closure,
> > and raise a runtime error if it is. A call on a procedure value  
> has to check,
> > and if it is a closure, load/copy its environment pointer value  
> into wherever
> > the calling convention expects it, then branch to the code  
> address. Passing
> > a nested procedure constant as a parameter involves constructing a  
> closure for
> > it and passing its address.
> >
> > gcc-C's mechanism: A value of type pointer to function is a  
> pointer to either
> > 1) the first byte of the function's machine code, if it is top  
> level,
> > (the same as with M3), or
> > 2) A trampoline.
> >
> > A trampoline is a bit of code that loads/copies an environment  
> pointer (hard
> > coded into the trampoline) and then branches to the function code.
> >
> > Trampolines probably have a small constant-time speed advantage  
> for _calls_,
> > but would be slower for some of the other operations, and the  
> runtime check
> > could be tricky. Probably it could be fooled into failing when it  
> shouldn't.
> > Moreover, trampolines are highly target-machine-dependent.  
> Switching to them
> > would create a really big problem for m3gdb, which would have to  
> have
> > different code for each target for each of the nested procedure  
> operations.
> >
> > Jay wrote:
> > > I see somewhat.
> > > It's stuff around "closure".
> > > The comparison of code bytes to -1 comes from If_closure for  
> example.
> > >
> > > The problem is presumably to come up with a unified  
> representation of
> > > pointers to functions that may or may not be nested, while  
> avoiding
> > > runtime codegen, even just a little bit, and for Modula-3 and C  
> function
> > > pointers to use the same representation.
> > > I don't think the present solution is really valid, and I am  
> skeptical
> > > that there is a solution.
> > > One of the requirements has to be dropped.
> > > Sniffing code bytes and trying to decide if they are code or not  
> as
> > > appears to currently happen is bogus.
> > >
> > > I think the solution is to remove the requirement that a Modula-3
> > > function pointer and a C function pointer are the same.
> > > Except, well, that probably doesn't work -- it means you need  
> two types
> > > of function pointers.
> > >
> > > Darn this is a hard problem.
> > >
> > > The runtime codegen required can be exceedingly simple, fast,  
> and small
> > > IF it were allowed to be on the stack. But that's a killer these  
> days.
> > >
> > > I think you have to give up unification of "closures" and  
> "function
> > > pointers".
> > > If you take the address of a nested function and call it, you  
> cannot
> > > access the locals of the enclosing scopes.
> > > So in affect, you end up with "two types of function pointers".
> > > Regular stateless ones and "closures" with some captured state.
> > >
> > > Thoughts?
> > >
> > > I'm kind of stumped. It's a desirable problem to solve, and  
> there is a
> > > purported solution in place, but the solution that is there is
> > > completely bogus, despite appearing to work for a long time, and  
> there
> > > is no solution. That is my understanding. I could be wrong on  
> any number
> > > of points but I'm pretty sure.
> > >
> > > I think you have to separate out function pointers and closures.
> > > Sniffing what it pointed to is dubous esp. as currently  
> implemented.
> > > If this is really the way to go, then signature bytes need to be  
> worked
> > > out for all architectures that are guaranteed to not look like  
> code.
> > > Or vice versa -- signature bytes worked out that all functions  
> start
> > > with, which is viable for Modula-3 but not for interop with C.
> > > Currently -1 is used, of pointer-size.
> > > That appears to be reasonable for x86:
> > >
> > > 0:000> eb . ff ff ff ff
> > > 0:000> u .
> > > ntdll32!DbgBreakPoint:
> > > 7d61002d ff ???
> > > 7d61002e ff ???
> > > 7d61002f ff ???
> > > 7d610030 ffc3 inc ebx
> > >
> > > but the instruction encodings or disassembly on other  
> architectures
> > > would have to be checked.
> > >
> > > - Jay
> > >
> > >  
> ------------------------------------------------------------------------
> > > From: jayk123 at hotmail.com
> > > To: m3devel at elegosoft.com
> > > Date: Sun, 25 May 2008 00:16:01 +0000
> > > Subject: [M3devel] function pointers and comparison to nil?
> > > mis-typed function pointers?
> > >
> > > I'm being lazy...
> > >
> > > Tony can you explain this stuff?
> > >
> > > Comparison of function pointers..
> > > What are the various representations and rules?
> > >
> > > What does it mean to compare nested functions?
> > >
> > > What does it mean to compare a function to NIL?
> > >
> > > I'll poke around more.
> > >
> > > What I am seeing is that comparison of function pointers to NIL is
> > > surprisingly
> > > expensive, and probably somewhat buggy. Or at least some of the  
> runtime
> > > generated "metadata-ish" stuff is produced or typed incorrectly.
> > >
> > > In particular, RTLinker.m3:
> > >
> > > PROCEDURE AddUnit (b: RT0.Binder) =
> > > VAR m: RT0.ModulePtr;
> > > BEGIN
> > > IF (b = NIL) THEN RETURN END; line 119
> > > m := b(0); line 120
> > > IF (m = NIL) THEN RETURN END; line 121
> > > AddUnitI(m); line 122
> > > END AddUnit;
> > >
> > > generates a lot of code, just for the first line:
> > > (556) set_source_line
> > > source line 119
> > > (557) load
> > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb
> > > (558) load_nil
> > > (559) if_eq
> > > (560) load
> > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb
> > > (561) load_indirect
> > > load address offset 0x0 src_t 0x5 dst_t 0x5
> > > (562) load_integer
> > > integer n_bytes 0x0 hi 0x0 low 0x1 sign -1
> > > (563) if_eq
> > > (564) set_label
> > > (565) load_nil
> > > (566) load
> > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb
> > > (567) if_ne
> > > (568) set_label
> > > (569) exit_proc
> > > (570) set_label
> > > (571) set_source_line
> > > source line 120
> > >
> > > The details on the load_integer trace might not be completely
> > > correct. I will test a fix shortly.
> > > Esp. that n_bytes gets decremented to zero before the trace.
> > >
> > > Ok, I see now why some of the bloat -- because the "then return  
> end"
> > > is on the same line.
> > > If it were written as:
> > > if (b = NIL THEN
> > > return
> > > end
> > > It probably wouldn't look so bad. That took me a while to realize.
> > >
> > > The following is generated for SPARC64_OPENBSD:
> > >
> > > line 119
> > > .stabn 68,0,119,.LLM61-.LLFBB4
> > > .LLM61:
> > > ldx [%fp+2175], %g1
> > > brz %g1, .LL26
> > > nop
> > > ldx [%fp+2175], %g1
> > > ldx [%g1], %g1 bus error here? yes, probably this one
> > > cmp %g1, -1
> > > be %xcc, .LL27
> > > nop
> > > .LL26:
> > > ldx [%fp+2175], %g1
> > > brz %g1, .LL33
> > > nop
> > > .LL27:
> > > line 120
> > > .stabn 68,0,120,.LLM62-.LLFBB4
> > > .LLM62:
> > > ldx [%fp+2175], %g1
> > > stx %g1, [%fp+2007]
> > > ldx [%fp+2007], %g1
> > > brz %g1, .LL30
> > > nop
> > > ldx [%fp+2007], %g1
> > > ldx [%g1], %g1 or here ?
> > > cmp %g1, -1
> > > bne %xcc, .LL30
> > > nop
> > > ldx [%fp+2007], %g1
> > > add %g1, 16, %g1
> > > ldx [%g1], %g1 or here?
> > > stx %g1, [%fp+2015]
> > > ldx [%fp+2007], %g1
> > > add %g1, 8, %g1
> > > ldx [%g1], %g1
> > > stx %g1, [%fp+2007]
> > > .LL30:
> > > ldx [%fp+2007], %g1
> > > ldx [%fp+2015], %g5
> > > mov 0, %o0
> > > call %g1, 0
> > > nop
> > > mov %o0, %g1
> > > stx %g1, [%fp+2023]
> > > ldx [%fp+2023], %g1
> > > stx %g1, [%fp+1999]
> > >
> > > line 121
> > >
> > > .stabn 68,0,121,.LLM63-.LLFBB4
> > > .LLM63:
> > > ldx [%fp+1999], %g1
> > > brz %g1, .LL33
> > > nop
> > > .LL32:
> > > .stabn 68,0,122,.LLM64-.LLFBB4
> > > .LLM64:
> > >
> > > g1 points to RTSignal_I3
> > >
> > > (gdb) x/i $pc
> > > 0x3ff0a8 : ldx [ %g1 ], %g1
> > > (gdb) x/i $g1
> > > 0x4021f4 : save %sp, -208, %sp
> > >
> > > I am willing to accept that a "function pointer" is a pair of
> > > pointers, or even three pointers.
> > > A pointer to code, a pointer to globals for position independent
> > > code, a frame pointer to locals.
> > > That equality comparison of function pointers requires comparing  
> two
> > > (or three) pointers.
> > > (Though the global pointer shouldn't need comparing.)
> > > At least for nested functions. Less so for non-nested. ?
> > > Much less for comparison to NIL. ?
> > >
> > > And either way, this code is reading bogus data.
> > > There isn't a pointer at the function address, there is code.
> > >
> > > Something doesn't add up.
> > >
> > > I'm going to try setting "aligned procedures" but that's quite  
> bogus
> > > I think.
> > >
> > > EqualExpr.m3 says
> > >
> > > Note: procedures pointers are always aligned!
> > >
> > > but maybe not?
> > >
> > > Yeah yeah I'm being lazy. I'll read more code..
> > >
> > > I also wonder if a "function pointer" can be optimized for the  
> case
> > > of not being to a nested function.
> > > It looks like calling a function pointer is very inefficient.
> > > It looks like..am I reading that correctly?.. that if the pointer
> > > points to -1, then it is nested and
> > > a pair of pointers, and not otherwise. That -1 is treated  
> specially
> > > as the first bytes of a function?
> > > Is that a Modula-3-ism or a SPARC-ism?
> > > It looks like a Modula-3-ism. And it seems dubious.
> > > But I'll have to read more..
> > >
> > > NT386GNU does the same sort of wrong looking thing:
> > >
> > > LFBB4:
> > > pushl %ebp
> > > movl %esp, %ebp
> > > subl $24, %esp
> > > LBB5:
> > > .stabn 68,0,117,LM60-LFBB4
> > > LM60:
> > > movl $0, -16(%ebp)
> > > .stabn 68,0,119,LM61-LFBB4
> > > LM61:
> > > movl 8(%ebp), %eax
> > > testl %eax, %eax
> > > je L26
> > > movl 8(%ebp), %eax
> > > movl (%eax), %eax BAD
> > > cmpl $-1, %eax BAD
> > > je L27
> > > L26:
> > > movl 8(%ebp), %eax
> > > testl %eax, %eax
> > > je L33
> > > L27:
> > > .stabn 68,0,120,LM62-LFBB4
> > > LM62:
> > >
> > >
> > > and NT386:
> > >
> > > 0:000> u
> > > cm3!RTLinker__AddUnit:
> > > 00607864 55 push ebp
> > > 00607865 8bec mov ebp,esp
> > > 00607867 81ec0c000000 sub esp,0Ch
> > > 0060786d 53 push ebx
> > > 0060786e 56 push esi
> > > 0060786f 57 push edi
> > > 00607870 c745fc00000000 mov dword ptr [ebp-4],0
> > > 00607877 837d0800 cmp dword ptr [ebp+8],0
> > > 0:000> u
> > > cm3!RTLinker__AddUnit+0x17:
> > > 0060787b 0f840f000000 je cm3!RTLinker__AddUnit+0x2c (00607890)
> > > 00607881 8b7508 mov esi,dword ptr [ebp+8]
> > > 00607884 8b5e00 mov ebx,dword ptr
> > > [esi] BAD
> > > 00607887 83fbff cmp
> > > ebx,0FFFFFFFFh BAD
> > > 0060788a 0f840f000000 je cm3!RTLinker__AddUnit+0x3b (0060789f)
> > > 00607890 837d0800 cmp dword ptr [ebp+8],0
> > > 00607894 0f8505000000 jne cm3!RTLinker__AddUnit+0x3b (0060789f)
> > > 0060789a e969000000 jmp cm3!RTLinker__AddUnit+0xa4 (00607908)
> > >
> > > cm3!RTLinker__AddUnit+0x20:
> > > 00607884 8b5e00 mov ebx,dword ptr [esi]
> > > ds:002b:0062c950=81ec8b55
> > > 0:000> u @esi
> > > cm3!RTLinker_I3:
> > > 0062c950 55 push ebp
> > > 0062c951 8bec mov ebp,esp
> > > 0062c953 81ec00000000 sub esp,0
> > > 0062c959 53 push ebx
> > > 0062c95a 56 push esi
> > > 0062c95b 57 push edi
> > > 0062c95c 837d0800 cmp dword ptr [ebp+8],0
> > > 0062c960 0f8400000000 je cm3!RTLinker_I3+0x16 (0062c966)
> > >
> > > This is just wrong.
> > > Comparing bytes of code to -1.
> > >
> > > I think the likely fix is for the "I3" code to be laid out as a
> > > "constant function pointer", a pointer to a pair of pointers where
> > > one points to the code and one is to -1. Something like that. That
> > > can't be quite correct given that the existing data is callable.
> > >
> > > - Jay
> >
> > --
> > -------------------------------------------------------------
> > Rodney M. Bates, retired assistant professor
> > Dept. of Computer Science, Wichita State University
> > Wichita, KS 67260-0083
> > 316-978-3922
> > rodney.bates at wichita.edu
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From hosking at cs.purdue.edu  Tue May 27 11:37:31 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 27 May 2008 10:37:31 +0100
Subject: [M3devel] gcc/m3cc/cm3c for OpenBSD?
In-Reply-To: 
References: 
Message-ID: <9B55DC75-DDBB-46F8-929F-2216922E39BE@cs.purdue.edu>



On May 19, 2008, at 1:47 PM, Jay wrote:

> What is the right way to handle these:
>  http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/gcc/4.3/patches/
> I imagine:
>  1) import them m3-sys/m3cc/src/patches/openbsd
>  2) perhaps use a vendor branch for the import
>    however they haven't changed in 14 months
>    and HOPEFULLY they get ported upstream

Best this so later vendor upgrades don't confuse them with M3-related  
changes.

>
>  3) apply patches at build time
>
> Seems kind of bad, but I figure also too much to manage to checkin  
> the patch results?
> I realize it stinks largely due to the risk of accidentally doing  
> what is avoided.
> Maybe there is like "VPATH" and the to-be-patched files can be  
> copied in the output
> directory and patched there?
>
>  They aren't all needed, by far, but definitely some of them are  
> needed.
>
>  not needed, roughly:
>     *objc*, *ada*, *lib*
>
>  needed, roughly:
>   *config*
>
>  unclear:
>   all the NULL to (void*) 0 diffs, which are a lot of it
>
>  I kinda'thunk:
>   #ifdef __cplusplus
>   #define NULL 0 /* would perhaps need patch, depending on what  
> calling conventions
>   do with parameters and return values smaller than a word */
>   #else
>   #define NULL ((void*) 0) /* no need for patch */
>   #endif
>
> in particular because in C++ a cast from void* to another* is  
> needed, but not in C.
>
> In fact I see this on OpenBSD:
>
>  #ifndef NULL
>  #ifdef  __GNUG__
>  #define NULL    __null
>  #else
>  #define NULL    0L
>  #endif
>
> Similar question for the AMD64_NT gcc patches, though these are  
> newer, apparently
> still need testing, and since they are new, more hope they will go  
> upstream.
> I don't know why the OpenBSD patches linger, I didn't ask.
>
> I'll proceed as my suggest takes but presumably won't be read to  
> commit
>   till after broader judgement/consensus rendered.
>
>   - Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Tue May 27 13:15:12 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 27 May 2008 11:15:12 +0000
Subject: [M3devel] gcc/m3cc/cm3c for OpenBSD?
In-Reply-To: <9B55DC75-DDBB-46F8-929F-2216922E39BE@cs.purdue.edu>
References: 
	<9B55DC75-DDBB-46F8-929F-2216922E39BE@cs.purdue.edu>
Message-ID: 

Tony, I'm not sure what your answer is below, but I commited #1  +#3.
 
 >> 1) import them m3-sys/m3cc/src/patches/openbsd >> 3) apply patches at build time
Obvious major danger with the current code is of accidentally commiting the patched files.
Perhaps something like copying files into the output and using VPATH can remove that danger.
Or perhaps if the accident occurs, it is easily undone? I don't know.
 
 >> 2) perhaps use a vendor branch for the import 
 
Could there be a vendor branch for "OpenBSD gcc" and then "mainline" is the merge of the various branches?
 
 
 - Jay


CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] gcc/m3cc/cm3c for OpenBSD?Date: Tue, 27 May 2008 10:37:31 +0100



On May 19, 2008, at 1:47 PM, Jay wrote:

What is the right way to handle these: http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/gcc/4.3/patches/I imagine: 1) import them m3-sys/m3cc/src/patches/openbsd 2) perhaps use a vendor branch for the import   however they haven't changed in 14 months   and HOPEFULLY they get ported upstream

Best this so later vendor upgrades don't confuse them with M3-related changes.

 3) apply patches at build timeSeems kind of bad, but I figure also too much to manage to checkin the patch results?I realize it stinks largely due to the risk of accidentally doing what is avoided.Maybe there is like "VPATH" and the to-be-patched files can be copied in the outputdirectory and patched there? They aren't all needed, by far, but definitely some of them are needed.  not needed, roughly:    *objc*, *ada*, *lib* needed, roughly:   *config*  unclear:  all the NULL to (void*) 0 diffs, which are a lot of it I kinda'thunk:  #ifdef __cplusplus  #define NULL 0 /* would perhaps need patch, depending on what calling conventions  do with parameters and return values smaller than a word */   #else  #define NULL ((void*) 0) /* no need for patch */   #endifin particular because in C++ a cast from void* to another* is needed, but not in C.In fact I see this on OpenBSD: #ifndef NULL #ifdef  __GNUG__ #define NULL    __null #else #define NULL    0L #endifSimilar question for the AMD64_NT gcc patches, though these are newer, apparentlystill need testing, and since they are new, more hope they will go upstream.I don't know why the OpenBSD patches linger, I didn't ask.I'll proceed as my suggest takes but presumably won't be read to commit  till after broader judgement/consensus rendered.  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Tue May 27 13:34:39 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 27 May 2008 11:34:39 +0000
Subject: [M3devel] function pointers and comparison to nil? mis-typed
 function pointers?
In-Reply-To: <7F087A94-FCF4-487C-8744-530F82B95F95@cs.purdue.edu>
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
	
	
	
	
	<7F087A94-FCF4-487C-8744-530F82B95F95@cs.purdue.edu>
Message-ID: 

gcc via the C front end does more -- it allows taking the address of a nested function, which generates code on the stack.
I have NOT looked at where the line is here between the C front end and the back end.
..but Ada and Pascal reportedly need this, and it is quite target-dependent, so presumably this is a back end feature.
Still, gcc's vaunted portability here is not clearly adequate consolation and merely shifting the work to it is not clearly a good move.
(besides the integrated backend and any hypothetical LLVM backend or C backend)
 
I was looking into this stuff because calling the module binders in RTLinker.m3 on SPARC64_OPENBSD hit an alignment fault, because SPARC64 instructions are 32bits and 32bit aligned (I guess) but SPARC64 integers are 64bits (definitely) and 64bit aligned (guess), and therefore the code to sniffs for the -1 faults. I'm well past this. The fix is simply to mark in Target.m3 procedures as not aligned and then the check for the -1 marker is preceded by a check of the alignment of the pointer, and unaligned pointers are presumed to not be closures.
 
I'd love to be able to say "This area is obviously messed up and it should be done such and such a way.", but the first is true and the second doesn't exist. Oh well.
My perfectionist and fixy/churny streak can only muster "I wonder how -1 decodes on various architectures and if more reliable per-target markers can be formulated.." esp. something that doesn't depend on invalid encodings, which could be reclaimed in the future for some new instrutions, but perhaps instead relies on valid encodings that would "never" be at the start of a function..though it is pretty hard to rule out anything -- maybe a jmp to 0? I realize that load/store instruction sets can't even necessarily encode that.
Nope -- x86 encodes jmps as PC-relative.
Ok -- indirect call:
 
7c901230 ff1500000000    call    dword ptr ds:[0]7c901236 0f84c4ed6f83    je      00000000
 
so ff 15 00 00 00 00 may be a better marker of "not code" than ff ff ff ff, on x86, maybe.
 
You know -1 may not be legal today, but it could be become legal in the future..
Whereas *arguably* call indirect 0 is "legal" today, so would not change meaning, but "never" occurs, so could be a marker, for some definition of "legal", "never", etc....
 
 - Jay


CC: rodney.bates at wichita.edu; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?Date: Tue, 27 May 2008 09:48:37 +0100gcc just allows computation of the static link.

I think there is an alternate compilation mode supported by the front-end for other platforms (like the integrated back end) but I have not looked at that closely.





On May 26, 2008, at 8:45 PM, Jay wrote:

It stinks either way imho.The portability is handled, somehow or another, by gcc's support for nested functions.For example on OpenBSD, they call mprotect to make the trampoline executable -- expensive! and leaves a bit of a security hole.On Linux you can sometimes mark the .exe as needing an executable stack or not. Similarly on Windows, linker has /nxcompat, /nxcompat:no switch.ATL on Windows puts trampolines in the heap and specifically makes them executable -- since the heap isn't necessarily executable either.The -1 marker is also a bit of a portability problem but I guess in practise it works out.I'd be curious to see how it decodes on various processors.  - Jay


CC: rodney.bates at wichita.edu; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?Date: Mon, 26 May 2008 14:38:53 +0100

Moving away from the current implementation would be a portability disaster because of the fact that gcc requires an executable stack for its nested function implementation which is non-portable.

On May 26, 2008, at 11:04 AM, Jay wrote:

Cygwin gcc clearly generates code on the stack for nested functions.And then search the web..that's how it works in general.Nested functions have been deprecated on Mac OS X, in anticipation of possibly making the stack not executable. OpenBSD doesn't allow execution on the stack.They use mprotect to let trampolines run:  http://gcc.gnu.org/ml/gcc/2004-01/msg00742.html and  http://resin.csoft.net/cgi-bin/man.cgi?section=1&topic=gcc-local  Even though nested functions are a gcc extension to the C language, email threads out there discuss Ada, Pascal, and even ! Modula-3 as having nested functions, and that therefore deprecating the C language feature doesn't "solve" the "problem". I remain uncertain what, if anything, to do here. - keep the -1 hack, do nothing     generalize it slightly to let targets pick "better" markers  - use gcc's supported for nested functions    (plus the integrated backend, not difficult)  Clearly this is a dilemna to more than just me. :)  - Jay


From: jayk123 at hotmail.comTo: rodney.bates at wichita.edu; m3devel at elegosoft.comDate: Mon, 26 May 2008 05:26:41 +0000Subject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?Rodney, this agrees with much of what I figured out and guessed. I did not think of or look into some of what you point out though:  - what gcc's nested functions look like, and if you can take the address, and what that does   - calling Modula-3 nested functions as callbacks from C  Now, regarding trampolines.I alluded to them. It should be easy enough to generate them, and this would solve a few problems, but I believe also bring up a new big problem.Generating trampolines solves at least two problems:  - it allows Modula-3 nested function pointers ("closures") to be called from C  - it enables removing the check for -1  I contend that the check for -1 is not good. It is a somewhat risky assumption, that "-1" is not valid code.You do bring up a nice mitigation -- the assumption that it doesn't begin any functions, which is much narrower than it being valid code anywhere. For SPARC64_OPENBSD I figured out what the original authors meant to be the fix.You declare functions as not aligned, leading to the check for -1 first checking alignment (bigger code).Any pointer not aligned on an integer-sized address is presumed not a closure and not checked for the -1.This lets SPARC64_OPENBSD get further. Both it and PPC32_OPENBSD now for some reason suffer from an inability to heap allocate anything, failing around the attempt to create a new thread like in RTAllocator_M or so. I'll look into this more later.Now, the problem of trampolines..I consider the platform-dependent-ness to be surmountable.But where do you put the generated code? Putting it on the stack is counter to modern (and possibly old) "security" mechanisms.The stack is not generally executable, and even when it is, best just not do use that imho. That means, potentially/obviously, the need to heap allocate executable memory, for very small short lived data, quite inefficient. Is there some other way/place to produce trampolines, efficiently? In the absence of any good solution, I have to resign myself to assuming that -1 isn't the valid start of a function, and perhaps moving the marker into Target.i3, Target.m3 so that "more obvious" values get chosen. Like a breakpoint. Or "an epilogue", or "a trap instruction". I realize this needs details and is easily seen as "wrong". In particular, a function that does nothing could be termed as only having an "an epilogue". I know that other systems are "forced" to create "trampolines" so I should look into how they do that.I know that ATL, a Windows-specific library, is forced to heap allocate small executable chunks of memory and uses an efficient cache to optimize it. I do find this dependence on -1 not being the valid start of a function rather sleazy and at risk of being wrong.  - Jay

> Date: Sun, 25 May 2008 22:50:15 -0500> From: rodney.bates at wichita.edu> To: m3devel at elegosoft.com> Subject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?> > I think I can shed some light on this, having spent some time making> m3gdb handle the various operations on nested procedures. As for code> that mixes M3 and C, I believe the following are true:> > - Within M3 code only, the closure system works correctly in all cases.> This answers one of Jay's worries.> > - For values of M3 procedure/C function pointer that are top-level> (nonnested) procedures/functions, M3 and C code (generated by gcc,> at least) are interchangeable. This answers another of Jay's worries.> This will cover that great majority of cases.> > - Standard C has no nested functions. Gcc adds them as a language> extension. Thus, only in gcc-compiled C code do we need to worry> about nested procedures/functions between languages. (Do any other> C compilers exist that also have nested functions?)> > - M3 code should be able to call the value of a procedure variable> that was originally produced by C code as a pointer to a nested> function, and get the environment set up right, so its nonlocal> variable references will work, _if_ the nested function's> environment has not disappeared. This partially answers another> of Jay's worries. But:> > - M3's normal runtime check that precludes assigning a nonlocal> procedure value will not detect a C-code-produced nonlocal value,> thus the environment could indeed have disappeared if the programmer> was not careful. However, gcc-extended C's nested functions have> no protection against this bug when only C code is involved, so> perhaps not detecting it in mixed M3/C is to be expected.> > - C code that attempts to call a function pointer value that was> originally produced by M3 code as a nested procedure value will> almost certainly crash at the time of the call. This is the only> case that presents a significant problem. M3 code will not be> able to give a nested procedure as a callback to a C library.> > M3's mechanism: A value of procedure type is a pointer to either> 1) the first byte of the procedure's machine code, if it is top level, or> 2) A closure.> > A closure is a block of 3 words. The first word contains -1. Assuming> a word of all one bits is not valid machine code on any target machine> (or at least doesn't occur as the first code of any procedure), this can> be used at runtime to detect that this is indeed a closure and not code.> The remaining two words hold the code address and the environment address.> > So, an assignment of a procedure value has to check that it is not a closure,> and raise a runtime error if it is. A call on a procedure value has to check,> and if it is a closure, load/copy its environment pointer value into wherever> the calling convention expects it, then branch to the code address. Passing> a nested procedure constant as a parameter involves constructing a closure for> it and passing its address.> > gcc-C's mechanism: A value of type pointer to function is a pointer to either> 1) the first byte of the function's machine code, if it is top level,> (the same as with M3), or> 2) A trampoline.> > A trampoline is a bit of code that loads/copies an environment pointer (hard> coded into the trampoline) and then branches to the function code.> > Trampolines probably have a small constant-time speed advantage for _calls_,> but would be slower for some of the other operations, and the runtime check> could be tricky. Probably it could be fooled into failing when it shouldn't.> Moreover, trampolines are highly target-machine-dependent. Switching to them> would create a really big problem for m3gdb, which would have to have> different code for each target for each of the nested procedure operations.> > Jay wrote:> > I see somewhat.> > It's stuff around "closure".> > The comparison of code bytes to -1 comes from If_closure for example.> > > > The problem is presumably to come up with a unified representation of > > pointers to functions that may or may not be nested, while avoiding > > runtime codegen, even just a little bit, and for Modula-3 and C function > > pointers to use the same representation.> > I don't think the present solution is really valid, and I am skeptical > > that there is a solution.> > One of the requirements has to be dropped.> > Sniffing code bytes and trying to decide if they are code or not as > > appears to currently happen is bogus.> > > > I think the solution is to remove the requirement that a Modula-3 > > function pointer and a C function pointer are the same.> > Except, well, that probably doesn't work -- it means you need two types > > of function pointers.> > > > Darn this is a hard problem.> > > > The runtime codegen required can be exceedingly simple, fast, and small > > IF it were allowed to be on the stack. But that's a killer these days.> > > > I think you have to give up unification of "closures" and "function > > pointers".> > If you take the address of a nested function and call it, you cannot > > access the locals of the enclosing scopes.> > So in affect, you end up with "two types of function pointers".> > Regular stateless ones and "closures" with some captured state.> > > > Thoughts?> > > > I'm kind of stumped. It's a desirable problem to solve, and there is a > > purported solution in place, but the solution that is there is > > completely bogus, despite appearing to work for a long time, and there > > is no solution. That is my understanding. I could be wrong on any number > > of points but I'm pretty sure.> > > > I think you have to separate out function pointers and closures.> > Sniffing what it pointed to is dubous esp. as currently implemented.> > If this is really the way to go, then signature bytes need to be worked > > out for all architectures that are guaranteed to not look like code.> > Or vice versa -- signature bytes worked out that all functions start > > with, which is viable for Modula-3 but not for interop with C.> > Currently -1 is used, of pointer-size.> > That appears to be reasonable for x86:> > > > 0:000> eb . ff ff ff ff> > 0:000> u .> > ntdll32!DbgBreakPoint:> > 7d61002d ff ???> > 7d61002e ff ???> > 7d61002f ff ???> > 7d610030 ffc3 inc ebx> > > > but the instruction encodings or disassembly on other architectures > > would have to be checked.> > > > - Jay> > > > ------------------------------------------------------------------------> > From: jayk123 at hotmail.com> > To: m3devel at elegosoft.com> > Date: Sun, 25 May 2008 00:16:01 +0000> > Subject: [M3devel] function pointers and comparison to nil?> > mis-typed function pointers?> > > > I'm being lazy...> > > > Tony can you explain this stuff?> > > > Comparison of function pointers..> > What are the various representations and rules?> > > > What does it mean to compare nested functions?> > > > What does it mean to compare a function to NIL?> > > > I'll poke around more.> > > > What I am seeing is that comparison of function pointers to NIL is> > surprisingly> > expensive, and probably somewhat buggy. Or at least some of the runtime> > generated "metadata-ish" stuff is produced or typed incorrectly.> > > > In particular, RTLinker.m3:> > > > PROCEDURE AddUnit (b: RT0.Binder) => > VAR m: RT0.ModulePtr;> > BEGIN> > IF (b = NIL) THEN RETURN END; line 119> > m := b(0); line 120> > IF (m = NIL) THEN RETURN END; line 121> > AddUnitI(m); line 122> > END AddUnit;> > > > generates a lot of code, just for the first line:> > (556) set_source_line > > source line 119 > > (557) load > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb > > (558) load_nil > > (559) if_eq > > (560) load > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb > > (561) load_indirect > > load address offset 0x0 src_t 0x5 dst_t 0x5 > > (562) load_integer > > integer n_bytes 0x0 hi 0x0 low 0x1 sign -1 > > (563) if_eq > > (564) set_label > > (565) load_nil > > (566) load > > m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb > > (567) if_ne > > (568) set_label > > (569) exit_proc > > (570) set_label > > (571) set_source_line > > source line 120 > > > > The details on the load_integer trace might not be completely> > correct. I will test a fix shortly.> > Esp. that n_bytes gets decremented to zero before the trace.> > > > Ok, I see now why some of the bloat -- because the "then return end"> > is on the same line.> > If it were written as:> > if (b = NIL THEN > > return> > end > > It probably wouldn't look so bad. That took me a while to realize.> > > > The following is generated for SPARC64_OPENBSD:> > > > line 119> > .stabn 68,0,119,.LLM61-.LLFBB4> > .LLM61:> > ldx [%fp+2175], %g1> > brz %g1, .LL26> > nop> > ldx [%fp+2175], %g1> > ldx [%g1], %g1 bus error here? yes, probably this one> > cmp %g1, -1> > be %xcc, .LL27> > nop> > .LL26:> > ldx [%fp+2175], %g1> > brz %g1, .LL33> > nop> > .LL27:> > line 120> > .stabn 68,0,120,.LLM62-.LLFBB4> > .LLM62:> > ldx [%fp+2175], %g1> > stx %g1, [%fp+2007]> > ldx [%fp+2007], %g1> > brz %g1, .LL30> > nop> > ldx [%fp+2007], %g1> > ldx [%g1], %g1 or here ?> > cmp %g1, -1> > bne %xcc, .LL30> > nop> > ldx [%fp+2007], %g1> > add %g1, 16, %g1> > ldx [%g1], %g1 or here?> > stx %g1, [%fp+2015]> > ldx [%fp+2007], %g1> > add %g1, 8, %g1> > ldx [%g1], %g1> > stx %g1, [%fp+2007]> > .LL30:> > ldx [%fp+2007], %g1> > ldx [%fp+2015], %g5> > mov 0, %o0> > call %g1, 0> > nop> > mov %o0, %g1> > stx %g1, [%fp+2023]> > ldx [%fp+2023], %g1> > stx %g1, [%fp+1999]> > > > line 121> > > > .stabn 68,0,121,.LLM63-.LLFBB4> > .LLM63:> > ldx [%fp+1999], %g1> > brz %g1, .LL33> > nop> > .LL32:> > .stabn 68,0,122,.LLM64-.LLFBB4> > .LLM64:> > > > g1 points to RTSignal_I3> > > > (gdb) x/i $pc> > 0x3ff0a8 : ldx [ %g1 ], %g1> > (gdb) x/i $g1> > 0x4021f4 : save %sp, -208, %sp> > > > I am willing to accept that a "function pointer" is a pair of> > pointers, or even three pointers.> > A pointer to code, a pointer to globals for position independent> > code, a frame pointer to locals.> > That equality comparison of function pointers requires comparing two> > (or three) pointers.> > (Though the global pointer shouldn't need comparing.)> > At least for nested functions. Less so for non-nested. ?> > Much less for comparison to NIL. ?> > > > And either way, this code is reading bogus data.> > There isn't a pointer at the function address, there is code.> > > > Something doesn't add up.> > > > I'm going to try setting "aligned procedures" but that's quite bogus> > I think.> > > > EqualExpr.m3 says> > > > Note: procedures pointers are always aligned!> > > > but maybe not?> > > > Yeah yeah I'm being lazy. I'll read more code..> > > > I also wonder if a "function pointer" can be optimized for the case> > of not being to a nested function.> > It looks like calling a function pointer is very inefficient.> > It looks like..am I reading that correctly?.. that if the pointer> > points to -1, then it is nested and> > a pair of pointers, and not otherwise. That -1 is treated specially> > as the first bytes of a function?> > Is that a Modula-3-ism or a SPARC-ism?> > It looks like a Modula-3-ism. And it seems dubious.> > But I'll have to read more..> > > > NT386GNU does the same sort of wrong looking thing:> > > > LFBB4:> > pushl %ebp> > movl %esp, %ebp> > subl $24, %esp> > LBB5:> > .stabn 68,0,117,LM60-LFBB4> > LM60:> > movl $0, -16(%ebp)> > .stabn 68,0,119,LM61-LFBB4> > LM61:> > movl 8(%ebp), %eax> > testl %eax, %eax> > je L26> > movl 8(%ebp), %eax> > movl (%eax), %eax BAD> > cmpl $-1, %eax BAD> > je L27> > L26:> > movl 8(%ebp), %eax> > testl %eax, %eax> > je L33> > L27:> > .stabn 68,0,120,LM62-LFBB4> > LM62:> > > > > > and NT386:> > > > 0:000> u> > cm3!RTLinker__AddUnit:> > 00607864 55 push ebp> > 00607865 8bec mov ebp,esp> > 00607867 81ec0c000000 sub esp,0Ch> > 0060786d 53 push ebx> > 0060786e 56 push esi> > 0060786f 57 push edi> > 00607870 c745fc00000000 mov dword ptr [ebp-4],0> > 00607877 837d0800 cmp dword ptr [ebp+8],0> > 0:000> u> > cm3!RTLinker__AddUnit+0x17:> > 0060787b 0f840f000000 je cm3!RTLinker__AddUnit+0x2c (00607890)> > 00607881 8b7508 mov esi,dword ptr [ebp+8]> > 00607884 8b5e00 mov ebx,dword ptr> > [esi] BAD > > 00607887 83fbff cmp > > ebx,0FFFFFFFFh BAD> > 0060788a 0f840f000000 je cm3!RTLinker__AddUnit+0x3b (0060789f)> > 00607890 837d0800 cmp dword ptr [ebp+8],0> > 00607894 0f8505000000 jne cm3!RTLinker__AddUnit+0x3b (0060789f)> > 0060789a e969000000 jmp cm3!RTLinker__AddUnit+0xa4 (00607908)> > > > cm3!RTLinker__AddUnit+0x20:> > 00607884 8b5e00 mov ebx,dword ptr [esi] > > ds:002b:0062c950=81ec8b55> > 0:000> u @esi> > cm3!RTLinker_I3:> > 0062c950 55 push ebp> > 0062c951 8bec mov ebp,esp> > 0062c953 81ec00000000 sub esp,0> > 0062c959 53 push ebx> > 0062c95a 56 push esi> > 0062c95b 57 push edi> > 0062c95c 837d0800 cmp dword ptr [ebp+8],0> > 0062c960 0f8400000000 je cm3!RTLinker_I3+0x16 (0062c966)> > > > This is just wrong.> > Comparing bytes of code to -1.> > > > I think the likely fix is for the "I3" code to be laid out as a> > "constant function pointer", a pointer to a pair of pointers where> > one points to the code and one is to -1. Something like that. That> > can't be quite correct given that the existing data is callable.> > > > - Jay> > -- > -------------------------------------------------------------> Rodney M. Bates, retired assistant professor> Dept. of Computer Science, Wichita State University> Wichita, KS 67260-0083> 316-978-3922> rodney.bates at wichita.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From wagner at elegosoft.com  Tue May 27 14:44:52 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 27 May 2008 14:44:52 +0200
Subject: [M3devel] gcc/m3cc/cm3c for OpenBSD?
In-Reply-To: 
References: 
	<9B55DC75-DDBB-46F8-929F-2216922E39BE@cs.purdue.edu>
	
Message-ID: <20080527144452.f6j8bolwgksw0wsc@mail.elegosoft.com>

Quoting Jay :

> Tony, I'm not sure what your answer is below, but I commited #1  +#3.
>
>  >> 1) import them m3-sys/m3cc/src/patches/openbsd >> 3) apply   
> patches at build time
> Obvious major danger with the current code is of accidentally   
> commiting the patched files.
> Perhaps something like copying files into the output and using VPATH  
>  can remove that danger.
> Or perhaps if the accident occurs, it is easily undone? I don't know.
>
>  >> 2) perhaps use a vendor branch for the import
>
> Could there be a vendor branch for "OpenBSD gcc" and then "mainline"  
>  is the merge of the various branches?

CVS does only really support _one_ vendor branch, even if some
docs say otherwise. So if the original gcc sources are on a vendor
branch, openbsd changes for examples should be imported on another
branch, and then explicitly merged (vendor branch is merged implicitly,
which is arguably a feature or a bug ;-)

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  Tue May 27 15:59:26 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 27 May 2008 15:59:26 +0200
Subject: [M3devel] FW: NT386 environment variables (new NT386	snapshots)
In-Reply-To: 
References: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
	
	<4823279D.1E75.00D7.1@scires.com>
	
Message-ID: <20080527155926.203bam89w4w0kgko@mail.elegosoft.com>

Quoting Jay :

> truncated again...
> m3support -- nothing interesting in any logs regarding my mail?
> And nobody else uses hotmail, right?

@Ronny, can you please check if our mail logs reveal any reason
for Jay's mails to be truncated now and then?

>> I will apply an easy fix.
> done

I'm not sure if this means that the issues concerning evnironment
variable access (both via Env and RTArgs) are now fixed for NT386(GNU)...
Can we forget about this issue?

Olaf

> From: jayk123 at hotmail.comTo: rcoleburn at scires.com;   
> m3devel at elegosoft.comSubject: RE: [M3devel] NT386 environment   
> variables (new NT386 snapshots)Date: Fri, 9 May 2008 07:44:09 +0000
>
>
>  > these problems (pixmaps, buildstandalone, environ vars, serial   
> i/o, etc...  Ok, here is the story with environment variables.I   
> tested 3.6 and current, gui and console.This is the   
> program:C:\dev2\j\m3\3>type src\m3makefileimport ("m3core")import   
> ("libm3")m3_option ("-gui")     twiddle this line in and out with a   
> commentimplementation ("Main")program ("pgm") C:\dev2\j\m3\3>type   
> src\Main.m3MODULE Main;IMPORT IO;IMPORT RTArgs; BEGIN(* IO.Put just   
> crashes in 3.6 gui apps *)  IO.Put(RTArgs.GetArg(2));    
> IO.Put(RTArgs.GetEnv(2)); (* use this for gui apps *)  EVAL   
> RTArgs.GetArg(2);  EVAL RTArgs.GetEnv(2);END Main.In 3.6 console   
> apps, RTArgs.GetEnv returns garbage. That makes sense from the   
> code.In current console apps, GetEnv works.In current gui apps,   
> GetEnv access violates, or returns an invalid pointer.  This also   
> makes sense from the code.Randy, does this actually work for you?I'd  
>  be quite surprised.I haven't tried 4.1 yet, just 3.6 and current.I   
> will apply an easy fix. - Jay
>
>
> Date: Thu, 8 May 2008 16:17:37 -0400From: rcoleburn at scires.comTo:   
> m3devel at elegosoft.comSubject: Re: [M3devel] new NT386 snapshots
> Jay:
>
> I have both console and gui programs built using 4.1 that do pull   
> stuff out of the environment.  I've not noticed any problems with   
> either mode.
>
> From my perspective, the old 4.1 seems more reliable than the   
> current system in a number of respects.  I have a new project with a  
>  hard deadline that I would like to use the new cm3 system for, but   
> until these problems (pixmaps, buildstandalone, environ vars, serial  
>  i/o, etc.) can be resolved, I'm going to keep using 4.1 for my   
> production work.
>
> Regards,
> Randy>>> Jay  5/8/2008 2:46 PM   
> >>>http://modula3.elegosoft.com/cm3/uploaded-archives/   
> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0.ziphttp://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-WIN32-NT386-d5.7.0.ziphttp://modula3.elegosoft.com/cm3/uploaded-archives/cm3-std-WIN32-NT386-d5.7.0-symbols.zip These should have:  latest quake extensions   set relation fixes   other set fixes revealed through dynamic linking of one regression test   hypothetical ability to cross-build to AMD64_LINUX, AMD64_DARWIN    one jmpbuf size for all NT386 configurations (NT386, NT386GNU, NT386MINGNU)  Built with Visual C++ 9.0 Express, so you'll want:http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en  Still more work to do though, e.g. assertion failures in unit tests, pixmap.. Fuller disclosure:Something is leaking memory on my system such that "everything" starts "failing" and I have to reboot.This isn't Modula-3 related.Hopefully these files aren't damaged as a result.Must be some buggy driver or something.. Aside: The environment variable thingy has been bugging me a long time and I finally looked deeper at it.It appears broken in CM3 4.x. I didn't check 3.x yet.I'm still mulling a fix, and haven't run a repro of the break, but it's not a big deal either way.Basically console apps use main that takes char** and gui apps use WinMain that doesn't get environment variables but the generated code calls GetEvironmentStrings() which returns null separated strings.Must be that hardly anyone uses environment variables in Modula-3 on Win32 for this to have lingered so long, at least gui apps.  -   
> 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 hosking at cs.purdue.edu  Tue May 27 15:56:51 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 27 May 2008 14:56:51 +0100
Subject: [M3devel] function pointers and comparison to nil? mis-typed
	function pointers?
In-Reply-To: 
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
	
	
	
	
	<7F087A94-FCF4-487C-8744-530F82B95F95@cs.purdue.edu>
	
Message-ID: <551F22B1-0098-4828-A91B-3FD4E368231A@cs.purdue.edu>

On May 27, 2008, at 12:34 PM, Jay wrote:

> gcc via the C front end does more -- it allows taking the address of  
> a nested function, which generates code on the stack.
> I have NOT looked at where the line is here between the C front end  
> and the back end.
> ..but Ada and Pascal reportedly need this, and it is quite target- 
> dependent, so presumably this is a back end feature.
> Still, gcc's vaunted portability here is not clearly adequate  
> consolation and merely shifting the work to it is not clearly a good  
> move.
> (besides the integrated backend and any hypothetical LLVM backend or  
> C backend)

True, but it is deprecated and doesn't work on all platforms because  
of stack non-executability.  We compute the static chain using gcc's  
support as it is (with hacks to avoid computation of a function  
pointer via trampoline).

> I was looking into this stuff because calling the module binders in  
> RTLinker.m3 on SPARC64_OPENBSD hit an alignment fault, because  
> SPARC64 instructions are 32bits and 32bit aligned (I guess) but  
> SPARC64 integers are 64bits (definitely) and 64bit aligned (guess),  
> and therefore the code to sniffs for the -1 faults. I'm well past  
> this. The fix is simply to mark in Target.m3 procedures as not  
> aligned and then the check for the -1 marker is preceded by a check  
> of the alignment of the pointer, and unaligned pointers are presumed  
> to not be closures.

OK.

> I'd love to be able to say "This area is obviously messed up and it  
> should be done such and such a way.", but the first is true and the  
> second doesn't exist. Oh well.
> My perfectionist and fixy/churny streak can only muster "I wonder  
> how -1 decodes on various architectures and if more reliable per- 
> target markers can be formulated.." esp. something that doesn't  
> depend on invalid encodings, which could be reclaimed in the future  
> for some new instrutions, but perhaps instead relies on valid  
> encodings that would "never" be at the start of a function..though  
> it is pretty hard to rule out anything -- maybe a jmp to 0? I  
> realize that load/store instruction sets can't even necessarily  
> encode that.
> Nope -- x86 encodes jmps as PC-relative.
> Ok -- indirect call:
>
> 7c901230 ff1500000000    call    dword ptr ds:[0]
> 7c901236 0f84c4ed6f83    je      00000000
>
> so ff 15 00 00 00 00 may be a better marker of "not code" than ff ff  
> ff ff, on x86, maybe.
>
> You know -1 may not be legal today, but it could be become legal in  
> the future..
> Whereas *arguably* call indirect 0 is "legal" today, so would not  
> change meaning, but "never" occurs, so could be a marker, for some  
> definition of "legal", "never", etc....
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From hendrik at topoi.pooq.com  Tue May 27 17:45:51 2008
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Tue, 27 May 2008 11:45:51 -0400
Subject: [M3devel] function pointers and comparison to nil? mis-typed
	function pointers?
In-Reply-To: <483A3377.7070801@wichita.edu>
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
Message-ID: <20080527154551.GA24415@topoi.pooq.com>

On Sun, May 25, 2008 at 10:50:15PM -0500, Rodney M. Bates wrote:
> I think I can shed some light on this, having spent some time making
> m3gdb handle the various operations on nested procedures.  As for code
> that mixes M3 and C, I believe the following are true:
> 
> - Within M3 code only, the closure system works correctly in all cases.
>   This answers one of Jay's worries.

As long as procedure-entry code can be guaranteed never to start wit a 
word of one-bits.  We do have some influence on this code, though, and 
if necessary might be able to choose a different bit pattern on a 
specific platform.

> 
> - For values of M3 procedure/C function pointer that are top-level
>   (nonnested) procedures/functions, M3 and C code (generated by gcc,
>   at least) are interchangeable.  This answers another of Jay's worries.
>   This will cover that great majority of cases.

Yes.  And in many cases, we will know statically that this is the case.

> 
> - Standard C has no nested functions.  Gcc adds them as a language
>   extension.  Thus, only in gcc-compiled C code do we need to worry
>   about nested procedures/functions between languages.  (Do any other
>   C compilers exist that also have nested functions?)

Standard C has no nested function, and does not need closures.  As a 
result, Standard C can use simple pointers to represent function 
addresses.  The language extension retrofits closures using run-time 
code generation.  The way this is done (on the satck) is nonportable, 
and we'd like to avoid that nonportability.

The problem with seems to be just that you seem to want to use an 
address of a function as a function pointer, and that just doesn't have 
enough space in it to represent a closure.

But why do it that way?  Why not just let *all* Modula 3 functions be 
represented by closures?  Then you never have to test whether something 
is a closure, it just always is.  Top-level functions with no 
environment just use a null pointer as environment -- and never use it.

The only arguments for not doing this would seem to be 
(a) the waste of space, making functions a little larger than necessary, 
(b) and C compatibility.

Now (a) is probably a nonissue, since the vast majority of functions 
never have their addresses taken, are never passes as parameters to 
other procedures, and so forth.  So for the vast majority of functions, 
you simply never have to build the closure.

(b) might be a problem. The obvious trick is just to forbid passing to C 
a non-top-level function.  Since even the C programmers who devise 
interfaces with callbacks realise that just a functino pointer isn't 
enough, they usually provide a machanism for passing a void pointer to 
additional information the callback might need.  Nothing here puts 
Modula 3 at a disadvantage relative to C.  You can just use a top-level 
function and let the programmer provide it with whatever it needs.

But if it is deemed essential to provide actual single-pointer callback 
addresses, this can be done by using a built-in function to convert a 
procedure to a single-pointer callback.  This functin will have to be 
rewritten for each platform, and can allocate the necessary 
dynamically-genereated code on the heap (or, of course, on the stack, if 
possible on that platform).  As for portability, it's certianly no 
big deal to do this;  compared with writing a platform-dependent code 
generator (itself a requirement), this is not huge.

> - M3's normal runtime check that precludes assigning a nonlocal
>   procedure value will not detect a C-code-produced nonlocal value,
>   thus the environment could indeed have disappeared if the programmer
>   was not careful.  However, gcc-extended C's nested functions have
>   no protection against this bug when only C code is involved, so
>   perhaps not detecting it in mixed M3/C is to be expected.

We really can't protect against bugs in C code.  If we could prevent 
bugs in C, the market for it would be huge, and we'd be well advised to 
consider that our main business.

> 
> - C code that attempts to call a function pointer value that was
>   originally produced by M3 code as a nested procedure value will
>   almost certainly crash at the time of the call.  This is the only
>   case that presents a significant problem.  M3 code will not be
>   able to give a nested procedure as a callback to a C library.

Wherefor only in this case should we do run-time code generation.

It has been argued that we don't need to protect against C programmers 
going hog-wild and breaking their own code.  Such is the nature of C.

But, we can chack for some of it, it we are willing to go to the effort.  
The technique used in the CDC Algol 68 compiler long ago might even 
enable us to restrict the constraint on assigning nested procedures to 
variables by a suitable run-time check.

The CDC Algol 68 compiler had a trick for recognising expired scopes 
using the garbage collector.  Let's see if I can remember the details.  
It involved special treatment for procedures whose addresses are taken, 
and for the blocks that contain them.  When entering such a block at 
run-time, a word is allocated on the heap representing that scope.   It 
is filled with something relevant, such as the address if the stack 
frame for the block, and the stack frame also pointed to that scope-cell 
(as I'll describe it).  Taking the  address of a procedure involved 
building a closure that points to that scope-cell.  When leaving the 
block, the contents of the scope-cell is wiped to some recognisable 
invalid value.  When entering the procedure the scope-cell will 
still be around even if the scope is not.  The procedure (this is inside 
the procedure itself, not at the call) checks that the scope-cell has 
not been wiped, and therefore is still valid.  If valid, it contains the 
necessary environment information.  If not, break off execution.

-- hendrik


From dabenavidesd at yahoo.es  Wed May 28 04:10:05 2008
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 28 May 2008 02:10:05 +0000 (GMT)
Subject: [M3devel] garbage collection problem on LINUXLIBC6?
In-Reply-To: <406663.93255.qm@web27103.mail.ukl.yahoo.com>
Message-ID: <540006.79045.qm@web27102.mail.ukl.yahoo.com>

Dear developers:
I have finally understood that the issue was related with the terminal emulator from which I launched the M3 executables. All M3 executables are fine and working well.
Thanks for your attention.

--- 24/5/08, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> wrote:
De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] garbage collection problem on LINUXLIBC6?
Para: m3devel at elegosoft.com
Fecha: s?bado, 24 mayo, 2008 12:29

Hi:
I recently have compiled the cm3 system with good results on a 2-core machine on LINUXLIBC6, kubuntu of 32 bits. It runs gui applications of cm3 with no problems at all.
I think maybe the issue is related with something about the operating system, or at least the machine, I didn't check this until now.

Thanks

--- 19/5/08, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> wrote:
De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] garbage collection problem on LINUXLIBC6?
Para: m3devel at elegosoft.com, "Randy Coleburn"
 <rcoleburn at scires.com>
Fecha: lunes, 19 mayo, 2008 12:02

Hi again:
and the process is using the cpu very much (using top command)

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 9758 daniel    20   0 33644 3836 2684 R 60.0  0.7   1:05.17 draw

Thanks in advance.


--- 19/5/08, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> wrote:
De: Daniel Alejandro
 Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] garbage collection problem on LINUXLIBC6?
Para: m3devel at elegosoft.com, "Randy Coleburn" <rcoleburn at scires.com>
Fecha: lunes, 19 mayo, 2008 11:52

Hi Randy:
In my case, the program just doesn't start, maybe after some minutes yes, but obviously this is abnormal.
When I start mentor @M3tracelinker, I got after a lot of output the following lines and it just doesn't start after it:
  ../src/color/Color.i3(3)
  ../src/runtime/common/RTHooks.i3(3)
RunMainBody: exec: ../src/color/ColorNameTable.i3(3)
RunMainBody: exec: ../src/color/ColorNameF.i3(3)
RunMainBody: exec:
 ../src/color/ColorNa

But if I put @M3nogc @M3tracelinker the program starts and the output is:
RunMainBody: ../LINUXLIBC6/MentorBundle.m3(2)
  ../LINUXLIBC6/MentorBundle.i3(5)
  ../src/rw/TextWr.i3(3)
  ../src/rw/Wr.i3(3)
 
 ../src/thread/Common/Thread.i3(3)
  ../src/text/Text.i3(3)
  ../src/bundleintf/BundleRep.i3(3)
  ../src/bundleintf/Bundle.i3(3)
 
 ../src/runtime/common/RTHooks.i3(3)
RunMainBody: exec: ../LINUXLIBC6/MentorBundle.m3(3)
RunMainBody: exec: ../LINUXLIBC6/MentorBundle.i3(3)
RunMainBody: exec: ../src/Main.m3(3)

However when examining a simple gui program, the stdout shows the same  out for @M3tracelinker with or without garbage collection

  ../src/split/TextVBT.i3(5)
  ../src/runtime/common/RTHooks.i3(3)
RunMainBody: exec: ../src/split/TextVBTClass.i3(3)
RunMainBody: exec: ../src/split/TextVBT.m3(3)
RunMainBody: exec: ../src/split/TextVBT.i3(3)
RunMainBody: exec: ../src/Draw.m3(3)

If I run the program under m3gdb without parametres, breaking on RTLinker.RunMainBody, I got:
Breakpoint 3, RunMainBody (m=16_b7e108c0)
    at ../src/runtime/common/RTLinker.m3:349
349       VAR desc, desc2: InitPtr;  imp: RT0.ImportPtr;  m2:
 RT0.ModulePtr;
(m3gdb)
Continuando.

Breakpoint 3, RunMainBody (m=16_b7e10ba0)
    at ../src/runtime/common/RTLinker.m3:349
349       VAR desc, desc2: InitPtr;  imp: RT0.ImportPtr;  m2: RT0.ModulePtr;
(m3gdb)
Continuando.

Breakpoint 3, RunMainBody (m=16_b7e0b660)
    at ../src/runtime/common/RTLinker.m3:349
349       VAR desc, desc2: InitPtr;  imp: RT0.ImportPtr;  m2: RT0.ModulePtr;
(m3gdb)
Continuando.


[Nuevo Thread -1234015344 (LWP 9706)]
[Thread -1234015344 (LWP 9706) exited]

And the program hangs there.
And again the same situation on the stack trace when killing the process inside m3gdb (also got a segment violation on m3gdb):

(m3gdb) where
#0  0xb7fbf410 in __kernel_vsyscall ()
#1  0xb7108ae7 in pthread_kill () from
 /lib/tls/i686/cmov/libpthread.so.0
#2  0xb737c397 in SignalThread (act=16_08055d88, state=Stopping)
    at ../src/thread/PTHREAD/ThreadPThread.m3:1058
#3  0xb737c6dc in StopWorld () at ../src/thread/PTHREAD/ThreadPThread.m3:1142
#4  0xb737b9e7 in SuspendOthers ()
    at ../src/thread/PTHREAD/ThreadPThread.m3:905
#5  0xb7355244 in CollectSomeInStateZero ()
    at ../src/runtime/common/RTCollector.m3:755
#6  0xb7355203 in CollectSome () at ../src/runtime/common/RTCollector.m3:729
#7  0xb7354c24 in CollectEnough () at ../src/runtime/common/RTCollector.m3:656
#8  0xb73586c1 in AllocTraced (def=16_b7dfbfb4, dataSize=456, dataAlignment=4,
    initProc=Static link does not lead to a valid frame.
) at ../src/runtime/common/RTCollector.m3:1462
#9  0xb734af25 in GetTracedObj (def=16_b7dfbfb4)
    at
 ../src/runtime/common/RTAllocator.m3:206
#10 0xb734a9b0 in AllocateTracedObj (defn=16_b7dfbfb4)
    at ../src/runtime/common/RTAllocator.m3:131
#11 0xb7d63df5 in Connect (inst=NIL, trsl=NIL) at ../src/xvbt/XClientF.m3:495
#12 0xb7d66717 in DoConnect (self=16_b6f41d5c, inst=NIL, localOnly=FALSE,
    t=NIL) at ../src/xvbt/XClientF.m3:637
#13 0xb7d46c23 in DoConnect (self=16_b6f41d5c, inst=NIL, localOnly=FALSE,
    t=NIL) at ../src/xvbt/XClient.m3:1495
#14 0xb7d9962c in Connect (inst=NIL, localOnly=FALSE)
---Type <return> to continue, or q <return> to quit---
    at ../src/vbt/TrestleClass.m3:30
#15 0xb7df2117 in Default () at ../src/trestle/Trestle.m3:838
#16 0xb7ded789 in PreAttach (v=16_b6f41cf8, trsl=NIL)
    at ../src/trestle/Trestle.m3:264
#17 0xb7deb95b in Install (v=16_b6f41cf8, applName=NIL, inst=NIL,
Fallo de
 segmentaci?n


Maybe could be some gcc backend issue?
I would like to know if others have the same problem.
Thanks.
  
--- 19/5/08, Randy Coleburn <rcoleburn at scires.com> wrote:
De: Randy Coleburn <rcoleburn at scires.com>
Asunto: Re: [M3devel] garbage collection problem on LINUXLIBC6?
Para: m3devel at elegosoft.com
Fecha: lunes, 19 mayo, 2008 10:08


 
Daniel, I have this same problem on GUI applications created on cm3 v4.1.  If I don't put "@M3novm" on the command line, the programs crash during startup.  It has something to do with the garbage collector.  In my testing of cm3 d5.7.0 on Windows XP, I have not run into the problem yet, so I think Tony has fixed it with his new garbage collector, at least on Windows.
Regards,
Randy

>>> "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> 5/18/2008 6:39 PM >>>




Dear developers:
I'm running a new installed cm3 on an ubuntu 8.04 32 bits, and I can't run anything with gui if I don't use @M3nogc
The rest of the applications, the compiler, and m3browser seem to work without problems ??
I'm debugging mentor but I just got this until now:
Breakpoint 5, Init () at ../src/color/ColorName.m3:207
207           IF table.put (NormalizeName (Basic [i].name), i) THEN
(m3gdb) where
#0  Init () at ../src/color/ColorName.m3:207
#1  0xb7c7b7ff in ColorName (mode=1) at ../src/color/ColorName.m3:214
#2  0xb70e2389 in RunMainBody (m=16_b7ca2fa0) at ../src/runtime/common/RTLinker.m3:399
#3  0xb70e2055 in RunMainBody (m=16_b7d38100) at ../src/runtime/common/RTLinker.m3:379
#4  0xb70e2055 in RunMainBody (m=16_b7d2fe20) at ../src/runtime/common/RTLinker.m3:379
#5  0xb70e2055 in RunMainBody (m=16_b7d34480) at
 ../src/runtime/common/RTLinker.m3:379
#6  0xb70e2055 in RunMainBody (m=16_b7d30d60) at ../src/runtime/common/RTLinker.m3:379
#7  0xb70e2055 in RunMainBody (m=16_b7d4d620) at ../src/runtime/common/RTLinker.m3:379
#8  0xb70e2055 in RunMainBody (m=16_b7e31d80) at ../src/runtime/common/RTLinker.m3:379
#9  0xb70e2055 in RunMainBody (m=16_b7e33220) at ../src/runtime/common/RTLinker.m3:379
#10 0xb70e2055 in RunMainBody (m=16_b7e36d40) at ../src/runtime/common/RTLinker.m3:379
#11 0xb70e2055 in RunMainBody (m=16_b7e364e0) at ../src/runtime/common/RTLinker.m3:379
#12 0xb70e2055 in RunMainBody (m=16_b7e36ba0) at ../src/runtime/common/RTLinker.m3:379
#13 0xb70e2055 in RunMainBody (m=16_b7e32cc0) at ../src/runtime/common/RTLinker.m3:379
#14 0xb70e2055 in RunMainBody (m=16_b7e32900) at ../src/runtime/common/RTLinker.m3:379
#15 0xb70e2055 in RunMainBody (m=16_08255600) at ../src/runtime/common/RTLinker.m3:379
#16
 0xb70e2055 in RunMainBody (m=16_08256040) at ../src/runtime/common/RTLinker.m3:379
#17 0xb70e2055 in RunMainBody (m=16_08312aa0) at ../src/runtime/common/RTLinker.m3:379
#18 0xb70e0dff in AddUnitI (m=16_08312aa0) at ../src/runtime/common/RTLinker.m3:113
#19 0xb70e0e8d in AddUnit (b={"Main_M3", Declared at: ../src/Main.m3:164}) at ../src/runtime/common/RTLinker.m3:122
#20 0x0806df1e in main (argc=3, argv=0xbfa03774, envp=0xbfa03784) at _m3main.mc:4
#21 0xb6d44450 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#22 0x0806de71 in _start ()
(m3gdb) cont
Continuando.

Breakpoint 5, Init () at ../src/color/ColorName.m3:207
207           IF table.put (NormalizeName (Basic [i].name), i) THEN
(m3gdb) cont
and the process hangs there when debugging mentor.

I have checked  Juno under m3gdb after have killed it and got:

(m3gdb) where
#0 
 0xb7fb0410 in __kernel_vsyscall ()
#1  0xb7018ae7 in pthread_kill () from /lib/tls/i686/cmov/libpthread.so.0
#2  0xb728c397 in SignalThread (act=16_0813c120, state=Stopping) at ../src/thread/PTHREAD/ThreadPThread.m3:1058
#3  0xb728c55e in StopWorld () at ../src/thread/PTHREAD/ThreadPThread.m3:1116
#4  0xb728b9e7 in SuspendOthers () at ../src/thread/PTHREAD/ThreadPThread.m3:905
#5  0xb7265244 in CollectSomeInStateZero () at ../src/runtime/common/RTCollector.m3:755
#6  0xb7265203 in CollectSome () at ../src/runtime/common/RTCollector.m3:729
#7  0xb7264c24 in CollectEnough () at ../src/runtime/common/RTCollector.m3:656
#8  0xb72686c1 in AllocTraced (def=16_b7be1400, dataSize=12, dataAlignment=4, initProc=NIL)
    at ../src/runtime/common/RTCollector.m3:1462
#9  0xb725ad8f in GetTracedRef (def=16_b7be1400) at ../src/runtime/common/RTAllocator.m3:191
#10 0xb725a987
 in AllocateTracedRef (defn=16_b7be1400) at ../src/runtime/common/RTAllocator.m3:126
#11 0xb7b5d8fb in Put (tbl=16_b6e50438, key=8047, val=244) at ../LINUXLIBC6/IntIntTbl.m3 => ../src/table/Table.mg:127
#12 0xb7dd4e2c in Set (a='>', b='o', c=244, bothCases=FALSE, reversed=TRUE) at ../src/etext/KeyFilter.m3:288
#13 0xb7dd521c in Set (a='o', b='>', c=244, bothCases=FALSE, reversed=FALSE) at ../src/etext/KeyFilter.m3:304
#14 0xb7dd5882 in KeyFilter (mode=1) at ../src/etext/KeyFilter.m3:437
#15 0xb7273389 in RunMainBody (m=16_b7e51da0) at ../src/runtime/common/RTLinker.m3:399
#16 0xb7273055 in RunMainBody (m=16_b7e547e0) at ../src/runtime/common/RTLinker.m3:379
#17 0xb7273055 in RunMainBody (m=16_b7e56c00) at ../src/runtime/common/RTLinker.m3:379
#18 0xb7273055 in RunMainBody (m=16_b7e54240) at ../src/runtime/common/RTLinker.m3:379
#19 0xb7273055 in RunMainBody (m=16_b7e537e0) at
 ../src/runtime/common/RTLinker.m3:379
#20 0xb7273055 in RunMainBody (m=16_080b85a0) at ../src/runtime/common/RTLinker.m3:379
#21 0xb7271dff in AddUnitI (m=16_080b85a0) at ../src/runtime/common/RTLinker.m3:113
#22 0xb7271e8d in AddUnit (b={"Juno_M3", Declared at: ../src/Juno.m3:1974}) at ../src/runtime/common/RTLinker.m3:122
#23 0x0805120e in main (argc=1, argv=0xbf96ff14, envp=0xbf96ff1c) at _m3main.mc:4
#24 0xb6ed5450 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#25 0x08051161 in _start ()


When killing mentor under m3gdb it shows like the same back trace:
(m3gdb) where
#0  0xb70fb39a in SignalThread (act=16_0834ff08, state=Stopping) at ../src/thread/PTHREAD/ThreadPThread.m3:1058
#1  0xb70fb6dc in StopWorld () at ../src/thread/PTHREAD/ThreadPThread.m3:1142
#2  0xb70fa9e7 in SuspendOthers () at ../src/thread/PTHREAD/ThreadPThread.m3:905
#3  0xb70d4244 in CollectSomeInStateZero
 () at ../src/runtime/common/RTCollector.m3:755
#4  0xb70d4203 in CollectSome () at ../src/runtime/common/RTCollector.m3:729
#5  0xb70d3c24 in CollectEnough () at ../src/runtime/common/RTCollector.m3:656
#6  0xb70d76c1 in AllocTraced (def=16_b712d934, dataSize=24, dataAlignment=4, initProc=Static link does not lead to a valid frame.
)
    at ../src/runtime/common/RTCollector.m3:1462
#7  0xb70c9f25 in GetTracedObj (def=16_b712d934) at ../src/runtime/common/RTAllocator.m3:206
#8  0xb70c99b0 in AllocateTracedObj (defn=16_b712d934) at ../src/runtime/common/RTAllocator.m3:131
#9  0xb710d586 in New (a={'a','z','u','r','e','4'}) at ../src/text/Text8Short.m3:16
#10 0xb710ce87 in New (a={'a','z','u','r','e','4'}) at ../src/text/Text8.m3:18
#11 0xb710ba9d in FromChars (a={'a','z','u','r','e','4'}) at ../src/text/Text.m3:206
#12 0xb7c7a62f in NormalizeName (a=16_b7ca378c) at
 ../src/color/ColorName.m3:83
#13 0xb7c7b789 in Init () at ../src/color/ColorName.m3:207
#14 0xb7c7b7ff in ColorName (mode=1) at ../src/color/ColorName.m3:214
#15 0xb70e2389 in RunMainBody (m=16_b7ca2fa0) at ../src/runtime/common/RTLinker.m3:399
#16 0xb70e2055 in RunMainBody (m=16_b7d38100) at ../src/runtime/common/RTLinker.m3:379
#17 0xb70e2055 in RunMainBody (m=16_b7d2fe20) at ../src/runtime/common/RTLinker.m3:379
#18 0xb70e2055 in RunMainBody (m=16_b7d34480) at ../src/runtime/common/RTLinker.m3:379
#19 0xb70e2055 in RunMainBody (m=16_b7d30d60) at ../src/runtime/common/RTLinker.m3:379
#20 0xb70e2055 in RunMainBody (m=16_b7d4d620) at ../src/runtime/common/RTLinker.m3:379
#21 0xb70e2055 in RunMainBody (m=16_b7e31d80) at ../src/runtime/common/RTLinker.m3:379
#22 0xb70e2055 in RunMainBody (m=16_b7e33220) at ../src/runtime/common/RTLinker.m3:379
#23 0xb70e2055 in RunMainBody (m=16_b7e36d40) at
 ../src/runtime/common/RTLinker.m3:379
#24 0xb70e2055 in RunMainBody (m=16_b7e364e0) at ../src/runtime/common/RTLinker.m3:379
#25 0xb70e2055 in RunMainBody (m=16_b7e36ba0) at ../src/runtime/common/RTLinker.m3:379
#26 0xb70e2055 in RunMainBody (m=16_b7e32cc0) at ../src/runtime/common/RTLinker.m3:379
#27 0xb70e2055 in RunMainBody (m=16_b7e32900) at ../src/runtime/common/RTLinker.m3:379
#28 0xb70e2055 in RunMainBody (m=16_08255600) at ../src/runtime/common/RTLinker.m3:379
#29 0xb70e2055 in RunMainBody (m=16_08256040) at ../src/runtime/common/RTLinker.m3:379
#30 0xb70e2055 in RunMainBody (m=16_08312aa0) at ../src/runtime/common/RTLinker.m3:379
#31 0xb70e0dff in AddUnitI (m=16_08312aa0) at ../src/runtime/common/RTLinker.m3:113
#32 0xb70e0e8d in AddUnit (b={"Main_M3", Declared at: ../src/Main.m3:164}) at ../src/runtime/common/RTLinker.m3:122
#33 0x0806df1e in main (argc=3, argv=0xbfa03774, envp=0xbfa03784) at _m3main.mc:4
#34
 0xb6d44450 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#35 0x0806de71 in _start ()

Thanks in advance




Enviado desde Correo Yahoo!
La bandeja de entrada m?s inteligente.








      
Enviado desde Correo Yahoo!
La bandeja de entrada m?s inteligente.









      
Enviado desde Correo Yahoo!
La bandeja de entrada m?s inteligente.









      
Enviado desde Correo Yahoo!
La bandeja de entrada m?s inteligente.



      ______________________________________________ 
Enviado desde Correo Yahoo! La bandeja de entrada m?s inteligente.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Wed May 28 06:26:10 2008
From: jayk123 at hotmail.com (Jay)
Date: Wed, 28 May 2008 04:26:10 +0000
Subject: [M3devel] function pointers and comparison to nil?
	mis-typed	function pointers?
In-Reply-To: <20080527154551.GA24415@topoi.pooq.com>
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
	<20080527154551.GA24415@topoi.pooq.com>
Message-ID: 

> The CDC Algol 68 compiler had a trick for recognising expired scopes 
Hendrik -- but then again there is that heap allocation cost..
 
This is also a step toward, like, heap allocated stack frames, except the garbage collected heap is only being used for its "lifetime features" and not its ability to store anything (other than lifetime/liveness).
 
As I understand..and this is maybe crazy...a straightforward Scheme implementation -- with no static analysis -- and "Stackless Python" take that next step -- all frames are heap allocated and garbage collected, and therefore a pointer to a nested function can outlive its original context. Neat but seems expensive. Perhaps can be fast enough.
I like the canonical Scheme example:
 
  (define make-adder (x) (lamba (y) (+ x y)))  
  (define add5 (make-adder 5))  
  (add5 3)  
 
  => 8  
 
implies make-adder's frame that contains "5" is heap allocated and then "add5" is a heap allocated chunk that contains merely that pointer and a pointer to the nexted function.
 
 > procedure to a single-pointer callback. This functin will have to be   > rewritten for each platform, and can allocate the necessary   > dynamically-genereated code on the heap (or, of course, on the stack, if   > possible on that platform). As for portability, it's certianly no  
I think it's easy enough to generate the code, the problem is where to put it.
Stack is not necessarily executable, heap is more expensive to allocate.
But in this forum I'm always contradicted on that last point, so it could just be in the heap.
Note that the heap isn't necessarily executable either.
 
I don't think breaking the existing compatibility with C function pointers is good.
In fact, I dare suggest that C interop should be aided by the Modula-3 compiler generating "headers" for C.
Really just a possible part of any "C backend". :)
 
If the type system is strong enough..having two separate types for C function pointers and Modula-3 function pointers might be viable. But you'd have to review all the "loopholes". Again probably a losing effort.
 
As I've said a few times, I'm fairly content to leave this all alone. Maybe just to research "reliable" markers that cannot now or ever be confused for "real code". It's hard to make such a guarantee what with processors always evolving and gaining new instructions. If the constant could be dynamic, it could be an absolute reference to a particular reserved symbol. If you manage to call it incorrectly, that symbol would be a real function and raise an exception. This a) depends on their being a suitable addressing mode, ie: not PC-relative and allowing for large enough constants (possibly multiple instructions..big, wasteful) b) makes the check for the signature much more expensive since it'd have to read memory another time c) likewise for the formation of the closures. Could be that part of the signature is constant and part dynamic.
 
Another idea would be to have a static check post-link run through all the code and verify the marker doesn't appear at the start of any function, if there is sufficient ability to read the code that way.
 
Anyway, it's probably all fairly moot.
Just need to disassemble -1 on every platform now and every so often, to "lazily" "ensure" it is not valid code.
 
Had I not hit the alignment fault I never would have discovered this stuff and we wouldn't be talking too much about it... :)
 
 - Jay



> Date: Tue, 27 May 2008 11:45:51 -0400> From: hendrik at topoi.pooq.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?> > On Sun, May 25, 2008 at 10:50:15PM -0500, Rodney M. Bates wrote:> > I think I can shed some light on this, having spent some time making> > m3gdb handle the various operations on nested procedures. As for code> > that mixes M3 and C, I believe the following are true:> > > > - Within M3 code only, the closure system works correctly in all cases.> > This answers one of Jay's worries.> > As long as procedure-entry code can be guaranteed never to start wit a > word of one-bits. We do have some influence on this code, though, and > if necessary might be able to choose a different bit pattern on a > specific platform.> > > > > - For values of M3 procedure/C function pointer that are top-level> > (nonnested) procedures/functions, M3 and C code (generated by gcc,> > at least) are interchangeable. This answers another of Jay's worries.> > This will cover that great majority of cases.> > Yes. And in many cases, we will know statically that this is the case.> > > > > - Standard C has no nested functions. Gcc adds them as a language> > extension. Thus, only in gcc-compiled C code do we need to worry> > about nested procedures/functions between languages. (Do any other> > C compilers exist that also have nested functions?)> > Standard C has no nested function, and does not need closures. As a > result, Standard C can use simple pointers to represent function > addresses. The language extension retrofits closures using run-time > code generation. The way this is done (on the satck) is nonportable, > and we'd like to avoid that nonportability.> > The problem with seems to be just that you seem to want to use an > address of a function as a function pointer, and that just doesn't have > enough space in it to represent a closure.> > But why do it that way? Why not just let *all* Modula 3 functions be > represented by closures? Then you never have to test whether something > is a closure, it just always is. Top-level functions with no > environment just use a null pointer as environment -- and never use it.> > The only arguments for not doing this would seem to be > (a) the waste of space, making functions a little larger than necessary, > (b) and C compatibility.> > Now (a) is probably a nonissue, since the vast majority of functions > never have their addresses taken, are never passes as parameters to > other procedures, and so forth. So for the vast majority of functions, > you simply never have to build the closure.> > (b) might be a problem. The obvious trick is just to forbid passing to C > a non-top-level function. Since even the C programmers who devise > interfaces with callbacks realise that just a functino pointer isn't > enough, they usually provide a machanism for passing a void pointer to > additional information the callback might need. Nothing here puts > Modula 3 at a disadvantage relative to C. You can just use a top-level > function and let the programmer provide it with whatever it needs.> > But if it is deemed essential to provide actual single-pointer callback > addresses, this can be done by using a built-in function to convert a > procedure to a single-pointer callback. This functin will have to be > rewritten for each platform, and can allocate the necessary > dynamically-genereated code on the heap (or, of course, on the stack, if > possible on that platform). As for portability, it's certianly no > big deal to do this; compared with writing a platform-dependent code > generator (itself a requirement), this is not huge.> > > - M3's normal runtime check that precludes assigning a nonlocal> > procedure value will not detect a C-code-produced nonlocal value,> > thus the environment could indeed have disappeared if the programmer> > was not careful. However, gcc-extended C's nested functions have> > no protection against this bug when only C code is involved, so> > perhaps not detecting it in mixed M3/C is to be expected.> > We really can't protect against bugs in C code. If we could prevent > bugs in C, the market for it would be huge, and we'd be well advised to > consider that our main business.> > > > > - C code that attempts to call a function pointer value that was> > originally produced by M3 code as a nested procedure value will> > almost certainly crash at the time of the call. This is the only> > case that presents a significant problem. M3 code will not be> > able to give a nested procedure as a callback to a C library.> > Wherefor only in this case should we do run-time code generation.> > It has been argued that we don't need to protect against C programmers > going hog-wild and breaking their own code. Such is the nature of C.> > But, we can chack for some of it, it we are willing to go to the effort. > The technique used in the CDC Algol 68 compiler long ago might even > enable us to restrict the constraint on assigning nested procedures to > variables by a suitable run-time check.> > The CDC Algol 68 compiler had a trick for recognising expired scopes > using the garbage collector. Let's see if I can remember the details. > It involved special treatment for procedures whose addresses are taken, > and for the blocks that contain them. When entering such a block at > run-time, a word is allocated on the heap representing that scope. It > is filled with something relevant, such as the address if the stack > frame for the block, and the stack frame also pointed to that scope-cell > (as I'll describe it). Taking the address of a procedure involved > building a closure that points to that scope-cell. When leaving the > block, the contents of the scope-cell is wiped to some recognisable > invalid value. When entering the procedure the scope-cell will > still be around even if the scope is not. The procedure (this is inside > the procedure itself, not at the call) checks that the scope-cell has > not been wiped, and therefore is still valid. If valid, it contains the > necessary environment information. If not, break off execution.> > -- hendrik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From hendrik at topoi.pooq.com  Wed May 28 08:14:24 2008
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Wed, 28 May 2008 02:14:24 -0400
Subject: [M3devel] function pointers and comparison to nil?
	mis-typed	function pointers?
In-Reply-To: 
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
	<20080527154551.GA24415@topoi.pooq.com>
	
Message-ID: <20080528061424.GA25708@topoi.pooq.com>

On Wed, May 28, 2008 at 04:26:10AM +0000, Jay wrote:
> > The CDC Algol 68 compiler had a trick for recognising expired scopes 
> Hendrik -- but then again there is that heap allocation cost..

But only for the blocks closest-containing procedures whose addresses 
are taken.  That is relatively rare, and it will not cause heap allocation 
for anyone that does not take addresses of nested procedures.
>  
> This is also a step toward, like, heap allocated stack frames, except 
> the garbage collected heap is only being used for its "lifetime 
> features" and not its ability to store anything (other than 
> lifetime/liveness).
>  
> As I understand..and this is maybe crazy...a straightforward Scheme implementation -- with no static analysis -- and "Stackless Python" take that next step -- all frames are heap allocated and garbage collected, and therefore a pointer to a nested function can outlive its original context. Neat but seems expensive. Perhaps can be fast enough.
> I like the canonical Scheme example:
>  
>   (define make-adder (x) (lamba (y) (+ x y)))  
>   (define add5 (make-adder 5))  
>   (add5 3)  
>  
>   => 8  
>  
> implies make-adder's frame that contains "5" is heap allocated and then "add5" is a heap allocated chunk that contains merely that pointer and a pointer to the nexted function.
>  
>  > procedure to a single-pointer callback. This functin will have to be   > rewritten for each platform, and can allocate the necessary   > dynamically-genereated code on the heap (or, of course, on the stack, if   > possible on that platform). As for portability, it's certianly no  

> I think it's easy enough to generate the code, the problem is where to put it.
> Stack is not necessarily executable, heap is more expensive to allocate.
> But in this forum I'm always contradicted on that last point, so it could just be in the heap.
> Note that the heap isn't necessarily executable either.

Id you can't write into dynamically-allocated code space, you may as 
well forget about JIT compilers.  Well, I suppose there could be 
machines that can't have JIT compilers.
 
Actually, if you're talking to C, you should be able to follow the 
same restrictions that C uses.

>  
> I don't think breaking the existing compatibility with C function 
> pointers is good.

Until this discussion started, I never dreamed there was any 
compatibility with C functino pointers except for non-nested procedures.  
This all came as a surprise to me.

> In fact, I dare suggest that C interop should be aided by the Modula-3 
> compiler generating "headers" for C.
> Really just a possible part of any "C backend". :)
>  
> If the type system is strong enough..having two separate types for C 
> function pointers and Modula-3 function pointers might be viable. But 
> you'd have to review all the "loopholes". Again probably a losing 
> effort.

Just like C strings and Modula 3 strings?

>  
> As I've said a few times, I'm fairly content to leave this all alone. 

I, too.  But I thought it ws worth pointing out that there is a 
conceptually clean solution, especially since conceptually clean 
practicality is one of Modula 3's hallmarks.

-- hendrik


From jayk123 at hotmail.com  Wed May 28 09:04:58 2008
From: jayk123 at hotmail.com (Jay)
Date: Wed, 28 May 2008 07:04:58 +0000
Subject: [M3devel] function pointers and comparison to
	nil?	mis-typed	function pointers?
In-Reply-To: <20080528061424.GA25708@topoi.pooq.com>
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
	<20080527154551.GA24415@topoi.pooq.com>
	 
	<20080528061424.GA25708@topoi.pooq.com>
Message-ID: 

> Id you can't write into dynamically-allocated code space, you may as > well forget about JIT compilers. Well, I suppose there could be > machines that can't have JIT compilers.
Those systems are slow.....AND this "proposal" (exaggeration!) as I understand equates to a heap alloc per function call for CERTAIN RARE function calls, or perhaps more fine grained, per taking-address-of-nested functions.
 
These slow systems with JITs don't usually JIT "that often".
They JIT like at one of:
   module load 
   first time a function is called  
   first time a block is entered 
 
but not for subsequent loads/runs, at least not with the same process or "app domain".
 
> Until this discussion started, I never dreamed there was any > compatibility with C functino pointers except for non-nested procedures. > This all came as a surprise to me.
That is all there is. You cannot pass a closure pointer off to C code as a function pointer.
You CAN pass gcc nested C functions off as such however.
Opposing forces -- closures as dynamically sniffed pair of pointers vs. closures as dynamically generated code.
Ok, also nested functions that don't happen to use their parent frames' locals probably interop.
 
Ok, probably I should go and implement the *option* cm3cg -trampolines and m3 -trampolines or somesuch.
 
I guess a pragma <* trampoline *> or <* c function pointer *> to let source ask for it, but that's getting ahead of things, it's "experimental" and probably just not desirable, but maybe just interesting to get working...
 
 - Jay



> Date: Wed, 28 May 2008 02:14:24 -0400> From: hendrik at topoi.pooq.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?> > On Wed, May 28, 2008 at 04:26:10AM +0000, Jay wrote:> > > The CDC Algol 68 compiler had a trick for recognising expired scopes > > Hendrik -- but then again there is that heap allocation cost..> > But only for the blocks closest-containing procedures whose addresses > are taken. That is relatively rare, and it will not cause heap allocation > for anyone that does not take addresses of nested procedures.> > > > This is also a step toward, like, heap allocated stack frames, except > > the garbage collected heap is only being used for its "lifetime > > features" and not its ability to store anything (other than > > lifetime/liveness).> > > > As I understand..and this is maybe crazy...a straightforward Scheme implementation -- with no static analysis -- and "Stackless Python" take that next step -- all frames are heap allocated and garbage collected, and therefore a pointer to a nested function can outlive its original context. Neat but seems expensive. Perhaps can be fast enough.> > I like the canonical Scheme example:> > > > (define make-adder (x) (lamba (y) (+ x y))) > > (define add5 (make-adder 5)) > > (add5 3) > > > > => 8 > > > > implies make-adder's frame that contains "5" is heap allocated and then "add5" is a heap allocated chunk that contains merely that pointer and a pointer to the nexted function.> > > > > procedure to a single-pointer callback. This functin will have to be > rewritten for each platform, and can allocate the necessary > dynamically-genereated code on the heap (or, of course, on the stack, if > possible on that platform). As for portability, it's certianly no > > > I think it's easy enough to generate the code, the problem is where to put it.> > Stack is not necessarily executable, heap is more expensive to allocate.> > But in this forum I'm always contradicted on that last point, so it could just be in the heap.> > Note that the heap isn't necessarily executable either.> > Id you can't write into dynamically-allocated code space, you may as > well forget about JIT compilers. Well, I suppose there could be > machines that can't have JIT compilers.> > Actually, if you're talking to C, you should be able to follow the > same restrictions that C uses.> > > > > I don't think breaking the existing compatibility with C function > > pointers is good.> > Until this discussion started, I never dreamed there was any > compatibility with C functino pointers except for non-nested procedures. > This all came as a surprise to me.> > > In fact, I dare suggest that C interop should be aided by the Modula-3 > > compiler generating "headers" for C.> > Really just a possible part of any "C backend". :)> > > > If the type system is strong enough..having two separate types for C > > function pointers and Modula-3 function pointers might be viable. But > > you'd have to review all the "loopholes". Again probably a losing > > effort.> > Just like C strings and Modula 3 strings?> > > > > As I've said a few times, I'm fairly content to leave this all alone. > > I, too. But I thought it ws worth pointing out that there is a > conceptually clean solution, especially since conceptually clean > practicality is one of Modula 3's hallmarks.> > -- hendrik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From ronny.forberger at elegosoft.com  Wed May 28 11:52:29 2008
From: ronny.forberger at elegosoft.com (Ronny Forberger)
Date: Wed, 28 May 2008 11:52:29 +0200
Subject: [M3devel] FW: NT386 environment variables (new NT386	snapshots)
In-Reply-To: <20080527155926.203bam89w4w0kgko@mail.elegosoft.com>
References: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
	
	<4823279D.1E75.00D7.1@scires.com>
	
	<20080527155926.203bam89w4w0kgko@mail.elegosoft.com>
Message-ID: <20080528115229.yjpegnw34ow4g0o8@mail.elegosoft.com>

--
Message from: Olaf Wagner 
Date: Di 27 Mai 2008 15:59:26 CEST
Subject: Re: [M3devel] FW: NT386 environment variables (new NT386 snapshots)


> Quoting Jay :
>
>> truncated again...
>> m3support -- nothing interesting in any logs regarding my mail?
>> And nobody else uses hotmail, right?
>
> @Ronny, can you please check if our mail logs reveal any reason
> for Jay's mails to be truncated now and then?

The logs don't say anything about it. But it might be that this  
happens when mailman converts HTML-only messages to plain text, which  
is common behavior on mailing lists.

Jay, if your messages are HTML-only, you perhaps could try sending  
plain text only messages to the lists and check again.

[...]

Regards,

Ronny

-- 
Ronny Forberger
IT Services & Support

elego Software Solutions GmbH
Gustav-Meyer-Allee 25
Building 12.3 (BIG) room 227
13355 Berlin, Germany

phone +49 30 23 45 86 96      ronny.forberger at elegosoft.com
fax   +49 30 23 45 86 95      http://www.elegosoft.com

Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin
Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194



From hendrik at topoi.pooq.com  Wed May 28 14:00:30 2008
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Wed, 28 May 2008 08:00:30 -0400
Subject: [M3devel] function pointers and comparison to
	nil?	mis-typed	function pointers?
In-Reply-To: 
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
	<20080527154551.GA24415@topoi.pooq.com>
	
	<20080528061424.GA25708@topoi.pooq.com>
	
Message-ID: <20080528120030.GA26129@topoi.pooq.com>

On Wed, May 28, 2008 at 07:04:58AM +0000, Jay wrote:
> > Id you can't write into dynamically-allocated code space, you may as > well forget about JIT compilers. Well, I suppose there could be > machines that can't have JIT compilers.
> Those systems are slow.....AND this "proposal" (exaggeration!) as I understand equates to a heap alloc per function call for CERTAIN RARE function calls, or perhaps more fine grained, per taking-address-of-nested functions.
>  
> These slow systems with JITs don't usually JIT "that often".
> They JIT like at one of:
>    module load 
>    first time a function is called  
>    first time a block is entered 
>  
> but not for subsequent loads/runs, at least not with the same process or "app domain".
>  
> > Until this discussion started, I never dreamed there was any
> > compatibility with C functino pointers except for non-nested 
> > procedures.
> > This all came as a surprise to me.

> That is all there is. You cannot pass a closure pointer off to C code 
> as a function pointer.

So the only programs that will be affected by the heap allocation to 
convert Modula 3 closures to C closures are programs which are currently 
illegal.  This makes it effectively have zero cost for existing code.

> You CAN pass gcc nested C functions off as such however.

Thus eventually we can expect to have to interface with libraries that 
expect nested C functino closures and don't pass an extra void pointer 
for environment.

> Opposing forces -- closures as dynamically sniffed pair of pointers 
> vs. closures as dynamically generated code.
> Ok, also nested functions that don't happen to use their parent 
> frames' locals probably interop.

I fact, everywhere we talk about the syntactically enclosing block, we 
should be talking about the most local enclosing block that declares 
names used in the function.

>  
> Ok, probably I should go and implement the *option* cm3cg -trampolines 
> and m3 -trampolines or somesuch.
>  
> I guess a pragma <* trampoline *> or <* c function pointer *> to let 
> source ask for it, but that's getting ahead of things, it's 
> "experimental" and probably just not desirable, but maybe just 
> interesting to get working...
>  
>  - Jay


From wagner at elegosoft.com  Thu May 29 15:02:09 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Thu, 29 May 2008 15:02:09 +0200
Subject: [M3devel] _lowbits / _highbits (Pixmap bug-- 4.1 vs. buggy	5.x)
In-Reply-To: 
References: 
	
Message-ID: <20080529150209.vnhlgwbjcog4wc04@mail.elegosoft.com>

Quoting Jay :

> 1) Just fyi, NT386GNU didn't build with my fix, so it is disabled   
> there only, and the bug could very well be present there.
> Er, then again, this stuff works differently for the gcc backend, so  
>  I don't know, I'll have to look, and run the tests, not today.
> Which reminds me also, these symbols should be static hand.c, except  
>  for NT386 -- the source can't tell, so it'll have to be a define   
> from the m3makefile.
>
> 2) Can anyone confirm my history and the missing source?
> ie: Confirm that what is marked as 4.1 and 5.1 in CVS really is 4.1   
> and 5.1? I don't think 4.1 is accurately marked.
> In particular, I don't think the 4.1 Stackx86.m3  is what 4.1   
> actually shipped.
>
> 3) Or confirm my analysis that leads to the "accusation"? It was tedious.

I don't think that a complete 4.1 code set was ever imported into
the CVS CM3 repository; at least I don't remember we got the complete
4.1 code from Farshad Nayeri. What we got was 5.1 and it wasn't even
compilable by any existing M3 compiler. The gcc backend was so old
that it wasn't usable on any system we had. I think we extensively used
PM3 for booting and even incorporated some of PM3's code where
necessary.

I remember that I had several evaluation CDs from CM3 some years before
the open source release, so it may be that contents from one of these
CDs were imported as 4.1. I'm afraid it is not really traceable now.
We never got any versioned code from Critical Mass (I don't know what
they used for version control), only the bare source code.

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 rcoleburn at scires.com  Thu May 29 18:31:14 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Thu, 29 May 2008 12:31:14 -0400
Subject: [M3devel] _lowbits / _highbits (Pixmap bug-- 4.1 vs.	buggy	5.x)
In-Reply-To: <20080529150209.vnhlgwbjcog4wc04@mail.elegosoft.com>
References: 
	
	<20080529150209.vnhlgwbjcog4wc04@mail.elegosoft.com>
Message-ID: <483EA20A.1E75.00D7.1@scires.com>

Olaf / Jay:
 
My Reactor v4.1 CD has a source directory, but this folder does not
contain the sources for the compiler or Reactor, just the libraries et
al.
 
Here is a list of the archives in that folder:
 
BINUTILS.TGZ
m3-comm.TGZ
m3-db.TGZ
M3-DEMO.TGZ
M3-GAMES.TGZ
M3-LCTRN.TGZ
m3-libs.TGZ
M3-MAIL.TGZ
M3-OBLIQ.TGZ
M3-PKGTL.TGZ
M3-TOOLS.TGZ
m3-ui.TGZ
m3-www.TGZ
M3CC.TGZ
M3GDB.TGZ
 
There is also a CONTRIB folder with the following:
 
CVSUP
IDLM3
M2TOM3
M3DDD
M3PC
M3TOMIF
SRC-M3
 
If Farshad is ok with it, I can send you these files, but I would need
his approval because we licensed this product from Critical Mass.
 
On a side note, I just built a new laptop computer from a fresh install
of XP Pro.  I got the latest cm3 from the repository and rebuilt
everything.  On this platform, my pixmaps show up with a "yellow" color
everywhere "white" would normally show.  This is strange behavior.  I
checked the .lst file and it is showing as a GUI program and the
"hand.obj" is included.  Any ideas?
 
Since Jay has made good progress on fixing some of my major gripes, I
am trying to use the new (current) cm3 for my project that is due for
delivery at the end of July.  The new garbage collector seems to work
much better on Windows than the one from 4.1.  Since we don't have an
official stable release right now, I am going to have to draw a line in
the sand at some point soon and take a snapshot of the cm3 source tree
as the "official" development environment for future support of my
project deliverables.
 
This latest problem with pixmaps on one platform and with CM3IDE on all
XP platforms I've tested so far is disturbing.  As soon as I can get a
handle on these problems, I think I am going to freeze my development
environment for this project unless someone comes up with a major
fix/change.
 
Regards,
Randy

>>> Olaf Wagner  5/29/2008 9:02 AM >>>
Quoting Jay :

> 1) Just fyi, NT386GNU didn't build with my fix, so it is disabled   
> there only, and the bug could very well be present there.
> Er, then again, this stuff works differently for the gcc backend, so 

>  I don't know, I'll have to look, and run the tests, not today.
> Which reminds me also, these symbols should be static hand.c, except 

>  for NT386 -- the source can't tell, so it'll have to be a define   
> from the m3makefile.
>
> 2) Can anyone confirm my history and the missing source?
> ie: Confirm that what is marked as 4.1 and 5.1 in CVS really is 4.1  

> and 5.1? I don't think 4.1 is accurately marked.
> In particular, I don't think the 4.1 Stackx86.m3  is what 4.1   
> actually shipped.
>
> 3) Or confirm my analysis that leads to the "accusation"? It was
tedious.

I don't think that a complete 4.1 code set was ever imported into
the CVS CM3 repository; at least I don't remember we got the complete
4.1 code from Farshad Nayeri. What we got was 5.1 and it wasn't even
compilable by any existing M3 compiler. The gcc backend was so old
that it wasn't usable on any system we had. I think we extensively
used
PM3 for booting and even incorporated some of PM3's code where
necessary.

I remember that I had several evaluation CDs from CM3 some years
before
the open source release, so it may be that contents from one of these
CDs were imported as 4.1. I'm afraid it is not really traceable now.
We never got any versioned code from Critical Mass (I don't know what
they used for version control), only the bare source code.

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 mika at async.caltech.edu  Thu May 29 20:53:01 2008
From: mika at async.caltech.edu (Mika Nystrom)
Date: Thu, 29 May 2008 11:53:01 -0700
Subject: [M3devel] _lowbits / _highbits (Pixmap bug-- 4.1 vs. buggy 5.x)
In-Reply-To: Your message of "Thu, 29 May 2008 12:31:14 EDT."
	<483EA20A.1E75.00D7.1@scires.com> 
Message-ID: <200805291853.m4TIr1FF079831@camembert.async.caltech.edu>

"Randy Coleburn" writes:
...
>On a side note, I just built a new laptop computer from a fresh install
>of XP Pro.  I got the latest cm3 from the repository and rebuilt
>everything.  On this platform, my pixmaps show up with a "yellow" color
>everywhere "white" would normally show.  This is strange behavior.  I
>checked the .lst file and it is showing as a GUI program and the
>"hand.obj" is included.  Any ideas?
...

Not sure if this is related, but "xv" does exactly this for me when
running under VNC, at least with certain combinations of color depths.
No Modula-3 involved.  This is when I am accessing a FreeBSD VNC server
remotely from RealVNC on win2k as well as win XP.  Never quite figured
out why it happens.

    Mika


From jayk123 at hotmail.com  Thu May 29 21:07:40 2008
From: jayk123 at hotmail.com (Jay)
Date: Thu, 29 May 2008 19:07:40 +0000
Subject: [M3devel] _lowbits / _highbits (Pixmap bug-- 4.1 vs.	buggy	5.x)
In-Reply-To: <483EA20A.1E75.00D7.1@scires.com>
References: 
	
	<20080529150209.vnhlgwbjcog4wc04@mail.elegosoft.com> 
	<483EA20A.1E75.00D7.1@scires.com>
Message-ID: 

I have the 4.1 CD. I bought it from Critical Mass the normal legitimate way. I hacked my cm3.exe the other day to skip the license check since I can't find my key, it's very easy to do.
My observations agree with yours -- no source on the CD to the compiler, contrib includes the DEC 3.6 code.
 
What are the CM3IDE problems?
 
What is the pixmap behavior with build_standalone()?
I'm inclined to think this is not a Modula-3 problem but hard to debug remotely like this..
 
 - Jay


Date: Thu, 29 May 2008 12:31:14 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: Re: [M3devel] _lowbits / _highbits (Pixmap bug-- 4.1 vs. buggy 5.x)

Olaf / Jay:
 
My Reactor v4.1 CD has a source directory, but this folder does not contain the sources for the compiler or Reactor, just the libraries et al.
 
Here is a list of the archives in that folder:
 
BINUTILS.TGZm3-comm.TGZm3-db.TGZM3-DEMO.TGZM3-GAMES.TGZM3-LCTRN.TGZm3-libs.TGZM3-MAIL.TGZM3-OBLIQ.TGZM3-PKGTL.TGZM3-TOOLS.TGZm3-ui.TGZm3-www.TGZM3CC.TGZM3GDB.TGZ
 
There is also a CONTRIB folder with the following:
 
CVSUPIDLM3M2TOM3M3DDDM3PCM3TOMIFSRC-M3
 
If Farshad is ok with it, I can send you these files, but I would need his approval because we licensed this product from Critical Mass.
 
On a side note, I just built a new laptop computer from a fresh install of XP Pro.  I got the latest cm3 from the repository and rebuilt everything.  On this platform, my pixmaps show up with a "yellow" color everywhere "white" would normally show.  This is strange behavior.  I checked the .lst file and it is showing as a GUI program and the "hand.obj" is included.  Any ideas?
 
Since Jay has made good progress on fixing some of my major gripes, I am trying to use the new (current) cm3 for my project that is due for delivery at the end of July.  The new garbage collector seems to work much better on Windows than the one from 4.1.  Since we don't have an official stable release right now, I am going to have to draw a line in the sand at some point soon and take a snapshot of the cm3 source tree as the "official" development environment for future support of my project deliverables.
 
This latest problem with pixmaps on one platform and with CM3IDE on all XP platforms I've tested so far is disturbing.  As soon as I can get a handle on these problems, I think I am going to freeze my development environment for this project unless someone comes up with a major fix/change.
 
Regards,
Randy>>> Olaf Wagner  5/29/2008 9:02 AM >>>Quoting Jay :> 1) Just fyi, NT386GNU didn't build with my fix, so it is disabled   > there only, and the bug could very well be present there.> Er, then again, this stuff works differently for the gcc backend, so  >  I don't know, I'll have to look, and run the tests, not today.> Which reminds me also, these symbols should be static hand.c, except  >  for NT386 -- the source can't tell, so it'll have to be a define   > from the m3makefile.>> 2) Can anyone confirm my history and the missing source?> ie: Confirm that what is marked as 4.1 and 5.1 in CVS really is 4.1   > and 5.1? I don't think 4.1 is accurately marked.> In particular, I don't think the 4.1 Stackx86.m3  is what 4.1   > actually shipped.>> 3) Or confirm my analysis that leads to the "accusation"? It was tedious.I don't think that a complete 4.1 code set was ever imported intothe CVS CM3 repository; at least I don't remember we got the complete4.1 code from Farshad Nayeri. What we got was 5.1 and it wasn't evencompilable by any existing M3 compiler. The gcc backend was so oldthat it wasn't usable on any system we had. I think we extensively usedPM3 for booting and even incorporated some of PM3's code wherenecessary.I remember that I had several evaluation CDs from CM3 some years beforethe open source release, so it may be that contents from one of theseCDs were imported as 4.1. I'm afraid it is not really traceable now.We never got any versioned code from Critical Mass (I don't know whatthey used for version control), only the bare source code.Olaf-- Olaf Wagner -- elego Software Solutions GmbH                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germanyphone: +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: BerlinHandelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jayk123 at hotmail.com  Thu May 29 21:41:45 2008
From: jayk123 at hotmail.com (Jay)
Date: Thu, 29 May 2008 19:41:45 +0000
Subject: [M3devel] _lowbits / _highbits (Pixmap bug-- 4.1 vs. buggy	5.x)
In-Reply-To: <20080529150209.vnhlgwbjcog4wc04@mail.elegosoft.com>
References: 
	 
	<20080529150209.vnhlgwbjcog4wc04@mail.elegosoft.com>
Message-ID: 

Ok, I stand by my earlier analysis, though I forget what it was. :)
Partly that the "4.1" source in CVS is not 4.1, so understanding how it worked can't be done from source. Though I guess I could read the assembly if we really need to know..
 
Thanks,
 - Jay



> Date: Thu, 29 May 2008 15:02:09 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] _lowbits / _highbits (Pixmap bug-- 4.1 vs. buggy 5.x)> > Quoting Jay :> > > 1) Just fyi, NT386GNU didn't build with my fix, so it is disabled > > there only, and the bug could very well be present there.> > Er, then again, this stuff works differently for the gcc backend, so > > I don't know, I'll have to look, and run the tests, not today.> > Which reminds me also, these symbols should be static hand.c, except > > for NT386 -- the source can't tell, so it'll have to be a define > > from the m3makefile.> >> > 2) Can anyone confirm my history and the missing source?> > ie: Confirm that what is marked as 4.1 and 5.1 in CVS really is 4.1 > > and 5.1? I don't think 4.1 is accurately marked.> > In particular, I don't think the 4.1 Stackx86.m3 is what 4.1 > > actually shipped.> >> > 3) Or confirm my analysis that leads to the "accusation"? It was tedious.> > I don't think that a complete 4.1 code set was ever imported into> the CVS CM3 repository; at least I don't remember we got the complete> 4.1 code from Farshad Nayeri. What we got was 5.1 and it wasn't even> compilable by any existing M3 compiler. The gcc backend was so old> that it wasn't usable on any system we had. I think we extensively used> PM3 for booting and even incorporated some of PM3's code where> necessary.> > I remember that I had several evaluation CDs from CM3 some years before> the open source release, so it may be that contents from one of these> CDs were imported as 4.1. I'm afraid it is not really traceable now.> We never got any versioned code from Critical Mass (I don't know what> they used for version control), only the bare source code.> > 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 jayk123 at hotmail.com  Fri May 30 08:31:19 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 30 May 2008 06:31:19 +0000
Subject: [M3devel] _lowbits / _highbits (Pixmap bug-- 4.1 vs.	buggy	5.x)
In-Reply-To: 
References: 
	
	<20080529150209.vnhlgwbjcog4wc04@mail.elegosoft.com> 
	<483EA20A.1E75.00D7.1@scires.com> 
	
Message-ID: 



Also if you can send me a test case I can build and run for the current pixmap problem, please do.


 - Jay



________________________________

From: jayk123 at hotmail.com
To: rcoleburn at scires.com; m3devel at elegosoft.com
Date: Thu, 29 May 2008 19:07:40 +0000
Subject: Re: [M3devel] _lowbits / _highbits (Pixmap bug-- 4.1 vs. buggy 5.x)




I have the 4.1 CD. I bought it from Critical Mass the normal legitimate way. I hacked my cm3.exe the other day to skip the license check since I can't find my key, it's very easy to do.
My observations agree with yours -- no source on the CD to the compiler, contrib includes the DEC 3.6 code.

What are the CM3IDE problems?

What is the pixmap behavior with build_standalone()?
I'm inclined to think this is not a Modula-3 problem but hard to debug remotely like this..

 - Jay



________________________________

Date: Thu, 29 May 2008 12:31:14 -0400
From: rcoleburn at scires.com
To: m3devel at elegosoft.com
Subject: Re: [M3devel] _lowbits / _highbits (Pixmap bug-- 4.1 vs. buggy 5.x)


Olaf / Jay:



My Reactor v4.1 CD has a source directory, but this folder does not contain the sources for the compiler or Reactor, just the libraries et al.



Here is a list of the archives in that folder:



BINUTILS.TGZ
m3-comm.TGZ
m3-db.TGZ
M3-DEMO.TGZ
M3-GAMES.TGZ
M3-LCTRN.TGZ
m3-libs.TGZ
M3-MAIL.TGZ
M3-OBLIQ.TGZ
M3-PKGTL.TGZ
M3-TOOLS.TGZ
m3-ui.TGZ
m3-www.TGZ
M3CC.TGZ
M3GDB.TGZ



There is also a CONTRIB folder with the following:



CVSUP
IDLM3
M2TOM3
M3DDD
M3PC
M3TOMIF
SRC-M3



If Farshad is ok with it, I can send you these files, but I would need his approval because we licensed this product from Critical Mass.



On a side note, I just built a new laptop computer from a fresh install of XP Pro.  I got the latest cm3 from the repository and rebuilt everything.  On this platform, my pixmaps show up with a "yellow" color everywhere "white" would normally show.  This is strange behavior.  I checked the .lst file and it is showing as a GUI program and the "hand.obj" is included.  Any ideas?



Since Jay has made good progress on fixing some of my major gripes, I am trying to use the new (current) cm3 for my project that is due for delivery at the end of July.  The new garbage collector seems to work much better on Windows than the one from 4.1.  Since we don't have an official stable release right now, I am going to have to draw a line in the sand at some point soon and take a snapshot of the cm3 source tree as the "official" development environment for future support of my project deliverables.



This latest problem with pixmaps on one platform and with CM3IDE on all XP platforms I've tested so far is disturbing.  As soon as I can get a handle on these problems, I think I am going to freeze my development environment for this project unless someone comes up with a major fix/change.



Regards,

Randy

>>> Olaf Wagner  5/29/2008 9:02 AM>>>
Quoting Jay :

> 1) Just fyi, NT386GNU didn't build with my fix, so it is disabled
> there only, and the bug could very well be present there.
> Er, then again, this stuff works differently for the gcc backend, so
>  I don't know, I'll have to look, and run the tests, not today.
> Which reminds me also, these symbols should be static hand.c, except
>  for NT386 -- the source can't tell, so it'll have to be a define
> from the m3makefile.
>
> 2) Can anyone confirm my history and the missing source?
> ie: Confirm that what is marked as 4.1 and 5.1 in CVS really is 4.1
> and 5.1? I don't think 4.1 is accurately marked.
> In particular, I don't think the 4.1 Stackx86.m3  is what 4.1
> actually shipped.
>
> 3) Or confirm my analysis that leads to the "accusation"? It was tedious.

I don't think that a complete 4.1 code set was ever imported into
the CVS CM3 repository; at least I don't remember we got the complete
4.1 code from Farshad Nayeri. What we got was 5.1 and it wasn't even
compilable by any existing M3 compiler. The gcc backend was so old
that it wasn't usable on any system we had. I think we extensively used
PM3 for booting and even incorporated some of PM3's code where
necessary.

I remember that I had several evaluation CDs from CM3 some years before
the open source release, so it may be that contents from one of these
CDs were imported as 4.1. I'm afraid it is not really traceable now.
We never got any versioned code from Critical Mass (I don't know what
they used for version control), only the bare source code.

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 jayk123 at hotmail.com  Fri May 30 08:45:03 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 30 May 2008 06:45:03 +0000
Subject: [M3devel] FW: NT386 environment variables (new NT386	snapshots)
In-Reply-To: <20080527155926.203bam89w4w0kgko@mail.elegosoft.com>
References: <20080506081613.gsg5kybu8s0ggws8@mail.elegosoft.com>
	
	<4823279D.1E75.00D7.1@scires.com>
	 
	<20080527155926.203bam89w4w0kgko@mail.elegosoft.com>
Message-ID: 


Yes, RTArgs and Env should work now on NT386.

NT386GNU actually probably doesn't yet implement "gui" apps, and NT386GNU console apps I expect work.
I should finish and test that, very small feature. More interesting for NT386MINGNU probably, but the same code to implement it and trivial.

The fix could be better/smaller, but probably ok.
In particular, the compiler generates a main that passes data to the runtime.
Sometimes main is right, sometimes wrong.
I left the compiler/main alone, but changed the NT386 runtime to always just fetch the data itself and always ignore the data it got from main. This might let some hypothetical bootstrapping scenarios keep working, using a new compiler to target an old runtime..

I'll switch to plain text and see how it goes.
Apparently that requires switching to "classic" Hotmail and I haven't seen if I can make it "sticky" or not.
We'll see. jay.krell at cornell.edu will work again shortly too but that won't help. :)
I have ONE other report of truncated mail.

 - Jay


> Date: Tue, 27 May 2008 15:59:26 +0200
> From: wagner
> To: m3devel; rforb
> Subject: Re: [M3devel] FW: NT386 environment variables (new NT386 snapshots)
>
> Quoting Jay 
>
>> truncated again...
>> m3support -- nothing interesting in any logs regarding my mail?
>> And nobody else uses hotmail, right?
>
> @Ronny, can you please check if our mail logs reveal any reason
> for Jay's mails to be truncated now and then?
>
>>> I will apply an easy fix.
>> done
>
> I'm not sure if this means that the issues concerning evnironment
> variable access (both via Env and RTArgs) are now fixed for NT386(GNU)...
> Can we forget about this issue?
>
> Olaf
>
....snip snip snip....


From rodney.bates at wichita.edu  Sat May 31 00:14:36 2008
From: rodney.bates at wichita.edu (Rodney M. Bates)
Date: Fri, 30 May 2008 17:14:36 -0500
Subject: [M3devel] function pointers and comparison to nil? mis-typed
 function pointers?
In-Reply-To: 
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
	
	
	
	
	<483B21F9.6070205@wichita.edu>
	
Message-ID: <48407C4C.5020407@wichita.edu>



Jay wrote:
>  > Mistaking the function's real code for a closure is a lot less likely
>  > than mistaking the function's real code for a trampoline. A trampoline
> 
> What is the danger in "mistaking" "real code" for a "trampoline"?
> They are both "real code".

This mistake would break correct implementation of the language.  It
would mean a runtime error, called for by the language semantics,
would go undetected.

(2.3.1: Since there is no way to determine statically whether the
value of a procedure parameter is local or global, assigning a local
procedure is a runtime rather than a static error.)

> The differences are:
>   - trampoline has limited lifetime -- unless it is heap allocated and

Not sure if this is what you meant, but the needed lifetime of either a
M3 closure or a trampoline are the same.  Either way, it is created on
the stack during a call to which a nested procedure is passed as parameter.
In Modula-3, the only reason to heap allocate would be if it is a trampoline,
to get around the possible non-executable state of the stack on some targets.
There is no need for heap lifetime semantics.

> garbage collected
>     ("real code" also has "limited lifetime", but relatively much 
> longer, if code can be unloaded, which it can be in many environments)
>   - the "real code" of nested functions has a different calling 
> convention than "real code" for non nested functions; it has an extra 
> parameter "somewhere", for the "static link"; in gcc C nested functions 
> on Cygwin/x86, this is in ecx

Again, this difference in calling convention is entirely independent of
whether M3 closures or trampolines are used.  They are different ways of
getting the environment pointer (ecx, on x86) loaded, before actually
transferring to the callee's code.

>  
> What do folks think about putting trampolines in executable garbage 
> collected heap?
> I think that's inefficient but I'm usually in the minority here 
> regarding the heap being inefficient.
>  
> One way or another, gcc makes C nested functions fairly portable, except 
> Apple's gcc on Darwin.
> Portability of -1 as a marker denoting "not code" is also dubious.
>  
> I think it stinks either way.
>  
> Anyone think coming up with "better" per-architecture markers is reasonable?

If we keep M3-style closures, the only architecture dependence is the value of
the marker word, that would be a dependence I could live with.  Trampolines,
in contrast, would have target opcodes in them, the bit layout of the trampoline
would vary, and the two pointers would almost surely be unaligned on many targets,
making m3gdb's job a lot harder.

>  
>  - Jay
> 
> ------------------------------------------------------------------------
> 
>  > Date: Mon, 26 May 2008 15:47:53 -0500
>  > From: rodney.bates at wichita.edu
>  > To: m3devel at elegosoft.com
>  > Subject: Re: [M3devel] function pointers and comparison to nil? 
> mis-typed function pointers?
>  >
>  >
>  >
>  > Jay wrote:
>  > > It stinks either way imho.
>  > > The portability is handled, somehow or another, by gcc's support for
>  > > nested functions.
>  > > For example on OpenBSD, they call mprotect to make the trampoline
>  > > executable -- expensive! and leaves a bit of a security hole.
>  > > On Linux you can sometimes mark the .exe as needing an executable 
> stack
>  > > or not. Similarly on Windows, linker has /nxcompat, /nxcompat:no 
> switch.
>  > > ATL on Windows puts trampolines in the heap and specifically makes 
> them
>  > > executable -- since the heap isn't necessarily executable either.
>  > > The -1 marker is also a bit of a portability problem but I guess in
>  > > practise it works out.
>  >
>  > Using trampolines would make this problem worse, perhaps much worse.
>  > Mistaking the function's real code for a closure is a lot less likely
>  > than mistaking the function's real code for a trampoline. A trampoline
>  > is, after all, always valid machine code on the executing processor.
>  > Not necessarily so for -1.
>  >
>  > > I'd be curious to see how it decodes on various processors.
>  > >
>  > > - Jay
>  > >
>  > --
>  > -------------------------------------------------------------
>  > Rodney M. Bates, retired assistant professor
>  > Dept. of Computer Science, Wichita State University
>  > Wichita, KS 67260-0083
>  > 316-978-3922
>  > rodney.bates at wichita.edu
> 

-- 
-------------------------------------------------------------
Rodney M. Bates, retired assistant professor
Dept. of Computer Science, Wichita State University
Wichita, KS 67260-0083
316-978-3922
rodney.bates at wichita.edu


From rodney.bates at wichita.edu  Sat May 31 01:17:02 2008
From: rodney.bates at wichita.edu (Rodney M. Bates)
Date: Fri, 30 May 2008 18:17:02 -0500
Subject: [M3devel] function pointers and comparison to nil? mis-typed
 function pointers?
In-Reply-To: 
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
	
	
Message-ID: <48408AEE.8090405@wichita.edu>

I still want to obsess on variables of type procedure/pointer-to-function,
because some of the discussion appears to me to maybe forgetting that each
language has a definition, and language implementors should adhere to it.
These are not the bad old days of the 1960s, when the only authority on the
semantics of a language was "whatever our particular compiler does".

The various languages have different rules for dealing with the problem of
dangling environment pointers in procedure variables, and these affect the
implementation choices.

In Pascal, procedures can be passed as parameters but never assigned,
regardless of whether nested or not.  It is a consequence of normal
lifetime rules that dangling environments can't happen.  The most obvious
implementation is to always use a traditional, two-word closure, nested or
not, so no marker is needed   This has an environment pointer and a code
pointer.

In Modula-2, procedures can be both passed and assigned, but only global
procedure values are allowed.  This can be checked statically and prevents
dangling environment pointers in a different way.  No environment pointer
is needed, so one-word pointers to code can be used as the implementation.

In Modula-3, you can pass any procedure but only assign a top-level procedure.
This precludes dangling environments in yet another way, that is more liberal
than either Pascal or Modula-2,, but requires a runtime check on procedure
assignments.  Modula-3 could be implemented using always two-word closures
with no marker, or the way it is.

In C, as extended by gcc, dangling environment pointers can happen and the
language makes no attempt to prevent them.  In the words of the gcc manual,
if you use one, "all hell will break loose".  Trampolines implement this
fine, while keeping pointers to global functions having the expected,
one-word representation.

My one handy Algol68 book has the usual tutorial language book problem: it
omits the cases you really need to look up.  It only states that there will
be problems if you use a dangling environment, but not whether the language
specifies this should be detected by the language, or whether "all hell will
break loose."  I'm guessing it's the latter. The implementation technique
Hendrik describes makes it a detected runtime error, but not unless/until
you try to use the lost environment.  This is more generous than Modula-3's rule.

And, of course, if your language is really dynamic, it could just say an
environment is always accessible, requiring many or all activation records
to be heap allocated.

Though it's obviously desirable,  Supporting all this for mixtures of
languages is, IMO, highly unrealistic without a lot of cooperation among
the developers of all the compilers of all the languages involved.  And this
involves both defining semantics and coming up with compatible implementations.
The horse is already long gone from the barn on other language definitions
and their compilers.

The system we now have is actually a quite good after-the-fact compromise.
It correctly implements Modula-3, and allows free intermixing of C and Modula-3
procedure/pointer-to-function values, as long as the values are not nested.
It also doesn't require an executable stack.  Not bad, considering we have
no influence on any other language definers or compiler writers.

Jay wrote:
>  
> Even though nested functions are a gcc extension to the C language, 
> email threads out there discuss Ada, Pascal, and even ! Modula-3 as 
> having nested functions, and that therefore deprecating the C language 
> feature doesn't "solve" the "problem".
>  
> I remain uncertain what, if anything, to do here.
>  - keep the -1 hack, do nothing
>     generalize it slightly to let targets pick "better" markers
>  - use gcc's supported for nested functions
>    (plus the integrated backend, not difficult)
>  
> Clearly this is a dilemna to more than just me. :)
>  
>  - Jay
>
-- 
-------------------------------------------------------------
Rodney M. Bates, retired assistant professor
Dept. of Computer Science, Wichita State University
Wichita, KS 67260-0083
316-978-3922
rodney.bates at wichita.edu


From hendrik at topoi.pooq.com  Sat May 31 15:29:24 2008
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sat, 31 May 2008 09:29:24 -0400
Subject: [M3devel] function pointers and comparison to nil? mis-typed
	function pointers?
In-Reply-To: <48408AEE.8090405@wichita.edu>
References: <483862F4.1E75.00D7.1@scires.com>
	
	
	<483A3377.7070801@wichita.edu>
	
	
	<48408AEE.8090405@wichita.edu>
Message-ID: <20080531132924.GA30413@topoi.pooq.com>

On Fri, May 30, 2008 at 06:17:02PM -0500, Rodney M. Bates wrote:
> 
> My one handy Algol68 book has the usual tutorial language book problem: it
> omits the cases you really need to look up.  It only states that there will
> be problems if you use a dangling environment, but not whether the language
> specifies this should be detected by the language, or whether "all hell will
> break loose."  I'm guessing it's the latter. The implementation technique
> Hendrik describes makes it a detected runtime error, but not unless/until
> you try to use the lost environment.  This is more generous than Modula-3's 
> rule.

The actual Algol 68 definition does pronounce on this.  The CDC 
implementation was much more liberal than the language definition.

Every reference/variable and every procedure has a scope.  The scope of 
a variable is the level on the run-time stack at which it is allocated.  
Variables can be on the heap; this is global scope.  The scope of a 
procedure is the stack elvel at which its most local global identifier 
is bound.  Even if the identifier refers to an object on the heap, it is 
the level at which it is bound that counts.

There is a universal scope restriction:  No object can refer to a more 
local object.  The constraint in the language definition is applied on 
assignment.

I know of no Algol 68 implementation that I can say for sure implements 
this restriction with a run-time check.  Of course it can be done, 
either by tagging each pointer with an explicit mention of its stack 
level (which takes space) or by comparing its value and comparing it to 
various stack locations in a kind of search.

The first release of the CDC algol 68 compiler just allocated all 
variables on the heap, making the check unnecessary for safety.  
Programmers almost never wrote code that passed procedures out-of-scope.

Later releases performed static analysis to determine where it was safe 
to allocate in the stack (almost all the time), and used the mechanism I 
described earlier to check procedures when they were called if the 
static check didn't suffice..
> 
> And, of course, if your language is really dynamic, it could just say an
> environment is always accessible, requiring many or all activation records
> to be heap allocated.

Which was a proposal made for the original Algol 68, but was turned 
down.  I think it should have been accepted.  We would have had a 
strongly-typed Scheme ahead of its time.

-- hendrik