From jay.krell at cornell.edu Thu Jul 1 11:23:01 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 1 Jul 2010 09:23:01 +0000 Subject: [M3devel] m3tests/cmp_fie vs. compare_file Message-ID: I find it confusing that m3-sys/m3tests/src/m3makefile contains both cmp_file and compare_file (unless one was a thin wrapper over the other, not the case) Olaf you added cmp_file in http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3tests/src/m3makefile.diff?r1=1.3;r2=1.4. Presumably they can be merged into one function? ?- Jay From wagner at elegosoft.com Thu Jul 1 11:38:53 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 01 Jul 2010 11:38:53 +0200 Subject: [M3devel] m3tests/cmp_fie vs. compare_file In-Reply-To: References: Message-ID: <20100701113853.cn7e82bwso48oc0s@mail.elegosoft.com> Quoting Jay K : > > I find it confusing that m3-sys/m3tests/src/m3makefile contains both > cmp_file and compare_file (unless one was a thin wrapper over the > other, not the case) > Olaf you added cmp_file in > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3tests/src/m3makefile.diff?r1=1.3;r2=1.4. > > Presumably they can be merged into one function? compare_file() writes output and doesn't return anything meaningful (it's a procedure), while cmp_file is a boolean state function that doesn't write anything to stdout. The first could be based on the second. Of course you can find a common signature, but then you'll have to change all occurences and add a use case parameter, which isn't nice, too. Perhaps you can suggest better names? Please do not change the semantics (i.e. the use of @cmp, for example) though, as that might break the regression tests. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Jul 1 12:26:15 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 1 Jul 2010 10:26:15 +0000 Subject: [M3devel] m3tests/cmp_fie vs. compare_file In-Reply-To: <20100701113853.cn7e82bwso48oc0s@mail.elegosoft.com> References: , <20100701113853.cn7e82bwso48oc0s@mail.elegosoft.com> Message-ID: Understood. They do a lot of the same but merging requires both a decent top-down understanding of the semantics to plan ahead slightly and then a close bottom-up line by line read to merge and preserve meaning. (I seem to be speaking like an MBA this evening. Don't worry. :) ) I don't have the energy for it at the moment. I am extending this area though, the stuff for recording and later comparing assembly output. Background: Fixing more configure -enable-checking seems to regress code /slightly/, in bit insert/extract. So I haven't commited said fix. So I'm going to try the bitfield refs again (that Tony had done). That might both fix and improve the code. Once they are merged the result can probably keep the name compare_file. Thanks for the overview. I'll try to look into this eventually and I'll try not to look into it too soon, before other things that are probably more useful (and more interesting and fun). Btw, there's stuff called "jux" in the code here. Is it rude to request sticking to English? Thanks. ?- Jay ---------------------------------------- > Date: Thu, 1 Jul 2010 11:38:53 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] m3tests/cmp_fie vs. compare_file > > Quoting Jay K : > > > > > I find it confusing that m3-sys/m3tests/src/m3makefile contains both > > cmp_file and compare_file (unless one was a thin wrapper over the > > other, not the case) > > Olaf you added cmp_file in > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3tests/src/m3makefile.diff?r1=1.3;r2=1.4. > > > > Presumably they can be merged into one function? > > compare_file() writes output and doesn't return anything meaningful > (it's a procedure), while cmp_file is a boolean state function that > doesn't write anything to stdout. > > The first could be based on the second. > > Of course you can find a common signature, but then you'll have to > change all occurences and add a use case parameter, which isn't nice, > too. > > Perhaps you can suggest better names? > > Please do not change the semantics (i.e. the use of @cmp, for example) > though, as that might break the regression tests. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Thu Jul 1 16:45:18 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 1 Jul 2010 14:45:18 +0000 Subject: [M3devel] add/subtract in Quake Message-ID: Folks might find this amusing or useful. I actually think I'm going to use it, just for the numbers 0-64.It implements addition and subtraction for a fixed range, here 0-9999Global variables are only used for initialization.Thereafter, just global constants (no enforcement of that, but I think it could be done by having initialization return them). Approach is that adding 1 to a single digit can be done with a small map.Adding 1 to multiple digits can be done using multiple variables and checking for "wraparound" to 0 (the table maps 9 to 0).You count up to 9999, filling in an Add1 and Sub1 hash table as you go up. I don't think quake has an appropriate looping mechanism, so counting up to 9999 is done recursively.Then Add and Sub are implemented recursively like Add1{Add(a, Sub1(b)}. local Add1 = { }local Sub1 = { } local counter0 = 0local counter1 = 0local counter2 = 0local counter3 = 0 local proc Increment() is local inc = { 0:1,1:2,2:3,3:4,4:5, 5:6,6:7,7:8,8:9,9:0 } counter0 = inc{counter0} if equal(counter0, 0) counter1 = inc{counter1} if equal(counter1, 0) counter2 = inc{counter2} if equal(counter2, 0) counter3 = inc{counter3} end end end local c = "" foreach d in [counter3, counter2, counter1, counter0] if not equal(d, 0) or not equal(c, "") c = c & d end end return cend proc InitMath_F1(a, b) is if equal(a, "9999") return end Add1{a} = b Sub1{b} = a InitMath_F1(b, Increment())end proc InitMath() is counter0 = 0 counter1 = 0 counter2 = 0 counter3 = 0 InitMath_F1(0, Increment())end proc Add(a, b) is if equal(a, 0) return b end if equal(b, 0) return a end if equal(a, 1) return Add1{b} end if equal(b, 1) return Add1{a} end return Add1{Add(a, Sub1{b})}end proc Sub(a, b) is if equal(a, 0) return b end if equal(b, 0) return a end if equal(a, 1) return Sub1{b} end if equal(b, 1) return Sub1{a} end return Sub1{Sub(a, Sub1{b})}end InitMath()write("99 - 40 is " & Sub(99, 40), CR)write("6 - 4 is " & Sub(6, 4), CR)write("3 + 2 is " & Add(2, 3), CR) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Thu Jul 1 22:33:13 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 01 Jul 2010 15:33:13 -0500 Subject: [M3devel] Another CVS question: duplicate local copies Message-ID: <4C2CFB89.4000406@lcwb.coop> I understand a release tag is "sticky", meaning once I specify it in a CVS command, the value I gave becomes internal state and will continue to be used in subsequent commands, until I do something explicitly to change it. Where is this state recorded? I particular, is it somewhere in the repository, or on my local disk? The motivation is this: I am now connected through a satellite internet service that has high latency, slow speed, and worst, a restrictive quota on bit volumes. I can scarcely afford the data transfer of frequent switches between the head and release branches. I want to keep a local copy of each. Can I do this? I made a complete copy of my local distribution, currently of the head. In the copy, I did "cvs -z9 -q update -r release_branch_cm3_5_8". So if I do an update in the future from inside the original directory, will I get head versions, and if I do it in my copy that is now the release branch, will I get updates to the release branch? Or do I have to specify tags carefully every time, no matter where I am? Or is this feasible at all? From wagner at elegosoft.com Thu Jul 1 22:51:37 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 01 Jul 2010 22:51:37 +0200 Subject: [M3devel] Another CVS question: duplicate local copies In-Reply-To: <4C2CFB89.4000406@lcwb.coop> References: <4C2CFB89.4000406@lcwb.coop> Message-ID: <20100701225137.lrzkgtfmswgcokcs@mail.elegosoft.com> Quoting "Rodney M. Bates" : > I understand a release tag is "sticky", meaning once I specify it in a > CVS command, the value I gave becomes internal state and will continue > to be used in subsequent commands, until I do something explicitly to > change it. Where is this state recorded? I particular, is it somewhere > in the repository, or on my local disk? It's in the CVS/Entries files; there's a column for sticky tags. It looks like this: % cat m3-libs/binIO/src/CVS/Entries /BinIO.i3/1.1.1.1/Sat Jan 5 16:32:08 2002//Trelease_branch_cm3_5_8 /BinIO.m3/1.1.1.1/Sat Jan 5 16:32:09 2002//Trelease_branch_cm3_5_8 /FastBinIO.i3/1.1.1.1/Sat Jan 5 16:32:09 2002//Trelease_branch_cm3_5_8 /FastBinIO.m3/1.1.1.1/Sat Jan 5 16:32:10 2002//Trelease_branch_cm3_5_8 /m3makefile/1.1.1.1/Sat Mar 27 11:42:57 2004//Trelease_branch_cm3_5_8 /m3overrides/1.2/Sat Jul 25 09:33:14 2009//Trelease_branch_cm3_5_8 D The repository does not know about any workspaces. > The motivation is this: I am now connected through a satellite internet > service that has high latency, slow speed, and worst, a restrictive > quota on bit volumes. I can scarcely afford the data transfer of > frequent switches between the head and release branches. I want to > keep a local copy of each. Can I do this? You can have as many CVS workspaces with different branches and versions as you like. > I made a complete copy of my local distribution, currently of the > head. In the copy, I did "cvs -z9 -q update -r release_branch_cm3_5_8". > So if I do an update in the future from inside the original directory, > will I get head versions, and if I do it in my copy that is now the > release branch, will I get updates to the release branch? Or do I > have to specify tags carefully every time, no matter where I am? > Or is this feasible at all? That should be no problem with CVS. Just be careful not to mess up the CVS directories manually. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Fri Jul 2 09:34:19 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 02 Jul 2010 09:34:19 +0200 Subject: [M3devel] add/subtract in Quake In-Reply-To: References: Message-ID: <20100702093419.0hvbuzj2ysocsk4s@mail.elegosoft.com> Shouldn't we rather define some standard quake functions and implement them in M3, like add, substract, multiply, div, mod? Probably working on TEXT of course... or even introduce a new quake type for integers? I haven't really thought about that, but I've missed integer arithmetics several times in the past, too. Olaf Quoting Jay K : > Folks might find this amusing or useful. I actually think I'm > going to use it, just for the numbers 0-64.It implements addition > and subtraction for a fixed range, here 0-9999Global variables are > only used for initialization.Thereafter, just global constants (no > enforcement of that, but I think it could be done by having > initialization return them). > Approach is that adding 1 to a single digit can be done with a small > map.Adding 1 to multiple digits can be done using multiple > variables and checking for "wraparound" to 0 (the table maps 9 to > 0).You count up to 9999, filling in an Add1 and Sub1 hash table as > you go up. I don't think quake has an appropriate looping > mechanism, so counting up to 9999 is done recursively.Then Add and > Sub are implemented recursively like Add1{Add(a, Sub1(b)}. > > local Add1 = { }local Sub1 = { } > > local counter0 = 0local counter1 = 0local counter2 = 0local counter3 = 0 > > local proc Increment() is local inc = { 0:1,1:2,2:3,3:4,4:5, > 5:6,6:7,7:8,8:9,9:0 } counter0 = inc{counter0} if > equal(counter0, 0) counter1 = inc{counter1} if equal(counter1, > 0) counter2 = inc{counter2} if equal(counter2, 0) > counter3 = inc{counter3} end end end local c = "" foreach > d in [counter3, counter2, counter1, counter0] if not equal(d, 0) > or not equal(c, "") c = c & d end end return cend > > proc InitMath_F1(a, b) is if equal(a, "9999") return end > Add1{a} = b Sub1{b} = a InitMath_F1(b, Increment())end > proc InitMath() is counter0 = 0 counter1 = 0 counter2 = 0 > counter3 = 0 InitMath_F1(0, Increment())end > > proc Add(a, b) is if equal(a, 0) return b end if equal(b, 0) > return a end if equal(a, 1) return Add1{b} end if equal(b, 1) > return Add1{a} end return Add1{Add(a, Sub1{b})}end > > proc Sub(a, b) is if equal(a, 0) return b end if equal(b, 0) > return a end if equal(a, 1) return Sub1{b} end if equal(b, 1) > return Sub1{a} end return Sub1{Sub(a, Sub1{b})}end > > InitMath()write("99 - 40 is " & Sub(99, 40), CR)write("6 - 4 is " & > Sub(6, 4), CR)write("3 + 2 is " & Add(2, 3), CR) -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Jul 2 10:10:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 2 Jul 2010 08:10:10 +0000 Subject: [M3devel] ppc_linux hanging Message-ID: Alas, PPC_LINUX is very prone to hang on head. ?e.g. compiling m3front. ?It doesn't hang with @M3nogc. ?The stack at the time just shows junk, no symbols at all. ? and info threads shows nothing, maybe I mistyped it. I'll try to figure it out. The biggest recent change I think is removing volatile so I'll start by trying with that put back. Also I use Darwin more lately, which has its own thread suspension code. Could be something broke the others. Later, ?- Jay From jay.krell at cornell.edu Fri Jul 2 10:20:26 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 2 Jul 2010 08:20:26 +0000 Subject: [M3devel] add/subtract in Quake In-Reply-To: <20100702093419.0hvbuzj2ysocsk4s@mail.elegosoft.com> References: , <20100702093419.0hvbuzj2ysocsk4s@mail.elegosoft.com> Message-ID: If someone can specify and/or implement, yes. In the meantime I'll proceed without. It appears many newlines were lost from my email rendering it unreadable. Arg. Then we maybe need for loops. And comparison and bitwise operation and shifting -- consider the case of combinatorial test generation...you nested for loop various integers from 0 to 1 and then shift them each a different amount, oring them together to get a test number... Or you loop from 0 to 2^n and you check for a bit set to decide which variation of that variable to generate. Or maybe we need a different scripting language. Python is very good. A friend is telling me about Lua. ? Need to check about portability to OpenBSD/mips64..never quite got Python working there, but close.. :) Or maybe we should use makefile.m3 that gets compiled on-demand or something. ? Really. Maybe. makefile.m3 around m3-sys would have to limit itself to working with old compiler/m3core/libm3. You know.."compiled languages" ought to compete better with "scripting languages".. the distinction belies any technical classification, to me. What is a "scripting language" vs. others? They are often interprted. But not always. Quake is acually compiled in a way. Often dynamically typed. But not always. Often lack tools for turning them into "executables". But not always. Often are slow. But not always. Usually are "safe". Always? ? But so sometimes are others: Modula-3, C#, Java, etc. ?- Jay ---------------------------------------- > Date: Fri, 2 Jul 2010 09:34:19 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] add/subtract in Quake > > Shouldn't we rather define some standard quake functions and implement > them in M3, like add, substract, multiply, div, mod? > Probably working on TEXT of course... or even introduce a new > quake type for integers? > > I haven't really thought about that, but I've missed integer arithmetics > several times in the past, too. > > Olaf > > Quoting Jay K : > > > Folks might find this amusing or useful. I actually think I'm > > going to use it, just for the numbers 0-64.It implements addition > > and subtraction for a fixed range, here 0-9999Global variables are > > only used for initialization.Thereafter, just global constants (no > > enforcement of that, but I think it could be done by having > > initialization return them). > > Approach is that adding 1 to a single digit can be done with a small > > map.Adding 1 to multiple digits can be done using multiple > > variables and checking for "wraparound" to 0 (the table maps 9 to > > 0).You count up to 9999, filling in an Add1 and Sub1 hash table as > > you go up. I don't think quake has an appropriate looping > > mechanism, so counting up to 9999 is done recursively.Then Add and > > Sub are implemented recursively like Add1{Add(a, Sub1(b)}. > > > > local Add1 = { }local Sub1 = { } > > > > local counter0 = 0local counter1 = 0local counter2 = 0local counter3 = 0 > > > > local proc Increment() is local inc = { 0:1,1:2,2:3,3:4,4:5, > > 5:6,6:7,7:8,8:9,9:0 } counter0 = inc{counter0} if > > equal(counter0, 0) counter1 = inc{counter1} if equal(counter1, > > 0) counter2 = inc{counter2} if equal(counter2, 0) > > counter3 = inc{counter3} end end end local c = "" foreach > > d in [counter3, counter2, counter1, counter0] if not equal(d, 0) > > or not equal(c, "") c = c & d end end return cend > > > > proc InitMath_F1(a, b) is if equal(a, "9999") return end > > Add1{a} = b Sub1{b} = a InitMath_F1(b, Increment())end > > proc InitMath() is counter0 = 0 counter1 = 0 counter2 = 0 > > counter3 = 0 InitMath_F1(0, Increment())end > > > > proc Add(a, b) is if equal(a, 0) return b end if equal(b, 0) > > return a end if equal(a, 1) return Add1{b} end if equal(b, 1) > > return Add1{a} end return Add1{Add(a, Sub1{b})}end > > > > proc Sub(a, b) is if equal(a, 0) return b end if equal(b, 0) > > return a end if equal(a, 1) return Sub1{b} end if equal(b, 1) > > return Sub1{a} end return Sub1{Sub(a, Sub1{b})}end > > > > InitMath()write("99 - 40 is " & Sub(99, 40), CR)write("6 - 4 is " & > > Sub(6, 4), CR)write("3 + 2 is " & Add(2, 3), CR) > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Fri Jul 2 12:35:09 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 2 Jul 2010 10:35:09 +0000 Subject: [M3devel] object oriented programming in Quake Message-ID: next in the series of advanced programming in quake... Perl/Python-esque "objects" (aka hash tables) ?- Quake doesn't have lexical scoping. Or therefore closures. ? ??? So you have to pass the this pointer manually. ? - Quake does allow naming a procedure to act like taking its address; it can be stored and called later. ?????? This is really the only thing that helps the situation. ?- I wasn't able to write "void member functions" aka "methods that don't return anything", thus the "a = " ?- There is no private/protected. ?- Similar reduction in making typos static errors: ie: a{"foo"} = 1 vs. a{"food"} = 1, whichever you meant, no matter, ?? you get what you typed, no errors. ? - No "inheritance" demonstrated but er you could probably say there is JavaScript-esque prototyping -- just assign from another object (hash table) proc NewCounter() is ? local proc inc(this) is ??? this{"c"} = Add(this{"c"}, 1) ??? return this ? end ? local proc get(this) is ??? return this{"c"} ? end ? local this = { } ? this{"c"} = 0 ? this{"inc"} = inc ? this{"get"} = get ? return this end local c1 = NewCounter() local c2 = NewCounter() write("c1 is " & c1{"get"}(c1), CR) a = c1{"inc"}(c1) write("c1 is " & c1{"get"}(c1), CR) a = c1{"inc"}(c1) a = c1{"inc"}(c1) write("c1 is " & c1{"get"}(c1), CR) write("c2 is " & c2{"get"}(c2), CR) a = c2{"inc"}(c2) a = c2{"inc"}(c2) a = c2{"inc"}(c2) write("c2 is " & c2{"get"}(c2), CR) ?- Jay From jay.krell at cornell.edu Fri Jul 2 13:04:54 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 2 Jul 2010 11:04:54 +0000 Subject: [M3devel] looping over range of integers in quake Message-ID: Given the lack of lexical scoping and closures, the second form is preferred. ? Actually there is lexical scoping it seems, but not closures. Maybe more on that later. proc For(start, endd, body) is ? if equal(start, endd & "") ??? return ? end ? body(start) ? For(Add(start, 1), endd, body) end For(0, 10, write) write(CR) proc ToString(a) is ? return a & "" end proc Range(start, endd) is % I thought local a good idea here but no. ? proc Helper(result, start, endd) is ??? if equal(start, endd) ????? return result ??? end ??? result += start ??? return Helper(result, Add(start, 1), endd) ? end ? return Helper([ ], ToString(start), ToString(endd)) end foreach i in Range(0, 10) ? write(i, CR) end From jay.krell at cornell.edu Sat Jul 3 12:37:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 3 Jul 2010 10:37:36 +0000 Subject: [M3devel] ppc_linux hanging In-Reply-To: References: Message-ID: Alas, good news, bad news, restoring volatile on every load/store seems to fix this. I wasn't even optimizing. Tony any ideas? I386_LINUX is ok. AMD64_DARWIN is ok. SOLgnu is ok, but that doesn't count. I left volatile on there, was worried for some reason about interaction with stack walker, I forget. So far the debugger is being very uncooperative, can't set any breakpoints..it works for C. Aha.. gcc -gstabs+ -fPIC -pie 2.c (gdb) break main Breakpoint 1 at 0x658: file 2.c, line 3. (gdb) run Starting program: /home/jay/a.out Warning: Cannot insert breakpoint 1. Error accessing memory address 0x658: Input/output error. (gdb) q The program is running.? Exit anyway? (y or n) y jay at plin:~$ gcc -gstabs+ -fPIC 2.c jay at plin:~$ gdb ./a.out GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.? Type "show copying" and "show warranty" for details. This GDB was configured as "powerpc-linux-gnu"... (gdb) break main Breakpoint 1 at 0x10000448: file 2.c, line 3. (gdb) run Starting program: /home/jay/a.out Breakpoint 1, main () at 2.c:3 3??? } So lame.. ? - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: ppc_linux hanging > Date: Fri, 2 Jul 2010 08:10:10 +0000 > > > Alas, PPC_LINUX is very prone to hang on head. > e.g. compiling m3front. > It doesn't hang with @M3nogc. > The stack at the time just shows junk, no symbols at all. > and info threads shows nothing, maybe I mistyped it. > > > I'll try to figure it out. > The biggest recent change I think is removing volatile so I'll start > by trying with that put back. > > > Also I use Darwin more lately, which has its own thread suspension code. > Could be something broke the others. > > > Later, > - Jay > > From jay.krell at cornell.edu Sat Jul 3 13:21:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 3 Jul 2010 11:21:44 +0000 Subject: [M3devel] quake continue Message-ID: It'd be very nice if quake had "continue". I find myself having to indent loops further and further and further when continue is really want I want. You can fake it by moving code into a function and using return but... ?- Jay From jay.krell at cornell.edu Sat Jul 3 17:13:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 3 Jul 2010 15:13:20 +0000 Subject: [M3devel] Could not find a legal alignment for the packed type? Message-ID: "../I386_LINUX/bitfield.m3", line 16078: Could not find a legal alignment for the packed type. <*NOWARN*>TYPE BitField_offset63_count1 = RECORD ?offset:BITS 63 FOR? [0L .. Long.RightShift(Long.Not(0L), 1)]; ?value:BITS 1 FOR? [0L .. Long.RightShift(Long.Not(0L), 63)]; END; ? Does that make sense? Obviously? the record contains one LONGINT broken up into a 1 bit field and a 63 bit field. I'll try removing the "BITS FOR". ? - Jay From rodney_bates at lcwb.coop Sat Jul 3 18:09:27 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 03 Jul 2010 11:09:27 -0500 Subject: [M3devel] Another CVS question: duplicate local copies In-Reply-To: <20100701225137.lrzkgtfmswgcokcs@mail.elegosoft.com> References: <4C2CFB89.4000406@lcwb.coop> <20100701225137.lrzkgtfmswgcokcs@mail.elegosoft.com> Message-ID: <4C2F60B7.3070903@lcwb.coop> OK, thanks. I had since noticed the tags in .../CVS/Entries files. It seems to be working, after I remembered to add -dAP to my cvs update command. Olaf Wagner wrote: > Quoting "Rodney M. Bates" : > >> I understand a release tag is "sticky", meaning once I specify it in a >> CVS command, the value I gave becomes internal state and will continue >> to be used in subsequent commands, until I do something explicitly to >> change it. Where is this state recorded? I particular, is it somewhere >> in the repository, or on my local disk? > > It's in the CVS/Entries files; there's a column for sticky tags. > It looks like this: > > % cat m3-libs/binIO/src/CVS/Entries > /BinIO.i3/1.1.1.1/Sat Jan 5 16:32:08 2002//Trelease_branch_cm3_5_8 > /BinIO.m3/1.1.1.1/Sat Jan 5 16:32:09 2002//Trelease_branch_cm3_5_8 > /FastBinIO.i3/1.1.1.1/Sat Jan 5 16:32:09 2002//Trelease_branch_cm3_5_8 > /FastBinIO.m3/1.1.1.1/Sat Jan 5 16:32:10 2002//Trelease_branch_cm3_5_8 > /m3makefile/1.1.1.1/Sat Mar 27 11:42:57 2004//Trelease_branch_cm3_5_8 > /m3overrides/1.2/Sat Jul 25 09:33:14 2009//Trelease_branch_cm3_5_8 > D > > The repository does not know about any workspaces. > >> The motivation is this: I am now connected through a satellite internet >> service that has high latency, slow speed, and worst, a restrictive >> quota on bit volumes. I can scarcely afford the data transfer of >> frequent switches between the head and release branches. I want to >> keep a local copy of each. Can I do this? > > You can have as many CVS workspaces with different branches and > versions as you like. > >> I made a complete copy of my local distribution, currently of the >> head. In the copy, I did "cvs -z9 -q update -r release_branch_cm3_5_8". >> So if I do an update in the future from inside the original directory, >> will I get head versions, and if I do it in my copy that is now the >> release branch, will I get updates to the release branch? Or do I >> have to specify tags carefully every time, no matter where I am? >> Or is this feasible at all? > > That should be no problem with CVS. > Just be careful not to mess up the CVS directories manually. > > Olaf From jay.krell at cornell.edu Sun Jul 4 02:03:05 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 00:03:05 +0000 Subject: [M3devel] "exact codegen" testing Message-ID: m3-sys/m3tests now has infrastructure for "exact codegen" testing. An interesting thing I just realized, is that it is, well, it is trivial. And it is applicable to any test. If the "expected" directory exists, then it gets compared. ? Now, probably in such cases you want to "trim" the code some, such as by turning off or reducing symbols. This can be used for cross builds -- since assembly is what cross builds produce on the host, and assembly is what this looks at. Probably then what is needed is a script to loop through all architectures and update whichever tests have checked in assembly. Or a two step, produce them all, present diff to human, update them all. There is a temporary problem right now that I made the "c" tests run. They include one with an infinite loop. I'll undo that now. "p" tests are now subtely redefined. Previously: Programs whose output is interesting or for which running them is interesting. Now: "code" tests that are safe to run (ie. they need not do anything), i.e should always be built and run, even if running them doesn't do anything interesting, building them does. I'll move c135 to be a "p" test. c135 should probably be expanded further. Specifically with the goal of covering every single M3CG_Op and every boolean parameter combination thereof. ? i.e. extract with sign extend both true and false, though for example extract_n(sign_extend=true) is never ? used by the frontend. Iterating through integer values can't be done for all values, but booleans can be. There's still a fair amount missing. Though other tests and building the system itself should provide much/all of it. ?- Jay From hosking at cs.purdue.edu Sun Jul 4 02:29:00 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 3 Jul 2010 20:29:00 -0400 Subject: [M3devel] ppc_linux hanging In-Reply-To: References: Message-ID: <9B486681-F277-414E-8A67-F2A63E2BC4CD@cs.purdue.edu> Is there something about the memory model on PPC? It manifests as a hang, correct? On 3 Jul 2010, at 06:37, Jay K wrote: > > Alas, good news, bad news, restoring volatile on every load/store seems to fix this. > I wasn't even optimizing. > > Tony any ideas? > > I386_LINUX is ok. AMD64_DARWIN is ok. > SOLgnu is ok, but that doesn't count. I left volatile on there, was worried for some reason about interaction with stack walker, I forget. > > So far the debugger is being very uncooperative, can't set any breakpoints..it works for C. > > Aha.. > > gcc -gstabs+ -fPIC -pie 2.c > (gdb) break main > Breakpoint 1 at 0x658: file 2.c, line 3. > (gdb) run > Starting program: /home/jay/a.out > Warning: > Cannot insert breakpoint 1. > Error accessing memory address 0x658: Input/output error. > > > (gdb) q > The program is running. Exit anyway? (y or n) y > jay at plin:~$ gcc -gstabs+ -fPIC 2.c > jay at plin:~$ gdb ./a.out > GNU gdb 6.8-debian > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "powerpc-linux-gnu"... > (gdb) break main > Breakpoint 1 at 0x10000448: file 2.c, line 3. > (gdb) run > Starting program: /home/jay/a.out > > Breakpoint 1, main () at 2.c:3 > 3 } > > > So lame.. > > - Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Subject: ppc_linux hanging >> Date: Fri, 2 Jul 2010 08:10:10 +0000 >> >> >> Alas, PPC_LINUX is very prone to hang on head. >> e.g. compiling m3front. >> It doesn't hang with @M3nogc. >> The stack at the time just shows junk, no symbols at all. >> and info threads shows nothing, maybe I mistyped it. >> >> >> I'll try to figure it out. >> The biggest recent change I think is removing volatile so I'll start >> by trying with that put back. >> >> >> Also I use Darwin more lately, which has its own thread suspension code. >> Could be something broke the others. >> >> >> Later, >> - Jay >> >> > From jay.krell at cornell.edu Sun Jul 4 02:38:16 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 00:38:16 +0000 Subject: [M3devel] ppc_linux hanging In-Reply-To: <9B486681-F277-414E-8A67-F2A63E2BC4CD@cs.purdue.edu> References: , , <9B486681-F277-414E-8A67-F2A63E2BC4CD@cs.purdue.edu> Message-ID: I'm afraid I just don't know. Now I'm seeing: Fatal Error: bad version stamps: TextClass.i3 version stamp mismatch: M3_BUILTIN.TEXT ? <61b2d19ae7136110> => TextClass.i3 ? => M3_BUILTIN.i3? ?*** execution of [, From: hosking at cs.purdue.edu > Date: Sat, 3 Jul 2010 20:29:00 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] ppc_linux hanging > > Is there something about the memory model on PPC? It manifests as a hang, correct? > > On 3 Jul 2010, at 06:37, Jay K wrote: > > > > > Alas, good news, bad news, restoring volatile on every load/store seems to fix this. > > I wasn't even optimizing. > > > > Tony any ideas? > > > > I386_LINUX is ok. AMD64_DARWIN is ok. > > SOLgnu is ok, but that doesn't count. I left volatile on there, was worried for some reason about interaction with stack walker, I forget. > > > > So far the debugger is being very uncooperative, can't set any breakpoints..it works for C. > > > > Aha.. > > > > gcc -gstabs+ -fPIC -pie 2.c > > (gdb) break main > > Breakpoint 1 at 0x658: file 2.c, line 3. > > (gdb) run > > Starting program: /home/jay/a.out > > Warning: > > Cannot insert breakpoint 1. > > Error accessing memory address 0x658: Input/output error. > > > > > > (gdb) q > > The program is running. Exit anyway? (y or n) y > > jay at plin:~$ gcc -gstabs+ -fPIC 2.c > > jay at plin:~$ gdb ./a.out > > GNU gdb 6.8-debian > > Copyright (C) 2008 Free Software Foundation, Inc. > > License GPLv3+: GNU GPL version 3 or later > > This is free software: you are free to change and redistribute it. > > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > > and "show warranty" for details. > > This GDB was configured as "powerpc-linux-gnu"... > > (gdb) break main > > Breakpoint 1 at 0x10000448: file 2.c, line 3. > > (gdb) run > > Starting program: /home/jay/a.out > > > > Breakpoint 1, main () at 2.c:3 > > 3 } > > > > > > So lame.. > > > > - Jay > > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: m3devel at elegosoft.com > >> Subject: ppc_linux hanging > >> Date: Fri, 2 Jul 2010 08:10:10 +0000 > >> > >> > >> Alas, PPC_LINUX is very prone to hang on head. > >> e.g. compiling m3front. > >> It doesn't hang with @M3nogc. > >> The stack at the time just shows junk, no symbols at all. > >> and info threads shows nothing, maybe I mistyped it. > >> > >> > >> I'll try to figure it out. > >> The biggest recent change I think is removing volatile so I'll start > >> by trying with that put back. > >> > >> > >> Also I use Darwin more lately, which has its own thread suspension code. > >> Could be something broke the others. > >> > >> > >> Later, > >> - Jay > >> > >> > > > From jay.krell at cornell.edu Sun Jul 4 03:16:23 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 01:16:23 +0000 Subject: [M3devel] aliases/optimization In-Reply-To: <00538FB2-00DA-4C0E-82F3-D151B9A85A0E@cs.purdue.edu> References: <20100703105709.DBD2E2474003@birch.elegosoft.com>, , , , , , <00538FB2-00DA-4C0E-82F3-D151B9A85A0E@cs.purdue.edu> Message-ID: aha you just reminded me of something that we need to remember a bit and apply soon. Depending on compilers, optimization, etc. gcc doesn't like: float f; int i; i = *(int*)&f; though I think that's perfectly reasonable..anyway the equivalent form of code that gcc is explicitly ok with is: float f; int i; union { ? float f; ? int i; } u; u.f = f; i = u.i; So, point being, we should try changing LOOPHOLE to compile like that. You know, cons up the union type on-demand, make a local, etc. If we are lucky, that might solve some of our problems. Not the PPC ones. But that I left some systematic use of volatile in, like for all floating point, or something. And maybe it'll fix some of the optimizations I disabled. ? It'd still leave "unit at a time" broken. ? Possibly in tree-nested we can remove any notion of the functions being nested and ?? maybe that'll help.. Search the for "gcc type punning" ?=> wikipedia ?=> link at the bottom http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Optimize-Options.html#index-fstrict_002daliasing-542 There is a subtlty there though..we'd have use member_ref on the union. They also give some pointer to what to do "for real". I can follow up, later. Disabling unit at a time is also lame. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Sat, 3 Jul 2010 20:50:11 -0400 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > I added it a long time back only because I saw failures with optimisation turned on. Something to do with the alias analysis (and lack of proper type information) as far as I recall. > > > On 3 Jul 2010, at 20:44, Jay K wrote: > > > > > Tony, just to be clear..you/I are disturbed by volatile, but it has also, I believe, like always been there. > > It has been gone only very briefly, and its non-use is probably limited for other reasons (how many people are > > using it, on how many platforms?). > > > > > > - Jay > > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: hosking at cs.purdue.edu; jkrell at elego.de > >> CC: m3commit at elegosoft.com > >> Subject: RE: [M3commit] CVS Update: cm3 > >> Date: Sun, 4 Jul 2010 00:42:20 +0000 > >> > >> > >> Not a multiprocessor. > >> Still interested in selective volatile? > >> > >> > >> This all bothers me too. > >> I don't want volatile. It makes the optimized code terrible. > >> But I don't want to debug any problem from removing it, beyond compilation failure. > >> > >> > >> I can try a few things. > >> This is all wierd. I swear I saw it hang several times. > >> I swear I'm trying to to change "too many" variables at a time. Yes, I know, 2 is too many. > >> > >> > >> Once I started getting version stamp mismatch, I resorted to using a cross built cm3. > >> Out of necessity sort of, but that causes more flucuation of variables. > >> > >> Let me try again with volatile and see if it is solid. > >> Then I'll try with only volatile stores. > >> > >> I've been trying optimized and unoptimized, and not kept good track of which when. > >> > >> > >> - Jay > >> > >> > >> ---------------------------------------- > >>> From: hosking at cs.purdue.edu > >>> Date: Sat, 3 Jul 2010 20:36:20 -0400 > >>> To: jkrell at elego.de > >>> CC: m3commit at elegosoft.com > >>> Subject: Re: [M3commit] CVS Update: cm3 > >>> > >>> I am very disturbed that volatile is needed here. Can we selectively turn it on for thread-critical files like ThreadPThread and see if it fixes the problem. I wonder if the double-checked locking is broken for PPC memory model. Is this on a multi-processor? > >>> > >>> On 3 Jul 2010, at 12:57, Jay Krell wrote: > >>> > >>>> CVSROOT: /usr/cvs > >>>> Changes by: jkrell at birch. 10/07/03 12:57:09 > >>>> > >>>> Modified files: > >>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > >>>> > >>>> Log message: > >>>> restore volatile for powerpc and powerpc64 platforms > >>>> This seems to fix PPC_LINUX hanging. > >>>> This needs further debugging, but I'm not eager. > >>>> This will also affect PPC_DARWIN, PPC64_DARWIN, PPC32_OPENBSD, > >>>> PPC32_NETBSD, PPC32_FREEBSD, etc., but these platforms are little used or > >>>> nonexistant. > >>>> > >>>> Having volatile like has been the very long standing situation though. > >>>> The result is that the optimizer does basically nothing. > >>> > >> > > > From jay.krell at cornell.edu Sun Jul 4 10:14:47 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 08:14:47 +0000 Subject: [M3devel] aliases/optimization In-Reply-To: References: <20100703105709.DBD2E2474003@birch.elegosoft.com>, , , , , , <00538FB2-00DA-4C0E-82F3-D151B9A85A0E@cs.purdue.edu>, Message-ID: It appears this behavior is part of the C frontend, not the backend. It appears..that maybe..we should provide a langhook get_alias_set that always returns 0. The default is always -1. Not clear to me. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: aliases/optimization > Date: Sun, 4 Jul 2010 01:16:23 +0000 > > > aha you just reminded me of something that we need to remember a bit and apply soon. > > > Depending on compilers, optimization, etc. gcc doesn't like: > > > float f; > int i; > i = *(int*)&f; > > though I think that's perfectly reasonable..anyway the equivalent form of code that gcc is explicitly ok with is: > > float f; > > int i; > union { > float f; > int i; > } u; > u.f = f; > i = u.i; > > So, point being, we should try changing LOOPHOLE to compile like that. > You know, cons up the union type on-demand, make a local, etc. > > If we are lucky, that might solve some of our problems. > Not the PPC ones. > But that I left some systematic use of volatile in, like for all floating point, or something. > And maybe it'll fix some of the optimizations I disabled. > It'd still leave "unit at a time" broken. > Possibly in tree-nested we can remove any notion of the functions being nested and > maybe that'll help.. > > Search the for "gcc type punning" > => wikipedia > => link at the bottom > > http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Optimize-Options.html#index-fstrict_002daliasing-542 > > There is a subtlty there though..we'd have use member_ref on the union. > They also give some pointer to what to do "for real". I can follow up, later. > > > Disabling unit at a time is also lame. > > > - Jay > > ---------------------------------------- > > From: hosking at cs.purdue.edu > > Date: Sat, 3 Jul 2010 20:50:11 -0400 > > To: jay.krell at cornell.edu > > CC: m3commit at elegosoft.com > > Subject: Re: [M3commit] CVS Update: cm3 > > > > I added it a long time back only because I saw failures with optimisation turned on. Something to do with the alias analysis (and lack of proper type information) as far as I recall. > > > > > > On 3 Jul 2010, at 20:44, Jay K wrote: > > > > > > > > Tony, just to be clear..you/I are disturbed by volatile, but it has also, I believe, like always been there. > > > It has been gone only very briefly, and its non-use is probably limited for other reasons (how many people are > > > using it, on how many platforms?). > > > > > > > > > - Jay > > > > > > ---------------------------------------- > > >> From: jay.krell at cornell.edu > > >> To: hosking at cs.purdue.edu; jkrell at elego.de > > >> CC: m3commit at elegosoft.com > > >> Subject: RE: [M3commit] CVS Update: cm3 > > >> Date: Sun, 4 Jul 2010 00:42:20 +0000 > > >> > > >> > > >> Not a multiprocessor. > > >> Still interested in selective volatile? > > >> > > >> > > >> This all bothers me too. > > >> I don't want volatile. It makes the optimized code terrible. > > >> But I don't want to debug any problem from removing it, beyond compilation failure. > > >> > > >> > > >> I can try a few things. > > >> This is all wierd. I swear I saw it hang several times. > > >> I swear I'm trying to to change "too many" variables at a time. Yes, I know, 2 is too many. > > >> > > >> > > >> Once I started getting version stamp mismatch, I resorted to using a cross built cm3. > > >> Out of necessity sort of, but that causes more flucuation of variables. > > >> > > >> Let me try again with volatile and see if it is solid. > > >> Then I'll try with only volatile stores. > > >> > > >> I've been trying optimized and unoptimized, and not kept good track of which when. > > >> > > >> > > >> - Jay > > >> > > >> > > >> ---------------------------------------- > > >>> From: hosking at cs.purdue.edu > > >>> Date: Sat, 3 Jul 2010 20:36:20 -0400 > > >>> To: jkrell at elego.de > > >>> CC: m3commit at elegosoft.com > > >>> Subject: Re: [M3commit] CVS Update: cm3 > > >>> > > >>> I am very disturbed that volatile is needed here. Can we selectively turn it on for thread-critical files like ThreadPThread and see if it fixes the problem. I wonder if the double-checked locking is broken for PPC memory model. Is this on a multi-processor? > > >>> > > >>> On 3 Jul 2010, at 12:57, Jay Krell wrote: > > >>> > > >>>> CVSROOT: /usr/cvs > > >>>> Changes by: jkrell at birch. 10/07/03 12:57:09 > > >>>> > > >>>> Modified files: > > >>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > >>>> > > >>>> Log message: > > >>>> restore volatile for powerpc and powerpc64 platforms > > >>>> This seems to fix PPC_LINUX hanging. > > >>>> This needs further debugging, but I'm not eager. > > >>>> This will also affect PPC_DARWIN, PPC64_DARWIN, PPC32_OPENBSD, > > >>>> PPC32_NETBSD, PPC32_FREEBSD, etc., but these platforms are little used or > > >>>> nonexistant. > > >>>> > > >>>> Having volatile like has been the very long standing situation though. > > >>>> The result is that the optimizer does basically nothing. > > >>> > > >> > > > > > > From jay.krell at cornell.edu Sun Jul 4 10:18:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 08:18:31 +0000 Subject: [M3devel] aliases/optimization In-Reply-To: References: <20100703105709.DBD2E2474003@birch.elegosoft.com>, , , , , , <00538FB2-00DA-4C0E-82F3-D151B9A85A0E@cs.purdue.edu>, , Message-ID: er, well, clearly, if we just assign flag_strict_aliasing = false, this stuff all falls away. That I will try. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: aliases/optimization > Date: Sun, 4 Jul 2010 08:14:47 +0000 > > > It appears this behavior is part of the C frontend, not the backend. > It appears..that maybe..we should provide a langhook get_alias_set that always returns 0. > The default is always -1. > Not clear to me. > > - Jay > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: hosking at cs.purdue.edu > > CC: m3devel at elegosoft.com > > Subject: aliases/optimization > > Date: Sun, 4 Jul 2010 01:16:23 +0000 > > > > > > aha you just reminded me of something that we need to remember a bit and apply soon. > > > > > > Depending on compilers, optimization, etc. gcc doesn't like: > > > > > > float f; > > int i; > > i = *(int*)&f; > > > > though I think that's perfectly reasonable..anyway the equivalent form of code that gcc is explicitly ok with is: > > > > float f; > > > > int i; > > union { > > float f; > > int i; > > } u; > > u.f = f; > > i = u.i; > > > > So, point being, we should try changing LOOPHOLE to compile like that. > > You know, cons up the union type on-demand, make a local, etc. > > > > If we are lucky, that might solve some of our problems. > > Not the PPC ones. > > But that I left some systematic use of volatile in, like for all floating point, or something. > > And maybe it'll fix some of the optimizations I disabled. > > It'd still leave "unit at a time" broken. > > Possibly in tree-nested we can remove any notion of the functions being nested and > > maybe that'll help.. > > > > Search the for "gcc type punning" > > => wikipedia > > => link at the bottom > > > > http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Optimize-Options.html#index-fstrict_002daliasing-542 > > > > There is a subtlty there though..we'd have use member_ref on the union. > > They also give some pointer to what to do "for real". I can follow up, later. > > > > > > Disabling unit at a time is also lame. > > > > > > - Jay > > > > ---------------------------------------- > > > From: hosking at cs.purdue.edu > > > Date: Sat, 3 Jul 2010 20:50:11 -0400 > > > To: jay.krell at cornell.edu > > > CC: m3commit at elegosoft.com > > > Subject: Re: [M3commit] CVS Update: cm3 > > > > > > I added it a long time back only because I saw failures with optimisation turned on. Something to do with the alias analysis (and lack of proper type information) as far as I recall. > > > > > > > > > On 3 Jul 2010, at 20:44, Jay K wrote: > > > > > > > > > > > Tony, just to be clear..you/I are disturbed by volatile, but it has also, I believe, like always been there. > > > > It has been gone only very briefly, and its non-use is probably limited for other reasons (how many people are > > > > using it, on how many platforms?). > > > > > > > > > > > > - Jay > > > > > > > > ---------------------------------------- > > > >> From: jay.krell at cornell.edu > > > >> To: hosking at cs.purdue.edu; jkrell at elego.de > > > >> CC: m3commit at elegosoft.com > > > >> Subject: RE: [M3commit] CVS Update: cm3 > > > >> Date: Sun, 4 Jul 2010 00:42:20 +0000 > > > >> > > > >> > > > >> Not a multiprocessor. > > > >> Still interested in selective volatile? > > > >> > > > >> > > > >> This all bothers me too. > > > >> I don't want volatile. It makes the optimized code terrible. > > > >> But I don't want to debug any problem from removing it, beyond compilation failure. > > > >> > > > >> > > > >> I can try a few things. > > > >> This is all wierd. I swear I saw it hang several times. > > > >> I swear I'm trying to to change "too many" variables at a time. Yes, I know, 2 is too many. > > > >> > > > >> > > > >> Once I started getting version stamp mismatch, I resorted to using a cross built cm3. > > > >> Out of necessity sort of, but that causes more flucuation of variables. > > > >> > > > >> Let me try again with volatile and see if it is solid. > > > >> Then I'll try with only volatile stores. > > > >> > > > >> I've been trying optimized and unoptimized, and not kept good track of which when. > > > >> > > > >> > > > >> - Jay > > > >> > > > >> > > > >> ---------------------------------------- > > > >>> From: hosking at cs.purdue.edu > > > >>> Date: Sat, 3 Jul 2010 20:36:20 -0400 > > > >>> To: jkrell at elego.de > > > >>> CC: m3commit at elegosoft.com > > > >>> Subject: Re: [M3commit] CVS Update: cm3 > > > >>> > > > >>> I am very disturbed that volatile is needed here. Can we selectively turn it on for thread-critical files like ThreadPThread and see if it fixes the problem. I wonder if the double-checked locking is broken for PPC memory model. Is this on a multi-processor? > > > >>> > > > >>> On 3 Jul 2010, at 12:57, Jay Krell wrote: > > > >>> > > > >>>> CVSROOT: /usr/cvs > > > >>>> Changes by: jkrell at birch. 10/07/03 12:57:09 > > > >>>> > > > >>>> Modified files: > > > >>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > >>>> > > > >>>> Log message: > > > >>>> restore volatile for powerpc and powerpc64 platforms > > > >>>> This seems to fix PPC_LINUX hanging. > > > >>>> This needs further debugging, but I'm not eager. > > > >>>> This will also affect PPC_DARWIN, PPC64_DARWIN, PPC32_OPENBSD, > > > >>>> PPC32_NETBSD, PPC32_FREEBSD, etc., but these platforms are little used or > > > >>>> nonexistant. > > > >>>> > > > >>>> Having volatile like has been the very long standing situation though. > > > >>>> The result is that the optimizer does basically nothing. > > > >>> > > > >> > > > > > > > > > > From jay.krell at cornell.edu Sun Jul 4 16:25:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 14:25:04 +0000 Subject: [M3devel] eliminating volatile on floats Message-ID: Through simple trial/error I've tracked a need (the only need?) for floats down: If I set flag_tree_ter = 0, I can compile m3core where I couldn't before, with -O3. I suspect due to: builtins.c: int get_pointer_alignment (tree exp, unsigned int max_align) { ? unsigned int align, inner; ? /* We rely on TER to compute accurate alignment information.? */ ? if (!(optimize && flag_tree_ter)) ??? return 0; Another thing to try is #if 0 out this block of code (it is not in parse,c but "gcc? itself"). That should yield more optimization, but more patch to gcc. I'm inclined to try that. There should be additional options, like getting the alignment correct or such. The code that fails to compile is: /dev2/cm3/m3-libs/m3core/src/float/IEEE/LongFloat.m3 PROCEDURE CopySign (x, y: T): T = ? VAR res := x; ? BEGIN ??? LOOPHOLE (res, Rep.T).sign := LOOPHOLE (y, Rep.T).sign; ??? RETURN res; ? END CopySign; I also tried some other options like adding volatile and/or temporaries on loophole's using t_struct. (To be clear, we only have volatile on float loads, not stores, though I think only stores would be preferable to only loads. "reads are more common than writes", "consider the registers to be a write-through cache") ?- Jay From jay.krell at cornell.edu Sun Jul 4 16:44:26 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 14:44:26 +0000 Subject: [M3devel] other optimizations to think about? Message-ID: Given that we know vaguely what these things are: ??? flag_strict_aliasing = 0; ??? flag_strict_overflow = 0; I'm inclined to turn them off in m3cg/parse.c like how a few others are. They sound kind of scary and not valuable. strict_aliasing I believe is something like where if you have pointers to integers and pointers to floats, writes through one are assumed to not affect reads through the other. ? So the reads can be cached in registers across the writes. Tony has mentioned a need for alias analysis a few times, so.. Or we could just turn it off in unsafe modules or once we see a loophole, perhaps. strict_overflow is something like where the compiler assumes there shall be no signed integer overflow, ?or that signed integer overflow doesn't trap?, and then make optimizations based on that assumption. I don't feel I'm yet willing to give up a possibly systematic that signed oveflow silently overflow. This optimization in fact I believe/thought defeats the obvious ways to check for overflow. int add(int a, int b) { int c = a + b; ?? if (c < a) ????? error_and_exit("overflow"); ? return c; } strict overflow means c can't be less than a, so the check can be optimized away. I wasn't able to reproduce this, granted, with: ?Apple gcc 4.2 ? Debian 5.0 gcc 4.3 ? self-built gcc 4.5 http://gcc.gnu.org/gcc-4.2/changes.html does sound like what I'm saying though. er, wait, what I showed is the unsigned algorithm, duh. void overflow(void); int add(int a, int b) { ? int c = (a + b); ? int asign = (a < 0); ? if (asign == (b < 0) && asign != (c < 0)) ??? overflow(); ? return c; } still, doesn't have a problem. (explanation: overflow occured if inputs have same sign and output differs from their sign overflow cannot occur if inputs have different sign sign(x) equivalent to (x < 0) (maps one to one: negative => 1, positive => 0) ) ?- Jay From jay.krell at cornell.edu Sun Jul 4 16:54:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 14:54:03 +0000 Subject: [M3devel] other optimizations to think about? In-Reply-To: References: Message-ID: proofreading... > strict_overflow is something like where the compiler assumes there shall be no signed integer overflow, ?or that signed integer overflow doesn't trap?, and then make optimizations based on that assumption. > I don't feel I'm yet willing to give up a possibly systematic that signed oveflow silently overflow. DOES trap systematic ASSUMPTION ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: other optimizations to think about? > Date: Sun, 4 Jul 2010 14:44:26 +0000 > > > Given that we know vaguely what these things are: > flag_strict_aliasing = 0; > flag_strict_overflow = 0; > > > I'm inclined to turn them off in m3cg/parse.c like how a few others are. > They sound kind of scary and not valuable. > > > strict_aliasing I believe is something like where if you have pointers to integers and pointers to floats, writes through one are assumed to not affect reads through the other. > So the reads can be cached in registers across the writes. > Tony has mentioned a need for alias analysis a few times, so.. > Or we could just turn it off in unsafe modules or once we see a loophole, perhaps. > > > strict_overflow is something like where the compiler assumes there shall be no signed integer overflow, ?or that signed integer overflow doesn't trap?, and then make optimizations based on that assumption. > I don't feel I'm yet willing to give up a possibly systematic that signed oveflow silently overflow. > This optimization in fact I believe/thought defeats the obvious ways to check for overflow. > int add(int a, int b) > { int c = a + b; > if (c < a) > error_and_exit("overflow"); > return c; > } > > strict overflow means c can't be less than a, so the check can be optimized away. > > I wasn't able to reproduce this, granted, with: > Apple gcc 4.2 > Debian 5.0 gcc 4.3 > self-built gcc 4.5 > > http://gcc.gnu.org/gcc-4.2/changes.html > > does sound like what I'm saying though. > > er, wait, what I showed is the unsigned algorithm, duh. > > void overflow(void); > > int add(int a, int b) > { > int c = (a + b); > int asign = (a < 0); > if (asign == (b < 0) && asign != (c < 0)) > overflow(); > return c; > } > > still, doesn't have a problem. > > (explanation: > overflow occured if inputs have same sign and output differs from their sign > overflow cannot occur if inputs have different sign > sign(x) equivalent to (x < 0) (maps one to one: negative => 1, positive => 0) > ) > > > - Jay > From hosking at cs.purdue.edu Sun Jul 4 16:49:55 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 4 Jul 2010 10:49:55 -0400 Subject: [M3devel] eliminating volatile on floats In-Reply-To: References: Message-ID: I don't understand what we would need to do to fix this without the hack of commenting out gcc functionality. Better to give gcc something it likes than to hack it. On 4 Jul 2010, at 10:25, Jay K wrote: > > Through simple trial/error I've tracked a need (the only need?) for floats down: > > If I set flag_tree_ter = 0, I can compile m3core where I couldn't before, with -O3. > > > I suspect due to: > > builtins.c: > > int > get_pointer_alignment (tree exp, unsigned int max_align) > { > unsigned int align, inner; > > /* We rely on TER to compute accurate alignment information. */ > if (!(optimize && flag_tree_ter)) > return 0; > > > Another thing to try is #if 0 out this block of code (it is not in parse,c but "gcc itself"). > That should yield more optimization, but more patch to gcc. > I'm inclined to try that. > > > There should be additional options, like getting the alignment correct or such. > > > The code that fails to compile is: > /dev2/cm3/m3-libs/m3core/src/float/IEEE/LongFloat.m3 > > > PROCEDURE CopySign (x, y: T): T = > VAR res := x; > BEGIN > LOOPHOLE (res, Rep.T).sign := LOOPHOLE (y, Rep.T).sign; > RETURN res; > END CopySign; > > > I also tried some other options like adding volatile and/or temporaries on loophole's using t_struct. > > > (To be clear, we only have volatile on float loads, not stores, though I think only stores would be preferable to only loads. > "reads are more common than writes", "consider the registers to be a write-through cache") > > > - Jay > From hosking at cs.purdue.edu Sun Jul 4 16:47:50 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 4 Jul 2010 10:47:50 -0400 Subject: [M3devel] aliases/optimization In-Reply-To: References: <20100703105709.DBD2E2474003@birch.elegosoft.com>, , , , , , <00538FB2-00DA-4C0E-82F3-D151B9A85A0E@cs.purdue.edu>, Message-ID: I thought I already implemented one of those. On 4 Jul 2010, at 04:14, Jay K wrote: > > It appears this behavior is part of the C frontend, not the backend. > It appears..that maybe..we should provide a langhook get_alias_set that always returns 0. > The default is always -1. > Not clear to me. > > - Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: aliases/optimization >> Date: Sun, 4 Jul 2010 01:16:23 +0000 >> >> >> aha you just reminded me of something that we need to remember a bit and apply soon. >> >> >> Depending on compilers, optimization, etc. gcc doesn't like: >> >> >> float f; >> int i; >> i = *(int*)&f; >> >> though I think that's perfectly reasonable..anyway the equivalent form of code that gcc is explicitly ok with is: >> >> float f; >> >> int i; >> union { >> float f; >> int i; >> } u; >> u.f = f; >> i = u.i; >> >> So, point being, we should try changing LOOPHOLE to compile like that. >> You know, cons up the union type on-demand, make a local, etc. >> >> If we are lucky, that might solve some of our problems. >> Not the PPC ones. >> But that I left some systematic use of volatile in, like for all floating point, or something. >> And maybe it'll fix some of the optimizations I disabled. >> It'd still leave "unit at a time" broken. >> Possibly in tree-nested we can remove any notion of the functions being nested and >> maybe that'll help.. >> >> Search the for "gcc type punning" >> => wikipedia >> => link at the bottom >> >> http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Optimize-Options.html#index-fstrict_002daliasing-542 >> >> There is a subtlty there though..we'd have use member_ref on the union. >> They also give some pointer to what to do "for real". I can follow up, later. >> >> >> Disabling unit at a time is also lame. >> >> >> - Jay >> >> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> Date: Sat, 3 Jul 2010 20:50:11 -0400 >>> To: jay.krell at cornell.edu >>> CC: m3commit at elegosoft.com >>> Subject: Re: [M3commit] CVS Update: cm3 >>> >>> I added it a long time back only because I saw failures with optimisation turned on. Something to do with the alias analysis (and lack of proper type information) as far as I recall. >>> >>> >>> On 3 Jul 2010, at 20:44, Jay K wrote: >>> >>>> >>>> Tony, just to be clear..you/I are disturbed by volatile, but it has also, I believe, like always been there. >>>> It has been gone only very briefly, and its non-use is probably limited for other reasons (how many people are >>>> using it, on how many platforms?). >>>> >>>> >>>> - Jay >>>> >>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: hosking at cs.purdue.edu; jkrell at elego.de >>>>> CC: m3commit at elegosoft.com >>>>> Subject: RE: [M3commit] CVS Update: cm3 >>>>> Date: Sun, 4 Jul 2010 00:42:20 +0000 >>>>> >>>>> >>>>> Not a multiprocessor. >>>>> Still interested in selective volatile? >>>>> >>>>> >>>>> This all bothers me too. >>>>> I don't want volatile. It makes the optimized code terrible. >>>>> But I don't want to debug any problem from removing it, beyond compilation failure. >>>>> >>>>> >>>>> I can try a few things. >>>>> This is all wierd. I swear I saw it hang several times. >>>>> I swear I'm trying to to change "too many" variables at a time. Yes, I know, 2 is too many. >>>>> >>>>> >>>>> Once I started getting version stamp mismatch, I resorted to using a cross built cm3. >>>>> Out of necessity sort of, but that causes more flucuation of variables. >>>>> >>>>> Let me try again with volatile and see if it is solid. >>>>> Then I'll try with only volatile stores. >>>>> >>>>> I've been trying optimized and unoptimized, and not kept good track of which when. >>>>> >>>>> >>>>> - Jay >>>>> >>>>> >>>>> ---------------------------------------- >>>>>> From: hosking at cs.purdue.edu >>>>>> Date: Sat, 3 Jul 2010 20:36:20 -0400 >>>>>> To: jkrell at elego.de >>>>>> CC: m3commit at elegosoft.com >>>>>> Subject: Re: [M3commit] CVS Update: cm3 >>>>>> >>>>>> I am very disturbed that volatile is needed here. Can we selectively turn it on for thread-critical files like ThreadPThread and see if it fixes the problem. I wonder if the double-checked locking is broken for PPC memory model. Is this on a multi-processor? >>>>>> >>>>>> On 3 Jul 2010, at 12:57, Jay Krell wrote: >>>>>> >>>>>>> CVSROOT: /usr/cvs >>>>>>> Changes by: jkrell at birch. 10/07/03 12:57:09 >>>>>>> >>>>>>> Modified files: >>>>>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >>>>>>> >>>>>>> Log message: >>>>>>> restore volatile for powerpc and powerpc64 platforms >>>>>>> This seems to fix PPC_LINUX hanging. >>>>>>> This needs further debugging, but I'm not eager. >>>>>>> This will also affect PPC_DARWIN, PPC64_DARWIN, PPC32_OPENBSD, >>>>>>> PPC32_NETBSD, PPC32_FREEBSD, etc., but these platforms are little used or >>>>>>> nonexistant. >>>>>>> >>>>>>> Having volatile like has been the very long standing situation though. >>>>>>> The result is that the optimizer does basically nothing. >>>>>> >>>>> >>>> >>> >> > From jay.krell at cornell.edu Sun Jul 4 16:57:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 14:57:24 +0000 Subject: [M3devel] aliases/optimization In-Reply-To: <393E6607-54BD-4776-AB1E-D68BDA6F6906@cs.purdue.edu> References: <20100703105709.DBD2E2474003@birch.elegosoft.com>, , , , , , <00538FB2-00DA-4C0E-82F3-D151B9A85A0E@cs.purdue.edu> , <393E6607-54BD-4776-AB1E-D68BDA6F6906@cs.purdue.edu> Message-ID: Further research suggests this is frontend behavior, not backend. Oops my mistake. I read the C compiler documentation and forget about that division. Though I haven't tried this, it appears maybe a "lang hook" get_alias_set that returns 0 might be an easy win pessimistic win. Perhaps, again, only in unsafe modules and/or modules that use loophole (yes, I realize loophole implies unsafe). It's not clear to me yet what the default alias analysis is. -1 seems to mean "the default" and 0 seems to mean "pessimisic" Oh I didn't realize, we have: alias_set_type m3_get_alias_set (tree ARG_UNUSED (t)) { ? return 0; } which I'm pretty sure means pessimistic. ?- Jay ---------------------------------------- > Subject: Re: aliases/optimization > From: hosking at cs.purdue.edu > Date: Sun, 4 Jul 2010 10:47:03 -0400 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > Yes, that's right! > > On 3 Jul 2010, at 21:16, Jay K wrote: > > > > > aha you just reminded me of something that we need to remember a bit and apply soon. > > > > > > Depending on compilers, optimization, etc. gcc doesn't like: > > > > > > float f; > > int i; > > i = *(int*)&f; > > > > though I think that's perfectly reasonable..anyway the equivalent form of code that gcc is explicitly ok with is: > > > > float f; > > > > int i; > > union { > > float f; > > int i; > > } u; > > u.f = f; > > i = u.i; > > > > So, point being, we should try changing LOOPHOLE to compile like that. > > You know, cons up the union type on-demand, make a local, etc. > > > > If we are lucky, that might solve some of our problems. > > Not the PPC ones. > > But that I left some systematic use of volatile in, like for all floating point, or something. > > And maybe it'll fix some of the optimizations I disabled. > > It'd still leave "unit at a time" broken. > > Possibly in tree-nested we can remove any notion of the functions being nested and > > maybe that'll help.. > > > > Search the for "gcc type punning" > > => wikipedia > > => link at the bottom > > > > http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Optimize-Options.html#index-fstrict_002daliasing-542 > > > > There is a subtlty there though..we'd have use member_ref on the union. > > They also give some pointer to what to do "for real". I can follow up, later. > > > > > > Disabling unit at a time is also lame. > > > > > > - Jay > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Sat, 3 Jul 2010 20:50:11 -0400 > >> To: jay.krell at cornell.edu > >> CC: m3commit at elegosoft.com > >> Subject: Re: [M3commit] CVS Update: cm3 > >> > >> I added it a long time back only because I saw failures with optimisation turned on. Something to do with the alias analysis (and lack of proper type information) as far as I recall. > >> > >> > >> On 3 Jul 2010, at 20:44, Jay K wrote: > >> > >>> > >>> Tony, just to be clear..you/I are disturbed by volatile, but it has also, I believe, like always been there. > >>> It has been gone only very briefly, and its non-use is probably limited for other reasons (how many people are > >>> using it, on how many platforms?). > >>> > >>> > >>> - Jay > >>> > >>> ---------------------------------------- > >>>> From: jay.krell at cornell.edu > >>>> To: hosking at cs.purdue.edu; jkrell at elego.de > >>>> CC: m3commit at elegosoft.com > >>>> Subject: RE: [M3commit] CVS Update: cm3 > >>>> Date: Sun, 4 Jul 2010 00:42:20 +0000 > >>>> > >>>> > >>>> Not a multiprocessor. > >>>> Still interested in selective volatile? > >>>> > >>>> > >>>> This all bothers me too. > >>>> I don't want volatile. It makes the optimized code terrible. > >>>> But I don't want to debug any problem from removing it, beyond compilation failure. > >>>> > >>>> > >>>> I can try a few things. > >>>> This is all wierd. I swear I saw it hang several times. > >>>> I swear I'm trying to to change "too many" variables at a time. Yes, I know, 2 is too many. > >>>> > >>>> > >>>> Once I started getting version stamp mismatch, I resorted to using a cross built cm3. > >>>> Out of necessity sort of, but that causes more flucuation of variables. > >>>> > >>>> Let me try again with volatile and see if it is solid. > >>>> Then I'll try with only volatile stores. > >>>> > >>>> I've been trying optimized and unoptimized, and not kept good track of which when. > >>>> > >>>> > >>>> - Jay > >>>> > >>>> > >>>> ---------------------------------------- > >>>>> From: hosking at cs.purdue.edu > >>>>> Date: Sat, 3 Jul 2010 20:36:20 -0400 > >>>>> To: jkrell at elego.de > >>>>> CC: m3commit at elegosoft.com > >>>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>>> > >>>>> I am very disturbed that volatile is needed here. Can we selectively turn it on for thread-critical files like ThreadPThread and see if it fixes the problem. I wonder if the double-checked locking is broken for PPC memory model. Is this on a multi-processor? > >>>>> > >>>>> On 3 Jul 2010, at 12:57, Jay Krell wrote: > >>>>> > >>>>>> CVSROOT: /usr/cvs > >>>>>> Changes by: jkrell at birch. 10/07/03 12:57:09 > >>>>>> > >>>>>> Modified files: > >>>>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > >>>>>> > >>>>>> Log message: > >>>>>> restore volatile for powerpc and powerpc64 platforms > >>>>>> This seems to fix PPC_LINUX hanging. > >>>>>> This needs further debugging, but I'm not eager. > >>>>>> This will also affect PPC_DARWIN, PPC64_DARWIN, PPC32_OPENBSD, > >>>>>> PPC32_NETBSD, PPC32_FREEBSD, etc., but these platforms are little used or > >>>>>> nonexistant. > >>>>>> > >>>>>> Having volatile like has been the very long standing situation though. > >>>>>> The result is that the optimizer does basically nothing. > >>>>> > >>>> > >>> > >> > > > From jay.krell at cornell.edu Sun Jul 4 16:57:49 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 14:57:49 +0000 Subject: [M3devel] aliases/optimization In-Reply-To: References: <20100703105709.DBD2E2474003@birch.elegosoft.com>, ,,, , , , , , , <00538FB2-00DA-4C0E-82F3-D151B9A85A0E@cs.purdue.edu>, , , , Message-ID: Yep I just noticed, finally. ?- Jay --------------------------------------- > From: hosking at cs.purdue.edu > Date: Sun, 4 Jul 2010 10:47:50 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] aliases/optimization > > I thought I already implemented one of those. > > On 4 Jul 2010, at 04:14, Jay K wrote: > > > > > It appears this behavior is part of the C frontend, not the backend. > > It appears..that maybe..we should provide a langhook get_alias_set that always returns 0. > > The default is always -1. > > Not clear to me. > > > > - Jay > > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: hosking at cs.purdue.edu > >> CC: m3devel at elegosoft.com > >> Subject: aliases/optimization > >> Date: Sun, 4 Jul 2010 01:16:23 +0000 > >> > >> > >> aha you just reminded me of something that we need to remember a bit and apply soon. > >> > >> > >> Depending on compilers, optimization, etc. gcc doesn't like: > >> > >> > >> float f; > >> int i; > >> i = *(int*)&f; > >> > >> though I think that's perfectly reasonable..anyway the equivalent form of code that gcc is explicitly ok with is: > >> > >> float f; > >> > >> int i; > >> union { > >> float f; > >> int i; > >> } u; > >> u.f = f; > >> i = u.i; > >> > >> So, point being, we should try changing LOOPHOLE to compile like that. > >> You know, cons up the union type on-demand, make a local, etc. > >> > >> If we are lucky, that might solve some of our problems. > >> Not the PPC ones. > >> But that I left some systematic use of volatile in, like for all floating point, or something. > >> And maybe it'll fix some of the optimizations I disabled. > >> It'd still leave "unit at a time" broken. > >> Possibly in tree-nested we can remove any notion of the functions being nested and > >> maybe that'll help.. > >> > >> Search the for "gcc type punning" > >> => wikipedia > >> => link at the bottom > >> > >> http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Optimize-Options.html#index-fstrict_002daliasing-542 > >> > >> There is a subtlty there though..we'd have use member_ref on the union. > >> They also give some pointer to what to do "for real". I can follow up, later. > >> > >> > >> Disabling unit at a time is also lame. > >> > >> > >> - Jay > >> > >> ---------------------------------------- > >>> From: hosking at cs.purdue.edu > >>> Date: Sat, 3 Jul 2010 20:50:11 -0400 > >>> To: jay.krell at cornell.edu > >>> CC: m3commit at elegosoft.com > >>> Subject: Re: [M3commit] CVS Update: cm3 > >>> > >>> I added it a long time back only because I saw failures with optimisation turned on. Something to do with the alias analysis (and lack of proper type information) as far as I recall. > >>> > >>> > >>> On 3 Jul 2010, at 20:44, Jay K wrote: > >>> > >>>> > >>>> Tony, just to be clear..you/I are disturbed by volatile, but it has also, I believe, like always been there. > >>>> It has been gone only very briefly, and its non-use is probably limited for other reasons (how many people are > >>>> using it, on how many platforms?). > >>>> > >>>> > >>>> - Jay > >>>> > >>>> ---------------------------------------- > >>>>> From: jay.krell at cornell.edu > >>>>> To: hosking at cs.purdue.edu; jkrell at elego.de > >>>>> CC: m3commit at elegosoft.com > >>>>> Subject: RE: [M3commit] CVS Update: cm3 > >>>>> Date: Sun, 4 Jul 2010 00:42:20 +0000 > >>>>> > >>>>> > >>>>> Not a multiprocessor. > >>>>> Still interested in selective volatile? > >>>>> > >>>>> > >>>>> This all bothers me too. > >>>>> I don't want volatile. It makes the optimized code terrible. > >>>>> But I don't want to debug any problem from removing it, beyond compilation failure. > >>>>> > >>>>> > >>>>> I can try a few things. > >>>>> This is all wierd. I swear I saw it hang several times. > >>>>> I swear I'm trying to to change "too many" variables at a time. Yes, I know, 2 is too many. > >>>>> > >>>>> > >>>>> Once I started getting version stamp mismatch, I resorted to using a cross built cm3. > >>>>> Out of necessity sort of, but that causes more flucuation of variables. > >>>>> > >>>>> Let me try again with volatile and see if it is solid. > >>>>> Then I'll try with only volatile stores. > >>>>> > >>>>> I've been trying optimized and unoptimized, and not kept good track of which when. > >>>>> > >>>>> > >>>>> - Jay > >>>>> > >>>>> > >>>>> ---------------------------------------- > >>>>>> From: hosking at cs.purdue.edu > >>>>>> Date: Sat, 3 Jul 2010 20:36:20 -0400 > >>>>>> To: jkrell at elego.de > >>>>>> CC: m3commit at elegosoft.com > >>>>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>>>> > >>>>>> I am very disturbed that volatile is needed here. Can we selectively turn it on for thread-critical files like ThreadPThread and see if it fixes the problem. I wonder if the double-checked locking is broken for PPC memory model. Is this on a multi-processor? > >>>>>> > >>>>>> On 3 Jul 2010, at 12:57, Jay Krell wrote: > >>>>>> > >>>>>>> CVSROOT: /usr/cvs > >>>>>>> Changes by: jkrell at birch. 10/07/03 12:57:09 > >>>>>>> > >>>>>>> Modified files: > >>>>>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > >>>>>>> > >>>>>>> Log message: > >>>>>>> restore volatile for powerpc and powerpc64 platforms > >>>>>>> This seems to fix PPC_LINUX hanging. > >>>>>>> This needs further debugging, but I'm not eager. > >>>>>>> This will also affect PPC_DARWIN, PPC64_DARWIN, PPC32_OPENBSD, > >>>>>>> PPC32_NETBSD, PPC32_FREEBSD, etc., but these platforms are little used or > >>>>>>> nonexistant. > >>>>>>> > >>>>>>> Having volatile like has been the very long standing situation though. > >>>>>>> The result is that the optimizer does basically nothing. > >>>>>> > >>>>> > >>>> > >>> > >> > > > From hosking at cs.purdue.edu Sun Jul 4 16:47:03 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 4 Jul 2010 10:47:03 -0400 Subject: [M3devel] aliases/optimization In-Reply-To: References: <20100703105709.DBD2E2474003@birch.elegosoft.com>, , , , , , <00538FB2-00DA-4C0E-82F3-D151B9A85A0E@cs.purdue.edu> Message-ID: <393E6607-54BD-4776-AB1E-D68BDA6F6906@cs.purdue.edu> Yes, that's right! On 3 Jul 2010, at 21:16, Jay K wrote: > > aha you just reminded me of something that we need to remember a bit and apply soon. > > > Depending on compilers, optimization, etc. gcc doesn't like: > > > float f; > int i; > i = *(int*)&f; > > though I think that's perfectly reasonable..anyway the equivalent form of code that gcc is explicitly ok with is: > > float f; > > int i; > union { > float f; > int i; > } u; > u.f = f; > i = u.i; > > So, point being, we should try changing LOOPHOLE to compile like that. > You know, cons up the union type on-demand, make a local, etc. > > If we are lucky, that might solve some of our problems. > Not the PPC ones. > But that I left some systematic use of volatile in, like for all floating point, or something. > And maybe it'll fix some of the optimizations I disabled. > It'd still leave "unit at a time" broken. > Possibly in tree-nested we can remove any notion of the functions being nested and > maybe that'll help.. > > Search the for "gcc type punning" > => wikipedia > => link at the bottom > > http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Optimize-Options.html#index-fstrict_002daliasing-542 > > There is a subtlty there though..we'd have use member_ref on the union. > They also give some pointer to what to do "for real". I can follow up, later. > > > Disabling unit at a time is also lame. > > > - Jay > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Sat, 3 Jul 2010 20:50:11 -0400 >> To: jay.krell at cornell.edu >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> I added it a long time back only because I saw failures with optimisation turned on. Something to do with the alias analysis (and lack of proper type information) as far as I recall. >> >> >> On 3 Jul 2010, at 20:44, Jay K wrote: >> >>> >>> Tony, just to be clear..you/I are disturbed by volatile, but it has also, I believe, like always been there. >>> It has been gone only very briefly, and its non-use is probably limited for other reasons (how many people are >>> using it, on how many platforms?). >>> >>> >>> - Jay >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: hosking at cs.purdue.edu; jkrell at elego.de >>>> CC: m3commit at elegosoft.com >>>> Subject: RE: [M3commit] CVS Update: cm3 >>>> Date: Sun, 4 Jul 2010 00:42:20 +0000 >>>> >>>> >>>> Not a multiprocessor. >>>> Still interested in selective volatile? >>>> >>>> >>>> This all bothers me too. >>>> I don't want volatile. It makes the optimized code terrible. >>>> But I don't want to debug any problem from removing it, beyond compilation failure. >>>> >>>> >>>> I can try a few things. >>>> This is all wierd. I swear I saw it hang several times. >>>> I swear I'm trying to to change "too many" variables at a time. Yes, I know, 2 is too many. >>>> >>>> >>>> Once I started getting version stamp mismatch, I resorted to using a cross built cm3. >>>> Out of necessity sort of, but that causes more flucuation of variables. >>>> >>>> Let me try again with volatile and see if it is solid. >>>> Then I'll try with only volatile stores. >>>> >>>> I've been trying optimized and unoptimized, and not kept good track of which when. >>>> >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>>> From: hosking at cs.purdue.edu >>>>> Date: Sat, 3 Jul 2010 20:36:20 -0400 >>>>> To: jkrell at elego.de >>>>> CC: m3commit at elegosoft.com >>>>> Subject: Re: [M3commit] CVS Update: cm3 >>>>> >>>>> I am very disturbed that volatile is needed here. Can we selectively turn it on for thread-critical files like ThreadPThread and see if it fixes the problem. I wonder if the double-checked locking is broken for PPC memory model. Is this on a multi-processor? >>>>> >>>>> On 3 Jul 2010, at 12:57, Jay Krell wrote: >>>>> >>>>>> CVSROOT: /usr/cvs >>>>>> Changes by: jkrell at birch. 10/07/03 12:57:09 >>>>>> >>>>>> Modified files: >>>>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >>>>>> >>>>>> Log message: >>>>>> restore volatile for powerpc and powerpc64 platforms >>>>>> This seems to fix PPC_LINUX hanging. >>>>>> This needs further debugging, but I'm not eager. >>>>>> This will also affect PPC_DARWIN, PPC64_DARWIN, PPC32_OPENBSD, >>>>>> PPC32_NETBSD, PPC32_FREEBSD, etc., but these platforms are little used or >>>>>> nonexistant. >>>>>> >>>>>> Having volatile like has been the very long standing situation though. >>>>>> The result is that the optimizer does basically nothing. >>>>> >>>> >>> >> > From jay.krell at cornell.edu Sun Jul 4 17:01:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 15:01:53 +0000 Subject: [M3devel] eliminating volatile on floats In-Reply-To: References: , Message-ID: The #if 0 didn't seem to work. I'll go with ter = 0 for now. Then maybe look at what equivalent C does. I still think the problem is maybe something about alignment, more than type punning/aliases, though they are related. I checked some obvious things, like, if alignment of int/long/float/double/void* were other than I expected in C. I'll go with ter = 0 for now. I think I'll commit that as some steps forward and backward but not a bad tradeoff. Granted, I don't know really what ter is and how effective it is, but O1, O2, O3 are each a "bundle" of quite a number of optimizations. Throwing out some of them seems not too terrible. Throwing in volatile definitely defeats a lot, and probably not the ones I turn off. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Sun, 4 Jul 2010 10:49:55 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] eliminating volatile on floats > > I don't understand what we would need to do to fix this without the hack of commenting out gcc functionality. Better to give gcc something it likes than to hack it. > > On 4 Jul 2010, at 10:25, Jay K wrote: > > > > > Through simple trial/error I've tracked a need (the only need?) for floats down: > > > > If I set flag_tree_ter = 0, I can compile m3core where I couldn't before, with -O3. > > > > > > I suspect due to: > > > > builtins.c: > > > > int > > get_pointer_alignment (tree exp, unsigned int max_align) > > { > > unsigned int align, inner; > > > > /* We rely on TER to compute accurate alignment information. */ > > if (!(optimize && flag_tree_ter)) > > return 0; > > > > > > Another thing to try is #if 0 out this block of code (it is not in parse,c but "gcc itself"). > > That should yield more optimization, but more patch to gcc. > > I'm inclined to try that. > > > > > > There should be additional options, like getting the alignment correct or such. > > > > > > The code that fails to compile is: > > /dev2/cm3/m3-libs/m3core/src/float/IEEE/LongFloat.m3 > > > > > > PROCEDURE CopySign (x, y: T): T = > > VAR res := x; > > BEGIN > > LOOPHOLE (res, Rep.T).sign := LOOPHOLE (y, Rep.T).sign; > > RETURN res; > > END CopySign; > > > > > > I also tried some other options like adding volatile and/or temporaries on loophole's using t_struct. > > > > > > (To be clear, we only have volatile on float loads, not stores, though I think only stores would be preferable to only loads. > > "reads are more common than writes", "consider the registers to be a write-through cache") > > > > > > - Jay > > > From jay.krell at cornell.edu Sun Jul 4 17:50:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 15:50:03 +0000 Subject: [M3devel] volatile float/ter/copysign Message-ID: This is the code that often fails to compile. Aha, well look at that. PROCEDURE CopySign (x, y: T): T = ? VAR res := x; ? BEGIN ??? LOOPHOLE (res, Rep.T).sign := LOOPHOLE (y, Rep.T).sign; ??? RETURN res; ? END CopySign; There's no loophole! Store lreal, load int64->word8 => insert_mn => store int64->word8. There are several other ways to write this code, but I guess that's not the point. (552) begin_procedure ? procedure LongFloat__CopySign ?LongFloat__CopySign(553) set_source_line ? source line? 117 (554) load ? type:lreal ? type:lreal ? m3cg_load (M3_CtKayy_x): offset 0x0, convert lreal -> lreal (555) store ? type:lreal ? type:lreal ? store (M3_CtKayy_res) offset:0x0 src_t:lreal dst_t:lreal (556) set_source_line ? source line? 119 (557) load ? type:word8 ? type:int64 ? m3cg_load (M3_CtKayy_y): offset 0x38, convert word8 -> int64 (558) extract_mn ? type:int64 ?extract_mn offset:7 count:1 sign_extend:0 (559) load ? type:word8 ? type:int64 ? m3cg_load (M3_CtKayy_res): offset 0x38, convert word8 -> int64 (560) swap ? type:int64 ? type:int64 (561) insert_mn ? type:int64 ?insert_mn offset:7 count:1 (562) store ? type:int64 ? type:word8 ? store (M3_CtKayy_res) offset:0x38 src_t:int64 dst_t:word8 (563) set_source_line ? source line? 120 (564) load ? type:lreal ? type:lreal ? m3cg_load (M3_CtKayy_res): offset 0x0, convert lreal -> lreal (565) exit_proc ? type:lreal (566) end_procedure ?- Jay From jay.krell at cornell.edu Sun Jul 4 18:20:01 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 16:20:01 +0000 Subject: [M3devel] licensing (gcc patches) Message-ID: licensing "for the record" I don't necessarily want to discuss it.. It has been speculated here that our gcc patches weren't acceptable because our license is more restrictive than GPL. I believe it is more like the opposite. Our patches not accepted because our license is /less/ restrictive. ?To most of the code. Not to the patch or files added to gcc. ?? They can't really be. In particular, by splitting cm3 from m3cg, the license "boundary" is stopped. parse.c is/must be GPL. All the various *.m3 files not. GPL advocates would prefer GPL code be linked to more code, thus forcing more code to be GPL. Doing something like splitting "something" into two processes is kind of a deliberate anti-GPL move. It may or may not make good engineering sense. (It does and it doesn't, in fact. It is good for development/testing, bad for performance.) Lately they allow "plugins", though they must be GPL. Gcc faces "competition", e.g. LLVM. Maybe things are more relaxed now. Besides all that, non-trivial gcc patches require signing FSF papers. Something I at least am very unlikely able to do. But the vast bulk of the work I had nothing to do with. And you can remove my changs with little effect. Alternatively of course, LLVM has a more liberal license. Generating C has no licening problem. Porting m3back to more targets ditto.. ?- Jay From hendrik at topoi.pooq.com Sun Jul 4 22:04:18 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 4 Jul 2010 16:04:18 -0400 Subject: [M3devel] licensing (gcc patches) In-Reply-To: References: Message-ID: <20100704200418.GC22573@topoi.pooq.com> On Sun, Jul 04, 2010 at 04:20:01PM +0000, Jay K wrote: > > licensing > > > "for the record" > I don't necessarily want to discuss it.. > > > It has been speculated here that > our gcc patches weren't acceptable > because our license is more restrictive than GPL. > > > I believe it is more like the opposite. > Our patches not accepted because our license is /less/ restrictive. The restriction I see in the modula 3 license is everyone dealing in Modula 3 code has to allow SRC to do anything they want to any of it. This 'requirement to allow' is a restriction that doesn't apply to GPL, so in that sense we're more restrictive. In pretty well all other ways, we're less restrictive. > ?To most of the code. Not to the patch or files added to gcc. > ?They can't really be. Of course any code we *add* at this point can be dual-licensed, letting people who get it use one license, or the other, or both, at their option. -- hendrik From wagner at elegosoft.com Mon Jul 5 09:32:30 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 05 Jul 2010 09:32:30 +0200 Subject: [M3devel] licensing (gcc patches) In-Reply-To: <20100704200418.GC22573@topoi.pooq.com> References: <20100704200418.GC22573@topoi.pooq.com> Message-ID: <20100705093230.k462uhajq8cc8kkw@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Sun, Jul 04, 2010 at 04:20:01PM +0000, Jay K wrote: >> >> licensing >> >> "for the record" >> I don't necessarily want to discuss it.. >> >> >> It has been speculated here that >> our gcc patches weren't acceptable >> because our license is more restrictive than GPL. >> >> I believe it is more like the opposite. >> Our patches not accepted because our license is /less/ restrictive. > > The restriction I see in the modula 3 license is everyone dealing in > Modula 3 code has to allow SRC to do anything they want to any of it. > This 'requirement to allow' is a restriction that doesn't apply to GPL, > so in that sense we're more restrictive. > > In pretty well all other ways, we're less restrictive. The M3 licence allows free use and distribution of the code in source and binary format. There is no restriction that source must be provided if it is changed or sold or just used as a service by anyone, i.e. it is no viral license. The only provision is that _if_ patches are returned to the copyright owner (which can be DEC, Critical Mass, or others), they may use them for any purpose they wish without any restriction, too. Actually, both DEC and Critical Mass won't (any more). At least as far as I can see... >> ?To most of the code. Not to the patch or files added to gcc. >> ?They can't really be. > > Of course any code we *add* at this point can be dual-licensed, letting > people who get it use one license, or the other, or both, at their > option. Code linked with gcc must be under GPL. That's why DEC went to all this fuss with two-phase compilation using two processes. Otherwise all the M3 compiler code would need to be distributed as source by anyone who uses it, too. GPL is still pretty much a no-go for commercial use. In fact that's the reason why the FSF never accepted the M3 extensions for gcc; they didn't approve of the license `workaround'. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Jul 5 09:39:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 07:39:44 +0000 Subject: [M3devel] licensing (gcc patches) In-Reply-To: <20100704200418.GC22573@topoi.pooq.com> References: , <20100704200418.GC22573@topoi.pooq.com> Message-ID: > Of course any code we *add* at this point can be dual-licensed, letting I find "dual license" confusing. I like the BSD way, esp. OpenBSD way.Besides being "liberal", they also significantly favor "simplicity". Simple, short, clear, and also widely used. I'm talking about the license, not the code.That is, if you come up with a new license, and claim it is liberal, but it takes too muchtime/effort/money/lawyer to read and interpret, then they reject it.They reject for example Apache 2.x. Thus they stick with Apache 1.x.I kind of wish they wouldn't stick with Apache 1.x, it seems "dangerous" to lingerback on "old" versions, but I understand the reason.I don't know if they stuck with gcc 3.x to avoid bloat or to avoid GPL 3. I don't think we have a choice in the licensing of what we add, parse.c in particular.I suspect parts of it are copied from the GPL gcc C front end.That is ok. - Jay > Date: Sun, 4 Jul 2010 16:04:18 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] licensing (gcc patches) > > On Sun, Jul 04, 2010 at 04:20:01PM +0000, Jay K wrote: > > > > licensing > > > > > > "for the record" > > I don't necessarily want to discuss it.. > > > > > > It has been speculated here that > > our gcc patches weren't acceptable > > because our license is more restrictive than GPL. > > > > > > I believe it is more like the opposite. > > Our patches not accepted because our license is /less/ restrictive. > > The restriction I see in the modula 3 license is everyone dealing in > Modula 3 code has to allow SRC to do anything they want to any of it. > This 'requirement to allow' is a restriction that doesn't apply to GPL, > so in that sense we're more restrictive. > > In pretty well all other ways, we're less restrictive. > > > To most of the code. Not to the patch or files added to gcc. > > They can't really be. > > Of course any code we *add* at this point can be dual-licensed, letting > people who get it use one license, or the other, or both, at their > option. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jul 5 11:24:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 09:24:20 +0000 Subject: [M3devel] loophole/copysign Message-ID: Our codegen is remarkably low level. That is, lower level earlier than C. gcc/m3cg -ftree-dump-all As early as LongFloat.mc.003t.original, the first file dumped, we have: LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) { ? xreel M3_CtKayy__result; ? xreel M3_CtKayy_res; ??? xreel M3_CtKayy__result; ??? xreel M3_CtKayy_res; ? M3_CtKayy_res = M3_CtKayy_x; ? BIT_FIELD_REF = (word_8) ((int_64) ? BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); ? = M3_CtKayy_res; ? return ; } compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: copy_sign_f (from, to) { ? float res; ? float D.1918; ? D.1917; ? struct float_t * from.1; ? struct float_t * res.0; : ? res = to_1; ? res.0_4 = (struct float_t *) &res; ? from.1_5 = (struct float_t *) &from; ? D.1917_6 = from.1_5->sign; ? res.0_4->sign = D.1917_6; ? D.1918_7 = res; ? return D.1918_7; } See, you know, from gcc's point of view, we don't have any records/structs/unions. Just integers and offsets from them mostly. The right fix is to build up types. That way also debugging with gdb will have a chance. Perhaps not a small amount of work. But maybe not too bad. For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. At least if one type but not the other is floating point. I don't know if that will work, but maybe. Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or store volatile. ?- Jay From jay.krell at cornell.edu Mon Jul 5 12:42:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 10:42:57 +0000 Subject: [M3devel] loophole/copysign In-Reply-To: References: Message-ID: Tony, et. al.. in m3front/src/exprs/CastExpr.m3..what's the difference between a "designator" and a "value"? http://www-plan.cs.colorado.edu/diwan/modula3/designators.html An identifier is a writable designator if it is declared as a variable, is a VAR or VALUE parameter, is a local of a TYPECASE or TRY EXCEPT statement, or is a WITH local that is bound to a writable designator. An identifier is a readonly designator if it is a READONLY parameter, a local of a FOR statement, or a WITH local bound to a non-designator or readonly designator. I guess a designator is what I would think of a "variable" or "read only variable"? Something that either is "in memory" or can "reasonably" be put there? 1 + 2 is not a designator. Or, generally, a "variable", but that includes such similar things as parameters, "with variables", "for variables", "TYPECASE vairables", "TRY variables" Anything with a name??? (not functions/modules/generics -- "named data") Anyway, the next questions include: In CastExpr.m3 would it be terrible and/or wrong to treat "designators" the same as "values"? ?I realize, probably a deoptimization. ?I think this lets the backend work. ? And really, more to the point...shouldn't CastExpr.m3 use cg.loophole far more? I haven't had much luck with that. I always get the cg stack out of balance or with the wrong types, even though it seems like it should be easy. I have more testing to do, but classifying the loophole as V_to_S (value to structure) in place of D_to_S (designator to structure), at least if either side is one of the three float types, seems reasonable and correct, albeit slight deoptimization -- in unsafe code dealing with floating point..should be rare.. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 5 Jul 2010 09:24:20 +0000 > Subject: [M3devel] loophole/copysign > > > Our codegen is remarkably low level. That is, lower level earlier than C. > > > gcc/m3cg -ftree-dump-all > > > As early as LongFloat.mc.003t.original, the first file dumped, we have: > > LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) > { > xreel M3_CtKayy__result; > xreel M3_CtKayy_res; > > xreel M3_CtKayy__result; > xreel M3_CtKayy_res; > M3_CtKayy_res = M3_CtKayy_x; > BIT_FIELD_REF = (word_8) ((int_64) > BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); > = M3_CtKayy_res; > return ; > } > > compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: > > copy_sign_f (from, to) > { > float res; > float D.1918; > D.1917; > struct float_t * from.1; > struct float_t * res.0; > > : > res = to_1; > res.0_4 = (struct float_t *) &res; > from.1_5 = (struct float_t *) &from; > D.1917_6 = from.1_5->sign; > res.0_4->sign = D.1917_6; > D.1918_7 = res; > return D.1918_7; > > } > > > See, you know, from gcc's point of view, we don't have any records/structs/unions. > Just integers and offsets from them mostly. > > > The right fix is to build up types. > That way also debugging with gdb will have a chance. > Perhaps not a small amount of work. But maybe not too bad. > > > For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. > At least if one type but not the other is floating point. > I don't know if that will work, but maybe. > > Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or > store volatile. > > - Jay > From jay.krell at cornell.edu Mon Jul 5 13:25:19 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 11:25:19 +0000 Subject: [M3devel] loophole/copysign In-Reply-To: References: , Message-ID: Hm. it seems that it might be important to preserve the "designatorness", like in: libm3/...RandomReal.m3: ? VAR frac, exp: INTEGER; result: LONGREAL; ??? (* Repack as LONGREAL: *) ??? WITH lr = LOOPHOLE (result, LongRealRep.T) DO ????? lr.sign := 0; ????? lr.exponent := exp; ????? lr.significand0 := Word.Shift (Word.And (frac, 16_7fffffff), ????????????????????????????????????? -(WordSize - 1 - FractionBits)); ????? lr.significand1 := r.integer (min := -16_7fffffff-1, max :=16_7fffffff); ??? END; ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 5 Jul 2010 10:42:57 +0000 > Subject: Re: [M3devel] loophole/copysign > > > Tony, et. al.. in m3front/src/exprs/CastExpr.m3..what's the difference between a "designator" and a "value"? > > > http://www-plan.cs.colorado.edu/diwan/modula3/designators.html > > An identifier is a writable designator > if it is declared as a variable, > is a VAR or VALUE parameter, > is a local of a TYPECASE > or TRY EXCEPT statement, > or is a WITH local that is bound to a writable designator. > An identifier is a readonly designator if it is > a READONLY parameter, > a local of a FOR statement, > or a WITH local bound to a non-designator or > readonly designator. > > > > I guess a designator is what I would think of a "variable" or "read only variable"? > Something that either is "in memory" or can "reasonably" be put there? > > > 1 + 2 is not a designator. > > > Or, generally, a "variable", but that includes such similar things as parameters, "with variables", "for variables", "TYPECASE vairables", "TRY variables" > > > Anything with a name??? (not functions/modules/generics -- "named data") > > > Anyway, the next questions include: > > > In CastExpr.m3 would it be terrible and/or wrong to treat "designators" the same as "values"? > I realize, probably a deoptimization. > I think this lets the backend work. > > > And really, more to the point...shouldn't CastExpr.m3 use cg.loophole far more? > I haven't had much luck with that. I always get the cg stack out of balance or with the wrong types, even though it seems like it should be easy. > > > I have more testing to do, but classifying the loophole as V_to_S (value to structure) in place of D_to_S (designator to structure), at least if either side is one of the three float types, seems reasonable and correct, albeit slight deoptimization -- in unsafe code dealing with floating point..should be rare.. > > > - Jay > > > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Date: Mon, 5 Jul 2010 09:24:20 +0000 > > Subject: [M3devel] loophole/copysign > > > > > > Our codegen is remarkably low level. That is, lower level earlier than C. > > > > > > gcc/m3cg -ftree-dump-all > > > > > > As early as LongFloat.mc.003t.original, the first file dumped, we have: > > > > LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) > > { > > xreel M3_CtKayy__result; > > xreel M3_CtKayy_res; > > > > xreel M3_CtKayy__result; > > xreel M3_CtKayy_res; > > M3_CtKayy_res = M3_CtKayy_x; > > BIT_FIELD_REF = (word_8) ((int_64) > > BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); > > = M3_CtKayy_res; > > return ; > > } > > > > compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: > > > > copy_sign_f (from, to) > > { > > float res; > > float D.1918; > > D.1917; > > struct float_t * from.1; > > struct float_t * res.0; > > > > : > > res = to_1; > > res.0_4 = (struct float_t *) &res; > > from.1_5 = (struct float_t *) &from; > > D.1917_6 = from.1_5->sign; > > res.0_4->sign = D.1917_6; > > D.1918_7 = res; > > return D.1918_7; > > > > } > > > > > > See, you know, from gcc's point of view, we don't have any records/structs/unions. > > Just integers and offsets from them mostly. > > > > > > The right fix is to build up types. > > That way also debugging with gdb will have a chance. > > Perhaps not a small amount of work. But maybe not too bad. > > > > > > For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. > > At least if one type but not the other is floating point. > > I don't know if that will work, but maybe. > > > > Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or > > store volatile. > > > > - Jay > > > From jay.krell at cornell.edu Mon Jul 5 13:36:11 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 11:36:11 +0000 Subject: [M3devel] loophole/copysign In-Reply-To: References: , , , Message-ID: another idea: let's not use bitfield ref for float/double ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 5 Jul 2010 11:25:19 +0000 > Subject: Re: [M3devel] loophole/copysign > > > Hm. it seems that it might be important to preserve the "designatorness", like in: > > libm3/...RandomReal.m3: > > VAR frac, exp: INTEGER; result: LONGREAL; > > (* Repack as LONGREAL: *) > WITH lr = LOOPHOLE (result, LongRealRep.T) DO > lr.sign := 0; > lr.exponent := exp; > lr.significand0 := Word.Shift (Word.And (frac, 16_7fffffff), > -(WordSize - 1 - FractionBits)); > lr.significand1 := r.integer (min := -16_7fffffff-1, max :=16_7fffffff); > END; > > > - Jay > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Date: Mon, 5 Jul 2010 10:42:57 +0000 > > Subject: Re: [M3devel] loophole/copysign > > > > > > Tony, et. al.. in m3front/src/exprs/CastExpr.m3..what's the difference between a "designator" and a "value"? > > > > > > http://www-plan.cs.colorado.edu/diwan/modula3/designators.html > > > > An identifier is a writable designator > > if it is declared as a variable, > > is a VAR or VALUE parameter, > > is a local of a TYPECASE > > or TRY EXCEPT statement, > > or is a WITH local that is bound to a writable designator. > > An identifier is a readonly designator if it is > > a READONLY parameter, > > a local of a FOR statement, > > or a WITH local bound to a non-designator or > > readonly designator. > > > > > > > > I guess a designator is what I would think of a "variable" or "read only variable"? > > Something that either is "in memory" or can "reasonably" be put there? > > > > > > 1 + 2 is not a designator. > > > > > > Or, generally, a "variable", but that includes such similar things as parameters, "with variables", "for variables", "TYPECASE vairables", "TRY variables" > > > > > > Anything with a name??? (not functions/modules/generics -- "named data") > > > > > > Anyway, the next questions include: > > > > > > In CastExpr.m3 would it be terrible and/or wrong to treat "designators" the same as "values"? > > I realize, probably a deoptimization. > > I think this lets the backend work. > > > > > > And really, more to the point...shouldn't CastExpr.m3 use cg.loophole far more? > > I haven't had much luck with that. I always get the cg stack out of balance or with the wrong types, even though it seems like it should be easy. > > > > > > I have more testing to do, but classifying the loophole as V_to_S (value to structure) in place of D_to_S (designator to structure), at least if either side is one of the three float types, seems reasonable and correct, albeit slight deoptimization -- in unsafe code dealing with floating point..should be rare.. > > > > > > - Jay > > > > > > > > ---------------------------------------- > > > From: jay.krell at cornell.edu > > > To: m3devel at elegosoft.com > > > Date: Mon, 5 Jul 2010 09:24:20 +0000 > > > Subject: [M3devel] loophole/copysign > > > > > > > > > Our codegen is remarkably low level. That is, lower level earlier than C. > > > > > > > > > gcc/m3cg -ftree-dump-all > > > > > > > > > As early as LongFloat.mc.003t.original, the first file dumped, we have: > > > > > > LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) > > > { > > > xreel M3_CtKayy__result; > > > xreel M3_CtKayy_res; > > > > > > xreel M3_CtKayy__result; > > > xreel M3_CtKayy_res; > > > M3_CtKayy_res = M3_CtKayy_x; > > > BIT_FIELD_REF = (word_8) ((int_64) > > > BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); > > > = M3_CtKayy_res; > > > return ; > > > } > > > > > > compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: > > > > > > copy_sign_f (from, to) > > > { > > > float res; > > > float D.1918; > > > D.1917; > > > struct float_t * from.1; > > > struct float_t * res.0; > > > > > > : > > > res = to_1; > > > res.0_4 = (struct float_t *) &res; > > > from.1_5 = (struct float_t *) &from; > > > D.1917_6 = from.1_5->sign; > > > res.0_4->sign = D.1917_6; > > > D.1918_7 = res; > > > return D.1918_7; > > > > > > } > > > > > > > > > See, you know, from gcc's point of view, we don't have any records/structs/unions. > > > Just integers and offsets from them mostly. > > > > > > > > > The right fix is to build up types. > > > That way also debugging with gdb will have a chance. > > > Perhaps not a small amount of work. But maybe not too bad. > > > > > > > > > For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. > > > At least if one type but not the other is floating point. > > > I don't know if that will work, but maybe. > > > > > > Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or > > > store volatile. > > > > > > - Jay > > > > > > From hendrik at topoi.pooq.com Mon Jul 5 14:24:15 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 5 Jul 2010 08:24:15 -0400 Subject: [M3devel] licensing (gcc patches) In-Reply-To: <20100705093230.k462uhajq8cc8kkw@mail.elegosoft.com> References: <20100704200418.GC22573@topoi.pooq.com> <20100705093230.k462uhajq8cc8kkw@mail.elegosoft.com> Message-ID: <20100705122414.GB27490@topoi.pooq.com> On Mon, Jul 05, 2010 at 09:32:30AM +0200, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > >> On Sun, Jul 04, 2010 at 04:20:01PM +0000, Jay K wrote: >>> >>> licensing >>> >>> "for the record" >>> I don't necessarily want to discuss it.. >>> >>> >>> It has been speculated here that >>> our gcc patches weren't acceptable >>> because our license is more restrictive than GPL. >>> >>> I believe it is more like the opposite. >>> Our patches not accepted because our license is /less/ restrictive. >> >> The restriction I see in the modula 3 license is everyone dealing in >> Modula 3 code has to allow SRC to do anything they want to any of it. >> This 'requirement to allow' is a restriction that doesn't apply to GPL, >> so in that sense we're more restrictive. >> >> In pretty well all other ways, we're less restrictive. > > The M3 licence allows free use and distribution of the code in source > and binary format. There is no restriction that source must be provided > if it is changed or sold or just used as a service by anyone, i.e. it is > no viral license. > > The only provision is that _if_ patches are returned to the copyright owner > (which can be DEC, Critical Mass, or others), they may use them for any > purpose they wish without any restriction, too. > > Actually, both DEC and Critical Mass won't (any more). At least as far > as I can see... > >>> ?To most of the code. Not to the patch or files added to gcc. >>> ?They can't really be. >> >> Of course any code we *add* at this point can be dual-licensed, letting >> people who get it use one license, or the other, or both, at their >> option. > > Code linked with gcc must be under GPL. That's why DEC went to all > this fuss with two-phase compilation using two processes. Otherwise all > the M3 compiler code would need to be distributed as source by anyone > who uses it, too. But code can be released under more than one licence, the SRC license *and* the GPL, for example. Of course, that would require the copyright holders to do that. > GPL is still pretty much a no-go for commercial use. > > In fact that's the reason why the FSF never accepted the M3 extensions > for gcc; they didn't approve of the license `workaround'. So the issue here is not wiether the M3 extensions to gcc are GPL'd, butwhether the FSF is willing to accept them into their gcc distribution? -- hendrik. From hendrik at topoi.pooq.com Mon Jul 5 14:39:55 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 5 Jul 2010 08:39:55 -0400 Subject: [M3devel] licensing (gcc patches) In-Reply-To: References: <20100704200418.GC22573@topoi.pooq.com> Message-ID: <20100705123955.GC27490@topoi.pooq.com> On Mon, Jul 05, 2010 at 07:39:44AM +0000, Jay K wrote: > > > Of course any code we *add* at this point can be dual-licensed, letting > I find "dual license" confusing. Each licence gives potential clients certain rights. If they follow the restrictions in either licence, they have the privileges granted by that licence. If they follow the restrictions of both, they have the privileges granted by both. If all of out new code were to be dual-licensed, we'd be compatible with the SRC licence (pretty easy to be), and our new code could be taken by anyone and used and redistributed under the GPL on its own. Whether it would be useful on its own is another question. GPL becomes restrictive is when you don't have the permission of all the copyright holders to change licenses. As in our case, where we, as far as I can tell, can't get it from SRC, perhaps only because they just don't care at all about the matter any more. > > I like the BSD way, esp. OpenBSD way.Besides being "liberal", they > also significantly favor "simplicity". Simple, short, clear, and also > widely used. I'm talking about the license, not the code.That is, if > you come up with a new license, and claim it is liberal, but it takes > too muchtime/effort/money/lawyer to read and interpret, then they > reject it.They reject for example Apache 2.x. Thus they stick with > Apache 1.x.I kind of wish they wouldn't stick with Apache 1.x, it > seems "dangerous" to lingerback on "old" versions, but I understand > the reason.I don't know if they stuck with gcc 3.x to avoid bloat or > to avoid GPL 3. > > I don't think we have a choice in the licensing of what we add, > parse.c in particular. I suspect parts of it are copied from the GPL > gcc C front end. That is ok. And that restricts us from distributing parse.c other than under the GPL. We can't dual-licence that bit. Is parse.c part of our modified gcc back end? If so, yes, that is OK. -- hendrik From jay.krell at cornell.edu Mon Jul 5 14:49:18 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 12:49:18 +0000 Subject: [M3devel] licensing (gcc patches) In-Reply-To: <20100705123955.GC27490@topoi.pooq.com> References: <20100704200418.GC22573@topoi.pooq.com>, , <20100705123955.GC27490@topoi.pooq.com> Message-ID: Yes parse.c is a new file added to gcc and contains the bulk of our work on gcc. There are some other small files and small diffs, but parse.c is really it. parse.c: the name seems wrong, but if you consider that from gcc's point of view, we are a front end, then it makes sense. As a front end to gcc, our "source language" is very odd, it is binary files encoding the sequence of function calls the "actual" frontend would have me to an "actual" backend. ?- Jay ---------------------------------------- > Date: Mon, 5 Jul 2010 08:39:55 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] licensing (gcc patches) > > On Mon, Jul 05, 2010 at 07:39:44AM +0000, Jay K wrote: > > > > > Of course any code we *add* at this point can be dual-licensed, letting > > I find "dual license" confusing. > > Each licence gives potential clients certain rights. If they follow > the restrictions in either licence, they have the privileges granted by > that licence. If they follow the restrictions of both, they have the > privileges granted by both. > > If all of out new code were to be dual-licensed, we'd be compatible with > the SRC licence (pretty easy to be), and our new code could be taken by > anyone and used and redistributed under the GPL on its own. Whether it > would be useful on its own is another question. > > GPL becomes restrictive is when you don't have the permission of all the > copyright holders to change licenses. As in our case, where we, as far > as I can tell, can't get it from SRC, perhaps only because they just > don't care at all about the matter any more. > > > > > I like the BSD way, esp. OpenBSD way.Besides being "liberal", they > > also significantly favor "simplicity". Simple, short, clear, and also > > widely used. I'm talking about the license, not the code.That is, if > > you come up with a new license, and claim it is liberal, but it takes > > too muchtime/effort/money/lawyer to read and interpret, then they > > reject it.They reject for example Apache 2.x. Thus they stick with > > Apache 1.x.I kind of wish they wouldn't stick with Apache 1.x, it > > seems "dangerous" to lingerback on "old" versions, but I understand > > the reason.I don't know if they stuck with gcc 3.x to avoid bloat or > > to avoid GPL 3. > > > > I don't think we have a choice in the licensing of what we add, > > parse.c in particular. I suspect parts of it are copied from the GPL > > gcc C front end. That is ok. > > And that restricts us from distributing parse.c other than under the > GPL. We can't dual-licence that bit. Is parse.c part of our modified > gcc back end? If so, yes, that is OK. > > -- hendrik From jay.krell at cornell.edu Mon Jul 5 14:56:23 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 12:56:23 +0000 Subject: [M3devel] loophole/copysign In-Reply-To: References: , , , , Message-ID: nope. I know this is gross, but how about we addd CG.make_volatile that front end can call very sparingly, that acts just like generating a call to setjmp or vfork -- in that it makes locals, parameters, temporaries in current function as volatile? CastExpr.m3 would call it for D_to_S and FloatType[src] # FloatType[dest]. It would be available as a desparate measure if we find other problems. To selectively inhibit optimization a function at a time. ? Which, granted, is generally overkill. I'm trying this now.. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: RE: [M3devel] loophole/copysign > Date: Mon, 5 Jul 2010 11:36:11 +0000 > > > another idea: let's not use bitfield ref for float/double > > - Jay > > > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Date: Mon, 5 Jul 2010 11:25:19 +0000 > > Subject: Re: [M3devel] loophole/copysign > > > > > > Hm. it seems that it might be important to preserve the "designatorness", like in: > > > > libm3/...RandomReal.m3: > > > > VAR frac, exp: INTEGER; result: LONGREAL; > > > > (* Repack as LONGREAL: *) > > WITH lr = LOOPHOLE (result, LongRealRep.T) DO > > lr.sign := 0; > > lr.exponent := exp; > > lr.significand0 := Word.Shift (Word.And (frac, 16_7fffffff), > > -(WordSize - 1 - FractionBits)); > > lr.significand1 := r.integer (min := -16_7fffffff-1, max :=16_7fffffff); > > END; > > > > > > - Jay > > > > ---------------------------------------- > > > From: jay.krell at cornell.edu > > > To: m3devel at elegosoft.com > > > Date: Mon, 5 Jul 2010 10:42:57 +0000 > > > Subject: Re: [M3devel] loophole/copysign > > > > > > > > > Tony, et. al.. in m3front/src/exprs/CastExpr.m3..what's the difference between a "designator" and a "value"? > > > > > > > > > http://www-plan.cs.colorado.edu/diwan/modula3/designators.html > > > > > > An identifier is a writable designator > > > if it is declared as a variable, > > > is a VAR or VALUE parameter, > > > is a local of a TYPECASE > > > or TRY EXCEPT statement, > > > or is a WITH local that is bound to a writable designator. > > > An identifier is a readonly designator if it is > > > a READONLY parameter, > > > a local of a FOR statement, > > > or a WITH local bound to a non-designator or > > > readonly designator. > > > > > > > > > > > > I guess a designator is what I would think of a "variable" or "read only variable"? > > > Something that either is "in memory" or can "reasonably" be put there? > > > > > > > > > 1 + 2 is not a designator. > > > > > > > > > Or, generally, a "variable", but that includes such similar things as parameters, "with variables", "for variables", "TYPECASE vairables", "TRY variables" > > > > > > > > > Anything with a name??? (not functions/modules/generics -- "named data") > > > > > > > > > Anyway, the next questions include: > > > > > > > > > In CastExpr.m3 would it be terrible and/or wrong to treat "designators" the same as "values"? > > > I realize, probably a deoptimization. > > > I think this lets the backend work. > > > > > > > > > And really, more to the point...shouldn't CastExpr.m3 use cg.loophole far more? > > > I haven't had much luck with that. I always get the cg stack out of balance or with the wrong types, even though it seems like it should be easy. > > > > > > > > > I have more testing to do, but classifying the loophole as V_to_S (value to structure) in place of D_to_S (designator to structure), at least if either side is one of the three float types, seems reasonable and correct, albeit slight deoptimization -- in unsafe code dealing with floating point..should be rare.. > > > > > > > > > - Jay > > > > > > > > > > > > ---------------------------------------- > > > > From: jay.krell at cornell.edu > > > > To: m3devel at elegosoft.com > > > > Date: Mon, 5 Jul 2010 09:24:20 +0000 > > > > Subject: [M3devel] loophole/copysign > > > > > > > > > > > > Our codegen is remarkably low level. That is, lower level earlier than C. > > > > > > > > > > > > gcc/m3cg -ftree-dump-all > > > > > > > > > > > > As early as LongFloat.mc.003t.original, the first file dumped, we have: > > > > > > > > LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) > > > > { > > > > xreel M3_CtKayy__result; > > > > xreel M3_CtKayy_res; > > > > > > > > xreel M3_CtKayy__result; > > > > xreel M3_CtKayy_res; > > > > M3_CtKayy_res = M3_CtKayy_x; > > > > BIT_FIELD_REF = (word_8) ((int_64) > > > > BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); > > > > = M3_CtKayy_res; > > > > return ; > > > > } > > > > > > > > compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: > > > > > > > > copy_sign_f (from, to) > > > > { > > > > float res; > > > > float D.1918; > > > > D.1917; > > > > struct float_t * from.1; > > > > struct float_t * res.0; > > > > > > > > : > > > > res = to_1; > > > > res.0_4 = (struct float_t *) &res; > > > > from.1_5 = (struct float_t *) &from; > > > > D.1917_6 = from.1_5->sign; > > > > res.0_4->sign = D.1917_6; > > > > D.1918_7 = res; > > > > return D.1918_7; > > > > > > > > } > > > > > > > > > > > > See, you know, from gcc's point of view, we don't have any records/structs/unions. > > > > Just integers and offsets from them mostly. > > > > > > > > > > > > The right fix is to build up types. > > > > That way also debugging with gdb will have a chance. > > > > Perhaps not a small amount of work. But maybe not too bad. > > > > > > > > > > > > For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. > > > > At least if one type but not the other is floating point. > > > > I don't know if that will work, but maybe. > > > > > > > > Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or > > > > store volatile. > > > > > > > > - Jay > > > > > > > > > > From hendrik at topoi.pooq.com Mon Jul 5 17:25:07 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 5 Jul 2010 11:25:07 -0400 Subject: [M3devel] licensing (gcc patches) In-Reply-To: References: <20100705123955.GC27490@topoi.pooq.com> Message-ID: <20100705152506.GE27490@topoi.pooq.com> On Mon, Jul 05, 2010 at 12:49:18PM +0000, Jay K wrote: > > Yes parse.c is a new file added to gcc and contains the bulk of our work on gcc. > There are some other small files and small diffs, but parse.c is really it. > > parse.c: the name seems wrong, but if you consider that from gcc's point of view, > we are a front end, then it makes sense. As a front end to gcc, our "source language" > is very odd, it is binary files encoding the sequence of function calls the "actual" > frontend would have me to an "actual" backend. I like that technique. It's similar to the intermediate code the coq proof checker produces after it's proved a theorem -- a file coding the sequence of calls to the elementary proof rules that turned out to be actually needed to get to the conclusion. It stores these files in a library, so it can read them in later and reprove the theorem quickly in case you need it again. It beats cryptographic signatures for security. I wonder if the FSF gang would look at parse.c differently if there were other compilers, GPLed ones, that use your back end. -- hendrik From dabenavidesd at yahoo.es Mon Jul 5 19:17:26 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 5 Jul 2010 17:17:26 +0000 (GMT) Subject: [M3devel] licensing (gcc patches) In-Reply-To: <20100705152506.GE27490@topoi.pooq.com> Message-ID: <495012.96539.qm@web23608.mail.ird.yahoo.com> Hi all: I think as is pointed out original developers copyright holders must be at the public domain as they are not present anymore and nobody seems to reclaim if there is any wanting to hold them as they don't have nobody who uses it as far as we know. So it probably needs to be a process of release of this holders to the public domain and especially the owners of the linked code would not regret having the hold as far as they return what they did to the originals which I believe don't or wouldn't hesitate to receive. If they do hesitate to receive they would be admitting they are not anymore owners of it and the changes would and shall be returned to somebody who will receive for them as to allow any wanting to do changes. I don't think FSF would accept to do that procedure. What shall we do then? --- El lun, 5/7/10, hendrik at topoi.pooq.com escribi?: > De: hendrik at topoi.pooq.com > Asunto: Re: [M3devel] licensing (gcc patches) > Para: m3devel at elegosoft.com > Fecha: lunes, 5 de julio, 2010 10:25 > On Mon, Jul 05, 2010 at 12:49:18PM > +0000, Jay K wrote: > > > > Yes parse.c is a new file added to gcc and contains > the bulk of our work on gcc. > > There are some other small files and small diffs, but > parse.c is really it. > > > > parse.c: the name seems wrong, but if you consider > that from gcc's point of view, > > we are a front end, then it makes sense. As a front > end to gcc, our "source language" > > is very odd, it is binary files encoding the sequence > of function calls the "actual" > > frontend would have me to an "actual" backend. > > I like that technique. It's similar to the > intermediate code the coq > proof checker produces after it's proved a theorem -- a > file > coding the sequence of calls to the elementary proof rules > that turned > out to be actually needed to get to the conclusion. > It stores these > files in a library, so it can read them in later and > reprove the theorem > quickly in case you need it again. It beats > cryptographic signatures > for security. > > I wonder if the FSF gang would look at parse.c differently > if there were > other compilers, GPLed ones, that use your back end. > > -- hendrik > From hosking at cs.purdue.edu Mon Jul 5 20:24:01 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 14:24:01 -0400 Subject: [M3devel] loophole/copysign In-Reply-To: References: Message-ID: <3267416E-1152-4A3D-A4C0-491F2C5FF74D@cs.purdue.edu> We shouldn't need a barrier here. That is for memory operations, whereas these need not be. I would hate to make this change. Why can't we produce gcc trees that accomplish what we need? On 5 Jul 2010, at 05:24, Jay K wrote: > > Our codegen is remarkably low level. That is, lower level earlier than C. > > > gcc/m3cg -ftree-dump-all > > > As early as LongFloat.mc.003t.original, the first file dumped, we have: > > LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) > { > xreel M3_CtKayy__result; > xreel M3_CtKayy_res; > > xreel M3_CtKayy__result; > xreel M3_CtKayy_res; > M3_CtKayy_res = M3_CtKayy_x; > BIT_FIELD_REF = (word_8) ((int_64) > BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); > = M3_CtKayy_res; > return ; > } > > compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: > > copy_sign_f (from, to) > { > float res; > float D.1918; > D.1917; > struct float_t * from.1; > struct float_t * res.0; > > : > res = to_1; > res.0_4 = (struct float_t *) &res; > from.1_5 = (struct float_t *) &from; > D.1917_6 = from.1_5->sign; > res.0_4->sign = D.1917_6; > D.1918_7 = res; > return D.1918_7; > > } > > > See, you know, from gcc's point of view, we don't have any records/structs/unions. > Just integers and offsets from them mostly. > > > The right fix is to build up types. > That way also debugging with gdb will have a chance. > Perhaps not a small amount of work. But maybe not too bad. > > > For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. > At least if one type but not the other is floating point. > I don't know if that will work, but maybe. > > Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or > store volatile. > > - Jay > From hosking at cs.purdue.edu Mon Jul 5 20:24:56 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 14:24:56 -0400 Subject: [M3devel] loophole/copysign In-Reply-To: References: Message-ID: <2F356C4B-5541-489B-B957-E3D295F549F5@cs.purdue.edu> A designator is something that can be assigned to as well as read from. It says nothing about it being in memory. A value cannot be assigned to. On 5 Jul 2010, at 06:42, Jay K wrote: > > Tony, et. al.. in m3front/src/exprs/CastExpr.m3..what's the difference between a "designator" and a "value"? > > > http://www-plan.cs.colorado.edu/diwan/modula3/designators.html > > An identifier is a writable designator > if it is declared as a variable, > is a VAR or VALUE parameter, > is a local of a TYPECASE > or TRY EXCEPT statement, > or is a WITH local that is bound to a writable designator. > An identifier is a readonly designator if it is > a READONLY parameter, > a local of a FOR statement, > or a WITH local bound to a non-designator or > readonly designator. > > > > I guess a designator is what I would think of a "variable" or "read only variable"? > Something that either is "in memory" or can "reasonably" be put there? > > > 1 + 2 is not a designator. > > > Or, generally, a "variable", but that includes such similar things as parameters, "with variables", "for variables", "TYPECASE vairables", "TRY variables" > > > Anything with a name??? (not functions/modules/generics -- "named data") > > > Anyway, the next questions include: > > > In CastExpr.m3 would it be terrible and/or wrong to treat "designators" the same as "values"? > I realize, probably a deoptimization. > I think this lets the backend work. > > > And really, more to the point...shouldn't CastExpr.m3 use cg.loophole far more? > I haven't had much luck with that. I always get the cg stack out of balance or with the wrong types, even though it seems like it should be easy. > > > I have more testing to do, but classifying the loophole as V_to_S (value to structure) in place of D_to_S (designator to structure), at least if either side is one of the three float types, seems reasonable and correct, albeit slight deoptimization -- in unsafe code dealing with floating point..should be rare.. > > > - Jay > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Date: Mon, 5 Jul 2010 09:24:20 +0000 >> Subject: [M3devel] loophole/copysign >> >> >> Our codegen is remarkably low level. That is, lower level earlier than C. >> >> >> gcc/m3cg -ftree-dump-all >> >> >> As early as LongFloat.mc.003t.original, the first file dumped, we have: >> >> LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) >> { >> xreel M3_CtKayy__result; >> xreel M3_CtKayy_res; >> >> xreel M3_CtKayy__result; >> xreel M3_CtKayy_res; >> M3_CtKayy_res = M3_CtKayy_x; >> BIT_FIELD_REF = (word_8) ((int_64) >> BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); >> = M3_CtKayy_res; >> return ; >> } >> >> compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: >> >> copy_sign_f (from, to) >> { >> float res; >> float D.1918; >> D.1917; >> struct float_t * from.1; >> struct float_t * res.0; >> >> : >> res = to_1; >> res.0_4 = (struct float_t *) &res; >> from.1_5 = (struct float_t *) &from; >> D.1917_6 = from.1_5->sign; >> res.0_4->sign = D.1917_6; >> D.1918_7 = res; >> return D.1918_7; >> >> } >> >> >> See, you know, from gcc's point of view, we don't have any records/structs/unions. >> Just integers and offsets from them mostly. >> >> >> The right fix is to build up types. >> That way also debugging with gdb will have a chance. >> Perhaps not a small amount of work. But maybe not too bad. >> >> >> For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. >> At least if one type but not the other is floating point. >> I don't know if that will work, but maybe. >> >> Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or >> store volatile. >> >> - Jay >> > From hosking at cs.purdue.edu Mon Jul 5 20:25:17 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 14:25:17 -0400 Subject: [M3devel] loophole/copysign In-Reply-To: References: , , , Message-ID: <01D93A8D-8D43-4D9A-A753-6B2D41C03F52@cs.purdue.edu> Yes, maybe that is the best way forward. On 5 Jul 2010, at 07:36, Jay K wrote: > > another idea: let's not use bitfield ref for float/double > > - Jay > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Date: Mon, 5 Jul 2010 11:25:19 +0000 >> Subject: Re: [M3devel] loophole/copysign >> >> >> Hm. it seems that it might be important to preserve the "designatorness", like in: >> >> libm3/...RandomReal.m3: >> >> VAR frac, exp: INTEGER; result: LONGREAL; >> >> (* Repack as LONGREAL: *) >> WITH lr = LOOPHOLE (result, LongRealRep.T) DO >> lr.sign := 0; >> lr.exponent := exp; >> lr.significand0 := Word.Shift (Word.And (frac, 16_7fffffff), >> -(WordSize - 1 - FractionBits)); >> lr.significand1 := r.integer (min := -16_7fffffff-1, max :=16_7fffffff); >> END; >> >> >> - Jay >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: m3devel at elegosoft.com >>> Date: Mon, 5 Jul 2010 10:42:57 +0000 >>> Subject: Re: [M3devel] loophole/copysign >>> >>> >>> Tony, et. al.. in m3front/src/exprs/CastExpr.m3..what's the difference between a "designator" and a "value"? >>> >>> >>> http://www-plan.cs.colorado.edu/diwan/modula3/designators.html >>> >>> An identifier is a writable designator >>> if it is declared as a variable, >>> is a VAR or VALUE parameter, >>> is a local of a TYPECASE >>> or TRY EXCEPT statement, >>> or is a WITH local that is bound to a writable designator. >>> An identifier is a readonly designator if it is >>> a READONLY parameter, >>> a local of a FOR statement, >>> or a WITH local bound to a non-designator or >>> readonly designator. >>> >>> >>> >>> I guess a designator is what I would think of a "variable" or "read only variable"? >>> Something that either is "in memory" or can "reasonably" be put there? >>> >>> >>> 1 + 2 is not a designator. >>> >>> >>> Or, generally, a "variable", but that includes such similar things as parameters, "with variables", "for variables", "TYPECASE vairables", "TRY variables" >>> >>> >>> Anything with a name??? (not functions/modules/generics -- "named data") >>> >>> >>> Anyway, the next questions include: >>> >>> >>> In CastExpr.m3 would it be terrible and/or wrong to treat "designators" the same as "values"? >>> I realize, probably a deoptimization. >>> I think this lets the backend work. >>> >>> >>> And really, more to the point...shouldn't CastExpr.m3 use cg.loophole far more? >>> I haven't had much luck with that. I always get the cg stack out of balance or with the wrong types, even though it seems like it should be easy. >>> >>> >>> I have more testing to do, but classifying the loophole as V_to_S (value to structure) in place of D_to_S (designator to structure), at least if either side is one of the three float types, seems reasonable and correct, albeit slight deoptimization -- in unsafe code dealing with floating point..should be rare.. >>> >>> >>> - Jay >>> >>> >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: m3devel at elegosoft.com >>>> Date: Mon, 5 Jul 2010 09:24:20 +0000 >>>> Subject: [M3devel] loophole/copysign >>>> >>>> >>>> Our codegen is remarkably low level. That is, lower level earlier than C. >>>> >>>> >>>> gcc/m3cg -ftree-dump-all >>>> >>>> >>>> As early as LongFloat.mc.003t.original, the first file dumped, we have: >>>> >>>> LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) >>>> { >>>> xreel M3_CtKayy__result; >>>> xreel M3_CtKayy_res; >>>> >>>> xreel M3_CtKayy__result; >>>> xreel M3_CtKayy_res; >>>> M3_CtKayy_res = M3_CtKayy_x; >>>> BIT_FIELD_REF = (word_8) ((int_64) >>>> BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); >>>> = M3_CtKayy_res; >>>> return ; >>>> } >>>> >>>> compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: >>>> >>>> copy_sign_f (from, to) >>>> { >>>> float res; >>>> float D.1918; >>>> D.1917; >>>> struct float_t * from.1; >>>> struct float_t * res.0; >>>> >>>> : >>>> res = to_1; >>>> res.0_4 = (struct float_t *) &res; >>>> from.1_5 = (struct float_t *) &from; >>>> D.1917_6 = from.1_5->sign; >>>> res.0_4->sign = D.1917_6; >>>> D.1918_7 = res; >>>> return D.1918_7; >>>> >>>> } >>>> >>>> >>>> See, you know, from gcc's point of view, we don't have any records/structs/unions. >>>> Just integers and offsets from them mostly. >>>> >>>> >>>> The right fix is to build up types. >>>> That way also debugging with gdb will have a chance. >>>> Perhaps not a small amount of work. But maybe not too bad. >>>> >>>> >>>> For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. >>>> At least if one type but not the other is floating point. >>>> I don't know if that will work, but maybe. >>>> >>>> Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or >>>> store volatile. >>>> >>>> - Jay >>>> >>> >> > From hosking at cs.purdue.edu Mon Jul 5 20:25:33 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 14:25:33 -0400 Subject: [M3devel] loophole/copysign In-Reply-To: References: , Message-ID: <195E2A33-B6BD-4554-9FAD-47E0445FBB46@cs.purdue.edu> Indeed. On 5 Jul 2010, at 07:25, Jay K wrote: > > Hm. it seems that it might be important to preserve the "designatorness", like in: > > libm3/...RandomReal.m3: > > VAR frac, exp: INTEGER; result: LONGREAL; > > (* Repack as LONGREAL: *) > WITH lr = LOOPHOLE (result, LongRealRep.T) DO > lr.sign := 0; > lr.exponent := exp; > lr.significand0 := Word.Shift (Word.And (frac, 16_7fffffff), > -(WordSize - 1 - FractionBits)); > lr.significand1 := r.integer (min := -16_7fffffff-1, max :=16_7fffffff); > END; > > > - Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Date: Mon, 5 Jul 2010 10:42:57 +0000 >> Subject: Re: [M3devel] loophole/copysign >> >> >> Tony, et. al.. in m3front/src/exprs/CastExpr.m3..what's the difference between a "designator" and a "value"? >> >> >> http://www-plan.cs.colorado.edu/diwan/modula3/designators.html >> >> An identifier is a writable designator >> if it is declared as a variable, >> is a VAR or VALUE parameter, >> is a local of a TYPECASE >> or TRY EXCEPT statement, >> or is a WITH local that is bound to a writable designator. >> An identifier is a readonly designator if it is >> a READONLY parameter, >> a local of a FOR statement, >> or a WITH local bound to a non-designator or >> readonly designator. >> >> >> >> I guess a designator is what I would think of a "variable" or "read only variable"? >> Something that either is "in memory" or can "reasonably" be put there? >> >> >> 1 + 2 is not a designator. >> >> >> Or, generally, a "variable", but that includes such similar things as parameters, "with variables", "for variables", "TYPECASE vairables", "TRY variables" >> >> >> Anything with a name??? (not functions/modules/generics -- "named data") >> >> >> Anyway, the next questions include: >> >> >> In CastExpr.m3 would it be terrible and/or wrong to treat "designators" the same as "values"? >> I realize, probably a deoptimization. >> I think this lets the backend work. >> >> >> And really, more to the point...shouldn't CastExpr.m3 use cg.loophole far more? >> I haven't had much luck with that. I always get the cg stack out of balance or with the wrong types, even though it seems like it should be easy. >> >> >> I have more testing to do, but classifying the loophole as V_to_S (value to structure) in place of D_to_S (designator to structure), at least if either side is one of the three float types, seems reasonable and correct, albeit slight deoptimization -- in unsafe code dealing with floating point..should be rare.. >> >> >> - Jay >> >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: m3devel at elegosoft.com >>> Date: Mon, 5 Jul 2010 09:24:20 +0000 >>> Subject: [M3devel] loophole/copysign >>> >>> >>> Our codegen is remarkably low level. That is, lower level earlier than C. >>> >>> >>> gcc/m3cg -ftree-dump-all >>> >>> >>> As early as LongFloat.mc.003t.original, the first file dumped, we have: >>> >>> LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) >>> { >>> xreel M3_CtKayy__result; >>> xreel M3_CtKayy_res; >>> >>> xreel M3_CtKayy__result; >>> xreel M3_CtKayy_res; >>> M3_CtKayy_res = M3_CtKayy_x; >>> BIT_FIELD_REF = (word_8) ((int_64) >>> BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); >>> = M3_CtKayy_res; >>> return ; >>> } >>> >>> compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: >>> >>> copy_sign_f (from, to) >>> { >>> float res; >>> float D.1918; >>> D.1917; >>> struct float_t * from.1; >>> struct float_t * res.0; >>> >>> : >>> res = to_1; >>> res.0_4 = (struct float_t *) &res; >>> from.1_5 = (struct float_t *) &from; >>> D.1917_6 = from.1_5->sign; >>> res.0_4->sign = D.1917_6; >>> D.1918_7 = res; >>> return D.1918_7; >>> >>> } >>> >>> >>> See, you know, from gcc's point of view, we don't have any records/structs/unions. >>> Just integers and offsets from them mostly. >>> >>> >>> The right fix is to build up types. >>> That way also debugging with gdb will have a chance. >>> Perhaps not a small amount of work. But maybe not too bad. >>> >>> >>> For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. >>> At least if one type but not the other is floating point. >>> I don't know if that will work, but maybe. >>> >>> Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or >>> store volatile. >>> >>> - Jay >>> >> > From hosking at cs.purdue.edu Mon Jul 5 20:26:29 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 14:26:29 -0400 Subject: [M3devel] loophole/copysign In-Reply-To: References: , , , , Message-ID: We really don't want to do this. We need to figure out what needs to be generated as gcc trees. Perhaps an anonymous struct will suffice. On 5 Jul 2010, at 08:56, Jay K wrote: > > nope. > I know this is gross, but how about we addd CG.make_volatile that front end can call very sparingly, > that acts just like generating a call to setjmp or vfork -- in that it makes locals, parameters, temporaries > in current function as volatile? > > CastExpr.m3 would call it for D_to_S and FloatType[src] # FloatType[dest]. > > It would be available as a desparate measure if we find other problems. > To selectively inhibit optimization a function at a time. > Which, granted, is generally overkill. > > I'm trying this now.. > - Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Subject: RE: [M3devel] loophole/copysign >> Date: Mon, 5 Jul 2010 11:36:11 +0000 >> >> >> another idea: let's not use bitfield ref for float/double >> >> - Jay >> >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: m3devel at elegosoft.com >>> Date: Mon, 5 Jul 2010 11:25:19 +0000 >>> Subject: Re: [M3devel] loophole/copysign >>> >>> >>> Hm. it seems that it might be important to preserve the "designatorness", like in: >>> >>> libm3/...RandomReal.m3: >>> >>> VAR frac, exp: INTEGER; result: LONGREAL; >>> >>> (* Repack as LONGREAL: *) >>> WITH lr = LOOPHOLE (result, LongRealRep.T) DO >>> lr.sign := 0; >>> lr.exponent := exp; >>> lr.significand0 := Word.Shift (Word.And (frac, 16_7fffffff), >>> -(WordSize - 1 - FractionBits)); >>> lr.significand1 := r.integer (min := -16_7fffffff-1, max :=16_7fffffff); >>> END; >>> >>> >>> - Jay >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: m3devel at elegosoft.com >>>> Date: Mon, 5 Jul 2010 10:42:57 +0000 >>>> Subject: Re: [M3devel] loophole/copysign >>>> >>>> >>>> Tony, et. al.. in m3front/src/exprs/CastExpr.m3..what's the difference between a "designator" and a "value"? >>>> >>>> >>>> http://www-plan.cs.colorado.edu/diwan/modula3/designators.html >>>> >>>> An identifier is a writable designator >>>> if it is declared as a variable, >>>> is a VAR or VALUE parameter, >>>> is a local of a TYPECASE >>>> or TRY EXCEPT statement, >>>> or is a WITH local that is bound to a writable designator. >>>> An identifier is a readonly designator if it is >>>> a READONLY parameter, >>>> a local of a FOR statement, >>>> or a WITH local bound to a non-designator or >>>> readonly designator. >>>> >>>> >>>> >>>> I guess a designator is what I would think of a "variable" or "read only variable"? >>>> Something that either is "in memory" or can "reasonably" be put there? >>>> >>>> >>>> 1 + 2 is not a designator. >>>> >>>> >>>> Or, generally, a "variable", but that includes such similar things as parameters, "with variables", "for variables", "TYPECASE vairables", "TRY variables" >>>> >>>> >>>> Anything with a name??? (not functions/modules/generics -- "named data") >>>> >>>> >>>> Anyway, the next questions include: >>>> >>>> >>>> In CastExpr.m3 would it be terrible and/or wrong to treat "designators" the same as "values"? >>>> I realize, probably a deoptimization. >>>> I think this lets the backend work. >>>> >>>> >>>> And really, more to the point...shouldn't CastExpr.m3 use cg.loophole far more? >>>> I haven't had much luck with that. I always get the cg stack out of balance or with the wrong types, even though it seems like it should be easy. >>>> >>>> >>>> I have more testing to do, but classifying the loophole as V_to_S (value to structure) in place of D_to_S (designator to structure), at least if either side is one of the three float types, seems reasonable and correct, albeit slight deoptimization -- in unsafe code dealing with floating point..should be rare.. >>>> >>>> >>>> - Jay >>>> >>>> >>>> >>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: m3devel at elegosoft.com >>>>> Date: Mon, 5 Jul 2010 09:24:20 +0000 >>>>> Subject: [M3devel] loophole/copysign >>>>> >>>>> >>>>> Our codegen is remarkably low level. That is, lower level earlier than C. >>>>> >>>>> >>>>> gcc/m3cg -ftree-dump-all >>>>> >>>>> >>>>> As early as LongFloat.mc.003t.original, the first file dumped, we have: >>>>> >>>>> LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) >>>>> { >>>>> xreel M3_CtKayy__result; >>>>> xreel M3_CtKayy_res; >>>>> >>>>> xreel M3_CtKayy__result; >>>>> xreel M3_CtKayy_res; >>>>> M3_CtKayy_res = M3_CtKayy_x; >>>>> BIT_FIELD_REF = (word_8) ((int_64) >>>>> BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); >>>>> = M3_CtKayy_res; >>>>> return ; >>>>> } >>>>> >>>>> compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: >>>>> >>>>> copy_sign_f (from, to) >>>>> { >>>>> float res; >>>>> float D.1918; >>>>> D.1917; >>>>> struct float_t * from.1; >>>>> struct float_t * res.0; >>>>> >>>>> : >>>>> res = to_1; >>>>> res.0_4 = (struct float_t *) &res; >>>>> from.1_5 = (struct float_t *) &from; >>>>> D.1917_6 = from.1_5->sign; >>>>> res.0_4->sign = D.1917_6; >>>>> D.1918_7 = res; >>>>> return D.1918_7; >>>>> >>>>> } >>>>> >>>>> >>>>> See, you know, from gcc's point of view, we don't have any records/structs/unions. >>>>> Just integers and offsets from them mostly. >>>>> >>>>> >>>>> The right fix is to build up types. >>>>> That way also debugging with gdb will have a chance. >>>>> Perhaps not a small amount of work. But maybe not too bad. >>>>> >>>>> >>>>> For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. >>>>> At least if one type but not the other is floating point. >>>>> I don't know if that will work, but maybe. >>>>> >>>>> Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or >>>>> store volatile. >>>>> >>>>> - Jay >>>>> >>>> >>> >> > From jay.krell at cornell.edu Mon Jul 5 22:44:45 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 20:44:45 +0000 Subject: [M3devel] loophole/copysign In-Reply-To: <3267416E-1152-4A3D-A4C0-491F2C5FF74D@cs.purdue.edu> References: , <3267416E-1152-4A3D-A4C0-491F2C5FF74D@cs.purdue.edu> Message-ID: I don't think a barrier worked. The thing is, I don't think a change in parse.c alone can work. It isn't being given enough information. Or, well, it does have enough information, but, like, it is information it never uses. It has some type information. It would have to notice that the most recent store to a variable was of a different type than a load. ?- Jay ---------------------------------------- > Subject: Re: [M3devel] loophole/copysign > From: hosking at cs.purdue.edu > Date: Mon, 5 Jul 2010 14:24:01 -0400 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > We shouldn't need a barrier here. That is for memory operations, whereas these need not be. I would hate to make this change. Why can't we produce gcc trees that accomplish what we need? > > On 5 Jul 2010, at 05:24, Jay K wrote: > > > > > Our codegen is remarkably low level. That is, lower level earlier than C. > > > > > > gcc/m3cg -ftree-dump-all > > > > > > As early as LongFloat.mc.003t.original, the first file dumped, we have: > > > > LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) > > { > > xreel M3_CtKayy__result; > > xreel M3_CtKayy_res; > > > > xreel M3_CtKayy__result; > > xreel M3_CtKayy_res; > > M3_CtKayy_res = M3_CtKayy_x; > > BIT_FIELD_REF = (word_8) ((int_64) > > BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); > > = M3_CtKayy_res; > > return ; > > } > > > > compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: > > > > copy_sign_f (from, to) > > { > > float res; > > float D.1918; > > D.1917; > > struct float_t * from.1; > > struct float_t * res.0; > > > > : > > res = to_1; > > res.0_4 = (struct float_t *) &res; > > from.1_5 = (struct float_t *) &from; > > D.1917_6 = from.1_5->sign; > > res.0_4->sign = D.1917_6; > > D.1918_7 = res; > > return D.1918_7; > > > > } > > > > > > See, you know, from gcc's point of view, we don't have any records/structs/unions. > > Just integers and offsets from them mostly. > > > > > > The right fix is to build up types. > > That way also debugging with gdb will have a chance. > > Perhaps not a small amount of work. But maybe not too bad. > > > > > > For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. > > At least if one type but not the other is floating point. > > I don't know if that will work, but maybe. > > > > Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or > > store volatile. > > > > - Jay > > > From jay.krell at cornell.edu Mon Jul 5 22:49:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 20:49:14 +0000 Subject: [M3devel] loophole/copysign In-Reply-To: References: , , , , , , , , , Message-ID: The make_volatile idea seems to work. I agree it isn't great. I only inserted one call to it, for loophole + d_to_s + floattype src # dest. Let me know if attached is ok to commit. The front end all but needs to change here somehow, as the backend isn't being given much information -- no loophole call at all. Thanks, ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Mon, 5 Jul 2010 14:26:29 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] loophole/copysign > > We really don't want to do this. We need to figure out what needs to be generated as gcc trees. Perhaps an anonymous struct will suffice. > > > On 5 Jul 2010, at 08:56, Jay K wrote: > > > > > nope. > > I know this is gross, but how about we addd CG.make_volatile that front end can call very sparingly, > > that acts just like generating a call to setjmp or vfork -- in that it makes locals, parameters, temporaries > > in current function as volatile? > > > > CastExpr.m3 would call it for D_to_S and FloatType[src] # FloatType[dest]. > > > > It would be available as a desparate measure if we find other problems. > > To selectively inhibit optimization a function at a time. > > Which, granted, is generally overkill. > > > > I'm trying this now.. > > - Jay > > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: m3devel at elegosoft.com > >> Subject: RE: [M3devel] loophole/copysign > >> Date: Mon, 5 Jul 2010 11:36:11 +0000 > >> > >> > >> another idea: let's not use bitfield ref for float/double > >> > >> - Jay > >> > >> > >> > >> ---------------------------------------- > >>> From: jay.krell at cornell.edu > >>> To: m3devel at elegosoft.com > >>> Date: Mon, 5 Jul 2010 11:25:19 +0000 > >>> Subject: Re: [M3devel] loophole/copysign > >>> > >>> > >>> Hm. it seems that it might be important to preserve the "designatorness", like in: > >>> > >>> libm3/...RandomReal.m3: > >>> > >>> VAR frac, exp: INTEGER; result: LONGREAL; > >>> > >>> (* Repack as LONGREAL: *) > >>> WITH lr = LOOPHOLE (result, LongRealRep.T) DO > >>> lr.sign := 0; > >>> lr.exponent := exp; > >>> lr.significand0 := Word.Shift (Word.And (frac, 16_7fffffff), > >>> -(WordSize - 1 - FractionBits)); > >>> lr.significand1 := r.integer (min := -16_7fffffff-1, max :=16_7fffffff); > >>> END; > >>> > >>> > >>> - Jay > >>> > >>> ---------------------------------------- > >>>> From: jay.krell at cornell.edu > >>>> To: m3devel at elegosoft.com > >>>> Date: Mon, 5 Jul 2010 10:42:57 +0000 > >>>> Subject: Re: [M3devel] loophole/copysign > >>>> > >>>> > >>>> Tony, et. al.. in m3front/src/exprs/CastExpr.m3..what's the difference between a "designator" and a "value"? > >>>> > >>>> > >>>> http://www-plan.cs.colorado.edu/diwan/modula3/designators.html > >>>> > >>>> An identifier is a writable designator > >>>> if it is declared as a variable, > >>>> is a VAR or VALUE parameter, > >>>> is a local of a TYPECASE > >>>> or TRY EXCEPT statement, > >>>> or is a WITH local that is bound to a writable designator. > >>>> An identifier is a readonly designator if it is > >>>> a READONLY parameter, > >>>> a local of a FOR statement, > >>>> or a WITH local bound to a non-designator or > >>>> readonly designator. > >>>> > >>>> > >>>> > >>>> I guess a designator is what I would think of a "variable" or "read only variable"? > >>>> Something that either is "in memory" or can "reasonably" be put there? > >>>> > >>>> > >>>> 1 + 2 is not a designator. > >>>> > >>>> > >>>> Or, generally, a "variable", but that includes such similar things as parameters, "with variables", "for variables", "TYPECASE vairables", "TRY variables" > >>>> > >>>> > >>>> Anything with a name??? (not functions/modules/generics -- "named data") > >>>> > >>>> > >>>> Anyway, the next questions include: > >>>> > >>>> > >>>> In CastExpr.m3 would it be terrible and/or wrong to treat "designators" the same as "values"? > >>>> I realize, probably a deoptimization. > >>>> I think this lets the backend work. > >>>> > >>>> > >>>> And really, more to the point...shouldn't CastExpr.m3 use cg.loophole far more? > >>>> I haven't had much luck with that. I always get the cg stack out of balance or with the wrong types, even though it seems like it should be easy. > >>>> > >>>> > >>>> I have more testing to do, but classifying the loophole as V_to_S (value to structure) in place of D_to_S (designator to structure), at least if either side is one of the three float types, seems reasonable and correct, albeit slight deoptimization -- in unsafe code dealing with floating point..should be rare.. > >>>> > >>>> > >>>> - Jay > >>>> > >>>> > >>>> > >>>> ---------------------------------------- > >>>>> From: jay.krell at cornell.edu > >>>>> To: m3devel at elegosoft.com > >>>>> Date: Mon, 5 Jul 2010 09:24:20 +0000 > >>>>> Subject: [M3devel] loophole/copysign > >>>>> > >>>>> > >>>>> Our codegen is remarkably low level. That is, lower level earlier than C. > >>>>> > >>>>> > >>>>> gcc/m3cg -ftree-dump-all > >>>>> > >>>>> > >>>>> As early as LongFloat.mc.003t.original, the first file dumped, we have: > >>>>> > >>>>> LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) > >>>>> { > >>>>> xreel M3_CtKayy__result; > >>>>> xreel M3_CtKayy_res; > >>>>> > >>>>> xreel M3_CtKayy__result; > >>>>> xreel M3_CtKayy_res; > >>>>> M3_CtKayy_res = M3_CtKayy_x; > >>>>> BIT_FIELD_REF = (word_8) ((int_64) > >>>>> BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); > >>>>> = M3_CtKayy_res; > >>>>> return ; > >>>>> } > >>>>> > >>>>> compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: > >>>>> > >>>>> copy_sign_f (from, to) > >>>>> { > >>>>> float res; > >>>>> float D.1918; > >>>>> D.1917; > >>>>> struct float_t * from.1; > >>>>> struct float_t * res.0; > >>>>> > >>>>> : > >>>>> res = to_1; > >>>>> res.0_4 = (struct float_t *) &res; > >>>>> from.1_5 = (struct float_t *) &from; > >>>>> D.1917_6 = from.1_5->sign; > >>>>> res.0_4->sign = D.1917_6; > >>>>> D.1918_7 = res; > >>>>> return D.1918_7; > >>>>> > >>>>> } > >>>>> > >>>>> > >>>>> See, you know, from gcc's point of view, we don't have any records/structs/unions. > >>>>> Just integers and offsets from them mostly. > >>>>> > >>>>> > >>>>> The right fix is to build up types. > >>>>> That way also debugging with gdb will have a chance. > >>>>> Perhaps not a small amount of work. But maybe not too bad. > >>>>> > >>>>> > >>>>> For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. > >>>>> At least if one type but not the other is floating point. > >>>>> I don't know if that will work, but maybe. > >>>>> > >>>>> Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or > >>>>> store volatile. > >>>>> > >>>>> - Jay > >>>>> > >>>> > >>> > >> > > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: volatile.txt URL: From jay.krell at cornell.edu Mon Jul 5 22:51:25 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 20:51:25 +0000 Subject: [M3devel] loophole/copysign In-Reply-To: <01D93A8D-8D43-4D9A-A753-6B2D41C03F52@cs.purdue.edu> References: , , , , , , , <01D93A8D-8D43-4D9A-A753-6B2D41C03F52@cs.purdue.edu> Message-ID: I think this is still a good idea but I don't think relevant here. There's no offset or type mismatch to trigger that path, in this code, I'm pretty sure. I think a temporary would still work, in the "LV" D_to_S variant. But a temporary is wrong for the non-LV case, due the need to preserve writes to the original. But I didn't read through how the compiler choses LV or not-LV so not yet keen on making that sort of change. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Mon, 5 Jul 2010 14:25:17 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] loophole/copysign > > Yes, maybe that is the best way forward. > > On 5 Jul 2010, at 07:36, Jay K wrote: > > > > > another idea: let's not use bitfield ref for float/double > > > > - Jay > > > > > > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: m3devel at elegosoft.com > >> Date: Mon, 5 Jul 2010 11:25:19 +0000 > >> Subject: Re: [M3devel] loophole/copysign > >> > >> > >> Hm. it seems that it might be important to preserve the "designatorness", like in: > >> > >> libm3/...RandomReal.m3: > >> > >> VAR frac, exp: INTEGER; result: LONGREAL; > >> > >> (* Repack as LONGREAL: *) > >> WITH lr = LOOPHOLE (result, LongRealRep.T) DO > >> lr.sign := 0; > >> lr.exponent := exp; > >> lr.significand0 := Word.Shift (Word.And (frac, 16_7fffffff), > >> -(WordSize - 1 - FractionBits)); > >> lr.significand1 := r.integer (min := -16_7fffffff-1, max :=16_7fffffff); > >> END; > >> > >> > >> - Jay > >> > >> ---------------------------------------- > >>> From: jay.krell at cornell.edu > >>> To: m3devel at elegosoft.com > >>> Date: Mon, 5 Jul 2010 10:42:57 +0000 > >>> Subject: Re: [M3devel] loophole/copysign > >>> > >>> > >>> Tony, et. al.. in m3front/src/exprs/CastExpr.m3..what's the difference between a "designator" and a "value"? > >>> > >>> > >>> http://www-plan.cs.colorado.edu/diwan/modula3/designators.html > >>> > >>> An identifier is a writable designator > >>> if it is declared as a variable, > >>> is a VAR or VALUE parameter, > >>> is a local of a TYPECASE > >>> or TRY EXCEPT statement, > >>> or is a WITH local that is bound to a writable designator. > >>> An identifier is a readonly designator if it is > >>> a READONLY parameter, > >>> a local of a FOR statement, > >>> or a WITH local bound to a non-designator or > >>> readonly designator. > >>> > >>> > >>> > >>> I guess a designator is what I would think of a "variable" or "read only variable"? > >>> Something that either is "in memory" or can "reasonably" be put there? > >>> > >>> > >>> 1 + 2 is not a designator. > >>> > >>> > >>> Or, generally, a "variable", but that includes such similar things as parameters, "with variables", "for variables", "TYPECASE vairables", "TRY variables" > >>> > >>> > >>> Anything with a name??? (not functions/modules/generics -- "named data") > >>> > >>> > >>> Anyway, the next questions include: > >>> > >>> > >>> In CastExpr.m3 would it be terrible and/or wrong to treat "designators" the same as "values"? > >>> I realize, probably a deoptimization. > >>> I think this lets the backend work. > >>> > >>> > >>> And really, more to the point...shouldn't CastExpr.m3 use cg.loophole far more? > >>> I haven't had much luck with that. I always get the cg stack out of balance or with the wrong types, even though it seems like it should be easy. > >>> > >>> > >>> I have more testing to do, but classifying the loophole as V_to_S (value to structure) in place of D_to_S (designator to structure), at least if either side is one of the three float types, seems reasonable and correct, albeit slight deoptimization -- in unsafe code dealing with floating point..should be rare.. > >>> > >>> > >>> - Jay > >>> > >>> > >>> > >>> ---------------------------------------- > >>>> From: jay.krell at cornell.edu > >>>> To: m3devel at elegosoft.com > >>>> Date: Mon, 5 Jul 2010 09:24:20 +0000 > >>>> Subject: [M3devel] loophole/copysign > >>>> > >>>> > >>>> Our codegen is remarkably low level. That is, lower level earlier than C. > >>>> > >>>> > >>>> gcc/m3cg -ftree-dump-all > >>>> > >>>> > >>>> As early as LongFloat.mc.003t.original, the first file dumped, we have: > >>>> > >>>> LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) > >>>> { > >>>> xreel M3_CtKayy__result; > >>>> xreel M3_CtKayy_res; > >>>> > >>>> xreel M3_CtKayy__result; > >>>> xreel M3_CtKayy_res; > >>>> M3_CtKayy_res = M3_CtKayy_x; > >>>> BIT_FIELD_REF = (word_8) ((int_64) > >>>> BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); > >>>> = M3_CtKayy_res; > >>>> return ; > >>>> } > >>>> > >>>> compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: > >>>> > >>>> copy_sign_f (from, to) > >>>> { > >>>> float res; > >>>> float D.1918; > >>>> D.1917; > >>>> struct float_t * from.1; > >>>> struct float_t * res.0; > >>>> > >>>> : > >>>> res = to_1; > >>>> res.0_4 = (struct float_t *) &res; > >>>> from.1_5 = (struct float_t *) &from; > >>>> D.1917_6 = from.1_5->sign; > >>>> res.0_4->sign = D.1917_6; > >>>> D.1918_7 = res; > >>>> return D.1918_7; > >>>> > >>>> } > >>>> > >>>> > >>>> See, you know, from gcc's point of view, we don't have any records/structs/unions. > >>>> Just integers and offsets from them mostly. > >>>> > >>>> > >>>> The right fix is to build up types. > >>>> That way also debugging with gdb will have a chance. > >>>> Perhaps not a small amount of work. But maybe not too bad. > >>>> > >>>> > >>>> For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. > >>>> At least if one type but not the other is floating point. > >>>> I don't know if that will work, but maybe. > >>>> > >>>> Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or > >>>> store volatile. > >>>> > >>>> - Jay > >>>> > >>> > >> > > > From hosking at cs.purdue.edu Mon Jul 5 23:32:44 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 17:32:44 -0400 Subject: [M3devel] loophole/copysign In-Reply-To: References: , , , , , , , , , Message-ID: <19A59BEE-60F0-4A37-8FF8-69FBC74AB153@cs.purdue.edu> Are you saying that conversion of floats is not generating a loophole? The volatilise idea is overkill, and I don't want to see it contaminate the M3CG interfaces. Can you point me at the problematic code in CastExpr? On 5 Jul 2010, at 16:49, Jay K wrote: > > The make_volatile idea seems to work. I agree it isn't great. I only inserted one call to it, for loophole + d_to_s + floattype src # dest. > Let me know if attached is ok to commit. > The front end all but needs to change here somehow, as the backend isn't being given much information -- no loophole call at all. > > Thanks, > - Jay > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Mon, 5 Jul 2010 14:26:29 -0400 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] loophole/copysign >> >> We really don't want to do this. We need to figure out what needs to be generated as gcc trees. Perhaps an anonymous struct will suffice. >> >> >> On 5 Jul 2010, at 08:56, Jay K wrote: >> >>> >>> nope. >>> I know this is gross, but how about we addd CG.make_volatile that front end can call very sparingly, >>> that acts just like generating a call to setjmp or vfork -- in that it makes locals, parameters, temporaries >>> in current function as volatile? >>> >>> CastExpr.m3 would call it for D_to_S and FloatType[src] # FloatType[dest]. >>> >>> It would be available as a desparate measure if we find other problems. >>> To selectively inhibit optimization a function at a time. >>> Which, granted, is generally overkill. >>> >>> I'm trying this now.. >>> - Jay >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: m3devel at elegosoft.com >>>> Subject: RE: [M3devel] loophole/copysign >>>> Date: Mon, 5 Jul 2010 11:36:11 +0000 >>>> >>>> >>>> another idea: let's not use bitfield ref for float/double >>>> >>>> - Jay >>>> >>>> >>>> >>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: m3devel at elegosoft.com >>>>> Date: Mon, 5 Jul 2010 11:25:19 +0000 >>>>> Subject: Re: [M3devel] loophole/copysign >>>>> >>>>> >>>>> Hm. it seems that it might be important to preserve the "designatorness", like in: >>>>> >>>>> libm3/...RandomReal.m3: >>>>> >>>>> VAR frac, exp: INTEGER; result: LONGREAL; >>>>> >>>>> (* Repack as LONGREAL: *) >>>>> WITH lr = LOOPHOLE (result, LongRealRep.T) DO >>>>> lr.sign := 0; >>>>> lr.exponent := exp; >>>>> lr.significand0 := Word.Shift (Word.And (frac, 16_7fffffff), >>>>> -(WordSize - 1 - FractionBits)); >>>>> lr.significand1 := r.integer (min := -16_7fffffff-1, max :=16_7fffffff); >>>>> END; >>>>> >>>>> >>>>> - Jay >>>>> >>>>> ---------------------------------------- >>>>>> From: jay.krell at cornell.edu >>>>>> To: m3devel at elegosoft.com >>>>>> Date: Mon, 5 Jul 2010 10:42:57 +0000 >>>>>> Subject: Re: [M3devel] loophole/copysign >>>>>> >>>>>> >>>>>> Tony, et. al.. in m3front/src/exprs/CastExpr.m3..what's the difference between a "designator" and a "value"? >>>>>> >>>>>> >>>>>> http://www-plan.cs.colorado.edu/diwan/modula3/designators.html >>>>>> >>>>>> An identifier is a writable designator >>>>>> if it is declared as a variable, >>>>>> is a VAR or VALUE parameter, >>>>>> is a local of a TYPECASE >>>>>> or TRY EXCEPT statement, >>>>>> or is a WITH local that is bound to a writable designator. >>>>>> An identifier is a readonly designator if it is >>>>>> a READONLY parameter, >>>>>> a local of a FOR statement, >>>>>> or a WITH local bound to a non-designator or >>>>>> readonly designator. >>>>>> >>>>>> >>>>>> >>>>>> I guess a designator is what I would think of a "variable" or "read only variable"? >>>>>> Something that either is "in memory" or can "reasonably" be put there? >>>>>> >>>>>> >>>>>> 1 + 2 is not a designator. >>>>>> >>>>>> >>>>>> Or, generally, a "variable", but that includes such similar things as parameters, "with variables", "for variables", "TYPECASE vairables", "TRY variables" >>>>>> >>>>>> >>>>>> Anything with a name??? (not functions/modules/generics -- "named data") >>>>>> >>>>>> >>>>>> Anyway, the next questions include: >>>>>> >>>>>> >>>>>> In CastExpr.m3 would it be terrible and/or wrong to treat "designators" the same as "values"? >>>>>> I realize, probably a deoptimization. >>>>>> I think this lets the backend work. >>>>>> >>>>>> >>>>>> And really, more to the point...shouldn't CastExpr.m3 use cg.loophole far more? >>>>>> I haven't had much luck with that. I always get the cg stack out of balance or with the wrong types, even though it seems like it should be easy. >>>>>> >>>>>> >>>>>> I have more testing to do, but classifying the loophole as V_to_S (value to structure) in place of D_to_S (designator to structure), at least if either side is one of the three float types, seems reasonable and correct, albeit slight deoptimization -- in unsafe code dealing with floating point..should be rare.. >>>>>> >>>>>> >>>>>> - Jay >>>>>> >>>>>> >>>>>> >>>>>> ---------------------------------------- >>>>>>> From: jay.krell at cornell.edu >>>>>>> To: m3devel at elegosoft.com >>>>>>> Date: Mon, 5 Jul 2010 09:24:20 +0000 >>>>>>> Subject: [M3devel] loophole/copysign >>>>>>> >>>>>>> >>>>>>> Our codegen is remarkably low level. That is, lower level earlier than C. >>>>>>> >>>>>>> >>>>>>> gcc/m3cg -ftree-dump-all >>>>>>> >>>>>>> >>>>>>> As early as LongFloat.mc.003t.original, the first file dumped, we have: >>>>>>> >>>>>>> LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) >>>>>>> { >>>>>>> xreel M3_CtKayy__result; >>>>>>> xreel M3_CtKayy_res; >>>>>>> >>>>>>> xreel M3_CtKayy__result; >>>>>>> xreel M3_CtKayy_res; >>>>>>> M3_CtKayy_res = M3_CtKayy_x; >>>>>>> BIT_FIELD_REF = (word_8) ((int_64) >>>>>>> BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); >>>>>>> = M3_CtKayy_res; >>>>>>> return ; >>>>>>> } >>>>>>> >>>>>>> compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: >>>>>>> >>>>>>> copy_sign_f (from, to) >>>>>>> { >>>>>>> float res; >>>>>>> float D.1918; >>>>>>> D.1917; >>>>>>> struct float_t * from.1; >>>>>>> struct float_t * res.0; >>>>>>> >>>>>>> : >>>>>>> res = to_1; >>>>>>> res.0_4 = (struct float_t *) &res; >>>>>>> from.1_5 = (struct float_t *) &from; >>>>>>> D.1917_6 = from.1_5->sign; >>>>>>> res.0_4->sign = D.1917_6; >>>>>>> D.1918_7 = res; >>>>>>> return D.1918_7; >>>>>>> >>>>>>> } >>>>>>> >>>>>>> >>>>>>> See, you know, from gcc's point of view, we don't have any records/structs/unions. >>>>>>> Just integers and offsets from them mostly. >>>>>>> >>>>>>> >>>>>>> The right fix is to build up types. >>>>>>> That way also debugging with gdb will have a chance. >>>>>>> Perhaps not a small amount of work. But maybe not too bad. >>>>>>> >>>>>>> >>>>>>> For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. >>>>>>> At least if one type but not the other is floating point. >>>>>>> I don't know if that will work, but maybe. >>>>>>> >>>>>>> Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or >>>>>>> store volatile. >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>> >>>>> >>>> >>> >> > From hosking at cs.purdue.edu Mon Jul 5 23:34:20 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 17:34:20 -0400 Subject: [M3devel] loophole/copysign In-Reply-To: References: , , , , , , , <01D93A8D-8D43-4D9A-A753-6B2D41C03F52@cs.purdue.edu> Message-ID: None of this is making much sense to me... On 5 Jul 2010, at 16:51, Jay K wrote: > > I think this is still a good idea but I don't think relevant here. > There's no offset or type mismatch to trigger that path, in this code, I'm pretty sure. > > I think a temporary would still work, in the "LV" D_to_S variant. > But a temporary is wrong for the non-LV case, due the need to preserve writes to the original. > But I didn't read through how the compiler choses LV or not-LV so not yet keen on making that sort of change. > > - Jay > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Mon, 5 Jul 2010 14:25:17 -0400 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] loophole/copysign >> >> Yes, maybe that is the best way forward. >> >> On 5 Jul 2010, at 07:36, Jay K wrote: >> >>> >>> another idea: let's not use bitfield ref for float/double >>> >>> - Jay >>> >>> >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: m3devel at elegosoft.com >>>> Date: Mon, 5 Jul 2010 11:25:19 +0000 >>>> Subject: Re: [M3devel] loophole/copysign >>>> >>>> >>>> Hm. it seems that it might be important to preserve the "designatorness", like in: >>>> >>>> libm3/...RandomReal.m3: >>>> >>>> VAR frac, exp: INTEGER; result: LONGREAL; >>>> >>>> (* Repack as LONGREAL: *) >>>> WITH lr = LOOPHOLE (result, LongRealRep.T) DO >>>> lr.sign := 0; >>>> lr.exponent := exp; >>>> lr.significand0 := Word.Shift (Word.And (frac, 16_7fffffff), >>>> -(WordSize - 1 - FractionBits)); >>>> lr.significand1 := r.integer (min := -16_7fffffff-1, max :=16_7fffffff); >>>> END; >>>> >>>> >>>> - Jay >>>> >>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: m3devel at elegosoft.com >>>>> Date: Mon, 5 Jul 2010 10:42:57 +0000 >>>>> Subject: Re: [M3devel] loophole/copysign >>>>> >>>>> >>>>> Tony, et. al.. in m3front/src/exprs/CastExpr.m3..what's the difference between a "designator" and a "value"? >>>>> >>>>> >>>>> http://www-plan.cs.colorado.edu/diwan/modula3/designators.html >>>>> >>>>> An identifier is a writable designator >>>>> if it is declared as a variable, >>>>> is a VAR or VALUE parameter, >>>>> is a local of a TYPECASE >>>>> or TRY EXCEPT statement, >>>>> or is a WITH local that is bound to a writable designator. >>>>> An identifier is a readonly designator if it is >>>>> a READONLY parameter, >>>>> a local of a FOR statement, >>>>> or a WITH local bound to a non-designator or >>>>> readonly designator. >>>>> >>>>> >>>>> >>>>> I guess a designator is what I would think of a "variable" or "read only variable"? >>>>> Something that either is "in memory" or can "reasonably" be put there? >>>>> >>>>> >>>>> 1 + 2 is not a designator. >>>>> >>>>> >>>>> Or, generally, a "variable", but that includes such similar things as parameters, "with variables", "for variables", "TYPECASE vairables", "TRY variables" >>>>> >>>>> >>>>> Anything with a name??? (not functions/modules/generics -- "named data") >>>>> >>>>> >>>>> Anyway, the next questions include: >>>>> >>>>> >>>>> In CastExpr.m3 would it be terrible and/or wrong to treat "designators" the same as "values"? >>>>> I realize, probably a deoptimization. >>>>> I think this lets the backend work. >>>>> >>>>> >>>>> And really, more to the point...shouldn't CastExpr.m3 use cg.loophole far more? >>>>> I haven't had much luck with that. I always get the cg stack out of balance or with the wrong types, even though it seems like it should be easy. >>>>> >>>>> >>>>> I have more testing to do, but classifying the loophole as V_to_S (value to structure) in place of D_to_S (designator to structure), at least if either side is one of the three float types, seems reasonable and correct, albeit slight deoptimization -- in unsafe code dealing with floating point..should be rare.. >>>>> >>>>> >>>>> - Jay >>>>> >>>>> >>>>> >>>>> ---------------------------------------- >>>>>> From: jay.krell at cornell.edu >>>>>> To: m3devel at elegosoft.com >>>>>> Date: Mon, 5 Jul 2010 09:24:20 +0000 >>>>>> Subject: [M3devel] loophole/copysign >>>>>> >>>>>> >>>>>> Our codegen is remarkably low level. That is, lower level earlier than C. >>>>>> >>>>>> >>>>>> gcc/m3cg -ftree-dump-all >>>>>> >>>>>> >>>>>> As early as LongFloat.mc.003t.original, the first file dumped, we have: >>>>>> >>>>>> LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) >>>>>> { >>>>>> xreel M3_CtKayy__result; >>>>>> xreel M3_CtKayy_res; >>>>>> >>>>>> xreel M3_CtKayy__result; >>>>>> xreel M3_CtKayy_res; >>>>>> M3_CtKayy_res = M3_CtKayy_x; >>>>>> BIT_FIELD_REF = (word_8) ((int_64) >>>>>> BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); >>>>>> = M3_CtKayy_res; >>>>>> return ; >>>>>> } >>>>>> >>>>>> compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: >>>>>> >>>>>> copy_sign_f (from, to) >>>>>> { >>>>>> float res; >>>>>> float D.1918; >>>>>> D.1917; >>>>>> struct float_t * from.1; >>>>>> struct float_t * res.0; >>>>>> >>>>>> : >>>>>> res = to_1; >>>>>> res.0_4 = (struct float_t *) &res; >>>>>> from.1_5 = (struct float_t *) &from; >>>>>> D.1917_6 = from.1_5->sign; >>>>>> res.0_4->sign = D.1917_6; >>>>>> D.1918_7 = res; >>>>>> return D.1918_7; >>>>>> >>>>>> } >>>>>> >>>>>> >>>>>> See, you know, from gcc's point of view, we don't have any records/structs/unions. >>>>>> Just integers and offsets from them mostly. >>>>>> >>>>>> >>>>>> The right fix is to build up types. >>>>>> That way also debugging with gdb will have a chance. >>>>>> Perhaps not a small amount of work. But maybe not too bad. >>>>>> >>>>>> >>>>>> For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. >>>>>> At least if one type but not the other is floating point. >>>>>> I don't know if that will work, but maybe. >>>>>> >>>>>> Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or >>>>>> store volatile. >>>>>> >>>>>> - Jay >>>>>> >>>>> >>>> >>> >> > From hosking at cs.purdue.edu Mon Jul 5 23:33:43 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 17:33:43 -0400 Subject: [M3devel] loophole/copysign In-Reply-To: References: , <3267416E-1152-4A3D-A4C0-491F2C5FF74D@cs.purdue.edu> Message-ID: <6BF4E7E7-1068-4623-AE86-6687E2B7B385@cs.purdue.edu> Surely we should instead give it the type conversion from what was stored to what is loaded. Can you point me at the problem code in CastExpr? On 5 Jul 2010, at 16:44, Jay K wrote: > > I don't think a barrier worked. > The thing is, I don't think a change in parse.c alone can work. It isn't being given enough information. > Or, well, it does have enough information, but, like, it is information it never uses. > It has some type information. It would have to notice that the most recent store to a variable was > of a different type than a load. > > - Jay > > > > ---------------------------------------- >> Subject: Re: [M3devel] loophole/copysign >> From: hosking at cs.purdue.edu >> Date: Mon, 5 Jul 2010 14:24:01 -0400 >> CC: m3devel at elegosoft.com >> To: jay.krell at cornell.edu >> >> We shouldn't need a barrier here. That is for memory operations, whereas these need not be. I would hate to make this change. Why can't we produce gcc trees that accomplish what we need? >> >> On 5 Jul 2010, at 05:24, Jay K wrote: >> >>> >>> Our codegen is remarkably low level. That is, lower level earlier than C. >>> >>> >>> gcc/m3cg -ftree-dump-all >>> >>> >>> As early as LongFloat.mc.003t.original, the first file dumped, we have: >>> >>> LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) >>> { >>> xreel M3_CtKayy__result; >>> xreel M3_CtKayy_res; >>> >>> xreel M3_CtKayy__result; >>> xreel M3_CtKayy_res; >>> M3_CtKayy_res = M3_CtKayy_x; >>> BIT_FIELD_REF = (word_8) ((int_64) >>> BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); >>> = M3_CtKayy_res; >>> return ; >>> } >>> >>> compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: >>> >>> copy_sign_f (from, to) >>> { >>> float res; >>> float D.1918; >>> D.1917; >>> struct float_t * from.1; >>> struct float_t * res.0; >>> >>> : >>> res = to_1; >>> res.0_4 = (struct float_t *) &res; >>> from.1_5 = (struct float_t *) &from; >>> D.1917_6 = from.1_5->sign; >>> res.0_4->sign = D.1917_6; >>> D.1918_7 = res; >>> return D.1918_7; >>> >>> } >>> >>> >>> See, you know, from gcc's point of view, we don't have any records/structs/unions. >>> Just integers and offsets from them mostly. >>> >>> >>> The right fix is to build up types. >>> That way also debugging with gdb will have a chance. >>> Perhaps not a small amount of work. But maybe not too bad. >>> >>> >>> For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. >>> At least if one type but not the other is floating point. >>> I don't know if that will work, but maybe. >>> >>> Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or >>> store volatile. >>> >>> - Jay >>> >> > From jay.krell at cornell.edu Mon Jul 5 23:42:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 21:42:43 +0000 Subject: [M3devel] loophole/copysign In-Reply-To: <6BF4E7E7-1068-4623-AE86-6687E2B7B385@cs.purdue.edu> References: , , <3267416E-1152-4A3D-A4C0-491F2C5FF74D@cs.purdue.edu>, , <6BF4E7E7-1068-4623-AE86-6687E2B7B385@cs.purdue.edu> Message-ID: CastExpr.m3 has precious few calls to CG.Loophole, including none for this case. cm3cg -y output for m3core/LongReal.mc CopySign has no calls to loophole. We store into a local as one type and read it back as another type. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Mon, 5 Jul 2010 17:33:43 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] loophole/copysign > > Surely we should instead give it the type conversion from what was stored to what is loaded. Can you point me at the problem code in CastExpr? > > On 5 Jul 2010, at 16:44, Jay K wrote: > > > > > I don't think a barrier worked. > > The thing is, I don't think a change in parse.c alone can work. It isn't being given enough information. > > Or, well, it does have enough information, but, like, it is information it never uses. > > It has some type information. It would have to notice that the most recent store to a variable was > > of a different type than a load. > > > > - Jay > > > > > > > > ---------------------------------------- > >> Subject: Re: [M3devel] loophole/copysign > >> From: hosking at cs.purdue.edu > >> Date: Mon, 5 Jul 2010 14:24:01 -0400 > >> CC: m3devel at elegosoft.com > >> To: jay.krell at cornell.edu > >> > >> We shouldn't need a barrier here. That is for memory operations, whereas these need not be. I would hate to make this change. Why can't we produce gcc trees that accomplish what we need? > >> > >> On 5 Jul 2010, at 05:24, Jay K wrote: > >> > >>> > >>> Our codegen is remarkably low level. That is, lower level earlier than C. > >>> > >>> > >>> gcc/m3cg -ftree-dump-all > >>> > >>> > >>> As early as LongFloat.mc.003t.original, the first file dumped, we have: > >>> > >>> LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) > >>> { > >>> xreel M3_CtKayy__result; > >>> xreel M3_CtKayy_res; > >>> > >>> xreel M3_CtKayy__result; > >>> xreel M3_CtKayy_res; > >>> M3_CtKayy_res = M3_CtKayy_x; > >>> BIT_FIELD_REF = (word_8) ((int_64) > >>> BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); > >>> = M3_CtKayy_res; > >>> return ; > >>> } > >>> > >>> compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: > >>> > >>> copy_sign_f (from, to) > >>> { > >>> float res; > >>> float D.1918; > >>> D.1917; > >>> struct float_t * from.1; > >>> struct float_t * res.0; > >>> > >>> : > >>> res = to_1; > >>> res.0_4 = (struct float_t *) &res; > >>> from.1_5 = (struct float_t *) &from; > >>> D.1917_6 = from.1_5->sign; > >>> res.0_4->sign = D.1917_6; > >>> D.1918_7 = res; > >>> return D.1918_7; > >>> > >>> } > >>> > >>> > >>> See, you know, from gcc's point of view, we don't have any records/structs/unions. > >>> Just integers and offsets from them mostly. > >>> > >>> > >>> The right fix is to build up types. > >>> That way also debugging with gdb will have a chance. > >>> Perhaps not a small amount of work. But maybe not too bad. > >>> > >>> > >>> For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. > >>> At least if one type but not the other is floating point. > >>> I don't know if that will work, but maybe. > >>> > >>> Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or > >>> store volatile. > >>> > >>> - Jay > >>> > >> > > > From jay.krell at cornell.edu Tue Jul 6 00:20:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 22:20:20 +0000 Subject: [M3devel] loophole/copysign In-Reply-To: References: , , <3267416E-1152-4A3D-A4C0-491F2C5FF74D@cs.purdue.edu>, , <6BF4E7E7-1068-4623-AE86-6687E2B7B385@cs.purdue.edu>, Message-ID: Specifically it goes down the "D_to_S" and "LV" paths (PrepLV, CompileLV, and not Prep and Compile, no temporary, no loophole) ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] loophole/copysign > Date: Mon, 5 Jul 2010 21:42:43 +0000 > > > CastExpr.m3 has precious few calls to CG.Loophole, including none for this case. > cm3cg -y output for m3core/LongReal.mc CopySign has no calls to loophole. > We store into a local as one type and read it back as another type. > > - Jay > > ---------------------------------------- > > From: hosking at cs.purdue.edu > > Date: Mon, 5 Jul 2010 17:33:43 -0400 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] loophole/copysign > > > > Surely we should instead give it the type conversion from what was stored to what is loaded. Can you point me at the problem code in CastExpr? > > > > On 5 Jul 2010, at 16:44, Jay K wrote: > > > > > > > > I don't think a barrier worked. > > > The thing is, I don't think a change in parse.c alone can work. It isn't being given enough information. > > > Or, well, it does have enough information, but, like, it is information it never uses. > > > It has some type information. It would have to notice that the most recent store to a variable was > > > of a different type than a load. > > > > > > - Jay > > > > > > > > > > > > ---------------------------------------- > > >> Subject: Re: [M3devel] loophole/copysign > > >> From: hosking at cs.purdue.edu > > >> Date: Mon, 5 Jul 2010 14:24:01 -0400 > > >> CC: m3devel at elegosoft.com > > >> To: jay.krell at cornell.edu > > >> > > >> We shouldn't need a barrier here. That is for memory operations, whereas these need not be. I would hate to make this change. Why can't we produce gcc trees that accomplish what we need? > > >> > > >> On 5 Jul 2010, at 05:24, Jay K wrote: > > >> > > >>> > > >>> Our codegen is remarkably low level. That is, lower level earlier than C. > > >>> > > >>> > > >>> gcc/m3cg -ftree-dump-all > > >>> > > >>> > > >>> As early as LongFloat.mc.003t.original, the first file dumped, we have: > > >>> > > >>> LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) > > >>> { > > >>> xreel M3_CtKayy__result; > > >>> xreel M3_CtKayy_res; > > >>> > > >>> xreel M3_CtKayy__result; > > >>> xreel M3_CtKayy_res; > > >>> M3_CtKayy_res = M3_CtKayy_x; > > >>> BIT_FIELD_REF = (word_8) ((int_64) > > >>> BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); > > >>> = M3_CtKayy_res; > > >>> return ; > > >>> } > > >>> > > >>> compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: > > >>> > > >>> copy_sign_f (from, to) > > >>> { > > >>> float res; > > >>> float D.1918; > > >>> D.1917; > > >>> struct float_t * from.1; > > >>> struct float_t * res.0; > > >>> > > >>> : > > >>> res = to_1; > > >>> res.0_4 = (struct float_t *) &res; > > >>> from.1_5 = (struct float_t *) &from; > > >>> D.1917_6 = from.1_5->sign; > > >>> res.0_4->sign = D.1917_6; > > >>> D.1918_7 = res; > > >>> return D.1918_7; > > >>> > > >>> } > > >>> > > >>> > > >>> See, you know, from gcc's point of view, we don't have any records/structs/unions. > > >>> Just integers and offsets from them mostly. > > >>> > > >>> > > >>> The right fix is to build up types. > > >>> That way also debugging with gdb will have a chance. > > >>> Perhaps not a small amount of work. But maybe not too bad. > > >>> > > >>> > > >>> For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. > > >>> At least if one type but not the other is floating point. > > >>> I don't know if that will work, but maybe. > > >>> > > >>> Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or > > >>> store volatile. > > >>> > > >>> - Jay > > >>> > > >> > > > > > > From hosking at cs.purdue.edu Tue Jul 6 00:27:10 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 18:27:10 -0400 Subject: [M3devel] loophole/copysign In-Reply-To: References: , , <3267416E-1152-4A3D-A4C0-491F2C5FF74D@cs.purdue.edu>, , <6BF4E7E7-1068-4623-AE86-6687E2B7B385@cs.purdue.edu> Message-ID: OK, so now I begin to understand. What you are saying is that gcc needs to have a union type capturing the fact that the variable is accessed using 2 different types. What happens in C code where you cast a memory location from one type to another? How does gcc cope with that? Presumably it gets some sort of type aliasing information? On 5 Jul 2010, at 17:42, Jay K wrote: > > CastExpr.m3 has precious few calls to CG.Loophole, including none for this case. > cm3cg -y output for m3core/LongReal.mc CopySign has no calls to loophole. > We store into a local as one type and read it back as another type. > > - Jay > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Mon, 5 Jul 2010 17:33:43 -0400 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] loophole/copysign >> >> Surely we should instead give it the type conversion from what was stored to what is loaded. Can you point me at the problem code in CastExpr? >> >> On 5 Jul 2010, at 16:44, Jay K wrote: >> >>> >>> I don't think a barrier worked. >>> The thing is, I don't think a change in parse.c alone can work. It isn't being given enough information. >>> Or, well, it does have enough information, but, like, it is information it never uses. >>> It has some type information. It would have to notice that the most recent store to a variable was >>> of a different type than a load. >>> >>> - Jay >>> >>> >>> >>> ---------------------------------------- >>>> Subject: Re: [M3devel] loophole/copysign >>>> From: hosking at cs.purdue.edu >>>> Date: Mon, 5 Jul 2010 14:24:01 -0400 >>>> CC: m3devel at elegosoft.com >>>> To: jay.krell at cornell.edu >>>> >>>> We shouldn't need a barrier here. That is for memory operations, whereas these need not be. I would hate to make this change. Why can't we produce gcc trees that accomplish what we need? >>>> >>>> On 5 Jul 2010, at 05:24, Jay K wrote: >>>> >>>>> >>>>> Our codegen is remarkably low level. That is, lower level earlier than C. >>>>> >>>>> >>>>> gcc/m3cg -ftree-dump-all >>>>> >>>>> >>>>> As early as LongFloat.mc.003t.original, the first file dumped, we have: >>>>> >>>>> LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) >>>>> { >>>>> xreel M3_CtKayy__result; >>>>> xreel M3_CtKayy_res; >>>>> >>>>> xreel M3_CtKayy__result; >>>>> xreel M3_CtKayy_res; >>>>> M3_CtKayy_res = M3_CtKayy_x; >>>>> BIT_FIELD_REF = (word_8) ((int_64) >>>>> BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); >>>>> = M3_CtKayy_res; >>>>> return ; >>>>> } >>>>> >>>>> compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: >>>>> >>>>> copy_sign_f (from, to) >>>>> { >>>>> float res; >>>>> float D.1918; >>>>> D.1917; >>>>> struct float_t * from.1; >>>>> struct float_t * res.0; >>>>> >>>>> : >>>>> res = to_1; >>>>> res.0_4 = (struct float_t *) &res; >>>>> from.1_5 = (struct float_t *) &from; >>>>> D.1917_6 = from.1_5->sign; >>>>> res.0_4->sign = D.1917_6; >>>>> D.1918_7 = res; >>>>> return D.1918_7; >>>>> >>>>> } >>>>> >>>>> >>>>> See, you know, from gcc's point of view, we don't have any records/structs/unions. >>>>> Just integers and offsets from them mostly. >>>>> >>>>> >>>>> The right fix is to build up types. >>>>> That way also debugging with gdb will have a chance. >>>>> Perhaps not a small amount of work. But maybe not too bad. >>>>> >>>>> >>>>> For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. >>>>> At least if one type but not the other is floating point. >>>>> I don't know if that will work, but maybe. >>>>> >>>>> Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or >>>>> store volatile. >>>>> >>>>> - Jay >>>>> >>>> >>> >> > From jay.krell at cornell.edu Tue Jul 6 00:50:38 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 22:50:38 +0000 Subject: [M3devel] loophole/copysign In-Reply-To: References: , , <3267416E-1152-4A3D-A4C0-491F2C5FF74D@cs.purdue.edu>, , <6BF4E7E7-1068-4623-AE86-6687E2B7B385@cs.purdue.edu> , Message-ID: The C trees are much higher level. First, cm3/m3-libs/m3core/src/float/test_copysign.c which is analogous to CopySign, the C code: typedef struct { ??????? unsigned rest : 31; ??????? unsigned sign : 1; } float_t; float copy_sign_f(float from, float to) { ??????? float res = to; ??????? ((float_t*)&res)->sign = ((float_t*)&from)->sign; ??????? return res; } is what we should somehow strive for. It yields a tree with almost everything preserved (typedefs fall out). gcc-4.2 -fdump-tree-all -c test_copysign.c test_copysign.c.003t.original: ;; Function copy_sign_f (copy_sign_f) ;; enabled by -tree-original { ? float res = to; ??? float res = to; ? ((struct float_t *) &res)->sign = ((struct float_t *) &from)->sign; ? return res; } which is nothing like what we produce. We don't have structs/member_refs ever, I believe. To maybe answer your question..well..: int reinterpret(float f) { ? return *(int*)&f; } gcc-4.2 -ftree-dump-all -c 5.c well, the tree is high super high fidelity, nearly indistinguishable from the input C: ;; Function reinterpret (reinterpret) ;; enabled by -tree-original { ? return *(int *) &f; } I think we would produce about the same thing if we went down the non-bitfield path in load or store. You know ... we don't even need to do loophole, but we need to do just one load or one store, with a conversion, instead of storing one way and loading the other. You could imagine parse.c might buffer up one load or store and then if the next instruction is not store or load, just flush it, but if it is store or load, merge them. Well, it depends on what load or store is to of course. ?- Jay ---------------------------------------- > Subject: Re: [M3devel] loophole/copysign > From: hosking at cs.purdue.edu > Date: Mon, 5 Jul 2010 18:27:10 -0400 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > OK, so now I begin to understand. What you are saying is that gcc needs to have a union type capturing the fact that the variable is accessed using 2 different types. What happens in C code where you cast a memory location from one type to another? How does gcc cope with that? Presumably it gets some sort of type aliasing information? > > On 5 Jul 2010, at 17:42, Jay K wrote: > > > > > CastExpr.m3 has precious few calls to CG.Loophole, including none for this case. > > cm3cg -y output for m3core/LongReal.mc CopySign has no calls to loophole. > > We store into a local as one type and read it back as another type. > > > > - Jay > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Mon, 5 Jul 2010 17:33:43 -0400 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] loophole/copysign > >> > >> Surely we should instead give it the type conversion from what was stored to what is loaded. Can you point me at the problem code in CastExpr? > >> > >> On 5 Jul 2010, at 16:44, Jay K wrote: > >> > >>> > >>> I don't think a barrier worked. > >>> The thing is, I don't think a change in parse.c alone can work. It isn't being given enough information. > >>> Or, well, it does have enough information, but, like, it is information it never uses. > >>> It has some type information. It would have to notice that the most recent store to a variable was > >>> of a different type than a load. > >>> > >>> - Jay > >>> > >>> > >>> > >>> ---------------------------------------- > >>>> Subject: Re: [M3devel] loophole/copysign > >>>> From: hosking at cs.purdue.edu > >>>> Date: Mon, 5 Jul 2010 14:24:01 -0400 > >>>> CC: m3devel at elegosoft.com > >>>> To: jay.krell at cornell.edu > >>>> > >>>> We shouldn't need a barrier here. That is for memory operations, whereas these need not be. I would hate to make this change. Why can't we produce gcc trees that accomplish what we need? > >>>> > >>>> On 5 Jul 2010, at 05:24, Jay K wrote: > >>>> > >>>>> > >>>>> Our codegen is remarkably low level. That is, lower level earlier than C. > >>>>> > >>>>> > >>>>> gcc/m3cg -ftree-dump-all > >>>>> > >>>>> > >>>>> As early as LongFloat.mc.003t.original, the first file dumped, we have: > >>>>> > >>>>> LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) > >>>>> { > >>>>> xreel M3_CtKayy__result; > >>>>> xreel M3_CtKayy_res; > >>>>> > >>>>> xreel M3_CtKayy__result; > >>>>> xreel M3_CtKayy_res; > >>>>> M3_CtKayy_res = M3_CtKayy_x; > >>>>> BIT_FIELD_REF = (word_8) ((int_64) > >>>>> BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); > >>>>> = M3_CtKayy_res; > >>>>> return ; > >>>>> } > >>>>> > >>>>> compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: > >>>>> > >>>>> copy_sign_f (from, to) > >>>>> { > >>>>> float res; > >>>>> float D.1918; > >>>>> D.1917; > >>>>> struct float_t * from.1; > >>>>> struct float_t * res.0; > >>>>> > >>>>> : > >>>>> res = to_1; > >>>>> res.0_4 = (struct float_t *) &res; > >>>>> from.1_5 = (struct float_t *) &from; > >>>>> D.1917_6 = from.1_5->sign; > >>>>> res.0_4->sign = D.1917_6; > >>>>> D.1918_7 = res; > >>>>> return D.1918_7; > >>>>> > >>>>> } > >>>>> > >>>>> > >>>>> See, you know, from gcc's point of view, we don't have any records/structs/unions. > >>>>> Just integers and offsets from them mostly. > >>>>> > >>>>> > >>>>> The right fix is to build up types. > >>>>> That way also debugging with gdb will have a chance. > >>>>> Perhaps not a small amount of work. But maybe not too bad. > >>>>> > >>>>> > >>>>> For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. > >>>>> At least if one type but not the other is floating point. > >>>>> I don't know if that will work, but maybe. > >>>>> > >>>>> Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or > >>>>> store volatile. > >>>>> > >>>>> - Jay > >>>>> > >>>> > >>> > >> > > > From jay.krell at cornell.edu Tue Jul 6 01:06:29 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 23:06:29 +0000 Subject: [M3devel] loophole/copysign In-Reply-To: References: , , <3267416E-1152-4A3D-A4C0-491F2C5FF74D@cs.purdue.edu>, , <6BF4E7E7-1068-4623-AE86-6687E2B7B385@cs.purdue.edu>, , , Message-ID: I'm not sure we need to be too fancy: not sure we need a union. I think merely taking the address and casting and derefing it might suffice. For aliasing we just always return 0, so presumably..any pointers are pessimistic. The alias information seems to be that any "decl" could be a variable, or a type..is in a "set". Sets are integer indices into an array of sets. Same integer => same set. But I think that we just return 0 all the time makes these easy and adequate. Could be better. But probably ok. Perhaps the better way would be: ? if file uses loophole anywhere, same as today ?? loophole in the front end or backend ?if file doesn't use loophole, we can probably at least put every? type in its own set? ? Er, not exactly: not subranges enums integers. ? But still probably some easy stuff? ?Anyway, just having everything in the same alias set should be ok for now. ?We're still digging out of a big hole: volatile everywhere.. no unit at a time.. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] loophole/copysign > Date: Mon, 5 Jul 2010 22:50:38 +0000 > > > The C trees are much higher level. > > First, cm3/m3-libs/m3core/src/float/test_copysign.c which is analogous to CopySign, the C code: > > typedef struct { > unsigned rest : 31; > unsigned sign : 1; > } float_t; > > float copy_sign_f(float from, float to) > { > float res = to; > ((float_t*)&res)->sign = ((float_t*)&from)->sign; > return res; > } > > is what we should somehow strive for. > > It yields a tree with almost everything preserved (typedefs fall out). > gcc-4.2 -fdump-tree-all -c test_copysign.c > > test_copysign.c.003t.original: > > ;; Function copy_sign_f (copy_sign_f) > ;; enabled by -tree-original > > { > float res = to; > > float res = to; > ((struct float_t *) &res)->sign = ((struct float_t *) &from)->sign; > return res; > } > > which is nothing like what we produce. > We don't have structs/member_refs ever, I believe. > > > To maybe answer your question..well..: > > int reinterpret(float f) > { > return *(int*)&f; > } > > gcc-4.2 -ftree-dump-all -c 5.c well, the tree is high super high fidelity, nearly > indistinguishable from the input C: > > > ;; Function reinterpret (reinterpret) > ;; enabled by -tree-original > { > return *(int *) &f; > } > > > I think we would produce about the same thing if we went down the non-bitfield path in load or store. > You know ... we don't even need to do loophole, but we need to do just one load or one store, with a conversion, > instead of storing one way and loading the other. > > > You could imagine parse.c might buffer up one load or store and then if the next instruction is not store or load, just flush it, > but if it is store or load, merge them. Well, it depends on what load or store is to of course. > > > - Jay > > ---------------------------------------- > > Subject: Re: [M3devel] loophole/copysign > > From: hosking at cs.purdue.edu > > Date: Mon, 5 Jul 2010 18:27:10 -0400 > > CC: m3devel at elegosoft.com > > To: jay.krell at cornell.edu > > > > OK, so now I begin to understand. What you are saying is that gcc needs to have a union type capturing the fact that the variable is accessed using 2 different types. What happens in C code where you cast a memory location from one type to another? How does gcc cope with that? Presumably it gets some sort of type aliasing information? > > > > On 5 Jul 2010, at 17:42, Jay K wrote: > > > > > > > > CastExpr.m3 has precious few calls to CG.Loophole, including none for this case. > > > cm3cg -y output for m3core/LongReal.mc CopySign has no calls to loophole. > > > We store into a local as one type and read it back as another type. > > > > > > - Jay > > > > > > ---------------------------------------- > > >> From: hosking at cs.purdue.edu > > >> Date: Mon, 5 Jul 2010 17:33:43 -0400 > > >> To: jay.krell at cornell.edu > > >> CC: m3devel at elegosoft.com > > >> Subject: Re: [M3devel] loophole/copysign > > >> > > >> Surely we should instead give it the type conversion from what was stored to what is loaded. Can you point me at the problem code in CastExpr? > > >> > > >> On 5 Jul 2010, at 16:44, Jay K wrote: > > >> > > >>> > > >>> I don't think a barrier worked. > > >>> The thing is, I don't think a change in parse.c alone can work. It isn't being given enough information. > > >>> Or, well, it does have enough information, but, like, it is information it never uses. > > >>> It has some type information. It would have to notice that the most recent store to a variable was > > >>> of a different type than a load. > > >>> > > >>> - Jay > > >>> > > >>> > > >>> > > >>> ---------------------------------------- > > >>>> Subject: Re: [M3devel] loophole/copysign > > >>>> From: hosking at cs.purdue.edu > > >>>> Date: Mon, 5 Jul 2010 14:24:01 -0400 > > >>>> CC: m3devel at elegosoft.com > > >>>> To: jay.krell at cornell.edu > > >>>> > > >>>> We shouldn't need a barrier here. That is for memory operations, whereas these need not be. I would hate to make this change. Why can't we produce gcc trees that accomplish what we need? > > >>>> > > >>>> On 5 Jul 2010, at 05:24, Jay K wrote: > > >>>> > > >>>>> > > >>>>> Our codegen is remarkably low level. That is, lower level earlier than C. > > >>>>> > > >>>>> > > >>>>> gcc/m3cg -ftree-dump-all > > >>>>> > > >>>>> > > >>>>> As early as LongFloat.mc.003t.original, the first file dumped, we have: > > >>>>> > > >>>>> LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) > > >>>>> { > > >>>>> xreel M3_CtKayy__result; > > >>>>> xreel M3_CtKayy_res; > > >>>>> > > >>>>> xreel M3_CtKayy__result; > > >>>>> xreel M3_CtKayy_res; > > >>>>> M3_CtKayy_res = M3_CtKayy_x; > > >>>>> BIT_FIELD_REF = (word_8) ((int_64) > > >>>>> BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); > > >>>>> = M3_CtKayy_res; > > >>>>> return ; > > >>>>> } > > >>>>> > > >>>>> compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: > > >>>>> > > >>>>> copy_sign_f (from, to) > > >>>>> { > > >>>>> float res; > > >>>>> float D.1918; > > >>>>> D.1917; > > >>>>> struct float_t * from.1; > > >>>>> struct float_t * res.0; > > >>>>> > > >>>>> : > > >>>>> res = to_1; > > >>>>> res.0_4 = (struct float_t *) &res; > > >>>>> from.1_5 = (struct float_t *) &from; > > >>>>> D.1917_6 = from.1_5->sign; > > >>>>> res.0_4->sign = D.1917_6; > > >>>>> D.1918_7 = res; > > >>>>> return D.1918_7; > > >>>>> > > >>>>> } > > >>>>> > > >>>>> > > >>>>> See, you know, from gcc's point of view, we don't have any records/structs/unions. > > >>>>> Just integers and offsets from them mostly. > > >>>>> > > >>>>> > > >>>>> The right fix is to build up types. > > >>>>> That way also debugging with gdb will have a chance. > > >>>>> Perhaps not a small amount of work. But maybe not too bad. > > >>>>> > > >>>>> > > >>>>> For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. > > >>>>> At least if one type but not the other is floating point. > > >>>>> I don't know if that will work, but maybe. > > >>>>> > > >>>>> Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or > > >>>>> store volatile. > > >>>>> > > >>>>> - Jay > > >>>>> > > >>>> > > >>> > > >> > > > > > > From mika at async.async.caltech.edu Tue Jul 6 07:58:33 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Mon, 05 Jul 2010 22:58:33 -0700 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20100705132228.0E6D52474003@birch.elegosoft.com>, <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu>, , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu>, , <6331F39C-AA28-4AC1-8C87-3D47D52D0C55@cs.purdue.edu>, , <02F12035-7271-4004-BE67-3DAB17C37B3B@cs.purdue.edu> Message-ID: <20100706055833.118D21A2080@async.async.caltech.edu> As I've said before, When I write: VAR a : INTEGER; BEGIN ... .... a := .. ... ... END that means I am putting you, the reader, on notice that I have no particularly meaningful idea of what a's initial value is. If I were to write VAR a := 0; BEGIN ... END I would mislead you into thinking that 0 is a somehow important initial value. Which it's not. It's just garbage, and it better not show up in the computation! Programs are mainly meant to be read by humans, not computers. Mika Jay K writes: >--_d2468f3b-9666-4291-98b5-5414421f54d9_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >We are going in circles. From jay.krell at cornell.edu Tue Jul 6 08:22:50 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Jul 2010 06:22:50 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20100706055833.118D21A2080@async.async.caltech.edu> References: <20100705132228.0E6D52474003@birch.elegosoft.com>, , <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , , , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu>, , , , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu>, , , , <6331F39C-AA28-4AC1-8C87-3D47D52D0C55@cs.purdue.edu>, , , , <02F12035-7271-4004-BE67-3DAB17C37B3B@cs.purdue.edu>, , <20100706055833.118D21A2080@async.async.caltech.edu> Message-ID: Programmers are notorious for making mistakes. When you write VAR a:INTEGER; you make the human proofreading your code have to work much harder to do the data/control flow analysis to make sure you didn't use the uninitialized value. Using the a := 0 value might still be "wrong", but is it at least consistent and the penalty for getting it wrong is generally less severe. Now, I don't want there to be a bug either way, but I feel that a consistent 0 is much "safer" than uninitialized. Either is typesafe, sure, but type safe is just the bare minimum expectation for my code. It must not only be type safe, but act correctly. Again, compiler isn't generally a program proofer, but the little it can do, let it do. Here is how I write C code: void function_with_two_temporary_buffers() { ? void* p = { 0 }; ? void* q = { 0 }; ? if (!(p = malloc(...))) ??? goto exit; ? if (!(q = malloc(...))) ??? goto exit; ... exit: ?? free(p); ?? free(q); } or void function_that_returns_two_buffers(void** a, void** b) { ? void* p = { 0 }; ? void* q = { 0 }; ? ? *a = p; ? *b = q; ? if (!(p = malloc(...)) ?? goto Exit; ? if (!(q = malloc(...)) ?? goto Exit; ??? .... ? *a = p; ?? p = 0; ?? *b = q; ?? q = 0; Exit: ? free(p); ? free(q); } In reality malloc is generally a function that returns an integer, negative for success. So it is more like: #define CHECK(expr) do { if ((status = (expr)) < 0) goto Exit; } while(0) ? CHECK(MemoryAlloc(..., &q)); See, the style is written to be easy for a human to verify the correctness of. Locals are always initialized. Ownership of resources is always clear. This is contrast with other styles: ?if (p = malloc(...)) ? { ????? ... ???? if (q = malloc(...)) ??? { ???????? ... ??????? free(q); ??? } ?? free(p); } where one has to follow the ever further indented blob of ifs. It doesn't scale. Every resource allocation makes the code incrementally harder for a human to read. Whereas the style that includes initializing all locals has no such incremental cost. (And this hard to read style is in fact somewhat encouraged by the "with" feature of Modula-3. C++'s equivalent -- declaring variables anywhere -- doesn't suggest ever increasing indentation. ) ?- Jay ---------------------------------------- > To: jay.krell at cornell.edu > Date: Mon, 5 Jul 2010 22:58:33 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > As I've said before, > > When I write: > > VAR > a : INTEGER; > BEGIN > > ... > > .... a := .. ... > > ... > > END > > that means I am putting you, the reader, on notice that I have no > particularly meaningful idea of what a's initial value is. > > If I were to write > > VAR > a := 0; > BEGIN > ... > END > > I would mislead you into thinking that 0 is a somehow important > initial value. Which it's not. It's just garbage, and it better > not show up in the computation! > > Programs are mainly meant to be read by humans, not computers. > > Mika > > > Jay K writes: > >--_d2468f3b-9666-4291-98b5-5414421f54d9_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >We are going in circles. From mika at async.async.caltech.edu Tue Jul 6 08:34:58 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Mon, 05 Jul 2010 23:34:58 -0700 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20100705132228.0E6D52474003@birch.elegosoft.com>, , <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , , , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu>, , , , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu>, , , , <6331F39C-AA28-4AC1-8C87-3D47D52D0C55@cs.purdue.edu>, , , , <02F12035-7271-4004-BE67-3DAB17C37B3B@cs.purdue.edu>, , <20100706055833.118D21A2080@async.async.caltech.edu> Message-ID: <20100706063458.DCFF41A2080@async.async.caltech.edu> Jay, I agree with the general premise that splitting declaration and initialization is bad coding style. I use WITH or the initialization of a procedure entry as much as possible to declare my variables. And if they have to change during the course of their lifetime, I do try to initialize them in the VAR. But... you're wrong :-) Imagine you have a variable whose initial value (i.e., the value it has before the first time it is used) is critical for the correctness of your algorithm. The initial value depends on something else, something that has to be computed. In this case, which does happen, at least in my code, there is no static value that is better than any other. VAR x : INTEGER; BEGIN is the right way to code that. VAR x := 0; BEGIN accomplishes exactly one thing: it obfuscates the code---it misleads the reader into thinking that x=0 is somehow relevant to the code, without adding anything at all to its correctness. As I said, the declaration that isn't initialized is to be used *sparingly* and whenever it is used it should be a giant red flag to the reader that the variable x is going to be initialized with a value that the programmer doesn't know at the time of declaration. What on earth do you gain from x := 0? A "little correctness"? Mika Jay K writes: > >Programmers are notorious for making mistakes. > > >When you write VAR a:INTEGER=3B >you make the human proofreading your code have to work much harder >to do the data/control flow analysis to make sure you didn't >use the uninitialized value. > > >Using the a :=3D 0 value might still be "wrong"=2C but is it at least consi= >stent >and the penalty for getting it wrong is generally less severe. > >Now=2C I don't want there to be a bug either way=2C but I feel that a consi= >stent 0 is much "safer" >than uninitialized. Either is typesafe=2C sure=2C but type safe is just the= > bare minimum expectation >for my code. It must not only be type safe=2C but act correctly. > >Again=2C compiler isn't generally a program proofer=2C but the little it ca= >n do=2C let it do. > > > >Here is how I write C code: > >void function_with_two_temporary_buffers() >{ >=A0 void* p =3D { 0 }=3B >=A0 void* q =3D { 0 }=3B > >=A0 if (!(p =3D malloc(...))) >=A0=A0=A0 goto exit=3B > >=A0 if (!(q =3D malloc(...))) > >=A0=A0=A0 goto exit=3B > > > >... > >exit: >=A0=A0 free(p)=3B >=A0=A0 free(q)=3B >} > >or >void function_that_returns_two_buffers(void** a=2C void** b) >{ >=A0 void* p =3D { 0 }=3B >=A0 void* q =3D { 0 }=3B >=A0=20 >=A0 *a =3D p=3B >=A0 *b =3D q=3B > >=A0 if (!(p =3D malloc(...)) >=A0=A0 goto Exit=3B > >=A0 if (!(q =3D malloc(...)) > >=A0=A0 goto Exit=3B > > > >=A0=A0=A0 .... >=A0 *a =3D p=3B >=A0=A0 p =3D 0=3B >=A0=A0 *b =3D q=3B >=A0=A0 q =3D 0=3B > >Exit:=20 >=A0 free(p)=3B >=A0 free(q)=3B > >} > >In reality malloc is generally a function that returns an integer=2C negati= >ve for success. >So it is more like: >#define CHECK(expr) do { if ((status =3D (expr)) < 0) goto Exit=3B } while(= >0) > > >=A0 CHECK(MemoryAlloc(...=2C &q))=3B > >See=2C the style is written to be easy for a human to verify the correctnes= >s of. >Locals are always initialized. Ownership of resources is always clear. > >This is contrast with other styles: > >=A0if (p =3D malloc(...)) >=A0 { >=A0=A0=A0=A0=A0 ... >=A0=A0=A0=A0 if (q =3D malloc(...)) >=A0=A0=A0 { >=A0=A0=A0=A0=A0=A0=A0=A0 ... >=A0=A0=A0=A0=A0=A0=A0 free(q)=3B >=A0=A0=A0 } >=A0=A0 free(p)=3B >} > >where one has to follow the ever further indented blob of ifs. >It doesn't scale. Every resource allocation makes the code incrementally ha= >rder for a human to read. >Whereas the style that includes initializing all locals has no such increme= >ntal cost. > >(And this hard to read style is in fact somewhat encouraged by the "with" f= >eature of Modula-3. >C++'s equivalent -- declaring variables anywhere -- doesn't suggest ever in= >creasing indentation. >) > > >=A0- Jay > > > >---------------------------------------- >> To: jay.krell at cornell.edu >> Date: Mon=2C 5 Jul 2010 22:58:33 -0700 >> From: mika at async.async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] [M3commit] CVS Update: cm3 >> >> >> As I've said before=2C >> >> When I write: >> >> VAR >> a : INTEGER=3B >> BEGIN >> >> ... >> >> .... a :=3D .. ... >> >> ... >> >> END >> >> that means I am putting you=2C the reader=2C on notice that I have no >> particularly meaningful idea of what a's initial value is. >> >> If I were to write >> >> VAR >> a :=3D 0=3B >> BEGIN >> ... >> END >> >> I would mislead you into thinking that 0 is a somehow important >> initial value. Which it's not. It's just garbage=2C and it better >> not show up in the computation! >> >> Programs are mainly meant to be read by humans=2C not computers. >> >> Mika >> >> >> Jay K writes: >> >--_d2468f3b-9666-4291-98b5-5414421f54d9_ >> >Content-Type: text/plain=3B charset=3D"iso-8859-1" >> >Content-Transfer-Encoding: quoted-printable >> > >> > >> >We are going in circles. > = From mika at async.async.caltech.edu Tue Jul 6 08:35:47 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Mon, 05 Jul 2010 23:35:47 -0700 Subject: [M3devel] [M3commit] CVS Update: cm3 Message-ID: <20100706063547.81FC21A2080@async.async.caltech.edu> >When you write VAR a:INTEGER=3B >you make the human proofreading your code have to work much harder >to do the data/control flow analysis to make sure you didn't >use the uninitialized value. And yes, that's precisely the point! From jay.krell at cornell.edu Tue Jul 6 12:05:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Jul 2010 10:05:43 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20100706063458.DCFF41A2080@async.async.caltech.edu> References: <20100705132228.0E6D52474003@birch.elegosoft.com>, , <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , , , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu>, , , , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu>, , , , <6331F39C-AA28-4AC1-8C87-3D47D52D0C55@cs.purdue.edu>, , , , <02F12035-7271-4004-BE67-3DAB17C37B3B@cs.purdue.edu>, , <20100706055833.118D21A2080@async.async.caltech.edu> , <20100706063458.DCFF41A2080@async.async.caltech.edu> Message-ID: > used it should be a giant red flag to the reader that the variable x is > going to be initialized with a value that the programmer doesn't know > at the time of declaration. What on earth do you gain from x := 0? > A "little correctness"? You are making the code more expensive to maintain, by making it harder for a human to analyze. For the benefit of microoptimization. ?- Jay ---------------------------------------- > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > Date: Mon, 5 Jul 2010 23:34:58 -0700 > From: mika at async.async.caltech.edu > > > Jay, I agree with the general premise that splitting declaration and > initialization is bad coding style. I use WITH or the initialization > of a procedure entry as much as possible to declare my variables. > And if they have to change during the course of their lifetime, > I do try to initialize them in the VAR. > > But... you're wrong :-) > > Imagine you have a variable whose initial value (i.e., the value it has > before the first time it is used) is critical for the correctness of > your algorithm. The initial value depends on something else, something > that has to be computed. In this case, which does happen, at least > in my code, there is no static value that is better than any other. > VAR x : INTEGER; BEGIN is the right way to code that. VAR x := 0; BEGIN > accomplishes exactly one thing: it obfuscates the code---it misleads the > reader into thinking that x=0 is somehow relevant to the code, without > adding anything at all to its correctness. As I said, the declaration > that isn't initialized is to be used *sparingly* and whenever it is > used it should be a giant red flag to the reader that the variable x is > going to be initialized with a value that the programmer doesn't know > at the time of declaration. What on earth do you gain from x := 0? > A "little correctness"? > > Mika > > Jay K writes: > > > >Programmers are notorious for making mistakes. > > > > > >When you write VAR a:INTEGER=3B > >you make the human proofreading your code have to work much harder > >to do the data/control flow analysis to make sure you didn't > >use the uninitialized value. > > > > > >Using the a :=3D 0 value might still be "wrong"=2C but is it at least consi= > >stent > >and the penalty for getting it wrong is generally less severe. > > > >Now=2C I don't want there to be a bug either way=2C but I feel that a consi= > >stent 0 is much "safer" > >than uninitialized. Either is typesafe=2C sure=2C but type safe is just the= > > bare minimum expectation > >for my code. It must not only be type safe=2C but act correctly. > > > >Again=2C compiler isn't generally a program proofer=2C but the little it ca= > >n do=2C let it do. > > > > > > > >Here is how I write C code: > > > >void function_with_two_temporary_buffers() > >{ > >=A0 void* p =3D { 0 }=3B > >=A0 void* q =3D { 0 }=3B > > > >=A0 if (!(p =3D malloc(...))) > >=A0=A0=A0 goto exit=3B > > > >=A0 if (!(q =3D malloc(...))) > > > >=A0=A0=A0 goto exit=3B > > > > > > > >... > > > >exit: > >=A0=A0 free(p)=3B > >=A0=A0 free(q)=3B > >} > > > >or > >void function_that_returns_two_buffers(void** a=2C void** b) > >{ > >=A0 void* p =3D { 0 }=3B > >=A0 void* q =3D { 0 }=3B > >=A0=20 > >=A0 *a =3D p=3B > >=A0 *b =3D q=3B > > > >=A0 if (!(p =3D malloc(...)) > >=A0=A0 goto Exit=3B > > > >=A0 if (!(q =3D malloc(...)) > > > >=A0=A0 goto Exit=3B > > > > > > > >=A0=A0=A0 .... > >=A0 *a =3D p=3B > >=A0=A0 p =3D 0=3B > >=A0=A0 *b =3D q=3B > >=A0=A0 q =3D 0=3B > > > >Exit:=20 > >=A0 free(p)=3B > >=A0 free(q)=3B > > > >} > > > >In reality malloc is generally a function that returns an integer=2C negati= > >ve for success. > >So it is more like: > >#define CHECK(expr) do { if ((status =3D (expr)) < 0) goto Exit=3B } while(= > >0) > > > > > >=A0 CHECK(MemoryAlloc(...=2C &q))=3B > > > >See=2C the style is written to be easy for a human to verify the correctnes= > >s of. > >Locals are always initialized. Ownership of resources is always clear. > > > >This is contrast with other styles: > > > >=A0if (p =3D malloc(...)) > >=A0 { > >=A0=A0=A0=A0=A0 ... > >=A0=A0=A0=A0 if (q =3D malloc(...)) > >=A0=A0=A0 { > >=A0=A0=A0=A0=A0=A0=A0=A0 ... > >=A0=A0=A0=A0=A0=A0=A0 free(q)=3B > >=A0=A0=A0 } > >=A0=A0 free(p)=3B > >} > > > >where one has to follow the ever further indented blob of ifs. > >It doesn't scale. Every resource allocation makes the code incrementally ha= > >rder for a human to read. > >Whereas the style that includes initializing all locals has no such increme= > >ntal cost. > > > >(And this hard to read style is in fact somewhat encouraged by the "with" f= > >eature of Modula-3. > >C++'s equivalent -- declaring variables anywhere -- doesn't suggest ever in= > >creasing indentation. > >) > > > > > >=A0- Jay > > > > > > > >---------------------------------------- > >> To: jay.krell at cornell.edu > >> Date: Mon=2C 5 Jul 2010 22:58:33 -0700 > >> From: mika at async.async.caltech.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > >> > >> > >> As I've said before=2C > >> > >> When I write: > >> > >> VAR > >> a : INTEGER=3B > >> BEGIN > >> > >> ... > >> > >> .... a :=3D .. ... > >> > >> ... > >> > >> END > >> > >> that means I am putting you=2C the reader=2C on notice that I have no > >> particularly meaningful idea of what a's initial value is. > >> > >> If I were to write > >> > >> VAR > >> a :=3D 0=3B > >> BEGIN > >> ... > >> END > >> > >> I would mislead you into thinking that 0 is a somehow important > >> initial value. Which it's not. It's just garbage=2C and it better > >> not show up in the computation! > >> > >> Programs are mainly meant to be read by humans=2C not computers. > >> > >> Mika > >> > >> > >> Jay K writes: > >> >--_d2468f3b-9666-4291-98b5-5414421f54d9_ > >> >Content-Type: text/plain=3B charset=3D"iso-8859-1" > >> >Content-Transfer-Encoding: quoted-printable > >> > > >> > > >> >We are going in circles. > > = From jay.krell at cornell.edu Tue Jul 6 12:08:30 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Jul 2010 10:08:30 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20100706063547.81FC21A2080@async.async.caltech.edu> References: <20100706063547.81FC21A2080@async.async.caltech.edu> Message-ID: ---------------------------------------- > To: jay > CC: m3devel > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > Date: Mon, 5 Jul 2010 23:35:47 -0700 > From: mikau > > >When you write VAR a:INTEGER=3B > >you make the human proofreading your code have to work much harder > >to do the data/control flow analysis to make sure you didn't > >use the uninitialized value. > > And yes, that's precisely the point! You are just adding to the maintenance cost of the code. If something makes it much more difficult to analyze by a human, and doesn't provide much benefit, don't do it. Esp. when a large fraction of the time, the compiler with far more cycles to burn, will be able to make the micro optimization. And another fraction of the time, the computer running the program will have plenty of cycles. ?(granted, the code is larger, and disk cycles are scarce). ?- Jay From jay.krell at cornell.edu Tue Jul 6 14:28:34 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Jul 2010 12:28:34 +0000 Subject: [M3devel] yet another proposed fix.. careful insertion of one instance of CG.Force() in CastExpr.m3 Message-ID: Ok, this is interesting. I think. Finally. I need to test more, but it is looking very promising. I think you'll like it (Tony). I still don't understand all the flow around the front end. I had to try out some guesses. It certainly appears that m3front/src/misc/CG.m3 is in the business of optimizations. This change might actually be too conservative. It defeats optimization in CG.m3. It limits it to D_to_S when one type is float and the other isn't. ?I guess S (struct) can't really be float. The assertion failure in gcc btw, was gcc_assert( something_is_float == other_is_float). So the conservativeness is somewhat sensible. Limiting it to D_to_S, though, unclear. The change is just inserting CG.Force(). OK? (Let me test a bit more -- build the entire tree.) This appears to let me leave "ter" on. I can try leaving other optimizations on. Index: exprs/CastExpr.m3 =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/CastExpr.m3,v retrieving revision 1.9 diff -u -r1.9 CastExpr.m3 --- exprs/CastExpr.m3??? 5 Jul 2010 11:28:32 -0000??? 1.9 +++ exprs/CastExpr.m3??? 6 Jul 2010 12:23:14 -0000 @@ -10,6 +10,7 @@ ? ?IMPORT M3Buf, CG, Expr, ExprRep, Type, Error, OpenArrayType; ?IMPORT M3, M3ID, M3RT, Target, TInt; +FROM Target IMPORT FloatType; ? ?TYPE ?? Kind = { @@ -394,7 +395,7 @@ ???? u? := Expr.TypeOf (e); ???? t? := p.tipe; ???? sz, t_align, u_align, z_align: INTEGER; -??? u_cg: CG.Type; +??? u_cg, t_cg: CG.Type; ???? u_info, t_info: Type.Info; ?? BEGIN ???? u := Type.CheckInfo (u, u_info); @@ -403,6 +404,7 @@ ???? u_align := u_info.alignment; ???? z_align := MAX (t_align, u_align); ???? u_cg := u_info.stk_type; +??? t_cg := t_info.stk_type; ???? sz := u_info.size; ???? Type.Compile (t); ???? Type.Compile (u); @@ -416,6 +418,15 @@ ?????? Kind.V_to_V => ???????? Expr.CompileLValue (p.expr, traced); ???????? CG.Boost_alignment (t_align); +(* Inhibit some optimization that causes compilation to fail. e.g. m3core: +../src/float/IEEE/RealFloat.m3: In function 'RealFloat__CopySign': +../src/float/IEEE/RealFloat.m3:96: internal compiler error: in convert_move, at expr.c:371 +../src/float/IEEE/LongFloat.m3: In function 'LongFloat__CopySign': +../src/float/IEEE/LongFloat.m3:116: internal compiler error: in convert_move, at expr.c:371 +*) +??????? IF p.kind = Kind.D_to_S AND FloatType[u_cg] # FloatType[t_cg] THEN +????????? CG.Force (); +??????? END; ? ???? | Kind.D_to_A, ?????? Kind.S_to_A, (577) begin_procedure ? procedure LongFloat__CopySign ?LongFloat__CopySign(578) set_source_line ? source line? 117 (579) load ? type:lreal ? type:lreal ? m3cg_load (M3_CtKayy_x): offset 0x0, convert lreal -> lreal (580) store ? type:lreal ? type:lreal ? store (M3_CtKayy_res) offset:0x0 src_t:lreal dst_t:lreal (581) set_source_line ? source line? 119 now notice we have use of load_address and load_indirect here, where before we had no address and load (direct) (582) load_address ? load address (M3_CtKayy_res) offset 0x0 (583) load_address ? load address (M3_CtKayy_y) offset 0x0 (584) load_indirect ? type:word8 ? type:int64 ? load address offset:0x38 src_t:word8 dst_t:int64 (585) extract_mn ? type:int64 ?extract_mn offset:7 count:1 sign_extend:0 (586) swap ? type:addr ? type:int64 (587) declare_temp ? type:addr ? temp var type:addr size:0x40 alignment:0x40 (588) store ? type:addr ? type:addr ? store (noname) offset:0x0 src_t:addr dst_t:addr (589) load ? type:addr ? type:addr ? m3cg_load (noname): offset 0x0, convert addr -> addr (590) load_indirect ? type:word8 ? type:int64 ? load address offset:0x38 src_t:word8 dst_t:int64 (591) swap ? type:int64 ? type:word8 (592) insert_mn ? type:int64 ?insert_mn offset:7 count:1 (593) load ? type:addr ? type:addr ? m3cg_load (noname): offset 0x0, convert addr -> addr (594) swap ? type:word8 ? type:addr (595) store_indirect ? type:int64 ? type:word8 ? store indirect offset:0x38 src_t:int64 dst_t:word8 (596) set_source_line ? source line? 120 (597) load ? type:lreal ? type:lreal ? m3cg_load (M3_CtKayy_res): offset 0x0, convert lreal -> lreal (598) exit_proc ? type:lreal (599) free_temp (600) end_procedure ? procedure LongFloat__CopySign ?- Jay From hosking at cs.purdue.edu Tue Jul 6 15:50:33 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 6 Jul 2010 09:50:33 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20100706055833.118D21A2080@async.async.caltech.edu> References: <20100705132228.0E6D52474003@birch.elegosoft.com>, <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu>, , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu>, , <6331F39C-AA28-4AC1-8C87-3D47D52D0C55@cs.purdue.edu>, , <02F12035-7271-4004-BE67-3DAB17C37B3B@cs.purdue.edu> <20100706055833.118D21A2080@async.async.caltech.edu> Message-ID: Thanks Mika, That's what I was hoping to express but I was too tired. I don't think we can convince Jay, but I do want him to understand at least that there is strong resistance to his desire to add all of these value initialisers, and that it really is not a priority. On 6 Jul 2010, at 01:58, Mika Nystrom wrote: > > As I've said before, > > When I write: > > VAR > a : INTEGER; > BEGIN > > ... > > .... a := .. ... > > ... > > END > > that means I am putting you, the reader, on notice that I have no > particularly meaningful idea of what a's initial value is. > > If I were to write > > VAR > a := 0; > BEGIN > ... > END > > I would mislead you into thinking that 0 is a somehow important > initial value. Which it's not. It's just garbage, and it better > not show up in the computation! > > Programs are mainly meant to be read by humans, not computers. > > Mika > > > Jay K writes: >> --_d2468f3b-9666-4291-98b5-5414421f54d9_ >> Content-Type: text/plain; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> >> We are going in circles. From hosking at cs.purdue.edu Tue Jul 6 15:58:19 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 6 Jul 2010 09:58:19 -0400 Subject: [M3devel] yet another proposed fix.. careful insertion of one instance of CG.Force() in CastExpr.m3 In-Reply-To: References: Message-ID: <0FABE0B5-71CE-49F8-BD07-688EA9DC1C17@cs.purdue.edu> I wonder if we should be forcing all D_to_S? Is it really only floats that cause this problem? Why would that be the case? On 6 Jul 2010, at 08:28, Jay K wrote: > > Ok, this is interesting. I think. Finally. > I need to test more, but it is looking very promising. I think you'll like it (Tony). > I still don't understand all the flow around the front end. I had to try out some guesses. > It certainly appears that m3front/src/misc/CG.m3 is in the business of optimizations. > This change might actually be too conservative. > It defeats optimization in CG.m3. It limits it to D_to_S when one type is float and the other isn't. > I guess S (struct) can't really be float. > > > The assertion failure in gcc btw, was gcc_assert( something_is_float == other_is_float). > So the conservativeness is somewhat sensible. > Limiting it to D_to_S, though, unclear. > > > The change is just inserting CG.Force(). > > > OK? (Let me test a bit more -- build the entire tree.) > > This appears to let me leave "ter" on. > I can try leaving other optimizations on. > > > Index: exprs/CastExpr.m3 > =================================================================== > RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/CastExpr.m3,v > retrieving revision 1.9 > diff -u -r1.9 CastExpr.m3 > --- exprs/CastExpr.m3 5 Jul 2010 11:28:32 -0000 1.9 > +++ exprs/CastExpr.m3 6 Jul 2010 12:23:14 -0000 > @@ -10,6 +10,7 @@ > > IMPORT M3Buf, CG, Expr, ExprRep, Type, Error, OpenArrayType; > IMPORT M3, M3ID, M3RT, Target, TInt; > +FROM Target IMPORT FloatType; > > TYPE > Kind = { > @@ -394,7 +395,7 @@ > u := Expr.TypeOf (e); > t := p.tipe; > sz, t_align, u_align, z_align: INTEGER; > - u_cg: CG.Type; > + u_cg, t_cg: CG.Type; > u_info, t_info: Type.Info; > BEGIN > u := Type.CheckInfo (u, u_info); > @@ -403,6 +404,7 @@ > u_align := u_info.alignment; > z_align := MAX (t_align, u_align); > u_cg := u_info.stk_type; > + t_cg := t_info.stk_type; > sz := u_info.size; > Type.Compile (t); > Type.Compile (u); > @@ -416,6 +418,15 @@ > Kind.V_to_V => > Expr.CompileLValue (p.expr, traced); > CG.Boost_alignment (t_align); > +(* Inhibit some optimization that causes compilation to fail. e.g. m3core: > +../src/float/IEEE/RealFloat.m3: In function 'RealFloat__CopySign': > +../src/float/IEEE/RealFloat.m3:96: internal compiler error: in convert_move, at expr.c:371 > +../src/float/IEEE/LongFloat.m3: In function 'LongFloat__CopySign': > +../src/float/IEEE/LongFloat.m3:116: internal compiler error: in convert_move, at expr.c:371 > +*) > + IF p.kind = Kind.D_to_S AND FloatType[u_cg] # FloatType[t_cg] THEN > + CG.Force (); > + END; > > | Kind.D_to_A, > Kind.S_to_A, > > > > (577) begin_procedure > procedure LongFloat__CopySign > LongFloat__CopySign(578) set_source_line > source line 117 > (579) load > type:lreal > type:lreal > m3cg_load (M3_CtKayy_x): offset 0x0, convert lreal -> lreal > (580) store > type:lreal > type:lreal > store (M3_CtKayy_res) offset:0x0 src_t:lreal dst_t:lreal > (581) set_source_line > source line 119 > > > now notice we have use of load_address and load_indirect here, where before we had no address and load (direct) > > > (582) load_address > load address (M3_CtKayy_res) offset 0x0 > (583) load_address > load address (M3_CtKayy_y) offset 0x0 > (584) load_indirect > type:word8 > type:int64 > load address offset:0x38 src_t:word8 dst_t:int64 > (585) extract_mn > type:int64 > extract_mn offset:7 count:1 sign_extend:0 > (586) swap > type:addr > type:int64 > (587) declare_temp > type:addr > temp var type:addr size:0x40 alignment:0x40 > (588) store > type:addr > type:addr > store (noname) offset:0x0 src_t:addr dst_t:addr > (589) load > type:addr > type:addr > m3cg_load (noname): offset 0x0, convert addr -> addr > (590) load_indirect > type:word8 > type:int64 > load address offset:0x38 src_t:word8 dst_t:int64 > (591) swap > type:int64 > type:word8 > (592) insert_mn > type:int64 > insert_mn offset:7 count:1 > (593) load > type:addr > type:addr > m3cg_load (noname): offset 0x0, convert addr -> addr > (594) swap > type:word8 > type:addr > (595) store_indirect > type:int64 > type:word8 > store indirect offset:0x38 src_t:int64 dst_t:word8 > (596) set_source_line > source line 120 > (597) load > type:lreal > type:lreal > m3cg_load (M3_CtKayy_res): offset 0x0, convert lreal -> lreal > (598) exit_proc > type:lreal > (599) free_temp > (600) end_procedure > procedure LongFloat__CopySign > > > > - Jay > > From rodney_bates at lcwb.coop Tue Jul 6 17:11:55 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 06 Jul 2010 10:11:55 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20100706055833.118D21A2080@async.async.caltech.edu> References: <20100705132228.0E6D52474003@birch.elegosoft.com>, <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu>, , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu>, , <6331F39C-AA28-4AC1-8C87-3D47D52D0C55@cs.purdue.edu>, , <02F12035-7271-4004-BE67-3DAB17C37B3B@cs.purdue.edu> <20100706055833.118D21A2080@async.async.caltech.edu> Message-ID: <4C3347BB.3050206@lcwb.coop> Mika Nystrom wrote: > As I've said before, > > When I write: > > VAR > a : INTEGER; > BEGIN > > ... > > .... a := .. ... > > ... > > END > > that means I am putting you, the reader, on notice that I have no > particularly meaningful idea of what a's initial value is. > > If I were to write > > VAR > a := 0; > BEGIN > ... > END > > I would mislead you into thinking that 0 is a somehow important > initial value. Which it's not. It's just garbage, and it better > not show up in the computation! I often write an initialization in a variable declaration that I fully expect will be overwritten before it is used, assuming I don't make a mistake elsewhere. I do this probably more often in field declarations of record and object types than in variables. I do it because it makes bugs more likely to be repeatable. This is at the cost that it may occasionally make a bug go unnoticed altogether because the initial value happens to suppress an obvious symptom. *But*, if it's code I wrote in the last ten years, or maybe fifteen, such initializations always have (* Paranoid. *) or (* Defensive. *) or a similar comment, for exactly Mika's reason. It tells a reader that this value is intended not be algorithmically significant. I suppose one could assume that an implementation of Modula-3 would initialize things consistently, but that relies on something that is not a rule of the language. Moreover, it is very likely not true for a type where all bit patterns represent members of the type. Sometimes I try to pick a really weird value, just so it will be more conspicuous and more likely to trigger a symptom, if it ever gets mistakenly used. This also helps in a debugger just to see if a real algorithmic initialization has ever been reached. For many types, I often reserve a distinct value to mean "unknown" or "meaningless", for some reason or other. Sometimes I even have more than one such special value. > > Programs are mainly meant to be read by humans, not computers. > > Mika > > > Jay K writes: >> --_d2468f3b-9666-4291-98b5-5414421f54d9_ >> Content-Type: text/plain; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> >> We are going in circles. > From hosking at cs.purdue.edu Tue Jul 6 17:45:21 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 6 Jul 2010 11:45:21 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <4C3347BB.3050206@lcwb.coop> References: <20100705132228.0E6D52474003@birch.elegosoft.com>, <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu>, , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu>, , <6331F39C-AA28-4AC1-8C87-3D47D52D0C55@cs.purdue.edu>, , <02F12035-7271-4004-BE67-3DAB17C37B3B@cs.purdue.edu> <20100706055833.118D21A2080@async.async.caltech.edu> <4C3347BB.3050206@lcwb.coop> Message-ID: <0B0BBBE5-3841-48BF-BB4F-E27EBDFBBEEF@cs.purdue.edu> I guess I just don't see the difference between writing: := 0 or := 1234567 or := -1 other than perhaps efficiency. In which case, excepting that you have a *known* initial value, writing: : INTEGER is no less expressive. On 6 Jul 2010, at 11:11, Rodney M. Bates wrote: > > > Mika Nystrom wrote: >> As I've said before, >> When I write: >> VAR a : INTEGER; >> BEGIN >> ... >> .... a := .. ... >> ... >> END >> that means I am putting you, the reader, on notice that I have no >> particularly meaningful idea of what a's initial value is. >> If I were to write VAR a := 0; >> BEGIN >> ... >> END >> I would mislead you into thinking that 0 is a somehow important >> initial value. Which it's not. It's just garbage, and it better >> not show up in the computation! > > I often write an initialization in a variable declaration that I > fully expect will be overwritten before it is used, assuming I > don't make a mistake elsewhere. I do this probably more often > in field declarations of record and object types than in variables. > > I do it because it makes bugs more likely to be repeatable. > This is at the cost that it may occasionally make a bug go > unnoticed altogether because the initial value happens to > suppress an obvious symptom. > > *But*, if it's code I wrote in the last ten years, or > maybe fifteen, such initializations always have (* Paranoid. *) > or (* Defensive. *) or a similar comment, for exactly Mika's > reason. It tells a reader that this value is intended not be > algorithmically significant. > > I suppose one could assume that an implementation of Modula-3 > would initialize things consistently, but that relies on > something that is not a rule of the language. Moreover, it > is very likely not true for a type where all bit patterns > represent members of the type. > > Sometimes I try to pick a really weird value, just so > it will be more conspicuous and more likely to trigger > a symptom, if it ever gets mistakenly used. This also helps > in a debugger just to see if a real algorithmic initialization > has ever been reached. > > For many types, I often reserve a distinct value to mean "unknown" > or "meaningless", for some reason or other. Sometimes I even > have more than one such special value. > > >> Programs are mainly meant to be read by humans, not computers. >> Mika >> Jay K writes: >>> --_d2468f3b-9666-4291-98b5-5414421f54d9_ >>> Content-Type: text/plain; charset="iso-8859-1" >>> Content-Transfer-Encoding: quoted-printable >>> >>> >>> We are going in circles. From hendrik at topoi.pooq.com Tue Jul 6 18:53:56 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 6 Jul 2010 12:53:56 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20100706055833.118D21A2080@async.async.caltech.edu> <20100706063458.DCFF41A2080@async.async.caltech.edu> Message-ID: <20100706165355.GA1520@topoi.pooq.com> On Tue, Jul 06, 2010 at 10:05:43AM +0000, Jay K wrote: > > > used it should be a giant red flag to the reader that the variable x is > > going to be initialized with a value that the programmer doesn't know > > at the time of declaration. What on earth do you gain from x := 0? > > A "little correctness"? > > You are making the code more expensive to maintain, by making > it harder for a human to analyze. For the benefit of microoptimization. Microoptimisation as a purpose? Didn't he just explain that VAR x : INTEGER; is intended to signal to the *reader* that the initial value is irrelevant? The fact that a naive compiler might compile it slightly more efficiently is a side effect, not a purpose. If he were interested in microoptimisation, he would better feed it into a flow-analysing compiler, which could even detect when an explicit initialization like VAR x := 0; is irrelevant and suppress it. It's not *about* optimisation. Indeed, they syntactic awkwardness of declaring variables with WITH (to make sure they're initialized where they're declared) is one of the problems of Modula 3, and one of the few places where C did it better. Granted C, didn't do this at all initially, and took it from Algol 68 in one of C's rounds of standardisation. -- hendrik From hendrik at topoi.pooq.com Tue Jul 6 19:02:28 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 6 Jul 2010 13:02:28 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20100706055833.118D21A2080@async.async.caltech.edu> Message-ID: <20100706170228.GB1520@topoi.pooq.com> On Tue, Jul 06, 2010 at 06:22:50AM +0000, Jay K wrote: > > Programmers are notorious for making mistakes. > > > When you write VAR a:INTEGER; > you make the human proofreading your code have to work much harder > to do the data/control flow analysis to make sure you didn't > use the uninitialized value. > > > Using the a := 0 value might still be "wrong", but is it at least consistent > and the penalty for getting it wrong is generally less severe. > > Now, I don't want there to be a bug either way, but I feel that a consistent 0 is much "safer" > than uninitialized. Either is typesafe, sure, but type safe is just the bare minimum expectation > for my code. It must not only be type safe, but act correctly. > > Again, compiler isn't generally a program proofer, but the little it can do, let it do. Agree with letting the compiler find flaws by flow analysis and report them, if it can. But explicitly initializing it so zero so that (a) the ocmpiler won't notice it's really uninitilized, and (b) it's going to have less of a penalty for getting it wrong? I disagree with this. If there's a bug in my program I want to find it so I can fix it. I don't want it masked by an arbitrary but innocuous initial value. Here's where letting the ocmpiler initialize undefined integer variables to something like 1683002888 might actually contribute to debugging, especially if it chooses this consistently so you can rerun the program reliable while you close in on the error. But for the programmer to write VAR x := 1683002888; would likely confuse the human reader, who would spend ages pondering why *that* value. - hendrik From hosking at cs.purdue.edu Tue Jul 6 19:00:21 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 6 Jul 2010 13:00:21 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20100706165355.GA1520@topoi.pooq.com> References: <20100706055833.118D21A2080@async.async.caltech.edu> <20100706063458.DCFF41A2080@async.async.caltech.edu> <20100706165355.GA1520@topoi.pooq.com> Message-ID: I agree. If Modula-3 was being designed today it would impose the same ban on uninitialized use of variables that Java does. We have a language that does not impose that ban, but instead assures that every ininitialized variable holds a valid value. I much prefer to see VAR x: INTEGER as an *explicit* marker that the variable holds an indeterminate but valid value. Seeing VAR x := 0 implies to me that there is something especially significant about the initial value 0. On 6 Jul 2010, at 12:53, hendrik at topoi.pooq.com wrote: > On Tue, Jul 06, 2010 at 10:05:43AM +0000, Jay K wrote: >> >>> used it should be a giant red flag to the reader that the variable x is >>> going to be initialized with a value that the programmer doesn't know >>> at the time of declaration. What on earth do you gain from x := 0? >>> A "little correctness"? >> >> You are making the code more expensive to maintain, by making >> it harder for a human to analyze. For the benefit of microoptimization. > > Microoptimisation as a purpose? Didn't he just explain that > VAR x : INTEGER; > is intended to signal to the *reader* that the initial value is > irrelevant? The fact that a naive compiler might compile it slightly > more efficiently is a side effect, not a purpose. If he were interested > in microoptimisation, he would better feed it into a flow-analysing > compiler, which could even detect when an explicit initialization like > VAR x := 0; > is irrelevant and suppress it. > > It's not *about* optimisation. > > Indeed, they syntactic awkwardness of declaring variables with WITH > (to make sure they're initialized where they're declared) is one of > the problems of Modula 3, and one of the few places where C did it > better. Granted C, didn't do this at all initially, and took it from > Algol 68 in one of C's rounds of standardisation. > > -- hendrik From hosking at cs.purdue.edu Tue Jul 6 19:04:36 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 6 Jul 2010 13:04:36 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20100706170228.GB1520@topoi.pooq.com> References: <20100706055833.118D21A2080@async.async.caltech.edu> <20100706170228.GB1520@topoi.pooq.com> Message-ID: So, here is a proposal. Why not have a flag to the M3 compiler that tells it to initialise every value with zero for numbers, NIL for references, or FIRST(T) for enumerations/subranges? I am sure we can come up with something reasonable for all the primitive types. This would be an aid to debugging, but avoid the need for explicit initialisation be expressed in the code. Then, if you find yourself wondering if an uninitialised variable is the culprit for some bug then you can simply turn on the flag. It would also have the side-effect of passing the flag Jay is using to the cm3cg backend. On 6 Jul 2010, at 13:02, hendrik at topoi.pooq.com wrote: > On Tue, Jul 06, 2010 at 06:22:50AM +0000, Jay K wrote: >> >> Programmers are notorious for making mistakes. >> >> >> When you write VAR a:INTEGER; >> you make the human proofreading your code have to work much harder >> to do the data/control flow analysis to make sure you didn't >> use the uninitialized value. >> >> >> Using the a := 0 value might still be "wrong", but is it at least consistent >> and the penalty for getting it wrong is generally less severe. >> >> Now, I don't want there to be a bug either way, but I feel that a consistent 0 is much "safer" >> than uninitialized. Either is typesafe, sure, but type safe is just the bare minimum expectation >> for my code. It must not only be type safe, but act correctly. >> >> Again, compiler isn't generally a program proofer, but the little it can do, let it do. > > Agree with letting the compiler find flaws by flow analysis and > report them, if it can. > > But explicitly initializing it so zero so that (a) the ocmpiler won't > notice it's really uninitilized, and (b) it's going to have less of a > penalty for getting it wrong? I disagree with this. If there's a bug > in my program I want to find it so I can fix it. I don't want it > masked by an arbitrary but innocuous initial value. > > Here's where letting the ocmpiler initialize undefined integer > variables to something like 1683002888 might actually contribute to > debugging, especially if it chooses this consistently so you can rerun > the program reliable while you close in on the error. > > But for the programmer to write > > VAR x := 1683002888; > > would likely confuse the human reader, who would spend ages pondering > why *that* value. > > - hendrik From hosking at cs.purdue.edu Tue Jul 6 19:10:34 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 6 Jul 2010 13:10:34 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20100706055833.118D21A2080@async.async.caltech.edu> <20100706170228.GB1520@topoi.pooq.com> Message-ID: Or, alternatively, we could turn it around and have a flag that turns off (for performance if desired) well-defined initialisations (much like nochecks does to turn off other runtime checks). This would be in the spirit of the language spec, which says simply that some legal value is present, and simply go one step further in making the initialised value deterministic. As far as I can tell, this changes only the behaviour of "automatic" variables (function-scope local variables) whose initial value can be any combination of bits in the variable. All other variables get deterministic initial values already. On 6 Jul 2010, at 13:04, Tony Hosking wrote: > So, here is a proposal. > Why not have a flag to the M3 compiler that tells it to initialise every value with zero for numbers, NIL for references, or FIRST(T) for enumerations/subranges? I am sure we can come up with something reasonable for all the primitive types. > This would be an aid to debugging, but avoid the need for explicit initialisation be expressed in the code. > > Then, if you find yourself wondering if an uninitialised variable is the culprit for some bug then you can simply turn on the flag. > It would also have the side-effect of passing the flag Jay is using to the cm3cg backend. > > On 6 Jul 2010, at 13:02, hendrik at topoi.pooq.com wrote: > >> On Tue, Jul 06, 2010 at 06:22:50AM +0000, Jay K wrote: >>> >>> Programmers are notorious for making mistakes. >>> >>> >>> When you write VAR a:INTEGER; >>> you make the human proofreading your code have to work much harder >>> to do the data/control flow analysis to make sure you didn't >>> use the uninitialized value. >>> >>> >>> Using the a := 0 value might still be "wrong", but is it at least consistent >>> and the penalty for getting it wrong is generally less severe. >>> >>> Now, I don't want there to be a bug either way, but I feel that a consistent 0 is much "safer" >>> than uninitialized. Either is typesafe, sure, but type safe is just the bare minimum expectation >>> for my code. It must not only be type safe, but act correctly. >>> >>> Again, compiler isn't generally a program proofer, but the little it can do, let it do. >> >> Agree with letting the compiler find flaws by flow analysis and >> report them, if it can. >> >> But explicitly initializing it so zero so that (a) the ocmpiler won't >> notice it's really uninitilized, and (b) it's going to have less of a >> penalty for getting it wrong? I disagree with this. If there's a bug >> in my program I want to find it so I can fix it. I don't want it >> masked by an arbitrary but innocuous initial value. >> >> Here's where letting the ocmpiler initialize undefined integer >> variables to something like 1683002888 might actually contribute to >> debugging, especially if it chooses this consistently so you can rerun >> the program reliable while you close in on the error. >> >> But for the programmer to write >> >> VAR x := 1683002888; >> >> would likely confuse the human reader, who would spend ages pondering >> why *that* value. >> >> - hendrik > From hendrik at topoi.pooq.com Tue Jul 6 19:23:05 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 6 Jul 2010 13:23:05 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20100706055833.118D21A2080@async.async.caltech.edu> <20100706170228.GB1520@topoi.pooq.com> Message-ID: <20100706172305.GC1520@topoi.pooq.com> On Tue, Jul 06, 2010 at 01:10:34PM -0400, Tony Hosking wrote: > Or, alternatively, we could turn it around and have a flag that turns off (for performance if desired) well-defined initialisations (much like nochecks does to turn off other runtime checks). This would be in the spirit of the language spec, which says simply that some legal value is present, and simply go one step further in making the initialised value deterministic. As far as I can tell, this changes only the behaviour of "automatic" variables (function-scope local variables) whose initial value can be any combination of bits in the variable. All other variables get deterministic initial values already. A flag like that that uses a consistent junk value would also be useful, since it's less likely to be accidentally masked. Zero is far too commonly valid for the application, and not just valid for the language. -- hendrik From hosking at cs.purdue.edu Tue Jul 6 21:18:26 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 6 Jul 2010 15:18:26 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20100706172305.GC1520@topoi.pooq.com> References: <20100706055833.118D21A2080@async.async.caltech.edu> <20100706170228.GB1520@topoi.pooq.com> <20100706172305.GC1520@topoi.pooq.com> Message-ID: <4147B852-EA8F-49A7-94DF-81EFE5F76EDA@cs.purdue.edu> I was proposing a 0 value in the common case (where 0 bits are valid for the type). On 6 Jul 2010, at 13:23, hendrik at topoi.pooq.com wrote: > On Tue, Jul 06, 2010 at 01:10:34PM -0400, Tony Hosking wrote: >> Or, alternatively, we could turn it around and have a flag that turns off (for performance if desired) well-defined initialisations (much like nochecks does to turn off other runtime checks). This would be in the spirit of the language spec, which says simply that some legal value is present, and simply go one step further in making the initialised value deterministic. As far as I can tell, this changes only the behaviour of "automatic" variables (function-scope local variables) whose initial value can be any combination of bits in the variable. All other variables get deterministic initial values already. > > A flag like that that uses a consistent junk value would also be > useful, since it's less likely to be accidentally masked. Zero is far > too commonly valid for the application, and not just valid for the > language. > > -- hendrik From jay.krell at cornell.edu Tue Jul 6 21:20:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Jul 2010 19:20:04 +0000 Subject: [M3devel] yet another proposed fix.. careful insertion of one instance of CG.Force() in CastExpr.m3 In-Reply-To: <0FABE0B5-71CE-49F8-BD07-688EA9DC1C17@cs.purdue.edu> References: , <0FABE0B5-71CE-49F8-BD07-688EA9DC1C17@cs.purdue.edu> Message-ID: Right, that's what I meant by "too conservative". The change is acceptable as a start asis, right? We can soon thereafter evaluate expanding it? ? Well, the danger in being too conservative, is I'll allow "ter" optimization, and then bad code could creep in when optimizing. ? I can build the system this way and Juno, mentor minimally work. I could have sworn mentor wasn't "running" (the ? algorithms weren't showing anything in the GUI), but I deleted ~/.zeusState and rebuilt again and it seems ok now) btw, I forgot to say, the nice thing about that make_volatile change is, it'd be available to us in a pinch to inhibit optimizations if/when they cause other problems. ?- Jay ---------------------------------------- > Subject: Re: yet another proposed fix.. careful insertion of one instance of CG.Force() in CastExpr.m3 > From: hosking at cs.purdue.edu > Date: Tue, 6 Jul 2010 09:58:19 -0400 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > I wonder if we should be forcing all D_to_S? Is it really only floats that cause this problem? Why would that be the case? > > On 6 Jul 2010, at 08:28, Jay K wrote: > > > > > Ok, this is interesting. I think. Finally. > > I need to test more, but it is looking very promising. I think you'll like it (Tony). > > I still don't understand all the flow around the front end. I had to try out some guesses. > > It certainly appears that m3front/src/misc/CG.m3 is in the business of optimizations. > > This change might actually be too conservative. > > It defeats optimization in CG.m3. It limits it to D_to_S when one type is float and the other isn't. > > I guess S (struct) can't really be float. > > > > > > The assertion failure in gcc btw, was gcc_assert( something_is_float == other_is_float). > > So the conservativeness is somewhat sensible. > > Limiting it to D_to_S, though, unclear. > > > > > > The change is just inserting CG.Force(). > > > > > > OK? (Let me test a bit more -- build the entire tree.) > > > > This appears to let me leave "ter" on. > > I can try leaving other optimizations on. > > > > > > Index: exprs/CastExpr.m3 > > =================================================================== > > RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/CastExpr.m3,v > > retrieving revision 1.9 > > diff -u -r1.9 CastExpr.m3 > > --- exprs/CastExpr.m3 5 Jul 2010 11:28:32 -0000 1.9 > > +++ exprs/CastExpr.m3 6 Jul 2010 12:23:14 -0000 > > @@ -10,6 +10,7 @@ > > > > IMPORT M3Buf, CG, Expr, ExprRep, Type, Error, OpenArrayType; > > IMPORT M3, M3ID, M3RT, Target, TInt; > > +FROM Target IMPORT FloatType; > > > > TYPE > > Kind = { > > @@ -394,7 +395,7 @@ > > u := Expr.TypeOf (e); > > t := p.tipe; > > sz, t_align, u_align, z_align: INTEGER; > > - u_cg: CG.Type; > > + u_cg, t_cg: CG.Type; > > u_info, t_info: Type.Info; > > BEGIN > > u := Type.CheckInfo (u, u_info); > > @@ -403,6 +404,7 @@ > > u_align := u_info.alignment; > > z_align := MAX (t_align, u_align); > > u_cg := u_info.stk_type; > > + t_cg := t_info.stk_type; > > sz := u_info.size; > > Type.Compile (t); > > Type.Compile (u); > > @@ -416,6 +418,15 @@ > > Kind.V_to_V => > > Expr.CompileLValue (p.expr, traced); > > CG.Boost_alignment (t_align); > > +(* Inhibit some optimization that causes compilation to fail. e.g. m3core: > > +../src/float/IEEE/RealFloat.m3: In function 'RealFloat__CopySign': > > +../src/float/IEEE/RealFloat.m3:96: internal compiler error: in convert_move, at expr.c:371 > > +../src/float/IEEE/LongFloat.m3: In function 'LongFloat__CopySign': > > +../src/float/IEEE/LongFloat.m3:116: internal compiler error: in convert_move, at expr.c:371 > > +*) > > + IF p.kind = Kind.D_to_S AND FloatType[u_cg] # FloatType[t_cg] THEN > > + CG.Force (); > > + END; > > > > | Kind.D_to_A, > > Kind.S_to_A, > > > > > > > > (577) begin_procedure > > procedure LongFloat__CopySign > > LongFloat__CopySign(578) set_source_line > > source line 117 > > (579) load > > type:lreal > > type:lreal > > m3cg_load (M3_CtKayy_x): offset 0x0, convert lreal -> lreal > > (580) store > > type:lreal > > type:lreal > > store (M3_CtKayy_res) offset:0x0 src_t:lreal dst_t:lreal > > (581) set_source_line > > source line 119 > > > > > > now notice we have use of load_address and load_indirect here, where before we had no address and load (direct) > > > > > > (582) load_address > > load address (M3_CtKayy_res) offset 0x0 > > (583) load_address > > load address (M3_CtKayy_y) offset 0x0 > > (584) load_indirect > > type:word8 > > type:int64 > > load address offset:0x38 src_t:word8 dst_t:int64 > > (585) extract_mn > > type:int64 > > extract_mn offset:7 count:1 sign_extend:0 > > (586) swap > > type:addr > > type:int64 > > (587) declare_temp > > type:addr > > temp var type:addr size:0x40 alignment:0x40 > > (588) store > > type:addr > > type:addr > > store (noname) offset:0x0 src_t:addr dst_t:addr > > (589) load > > type:addr > > type:addr > > m3cg_load (noname): offset 0x0, convert addr -> addr > > (590) load_indirect > > type:word8 > > type:int64 > > load address offset:0x38 src_t:word8 dst_t:int64 > > (591) swap > > type:int64 > > type:word8 > > (592) insert_mn > > type:int64 > > insert_mn offset:7 count:1 > > (593) load > > type:addr > > type:addr > > m3cg_load (noname): offset 0x0, convert addr -> addr > > (594) swap > > type:word8 > > type:addr > > (595) store_indirect > > type:int64 > > type:word8 > > store indirect offset:0x38 src_t:int64 dst_t:word8 > > (596) set_source_line > > source line 120 > > (597) load > > type:lreal > > type:lreal > > m3cg_load (M3_CtKayy_res): offset 0x0, convert lreal -> lreal > > (598) exit_proc > > type:lreal > > (599) free_temp > > (600) end_procedure > > procedure LongFloat__CopySign > > > > > > > > - Jay > > > > > From hosking at cs.purdue.edu Tue Jul 6 21:23:47 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 6 Jul 2010 15:23:47 -0400 Subject: [M3devel] yet another proposed fix.. careful insertion of one instance of CG.Force() in CastExpr.m3 In-Reply-To: References: , <0FABE0B5-71CE-49F8-BD07-688EA9DC1C17@cs.purdue.edu> Message-ID: <2A836943-BEB7-4D5C-928B-65FD2098DF6D@cs.purdue.edu> On 6 Jul 2010, at 15:20, Jay K wrote: > Right, that's what I meant by "too conservative". I am ok with forcing in all D_to_S cases. > The change is acceptable as a start asis, right? We can soon thereafter evaluate expanding it? > Well, the danger in being too conservative, is I'll allow "ter" optimization, and then bad code could creep in when optimising. I don't think that will happen with the force, since we will make it in memory for gcc which will probably then be much happier. > I can build the system this way and Juno, mentor minimally work. I could have sworn mentor wasn't "running" (the > algorithms weren't showing anything in the GUI), but I deleted ~/.zeusState and rebuilt again and it seems ok now) OK, great. > btw, I forgot to say, the nice thing about that make_volatile change is, it'd be available to us in a pinch to inhibit > optimizations if/when they cause other problems. I am extremely leery of introducing hacks into the IR that we will later regret. The rot will set in... > > - Jay > > ---------------------------------------- >> Subject: Re: yet another proposed fix.. careful insertion of one instance of CG.Force() in CastExpr.m3 >> From: hosking at cs.purdue.edu >> Date: Tue, 6 Jul 2010 09:58:19 -0400 >> CC: m3devel at elegosoft.com >> To: jay.krell at cornell.edu >> >> I wonder if we should be forcing all D_to_S? Is it really only floats that cause this problem? Why would that be the case? >> >> On 6 Jul 2010, at 08:28, Jay K wrote: >> >>> >>> Ok, this is interesting. I think. Finally. >>> I need to test more, but it is looking very promising. I think you'll like it (Tony). >>> I still don't understand all the flow around the front end. I had to try out some guesses. >>> It certainly appears that m3front/src/misc/CG.m3 is in the business of optimizations. >>> This change might actually be too conservative. >>> It defeats optimization in CG.m3. It limits it to D_to_S when one type is float and the other isn't. >>> I guess S (struct) can't really be float. >>> >>> >>> The assertion failure in gcc btw, was gcc_assert( something_is_float == other_is_float). >>> So the conservativeness is somewhat sensible. >>> Limiting it to D_to_S, though, unclear. >>> >>> >>> The change is just inserting CG.Force(). >>> >>> >>> OK? (Let me test a bit more -- build the entire tree.) >>> >>> This appears to let me leave "ter" on. >>> I can try leaving other optimizations on. >>> >>> >>> Index: exprs/CastExpr.m3 >>> =================================================================== >>> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/CastExpr.m3,v >>> retrieving revision 1.9 >>> diff -u -r1.9 CastExpr.m3 >>> --- exprs/CastExpr.m3 5 Jul 2010 11:28:32 -0000 1.9 >>> +++ exprs/CastExpr.m3 6 Jul 2010 12:23:14 -0000 >>> @@ -10,6 +10,7 @@ >>> >>> IMPORT M3Buf, CG, Expr, ExprRep, Type, Error, OpenArrayType; >>> IMPORT M3, M3ID, M3RT, Target, TInt; >>> +FROM Target IMPORT FloatType; >>> >>> TYPE >>> Kind = { >>> @@ -394,7 +395,7 @@ >>> u := Expr.TypeOf (e); >>> t := p.tipe; >>> sz, t_align, u_align, z_align: INTEGER; >>> - u_cg: CG.Type; >>> + u_cg, t_cg: CG.Type; >>> u_info, t_info: Type.Info; >>> BEGIN >>> u := Type.CheckInfo (u, u_info); >>> @@ -403,6 +404,7 @@ >>> u_align := u_info.alignment; >>> z_align := MAX (t_align, u_align); >>> u_cg := u_info.stk_type; >>> + t_cg := t_info.stk_type; >>> sz := u_info.size; >>> Type.Compile (t); >>> Type.Compile (u); >>> @@ -416,6 +418,15 @@ >>> Kind.V_to_V => >>> Expr.CompileLValue (p.expr, traced); >>> CG.Boost_alignment (t_align); >>> +(* Inhibit some optimization that causes compilation to fail. e.g. m3core: >>> +../src/float/IEEE/RealFloat.m3: In function 'RealFloat__CopySign': >>> +../src/float/IEEE/RealFloat.m3:96: internal compiler error: in convert_move, at expr.c:371 >>> +../src/float/IEEE/LongFloat.m3: In function 'LongFloat__CopySign': >>> +../src/float/IEEE/LongFloat.m3:116: internal compiler error: in convert_move, at expr.c:371 >>> +*) >>> + IF p.kind = Kind.D_to_S AND FloatType[u_cg] # FloatType[t_cg] THEN >>> + CG.Force (); >>> + END; >>> >>> | Kind.D_to_A, >>> Kind.S_to_A, >>> >>> >>> >>> (577) begin_procedure >>> procedure LongFloat__CopySign >>> LongFloat__CopySign(578) set_source_line >>> source line 117 >>> (579) load >>> type:lreal >>> type:lreal >>> m3cg_load (M3_CtKayy_x): offset 0x0, convert lreal -> lreal >>> (580) store >>> type:lreal >>> type:lreal >>> store (M3_CtKayy_res) offset:0x0 src_t:lreal dst_t:lreal >>> (581) set_source_line >>> source line 119 >>> >>> >>> now notice we have use of load_address and load_indirect here, where before we had no address and load (direct) >>> >>> >>> (582) load_address >>> load address (M3_CtKayy_res) offset 0x0 >>> (583) load_address >>> load address (M3_CtKayy_y) offset 0x0 >>> (584) load_indirect >>> type:word8 >>> type:int64 >>> load address offset:0x38 src_t:word8 dst_t:int64 >>> (585) extract_mn >>> type:int64 >>> extract_mn offset:7 count:1 sign_extend:0 >>> (586) swap >>> type:addr >>> type:int64 >>> (587) declare_temp >>> type:addr >>> temp var type:addr size:0x40 alignment:0x40 >>> (588) store >>> type:addr >>> type:addr >>> store (noname) offset:0x0 src_t:addr dst_t:addr >>> (589) load >>> type:addr >>> type:addr >>> m3cg_load (noname): offset 0x0, convert addr -> addr >>> (590) load_indirect >>> type:word8 >>> type:int64 >>> load address offset:0x38 src_t:word8 dst_t:int64 >>> (591) swap >>> type:int64 >>> type:word8 >>> (592) insert_mn >>> type:int64 >>> insert_mn offset:7 count:1 >>> (593) load >>> type:addr >>> type:addr >>> m3cg_load (noname): offset 0x0, convert addr -> addr >>> (594) swap >>> type:word8 >>> type:addr >>> (595) store_indirect >>> type:int64 >>> type:word8 >>> store indirect offset:0x38 src_t:int64 dst_t:word8 >>> (596) set_source_line >>> source line 120 >>> (597) load >>> type:lreal >>> type:lreal >>> m3cg_load (M3_CtKayy_res): offset 0x0, convert lreal -> lreal >>> (598) exit_proc >>> type:lreal >>> (599) free_temp >>> (600) end_procedure >>> procedure LongFloat__CopySign >>> >>> >>> >>> - Jay >>> >>> >> > From jay.krell at cornell.edu Tue Jul 6 22:21:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Jul 2010 20:21:08 +0000 Subject: [M3devel] fault reports beyond 100mill lines? Message-ID: It appears that if a file has over around 100 million lines, that fault reports (nil deref, subrange out of bounds, etc.) get the wrong line number. Leave it as ("qualit of implementation"?) or fail an assertion in the compiler earlier (leaving anyone with a huge file kind of stuck (generated?) or, unlikely, expand the range? The line number is in an integer along with a 5 bit fault code. ? We could also allow much larger numbers on 64bit targets. This is just because there's a "FIXME" comment in parse.c. The code is basically right and I'm adding comments and perhaps assertions. Certainly we can assert that the fault code is in range. I think I prefer silently losing bits in the line number, or conveting it to 0 if it is out of bounds or pinning it to maxint. ? Though it'd be maxint? / 32 which is less "special" looking if someone ever saw it.. though the runtime could ? report maxint / 32 as maxint. ?- Jay From jay.krell at cornell.edu Tue Jul 6 22:35:45 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Jul 2010 20:35:45 +0000 Subject: [M3devel] fault reports beyond 100mill lines? In-Reply-To: References: Message-ID: I'm pretty settled on silently losing line numbers over 100 million. If the host and target are 64 bits it preserves far more. If someone produces such a file, and it compiles and runs, but gets a runtime error in their code on the wrong line, they can claim they found a compiler bug... ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Tue, 6 Jul 2010 20:21:08 +0000 > Subject: [M3devel] fault reports beyond 100mill lines? > > > It appears that if a file has over around 100 million lines, that fault reports (nil deref, subrange out of bounds, etc.) get the wrong line number. > Leave it as ("qualit of implementation"?) or fail an assertion in the compiler earlier (leaving anyone with a huge file kind of stuck (generated?) or, unlikely, expand the range? > The line number is in an integer along with a 5 bit fault code. > We could also allow much larger numbers on 64bit targets. > > > This is just because there's a "FIXME" comment in parse.c. > The code is basically right and I'm adding comments and perhaps assertions. > Certainly we can assert that the fault code is in range. > > > I think I prefer silently losing bits in the line number, or conveting it to 0 if it is out of bounds or pinning it to maxint. > Though it'd be maxint / 32 which is less "special" looking if someone ever saw it.. though the runtime could > report maxint / 32 as maxint. > > - Jay > > From rcolebur at SCIRES.COM Wed Jul 7 00:19:45 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Tue, 6 Jul 2010 18:19:45 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20100706055833.118D21A2080@async.async.caltech.edu> <20100706063458.DCFF41A2080@async.async.caltech.edu> <20100706165355.GA1520@topoi.pooq.com> Message-ID: I agree also. Let's not change the language here, and let's not change the compiler's behavior to no longer match the language. I don't have a problem with selectively turning on a warning level at compile time for compiler to warn me that I might be using a variable before it is initialized, but I don't want compiler choosing to initialize it for me. --Randy -----Original Message----- From: Tony Hosking [mailto:hosking at cs.purdue.edu] Sent: Tuesday, July 06, 2010 1:00 PM To: hendrik at topoi.pooq.com Cc: m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 I agree. If Modula-3 was being designed today it would impose the same ban on uninitialized use of variables that Java does. We have a language that does not impose that ban, but instead assures that every ininitialized variable holds a valid value. I much prefer to see VAR x: INTEGER as an *explicit* marker that the variable holds an indeterminate but valid value. Seeing VAR x := 0 implies to me that there is something especially significant about the initial value 0. On 6 Jul 2010, at 12:53, hendrik at topoi.pooq.com wrote: > On Tue, Jul 06, 2010 at 10:05:43AM +0000, Jay K wrote: >> >>> used it should be a giant red flag to the reader that the variable x is >>> going to be initialized with a value that the programmer doesn't know >>> at the time of declaration. What on earth do you gain from x := 0? >>> A "little correctness"? >> >> You are making the code more expensive to maintain, by making >> it harder for a human to analyze. For the benefit of microoptimization. > > Microoptimisation as a purpose? Didn't he just explain that > VAR x : INTEGER; > is intended to signal to the *reader* that the initial value is > irrelevant? The fact that a naive compiler might compile it slightly > more efficiently is a side effect, not a purpose. If he were interested > in microoptimisation, he would better feed it into a flow-analysing > compiler, which could even detect when an explicit initialization like > VAR x := 0; > is irrelevant and suppress it. > > It's not *about* optimisation. > > Indeed, they syntactic awkwardness of declaring variables with WITH > (to make sure they're initialized where they're declared) is one of > the problems of Modula 3, and one of the few places where C did it > better. Granted C, didn't do this at all initially, and took it from > Algol 68 in one of C's rounds of standardisation. > > -- hendrik From rodney_bates at lcwb.coop Wed Jul 7 00:41:55 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 06 Jul 2010 17:41:55 -0500 Subject: [M3devel] loophole/copysign In-Reply-To: <2F356C4B-5541-489B-B957-E3D295F549F5@cs.purdue.edu> References: <2F356C4B-5541-489B-B957-E3D295F549F5@cs.purdue.edu> Message-ID: <4C33B133.8020107@lcwb.coop> Tony Hosking wrote: > A designator is something that can be assigned to as well as read from. > It says nothing about it being in memory. A value cannot be assigned to. > Not necessarily. There are writable designators and readonly designators. The only things I find that can spontaneously produce a readonly designator are a READONLY formal and a FOR local. Several things produce writable designators, Lots of things propagate designator-ness around, and sometimes writability too. E.g., subscripting an array propagates each of these properties independently from the array to the selected element. ADR, BITSIZE, BYTESIZE, and ADRSIZE can be applied to a readonly designator (but not to a non-designator). Assignment, passing to a VAR formal, and DISPOSE require a writable designator. Although it is really an implementation- level distinction, these pretty well imply that a designator will have to be in memory. Not necessarily the converse, as, for example, a compiler could very well store the result of A+B in memory, but the language still forbids applying ADR to it, etc., leaving the compiler a choice. > On 5 Jul 2010, at 06:42, Jay K wrote: > >> Tony, et. al.. in m3front/src/exprs/CastExpr.m3..what's the difference between a "designator" and a "value"? > From hendrik at topoi.pooq.com Wed Jul 7 01:01:16 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 6 Jul 2010 19:01:16 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <4147B852-EA8F-49A7-94DF-81EFE5F76EDA@cs.purdue.edu> References: <20100706055833.118D21A2080@async.async.caltech.edu> <20100706170228.GB1520@topoi.pooq.com> <20100706172305.GC1520@topoi.pooq.com> <4147B852-EA8F-49A7-94DF-81EFE5F76EDA@cs.purdue.edu> Message-ID: <20100706230115.GA3124@topoi.pooq.com> On Tue, Jul 06, 2010 at 03:18:26PM -0400, Tony Hosking wrote: > I was proposing a 0 value in the common case (where 0 bits are valid for the type). Yes, I understood that. I'm pointing out that a nonzero value (also where valid) is likely to find more errors than a zero value, and that a consistent nonzero value will make it easier to actually find the errors, instead of just detect them. And it's less likely to lead to programs that run successfully only when you specify the option. -- hendrik From ttmrichter at gmail.com Wed Jul 7 05:56:43 2010 From: ttmrichter at gmail.com (Michael Richter) Date: Wed, 7 Jul 2010 11:56:43 +0800 Subject: [M3devel] fault reports beyond 100mill lines? In-Reply-To: References: Message-ID: Why the magic number of 100,000,000? Why not 4 billion, say? On 7 July 2010 04:35, Jay K wrote: > > I'm pretty settled on silently losing line numbers over 100 million. > If the host and target are 64 bits it preserves far more. > If someone produces such a file, and it compiles and runs, but gets a > runtime error in their code on the wrong line, they can claim they found a > compiler bug... > > - Jay > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Date: Tue, 6 Jul 2010 20:21:08 +0000 > > Subject: [M3devel] fault reports beyond 100mill lines? > > > > > > It appears that if a file has over around 100 million lines, that fault > reports (nil deref, subrange out of bounds, etc.) get the wrong line number. > > Leave it as ("qualit of implementation"?) or fail an assertion in the > compiler earlier (leaving anyone with a huge file kind of stuck (generated?) > or, unlikely, expand the range? > > The line number is in an integer along with a 5 bit fault code. > > We could also allow much larger numbers on 64bit targets. > > > > > > This is just because there's a "FIXME" comment in parse.c. > > The code is basically right and I'm adding comments and perhaps > assertions. > > Certainly we can assert that the fault code is in range. > > > > > > I think I prefer silently losing bits in the line number, or conveting it > to 0 if it is out of bounds or pinning it to maxint. > > Though it'd be maxint / 32 which is less "special" looking if someone > ever saw it.. though the runtime could > > report maxint / 32 as maxint. > > > > - Jay > > > > > > -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Jul 7 06:03:42 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 7 Jul 2010 04:03:42 +0000 Subject: [M3devel] fault reports beyond 100mill lines? In-Reply-To: References: , , Message-ID: See below: >> The line number is in an integer along with a 5 bit fault code. Maybe that isn't clear -- they are in the same integer, 32bits or 64bits. 4 billion / 32 is roughly 100 million. - Jay Date: Wed, 7 Jul 2010 11:56:43 +0800 From: ttmrichter at gmail.com To: m3devel at elegosoft.com Subject: Re: [M3devel] fault reports beyond 100mill lines? Why the magic number of 100,000,000? Why not 4 billion, say? On 7 July 2010 04:35, Jay K wrote: I'm pretty settled on silently losing line numbers over 100 million. If the host and target are 64 bits it preserves far more. If someone produces such a file, and it compiles and runs, but gets a runtime error in their code on the wrong line, they can claim they found a compiler bug... - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Tue, 6 Jul 2010 20:21:08 +0000 > Subject: [M3devel] fault reports beyond 100mill lines? > > > It appears that if a file has over around 100 million lines, that fault reports (nil deref, subrange out of bounds, etc.) get the wrong line number. > Leave it as ("qualit of implementation"?) or fail an assertion in the compiler earlier (leaving anyone with a huge file kind of stuck (generated?) or, unlikely, expand the range? > The line number is in an integer along with a 5 bit fault code. > We could also allow much larger numbers on 64bit targets. > > > This is just because there's a "FIXME" comment in parse.c. > The code is basically right and I'm adding comments and perhaps assertions. > Certainly we can assert that the fault code is in range. > > > I think I prefer silently losing bits in the line number, or conveting it to 0 if it is out of bounds or pinning it to maxint. > Though it'd be maxint / 32 which is less "special" looking if someone ever saw it.. though the runtime could > report maxint / 32 as maxint. > > - Jay > > -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Wed Jul 7 06:30:06 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 7 Jul 2010 04:30:06 +0000 (GMT) Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: Message-ID: <4898.91283.qm@web23608.mail.ird.yahoo.com> Hi all: I could be wrong but if the mapped structures of original CM3 v4.1 were to detect compile time errors and runtime errors those ones no checked in M3 would be like to be checked at the CM3 JVM runtime (which abide CM3 itself at the time) then as the runtime JVM micro-ops were even possibly checked at java process runtime and possibly scanned at the lowest Modula-3 execution trace lower levels, we can I guess map those of the M3CG (even if are at the lowest level they did something like to match some structures at least they did that level of matching of two semantic structures and work as one like the CISC stack based JVM machine and the "RISC" stack class machine of M3CG) at the compile time back traces and so on interpretation (it would be not just not a M3CG VM like JVM but to get type info of the system and detect the probably undetectable otherwise Modula-3 runtime overflows i.e map some undetectable otherwise expressions meant to be not overflowed actually overflowed in the runtime). I guess in that way we can reserve more energies for both tasks compiler enhancement and m3cg tracing tree debugger ability if thats what you are looking for. In other short words I am proposing instead of the idea of initialize everything either manually or semi automatically get into the idea of a proper type system for M3CG and get rid of this kind of errors people are seeing meaningful if someone tells what else. I have a history of Modula-3, Java and JVM friendly leaving but to get into this properly I guess I would need more than energies I would like to get to check specially the implementation of the JVM lower level of CM3 and even better than that state or propose a type system for M3CG assembly language if we can call like that so no matters what we can have a better and systematic and reasonable (as JVM does) way of checking the M3CG code checking and generation if at all changes. Let me have a chance of asking of this more, probably first I need to check this paper wrote in DEC SRC about 1998 to see if the type system is pretty straight forward http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-158.pdf Thanks in advance --- El mar, 6/7/10, Tony Hosking escribi?: > De: Tony Hosking > Asunto: Re: [M3devel] [M3commit] CVS Update: cm3 > Para: hendrik at topoi.pooq.com > CC: m3devel at elegosoft.com > Fecha: martes, 6 de julio, 2010 12:00 > I agree. > > If Modula-3 was being designed today it would impose the > same ban on uninitialized use of variables that Java does. > We have a language that does not impose that ban, but > instead assures that every ininitialized variable holds a > valid value. > I much prefer to see > > VAR x: INTEGER > > as an *explicit* marker that the variable holds an > indeterminate but valid value. > > Seeing > > VAR x := 0 > > implies to me that there is something especially > significant about the initial value 0. > > > On 6 Jul 2010, at 12:53, hendrik at topoi.pooq.com > wrote: > > > On Tue, Jul 06, 2010 at 10:05:43AM +0000, Jay K > wrote: > >> > >>> used it should be a giant red flag to the > reader that the variable x is > >>> going to be initialized with a value that the > programmer doesn't know > >>> at the time of declaration. What on earth do > you gain from x := 0? > >>> A "little correctness"? > >> > >> You are making the code more expensive to > maintain, by making > >> it harder for a human to analyze. For the benefit > of microoptimization. > > > > Microoptimisation as a purpose? Didn't he just > explain that > > VAR x : INTEGER; > > is intended to signal to the *reader* that the initial > value is > > irrelevant? The fact that a naive compiler might > compile it slightly > > more efficiently is a side effect, not a > purpose. If he were interested > > in microoptimisation, he would better feed it into a > flow-analysing > > compiler, which could even detect when an explicit > initialization like > > VAR x := 0; > > is irrelevant and suppress it. > > > > It's not *about* optimisation. > > > > Indeed, they syntactic awkwardness of declaring > variables with WITH > > (to make sure they're initialized where they're > declared) is one of > > the problems of Modula 3, and one of the few places > where C did it > > better. Granted C, didn't do this at all > initially, and took it from > > Algol 68 in one of C's rounds of standardisation. > > > > -- hendrik > > From mika at async.async.caltech.edu Wed Jul 7 09:37:53 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Wed, 07 Jul 2010 00:37:53 -0700 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20100706063547.81FC21A2080@async.async.caltech.edu> Message-ID: <20100707073753.8A8F21A207C@async.async.caltech.edu> Jay K writes: > ... >> >When you write VAR a:INTEGER=3D3B >> >you make the human proofreading your code have to work much harder >> >to do the data/control flow analysis to make sure you didn't >> >use the uninitialized value. >> >> And yes=2C that's precisely the point! > > >You are just adding to the maintenance cost of the code. >If something makes it much more difficult to analyze by a human=2C and does= >n't >provide much benefit=2C don't do it. > Sorry to keep beating a dead horse but I meant precisely the opposite. If you ever see code that I have written that says: VAR x : INTEGER; BEGIN ... END that means *precisely* that there is no initial value of x for which the code is more correct than for any other initial value. I couldn't care less (99.9% of the time) about the insignficant time the compiler spends initializing the variable. It's all about readability. If it says VAR x := 0; BEGIN ... END it's really rather a mystery what that 0 means until the human has analyzed the code and realizes that on every path, x is written before it is read! And hey if you introduce a bug in the program where you forget to initialize x as you thought, the naive reader will assume the code is correct, because you did initialize it to zero (how clever, that zero value must be very special!) If you leave out the extra initialization, the bug will be fairly obvious even to someone who doesn't know exactly what the program is doing. I think you are just trading a set of moderately easy to analyze bugs for a set of very difficult bugs if you insist on initializing every variable including those without good initial values. Mika From jay.krell at cornell.edu Wed Jul 7 23:01:33 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 7 Jul 2010 21:01:33 +0000 Subject: [M3devel] try/finally and ter optimization? Message-ID: This is an example that crashes the backend if ter is enabled. TryFinStmt has three modes: Compile1, Compile2, Compile3. ?- stack walker ?- two other modes depending on the form of the function (I didn't read closely). ? One of them calls setjmp, one does not. ? In this case, no call to setjmp. ? Needs further investigation. ?Even if I put code in the finally block, same thing. ?TryStmt.m3 only has two modes, stack walker and not. ?So I think the problem is somewhere in TryFinStmt -- it doesn't generate a call to setjmp (Marker.CaptureState) (* Compiling this program has crashed some backends. ?* (gcc backend with -O3, no volatile, 'ter') ?* This is reduced from libm3/Formatter.m3 ?* The point therefore is merely to compile it without crashing. ?*) MODULE Main; ? VAR NoAlignOp: CARDINAL; PROCEDURE PeekOp(<*NOWARN*> i: CARDINAL): CARDINAL = ? BEGIN RETURN NoAlignOp; END PeekOp; VAR pos1: CARDINAL := 0; <*NOWARN*> PROCEDURE PrintAlign(VAR pos: CARDINAL) = ? VAR op, endRun: CARDINAL := 0; ? BEGIN ??? TRY ????? LOOP ??????? op := PeekOp(pos); ??????? LOOP ????????? IF op = NoAlignOp THEN ??????????? IF endRun = pos THEN ????????????? INC(endRun); ??????????? END; ??????????? EXIT; ????????? END; ????????? op := PeekOp(pos1); ??????? END; ????? END; ??? FINALLY ??? END; ? END PrintAlign; BEGIN END Main. From jay.krell at cornell.edu Thu Jul 8 12:22:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 8 Jul 2010 10:22:32 +0000 Subject: [M3devel] try/finally and ter optimization? In-Reply-To: References: Message-ID: To be clear, in several emails and commit comments, I mixed up "pre" and "ter". ?"ter" allowed now. ?"pre" is the problem. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: try/finally and ter optimization? > Date: Wed, 7 Jul 2010 21:01:33 +0000 > > > This is an example that crashes the backend if ter is enabled. > TryFinStmt has three modes: Compile1, Compile2, Compile3. > - stack walker > - two other modes depending on the form of the function (I didn't read closely). > One of them calls setjmp, one does not. > In this case, no call to setjmp. > Needs further investigation. > Even if I put code in the finally block, same thing. > TryStmt.m3 only has two modes, stack walker and not. > So I think the problem is somewhere in TryFinStmt -- it doesn't generate a call to setjmp (Marker.CaptureState) > > > > (* Compiling this program has crashed some backends. > * (gcc backend with -O3, no volatile, 'ter') > * This is reduced from libm3/Formatter.m3 > * The point therefore is merely to compile it without crashing. > *) > > MODULE Main; > > VAR NoAlignOp: CARDINAL; > > PROCEDURE PeekOp(<*NOWARN*> i: CARDINAL): CARDINAL = > BEGIN RETURN NoAlignOp; END PeekOp; > > VAR pos1: CARDINAL := 0; > > <*NOWARN*> PROCEDURE PrintAlign(VAR pos: CARDINAL) = > VAR op, endRun: CARDINAL := 0; > BEGIN > TRY > LOOP > op := PeekOp(pos); > LOOP > IF op = NoAlignOp THEN > IF endRun = pos THEN > INC(endRun); > END; > EXIT; > END; > op := PeekOp(pos1); > END; > END; > FINALLY > END; > END PrintAlign; > > BEGIN > END Main. > > From rcolebur at SCIRES.COM Thu Jul 8 18:42:58 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Thu, 8 Jul 2010 12:42:58 -0400 Subject: [M3devel] head branch can't compile on Windows Message-ID: I am no longer able to build the head branch on Windows. --Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 9 10:20:37 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 9 Jul 2010 08:20:37 +0000 Subject: [M3devel] head branch can't compile on Windows In-Reply-To: References: Message-ID: Randy is this what you see: "..\src\runtime\common\RTHeapStats.m3", line 203: unknown qualification '.' (And) "..\src\runtime\common\RTHeapStats.m3", line 207: unknown qualification '.' (T) "..\src\runtime\common\RTHeapStats.m3", line 208: unknown qualification '.' (T) "..\src\runtime\common\RTHeapStats.m3", line 209: unknown qualification '.' (LeftShift) "..\src\runtime\common\RTHeapStats.m3", line 210: unknown qualification '.' (And) "..\src\runtime\common\RTHeapStats.m3", line 212: unknown qualification '.' (Or) Yes, something is very wrong. - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com Date: Thu, 8 Jul 2010 12:42:58 -0400 Subject: [M3devel] head branch can't compile on Windows I am no longer able to build the head branch on Windows. --Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 9 14:01:16 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 9 Jul 2010 12:01:16 +0000 Subject: [M3devel] head branch can't compile on Windows In-Reply-To: References: , Message-ID: Randy, please try again, with the change to m3front/misc/Scanner.m3 (ie: version 1.13 or 1.11, not version 1.12). Tony, this was yours. Thanks, - Jay From: jay.krell at cornell.edu To: rcolebur at scires.com; m3devel at elegosoft.com Subject: RE: [M3devel] head branch can't compile on Windows Date: Fri, 9 Jul 2010 08:20:37 +0000 Randy is this what you see: "..\src\runtime\common\RTHeapStats.m3", line 203: unknown qualification '.' (And) "..\src\runtime\common\RTHeapStats.m3", line 207: unknown qualification '.' (T) "..\src\runtime\common\RTHeapStats.m3", line 208: unknown qualification '.' (T) "..\src\runtime\common\RTHeapStats.m3", line 209: unknown qualification '.' (LeftShift) "..\src\runtime\common\RTHeapStats.m3", line 210: unknown qualification '.' (And) "..\src\runtime\common\RTHeapStats.m3", line 212: unknown qualification '.' (Or) Yes, something is very wrong. - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com Date: Thu, 8 Jul 2010 12:42:58 -0400 Subject: [M3devel] head branch can't compile on Windows I am no longer able to build the head branch on Windows. --Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jul 11 13:46:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 11 Jul 2010 11:46:43 +0000 Subject: [M3devel] barrier labels? Message-ID: Tony, six years ago you introduce what is now: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c.diff?r1=1.5;r2=1.6 static void m3cg_set_label (void) { ... ? if (barrier) ??? { ... ????? { ??????? rtx list = DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels; ??????? DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels ????????? = gen_rtx_EXPR_LIST (VOIDmode, r, list); ????? } ... I'm not sure what to do here for gcc 4.5. ? The data has moved around and isn't available this early. I suppose we could hang some information on and ??? deal with it later in compilation. DECL_NONLOCAL(l) = true; seems promising, but it caused very bad code to be produced (incorrect, not inefficient). I didn't look into why. The bad code was changing the stack pointer where it should leave it alone. gcc-4.5 is working for me now (cm3 built with it can built itself), at least with -O1, AMD64_DARWIN. And Juno/mentor/tetris work without optimization, I'll test optimized later. Next I'll test -O2, -O3, m3-sys/m3tests. Do we have good exception handling tests? I know that cm3 uses exceptions, like, looking for cm3.cfg. I'll poke around more.. ?- Jay From hosking at cs.purdue.edu Sun Jul 11 22:25:41 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 11 Jul 2010 16:25:41 -0400 Subject: [M3devel] barrier labels? In-Reply-To: References: Message-ID: I extracted that usage from what C++ was doing for exception labels. The point is to make sure that flow analysis knows that the exception handler label targets are important "non-local" label targets. I do remember that DECL_NONLOCAL was *not* the right thing to do (that is used for proper non-local outer-scope goto targets for nested functions) and I remember the SP hacks being used with that (they need to recover from targeting from an inner-scope function and clean up the stack accordingly). I suggest poking around in what the C++ exception handling now does with table-driven exception targets. On 11 Jul 2010, at 07:46, Jay K wrote: > > Tony, six years ago you introduce what is now: > > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c.diff?r1=1.5;r2=1.6 > > > static void > m3cg_set_label (void) > { > ... > if (barrier) > { > ... > { > rtx list = DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels; > DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels > = gen_rtx_EXPR_LIST (VOIDmode, r, list); > } > ... > > > I'm not sure what to do here for gcc 4.5. > The data has moved around and isn't available this early. I suppose we could hang some information on and > deal with it later in compilation. > > > DECL_NONLOCAL(l) = true; seems promising, but it caused very bad code to be produced (incorrect, not inefficient). > I didn't look into why. The bad code was changing the stack pointer where it should leave it alone. > > > gcc-4.5 is working for me now (cm3 built with it can built itself), at least with -O1, AMD64_DARWIN. > And Juno/mentor/tetris work without optimization, I'll test optimized later. > Next I'll test -O2, -O3, m3-sys/m3tests. > > > Do we have good exception handling tests? > I know that cm3 uses exceptions, like, looking for cm3.cfg. > > > I'll poke around more.. > > > - Jay > From jay.krell at cornell.edu Mon Jul 12 01:41:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 11 Jul 2010 23:41:20 +0000 Subject: [M3devel] barrier labels? In-Reply-To: References: , Message-ID: Tony, thanks for the pointer..though I haven't been able to find it yet. I also looked for related code in 3.3 and 3.4, as I think 3.3 was current at the time. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Sun, 11 Jul 2010 16:25:41 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] barrier labels? > > I extracted that usage from what C++ was doing for exception labels. The point is to make sure that flow analysis knows that the exception handler label targets are important "non-local" label targets. I do remember that DECL_NONLOCAL was *not* the right thing to do (that is used for proper non-local outer-scope goto targets for nested functions) and I remember the SP hacks being used with that (they need to recover from targeting from an inner-scope function and clean up the stack accordingly). I suggest poking around in what the C++ exception handling now does with table-driven exception targets. > > On 11 Jul 2010, at 07:46, Jay K wrote: > > > > > Tony, six years ago you introduce what is now: > > > > > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c.diff?r1=1.5;r2=1.6 > > > > > > static void > > m3cg_set_label (void) > > { > > ... > > if (barrier) > > { > > ... > > { > > rtx list = DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels; > > DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels > > = gen_rtx_EXPR_LIST (VOIDmode, r, list); > > } > > ... > > > > > > I'm not sure what to do here for gcc 4.5. > > The data has moved around and isn't available this early. I suppose we could hang some information on and > > deal with it later in compilation. > > > > > > DECL_NONLOCAL(l) = true; seems promising, but it caused very bad code to be produced (incorrect, not inefficient). > > I didn't look into why. The bad code was changing the stack pointer where it should leave it alone. > > > > > > gcc-4.5 is working for me now (cm3 built with it can built itself), at least with -O1, AMD64_DARWIN. > > And Juno/mentor/tetris work without optimization, I'll test optimized later. > > Next I'll test -O2, -O3, m3-sys/m3tests. > > > > > > Do we have good exception handling tests? > > I know that cm3 uses exceptions, like, looking for cm3.cfg. > > > > > > I'll poke around more.. > > > > > > - Jay > > > From jay.krell at cornell.edu Mon Jul 12 01:51:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 11 Jul 2010 23:51:43 +0000 Subject: [M3devel] gcc 4.5 Message-ID: I'm inclined to make gcc 4.5 the default backend very soon. AMD64_DARWIN, I386_LINUX, SOLgnu are looking ok. ? I could also test PPC, like PPC_LINUX. SOLgnu leaves everything volatile (same as 4.3) so maybe isn't much validation. I doubt there is much value in testing other operating systems, mainly just other processors. ?? Though there is sometimes, e.g. I think I386_DARWIN uses sse for floating point and other I386 systems don't. ?? I should also test SPARC_LINUX to get sparc w/o volatile. There are many other targets. OpenBSD, NetBSD, FreeBSD, OSF/1, I386/AMD64_SOLARIS, ARMEL_LINUX, Cygwin, MinGW, etc. Others can test them? There is some downside, in particular I disable more optimization at -O3 than with gcc 4.3. One of the additional optimizations perhaps doesn't exist in 4.3 though. The label/barrier thing still isn't resolved. I haven't run through m3-sys/m3tests. But that the system can build itself is a good sign, though sometimes I overvalue it. And I tested some gui apps at least unoptimized. The "man vs. boy" test works. The 4.3 backend will remain available via cm3 -DGCC43 in the m3cc directory. ? You have to be careful about cm3cfg.common probing around and finding the intended one, ? such as by deleting all others. ?- Jay From hosking at cs.purdue.edu Mon Jul 12 02:52:25 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 11 Jul 2010 20:52:25 -0400 Subject: [M3devel] barrier labels? In-Reply-To: References: , Message-ID: <08509C7F-5EC5-4679-8094-6985A70CC7C6@cs.purdue.edu> No, that code came from 4.x... On 11 Jul 2010, at 19:41, Jay K wrote: > > Tony, thanks for the pointer..though I haven't been able to find it yet. > I also looked for related code in 3.3 and 3.4, as I think 3.3 was current at the time. > > - Jay > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Sun, 11 Jul 2010 16:25:41 -0400 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] barrier labels? >> >> I extracted that usage from what C++ was doing for exception labels. The point is to make sure that flow analysis knows that the exception handler label targets are important "non-local" label targets. I do remember that DECL_NONLOCAL was *not* the right thing to do (that is used for proper non-local outer-scope goto targets for nested functions) and I remember the SP hacks being used with that (they need to recover from targeting from an inner-scope function and clean up the stack accordingly). I suggest poking around in what the C++ exception handling now does with table-driven exception targets. >> >> On 11 Jul 2010, at 07:46, Jay K wrote: >> >>> >>> Tony, six years ago you introduce what is now: >>> >>> >>> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c.diff?r1=1.5;r2=1.6 >>> >>> >>> static void >>> m3cg_set_label (void) >>> { >>> ... >>> if (barrier) >>> { >>> ... >>> { >>> rtx list = DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels; >>> DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels >>> = gen_rtx_EXPR_LIST (VOIDmode, r, list); >>> } >>> ... >>> >>> >>> I'm not sure what to do here for gcc 4.5. >>> The data has moved around and isn't available this early. I suppose we could hang some information on and >>> deal with it later in compilation. >>> >>> >>> DECL_NONLOCAL(l) = true; seems promising, but it caused very bad code to be produced (incorrect, not inefficient). >>> I didn't look into why. The bad code was changing the stack pointer where it should leave it alone. >>> >>> >>> gcc-4.5 is working for me now (cm3 built with it can built itself), at least with -O1, AMD64_DARWIN. >>> And Juno/mentor/tetris work without optimization, I'll test optimized later. >>> Next I'll test -O2, -O3, m3-sys/m3tests. >>> >>> >>> Do we have good exception handling tests? >>> I know that cm3 uses exceptions, like, looking for cm3.cfg. >>> >>> >>> I'll poke around more.. >>> >>> >>> - Jay >>> >> > From jay.krell at cornell.edu Mon Jul 12 03:58:52 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 12 Jul 2010 01:58:52 +0000 Subject: [M3devel] import from same .so or not Message-ID: It seems to me, an important bit of information is not provided to the backend. The backend is told "import" or "export". But this is about "modules", .m3 files to .m3 files. It isn't about .so files to .so files, or .dlls to .dlls. It's really tristate, not boolean: ? private to just this source file? ? private to this source file and those it statically links to ? public for all Granted, you might statically link "everything". There isn't enforcement of the middle state, and symbols still need to be as unique as the third state. But it is definitely useful. In particular we don't use DECL_VISIBILITY (p) = VISIBILITY_HIDDEN enough. ? For a long time we never used it. e.g. in the release branch. Agreed? Anyone volunteer to fix? Or mind if I try? ?- Jay From jay.krell at cornell.edu Mon Jul 12 05:03:58 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 12 Jul 2010 03:03:58 +0000 Subject: [M3devel] barrier labels? In-Reply-To: <08509C7F-5EC5-4679-8094-6985A70CC7C6@cs.purdue.edu> References: , , , , <08509C7F-5EC5-4679-8094-6985A70CC7C6@cs.purdue.edu> Message-ID: I still don't see it, in the C++ frontend. There is: void expand_label (tree label) { ... ? if (DECL_NONLOCAL (label)) ??? { ... ???? nonlocal_goto_handler_labels ??? = gen_rtx_EXPR_LIST (VOIDmode, label_r, ??? ??? ??? ???? nonlocal_goto_handler_labels); ??? } but I don't think this works until later. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Sun, 11 Jul 2010 20:52:25 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] barrier labels? > > No, that code came from 4.x... > > > > > On 11 Jul 2010, at 19:41, Jay K wrote: > > > > > Tony, thanks for the pointer..though I haven't been able to find it yet. > > I also looked for related code in 3.3 and 3.4, as I think 3.3 was current at the time. > > > > - Jay > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Sun, 11 Jul 2010 16:25:41 -0400 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] barrier labels? > >> > >> I extracted that usage from what C++ was doing for exception labels. The point is to make sure that flow analysis knows that the exception handler label targets are important "non-local" label targets. I do remember that DECL_NONLOCAL was *not* the right thing to do (that is used for proper non-local outer-scope goto targets for nested functions) and I remember the SP hacks being used with that (they need to recover from targeting from an inner-scope function and clean up the stack accordingly). I suggest poking around in what the C++ exception handling now does with table-driven exception targets. > >> > >> On 11 Jul 2010, at 07:46, Jay K wrote: > >> > >>> > >>> Tony, six years ago you introduce what is now: > >>> > >>> > >>> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c.diff?r1=1.5;r2=1.6 > >>> > >>> > >>> static void > >>> m3cg_set_label (void) > >>> { > >>> ... > >>> if (barrier) > >>> { > >>> ... > >>> { > >>> rtx list = DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels; > >>> DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels > >>> = gen_rtx_EXPR_LIST (VOIDmode, r, list); > >>> } > >>> ... > >>> > >>> > >>> I'm not sure what to do here for gcc 4.5. > >>> The data has moved around and isn't available this early. I suppose we could hang some information on and > >>> deal with it later in compilation. > >>> > >>> > >>> DECL_NONLOCAL(l) = true; seems promising, but it caused very bad code to be produced (incorrect, not inefficient). > >>> I didn't look into why. The bad code was changing the stack pointer where it should leave it alone. > >>> > >>> > >>> gcc-4.5 is working for me now (cm3 built with it can built itself), at least with -O1, AMD64_DARWIN. > >>> And Juno/mentor/tetris work without optimization, I'll test optimized later. > >>> Next I'll test -O2, -O3, m3-sys/m3tests. > >>> > >>> > >>> Do we have good exception handling tests? > >>> I know that cm3 uses exceptions, like, looking for cm3.cfg. > >>> > >>> > >>> I'll poke around more.. > >>> > >>> > >>> - Jay > >>> > >> > > > From hosking at cs.purdue.edu Mon Jul 12 15:28:43 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jul 2010 09:28:43 -0400 Subject: [M3devel] import from same .so or not In-Reply-To: References: Message-ID: It seems to me this would require massive reworking of the build infrastructure! On 11 Jul 2010, at 21:58, Jay K wrote: > > It seems to me, an important bit of information is not provided to the backend. > > The backend is told "import" or "export". > But this is about "modules", .m3 files to .m3 files. > > It isn't about .so files to .so files, or .dlls to .dlls. > > It's really tristate, not boolean: > private to just this source file > private to this source file and those it statically links to > public for all > > Granted, you might statically link "everything". > There isn't enforcement of the middle state, and symbols still need to be as unique as the third state. > But it is definitely useful. > > In particular we don't use DECL_VISIBILITY (p) = VISIBILITY_HIDDEN enough. > For a long time we never used it. e.g. in the release branch. > > Agreed? > Anyone volunteer to fix? > Or mind if I try? > > > - Jay > > From hosking at cs.purdue.edu Mon Jul 12 15:43:01 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jul 2010 09:43:01 -0400 Subject: [M3devel] barrier labels? In-Reply-To: References: , , , , <08509C7F-5EC5-4679-8094-6985A70CC7C6@cs.purdue.edu> Message-ID: Perhaps we just need FORCED_LABEL for these: /* In a LABEL_DECL, nonzero means this label had its address taken and therefore can never be deleted and is a jump target for computed gotos. */ On 11 Jul 2010, at 23:03, Jay K wrote: > > I still don't see it, in the C++ frontend. > > There is: > > void > expand_label (tree label) > { > ... > if (DECL_NONLOCAL (label)) > { > ... nonlocal_goto_handler_labels > = gen_rtx_EXPR_LIST (VOIDmode, label_r, > nonlocal_goto_handler_labels); > } > > but I don't think this works until later. > > - Jay > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Sun, 11 Jul 2010 20:52:25 -0400 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] barrier labels? >> >> No, that code came from 4.x... >> >> >> >> >> On 11 Jul 2010, at 19:41, Jay K wrote: >> >>> >>> Tony, thanks for the pointer..though I haven't been able to find it yet. >>> I also looked for related code in 3.3 and 3.4, as I think 3.3 was current at the time. >>> >>> - Jay >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> Date: Sun, 11 Jul 2010 16:25:41 -0400 >>>> To: jay.krell at cornell.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] barrier labels? >>>> >>>> I extracted that usage from what C++ was doing for exception labels. The point is to make sure that flow analysis knows that the exception handler label targets are important "non-local" label targets. I do remember that DECL_NONLOCAL was *not* the right thing to do (that is used for proper non-local outer-scope goto targets for nested functions) and I remember the SP hacks being used with that (they need to recover from targeting from an inner-scope function and clean up the stack accordingly). I suggest poking around in what the C++ exception handling now does with table-driven exception targets. >>>> >>>> On 11 Jul 2010, at 07:46, Jay K wrote: >>>> >>>>> >>>>> Tony, six years ago you introduce what is now: >>>>> >>>>> >>>>> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c.diff?r1=1.5;r2=1.6 >>>>> >>>>> >>>>> static void >>>>> m3cg_set_label (void) >>>>> { >>>>> ... >>>>> if (barrier) >>>>> { >>>>> ... >>>>> { >>>>> rtx list = DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels; >>>>> DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels >>>>> = gen_rtx_EXPR_LIST (VOIDmode, r, list); >>>>> } >>>>> ... >>>>> >>>>> >>>>> I'm not sure what to do here for gcc 4.5. >>>>> The data has moved around and isn't available this early. I suppose we could hang some information on and >>>>> deal with it later in compilation. >>>>> >>>>> >>>>> DECL_NONLOCAL(l) = true; seems promising, but it caused very bad code to be produced (incorrect, not inefficient). >>>>> I didn't look into why. The bad code was changing the stack pointer where it should leave it alone. >>>>> >>>>> >>>>> gcc-4.5 is working for me now (cm3 built with it can built itself), at least with -O1, AMD64_DARWIN. >>>>> And Juno/mentor/tetris work without optimization, I'll test optimized later. >>>>> Next I'll test -O2, -O3, m3-sys/m3tests. >>>>> >>>>> >>>>> Do we have good exception handling tests? >>>>> I know that cm3 uses exceptions, like, looking for cm3.cfg. >>>>> >>>>> >>>>> I'll poke around more.. >>>>> >>>>> >>>>> - Jay >>>>> >>>> >>> >> > From jay.krell at cornell.edu Tue Jul 13 01:53:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 12 Jul 2010 23:53:57 +0000 Subject: [M3devel] import from same .so or not In-Reply-To: References: , Message-ID: I don't know. I hope not. The information is there: lowercase interface vs. uppercase Interface, lowercase module vs. uppercase Module, derived_interface(hidden or private). I haven't looked at where all it is sent around. - Jay > Subject: Re: [M3devel] import from same .so or not > From: hosking at cs.purdue.edu > Date: Mon, 12 Jul 2010 09:28:43 -0400 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > It seems to me this would require massive reworking of the build infrastructure! > > On 11 Jul 2010, at 21:58, Jay K wrote: > > > > > It seems to me, an important bit of information is not provided to the backend. > > > > The backend is told "import" or "export". > > But this is about "modules", .m3 files to .m3 files. > > > > It isn't about .so files to .so files, or .dlls to .dlls. > > > > It's really tristate, not boolean: > > private to just this source file > > private to this source file and those it statically links to > > public for all > > > > Granted, you might statically link "everything". > > There isn't enforcement of the middle state, and symbols still need to be as unique as the third state. > > But it is definitely useful. > > > > In particular we don't use DECL_VISIBILITY (p) = VISIBILITY_HIDDEN enough. > > For a long time we never used it. e.g. in the release branch. > > > > Agreed? > > Anyone volunteer to fix? > > Or mind if I try? > > > > > > - Jay > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Jul 13 02:14:39 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jul 2010 20:14:39 -0400 Subject: [M3devel] import from same .so or not In-Reply-To: References: , Message-ID: <9241B253-8004-4DDD-B1EF-A7D02A3FEAFD@cs.purdue.edu> There question is where and how to communicate it back to gcc. Does it mean putting all the module units on the same command line for compilation by a single instance of cm3cg? Or do you communicate it some other way? On 12 Jul 2010, at 19:53, Jay K wrote: > I don't know. I hope not. The information is there: lowercase interface vs. uppercase Interface, lowercase module vs. uppercase Module, derived_interface(hidden or private). > I haven't looked at where all it is sent around. > > - Jay > > > > Subject: Re: [M3devel] import from same .so or not > > From: hosking at cs.purdue.edu > > Date: Mon, 12 Jul 2010 09:28:43 -0400 > > CC: m3devel at elegosoft.com > > To: jay.krell at cornell.edu > > > > It seems to me this would require massive reworking of the build infrastructure! > > > > On 11 Jul 2010, at 21:58, Jay K wrote: > > > > > > > > It seems to me, an important bit of information is not provided to the backend. > > > > > > The backend is told "import" or "export". > > > But this is about "modules", .m3 files to .m3 files. > > > > > > It isn't about .so files to .so files, or .dlls to .dlls. > > > > > > It's really tristate, not boolean: > > > private to just this source file > > > private to this source file and those it statically links to > > > public for all > > > > > > Granted, you might statically link "everything". > > > There isn't enforcement of the middle state, and symbols still need to be as unique as the third state. > > > But it is definitely useful. > > > > > > In particular we don't use DECL_VISIBILITY (p) = VISIBILITY_HIDDEN enough. > > > For a long time we never used it. e.g. in the release branch. > > > > > > Agreed? > > > Anyone volunteer to fix? > > > Or mind if I try? > > > > > > > > > - Jay > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 13 02:50:47 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 13 Jul 2010 00:50:47 +0000 Subject: [M3devel] import from same .so or not In-Reply-To: <9241B253-8004-4DDD-B1EF-A7D02A3FEAFD@cs.purdue.edu> References: , , <9241B253-8004-4DDD-B1EF-A7D02A3FEAFD@cs.purdue.edu> Message-ID: I think it'd be another boolean or expansion of a boolean to an integer to declare/import/begin_procedure/constant/variable. Not passing all the files at once. Passing all the files at once is attractive for reasons of compilation perf and optimizing codegen but I believe it requires a lot of other work. Similarly, passing all the C files at once to the C compiler is also attractive, and more work. LTCG/LTO provide similar benefits, but we aren't setup to use LTO and honestly I'm trying to ignore it. I'll settle for -O1/2/3. - Jay Subject: Re: [M3devel] import from same .so or not From: hosking at cs.purdue.edu Date: Mon, 12 Jul 2010 20:14:39 -0400 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu There question is where and how to communicate it back to gcc. Does it mean putting all the module units on the same command line for compilation by a single instance of cm3cg? Or do you communicate it some other way? On 12 Jul 2010, at 19:53, Jay K wrote: I don't know. I hope not. The information is there: lowercase interface vs. uppercase Interface, lowercase module vs. uppercase Module, derived_interface(hidden or private). I haven't looked at where all it is sent around. - Jay > Subject: Re: [M3devel] import from same .so or not > From: hosking at cs.purdue.edu > Date: Mon, 12 Jul 2010 09:28:43 -0400 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > It seems to me this would require massive reworking of the build infrastructure! > > On 11 Jul 2010, at 21:58, Jay K wrote: > > > > > It seems to me, an important bit of information is not provided to the backend. > > > > The backend is told "import" or "export". > > But this is about "modules", .m3 files to .m3 files. > > > > It isn't about .so files to .so files, or .dlls to .dlls. > > > > It's really tristate, not boolean: > > private to just this source file > > private to this source file and those it statically links to > > public for all > > > > Granted, you might statically link "everything". > > There isn't enforcement of the middle state, and symbols still need to be as unique as the third state. > > But it is definitely useful. > > > > In particular we don't use DECL_VISIBILITY (p) = VISIBILITY_HIDDEN enough. > > For a long time we never used it. e.g. in the release branch. > > > > Agreed? > > Anyone volunteer to fix? > > Or mind if I try? > > > > > > - Jay > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Tue Jul 13 05:35:19 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Mon, 12 Jul 2010 23:35:19 -0400 Subject: [M3devel] still having compile problems with HEAD branch Message-ID: I'm still unable to build the HEAD branch on Windows. I'm getting some version mismatch errors early on in the build process. Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 13 06:36:01 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 13 Jul 2010 04:36:01 +0000 Subject: [M3devel] still having compile problems with HEAD branch In-Reply-To: References: Message-ID: Randy, you probably need to go back to a working state, such as by reinstalling a release, and restart upgrade.py. - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com Date: Mon, 12 Jul 2010 23:35:19 -0400 Subject: [M3devel] still having compile problems with HEAD branch I?m still unable to build the HEAD branch on Windows. I?m getting some version mismatch errors early on in the build process. Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 13 08:38:05 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 13 Jul 2010 06:38:05 +0000 Subject: [M3devel] barrier labels? In-Reply-To: References: , , , , , , , <08509C7F-5EC5-4679-8094-6985A70CC7C6@cs.purdue.edu>, , Message-ID: I don't know. There is so much unknown here. It is frustrating and difficult. We could use an extensive set of test cases. ? Or know more about the test cases we do have. And it'd be nice to see if anything varies in the 4.3 path if we put the labels on that list or not. tangent: I'd like automation that compiles the whole system, multiple architectures, and puts all the *s files in one flat directory per architecture. I guess it's just a matter of a little code. ??? It should just skip the few errors that are cross problems, which I should fix anyway. ??? That particular problem makes me a little nervous, but I suppose I can code it to use both INTEGER and Target.Int ?? ??? if doing a native build, and assert that the results match. I hit a snag yesterday, can't build any tests (just to assembly) without first shipping m3core/libm3. Can't ship m3core/libm3 for cross building. I guess, and I forgot this, I should have used -x for override. Duh. That's why I tried I386_DARWIN for some current 4.5 problems vs. SOLgnu, to escape cross building. Oops. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Mon, 12 Jul 2010 09:43:01 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] barrier labels? > > Perhaps we just need FORCED_LABEL for these: > > /* In a LABEL_DECL, nonzero means this label had its address taken > and therefore can never be deleted and is a jump target for > computed gotos. */ > > > On 11 Jul 2010, at 23:03, Jay K wrote: > > > > > I still don't see it, in the C++ frontend. > > > > There is: > > > > void > > expand_label (tree label) > > { > > ... > > if (DECL_NONLOCAL (label)) > > { > > ... nonlocal_goto_handler_labels > > = gen_rtx_EXPR_LIST (VOIDmode, label_r, > > nonlocal_goto_handler_labels); > > } > > > > but I don't think this works until later. > > > > - Jay > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Sun, 11 Jul 2010 20:52:25 -0400 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] barrier labels? > >> > >> No, that code came from 4.x... > >> > >> > >> > >> > >> On 11 Jul 2010, at 19:41, Jay K wrote: > >> > >>> > >>> Tony, thanks for the pointer..though I haven't been able to find it yet. > >>> I also looked for related code in 3.3 and 3.4, as I think 3.3 was current at the time. > >>> > >>> - Jay > >>> > >>> ---------------------------------------- > >>>> From: hosking at cs.purdue.edu > >>>> Date: Sun, 11 Jul 2010 16:25:41 -0400 > >>>> To: jay.krell at cornell.edu > >>>> CC: m3devel at elegosoft.com > >>>> Subject: Re: [M3devel] barrier labels? > >>>> > >>>> I extracted that usage from what C++ was doing for exception labels. The point is to make sure that flow analysis knows that the exception handler label targets are important "non-local" label targets. I do remember that DECL_NONLOCAL was *not* the right thing to do (that is used for proper non-local outer-scope goto targets for nested functions) and I remember the SP hacks being used with that (they need to recover from targeting from an inner-scope function and clean up the stack accordingly). I suggest poking around in what the C++ exception handling now does with table-driven exception targets. > >>>> > >>>> On 11 Jul 2010, at 07:46, Jay K wrote: > >>>> > >>>>> > >>>>> Tony, six years ago you introduce what is now: > >>>>> > >>>>> > >>>>> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c.diff?r1=1.5;r2=1.6 > >>>>> > >>>>> > >>>>> static void > >>>>> m3cg_set_label (void) > >>>>> { > >>>>> ... > >>>>> if (barrier) > >>>>> { > >>>>> ... > >>>>> { > >>>>> rtx list = DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels; > >>>>> DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels > >>>>> = gen_rtx_EXPR_LIST (VOIDmode, r, list); > >>>>> } > >>>>> ... > >>>>> > >>>>> > >>>>> I'm not sure what to do here for gcc 4.5. > >>>>> The data has moved around and isn't available this early. I suppose we could hang some information on and > >>>>> deal with it later in compilation. > >>>>> > >>>>> > >>>>> DECL_NONLOCAL(l) = true; seems promising, but it caused very bad code to be produced (incorrect, not inefficient). > >>>>> I didn't look into why. The bad code was changing the stack pointer where it should leave it alone. > >>>>> > >>>>> > >>>>> gcc-4.5 is working for me now (cm3 built with it can built itself), at least with -O1, AMD64_DARWIN. > >>>>> And Juno/mentor/tetris work without optimization, I'll test optimized later. > >>>>> Next I'll test -O2, -O3, m3-sys/m3tests. > >>>>> > >>>>> > >>>>> Do we have good exception handling tests? > >>>>> I know that cm3 uses exceptions, like, looking for cm3.cfg. > >>>>> > >>>>> > >>>>> I'll poke around more.. > >>>>> > >>>>> > >>>>> - Jay > >>>>> > >>>> > >>> > >> > > > From mika at async.async.caltech.edu Tue Jul 13 10:11:58 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Tue, 13 Jul 2010 01:11:58 -0700 Subject: [M3devel] "FreeBSD4" false advertising Message-ID: <20100713081158.D3E221A20A4@async.async.caltech.edu> Hi Modula-3ers, I am again (for the "umpteenth" time) attempting to move a medium-sized under-development software repository from PM3 to CM3. Things are looking better! But of course there is one snake in paradise. Can I upgrade the software without installing new OSes as well (at the same time)? The installation archive marked "FreeBSD4" does *not* work on FreeBSD 4/i386 nor on FreeBSD 5. Is it from 6 or 7? As I have mentioned before, FreeBSD is pretty good about being backward-compatible (FreeBSD 4 binaries and even compilers will work fine on 5 or 6), but it's not at all forwards-compatible. You simply cannot compile something on FreeBSD 6 and expect it to work on an earlier release of the OS. I have the following on a bona fide FreeBSD 4.11-RELEASE system: (62)trs80:~>cm3 -version Critical Mass Modula-3 version d0.0.0 last updated: unknown compiled: 2009-04-25 02:28:01 configuration: /usr/local/cm3/bin/cm3.cfg (63)trs80:~> My bootstrapping instructions I received from Tony do not work. Quake has changed so I get an error even cm3 trying to read the m3makefiles.... so how would I go about bootstrapping the latest CM3 on this? I wouldn't trust Python on it either. (I have Python but an old old version.) Yes I do want to get rid of FreeBSD-4.11 but one thing at a time would be my preference. Right now I seem to have all the software happy with CM3 (for once!) Mika From wagner at elegosoft.com Tue Jul 13 11:11:31 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 13 Jul 2010 11:11:31 +0200 Subject: [M3devel] "FreeBSD4" false advertising Message-ID: <20100713111131.lf9wqsz9eo0ckko0@mail.elegosoft.com> Quoting Mika Nystrom : > Hi Modula-3ers, > > I am again (for the "umpteenth" time) attempting to move a medium-sized > under-development software repository from PM3 to CM3. Things are looking > better! > > But of course there is one snake in paradise. Can I upgrade the software > without installing new OSes as well (at the same time)? > > The installation archive marked "FreeBSD4" does *not* work on FreeBSD 4/i386 > nor on FreeBSD 5. Is it from 6 or 7? > > As I have mentioned before, FreeBSD is pretty good about being > backward-compatible (FreeBSD 4 binaries and even compilers will work fine > on 5 or 6), but it's not at all forwards-compatible. You simply cannot > compile something on FreeBSD 6 and expect it to work on an earlier release > of the OS. Hi Mika, you're completely right about that. The name FreeBSD4 is currently wrong; nobody has added a new platform for every new release of FreeBSD since the time 4.x came out. It should long have been renamed to I386_FREEBSD. We also need to document the actual OS version an installation archive has been built on. I'll try to do that for the next release, but for 5.8 I think we simply need to rename and/or document the build systems (probably not before tomorrow evening though). The FreeBSD4 archives are actually built on a FreeBSD 6 system: FreeBSD new.elego.de 6.4-RELEASE-p5 FreeBSD 6.4-RELEASE-p5 #1: Sun Jun 14 14:03:37 CEST 2009 I'll try to rename them on birch, at least for the release and RC5, but I'm afraid I haven't got an actual FreeBSD 4.x system for build purposes anymore. The last version that may be directly useful I find on the web pages is FreeBSD 4.x and later: cm3-min-POSIX-FreeBSD4-d5.5.0.tgz (built on FreeBSD 4.11 i686) at http://www.modula3.com/cm3/cm3-min-POSIX-FreeBSD4-d5.5.0.tgz This could be used together with the upgrade.sh script to built the 5.8 release sources. > I have the following on a bona fide FreeBSD 4.11-RELEASE system: > > (62)trs80:~>cm3 -version > Critical Mass Modula-3 version d0.0.0 > last updated: unknown > compiled: 2009-04-25 02:28:01 > configuration: /usr/local/cm3/bin/cm3.cfg As the version string is actually undefined, this doesn't tell us very much :-( > (63)trs80:~> > > My bootstrapping instructions I received from Tony do not work. Quake has > changed so I get an error even cm3 trying to read the m3makefiles.... so > how would I go about bootstrapping the latest CM3 on this? I wouldn't > trust Python on it either. (I have Python but an old old version.) What exactly is the error you get? Can you try with the installation archives mentioned above? > Yes I do want to get rid of FreeBSD-4.11 but one thing at a time would be > my preference. Right now I seem to have all the software happy with CM3 > (for once!) I'd like to provide real FreeBSD4 archives, so if you get it to work, I'd ask you to run scripts/make-dist.sh to build and ship them (after the current FreeBSD4 archives have been renamed). If you get stuck, I'll try to help as I can; if you can provide remote access, I'd even try to build a working system myself. Sorry for the inconveniences, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 mika at async.async.caltech.edu Tue Jul 13 11:20:43 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Tue, 13 Jul 2010 02:20:43 -0700 Subject: [M3devel] "FreeBSD4" false advertising In-Reply-To: <20100713111131.lf9wqsz9eo0ckko0@mail.elegosoft.com> References: <20100713111131.lf9wqsz9eo0ckko0@mail.elegosoft.com> Message-ID: <20100713092043.808181A20A2@async.async.caltech.edu> Olaf Wagner writes: ... >FreeBSD 4.x and later: cm3-min-POSIX-FreeBSD4-d5.5.0.tgz >(built on FreeBSD 4.11 i686) at > > http://www.modula3.com/cm3/cm3-min-POSIX-FreeBSD4-d5.5.0.tgz > >This could be used together with the upgrade.sh script to built the >5.8 release sources. > >> I have the following on a bona fide FreeBSD 4.11-RELEASE system: >> >> (62)trs80:~>cm3 -version >> Critical Mass Modula-3 version d0.0.0 >> last updated: unknown >> compiled: 2009-04-25 02:28:01 >> configuration: /usr/local/cm3/bin/cm3.cfg > >As the version string is actually undefined, this doesn't tell us very =20 >much :-( Olaf, I'm pretty sure that release archive is a tarred up version of my system. (I built it on this machine!) How do I use upgrade.sh? I've been doing things manually following Tony's recommendations from a few years ago and that doesn't work. Well I'll try the obvious thing :-) Mika From jay.krell at cornell.edu Tue Jul 13 12:33:46 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 13 Jul 2010 10:33:46 +0000 Subject: [M3devel] "FreeBSD4" false advertising In-Reply-To: <20100713092043.808181A20A2@async.async.caltech.edu> References: <20100713111131.lf9wqsz9eo0ckko0@mail.elegosoft.com>, <20100713092043.808181A20A2@async.async.caltech.edu> Message-ID: The compatibility story on FreeBSD and some uncertain others is incredibly disappointing. When I build something on Windows 7, by default it works on older Windows systems. The ABI doesn't change. New functions are added. "Behavioral compability", *that* is the tricky part. Apple does similar, but also a hybrid of the "Unix model". Anyway, just do a cross build. It is fairly easy. ? If it is too hard, complain and suggest changes. Get the current source on the FreeBSD 4 machine and on nearly any other machine. ?? They don't actually have to be identical, I believe, because this won't be an "upgrade" but ??? eventually on the target will build up the entire system from "scratch", from just cm3, no libraries, ??? and cm3 no longer is tied to the libraries it is building at all (it used to be, it was bad). The second machine should have a working cm3. You can download a release. cd scripts/python ./boot1.py FreeBSD4 ?or ./boot1.py I386_FREEBSD wait a bit you'll have cme-boot-I386_FREEBSD-timestamp.tgz or such. Copy (scp) that to the FreeBSD 4 machine. Extract it. cd into it. Maybe look at the top of Makefile. ?Sometimes it isn't quite right. Using autoconf/libtool just a bit here is a good idea for future. make, maybe gnumake or gmake, though it is a very simple Makefile. result is cm3 in current directory ? ./cm3 ? It should say "unable to find cm3.cfg". ? If so, good, continue. ? If not, something didn't work and you'll have to investigate. mkdir -p $HOME/cm3/bin?? # or whatever cp cm3 $HOME/cm3/bin export PATH=$HOME/cm3/bin:$PATH cd scripts/python ./boot2.sh wait a while, a while result should be a working system, that built itself as well (look at boot2.sh) http://modula3.elegosoft.com/cm3/uploaded-archives/index.html You should be able to start from here: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-FreeBSD4-1.tar.gz or, er...here http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-FreeBSD4-1-userthreads.tar.gz Does FreeBSD4 have any sort of pthreads? If not, in the above instructions, you will need to make an edit in m3-libs/m3core/src/thread.quake. In the current tree, it looks pretty obvious what to do, since it is here that OpenBSD is pointed at user threads. In head,? I have added support and significantly tested a bunch of "fixed names": ? I386_LINUX, I386_FREEBSD, I386_NETBSD, I386_NT, I386_CYGWIN, I386_MINGW. Did I miss any? These are good names, right? esp. the last three? The one lagging point though is what to do about "SPARC32_SOLARIS". I think probably use cc by default but make swtiching to gcc just be a one line change in the config file. Maybe provide config files SPARC32_SOLARIS and SPARC32_SOLARIS_gcc. ?But they'd have the same TARGET and BUILD_DIR: SPARC32_SOLARIS. And maybe it should be SPARC_SOLARIS. ?- Jay ---------------------------------------- > To: wagner at elegosoft.com > Date: Tue, 13 Jul 2010 02:20:43 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] "FreeBSD4" false advertising > > Olaf Wagner writes: > ... > >FreeBSD 4.x and later: cm3-min-POSIX-FreeBSD4-d5.5.0.tgz > >(built on FreeBSD 4.11 i686) at > > > > http://www.modula3.com/cm3/cm3-min-POSIX-FreeBSD4-d5.5.0.tgz > > > >This could be used together with the upgrade.sh script to built the > >5.8 release sources. > > > >> I have the following on a bona fide FreeBSD 4.11-RELEASE system: > >> > >> (62)trs80:~>cm3 -version > >> Critical Mass Modula-3 version d0.0.0 > >> last updated: unknown > >> compiled: 2009-04-25 02:28:01 > >> configuration: /usr/local/cm3/bin/cm3.cfg > > > >As the version string is actually undefined, this doesn't tell us very =20 > >much :-( > > Olaf, I'm pretty sure that release archive is a tarred up version of my > system. (I built it on this machine!) > > How do I use upgrade.sh? I've been doing things manually following Tony's > recommendations from a few years ago and that doesn't work. > > Well I'll try the obvious thing :-) > > Mika From hosking at cs.purdue.edu Tue Jul 13 16:36:11 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 13 Jul 2010 10:36:11 -0400 Subject: [M3devel] import from same .so or not In-Reply-To: References: , , <9241B253-8004-4DDD-B1EF-A7D02A3FEAFD@cs.purdue.edu> Message-ID: <76827F66-451E-410E-9AF0-200D9538AFA1@cs.purdue.edu> OK, so what you want is for the build system (cm3/src/M3Build.m3) to pass a flag saying that a given module is package visible. Shouldn't be too hard to do. On 12 Jul 2010, at 20:50, Jay K wrote: > I think it'd be another boolean or expansion of a boolean to an integer to declare/import/begin_procedure/constant/variable. > Not passing all the files at once. > > > Passing all the files at once is attractive for reasons of compilation perf and optimizing codegen but I believe it requires a lot of other work. > > > Similarly, passing all the C files at once to the C compiler is also attractive, and more work. > > > LTCG/LTO provide similar benefits, but we aren't setup to use LTO and honestly I'm trying to ignore it. > I'll settle for -O1/2/3. > > > - Jay > > Subject: Re: [M3devel] import from same .so or not > From: hosking at cs.purdue.edu > Date: Mon, 12 Jul 2010 20:14:39 -0400 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > There question is where and how to communicate it back to gcc. Does it mean putting all the module units on the same command line for compilation by a single instance of cm3cg? Or do you communicate it some other way? > > On 12 Jul 2010, at 19:53, Jay K wrote: > > I don't know. I hope not. The information is there: lowercase interface vs. uppercase Interface, lowercase module vs. uppercase Module, derived_interface(hidden or private). > I haven't looked at where all it is sent around. > > - Jay > > > > Subject: Re: [M3devel] import from same .so or not > > From: hosking at cs.purdue.edu > > Date: Mon, 12 Jul 2010 09:28:43 -0400 > > CC: m3devel at elegosoft.com > > To: jay.krell at cornell.edu > > > > It seems to me this would require massive reworking of the build infrastructure! > > > > On 11 Jul 2010, at 21:58, Jay K wrote: > > > > > > > > It seems to me, an important bit of information is not provided to the backend. > > > > > > The backend is told "import" or "export". > > > But this is about "modules", .m3 files to .m3 files. > > > > > > It isn't about .so files to .so files, or .dlls to .dlls. > > > > > > It's really tristate, not boolean: > > > private to just this source file > > > private to this source file and those it statically links to > > > public for all > > > > > > Granted, you might statically link "everything". > > > There isn't enforcement of the middle state, and symbols still need to be as unique as the third state. > > > But it is definitely useful. > > > > > > In particular we don't use DECL_VISIBILITY (p) = VISIBILITY_HIDDEN enough. > > > For a long time we never used it. e.g. in the release branch. > > > > > > Agreed? > > > Anyone volunteer to fix? > > > Or mind if I try? > > > > > > > > > - Jay > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at wickensonline.co.uk Tue Jul 13 21:19:15 2010 From: mark at wickensonline.co.uk (Mark Wickens) Date: Tue, 13 Jul 2010 20:19:15 +0100 Subject: [M3devel] CM3 on Alpha tru64 4.0G In-Reply-To: <76827F66-451E-410E-9AF0-200D9538AFA1@cs.purdue.edu> References: , , <9241B253-8004-4DDD-B1EF-A7D02A3FEAFD@cs.purdue.edu> <76827F66-451E-410E-9AF0-200D9538AFA1@cs.purdue.edu> Message-ID: <1279048755.1793.13.camel@x60.appsoftint.co.uk> Hi Guys, I've been trying unsuccessfully to build various version of Modula-3 (DEC-SRC, PM3, CM3) on a DEC Alpha 300 running tru64 4.0G and was wondering whether anyone could give some guidance of what is possible, indeed sensible. I've received a couple of helpful emails for Daniel, but what I'd really like clarified are the following: 1. Is this sensible, or is tru64 5+ the only realistic tru64 platform to attempt? 2. The executables for tru64 uploaded to the opencm3 website in cm3-min-ALPHA_OSF-d5.8.2-20100612.tar.gz don't work for me - I get a decthreads exception. Does anyone know what version of tru64 these were built with? 3. Is it possible to build CM3 from scratch, or do I need some version of the M3 build tools? Many thanks for the help. I used DEC-SRC Modula-3 around 1995 and am trying to get it compiled up for a recent project, but on an original platform. Some may call me crazy, and they'd be totally justified. I'm not sure whether back-in-the-day I had it running on tru64 (well back then it would have been Digital Unix 3.2C) or whether it was on a linux box. Thanks for the help, Mark. From hosking at cs.purdue.edu Tue Jul 13 22:31:39 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 13 Jul 2010 16:31:39 -0400 Subject: [M3devel] CM3 on Alpha tru64 4.0G In-Reply-To: <1279048755.1793.13.camel@x60.appsoftint.co.uk> References: , , <9241B253-8004-4DDD-B1EF-A7D02A3FEAFD@cs.purdue.edu> <76827F66-451E-410E-9AF0-200D9538AFA1@cs.purdue.edu> <1279048755.1793.13.camel@x60.appsoftint.co.uk> Message-ID: <8E02058D-1A62-48FF-8DA7-B2C40C53B048@cs.purdue.edu> This should be entirely doable, so long as reasonable pthread APIs exist on 4.x Tru64. What was the decthreads exception? On 13 Jul 2010, at 15:19, Mark Wickens wrote: > Hi Guys, > > I've been trying unsuccessfully to build various version of Modula-3 > (DEC-SRC, PM3, CM3) on a DEC Alpha 300 running tru64 4.0G and was > wondering whether anyone could give some guidance of what is possible, > indeed sensible. > > I've received a couple of helpful emails for Daniel, but what I'd really > like clarified are the following: > > 1. Is this sensible, or is tru64 5+ the only realistic tru64 platform to > attempt? > > 2. The executables for tru64 uploaded to the opencm3 website in > cm3-min-ALPHA_OSF-d5.8.2-20100612.tar.gz don't work for me - I get a > decthreads exception. Does anyone know what version of tru64 these were > built with? > > 3. Is it possible to build CM3 from scratch, or do I need some version > of the M3 build tools? > > Many thanks for the help. I used DEC-SRC Modula-3 around 1995 and am > trying to get it compiled up for a recent project, but on an original > platform. Some may call me crazy, and they'd be totally justified. I'm > not sure whether back-in-the-day I had it running on tru64 (well back > then it would have been Digital Unix 3.2C) or whether it was on a linux > box. > > Thanks for the help, > > Mark. From mark at wickensonline.co.uk Tue Jul 13 22:40:28 2010 From: mark at wickensonline.co.uk (Mark Wickens) Date: Tue, 13 Jul 2010 21:40:28 +0100 Subject: [M3devel] CM3 on Alpha tru64 4.0G In-Reply-To: <8E02058D-1A62-48FF-8DA7-B2C40C53B048@cs.purdue.edu> References: , , <9241B253-8004-4DDD-B1EF-A7D02A3FEAFD@cs.purdue.edu> <76827F66-451E-410E-9AF0-200D9538AFA1@cs.purdue.edu> <1279048755.1793.13.camel@x60.appsoftint.co.uk> <8E02058D-1A62-48FF-8DA7-B2C40C53B048@cs.purdue.edu> Message-ID: <1279053628.1793.15.camel@x60.appsoftint.co.uk> Hi Tony, the exception I get is as follows: >From cm3-min-ALPHA_OSF-d5.8.2-20100612/bin bash-3.2$ ./cm3 %DECthreads bugcheck (version V3.18-037), terminating execution. % Reason: stkGet: (4) nxm_stack_create (0,5251072,16384,8192) % Running on OSF1 V4.0(1530) on AlphaServer 300 4/266, 256Mb; 1 CPUs, pid 21360 From jay.krell at cornell.edu Wed Jul 14 01:04:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 13 Jul 2010 23:04:20 +0000 Subject: [M3devel] CM3 on Alpha tru64 4.0G In-Reply-To: <1279053628.1793.15.camel@x60.appsoftint.co.uk> References: ,, , , , <9241B253-8004-4DDD-B1EF-A7D02A3FEAFD@cs.purdue.edu>, , <76827F66-451E-410E-9AF0-200D9538AFA1@cs.purdue.edu>, <1279048755.1793.13.camel@x60.appsoftint.co.uk>, <8E02058D-1A62-48FF-8DA7-B2C40C53B048@cs.purdue.edu>, <1279053628.1793.15.camel@x60.appsoftint.co.uk> Message-ID: Things to try: cross build, user threads. Do you have a "modern" system with a working cm3? Do you have cvs and a working C compiler/linker on this older system? ?- Jay ---------------------------------------- > From: mark at wickensonline.co.uk > To: hosking at cs.purdue.edu > Date: Tue, 13 Jul 2010 21:40:28 +0100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] CM3 on Alpha tru64 4.0G > > Hi Tony, the exception I get is as follows: > > >From cm3-min-ALPHA_OSF-d5.8.2-20100612/bin > > bash-3.2$ ./cm3 > %DECthreads bugcheck (version V3.18-037), terminating execution. > % Reason: stkGet: (4) nxm_stack_create (0,5251072,16384,8192) > % Running on OSF1 V4.0(1530) on AlphaServer 300 4/266, 256Mb; 1 CPUs, > pid 21360 > > From jay.krell at cornell.edu Wed Jul 14 01:27:51 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 13 Jul 2010 23:27:51 +0000 Subject: [M3devel] CM3 on Alpha tru64 4.0G In-Reply-To: References: , , , , , , , , <9241B253-8004-4DDD-B1EF-A7D02A3FEAFD@cs.purdue.edu>, , , , <76827F66-451E-410E-9AF0-200D9538AFA1@cs.purdue.edu>, , <1279048755.1793.13.camel@x60.appsoftint.co.uk>, , <8E02058D-1A62-48FF-8DA7-B2C40C53B048@cs.purdue.edu>, , <1279053628.1793.15.camel@x60.appsoftint.co.uk>, Message-ID: > Things to try: cross build, user threads. http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-ALPHA_OSF-pthreads-d5.8.2-20100713.tgz or http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-ALPHA_OSF-userthreads-d5.8.2-20100713.tgz ? And in userthreads, if there is no get/set/make/swapcontext, you can change the #if at the top of ThreadPosixC.c to try sigaltstack. Also the userthreads Makefile has -lpthread in it, which you'll maybe want to remove...depending on if there is pthread_atfork, i.e. you? might want to tweak this: jbook2:cm3-boot-ALPHA_OSF-d5.8.2-20100713 jay$ grep pthread_atfork *c RTProcessC.c:????? int i = pthread_atfork(prepare, parent, child); but try the pthread version first? These will give you a cm3 and if it prints "unable to find cm3.cfg", good. Tru64 4.x isn't officially supported by gcc any longer, but I noticed recent test results posted anyway. You just have to configure -enable-obsolete or somesuch. Can you give me ssh access? That's a good and bad thing. Should be doable without such direct help by me.. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: mark at wickensonline.co.uk; hosking at cs.purdue.edu > Date: Tue, 13 Jul 2010 23:04:20 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] CM3 on Alpha tru64 4.0G > > > Things to try: cross build, user threads. > Do you have a "modern" system with a working cm3? > Do you have cvs and a working C compiler/linker on this older system? > > - Jay > > ---------------------------------------- > > From: mark at wickensonline.co.uk > > To: hosking at cs.purdue.edu > > Date: Tue, 13 Jul 2010 21:40:28 +0100 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] CM3 on Alpha tru64 4.0G > > > > Hi Tony, the exception I get is as follows: > > > > >From cm3-min-ALPHA_OSF-d5.8.2-20100612/bin > > > > bash-3.2$ ./cm3 > > %DECthreads bugcheck (version V3.18-037), terminating execution. > > % Reason: stkGet: (4) nxm_stack_create (0,5251072,16384,8192) > > % Running on OSF1 V4.0(1530) on AlphaServer 300 4/266, 256Mb; 1 CPUs, > > pid 21360 > > > > > From jay.krell at cornell.edu Wed Jul 14 11:17:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Jul 2010 09:17:57 +0000 Subject: [M3devel] -pthread vs. -pthreads arg Message-ID: Just a note: Some versions of gcc accept -pthread, some -pthreads, some both. Lame. In particular, from the few systems I've tested: Darwin either Solaris pthreads FreeBSD OpenBSD Linux pthread ??? probably NetBSD, Interix, Cygwin same but I didn't check Solaris cc use -mt instead ?- Jay From mark at wickensonline.co.uk Wed Jul 14 11:40:23 2010 From: mark at wickensonline.co.uk (Mark Wickens) Date: Wed, 14 Jul 2010 10:40:23 +0100 Subject: [M3devel] -pthread vs. -pthreads arg In-Reply-To: References: Message-ID: <1279100423.1793.22.camel@x60.appsoftint.co.uk> On Wed, 2010-07-14 at 09:17 +0000, Jay K wrote: > Just a note: > Some versions of gcc accept -pthread, some -pthreads, some both. Lame. > In particular, from the few systems I've tested: > > Darwin either > Solaris pthreads > FreeBSD OpenBSD Linux pthread > probably NetBSD, Interix, Cygwin same but I didn't check > Solaris cc use -mt instead > > > - Jay > > Hi Jay, So what would you recommend as the best thing to try first? Cross-compile? I installed the debian based package on a 32 bit ubuntu 10.4 install and that works fine. I am also happy to give you remote access to the box - that is no problem at all. Regards, Mark. From wagner at elegosoft.com Wed Jul 14 12:55:16 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 14 Jul 2010 12:55:16 +0200 Subject: [M3devel] LongrealType missed, was: Re: "FreeBSD4" false advertising In-Reply-To: <20100714104312.155351A2098@async.async.caltech.edu> References: <20100714094120.93B001A2098@async.async.caltech.edu> <20100714114648.nhnwruh008840wso@mail.elegosoft.com> <20100714100138.631581A2098@async.async.caltech.edu>, <20100714100525.BEE931A2096@async.async.caltech.edu> <20100714104312.155351A2098@async.async.caltech.edu> Message-ID: <20100714125516.1mzfehgnkgcs800w@mail.elegosoft.com> Quoting Mika Nystrom : > Argh is it really necessary to break source compatibility here? > > I also don't like that I as a client have to import IEEE things when all > I want is "LONGREAL" (and let Modula-3 do whatever it wants with that). > > I would propose at least having an interface LongrealType with > > CONST Hash = Longreal.Hash > > etc. so as not to force clients to import all the nitty-gritty about > various floating point representations. And so as not to break source > compatibility! If I change this by removing Type, my code will no longer > compile with the old compilers.... Hm, I'm a little bit out of context here... What was the reason for this change? It seems nobody else has bothered so far. This was the commit in question: 2009-12-23 21:43 hosking * m3-libs/: m3core/src/m3makefile, libm3/src/types/ASCII.i3, libm3/src/types/ASCII.m3, libm3/src/types/Boolean.i3, libm3/src/types/Boolean.m3, libm3/src/types/COPYRIGHT-CMASS, libm3/src/types/Char.i3, libm3/src/types/Char.m3, libm3/src/types/Int32.i3, libm3/src/types/Int32.m3, libm3/src/types/Int64.i3, libm3/src/types/Int64.m3, libm3/src/types/Integer.i3, libm3/src/types/Integer.m3, libm3/src/types/Longint.i3, libm3/src/types/Longint.m3, libm3/src/types/LongrealType.i3, libm3/src/types/LongrealType.m3, libm3/src/types/RealType.i3, libm3/src/types/RealType.m3, libm3/src/types/Refany.i3, libm3/src/types/Refany.m3, libm3/src/types/Unicode.i3, libm3/src/types/Unicode.m3, libm3/src/types/WideChar.i3, libm3/src/types/WideChar.m3, libm3/src/types/m3makefile, m3core/src/float/Common/Extended.m3, m3core/src/float/Common/LongReal.m3, m3core/src/float/Common/Real.m3, m3core/src/float/IEEE/Extended.i3, m3core/src/float/IEEE/LongReal.i3, m3core/src/float/IEEE/Real.i3, m3core/src/float/VAX/Extended.i3, m3core/src/float/VAX/LongReal.i3, m3core/src/float/VAX/Real.i3: Move libm3/src/types into m3core. Note that LongrealType and RealType have been folded into m3core/src/float. Clients will need adjustment. Any comments? Olaf > Mika > > Jay K writes: >> >> Remove "Type" it appears. >> >> >> http://modula3.elegosoft.com/cm3/ChangeLog-2009 >> >> search for "clients will need". >> >> e.g. >> >> +++ cm3/m3-demo/mentor/src/binpack/m3makefile 2009/12/23 22:05:06 1.2 >> @@ -10=2C7 +10=2C7 @@ >> =20 >> import ("zeus") >> =20 >> -list ("Real"=2C "RealType") >> +list ("Real"=2C "Real") >> =20 >> zume ("Binpack") >> oblume ("Binpack"=2C "myview") >> >> --- cm3/m3-demo/mentor/src/binpack/RealList.i3 2001/01/13 14:18:20 1.1 >> +++ cm3/m3-demo/mentor/src/binpack/RealList.i3 2009/12/23 22:05:05 1.2 >> @@ -2=2C4 +2=2C4 @@ >> (* Distributed only by permission. *) >> (* Last modified on Fri Jul 9 16:36:47 PDT 1993 by mhb *) >> =20 >> -INTERFACE RealList =3D List(RealType) END RealList. >> +INTERFACE RealList =3D List(Real) END RealList. >> >> --- cm3/m3-demo/mentor/src/binpack/RealList.m3 2001/01/13 14:18:20 1.1 >> +++ cm3/m3-demo/mentor/src/binpack/RealList.m3 2009/12/23 22:05:06 1.2 >> @@ -2=2C4 +2=2C4 @@ >> (* All rights reserved. *) >> (* See the file COPYRIGHT for a full description. *) >> =20 >> -MODULE RealList =3D List(RealType) END RealList. >> +MODULE RealList =3D List(Real) END RealList. >> >> =A0- Jay >> >> ---------------------------------------- >>> To: wagner at elegosoft.com >>> CC: jay.krell at cornell.edu=3B mika at async.caltech.edu >>> Subject: Re: [M3devel] "FreeBSD4" false advertising >>> Date: Wed=2C 14 Jul 2010 03:05:25 -0700 >>> From: mika at async.async.caltech.edu >>> >>> I'm not actually sure I understand the intent of the changes in this area= >> . >>> >>> My old m3makefile has: >>> >>> Table("TextLongReal"=2C "Text"=2C "LongrealType") >>> >>> What am I supposed to use now? >>> >>> Mika >>> >>> Mika Nystrom writes: >>> >Olaf Wagner writes: >>> >>Quoting Mika Nystrom : >>> >> >>> >>> Hi Jay=2C Olaf=2C >>> >>> >>> >>> I actually built everything! After backing out some of my changes >>> >>> that I had tried to get 5.8.6-REL to build with=2C it worked=2C and m= >> entor >>> >>> ran=2C even. >>> >> >>> >>Great! So it's still possible to build cm3 on FreeBSD 4=2C though >>> >>not our release code. >>> > >>> >The differences relative to the current CVS head are very minor. >>> > >>> >1. Added FreeBSD4 to thread.quake as a non-pthread platform >>> > >>> >2. got rid of the -m32 flags in FreeBSD4.conf >>> > >>> >Everything else that needed to change I think Jay has managed to put in >>> >the CVS head. >>> > >>> >> >>> >>> But... what happened to libm3/src/types? Building my own code I get >>> >>> the following errors: >>> >>> >>> >>> new source -> compiling LRInterval.i3 >>> >>> "../FreeBSD4/LRInterval.i3 =3D3D> ../src/Interval.ig"=2C line 5: unab= >> le to =3D20 >>> >>> find interface (LongrealType) >>> >>> 1 error encountered >>> >>> >>> >>> I can't find LongrealType anywhere=2C do I have a broken checkout? We= >> ll=2C it >>> >>> is in one place=2C in "doc". (Same for RealType=2C maybe others?) >>> >> >>> >>See =3D20 >>> >>http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/t= >> ypes/=3D >>> >>Attic/LongrealType.i3 >>> > >>> >Surely this is wrong?? I am looking for an interface that has T =3D >>> >LONGREAL=2C not something that lets me muck around with the representati= >> on >>> >of IEEE=2C VAX=2C etc.=2C floating-point formats. >>> > >>> >Why is it even in m3core? This seems clearly like libm3 stuff.. I notice= >> d >>> >Boolean.i3 also moved. >>> > >>> >Also if there is no importable interface called LongrealType that is goi= >> ng >>> >to cause endless problems with source that is supposed to compile under >>> >different versions of Modula-3. Even relatively recent CM3s required >>> >you to use LongrealType to instantiate generics. >>> > >>> > Mika >> = > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 14 13:23:49 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Jul 2010 11:23:49 +0000 Subject: [M3devel] LongrealType missed, was: Re: "FreeBSD4" false advertising In-Reply-To: <20100714125516.1mzfehgnkgcs800w@mail.elegosoft.com> References: <20100714094120.93B001A2098@async.async.caltech.edu>, <20100714114648.nhnwruh008840wso@mail.elegosoft.com>, <20100714100138.631581A2098@async.async.caltech.edu>, <20100714100525.BEE931A2096@async.async.caltech.edu>, , <20100714104312.155351A2098@async.async.caltech.edu>, <20100714125516.1mzfehgnkgcs800w@mail.elegosoft.com> Message-ID: Mika, Please try updating libm3 and see if that works for you. Thanks. ?- Jay ---------------------------------------- > Date: Wed, 14 Jul 2010 12:55:16 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > CC: jay.krell at cornell.edu; mika at async.caltech.edu > Subject: LongrealType missed, was: Re: [M3devel] "FreeBSD4" false advertising > > Quoting Mika Nystrom : > > > Argh is it really necessary to break source compatibility here? > > > > I also don't like that I as a client have to import IEEE things when all > > I want is "LONGREAL" (and let Modula-3 do whatever it wants with that). > > > > I would propose at least having an interface LongrealType with > > > > CONST Hash = Longreal.Hash > > > > etc. so as not to force clients to import all the nitty-gritty about > > various floating point representations. And so as not to break source > > compatibility! If I change this by removing Type, my code will no longer > > compile with the old compilers.... > > Hm, I'm a little bit out of context here... > What was the reason for this change? It seems nobody else has bothered > so far. > > This was the commit in question: > > 2009-12-23 21:43 hosking > > * m3-libs/: m3core/src/m3makefile, libm3/src/types/ASCII.i3, > libm3/src/types/ASCII.m3, libm3/src/types/Boolean.i3, > libm3/src/types/Boolean.m3, libm3/src/types/COPYRIGHT-CMASS, > libm3/src/types/Char.i3, libm3/src/types/Char.m3, > libm3/src/types/Int32.i3, libm3/src/types/Int32.m3, > libm3/src/types/Int64.i3, libm3/src/types/Int64.m3, > libm3/src/types/Integer.i3, libm3/src/types/Integer.m3, > libm3/src/types/Longint.i3, libm3/src/types/Longint.m3, > libm3/src/types/LongrealType.i3, libm3/src/types/LongrealType.m3, > libm3/src/types/RealType.i3, libm3/src/types/RealType.m3, > libm3/src/types/Refany.i3, libm3/src/types/Refany.m3, > libm3/src/types/Unicode.i3, libm3/src/types/Unicode.m3, > libm3/src/types/WideChar.i3, libm3/src/types/WideChar.m3, > libm3/src/types/m3makefile, m3core/src/float/Common/Extended.m3, > m3core/src/float/Common/LongReal.m3, m3core/src/float/Common/Real.m3, > m3core/src/float/IEEE/Extended.i3, m3core/src/float/IEEE/LongReal.i3, > m3core/src/float/IEEE/Real.i3, m3core/src/float/VAX/Extended.i3, > m3core/src/float/VAX/LongReal.i3, m3core/src/float/VAX/Real.i3: > > Move libm3/src/types into m3core. > Note that LongrealType and RealType have been folded into m3core/src/float. > Clients will need adjustment. > > Any comments? > > Olaf > > > Mika > > > > Jay K writes: > >> > >> Remove "Type" it appears. > >> > >> > >> http://modula3.elegosoft.com/cm3/ChangeLog-2009 > >> > >> search for "clients will need". > >> > >> e.g. > >> > >> +++ cm3/m3-demo/mentor/src/binpack/m3makefile 2009/12/23 22:05:06 1.2 > >> @@ -10=2C7 +10=2C7 @@ > >> =20 > >> import ("zeus") > >> =20 > >> -list ("Real"=2C "RealType") > >> +list ("Real"=2C "Real") > >> =20 > >> zume ("Binpack") > >> oblume ("Binpack"=2C "myview") > >> > >> --- cm3/m3-demo/mentor/src/binpack/RealList.i3 2001/01/13 14:18:20 1.1 > >> +++ cm3/m3-demo/mentor/src/binpack/RealList.i3 2009/12/23 22:05:05 1.2 > >> @@ -2=2C4 +2=2C4 @@ > >> (* Distributed only by permission. *) > >> (* Last modified on Fri Jul 9 16:36:47 PDT 1993 by mhb *) > >> =20 > >> -INTERFACE RealList =3D List(RealType) END RealList. > >> +INTERFACE RealList =3D List(Real) END RealList. > >> > >> --- cm3/m3-demo/mentor/src/binpack/RealList.m3 2001/01/13 14:18:20 1.1 > >> +++ cm3/m3-demo/mentor/src/binpack/RealList.m3 2009/12/23 22:05:06 1.2 > >> @@ -2=2C4 +2=2C4 @@ > >> (* All rights reserved. *) > >> (* See the file COPYRIGHT for a full description. *) > >> =20 > >> -MODULE RealList =3D List(RealType) END RealList. > >> +MODULE RealList =3D List(Real) END RealList. > >> > >> =A0- Jay > >> > >> ---------------------------------------- > >>> To: wagner at elegosoft.com > >>> CC: jay.krell at cornell.edu=3B mika at async.caltech.edu > >>> Subject: Re: [M3devel] "FreeBSD4" false advertising > >>> Date: Wed=2C 14 Jul 2010 03:05:25 -0700 > >>> From: mika at async.async.caltech.edu > >>> > >>> I'm not actually sure I understand the intent of the changes in this area= > >> . > >>> > >>> My old m3makefile has: > >>> > >>> Table("TextLongReal"=2C "Text"=2C "LongrealType") > >>> > >>> What am I supposed to use now? > >>> > >>> Mika > >>> > >>> Mika Nystrom writes: > >>> >Olaf Wagner writes: > >>> >>Quoting Mika Nystrom : > >>> >> > >>> >>> Hi Jay=2C Olaf=2C > >>> >>> > >>> >>> I actually built everything! After backing out some of my changes > >>> >>> that I had tried to get 5.8.6-REL to build with=2C it worked=2C and m= > >> entor > >>> >>> ran=2C even. > >>> >> > >>> >>Great! So it's still possible to build cm3 on FreeBSD 4=2C though > >>> >>not our release code. > >>> > > >>> >The differences relative to the current CVS head are very minor. > >>> > > >>> >1. Added FreeBSD4 to thread.quake as a non-pthread platform > >>> > > >>> >2. got rid of the -m32 flags in FreeBSD4.conf > >>> > > >>> >Everything else that needed to change I think Jay has managed to put in > >>> >the CVS head. > >>> > > >>> >> > >>> >>> But... what happened to libm3/src/types? Building my own code I get > >>> >>> the following errors: > >>> >>> > >>> >>> new source -> compiling LRInterval.i3 > >>> >>> "../FreeBSD4/LRInterval.i3 =3D3D> ../src/Interval.ig"=2C line 5: unab= > >> le to =3D20 > >>> >>> find interface (LongrealType) > >>> >>> 1 error encountered > >>> >>> > >>> >>> I can't find LongrealType anywhere=2C do I have a broken checkout? We= > >> ll=2C it > >>> >>> is in one place=2C in "doc". (Same for RealType=2C maybe others?) > >>> >> > >>> >>See =3D20 > >>> >>http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/t= > >> ypes/=3D > >>> >>Attic/LongrealType.i3 > >>> > > >>> >Surely this is wrong?? I am looking for an interface that has T =3D > >>> >LONGREAL=2C not something that lets me muck around with the representati= > >> on > >>> >of IEEE=2C VAX=2C etc.=2C floating-point formats. > >>> > > >>> >Why is it even in m3core? This seems clearly like libm3 stuff.. I notice= > >> d > >>> >Boolean.i3 also moved. > >>> > > >>> >Also if there is no importable interface called LongrealType that is goi= > >> ng > >>> >to cause endless problems with source that is supposed to compile under > >>> >different versions of Modula-3. Even relatively recent CM3s required > >>> >you to use LongrealType to instantiate generics. > >>> > > >>> > Mika > >> = > > > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Wed Jul 14 15:19:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Jul 2010 13:19:31 +0000 Subject: [M3devel] SOLgnu not working Message-ID: Just a note, that I'm aware, SOLgnu appears to be broken in head. = package /home/jay/dev2/cm3/m3-win/import-libs == ?+++ /cm3/bin/cm3??? -build -DROOT=/home/jay/dev2/cm3 +++ *** *** runtime error: ***??? Unhandled exception: OSError.E ***??? file "../src/os/POSIX/OSErrorPosix.m3", line 50 *** Abort - core dumped No ETA on a fix. But it is? important. ?- Jay From jay.krell at cornell.edu Wed Jul 14 17:03:55 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Jul 2010 15:03:55 +0000 Subject: [M3devel] SOLgnu not working In-Reply-To: References: Message-ID: Oh, sorry, it's probably ok. ? Debugging it... I was in user threads..because I had bootstrapped from 5.4.0. Maybe 5.4.0 is broken, don't care. ? Tried SOLsun..working better. ? Compared them..discovered this SOLgnu used the 4.5.0 backend, which isn't yet enabled. ! ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: SOLgnu not working > Date: Wed, 14 Jul 2010 13:19:31 +0000 > > > Just a note, that I'm aware, SOLgnu appears to be broken in head. > > = package /home/jay/dev2/cm3/m3-win/import-libs == > > +++ /cm3/bin/cm3 -build -DROOT=/home/jay/dev2/cm3 +++ > > > *** > *** runtime error: > *** Unhandled exception: OSError.E > *** file "../src/os/POSIX/OSErrorPosix.m3", line 50 > *** > > Abort - core dumped > > No ETA on a fix. But it is important. > > - Jay > > > > > From wagner at elegosoft.com Thu Jul 15 14:43:43 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 15 Jul 2010 14:43:43 +0200 Subject: [M3devel] minor problems on the release branch Message-ID: <20100715144343.qby2zwskgg4kok48@mail.elegosoft.com> While checking the status of the final 5.8.6 release of CM3, I found several minor problems, which would benefit from attention nonetheless. Investigating these should also be a good starting point for newbies and others lurking on the list and waiting for something to do: Why did this change? http://hudson.modula3.com:8080/view/cm3/job/cm3-test-m3tests-AMD64_LINUX/lastBuild/testReport/(root)/m3tests/p040__binary_____ASCII_conversion_routines (failing since Build #556 (Apr 29, 2010 9:35:06 PM)) same issue: http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-m3tests-I386_OPENBSD/lastBuild/testReport/(root)/m3tests/p040__binary_____ASCII_conversion_routines (failing since Build #28 (Nov 22, 2009 7:43:34 AM)) http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-m3tests-LINUXLIBC6/lastBuild/testReport/(root)/m3tests/p040__binary_____ASCII_conversion_routines (failing since Build #276 (Jul 9, 2010 11:40:25 AM)) The shipping tests on Nt386 seem to have never worked: http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-m3tests-NT386/374/testReport/ Test reporting ist still more or less completely broken on SOLsun :-( http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-m3tests-SOLsun/lastBuild Failed packages on I386_OPENBSD: http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-all-pkgs-I386_OPENBSD/44/testReport/ Failed packages on NT386: http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-all-pkgs-NT386/182/testReport/ m3gdb build fails on PPC_LINUX and SPARC32_LINUX: http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-all-pkgs-PPC_LINUX/18/testReport/ http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-all-pkgs-SPARC32_LINUX/lastBuild/testReport/ Failed package tests on SOLgnu and SOLsun: http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-all-pkgs-SOLgnu/lastBuild/testReport/ http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-all-pkgs-SOLsun/lastBuild/testReport/ Regards, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 bugs at elego.de Thu Jul 15 15:21:30 2010 From: bugs at elego.de (CM3) Date: Thu, 15 Jul 2010 13:21:30 -0000 Subject: [M3devel] [CM3] #1068: Segmentation violation in String8.m3 In-Reply-To: <062.b174f7e6cb17a55b692f50f311e18b17@elego.de> References: <062.b174f7e6cb17a55b692f50f311e18b17@elego.de> Message-ID: <071.f664d53a4c2a0572384dcc425bb5f2da@elego.de> #1068: Segmentation violation in String8.m3 ------------------------------------------+--------------------------------- Reporter: peter.mckinna@? | Owner: wagner Type: sw-bug | Status: assigned Priority: medium | Milestone: CM3 Release 5.9 Component: comm | Version: 5.8-RC3 Severity: serious | Keywords: pickles, 64 to 32 bit Relnote: | Org: Estimatedhours: 0.0 | Hours: 0 Billable: 1 | Totalhours: 0 Internal: 0 | ------------------------------------------+--------------------------------- Htr: Fix: Env: ------------------------------------------+--------------------------------- Changes (by wagner): * owner: rbates => wagner * milestone: CM3 release 5.8 => CM3 Release 5.9 -- Ticket URL: CM3 Critical Mass Modula3 Compiler From bugs at elego.de Thu Jul 15 15:22:23 2010 From: bugs at elego.de (CM3) Date: Thu, 15 Jul 2010 13:22:23 -0000 Subject: [M3devel] [CM3] #1068: Segmentation violation in String8.m3 In-Reply-To: <062.b174f7e6cb17a55b692f50f311e18b17@elego.de> References: <062.b174f7e6cb17a55b692f50f311e18b17@elego.de> Message-ID: <071.7f4f89c8c47fb8f7fdd347237342be4a@elego.de> #1068: Segmentation violation in String8.m3 ------------------------------------------+--------------------------------- Reporter: peter.mckinna@? | Owner: rbates Type: sw-bug | Status: assigned Priority: medium | Milestone: CM3 Release 5.9 Component: comm | Version: 5.8-RC3 Severity: serious | Keywords: pickles, 64 to 32 bit Relnote: | Org: Estimatedhours: 0.0 | Hours: 0 Billable: 1 | Totalhours: 0 Internal: 0 | ------------------------------------------+--------------------------------- Htr: Fix: Env: ------------------------------------------+--------------------------------- Changes (by wagner): * owner: wagner => rbates -- Ticket URL: CM3 Critical Mass Modula3 Compiler From jay.krell at cornell.edu Thu Jul 15 15:39:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 15 Jul 2010 13:39:04 +0000 Subject: [M3devel] branches in changelog? Message-ID: http://www.opencm3.net/ChangeLog-2009 indicates when a file is added to release branch, but not modified. That might help track down..e.g. what happened circa November 21 2009. Thanks, ?- Jay From jay.krell at cornell.edu Thu Jul 15 15:56:55 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 15 Jul 2010 13:56:55 +0000 Subject: [M3devel] minor problems on the release branch In-Reply-To: <20100715144343.qby2zwskgg4kok48@mail.elegosoft.com> References: <20100715144343.qby2zwskgg4kok48@mail.elegosoft.com> Message-ID: I believe the .M3SHIP tests have always failed because they look for Posix paths in the output. You can likely now create correct stdout.pgm-NT386 and they will work. It's not just the slashes, but also libfoo.a vs. foo.lib, foo.exe vs. foo. I think. I vaguely recall noticing that and that the tests not the functionality was broken. To the extent that the tests are looking for "back substitution" to work and don't care about the others, change the slashes, remove the last path element, and declare that correct output? The float<>string conversion worries me some. I wish we had noticed it earlier. At a certain level, it's not a big deal: the resulting strings are certainly "reasonable". But programs could legitimately take a pretty close dependency on the behavior here. Right? ? Until/unless VAX support comes back, in which case we'll probably get varying results. To debug this, a bit tedious, but someone might consider getting the release branch to just before the failure and verifying it works, then just after the failure, verify it doens't work. Then compare the two branches. SOLsun fails for a minor reason: +cc: Warning: -xarch=v8plus is deprecated, use -m32 -xarch=sparc instead I probably just have to redirect it to >/dev/null. I don't just change the config file. The config file works with a range of cc versions and probes their behavior. ? (something we might consider in a more autoconf-sh way, i.e. less often, though it isn't all that often, and ? someone can upgrade their cc at almost any time, so...) Lots to work through.. ?? - Jay ---------------------------------------- > Date: Thu, 15 Jul 2010 14:43:43 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] minor problems on the release branch > > While checking the status of the final 5.8.6 release of CM3, I found > several minor problems, which would benefit from attention nonetheless. > > Investigating these should also be a good starting point for newbies and > others lurking on the list and waiting for something to do: > > Why did this change? > > > http://hudson.modula3.com:8080/view/cm3/job/cm3-test-m3tests-AMD64_LINUX/lastBuild/testReport/(root)/m3tests/p040__binary_____ASCII_conversion_routines > (failing since Build #556 (Apr 29, 2010 9:35:06 PM)) > > same issue: > > > http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-m3tests-I386_OPENBSD/lastBuild/testReport/(root)/m3tests/p040__binary_____ASCII_conversion_routines > (failing since Build #28 (Nov 22, 2009 7:43:34 AM)) > > > http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-m3tests-LINUXLIBC6/lastBuild/testReport/(root)/m3tests/p040__binary_____ASCII_conversion_routines > (failing since Build #276 (Jul 9, 2010 11:40:25 AM)) > > The shipping tests on Nt386 seem to have never worked: > > http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-m3tests-NT386/374/testReport/ > > Test reporting ist still more or less completely broken on SOLsun :-( > > > http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-m3tests-SOLsun/lastBuild > > Failed packages on I386_OPENBSD: > > > http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-all-pkgs-I386_OPENBSD/44/testReport/ > > Failed packages on NT386: > > > http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-all-pkgs-NT386/182/testReport/ > > m3gdb build fails on PPC_LINUX and SPARC32_LINUX: > > > http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-all-pkgs-PPC_LINUX/18/testReport/ > > http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-all-pkgs-SPARC32_LINUX/lastBuild/testReport/ > > Failed package tests on SOLgnu and SOLsun: > > > http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-all-pkgs-SOLgnu/lastBuild/testReport/ > > http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-all-pkgs-SOLsun/lastBuild/testReport/ > > Regards, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Thu Jul 15 17:18:08 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 15 Jul 2010 17:18:08 +0200 Subject: [M3devel] CM3 5.8 RELEASE (5.8.6) Message-ID: <20100715171808.ftd7ycx6tcoog8gk@mail.elegosoft.com> Finally I've declared the last state of the release branch as the final CM3 5.8 release! There have been almost no changes in the recent weeks, and it's unlikely that much improvements will be added if we wait any longer. So I've closed the milestone in trac, and retargeted the remaining 3 or 4 issues to the 5.9 release. https://projects.elego.de/cm3/milestone/CM3%20release%205.8 I've also moved the target date for 5.9 to end of June 2011 ;-) https://projects.elego.de/cm3/milestone/CM3%20Release%205.9 The 5.8 release archives can be downloaded here: http://www.modula3.com/cm3/releng/download.html All related information should be available via that link, too. Some more general information can be found at http://www.modula3.com/cm3/download.html I know this has taken longer than ever before, but we've managed it after all. Thanks to everybody who helped with this release. If you still find bugs, please report them here: https://projects.elego.de/cm3/newticket In the next week, I'll change the Hudson jobs to follow the CVS main trunk again. Best regards, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Jul 16 14:58:42 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 16 Jul 2010 12:58:42 +0000 Subject: [M3devel] $ORIGIN? Message-ID: So I can build a distribution FreeBSD 4.11... But it looks like FreeBSD didn't support $ORIGIN until very recently: 8.0. This is evidenced from two places: http://www.freebsd.org/releases/8.0R/relnotes-detailed.html ? indicates it is new and http://www.freebsd.org/cgi/man.cgi lets you specify version. The ld-elf.so manpage doesn't mention it until 8.0. This means, something like: ? FreeBSD users using < 8.0 will need/want to set LD_LIBRARY_PATH. ? I don't think the distributed binaries have any hardcoded paths in them, except for the $ORIGIN stuff, ?? which I think will just be ignored. "Normally" they do, but the distribution build specifically ?? tries to omit them. This "puts pressure" on considering "this problem" more/again? ? NetBSD < 5.0, FreeBSD < 8.0 ... enough to do something about? ? I've been looking into autoconf and libtool some, but i haven't yet, like.. ? what I'd like to see very clearly is them do the "relink before install" behavior. ? Once confirmed to be there.. maybe our "binary" packages are a bunch of .o files? ? Interesting compromise? ? Or, really, maybe we somewhat give up on "relocatability" and hardcode /usr/local/cm3? ? ?? I realize, official Debian packages need to be at /usr. ? Anyone building from source, can put the files anywhere. ? We can also only "give up" on FreeBSD and/or NetBSD -- where $ORIGIN is more recent introduction. I also seem to recall OSF/1 supports arbitrary environment variables, but doesn't define anything for you like $ORIGIN. Some system is that way. For that can invent custom names and wrapper scripts perhaps. I know, a likely question, it has been asked for, "what is common?" i.e. portable, works the same "everywhere"? ? That would be hardcoded paths, no relocatability. $ORIGIN is very common, but less so. I'm the one who opened this can of worms here. ?The previous -rpath was a mess with lots of directories. That could at least be changed to something short. ? $ORIGIN is indeed very promising and fairly portable, but not perfectly portable nor perfectly "behaved". ? I don't think any solution is perfectly "behaved", there are contradictory goals. ?- Jay From wagner at elegosoft.com Fri Jul 16 15:10:02 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 16 Jul 2010 15:10:02 +0200 Subject: [M3devel] $ORIGIN? In-Reply-To: References: Message-ID: <20100716151002.ygdg5pakxwc0kwwc@mail.elegosoft.com> Quoting Jay K : > So I can build a distribution FreeBSD 4.11... > > But it looks like FreeBSD didn't support $ORIGIN until very recently: 8.0. > > This is evidenced from two places: > > http://www.freebsd.org/releases/8.0R/relnotes-detailed.html > ? indicates it is new > > and http://www.freebsd.org/cgi/man.cgi lets you specify version. > The ld-elf.so manpage doesn't mention it until 8.0. That's correct. Alas, there's no common standard shared by all the systems we support. > This means, something like: > ? FreeBSD users using < 8.0 will need/want to set LD_LIBRARY_PATH. We should document that as a workaround. > ? I don't think the distributed binaries have any hardcoded paths in > them, except for the $ORIGIN stuff, > ?? which I think will just be ignored. "Normally" they do, but the > distribution build specifically > ?? tries to omit them. > This "puts pressure" on considering "this problem" more/again? > ? NetBSD < 5.0, FreeBSD < 8.0 ... enough to do something about? > ? I've been looking into autoconf and libtool some, but i haven't yet, like.. > ? what I'd like to see very clearly is them do the "relink before > install" behavior. > ? Once confirmed to be there.. maybe our "binary" packages are a > bunch of .o files? > ? Interesting compromise? > ? Or, really, maybe we somewhat give up on "relocatability" and > hardcode /usr/local/cm3? > ? ?? I realize, official Debian packages need to be at /usr. > ? Anyone building from source, can put the files anywhere. > ? We can also only "give up" on FreeBSD and/or NetBSD -- where > $ORIGIN is more recent introduction. We should keep that for the time being. > I also seem to recall OSF/1 supports arbitrary environment > variables, but doesn't define anything for you like $ORIGIN. > Some system is that way. > For that can invent custom names and wrapper scripts perhaps. > > I know, a likely question, it has been asked for, "what is common?" > i.e. portable, works the same "everywhere"? > ? That would be hardcoded paths, no relocatability. > $ORIGIN is very common, but less so. > > I'm the one who opened this can of worms here. > ?The previous -rpath was a mess with lots of directories. That could > at least be changed to something short. > ? $ORIGIN is indeed very promising and fairly portable, but not > perfectly portable nor perfectly "behaved". > ? I don't think any solution is perfectly "behaved", there are > contradictory goals. /usr/local/cm3 was the original one standard location when we first published the sources from Critical Mass. But lots of people complained and wanted more flexibility, or rather their platform-specific different standard setups. We haven't got the ressources to fulfill all wishes currently. I'd vote to keep the status quo until someone either has a great idea or implements something better, or we'll keep changing solutions back and forth. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Jul 16 15:47:46 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 16 Jul 2010 13:47:46 +0000 Subject: [M3devel] $ORIGIN? In-Reply-To: <20100716151002.ygdg5pakxwc0kwwc@mail.elegosoft.com> References: , <20100716151002.ygdg5pakxwc0kwwc@mail.elegosoft.com> Message-ID: > We should document that as a workaround. It sort of is, but it is a bit vague. We can fill in specifics: FreeBSD < 8.0 NetBSD < 5.0 (but we don't have NetBSD distributions so..) no problem on Linux, Solaris, MacOSX, NT. Basically, I have to say..I think we might have zero NetBSD users so I thought we were well covered. I didn't realize FreeBSD was late here. That was surprising. > But lots of people complained > and wanted more flexibility, or rather their platform-specific different > standard setups. This is a critical distinction of course. Using /opt/cm3 on Solaris. ? /usr/pkg on NetBSD. ? etc. is trivial. I'm guessing $HOME and $HOME/cm3 are common though too. ?? I keep getting non-root access to machines and using that. :) As well, for a long time, the answer was LD_LIBRARY_PATH, which despite going by a few different names, does seem common. But I'm not sure I prefer it. Obviously you can read all the distaste for it on the web. I'm *guessing* that non-NT users are mostly Linux users, and I'm *guessing* that $ORIGIN has been there a while. Solaris has also had it a while. FreeBSD as I said, not. NetBSD since 5.0 (current). OpenBSD I don't know. Building "static" -- "partly static" also evades this. Except for OpenBSD, "static" is only relative to Modula-3 libraries. But it is overkill, wasteful, bigger, slower. And lots of people don't build the system themselves, right? > We haven't got the resources to fulfill all wishes currently. Hehe. I want world peace and a few million dollars. :) > I'd vote to keep the status quo until someone either has a great idea > or implements something better, or we'll keep changing solutions back > and forth. Ok. I think all the ideas are known here. :) Ultimately I like the idea of generating C, and then using autoconf and libtool to fill in some cracks. But the C backend is a big missing in action piece. I'm largely talk, less action. Time passing helps, people will converge more on systems having $ORIGIN support. ? - Jay ---------------------------------------- > Date: Fri, 16 Jul 2010 15:10:02 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] $ORIGIN? > > Quoting Jay K : > > > So I can build a distribution FreeBSD 4.11... > > > > But it looks like FreeBSD didn't support $ORIGIN until very recently: 8.0. > > > > This is evidenced from two places: > > > > http://www.freebsd.org/releases/8.0R/relnotes-detailed.html > > indicates it is new > > > > and http://www.freebsd.org/cgi/man.cgi lets you specify version. > > The ld-elf.so manpage doesn't mention it until 8.0. > > That's correct. > > Alas, there's no common standard shared by all the systems we support. > > > This means, something like: > > FreeBSD users using < 8.0 will need/want to set LD_LIBRARY_PATH. > > We should document that as a workaround. > > > I don't think the distributed binaries have any hardcoded paths in > > them, except for the $ORIGIN stuff, > > which I think will just be ignored. "Normally" they do, but the > > distribution build specifically > > tries to omit them. > > > This "puts pressure" on considering "this problem" more/again? > > NetBSD < 5.0, FreeBSD < 8.0 ... enough to do something about? > > I've been looking into autoconf and libtool some, but i haven't yet, like.. > > what I'd like to see very clearly is them do the "relink before > > install" behavior. > > Once confirmed to be there.. maybe our "binary" packages are a > > bunch of .o files? > > Interesting compromise? > > Or, really, maybe we somewhat give up on "relocatability" and > > hardcode /usr/local/cm3? > > I realize, official Debian packages need to be at /usr. > > Anyone building from source, can put the files anywhere. > > We can also only "give up" on FreeBSD and/or NetBSD -- where > > $ORIGIN is more recent introduction. > > We should keep that for the time being. > > > I also seem to recall OSF/1 supports arbitrary environment > > variables, but doesn't define anything for you like $ORIGIN. > > Some system is that way. > > For that can invent custom names and wrapper scripts perhaps. > > > > I know, a likely question, it has been asked for, "what is common?" > > i.e. portable, works the same "everywhere"? > > That would be hardcoded paths, no relocatability. > > $ORIGIN is very common, but less so. > > > > I'm the one who opened this can of worms here. > > The previous -rpath was a mess with lots of directories. That could > > at least be changed to something short. > > $ORIGIN is indeed very promising and fairly portable, but not > > perfectly portable nor perfectly "behaved". > > I don't think any solution is perfectly "behaved", there are > > contradictory goals. > > /usr/local/cm3 was the original one standard location when we first > published the sources from Critical Mass. But lots of people complained > and wanted more flexibility, or rather their platform-specific different > standard setups. > > We haven't got the ressources to fulfill all wishes currently. > > I'd vote to keep the status quo until someone either has a great idea > or implements something better, or we'll keep changing solutions back > and forth. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Fri Jul 16 16:16:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 16 Jul 2010 14:16:36 +0000 Subject: [M3devel] FreeBSD 4 Message-ID: Mika already got this working himself, but anyway: http://modula3.elegosoft.com/cm3/uploaded-archives/ => http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-I386_FREEBSD-d5.8.2-FreeBSD4.11-20100715.tar.gz http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-all-I386_FREEBSD-d5.8.2-FreeBSD4.11-20100715.tar.gz They have "no runpath". You must set LD_LIBRARY_PATH. They use userthreads. But FreeBSD4 does have pthreads. Maybe they are adequate. I wasn't able to test gui apps. (Mika did.) System builds itself, so it largely works. ?- Jay From mika at async.async.caltech.edu Fri Jul 16 16:42:43 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Fri, 16 Jul 2010 07:42:43 -0700 Subject: [M3devel] $ORIGIN? In-Reply-To: References: Message-ID: <20100716144243.E10F81A20A7@async.async.caltech.edu> Jay K writes: > >So I can build a distribution FreeBSD 4.11... > > >But it looks like FreeBSD didn't support $ORIGIN until very recently: 8.0. > > >This is evidenced from two places: > > >http://www.freebsd.org/releases/8.0R/relnotes-detailed.html >=A0 indicates it is new > > >and http://www.freebsd.org/cgi/man.cgi lets you specify version. >The ld-elf.so manpage doesn't mention it until 8.0. > > >This means=2C something like: >=A0 FreeBSD users using < 8.0 will need/want to set LD_LIBRARY_PATH. >=A0 I don't think the distributed binaries have any hardcoded paths in them= >=2C except for the $ORIGIN stuff=2C >=A0=A0 which I think will just be ignored. "Normally" they do=2C but the di= >stribution build specifically >=A0=A0 tries to omit them. I have been using Modula-3 on FreeBSD since 2.x and have never needed to set LD_LIBRARY_PATH. And I (almost) always compile outside the /usr/local/... (m3build -O or cm3 -x) Mika From jay.krell at cornell.edu Fri Jul 16 21:19:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 16 Jul 2010 19:19:32 +0000 Subject: [M3devel] $ORIGIN? In-Reply-To: <20100716144243.E10F81A20A7@async.async.caltech.edu> References: , <20100716144243.E10F81A20A7@async.async.caltech.edu> Message-ID: > I have been using Modula-3 on FreeBSD since 2.x and have never needed > to set LD_LIBRARY_PATH. > > And I (almost) always compile outside the /usr/local/... (m3build -O or cm3 -x) If you build it yourself, sure. If I build it for someone else to use and I don't know where they are going to install it, that's when it is needed. ?- Jay ---------------------------------------- > To: jay.krell > CC: m3devel > Subject: Re: [M3devel] $ORIGIN? > Date: Fri, 16 Jul 2010 07:42:43 -0700 > From: mika > ... From jay.krell at cornell.edu Sun Jul 18 03:30:09 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 18 Jul 2010 01:30:09 +0000 Subject: [M3devel] compiler behavior under "low memory"? Message-ID: Mark had a machine with low memory. It has more swap now. Our behavior was: Compiling m3tk would make good progress, complete many files, then fail for ?lack of memory. Manual retry would start over due to ?"missing version information" or such. Thus progress was "impossible". By editing down m3makefile I was able to make progress. ?Some stuff would fail due to missing interfaces, but ?whatever I left in would get the version information saved. ? ? Perhaps we should write out the version information every "few" files? ?For some definition of "few"? 10? 10% of the total? ? ? That would at least let such situations progress via manual retry. ? (unless not even a "few" fit in memory) I also wonder about reducing memory used, or why indeed we run out, ?but that is a thornier problem. You know, all we should need to ?continue forward progress is to hold all interfaces in memory and ?one implementation at a time. Now, there are a few unknowns here. ?It is possible Mark's machine didn't have enough memory for ?all the relevant interfaces, and that we only "load" them on-demand. ? ?It is also likely, I should add, that virtual address space is the ? problem, not working set. Some systems want to commit room ? in swap for all allocated virtual memory, like, to be sure ? ahead of time that everything can be paged out so other ? code can progress. Something like that. I'm not sure here. ? That is, I suspect we don't care. Virtual address space is probably ? reasonable to deem cheap. No problem using almost 2GB of address space ? as long as working set isn't that large (ie: to fit in 31bit address space). ? If some OSes don't see it that way, oh well. This might just ? be a design/policy thing in Tru64. ? ? (I'm well aware of virtual memory vs. physical memory vs. working set. But for whatever reason, we were failing due to memory use. All that *should* matter is that address space usage stays within around 2GB and that working set isn't huge. Working set I've recently come to understand can be managed like so: ? - random access over set of memory that fits in physical memory ? - sequential access over arbitrary memory (up to 2GB) ? - hybrid of previous ????? ie. sequential accesses over multiple separate areas As long as access is sequential, you shouldn't "thrash". It is only random access over data that doesn't fit in physical memory ?that causes thrashing.) ?- Jay From jay.krell at cornell.edu Sun Jul 18 03:34:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 18 Jul 2010 01:34:14 +0000 Subject: [M3devel] multithreaded compiler? Message-ID: It should be reasonably easy to have the gcc backend run on multiple separate threads. ?- Jay From dabenavidesd at yahoo.es Sun Jul 18 05:28:54 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 18 Jul 2010 03:28:54 +0000 (GMT) Subject: [M3devel] compiler behavior under "low memory"? In-Reply-To: Message-ID: <583206.38293.qm@web23608.mail.ird.yahoo.com> Hi: If it only had such small memory requirements I suppose less than 64 MB RAM I didn't get the number of interfaces is about the same (probably a 10 % larger by now with new added packages), probably the best way forward is not just to change the swap memory as its a common sense to double the RAM but in that case you would need such a thing for one process less the rest of operating system, i.e solution is not general, If I understand well Mark 's Alpha DEC machine had the same machine and probably with M3 running in top of it in 1995. I wonder how these years have expanded the compilers proficiency (as time is against space and vice-versa, that is, less time is more memory like to make a recursive program to unfold in a sequential one) in such a memory constrained environments could be solved I can remember now that there was a change in Amer Diwan Whole program optimizer to grab in a pickled AST to later unpickle it and compile to M3CG-machine assembly optimized see: http://www.modula3.org/threads/1/#advanced and also a proposed or to-do of DEC-SRC M3 days about Cache policy it mentioned see: http://www.cs.arizona.edu/~collberg/Research/Modula-3/modula-3/html/todo.html AST cache policy. The current driver keeps an in-memory cache of compiled interfaces, but never flushes entries, this refers to the simple problem of big heap which another application generated out of memory back in those days the ESC/Modula-3 checker available for Alphas see: http://web.archive.org/web/20030704143617/http://research.compaq.com/SRC/esc/escm3/bin/Esc.alpha.bin.Z (which was user of Simplify theorem prover http://portal.acm.org/citation.cfm?id=1066100.1066102 or doi:0.1145/1066100.1066102 as it should be cited and also used m3tk toolkit ) and they managed to solve by means of calling the collector to scan and throw away the uncollected things at least in Simplify, years later I retired the line with no problem in Simplify and all run in good benchmarks tests of Simplify with no problems see too http://qpq.csl.sri.com/downloads/simplify_benchmarks-tar.gz/view The result was that they created a tool to understand where the memory heap was being actually ran out of memory and they manage to solve I believe by managing the same way besides clearing stuff not needed something is useful in any garbage collected type language http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.49.3474&rep=rep1&type=pdf see slides onhttp://labs.oracle.com/people/detlefs/papers/detlefs-coots95-slides.ps and extra figures http://labs.oracle.com/people/detlefs/papers/detlefs-coots95-slides2.ps In our case in that case as it can't throw away AST representations before M3CG-machine tough there is separate compilation we don't manage to type check all m3tk in runtime eliminating when is compiled and not used code generation currently the problem might be solved in the compilation server written for pm3 (see: http://arxiv.org/pdf/cs/0506035 ) or as Amer Diwan solved to manage for his particular purposes (see ftp://ftp.cs.umass.edu/pub/osl/papers/diwan-dissertation.ps.gz) because in any case of low resources limits it would be stored pickled or in swaped memory in the disc but in non-low memory limits it would be in both memory and disk as it is now (at some point you need to bring from copy from disk the needed bytes back to memory). Besides that the implemented behavior on VM exhaustion should be not taken in false as guys didn't in those days http://modula3.elegosoft.com/pm3/intro/questions/new.html An implemented solution but actually not used not seen here: http://web.archive.org/web/19980613063641/www.vlsi.polymtl.ca/m3/pkg/contrib/whenNEWfails/.ghindex.html Thanks for any corrections in advance if so --- El s?b, 17/7/10, Jay K escribi?: > De: Jay K > Asunto: [M3devel] compiler behavior under "low memory"? > Para: "m3devel" > Fecha: s?bado, 17 de julio, 2010 20:30 > > Mark had a machine with low memory. > It has more swap now. > > > Our behavior was: > > > Compiling m3tk would make good progress, complete many > files, then fail for > lack of memory. > > > Manual retry would start over due to > "missing version information" or such. > > > Thus progress was "impossible". > By editing down m3makefile I was able to make progress. > Some stuff would fail due to missing interfaces, but > whatever I left in would get the version information > saved. > > > Perhaps we should write out the version information every > "few" files? > For some definition of "few"? 10? 10% of the total? > > > That would at least let such situations progress via manual > retry. > (unless not even a "few" fit in memory) > > > I also wonder about reducing memory used, or why indeed we > run out, > but that is a thornier problem. You know, all we should > need to > continue forward progress is to hold all interfaces in > memory and > one implementation at a time. Now, there are a few > unknowns here. > It is possible Mark's machine didn't have enough memory > for > all the relevant interfaces, and that we only "load" them > on-demand. > > > It is also likely, I should add, that virtual address > space is the > problem, not working set. Some systems want to commit > room > in swap for all allocated virtual memory, like, to be > sure > ahead of time that everything can be paged out so other > code can progress. Something like that. I'm not sure > here. > That is, I suspect we don't care. Virtual address space > is probably > reasonable to deem cheap. No problem using almost 2GB of > address space > as long as working set isn't that large (ie: to fit in > 31bit address space). > If some OSes don't see it that way, oh well. This might > just > be a design/policy thing in Tru64. > > > (I'm well aware of virtual memory vs. physical memory vs. > working set. > But for whatever reason, we were failing due to memory > use. > All that *should* matter is that address space usage stays > within > around 2GB and that working set isn't huge. Working set > I've recently > come to understand can be managed like so: > - random access over set of memory that fits in physical > memory > - sequential access over arbitrary memory (up to 2GB) > - hybrid of previous > ie. sequential accesses over multiple separate > areas > > As long as access is sequential, you shouldn't "thrash". > It is only random access over data that doesn't fit in > physical memory > that causes thrashing.) > > > - Jay > > > > From jay.krell at cornell.edu Sun Jul 18 06:02:46 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 18 Jul 2010 04:02:46 +0000 Subject: [M3devel] compiler behavior under "low memory"? In-Reply-To: <583206.38293.qm@web23608.mail.ird.yahoo.com> References: , <583206.38293.qm@web23608.mail.ird.yahoo.com> Message-ID: Daniel I have a hard time understanding you. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.49.3474&rep=rep1&type=pdf Is interesting though. We should make sure that stuff still works, and fix it if not. i.e. the heap debugging tools embedded in the runtime (shownew, etc.) ?- Jay ---------------------------------------- > Date: Sun, 18 Jul 2010 03:28:54 +0000 > From: dabenavidesd at yahoo.es > To: m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] compiler behavior under "low memory"? > > Hi: > If it only had such small memory requirements I suppose less than 64 MB RAM I didn't get the number of interfaces is about the same (probably a 10 % larger by now with new added packages), probably the best way forward is not just to change the swap memory as its a common sense to double the RAM but in that case you would need such a thing for one process less the rest of operating system, i.e solution is not general, If I understand well Mark 's Alpha DEC machine had the same machine and probably with M3 running in top of it in 1995. I wonder how these years have expanded the compilers proficiency (as time is against space and vice-versa, that is, less time is more memory like to make a recursive program to unfold in a sequential one) in such a memory constrained environments could be solved I can remember now that there was a change in Amer Diwan Whole program optimizer to grab in a pickled AST to later unpickle it and compile to M3CG-machine assembly > optimized see: > http://www.modula3.org/threads/1/#advanced > and also a proposed or to-do of DEC-SRC M3 days about Cache policy it mentioned see: > http://www.cs.arizona.edu/~collberg/Research/Modula-3/modula-3/html/todo.html > AST cache policy. The current driver keeps an in-memory cache of compiled interfaces, but never flushes entries, this refers to the simple problem of big heap which another application generated out of memory back in those days the ESC/Modula-3 checker available for Alphas see: > http://web.archive.org/web/20030704143617/http://research.compaq.com/SRC/esc/escm3/bin/Esc.alpha.bin.Z (which was user of Simplify theorem prover http://portal.acm.org/citation.cfm?id=1066100.1066102 > or doi:0.1145/1066100.1066102 as it should be cited and also used m3tk toolkit ) and they managed to solve by means of calling the collector to scan and throw away the uncollected things at least in Simplify, years later I retired the line with no problem in Simplify and all run in good benchmarks tests of Simplify with no problems see too http://qpq.csl.sri.com/downloads/simplify_benchmarks-tar.gz/view > The result was that they created a tool to understand where the memory heap was being actually ran out of memory and they manage to solve I believe by managing the same way besides clearing stuff not needed something is useful in any garbage collected type language http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.49.3474&rep=rep1&type=pdf > see slides onhttp://labs.oracle.com/people/detlefs/papers/detlefs-coots95-slides.ps and extra figures http://labs.oracle.com/people/detlefs/papers/detlefs-coots95-slides2.ps > In our case in that case as it can't throw away AST representations before M3CG-machine tough there is separate compilation we don't manage to type check all m3tk in runtime eliminating when is compiled and not used code generation currently the problem might be solved in the compilation server written for pm3 (see: > http://arxiv.org/pdf/cs/0506035 ) > or as Amer Diwan solved to manage for his particular purposes (see ftp://ftp.cs.umass.edu/pub/osl/papers/diwan-dissertation.ps.gz) because in any case of low resources limits it would be stored pickled or in swaped memory in the disc but in non-low memory limits it would be in both memory and disk as it is now (at some point you need to bring from copy from disk the needed bytes back to memory). > Besides that the implemented behavior on VM exhaustion should be not taken in false as guys didn't in those days > http://modula3.elegosoft.com/pm3/intro/questions/new.html > An implemented solution but actually not used not seen here: > > http://web.archive.org/web/19980613063641/www.vlsi.polymtl.ca/m3/pkg/contrib/whenNEWfails/.ghindex.html > > Thanks for any corrections in advance if so > > > > > > --- El s?b, 17/7/10, Jay K escribi?: > > > De: Jay K > > Asunto: [M3devel] compiler behavior under "low memory"? > > Para: "m3devel" > > Fecha: s?bado, 17 de julio, 2010 20:30 > > > > Mark had a machine with low memory. > > It has more swap now. > > > > > > Our behavior was: > > > > > > Compiling m3tk would make good progress, complete many > > files, then fail for > > lack of memory. > > > > > > Manual retry would start over due to > > "missing version information" or such. > > > > > > Thus progress was "impossible". > > By editing down m3makefile I was able to make progress. > > Some stuff would fail due to missing interfaces, but > > whatever I left in would get the version information > > saved. > > > > > > Perhaps we should write out the version information every > > "few" files? > > For some definition of "few"? 10? 10% of the total? > > > > > > That would at least let such situations progress via manual > > retry. > > (unless not even a "few" fit in memory) > > > > > > I also wonder about reducing memory used, or why indeed we > > run out, > > but that is a thornier problem. You know, all we should > > need to > > continue forward progress is to hold all interfaces in > > memory and > > one implementation at a time. Now, there are a few > > unknowns here. > > It is possible Mark's machine didn't have enough memory > > for > > all the relevant interfaces, and that we only "load" them > > on-demand. > > > > > > It is also likely, I should add, that virtual address > > space is the > > problem, not working set. Some systems want to commit > > room > > in swap for all allocated virtual memory, like, to be > > sure > > ahead of time that everything can be paged out so other > > code can progress. Something like that. I'm not sure > > here. > > That is, I suspect we don't care. Virtual address space > > is probably > > reasonable to deem cheap. No problem using almost 2GB of > > address space > > as long as working set isn't that large (ie: to fit in > > 31bit address space). > > If some OSes don't see it that way, oh well. This might > > just > > be a design/policy thing in Tru64. > > > > > > (I'm well aware of virtual memory vs. physical memory vs. > > working set. > > But for whatever reason, we were failing due to memory > > use. > > All that *should* matter is that address space usage stays > > within > > around 2GB and that working set isn't huge. Working set > > I've recently > > come to understand can be managed like so: > > - random access over set of memory that fits in physical > > memory > > - sequential access over arbitrary memory (up to 2GB) > > - hybrid of previous > > ie. sequential accesses over multiple separate > > areas > > > > As long as access is sequential, you shouldn't "thrash". > > It is only random access over data that doesn't fit in > > physical memory > > that causes thrashing.) > > > > > > - Jay > > > > > > > > > > > > From jay.krell at cornell.edu Sun Jul 18 08:36:45 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 18 Jul 2010 06:36:45 +0000 Subject: [M3devel] Modula-3 condition variables vs. pthread/Win32 condition variables? Message-ID: I was thinking of writing "ThreadWin6.m3". We'd check GetVersion and if it is >= 6.0, use it instead. This would give us: ? smaller locks ? condition variables ? likely isomorphic code with ThreadPThread.m3 Question, probably a repeat: (I'll check the archives) ? Why aren't Modula-3 condition variables a thinner wrapper over pthread condition variables? One difference I see is alert. Can't alert just signal the condition being waited on? Might need interlocked operations against alertable and alerted, and maybe also thread.cond? ? (Should be viable, even within one word, use the lower two bits of thread.cond?) ? ?- Jay From jay.krell at cornell.edu Sun Jul 18 14:00:05 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 18 Jul 2010 12:00:05 +0000 Subject: [M3devel] moving to new target names, in Hudson? Message-ID: Olaf, can I request that if/when you move Hudson to head, that you also switch to I386_LINUX, I386_FREEBSD, I386_NT, and whatever we decide for SPARC32_SOLARIS? I've mostly switched to them myself. It wasn't difficult. (I always say that). I think for SPARC32_SOLARIS we should either have SPARC32_SOLARIS that is the equivalent of today's SOLsun. Effectively dropping SOLgnu. Or we also add SPARC32_SOLARIS_gcc, which is just a configuration file and not a target. This is like the "experiment" I did with NT386/NT386GNU, which I think I regret, except SPARC32_SOLARIS / SPARC32_SOLAROS_gcc are far far more similar than those. All their platform-specific code is identical. Their backend is identical. etc. A related option is SPARC32_SOLARIS_cc or SPARC32_SOLARIS_suncc, and SPARC32_SOLARIS_gcc. Config files. But the compiler only know about SPARC32_SOLARIS. Just putting the two config files more as peers, so to speak. The way I switched targets was probably doing a cross build. That is overkill. You can probably just export CM3_TARGET to the name you want. And maybe fiddle with shipping of cm3cg or settings its build_dir -- i.e. leave it as just host and host-target. Thanks, ?- Jay From jay.krell at cornell.edu Sun Jul 18 14:44:25 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 18 Jul 2010 12:44:25 +0000 Subject: [M3devel] div/mod Message-ID: ok, this is a really minor thing. Very esoteric, waste of time probably. Div and mod are defined in terms of each other. In the "real world", any integer mod negative 1 is 0. ? All integers are "evenly divisible" by 1 and negative 1. So INT_MIN mod -1 is 0. One can code that to be the case. Some versions of the code do. ? I'm not sure about the current code, as we don't call the C functions any longer, except for int64 on NT386. ? The older div/mod helpers, depending on optimization, would either return 0 ?? or generate an overflow exception. In our computer world, INT_MIN div -1 is not computable, and generates ? the same exception. Even with current code. If div and mod are defined in terms of each other, and one of them is not computable, ? is it wrong to be able to compute the other? ?- Jay From jay.krell at cornell.edu Sun Jul 18 15:35:51 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 18 Jul 2010 13:35:51 +0000 Subject: [M3devel] Alpha/OSF exception handling Message-ID: Modula-3 for ALPHA_OSF historically had the best exception handling implementation. With Solaris/sparc32 second best. And then everything else equally bad. The current Alpha/osf is now in the "equally bad" category. Because I'm lazy. It might be worth restoring its former glory. Maybe a small project for someone? The code is still in there. I just tweaked the m3makefiles to avoid trying it. jbook2:runtime jay$ pwd /dev2/cm3/m3-libs/m3core/src/runtime jbook2:runtime jay$ find ALPHA_OSF ALPHA_OSF/m3makefile-old Renaming that m3makefile. Fiddling with this: book2:runtime jay$ grep STACK * m3makefile:readonly HAS_STACK_WALKER = { m3makefile:if defined("M3_USE_STACK_WALKER") m3makefile:? if M3_USE_STACK_WALKER and HAS_STACK_WALKER contains TARGET m3makefile:??? if HAS_STACK_WALKER{TARGET} and this: jbook2:src jay$ pwd /dev2/cm3/m3-sys/m3middle/src book2:src jay$ grep -i _stack *m3 Target.m3:??? Has_stack_walker????????? := FALSE; Target.m3:???????????????? Has_stack_walker := TRUE; ?- Jay From wagner at elegosoft.com Sun Jul 18 16:55:13 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 18 Jul 2010 16:55:13 +0200 Subject: [M3devel] Hudson regression for current cm3 / incompatibilities Message-ID: <20100718165513.gug2fuk04k8cww0o@mail.elegosoft.com> I've disabled the existing cm3 build and test jobs on Hudson and copied them to new ones all named cm3-current-*; I've also added a new view cm3-current that is now displayed by default. The now disabled jobs may be used again for the next release. However, already some incompatibilities seen to habe crept in. Neither the m3cc nor the build jobs succeed; i.e. the current sources cannot be built with the latest release version, even with the upgrade script. This should be fixed. Please have a look at http://hudson.modula3.com:8080/ When everything looks good again, I'll start to rename some of the jobs to new platform names as Jay requested (if we can all agree on them). However, this will take some more time and a better connection than that I currently have here from my mobile notebook. And now for something completely different again (it's weekend after all), Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Jul 18 17:04:26 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 18 Jul 2010 17:04:26 +0200 Subject: [M3devel] moving to new target names, in Hudson? In-Reply-To: References: Message-ID: <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com> Quoting Jay K : > Olaf, can I request that if/when you move Hudson to head, that you > also switch to I386_LINUX, I386_FREEBSD, I386_NT, > and whatever we decide for SPARC32_SOLARIS? > I've mostly switched to them myself. It wasn't difficult. (I always > say that). It will require a lot of manual work, compared to the more or less automated transition I just made from release to current for all the jobs. The target platform names are part of the jobs, and are also used in various places in the build scripts, so that many things are likely to break. My guess is that it will take some days for every target move given my current attention pattern for cm3, i.e. have a look at how things work out now and then between other work. Let's wait until all the jobs work again with their old target names, Olaf > I think for SPARC32_SOLARIS we should either have SPARC32_SOLARIS > that is the equivalent of today's SOLsun. > Effectively dropping SOLgnu. > > > Or we also add SPARC32_SOLARIS_gcc, which is just a configuration > file and not a target. > This is like the "experiment" I did with NT386/NT386GNU, which I > think I regret, except > SPARC32_SOLARIS / SPARC32_SOLAROS_gcc are far far more similar than those. > All their platform-specific code is identical. Their backend is > identical. etc. > > > A related option is SPARC32_SOLARIS_cc or SPARC32_SOLARIS_suncc, and > SPARC32_SOLARIS_gcc. > Config files. > But the compiler only know about SPARC32_SOLARIS. > Just putting the two config files more as peers, so to speak. > > > The way I switched targets was probably doing a cross build. > That is overkill. You can probably just export CM3_TARGET to the > name you want. > And maybe fiddle with shipping of cm3cg or settings its build_dir -- > i.e. leave it as just host and host-target. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sun Jul 18 18:16:15 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 18 Jul 2010 16:16:15 +0000 Subject: [M3devel] Hudson regression for current cm3 / incompatibilities In-Reply-To: <20100718165513.gug2fuk04k8cww0o@mail.elegosoft.com> References: <20100718165513.gug2fuk04k8cww0o@mail.elegosoft.com> Message-ID: This is great Olaf, having this already going, no matter the target names. I'll watch it. Thanks, ?- Jay ---------------------------------------- > Date: Sun, 18 Jul 2010 16:55:13 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] Hudson regression for current cm3 / incompatibilities > > I've disabled the existing cm3 build and test jobs on Hudson and copied > them to new ones all named cm3-current-*; I've also added a new view > cm3-current that is now displayed by default. > The now disabled jobs may be used again for the next release. > > However, already some incompatibilities seen to habe crept in. > Neither the m3cc nor the build jobs succeed; i.e. the current sources > cannot be built with the latest release version, even with the > upgrade script. > > This should be fixed. > > Please have a look at > > http://hudson.modula3.com:8080/ > > When everything looks good again, I'll start to rename some of the > jobs to new platform names as Jay requested (if we can all agree on them). > However, this will take some more time and a better connection than that > I currently have here from my mobile notebook. > > And now for something completely different again (it's weekend after all), > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Sun Jul 18 18:25:35 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 18 Jul 2010 16:25:35 +0000 Subject: [M3devel] CM3 on Alpha tru64 4.0G In-Reply-To: References: , , ,,, ,,,,, , <9241B253-8004-4DDD-B1EF-A7D02A3FEAFD@cs.purdue.edu>, ,,, ,,<76827F66-451E-410E-9AF0-200D9538AFA1@cs.purdue.edu>, ,,<1279048755.1793.13.camel@x60.appsoftint.co.uk>, ,,<8E02058D-1A62-48FF-8DA7-B2C40C53B048@cs.purdue.edu>, , , <1279053628.1793.15.camel@x60.appsoftint.co.uk>, , , Message-ID: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-all-ALPHA_OSF-d5.8.2-OSF1V4.0-20100718.tar.gz http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-ALPHA_OSF-d5.8.2-OSF1V4.0-20100718.tar.gz System built itself natively on Mark's machine. Using pthreads. But no stack walker (I'm lazy and didn't even try it). Mark reports some GUI apps working. Would be cool to get this in Hudson but I think the current machines have too old Java. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: mark at wickensonline.co.uk; hosking at cs.purdue.edu > Date: Tue, 13 Jul 2010 23:27:51 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] CM3 on Alpha tru64 4.0G > > > > Things to try: cross build, user threads. > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-ALPHA_OSF-pthreads-d5.8.2-20100713.tgz > or > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-ALPHA_OSF-userthreads-d5.8.2-20100713.tgz > > ? > > And in userthreads, if there is no get/set/make/swapcontext, you can change the #if at the top of ThreadPosixC.c to try sigaltstack. > Also the userthreads Makefile has -lpthread in it, which you'll maybe want to remove...depending on if there is pthread_atfork, i.e. you might want to tweak this: > jbook2:cm3-boot-ALPHA_OSF-d5.8.2-20100713 jay$ grep pthread_atfork *c > RTProcessC.c: int i = pthread_atfork(prepare, parent, child); > > > but try the pthread version first? > > These will give you a cm3 and if it prints "unable to find cm3.cfg", good. > > Tru64 4.x isn't officially supported by gcc any longer, but I noticed recent test results posted anyway. > You just have to configure -enable-obsolete or somesuch. > > Can you give me ssh access? That's a good and bad thing. Should be doable without such direct help by me.. > > - Jay > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: mark at wickensonline.co.uk; hosking at cs.purdue.edu > > Date: Tue, 13 Jul 2010 23:04:20 +0000 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] CM3 on Alpha tru64 4.0G > > > > > > Things to try: cross build, user threads. > > Do you have a "modern" system with a working cm3? > > Do you have cvs and a working C compiler/linker on this older system? > > > > - Jay > > > > ---------------------------------------- > > > From: mark at wickensonline.co.uk > > > To: hosking at cs.purdue.edu > > > Date: Tue, 13 Jul 2010 21:40:28 +0100 > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] CM3 on Alpha tru64 4.0G > > > > > > Hi Tony, the exception I get is as follows: > > > > > > >From cm3-min-ALPHA_OSF-d5.8.2-20100612/bin > > > > > > bash-3.2$ ./cm3 > > > %DECthreads bugcheck (version V3.18-037), terminating execution. > > > % Reason: stkGet: (4) nxm_stack_create (0,5251072,16384,8192) > > > % Running on OSF1 V4.0(1530) on AlphaServer 300 4/266, 256Mb; 1 CPUs, > > > pid 21360 > > > > > > > > > From hosking at cs.purdue.edu Sun Jul 18 20:21:32 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 18 Jul 2010 14:21:32 -0400 Subject: [M3devel] Modula-3 condition variables vs. pthread/Win32 condition variables? In-Reply-To: References: Message-ID: <1908F6C1-08D0-46FE-89DE-D0B5BDEBDC59@cs.purdue.edu> On 18 Jul 2010, at 02:36, Jay K wrote: > > I was thinking of writing "ThreadWin6.m3". > We'd check GetVersion and if it is >= 6.0, use it instead. > This would give us: > smaller locks > condition variables > likely isomorphic code with ThreadPThread.m3 > > > Question, probably a repeat: (I'll check the archives) > Why aren't Modula-3 condition variables a thinner wrapper over pthread condition variables? Because there is no reliable way to alert a thread waiting on a condition variable. And we need a uniform way to handshake with a thread for GC, etc. Better just to build on the per-thread CV. > One difference I see is alert. Can't alert just signal the condition being waited on? > > > Might need interlocked operations against alertable and alerted, and maybe also thread.cond? > (Should be viable, even within one word, use the lower two bits of thread.cond?) Again, probably not a good idea going forward -- we will ultimately build M3 mutex/CV with non-blocking primitives where possible and inflate to pthread mutex only rarely. > > ? > > > - Jay > > > > > From hosking at cs.purdue.edu Sun Jul 18 20:22:41 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 18 Jul 2010 14:22:41 -0400 Subject: [M3devel] Alpha/OSF exception handling In-Reply-To: References: Message-ID: That is a huge shame. Why did you remove it? It used to be there and functional. On 18 Jul 2010, at 09:35, Jay K wrote: > > Modula-3 for ALPHA_OSF historically had the best exception handling implementation. > > With Solaris/sparc32 second best. > > And then everything else equally bad. > > > > > > The current Alpha/osf is now in the "equally bad" category. > Because I'm lazy. > > It might be worth restoring its former glory. > > > > Maybe a small project for someone? > > > The code is still in there. I just tweaked the m3makefiles to avoid trying it. > > > jbook2:runtime jay$ pwd > /dev2/cm3/m3-libs/m3core/src/runtime > jbook2:runtime jay$ find ALPHA_OSF > ALPHA_OSF/m3makefile-old > > Renaming that m3makefile. > > Fiddling with this: > > book2:runtime jay$ grep STACK * > m3makefile:readonly HAS_STACK_WALKER = { > m3makefile:if defined("M3_USE_STACK_WALKER") > m3makefile: if M3_USE_STACK_WALKER and HAS_STACK_WALKER contains TARGET > m3makefile: if HAS_STACK_WALKER{TARGET} > > > and this: > > > jbook2:src jay$ pwd > /dev2/cm3/m3-sys/m3middle/src > > > book2:src jay$ grep -i _stack *m3 > Target.m3: Has_stack_walker := FALSE; > Target.m3: Has_stack_walker := TRUE; > > > - Jay > From rodney_bates at lcwb.coop Mon Jul 19 00:41:43 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 18 Jul 2010 17:41:43 -0500 Subject: [M3devel] div/mod In-Reply-To: References: Message-ID: <4C438327.1070907@lcwb.coop> Jay K wrote: > ok, this is a really minor thing. Very esoteric, waste of time probably. > > > Div and mod are defined in terms of each other. > > > In the "real world", any integer mod negative 1 is 0. > All integers are "evenly divisible" by 1 and negative 1. > > So INT_MIN mod -1 is 0. > > > One can code that to be the case. Some versions of the code do. > I'm not sure about the current code, as we don't call the C functions any longer, except for int64 on NT386. > The older div/mod helpers, depending on optimization, would either return 0 > or generate an overflow exception. > > > In our computer world, INT_MIN div -1 is not computable, and generates > the same exception. Even with current code. My view of this is that the only reason INT_MIN DIV -1 raises an exception is that the mathematical result is not in INTEGER. The definitions of all the arithmetic operators in the language should be viewed as using the (unlimited range) operations of mathematics, with overflow happening if this lies outside the range of the result type. In fact, I doubt you can sensibly interpret the definitions in the language any other way. So it makes perfect sense for the DIV to raise the exception and the MOD not, since 0 is indeed in INTEGER. > > > If div and mod are defined in terms of each other, and one of them is not computable, > is it wrong to be able to compute the other? > > > - Jay > > From jay.krell at cornell.edu Mon Jul 19 02:16:46 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Jul 2010 00:16:46 +0000 Subject: [M3devel] Hudson regression for current cm3 / incompatibilities In-Reply-To: References: <20100718165513.gug2fuk04k8cww0o@mail.elegosoft.com>, Message-ID: Things are better now. Several jobs have succeeded. e.g. lots of I386_DARWIN, AMD64_LINUX, LINUXLIBC. Not all platforms have tried anything though. I just kicked some. e.g. SOLgnu. Not all platforms have new jobs. e.g. AMD64_DARWIN, NT386, SOLsun, PPC_DARWIN, PPC_LINUX, I386_OPENBSD. SPARC32_LINUX is still broken for reasons specific to it or at least sparc-specific. I'll look at it. cm3-current-build-FreeBSD4 seems hung. Thanks, ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Subject: RE: [M3devel] Hudson regression for current cm3 / incompatibilities > Date: Sun, 18 Jul 2010 16:16:15 +0000 > > > This is great Olaf, having this already going, no matter the target names. > I'll watch it. > > Thanks, > - Jay > > ---------------------------------------- > > Date: Sun, 18 Jul 2010 16:55:13 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: [M3devel] Hudson regression for current cm3 / incompatibilities > > > > I've disabled the existing cm3 build and test jobs on Hudson and copied > > them to new ones all named cm3-current-*; I've also added a new view > > cm3-current that is now displayed by default. > > The now disabled jobs may be used again for the next release. > > > > However, already some incompatibilities seen to habe crept in. > > Neither the m3cc nor the build jobs succeed; i.e. the current sources > > cannot be built with the latest release version, even with the > > upgrade script. > > > > This should be fixed. > > > > Please have a look at > > > > http://hudson.modula3.com:8080/ > > > > When everything looks good again, I'll start to rename some of the > > jobs to new platform names as Jay requested (if we can all agree on them). > > However, this will take some more time and a better connection than that > > I currently have here from my mobile notebook. > > > > And now for something completely different again (it's weekend after all), > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > > From jay.krell at cornell.edu Mon Jul 19 02:20:05 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Jul 2010 00:20:05 +0000 Subject: [M3devel] Hudson regression for current cm3 / incompatibilities In-Reply-To: References: <20100718165513.gug2fuk04k8cww0o@mail.elegosoft.com>, , , Message-ID: Oops. I was looking at the platform views instead of the cm3-current view. Things are better and worse than I said. More jobs exist, more jobs have succeeded, more jobs have also failed (that exist!) and I need to look at, e.g. PPC_DARWIN. I understand the PPC_DARWIN problem already -- related to building on older platform and my forcing autoconf to believe features are there. I know what to do. Thanks, ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Date: Mon, 19 Jul 2010 00:16:46 +0000 > Subject: Re: [M3devel] Hudson regression for current cm3 / incompatibilities > > > Things are better now. Several jobs have succeeded. e.g. lots of I386_DARWIN, AMD64_LINUX, LINUXLIBC. > Not all platforms have tried anything though. I just kicked some. e.g. SOLgnu. > Not all platforms have new jobs. e.g. AMD64_DARWIN, NT386, SOLsun, PPC_DARWIN, PPC_LINUX, I386_OPENBSD. > SPARC32_LINUX is still broken for reasons specific to it or at least sparc-specific. I'll look at it. > cm3-current-build-FreeBSD4 seems hung. > > Thanks, > - Jay > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com; m3devel at elegosoft.com > > Subject: RE: [M3devel] Hudson regression for current cm3 / incompatibilities > > Date: Sun, 18 Jul 2010 16:16:15 +0000 > > > > > > This is great Olaf, having this already going, no matter the target names. > > I'll watch it. > > > > Thanks, > > - Jay > > > > ---------------------------------------- > > > Date: Sun, 18 Jul 2010 16:55:13 +0200 > > > From: wagner at elegosoft.com > > > To: m3devel at elegosoft.com > > > Subject: [M3devel] Hudson regression for current cm3 / incompatibilities > > > > > > I've disabled the existing cm3 build and test jobs on Hudson and copied > > > them to new ones all named cm3-current-*; I've also added a new view > > > cm3-current that is now displayed by default. > > > The now disabled jobs may be used again for the next release. > > > > > > However, already some incompatibilities seen to habe crept in. > > > Neither the m3cc nor the build jobs succeed; i.e. the current sources > > > cannot be built with the latest release version, even with the > > > upgrade script. > > > > > > This should be fixed. > > > > > > Please have a look at > > > > > > http://hudson.modula3.com:8080/ > > > > > > When everything looks good again, I'll start to rename some of the > > > jobs to new platform names as Jay requested (if we can all agree on them). > > > However, this will take some more time and a better connection than that > > > I currently have here from my mobile notebook. > > > > > > And now for something completely different again (it's weekend after all), > > > > > > Olaf > > > -- > > > Olaf Wagner -- elego Software Solutions GmbH > > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > > > > > From jay.krell at cornell.edu Mon Jul 19 03:33:05 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Jul 2010 01:33:05 +0000 Subject: [M3devel] Hudson m3cc clean? In-Reply-To: <20100719012318.ABC2E2474003@birch.elegosoft.com> References: <20100719012318.ABC2E2474003@birch.elegosoft.com> Message-ID: Olaf, the m3cc tasks should run "clean" with this -- configure needs to rerun. It seems some have such a check mark option, some do not. Platforms that are succeeding I guess can be left alone, but the ppc/sparc ones.. The ones on my machines I can fiddle with, but PPC_DARWIN.. Thanks, ?- Jay ---------------------------------------- > Date: Mon, 19 Jul 2010 03:23:16 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/07/19 03:23:16 > > Modified files: > cm3/m3-sys/m3cc/src/: m3makefile > cm3/m3-sys/m3cc/gcc/gcc/config/: darwin.h > > Log message: > m3makefile, basically undo: > Revision 1.162 > always specify -build, -host, -target, for cross and native > consistent but experimenta/unorthodox > Usually people let config.guess do all the work for native > and always for build. > Default build to host, not target. > > Revision 1.161 > Always specify -target. > in native builds, always specify -build and -host. > This should provide for more consistency, > though is also a bit experimental and unorthodox. > > darwin.h, undo > Revision 1.2 > always support hidden aka private extern aka don't export every function > > This should fix PPC_DARWIN and maybe maybe others (SPARC32_LINUX). > > Possibly relatd, I've noticed SOLsun using sparc-sun-solaris2.10-gcc > to build cm3cg, when I was hoping it'd use Sun cc. This will > at least change it to plain gcc, but same thing. > From jay.krell at cornell.edu Mon Jul 19 05:53:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Jul 2010 03:53:08 +0000 Subject: [M3devel] Hudson m3cc clean? In-Reply-To: References: <20100719012318.ABC2E2474003@birch.elegosoft.com>, Message-ID: They should probably all be clean. Given also the merge to 4.3.5. And that I put back dependency tracking. I think I'll put something in m3cc/src/m3makefile with a timestamp or guid, checked in by developer, copied to an output file in build_dir, and if they vary, delete everything. So checking in a deliberate edit to m3cc/src/m3makefile will trigger clean. In the mean time did *some* ssh root@ ; cd ~hudson; rm -rf */*/m3cc/{PPC_LINUX,SPARC32_LINUX} on my machines. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Subject: Hudson m3cc clean? > Date: Mon, 19 Jul 2010 01:33:05 +0000 > > > Olaf, the m3cc tasks should run "clean" with this -- configure needs to rerun. > It seems some have such a check mark option, some do not. > Platforms that are succeeding I guess can be left alone, but the ppc/sparc ones.. > The ones on my machines I can fiddle with, but PPC_DARWIN.. > > Thanks, > - Jay > > ---------------------------------------- > > Date: Mon, 19 Jul 2010 03:23:16 +0000 > > To: m3commit at elegosoft.com > > From: jkrell at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 10/07/19 03:23:16 > > > > Modified files: > > cm3/m3-sys/m3cc/src/: m3makefile > > cm3/m3-sys/m3cc/gcc/gcc/config/: darwin.h > > > > Log message: > > m3makefile, basically undo: > > Revision 1.162 > > always specify -build, -host, -target, for cross and native > > consistent but experimenta/unorthodox > > Usually people let config.guess do all the work for native > > and always for build. > > Default build to host, not target. > > > > Revision 1.161 > > Always specify -target. > > in native builds, always specify -build and -host. > > This should provide for more consistency, > > though is also a bit experimental and unorthodox. > > > > darwin.h, undo > > Revision 1.2 > > always support hidden aka private extern aka don't export every function > > > > This should fix PPC_DARWIN and maybe maybe others (SPARC32_LINUX). > > > > Possibly relatd, I've noticed SOLsun using sparc-sun-solaris2.10-gcc > > to build cm3cg, when I was hoping it'd use Sun cc. This will > > at least change it to plain gcc, but same thing. > > > From jay.krell at cornell.edu Mon Jul 19 08:10:58 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Jul 2010 06:10:58 +0000 Subject: [M3devel] clean in m3cc Message-ID: Too dangerous: m3cc/src/m3makefile if stale(build_dir & "/clean_marker.txt", "../src/clean_marker.txt") or defined ("FORCE") ? m3cc_Run(["rm -rf " & build_dir & "/*"]) ? cp_if("../src/clean_marker.txt", build_dir & "/clean_marker.txt") end ? If build_dir has a space..? ?- Jay From jay.krell at cornell.edu Mon Jul 19 08:17:29 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Jul 2010 06:17:29 +0000 Subject: [M3devel] clean in m3cc In-Reply-To: References: Message-ID: nevermind ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 19 Jul 2010 06:10:58 +0000 > Subject: [M3devel] clean in m3cc > > > Too dangerous: > > m3cc/src/m3makefile > > if stale(build_dir & "/clean_marker.txt", "../src/clean_marker.txt") or defined ("FORCE") > m3cc_Run(["rm -rf " & build_dir & "/*"]) > cp_if("../src/clean_marker.txt", build_dir & "/clean_marker.txt") > end > > ? > > If build_dir has a space..? > > > - Jay > > From wagner at elegosoft.com Mon Jul 19 08:27:13 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 19 Jul 2010 08:27:13 +0200 Subject: [M3devel] compiler behavior under "low memory"? In-Reply-To: References: Message-ID: <20100719082713.yjrrwn53b40sw0gc@mail.elegosoft.com> Perhaps a small limit was set on the system? (bash: ulimit, csh: limit) As for a fix, perhaps we could catch the exception in the builder and write out all known version information acquired so far (FINALLY block)? Olaf Quoting Jay K : > Mark had a machine with low memory. > It has more swap now. > > Our behavior was: > > Compiling m3tk would make good progress, complete many files, then fail for > ?lack of memory. > > Manual retry would start over due to > ?"missing version information" or such. > > Thus progress was "impossible". > By editing down m3makefile I was able to make progress. > ?Some stuff would fail due to missing interfaces, but > ?whatever I left in would get the version information saved. > ? > Perhaps we should write out the version information every "few" files? > ?For some definition of "few"? 10? 10% of the total? > ? > ? > That would at least let such situations progress via manual retry. > ? (unless not even a "few" fit in memory) > > > I also wonder about reducing memory used, or why indeed we run out, > ?but that is a thornier problem. You know, all we should need to > ?continue forward progress is to hold all interfaces in memory and > ?one implementation at a time. Now, there are a few unknowns here. > ?It is possible Mark's machine didn't have enough memory for > ?all the relevant interfaces, and that we only "load" them on-demand. > > ? > ?It is also likely, I should add, that virtual address space is the > ? problem, not working set. Some systems want to commit room > ? in swap for all allocated virtual memory, like, to be sure > ? ahead of time that everything can be paged out so other > ? code can progress. Something like that. I'm not sure here. > ? That is, I suspect we don't care. Virtual address space is probably > ? reasonable to deem cheap. No problem using almost 2GB of address space > ? as long as working set isn't that large (ie: to fit in 31bit > address space). > ? If some OSes don't see it that way, oh well. This might just > ? be a design/policy thing in Tru64. > ? > ? > (I'm well aware of virtual memory vs. physical memory vs. working set. > But for whatever reason, we were failing due to memory use. > All that *should* matter is that address space usage stays within > around 2GB and that working set isn't huge. Working set I've recently > come to understand can be managed like so: > ? - random access over set of memory that fits in physical memory > ? - sequential access over arbitrary memory (up to 2GB) > ? - hybrid of previous > ????? ie. sequential accesses over multiple separate areas > > As long as access is sequential, you shouldn't "thrash". > It is only random access over data that doesn't fit in physical memory > ?that causes thrashing.) > > > ?- 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 wagner at elegosoft.com Mon Jul 19 08:30:13 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 19 Jul 2010 08:30:13 +0200 Subject: [M3devel] multithreaded compiler? In-Reply-To: References: Message-ID: <20100719083013.uediq2tuogowg04g@mail.elegosoft.com> Quoting Jay K : > It should be reasonably easy to have the gcc backend run on multiple > separate threads. This won't necessarily speed things up, but could be an interesting option (-j ) depending on the machine in use. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Jul 19 09:31:22 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Jul 2010 07:31:22 +0000 Subject: [M3devel] Alpha/OSF exception handling In-Reply-To: References: , Message-ID: I didn't "remove" it, but I did "disable" it. Similar. I didn't want to have to spend any time debugging it if it didn't work any longer. I'm sure we have precious few users of this system (2 this month though, quite a surge) and they can probably live with an equally bad implementation as all the other platforms (except for Solaris/sparc). ? Granted, they have slower than average systems, would benefit more perhaps from the optimization. We can try it out I guess. I do hope we can improve this across the aboard. ? Even if we don't use the tree exception handling nodes, we can probably at least use the same runtime support (libunwind in libgcc). ? Even then, Alpha/OSF won't be important. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Sun, 18 Jul 2010 14:22:41 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Alpha/OSF exception handling > > That is a huge shame. Why did you remove it? It used to be there and functional. > > On 18 Jul 2010, at 09:35, Jay K wrote: > > > > > Modula-3 for ALPHA_OSF historically had the best exception handling implementation. > > > > With Solaris/sparc32 second best. > > > > And then everything else equally bad. > > > > > > > > > > > > The current Alpha/osf is now in the "equally bad" category. > > Because I'm lazy. > > > > It might be worth restoring its former glory. > > > > > > > > Maybe a small project for someone? > > > > > > The code is still in there. I just tweaked the m3makefiles to avoid trying it. > > > > > > jbook2:runtime jay$ pwd > > /dev2/cm3/m3-libs/m3core/src/runtime > > jbook2:runtime jay$ find ALPHA_OSF > > ALPHA_OSF/m3makefile-old > > > > Renaming that m3makefile. > > > > Fiddling with this: > > > > book2:runtime jay$ grep STACK * > > m3makefile:readonly HAS_STACK_WALKER = { > > m3makefile:if defined("M3_USE_STACK_WALKER") > > m3makefile: if M3_USE_STACK_WALKER and HAS_STACK_WALKER contains TARGET > > m3makefile: if HAS_STACK_WALKER{TARGET} > > > > > > and this: > > > > > > jbook2:src jay$ pwd > > /dev2/cm3/m3-sys/m3middle/src > > > > > > book2:src jay$ grep -i _stack *m3 > > Target.m3: Has_stack_walker := FALSE; > > Target.m3: Has_stack_walker := TRUE; > > > > > > - Jay > > > From wagner at elegosoft.com Mon Jul 19 09:49:59 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 19 Jul 2010 09:49:59 +0200 Subject: [M3devel] Hudson regression for current cm3 / incompatibilities In-Reply-To: References: <20100718165513.gug2fuk04k8cww0o@mail.elegosoft.com>, , , Message-ID: <20100719094959.plxt7b5u8c0og8o8@mail.elegosoft.com> Quoting Jay K : > Oops. I was looking at the platform views instead of the cm3-current view. > Things are better and worse than I said. More jobs exist, more jobs > have succeeded, more jobs have also failed (that exist!) and I need > to look at, e.g. PPC_DARWIN. > I understand the PPC_DARWIN problem already -- related to building > on older platform and my forcing autoconf to believe features are > there. > I know what to do. O know that my script missed NT386 jobs, but the others should all be there. I'll add that manually today. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Jul 19 10:17:15 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 19 Jul 2010 10:17:15 +0200 Subject: [M3devel] clean in m3cc In-Reply-To: References: Message-ID: <20100719101715.r4k0ubcc0oo80oso@mail.elegosoft.com> I've added a Hudson build variable CLEAN to all cm3-current-m3cc-* jobs. Olaf Quoting Jay K : > nevermind > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Date: Mon, 19 Jul 2010 06:10:58 +0000 >> Subject: [M3devel] clean in m3cc >> >> >> Too dangerous: >> >> m3cc/src/m3makefile >> >> if stale(build_dir & "/clean_marker.txt", >> "../src/clean_marker.txt") or defined ("FORCE") >> m3cc_Run(["rm -rf " & build_dir & "/*"]) >> cp_if("../src/clean_marker.txt", build_dir & "/clean_marker.txt") >> end >> >> ? >> >> If build_dir has a space..? >> >> >> - 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 mika at async.async.caltech.edu Mon Jul 19 11:01:10 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Mon, 19 Jul 2010 02:01:10 -0700 Subject: [M3devel] div/mod In-Reply-To: References: Message-ID: <20100719090110.8ED961A2084@async.async.caltech.edu> No, aborting is always something the implementation is permitted to do if it can't do the sensible thing. If it can do something sensible, it may still be permitted to abort, but is not under the obligation to do so. I think this is a general principle. Mika Jay K writes: > >ok=2C this is a really minor thing. Very esoteric=2C waste of time probably= >. > > >Div and mod are defined in terms of each other. > > >In the "real world"=2C any integer mod negative 1 is 0.=20 >=A0 All integers are "evenly divisible" by 1 and negative 1. > >So INT_MIN mod -1 is 0. > > >One can code that to be the case. Some versions of the code do. >=A0 I'm not sure about the current code=2C as we don't call the C functions= > any longer=2C except for int64 on NT386. >=A0 The older div/mod helpers=2C depending on optimization=2C would either = >return 0 >=A0=A0 or generate an overflow exception. > > >In our computer world=2C INT_MIN div -1 is not computable=2C and generates >=A0 the same exception. Even with current code. > > >If div and mod are defined in terms of each other=2C and one of them is not= > computable=2C >=A0 is it wrong to be able to compute the other? > > >=A0- Jay > > = From mika at async.async.caltech.edu Mon Jul 19 11:04:59 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Mon, 19 Jul 2010 02:04:59 -0700 Subject: [M3devel] moving to new target names, in Hudson? In-Reply-To: <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com> References: <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com> Message-ID: <20100719090459.4CE191A2084@async.async.caltech.edu> Can I also add that changing the target names is going to require work---perhaps quite a bit of work---among users of CM3... now they will no longer match PM3, or a version of CM3 older than a particular, arbitrary date. All sorts of configuration and setup scripts will have to be fixed. I would hope this sort of thing would be done for a new version number or something else that is easily testable... I suppose you can grep through the output of cm3 -version. But m3build doesn't print the target, so the scripts really do become quite a bit more complicated.... Mika Olaf Wagner writes: >Quoting Jay K : > >> Olaf, can I request that if/when you move Hudson to head, that you =20 >> also switch to I386_LINUX, I386_FREEBSD, I386_NT, >> and whatever we decide for SPARC32_SOLARIS? >> I've mostly switched to them myself. It wasn't difficult. (I always =20 >> say that). > >It will require a lot of manual work, compared to the more or less >automated transition I just made from release to current for all the >jobs. The target platform names are part of the jobs, and are also used >in various places in the build scripts, so that many things are likely >to break. > >My guess is that it will take some days for every target move given my >current attention pattern for cm3, i.e. have a look at how things work >out now and then between other work. > >Let's wait until all the jobs work again with their old target names, > >Olaf > >> I think for SPARC32_SOLARIS we should either have SPARC32_SOLARIS =20 >> that is the equivalent of today's SOLsun. >> Effectively dropping SOLgnu. >> >> >> Or we also add SPARC32_SOLARIS_gcc, which is just a configuration =20 >> file and not a target. >> This is like the "experiment" I did with NT386/NT386GNU, which I =20 >> think I regret, except >> SPARC32_SOLARIS / SPARC32_SOLAROS_gcc are far far more similar than those. >> All their platform-specific code is identical. Their backend is =20 >> identical. etc. >> >> >> A related option is SPARC32_SOLARIS_cc or SPARC32_SOLARIS_suncc, and =20 >> SPARC32_SOLARIS_gcc. >> Config files. >> But the compiler only know about SPARC32_SOLARIS. >> Just putting the two config files more as peers, so to speak. >> >> >> The way I switched targets was probably doing a cross build. >> That is overkill. You can probably just export CM3_TARGET to the =20 >> name you want. >> And maybe fiddle with shipping of cm3cg or settings its build_dir -- =20 >> i.e. leave it as just host and host-target. >--=20 >Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb=C3=A4ude 12, 13355 Berlin, Germa= >ny >phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch=C3=A4ftsf=C3=BChrer: Olaf Wagner | Sitz= >: Berlin >Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Jul 19 12:48:38 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Jul 2010 10:48:38 +0000 Subject: [M3devel] moving to new target names, in Hudson? In-Reply-To: <20100719090459.4CE191A2084@async.async.caltech.edu> References: , <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com>, <20100719090459.4CE191A2084@async.async.caltech.edu> Message-ID: The old target names are still available. I agree something like cm3 -version should be more useful. Notice: ? gcc -dumpmachine ? gcc -dumpspecs ? gcc -dumpversion ? gcc -print-search-dirs *However* notice that cm3 is *not* preconfigured/predisposed for any particular target. It has a list of targets and it can handle any of them. The config file decides the target. ?In fact, neither cm3 nor the config files are particularly knowledable about targets. ? The config files vary a little in how they run the compiler or linker. ? cm3 varies mainly in word size, endianness, and jmpbuf size. ? All the real work of knowing about targets is buried in gcc. ? And a smattering of #ifdefs in C code. Some of which could be pushed to autoconf. The old names confuse people -- you, for example. They are inconsistent. They don't specify processor architecture. What pain did you all go through when FreeBSD changed to FreeBSD2 changed to FreeBSD3 changed to FreeBSD4? Or LINUX to LINUXELF to LINUXLIBC6? So long ago nobody remembers? I used LINUXELF a little, built it, went away, came back and there was LINUXLIBC6. I had no code. It didn't matter to me. ?- Jay ---------------------------------------- > To: wagner at elegosoft.com > Date: Mon, 19 Jul 2010 02:04:59 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] moving to new target names, in Hudson? > > > Can I also add that changing the target names is going to require > work---perhaps quite a bit of work---among users of CM3... now they will > no longer match PM3, or a version of CM3 older than a particular, arbitrary > date. All sorts of configuration and setup scripts will have to be fixed. > I would hope this sort of thing would be done for a new version number > or something else that is easily testable... I suppose you can grep through > the output of cm3 -version. But m3build doesn't print the target, so the > scripts really do become quite a bit more complicated.... > > Mika > > Olaf Wagner writes: > >Quoting Jay K : > > > >> Olaf, can I request that if/when you move Hudson to head, that you =20 > >> also switch to I386_LINUX, I386_FREEBSD, I386_NT, > >> and whatever we decide for SPARC32_SOLARIS? > >> I've mostly switched to them myself. It wasn't difficult. (I always =20 > >> say that). > > > >It will require a lot of manual work, compared to the more or less > >automated transition I just made from release to current for all the > >jobs. The target platform names are part of the jobs, and are also used > >in various places in the build scripts, so that many things are likely > >to break. > > > >My guess is that it will take some days for every target move given my > >current attention pattern for cm3, i.e. have a look at how things work > >out now and then between other work. > > > >Let's wait until all the jobs work again with their old target names, > > > >Olaf > > > >> I think for SPARC32_SOLARIS we should either have SPARC32_SOLARIS =20 > >> that is the equivalent of today's SOLsun. > >> Effectively dropping SOLgnu. > >> > >> > >> Or we also add SPARC32_SOLARIS_gcc, which is just a configuration =20 > >> file and not a target. > >> This is like the "experiment" I did with NT386/NT386GNU, which I =20 > >> think I regret, except > >> SPARC32_SOLARIS / SPARC32_SOLAROS_gcc are far far more similar than those. > >> All their platform-specific code is identical. Their backend is =20 > >> identical. etc. > >> > >> > >> A related option is SPARC32_SOLARIS_cc or SPARC32_SOLARIS_suncc, and =20 > >> SPARC32_SOLARIS_gcc. > >> Config files. > >> But the compiler only know about SPARC32_SOLARIS. > >> Just putting the two config files more as peers, so to speak. > >> > >> > >> The way I switched targets was probably doing a cross build. > >> That is overkill. You can probably just export CM3_TARGET to the =20 > >> name you want. > >> And maybe fiddle with shipping of cm3cg or settings its build_dir -- =20 > >> i.e. leave it as just host and host-target. > >--=20 > >Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb=C3=A4ude 12, 13355 Berlin, Germa= > >ny > >phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > http://www.elegosoft.com | Gesch=C3=A4ftsf=C3=BChrer: Olaf Wagner | Sitz= > >: Berlin > >Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Jul 19 12:50:37 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Jul 2010 10:50:37 +0000 Subject: [M3devel] clean in m3cc In-Reply-To: <20100719101715.r4k0ubcc0oo80oso@mail.elegosoft.com> References: , , <20100719101715.r4k0ubcc0oo80oso@mail.elegosoft.com> Message-ID: I put in another mechanism. If someone makes a change such that they want m3cc to build clean, edit m3-sys/m3cc/src/clean-marker.txt arbitrarily. I'm not sure though, the stuff at the top of m3cc/src/m3makefile might need to be adjusted to honor it. I probably should do even better -- the configure command line should be saved and if it changes, go clean. I didn't do that yet. ?- Jay ---------------------------------------- > Date: Mon, 19 Jul 2010 10:17:15 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] clean in m3cc > > I've added a Hudson build variable CLEAN to all cm3-current-m3cc-* jobs. > > Olaf > > Quoting Jay K : > > > nevermind > > > > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: m3devel at elegosoft.com > >> Date: Mon, 19 Jul 2010 06:10:58 +0000 > >> Subject: [M3devel] clean in m3cc > >> > >> > >> Too dangerous: > >> > >> m3cc/src/m3makefile > >> > >> if stale(build_dir & "/clean_marker.txt", > >> "../src/clean_marker.txt") or defined ("FORCE") > >> m3cc_Run(["rm -rf " & build_dir & "/*"]) > >> cp_if("../src/clean_marker.txt", build_dir & "/clean_marker.txt") > >> end > >> > >> ? > >> > >> If build_dir has a space..? > >> > >> > >> - 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 mika at async.async.caltech.edu Mon Jul 19 13:02:07 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Mon, 19 Jul 2010 04:02:07 -0700 Subject: [M3devel] moving to new target names, in Hudson? In-Reply-To: References: , <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com>, <20100719090459.4CE191A2084@async.async.caltech.edu> Message-ID: <20100719110208.011521A2091@async.async.caltech.edu> Jay K writes: > >The old target names are still available. > > ... > >*However* notice that cm3 is *not* preconfigured/predisposed for any partic= >ular target. cm3 -version prints a target... > > >It has a list of targets and it can handle any of them. The config file dec= >ides the target. >=A0In fact=2C neither cm3 nor the config files are particularly knowledable= > about targets. >=A0 The config files vary a little in how they run the compiler or linker. >=A0 cm3 varies mainly in word size=2C endianness=2C and jmpbuf size. >=A0 All the real work of knowing about targets is buried in gcc. >=A0 And a smattering of #ifdefs in C code. Some of which could be pushed to= > autoconf. > > >The old names confuse people -- you=2C for example. >They are inconsistent. >They don't specify processor architecture. > Well I agree with that much.. > >What pain did you all go through when FreeBSD changed to FreeBSD2 changed t= >o FreeBSD3 changed to FreeBSD4? >Or LINUX to LINUXELF to LINUXLIBC6? >So long ago nobody remembers? >I used LINUXELF a little=2C built it=2C went away=2C came back and there wa= >s LINUXLIBC6. I had no code. It didn't matter to me. > The point of these names, I thought, was that they were supposed to map to binary-incompatible systems. I remember having FreeBSD2 and FreeBSD3 at the same time. We had a cluster with machines with both OSes, which were not binary compatible. The point is so that you can run cm3/m3build for both in the same repository (even concurrently), and not have them interfere with each other. It's not a pain to have different names if they actually mean different things. If you just call everything I386_FREEBSD all hell will break loose in that situation... (just as when I by mistake run "FreeBSD4" (really FreeBSD6) CM3 in a directory where I have already compiled things with "FreeBSD4" (really FreeBSD4) PM3...) Or am I misunderstanding something here? I would have thought you really wanted to have a different name for each binary-incompatible system so you can build them all in the same place. Consistency in naming would be nice but I think it is secondary. Mika From jay.krell at cornell.edu Mon Jul 19 13:51:28 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Jul 2010 11:51:28 +0000 Subject: [M3devel] moving to new target names, in Hudson? In-Reply-To: <20100719110208.011521A2091@async.async.caltech.edu> References: , , <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com>, , <20100719090459.4CE191A2084@async.async.caltech.edu>, , <20100719110208.011521A2091@async.async.caltech.edu> Message-ID: Well, from the compiler (cm3, cm3cg) and libraries (m3core/*.m3, etc.) point of view, now, all I386_FREEBSD are the same. ?They are all little endian, 32bit word, have the same jmpbuf, and no stack walker. ?(Ok, there's a small difference in that older FreeBSD might not have decent enough pthreads. ? So we should really maybe have I386_FREEBSD_pthreads and I386_FREEBSD_userthreads. ??? But this still is overkill. They are still identical in cm3 and cm3cg. They vary only in m3core/*/m3makefile. ?? I think this is best done by making the "thread library" a variable that the user can edit in config file. ?? And maybe gets appended to BUILD_DIR. But TARGET is unchanged.) Any differences or binary compatibilities aren't present until m3core/*.c #includes varying headers. I think it makes more sense probably for people to start editing BUILD_DIR in their config files. ? I386_FREEBSD1 ? I386_FREEBSD2 ? I386_FREEBSD3 ? I386_FREEBSD4 ? I386_FREEBSD5 ? I386_FREEBSD6 ? I386_FREEBSD7 ? I386_FREEBSD8 ? I386_SOLARIS2.8 ? ? I386_SOLARIS2.9? ? I386_SOLARIS2.10 ? I386_SOLARIS2.11? Exposing this explosion in more than maybe one directory, I quite dislike. They could be config files that set BUILD_DIR, maybe THREAD_LIBRARY (which I just made up) and then include(I386_FREEBSD). I like to think they are "configurations", lightweight toplevel things, many of them, that quickly devolve into a small number of "targets". Maybe what we should really, like, is run config.guess and use its entire output: i386-unknown-freebsd4.11 Unknown is unsightly.. Specifically for BUILD_DIR. TARGET would be somehow computed from that? BUILD_DIR is arbitrary. See how profiling appends "p" to it? Not that I ever use that. Perhaps not that anyone ever has TARGET != BUILD_DIR. ? Though that is how Modula-3 works for Cygwin. I am slowly believing in the way of autoconf and the GNU build system. It must be observed. On one hand that exposes a combinatorial explosion of configurations. On the other, it avoids canonizing any particular combination as special. If cm3 were to discover jmpbuf size in some sort of autoconf-ish thing, and record that merely in the config file, we'd be left with basically only four architectures in cm3: little endian32, little endian64, big endian32, big endian64. Heck, it doesn't even need to be autoconfish. It just needs to be in the config files. And a very small number of other things: the name of setjmp (_setjmp or setjmp), if there is a stack walker (usually false but sometimes true). ?- Jay ---------------------------------------- > To: jay.krell at cornell.edu > Date: Mon, 19 Jul 2010 04:02:07 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] moving to new target names, in Hudson? > > Jay K writes: > > > >The old target names are still available. > > > > > ... > > > >*However* notice that cm3 is *not* preconfigured/predisposed for any partic= > >ular target. > > cm3 -version prints a target... > > > > > > >It has a list of targets and it can handle any of them. The config file dec= > >ides the target. > >=A0In fact=2C neither cm3 nor the config files are particularly knowledable= > > about targets. > >=A0 The config files vary a little in how they run the compiler or linker. > >=A0 cm3 varies mainly in word size=2C endianness=2C and jmpbuf size. > >=A0 All the real work of knowing about targets is buried in gcc. > >=A0 And a smattering of #ifdefs in C code. Some of which could be pushed to= > > autoconf. > > > > > >The old names confuse people -- you=2C for example. > >They are inconsistent. > >They don't specify processor architecture. > > > > Well I agree with that much.. > > > > >What pain did you all go through when FreeBSD changed to FreeBSD2 changed t= > >o FreeBSD3 changed to FreeBSD4? > >Or LINUX to LINUXELF to LINUXLIBC6? > >So long ago nobody remembers? > >I used LINUXELF a little=2C built it=2C went away=2C came back and there wa= > >s LINUXLIBC6. I had no code. It didn't matter to me. > > > > The point of these names, I thought, was that they were supposed to map > to binary-incompatible systems. I remember having FreeBSD2 and FreeBSD3 > at the same time. We had a cluster with machines with both OSes, which > were not binary compatible. The point is so that you can run cm3/m3build > for both in the same repository (even concurrently), and not have them > interfere with each other. It's not a pain to have different names > if they actually mean different things. If you just call everything > I386_FREEBSD all hell will break loose in that situation... (just as when > I by mistake run "FreeBSD4" (really FreeBSD6) CM3 in a directory where > I have already compiled things with "FreeBSD4" (really FreeBSD4) PM3...) > > Or am I misunderstanding something here? I would have thought you really > wanted to have a different name for each binary-incompatible system so > you can build them all in the same place. Consistency in naming would be > nice but I think it is secondary. > > Mika From wagner at elegosoft.com Mon Jul 19 14:38:44 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 19 Jul 2010 14:38:44 +0200 Subject: [M3devel] moving to new target names, in Hudson? In-Reply-To: <20100719110208.011521A2091@async.async.caltech.edu> References: , <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com>, <20100719090459.4CE191A2084@async.async.caltech.edu> <20100719110208.011521A2091@async.async.caltech.edu> Message-ID: <20100719143844.03al7scsg0g400so@mail.elegosoft.com> Quoting Mika Nystrom : [...] > The point of these names, I thought, was that they were supposed to map > to binary-incompatible systems. I remember having FreeBSD2 and FreeBSD3 > at the same time. We had a cluster with machines with both OSes, which > were not binary compatible. The point is so that you can run cm3/m3build > for both in the same repository (even concurrently), and not have them > interfere with each other. It's not a pain to have different names > if they actually mean different things. If you just call everything > I386_FREEBSD all hell will break loose in that situation... (just as when > I by mistake run "FreeBSD4" (really FreeBSD6) CM3 in a directory where > I have already compiled things with "FreeBSD4" (really FreeBSD4) PM3...) > > Or am I misunderstanding something here? I would have thought you really > wanted to have a different name for each binary-incompatible system so > you can build them all in the same place. Consistency in naming would be > nice but I think it is secondary. In theory, yes, but it hasn't always worked out in practice. Binary compatibility works at least in two directions: (a) Allow applications compiled on an older system with older tools and libraries to be run on a newer system. (b) Allow applications compiled on a newer system to run on all or certain selected older system versions. Usually (a) is provided by Open Source systems like Linux, FreeBSD etc., at least within a major release line, sometimes also crossing boundaries (remember the switch from aout to elf format in FreeBSD). (b) is often partially provided by commercial systems like Windows, though in practice this doesn't always work as expected, too. It would be nice if we really could follow all binary compatibility changes in all supported operating system targets with a new unique name, but I'm afraid we haven't been able to do that in the past nor will we succeed to do that in the future. You have experienced one failure as you tried the FreeBSD4 packages built on FreeBSD 6.4 on an actual FreeBSD 4.11 system. We may get better if we distinguish between different uses of the target platform name though: (1) TARGET as a choice for compilation variants that cm3 distinguishes internally (2) TARGET as a name for the directories containing derived files (which is already configurable in quake config files). For example, the profiling setups I made some years ago added a `p' to the TARGET name. (3) TARGET as an indicator for installation or other binary packages on which system these binaries may run (3) should include as many information as possible, though it is not clear to me where to stop here. Do we actually want the X version or the GUI support libraries to be included there? What if different loadable formats are supported, as under Darwin (PPC, I386, combined) or Windows (com, exe (coff))? I would tend to start with something like the output of uname -rsm here: o FreeBSD 8.0-STABLE amd64 o Linux 2.6.26-2-amd64 x86_64 o FreeBSD 6.4-RELEASE-p5 i386 o Darwin 9.8.0 i386 o Darwin 8.11.0 Power Macintosh We could also add a more or less unspecified variant part there, for example, if we need to distinguish between aout/coff/elf format. (1) should be the list of distinctions we need to make to support different target platforms. The current compromise seems to be that this is a combination of processor/machine architecture (like I386, AMD64) and operating system name (not version). Then (2) could be an installation-specific choice: either just use the more generic name from (1), or a combination of (1) and (3), or some arbitrary name. It's not completely thought through yet, so suggestions on what exactly would be required or great are welcome. I've already added the information of (3) to the CM3 5.8.6 download pages; the next release should include it in the actual package names. (1) should be consistently standardized if possible (i.e. FreeBSD1/2/3/4 --> I386_FREEBSD etc.). Many actual configuration options may be determined by auto-configuration then. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Jul 19 15:32:22 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Jul 2010 13:32:22 +0000 Subject: [M3devel] moving to new target names, in Hudson? In-Reply-To: <20100719143844.03al7scsg0g400so@mail.elegosoft.com> References: , , <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com>, , <20100719090459.4CE191A2084@async.async.caltech.edu>, , <20100719110208.011521A2091@async.async.caltech.edu>, <20100719143844.03al7scsg0g400so@mail.elegosoft.com> Message-ID: Clearly this stuff is hard to describe. I think both Olaf and I sound like we're rambling. Esp. me. :) Olaf clearly gets my point of view though. :) > (b) is often partially provided by commercial systems like Windows, though > in practice this doesn't always work as expected, too. Yes it does! That's tangential though. ?> What if different loadable > formats are supported, as under Darwin (PPC, I386, combined) Let's table the "universal binaries" subject for now. I think it is slightly interesting, but nobody has asked for it, and it is fairly unique to Darwin. ?It can be done either by building everything twice, or by combing files after the fact. ? Nice thing about combining after the fact is basically nothing changes. > or Windows (com, exe (coff))? No, really, no. But I'll explain since you brought it up. There are two or so formats of MS-DOS file. A .com file is just under 64K of bytes loaded anywhere, all addresses are relative and <= 64K. That is, there is no file format. It just must be small. This is for 16bit code only. We don't support 16bit MS-DOS. There is MS-DOS .exe files which can be large and are relocatable. Again, this is a 16bit thing. In more general reality, people write their own loaders for MS-DOS. There's a DOS extender that loads Win32 files for example. Now, in Windows there is just one file format, PE, COFF, PE/COFF, whatever. All the same thing. The file *name* of such a file is arbitrary and varies. "more.com" is of the same file format as "findstr.exe". It just has that wierdo extension for compatibility. It is not a .com file like in MS-DOS. P in PE is "portable", as in all versions of NT: MIPS, PowerPC, 32bit Alpha, x86, use the same format. Later there was some revision, PE was renamed PE32, PE32+ was introduced. It is almost the same thing, but a few fields were widened to 64bits. Still, 64bit Alpha, IA64, AMD64 all use the same format. So there are only two formats: 32bit and 64bit. That's still nicely pretty "portable". So, short story, drop executable file format as a variable, at least on Windows. I understand some Unixes switched from a.out to ELF. That is/was relevant. LINUX => LINUXELF. But 32bit Windows never switched formats for files containing 32bit code. True, Win3.1 and OS/2 had various NE (new executable?), LE (linear executable?) but I don't think we care. Maybe at some point we'll have I386_OS2_NE, I386_OS2_LE but I don't know enough to say. More likely we'd have I386_WIN31, with one file format, I386_OS2 with one file format. > I would tend to start with something like the > output of uname -rsm here: > > o FreeBSD 8.0-STABLE amd64 > o Linux 2.6.26-2-amd64 x86_64 > o FreeBSD 6.4-RELEASE-p5 i386 > o Darwin 9.8.0 i386 > o Darwin 8.11.0 Power Macintosh I mostly agree, but I think it is maybe a little two much information in some cases. Should just be e.g. FreeBSD 8.0 amd64. FreeBSD 6.4 i386 -- does RELEASE p5 really help? I think you should look at the output (not the code) of the GNU config.guess file. I think it is mostly the way to go. It has those dumb "unknown" and "pc" things, and the "vendor" (apple, sun, dec) is generally meaningless. But the first and third/fourth parts are good. It is similar to your uname -srm. There are things beyond uname, like "sizer" on Alpha/OSF. config.guess finds the "g" in 4.0g, but uname doesn't. I'll admit another evidence of the problem. PPC64_DARWIN ?I think the last release added a bunch. ?So PPC64_DARWIN < 10.5 wouldn't have any Trestle/X stuff. ?But PPC64_DARWIN10.5 would. >From an implementation/compiler/library point of view, this can be implemented by having the config/m3makefiles probe at config/install/runtime. I've been putting probes in at runtime. Stuff that possibly belongs in config or install. Now, there is this this thorny issue you mention. We build binaries for redistribution. This does in a sense resemble a cross build. Building on machine X to run on machine Y, which may be more or less the same. If you consider something like Debian where they produce tons of binary packages, or even FreeBSD/NetBSD/OpenBSD, they have a luxury. They aren't really doing cross builds. They know the packages will be installed on the same OS release. They rebuild all the packages for each release. And Ubuntu vs. Debian are different builds. What do we do? Perhaps we sort of go back to the old model where customers do their own build? Or partly their own build? I think this is a definite possibility. And we use autoconf a bit in there? I think definitely maybe. The "boot" packages I build are a possible start. Though they need to come with matching Modula-3 source tree, including m3cc. ? => Just like the 3.6 DEC SRC release. Should we work towards that? Does it stink too much to make people build it? It has upside and downside. Upside is we get largely out of this configuration problem. Downside is they have to be much more patient before using the system. Perhaps we provide similar to what we already have, but with "overspecified configuration" names. If we have an exact match for you, great. If not, you build it yourself? I don't know about these Linux kernel version numbers. I hope/think Linux might have good compatibility? Our usage is fairly light. This is partly why i was interested in Modula-3 threads over Linux, instead of over glibc. So we could avoid the ARMEL_LINUX_glibc vs ARMEL_LINUX_uclibc vs. ARMEL_LINUX_bionic (Android) question. I'm rambling terribly, I realize. Sorry. In conclusion...I think we probably do something like uname -srm or config.guess, distribute "boot" + m3src.tar.gz + m3cc.tar.gz like DEC SRC did, we provide some binaries. User can rename build_dir to whatever he/she wants, but we'd start with something like config.guess? ?? Things like word size, endian, jmpbuf size, setjmp name, move to config file? ? Try to configure these things with autoconf? Make my "boot" packages use autoconf? e.g. to compile the C? ? To find libraries and build the config file and fill out SYSTEM_LIBS? i.e. to replace cminstall? Remove all target knowledge from Target.m3? ???? It's a bunch of work, makes these confusing (as autoconf does), but it does solve some problems I don't know. ?- Jay ---------------------------------------- > Date: Mon, 19 Jul 2010 14:38:44 +0200 > From: wagner at elegosoft.com > To: mika at async.async.caltech.edu > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > Subject: Re: [M3devel] moving to new target names, in Hudson? > > Quoting Mika Nystrom : > [...] > > The point of these names, I thought, was that they were supposed to map > > to binary-incompatible systems. I remember having FreeBSD2 and FreeBSD3 > > at the same time. We had a cluster with machines with both OSes, which > > were not binary compatible. The point is so that you can run cm3/m3build > > for both in the same repository (even concurrently), and not have them > > interfere with each other. It's not a pain to have different names > > if they actually mean different things. If you just call everything > > I386_FREEBSD all hell will break loose in that situation... (just as when > > I by mistake run "FreeBSD4" (really FreeBSD6) CM3 in a directory where > > I have already compiled things with "FreeBSD4" (really FreeBSD4) PM3...) > > > > Or am I misunderstanding something here? I would have thought you really > > wanted to have a different name for each binary-incompatible system so > > you can build them all in the same place. Consistency in naming would be > > nice but I think it is secondary. > > In theory, yes, but it hasn't always worked out in practice. > Binary compatibility works at least in two directions: > > (a) Allow applications compiled on an older system with older tools > and libraries to be run on a newer system. > > (b) Allow applications compiled on a newer system to run on all or > certain selected older system versions. > > Usually (a) is provided by Open Source systems like Linux, FreeBSD etc., > at least within a major release line, sometimes also crossing boundaries > (remember the switch from aout to elf format in FreeBSD). > > (b) is often partially provided by commercial systems like Windows, though > in practice this doesn't always work as expected, too. > > It would be nice if we really could follow all binary compatibility > changes in all supported operating system targets with a new unique > name, but I'm afraid we haven't been able to do that in the past nor > will we succeed to do that in the future. > > You have experienced one failure as you tried the FreeBSD4 packages > built on FreeBSD 6.4 on an actual FreeBSD 4.11 system. > > We may get better if we distinguish between different uses of the target > platform name though: > > (1) TARGET as a choice for compilation variants that cm3 distinguishes > internally > > (2) TARGET as a name for the directories containing derived files (which is > already configurable in quake config files). For example, the profiling > setups I made some years ago added a `p' to the TARGET name. > > (3) TARGET as an indicator for installation or other binary packages > on which system these binaries may run > > (3) should include as many information as possible, though it is not > clear to me where to stop here. Do we actually want the X version or > the GUI support libraries to be included there? What if different loadable > formats are supported, as under Darwin (PPC, I386, combined) or Windows > (com, exe (coff))? I would tend to start with something like the > output of uname -rsm here: > > o FreeBSD 8.0-STABLE amd64 > o Linux 2.6.26-2-amd64 x86_64 > o FreeBSD 6.4-RELEASE-p5 i386 > o Darwin 9.8.0 i386 > o Darwin 8.11.0 Power Macintosh > > We could also add a more or less unspecified variant part there, for > example, if we need to distinguish between aout/coff/elf format. > > (1) should be the list of distinctions we need to make to support > different target platforms. The current compromise seems to be that > this is a combination of processor/machine architecture (like I386, AMD64) > and operating system name (not version). > > Then (2) could be an installation-specific choice: either just use > the more generic name from (1), or a combination of (1) and (3), or > some arbitrary name. It's not completely thought through yet, so suggestions > on what exactly would be required or great are welcome. > > I've already added the information of (3) to the CM3 5.8.6 download > pages; the next release should include it in the actual package names. > > (1) should be consistently standardized if possible (i.e. FreeBSD1/2/3/4 > --> I386_FREEBSD etc.). Many actual configuration options may be > determined by auto-configuration then. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From wagner at elegosoft.com Mon Jul 19 16:28:35 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 19 Jul 2010 16:28:35 +0200 Subject: [M3devel] moving to new target names, in Hudson? In-Reply-To: References: , , <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com>, , <20100719090459.4CE191A2084@async.async.caltech.edu>, , <20100719110208.011521A2091@async.async.caltech.edu>, <20100719143844.03al7scsg0g400so@mail.elegosoft.com> Message-ID: <20100719162835.j0mnd9q3fo4s0g4g@mail.elegosoft.com> Hi Jay, I've learned several new things about Windows again; but in general, I don't think we disagree very much about the options and things to do. I agree that config.guess might be a good short-time option for the installation package names. I also agree that we could provide assembled packages for everything like PM3 did and rely on auto-configuration for everything else. This might be some more work for Windows though, as it uses a different backend than all other platforms. We'd need to create completely different Makefiles and scripts for Windows than for Unix and Unix-like systems. Or rely on some other tooling as prerequisite (either perl, python, Cygwin, ... you name it). I wouldn't like that very much though. I'm not sure yet if that would be welcome by all users and be seen as a step forward. I wouldn't mind it though. If it is generally accepted as a good idea, we should build up the infrastructure for that kind of packages and installations in parallel to what we have now. It would definitely not be the native Windows-installer user experience then ;-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Jul 19 16:34:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Jul 2010 14:34:02 +0000 Subject: [M3devel] I386_OPENBSD hangs in stubgen Message-ID: I386_OPENBSD hangs in stubgen Problem seems to be in the "rewritten" user threads (ie: using the sigaltstack approach instead of poking at the jmpbuf) here: ??? sigemptyset(&sigs); ??? sigaddset(&sigs, SIGUSR1); ??? sigprocmask(SIG_BLOCK, &sigs, &osigs); ... ??? kill(getpid(), SIGUSR1); ??? sigfillset(&sigs); ??? sigdelset(&sigs, SIGUSR1); ??? while (!mctx_called) ??????? sigsuspend(&sigs); The kill seems to come in immdiately, even though sigusr1 is blocked. And then sigsuspend hangs waiting forever. I forgot to eheck if mctx_called has changed, or if the check is optimized out. It seems ok if the kill comes in right away actually. I thought I had tested all this already on OpenBSD/x86 but I guess maybe not. I thought maybe the -pthread vs. -lpthread did it, but it seems not. I'll poke around more. I might resort to putting back the jmpbuf hacking, which would be unfortunate. (OpenBSD doesn't implement get/set/make/swapcontext, at least as of previous release 4.6.) ?- Jay From mika at async.async.caltech.edu Mon Jul 19 16:47:22 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Mon, 19 Jul 2010 07:47:22 -0700 Subject: [M3devel] moving to new target names, in Hudson? In-Reply-To: References: , , <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com>, , <20100719090459.4CE191A2084@async.async.caltech.edu>, , <20100719110208.011521A2091@async.async.caltech.edu> Message-ID: <20100719144722.81DB41A208C@async.async.caltech.edu> Well Jay, from the user's point of view it really doesn't matter whether cm3 is one binary or many... BUILD_DIR has more to do with whether the binaries that it produces can run on one platform or many. But from what I gather from your email, the idea seems to be that you can have many targets in one compiler and the user of the compiler can set BUILD_DIR himself, as he pleases? That would be wonderful... Does it work to do that? Can I just change BUILD_DIR to, say, MIKAS_ENVIRONMENT_USING_CM3_5_8_6_WITH_THREADS_HACKS_ON_FREEBSD_4_11_I386 and have everything work for me? Mika Jay K writes: > >Well=2C from the compiler (cm3=2C cm3cg) and libraries (m3core/*.m3=2C etc.= >) point of view=2C now=2C all I386_FREEBSD are the same. >=A0They are all little endian=2C 32bit word=2C have the same jmpbuf=2C and = >no stack walker. >=A0(Ok=2C there's a small difference in that older FreeBSD might not have d= >ecent enough pthreads. >=A0 So we should really maybe have I386_FREEBSD_pthreads and I386_FREEBSD_u= >serthreads. >=A0=A0=A0 But this still is overkill. They are still identical in cm3 and c= >m3cg. They vary only in m3core/*/m3makefile. >=A0=A0 I think this is best done by making the "thread library" a variable = >that the user can edit in config file. >=A0=A0 And maybe gets appended to BUILD_DIR. But TARGET is unchanged.) > > >Any differences or binary compatibilities aren't present until m3core/*.c #= >includes varying headers. >I think it makes more sense probably for people to start editing BUILD_DIR = >in their config files. >=A0 I386_FREEBSD1=20 >=A0 I386_FREEBSD2=20 >=A0 >I386_FREEBSD3=20 >=A0 >I386_FREEBSD4=20 >=A0 >I386_FREEBSD5=20 >=A0 >I386_FREEBSD6=20 >=A0 >I386_FREEBSD7=20 >=A0 I386_FREEBSD8 >=A0 I386_SOLARIS2.8 =A0=20 > > > >=A0 I386_SOLARIS2.9=A0=20 > > >=A0 I386_SOLARIS2.10=20 > > > >=A0 I386_SOLARIS2.11=A0=20 > > > > >Exposing this explosion in more than maybe one directory=2C I quite dislike= >. >They could be config files that set BUILD_DIR=2C maybe THREAD_LIBRARY (whic= >h I just made up) and then include(I386_FREEBSD). >I like to think they are "configurations"=2C lightweight toplevel things=2C= > many of them=2C that quickly devolve into a small number of "targets". > > > >Maybe what we should really=2C like=2C is run config.guess and use its enti= >re output: i386-unknown-freebsd4.11 >Unknown is unsightly.. Specifically for BUILD_DIR. TARGET would be somehow = >computed from that? > > > > >BUILD_DIR is arbitrary. See how profiling appends "p" to it? Not that I eve= >r use that. >Perhaps not that anyone ever has TARGET !=3D BUILD_DIR. >=A0 Though that is how Modula-3 works for Cygwin. > > >I am slowly believing in the way of autoconf and the GNU build system. It m= >ust be observed. >On one hand that exposes a combinatorial explosion of configurations. >On the other=2C it avoids canonizing any particular combination as special.= >=20 > > >If cm3 were to discover jmpbuf size in some sort of autoconf-ish thing=2C a= >nd record that merely in the config file=2C >we'd be left with basically only four architectures in cm3: little endian32= >=2C little endian64=2C big endian32=2C big endian64. > > >Heck=2C it doesn't even need to be autoconfish. It just needs to be in the = >config files. >And a very small number of other things: the name of setjmp (_setjmp or set= >jmp)=2C if there is a stack walker (usually false but sometimes true). > > > >=A0- Jay > >---------------------------------------- >> To: jay.krell at cornell.edu >> Date: Mon=2C 19 Jul 2010 04:02:07 -0700 >> From: mika at async.async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] moving to new target names=2C in Hudson? >> >> Jay K writes: >> > >> >The old target names are still available. >> > >> > >> ... >> > >> >*However* notice that cm3 is *not* preconfigured/predisposed for any par= >tic=3D >> >ular target. >> >> cm3 -version prints a target... >> >> > >> > >> >It has a list of targets and it can handle any of them. The config file = >dec=3D >> >ides the target. >> >=3DA0In fact=3D2C neither cm3 nor the config files are particularly know= >ledable=3D >> > about targets. >> >=3DA0 The config files vary a little in how they run the compiler or lin= >ker. >> >=3DA0 cm3 varies mainly in word size=3D2C endianness=3D2C and jmpbuf siz= >e. >> >=3DA0 All the real work of knowing about targets is buried in gcc. >> >=3DA0 And a smattering of #ifdefs in C code. Some of which could be push= >ed to=3D >> > autoconf. >> > >> > >> >The old names confuse people -- you=3D2C for example. >> >They are inconsistent. >> >They don't specify processor architecture. >> > >> >> Well I agree with that much.. >> >> > >> >What pain did you all go through when FreeBSD changed to FreeBSD2 change= >d t=3D >> >o FreeBSD3 changed to FreeBSD4? >> >Or LINUX to LINUXELF to LINUXLIBC6? >> >So long ago nobody remembers? >> >I used LINUXELF a little=3D2C built it=3D2C went away=3D2C came back and= > there wa=3D >> >s LINUXLIBC6. I had no code. It didn't matter to me. >> > >> >> The point of these names=2C I thought=2C was that they were supposed to m= >ap >> to binary-incompatible systems. I remember having FreeBSD2 and FreeBSD3 >> at the same time. We had a cluster with machines with both OSes=2C which >> were not binary compatible. The point is so that you can run cm3/m3build >> for both in the same repository (even concurrently)=2C and not have them >> interfere with each other. It's not a pain to have different names >> if they actually mean different things. If you just call everything >> I386_FREEBSD all hell will break loose in that situation... (just as when >> I by mistake run "FreeBSD4" (really FreeBSD6) CM3 in a directory where >> I have already compiled things with "FreeBSD4" (really FreeBSD4) PM3...) >> >> Or am I misunderstanding something here? I would have thought you really >> wanted to have a different name for each binary-incompatible system so >> you can build them all in the same place. Consistency in naming would be >> nice but I think it is secondary. >> >> Mika > = From jay.krell at cornell.edu Mon Jul 19 16:56:15 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Jul 2010 14:56:15 +0000 Subject: [M3devel] moving to new target names, in Hudson? In-Reply-To: <20100719162835.j0mnd9q3fo4s0g4g@mail.elegosoft.com> References: , ,,<20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com>, , , <20100719090459.4CE191A2084@async.async.caltech.edu>, , , , <20100719110208.011521A2091@async.async.caltech.edu>, , <20100719143844.03al7scsg0g400so@mail.elegosoft.com>, , <20100719162835.j0mnd9q3fo4s0g4g@mail.elegosoft.com> Message-ID: I agree we agree, on the issues. ? I know I've been rambly though, so I'm not sure others understand. ? I had made these points earlier for Cygwin vs. native NT, but they were less valid there. ? The systems resembled each other less. I'm nervous about my own suggestion though. Don't worry about Windows here. It has excellent binary compatibility and the existing static configuration will work fine. There is a similar matter with the C runtime version, which is also tied to the compiler version. You see I already handled that in terms of archive names. I also got "boot" archives working for I386_NT. The Makefile works with Microsoft nmake and is very simple. The "boot" process produces .objs instead assembly source, which is fine and good -- because of the integrated backend. To be clear, on NT, I think having the user build the system is fine and good. But instead of config.guess, probably just use "I386_NT_VC70", "I386_NT_VC80", "I386_NT_VC90", "I386_NT_VC100" You can see in pylib.py I probe the compiler version trivially. I guess I'll rewrite that in .cmd or JScript embedded in .cmd. ?That will do fine. And like my proposal where we build a few Posix packages (maybe very few), we can build a few/very few .msis. And just to remind everyone, m3src.tar.gz is split from m3cc.tar.gz, so that I386_NT users don't have to download m3cc.tar.gz which they don't use. Also to point out the obvious once you think about it: ?We can use DEC SRC for "guidance" but we cannot actually just go back to how it worked. ? In particular, because quake was written in C back then. They distributed C source to it. ? Small different really, as I believe they still distributed assembly of m3build. Let's sit and think/talk about this longer before implementing something we decide we don't like. I did start playing with autconf finally..been a long time coming. Thing is..I don't think we need the full machinery of automake and even GNU make. Depending on..another matter.. If you look at the existing boot archives, they just build cm3, Makefile is pretty simple. autoconf will help, to find the C compiler, flags for -pthreads. I put some annotations in m3core.h of stuff autoconf can figure out. Question then: do we extend this and ship the entire system as assembly + C + makefiles? That is, make user build m3cc, but then just assemble? Or, only ship assembly for cm3? I don't see a big difference either way. Except that full system assembly + C dovetails nicely into things like iphone where you want to "finish" the build not on the target, but using the "native cross" toolset. ie: it is probably useful automation to have. Independent of if we distribute it. But this does remind me...another thing autoconf can do...not autoconf actually, but libtool can be of use. A bit of the config files is how to run the linker, shared vs. static. libtool is kind of gross and slow. But this is what it does. (Again, I just wouldn't do it for NT.) "and another thing" We can perhaps distribute patches to gcc instead of the full gcc tree. State what version they are against, give a URL. ? We'd keep our tree for development convenience though. "and another thing" Back in the existing scheme of things..I was considering a go at upgrading m3gdb.. I'm still nervous. Maybe we wait and see how much success/failure there is with the current release's binary distribution. Mika's FreeBSD 4 problems and Mark's problem with 5.1 binaries on 4.0g aren't really enough to warrant doing much. Except that we do understand the problem. "and another thing" To whatever extent systems are x86/amd64 and runnable in VMs, and to whatever extent they have good backward compatibility, and to whatever extent Java is available on older systems. just building on "oldest common denominator" might be good. (I just up the term. :) ) Probably this new stuff can be worked on and pondered..completely without upsetting the status quo. I think so. Good. I've had a big mental hurdle around autoconf/libtool for a long time but I'm finally starting to clear it.. I think they are part of the solution. This will address the $ORIGIN stuff also of course, largely. ?(We still might provide a few binaries; maybe only for systems with $ORIGIN.) ?- Jay ---------------------------------------- > Date: Mon, 19 Jul 2010 16:28:35 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] moving to new target names, in Hudson? > > Hi Jay, > > I've learned several new things about Windows again; but in general, > I don't think we disagree very much about the options and things to do. > > I agree that config.guess might be a good short-time option for the > installation package names. > > I also agree that we could provide assembled packages for everything > like PM3 did and rely on auto-configuration for everything else. > This might be some more work for Windows though, as it uses a different > backend than all other platforms. We'd need to create completely different > Makefiles and scripts for Windows than for Unix and Unix-like systems. > Or rely on some other tooling as prerequisite (either perl, python, > Cygwin, ... you name it). I wouldn't like that very much though. > > I'm not sure yet if that would be welcome by all users and be seen > as a step forward. I wouldn't mind it though. > If it is generally accepted as a good idea, we should build up the > infrastructure for that kind of packages and installations in parallel > to what we have now. > > It would definitely not be the native Windows-installer user experience > then ;-) > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Mon Jul 19 17:04:22 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Jul 2010 15:04:22 +0000 Subject: [M3devel] moving to new target names, in Hudson? In-Reply-To: <20100719144722.81DB41A208C@async.async.caltech.edu> References: , , <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com>, , <20100719090459.4CE191A2084@async.async.caltech.edu>, , <20100719110208.011521A2091@async.async.caltech.edu> , <20100719144722.81DB41A208C@async.async.caltech.edu> Message-ID: BUILD_DIR = "MIKAS_ENVIRONMENT_USING_CM3_5_8_6_WITH_THREADS_HACKS_ON_FREEBSD_4_11_I386" TARGET = "FreeBSD4" yes. I can't say I've ever done it, but it is supposed to work, and there is the profile precedent Olaf mentioned. Now, let's ask ourselves something important. Where does it ship to? Either it ships to BUILD_DIR, good, you get to rebuild everything (m3core, libm3, etc.) whenever you change BUILD_DIR. Or it ships to TARGET and my story is completely wrong. Unless we change it to BUILD_DOR. Let me see. We ship to build_dor. And I'm proposing...devil will in the details, actually doing it, seeing if it works out..if the config file sets word size (it already does, long ago), endian (I added recently), jmpbuf size... then TARGET might become even less meaningful. I think the alignments are all the same. The types are all the same, given word size. The floating point types are all the same, for now (I'm threatening to add VAX and 80bit x86 long double), but still that could be config file... then the compiler (cm3) is left knowing nothing of any predefined targets.. Currently TARGET must be from within a list the compiler knows about. BUILD_DIR is supposed to be arbitrary. The "ship no resolution" stuff has some dependency that build_dir == target, but that's ok. ?- Jay ---------------------------------------- > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] moving to new target names, in Hudson? > Date: Mon, 19 Jul 2010 07:47:22 -0700 > From: mika at async.async.caltech.edu > > > Well Jay, from the user's point of view it really doesn't matter whether > cm3 is one binary or many... BUILD_DIR has more to do with whether > the binaries that it produces can run on one platform or many. > > But from what I gather from your email, the idea seems to be that you > can have many targets in one compiler and the user of the compiler > can set BUILD_DIR himself, as he pleases? That would be wonderful... > Does it work to do that? Can I just change BUILD_DIR to, say, > > MIKAS_ENVIRONMENT_USING_CM3_5_8_6_WITH_THREADS_HACKS_ON_FREEBSD_4_11_I386 > > and have everything work for me? > > Mika > > Jay K writes: > > > >Well=2C from the compiler (cm3=2C cm3cg) and libraries (m3core/*.m3=2C etc.= > >) point of view=2C now=2C all I386_FREEBSD are the same. > >=A0They are all little endian=2C 32bit word=2C have the same jmpbuf=2C and = > >no stack walker. > >=A0(Ok=2C there's a small difference in that older FreeBSD might not have d= > >ecent enough pthreads. > >=A0 So we should really maybe have I386_FREEBSD_pthreads and I386_FREEBSD_u= > >serthreads. > >=A0=A0=A0 But this still is overkill. They are still identical in cm3 and c= > >m3cg. They vary only in m3core/*/m3makefile. > >=A0=A0 I think this is best done by making the "thread library" a variable = > >that the user can edit in config file. > >=A0=A0 And maybe gets appended to BUILD_DIR. But TARGET is unchanged.) > > > > > >Any differences or binary compatibilities aren't present until m3core/*.c #= > >includes varying headers. > >I think it makes more sense probably for people to start editing BUILD_DIR = > >in their config files. > >=A0 I386_FREEBSD1=20 > >=A0 I386_FREEBSD2=20 > >=A0 > >I386_FREEBSD3=20 > >=A0 > >I386_FREEBSD4=20 > >=A0 > >I386_FREEBSD5=20 > >=A0 > >I386_FREEBSD6=20 > >=A0 > >I386_FREEBSD7=20 > >=A0 I386_FREEBSD8 > >=A0 I386_SOLARIS2.8 =A0=20 > > > > > > > >=A0 I386_SOLARIS2.9=A0=20 > > > > > >=A0 I386_SOLARIS2.10=20 > > > > > > > >=A0 I386_SOLARIS2.11=A0=20 > > > > > > > > > >Exposing this explosion in more than maybe one directory=2C I quite dislike= > >. > >They could be config files that set BUILD_DIR=2C maybe THREAD_LIBRARY (whic= > >h I just made up) and then include(I386_FREEBSD). > >I like to think they are "configurations"=2C lightweight toplevel things=2C= > > many of them=2C that quickly devolve into a small number of "targets". > > > > > > > >Maybe what we should really=2C like=2C is run config.guess and use its enti= > >re output: i386-unknown-freebsd4.11 > >Unknown is unsightly.. Specifically for BUILD_DIR. TARGET would be somehow = > >computed from that? > > > > > > > > > >BUILD_DIR is arbitrary. See how profiling appends "p" to it? Not that I eve= > >r use that. > >Perhaps not that anyone ever has TARGET !=3D BUILD_DIR. > >=A0 Though that is how Modula-3 works for Cygwin. > > > > > >I am slowly believing in the way of autoconf and the GNU build system. It m= > >ust be observed. > >On one hand that exposes a combinatorial explosion of configurations. > >On the other=2C it avoids canonizing any particular combination as special.= > >=20 > > > > > >If cm3 were to discover jmpbuf size in some sort of autoconf-ish thing=2C a= > >nd record that merely in the config file=2C > >we'd be left with basically only four architectures in cm3: little endian32= > >=2C little endian64=2C big endian32=2C big endian64. > > > > > >Heck=2C it doesn't even need to be autoconfish. It just needs to be in the = > >config files. > >And a very small number of other things: the name of setjmp (_setjmp or set= > >jmp)=2C if there is a stack walker (usually false but sometimes true). > > > > > > > >=A0- Jay > > > >---------------------------------------- > >> To: jay.krell at cornell.edu > >> Date: Mon=2C 19 Jul 2010 04:02:07 -0700 > >> From: mika at async.async.caltech.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] moving to new target names=2C in Hudson? > >> > >> Jay K writes: > >> > > >> >The old target names are still available. > >> > > >> > > >> ... > >> > > >> >*However* notice that cm3 is *not* preconfigured/predisposed for any par= > >tic=3D > >> >ular target. > >> > >> cm3 -version prints a target... > >> > >> > > >> > > >> >It has a list of targets and it can handle any of them. The config file = > >dec=3D > >> >ides the target. > >> >=3DA0In fact=3D2C neither cm3 nor the config files are particularly know= > >ledable=3D > >> > about targets. > >> >=3DA0 The config files vary a little in how they run the compiler or lin= > >ker. > >> >=3DA0 cm3 varies mainly in word size=3D2C endianness=3D2C and jmpbuf siz= > >e. > >> >=3DA0 All the real work of knowing about targets is buried in gcc. > >> >=3DA0 And a smattering of #ifdefs in C code. Some of which could be push= > >ed to=3D > >> > autoconf. > >> > > >> > > >> >The old names confuse people -- you=3D2C for example. > >> >They are inconsistent. > >> >They don't specify processor architecture. > >> > > >> > >> Well I agree with that much.. > >> > >> > > >> >What pain did you all go through when FreeBSD changed to FreeBSD2 change= > >d t=3D > >> >o FreeBSD3 changed to FreeBSD4? > >> >Or LINUX to LINUXELF to LINUXLIBC6? > >> >So long ago nobody remembers? > >> >I used LINUXELF a little=3D2C built it=3D2C went away=3D2C came back and= > > there wa=3D > >> >s LINUXLIBC6. I had no code. It didn't matter to me. > >> > > >> > >> The point of these names=2C I thought=2C was that they were supposed to m= > >ap > >> to binary-incompatible systems. I remember having FreeBSD2 and FreeBSD3 > >> at the same time. We had a cluster with machines with both OSes=2C which > >> were not binary compatible. The point is so that you can run cm3/m3build > >> for both in the same repository (even concurrently)=2C and not have them > >> interfere with each other. It's not a pain to have different names > >> if they actually mean different things. If you just call everything > >> I386_FREEBSD all hell will break loose in that situation... (just as when > >> I by mistake run "FreeBSD4" (really FreeBSD6) CM3 in a directory where > >> I have already compiled things with "FreeBSD4" (really FreeBSD4) PM3...) > >> > >> Or am I misunderstanding something here? I would have thought you really > >> wanted to have a different name for each binary-incompatible system so > >> you can build them all in the same place. Consistency in naming would be > >> nice but I think it is secondary. > >> > >> Mika > > = From wagner at elegosoft.com Tue Jul 20 08:25:12 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 20 Jul 2010 08:25:12 +0200 Subject: [M3devel] NT386 builds fail on m3cc, was: Fwd: Re: elego-win-vm again Message-ID: <20100720082512.3ec0051v4ok8swo0@mail.elegosoft.com> It seems that current tries to build m3cc for NT386, which it shouldn't do and therefore fails. Why has this been changed? See http://hudson.modula3.com:8080/job/cm3-current-build-NT386/6/console for details. Please fix! Olaf ----- Forwarded message from michael.anderson at elego.de ----- Date: Mon, 19 Jul 2010 23:05:53 +0200 From: Michael Anderson Reply-To: Michael Anderson Subject: Re: elego-win-vm again To: Olaf Wagner Cc: manderson at elego.de, khaeusler at elego.de Quoting Olaf Wagner : > Can we somehow get that vm back online for some builds? > > http://hudson.modula3.com:8080/computer/elego-win-vm/log > Well, the vm is alive again, but the cm3-current-build-NT386 job is dying here: ... /home/elego/workspace/cm3-current-build-NT386/cm3/scripts/install-cm3-compiler.sh upgrade cp /home/elego/work/cm3-inst/wagner/current--release-build/bin/cm3.exe /home/elego/work/cm3-inst/wagner/current--release-build/bin/cm3-d5.8.2.exe cp_if: source does not exist: /home/elego/work/cm3-inst/wagner/current--release-build/bin/cm3cg Finished: FAILURE Where is cm3cg supposed to come from? > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 ----- End forwarded message ----- -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Tue Jul 20 08:51:03 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 20 Jul 2010 08:51:03 +0200 Subject: [M3devel] spin sources Message-ID: <1279608663.2648.3.camel@localhost> I tried to get them few moments ago, and download link is dead... Does anybody have them? -- Dragi?a Duri? From mark at wickensonline.co.uk Tue Jul 20 09:26:43 2010 From: mark at wickensonline.co.uk (Mark Wickens) Date: Tue, 20 Jul 2010 08:26:43 +0100 Subject: [M3devel] Just putting it out there... In-Reply-To: References: , , <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com> , , <20100719090459.4CE191A2084@async.async.caltech.edu> , , <20100719110208.011521A2091@async.async.caltech.edu> , <20100719143844.03al7scsg0g400so@mail.elegosoft.com> Message-ID: <1279610803.1935.1.camel@x60.appsoftint.co.uk> Hi guys, Has there been any discussion/moves about implementing Modula-3 as a language that runs on the Sun JVM? Seems a logical step given the similarities of Java to Modula-3 (I got that phrase the right way round, didn't I?) That is something I would definitely be able to provide help for. Regards, Mark. From mark at wickensonline.co.uk Tue Jul 20 09:33:09 2010 From: mark at wickensonline.co.uk (Mark Wickens) Date: Tue, 20 Jul 2010 08:33:09 +0100 Subject: [M3devel] Another thing Message-ID: <1279611189.1935.3.camel@x60.appsoftint.co.uk> Hi guys, I just subscribed to comp.os.modula3 and noticed the 5.8.6 release note - does the recent work on Digital Unix/tru64 platform mean that it will be promoted to an 'official' platform? Regards, Mark From jay.krell at cornell.edu Tue Jul 20 11:22:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 20 Jul 2010 09:22:39 +0000 Subject: [M3devel] Another thing In-Reply-To: <1279611189.1935.3.camel@x60.appsoftint.co.uk> References: <1279611189.1935.3.camel@x60.appsoftint.co.uk> Message-ID: Not for 5.8.6. It is already done and the changes for Mika and you are in "head". Maybe for the 5.9 release. I'm not sure the distinction matters. I don't think many people are using OSF1 any longer. You have a working system. Modulo the inefficient exception handling, like all other platforms (with one exception). Will you be using it much/long? Maybe you can try building it yourself, and then stay up to date with CVS and rebuild/test? Currently to do a "proper", "full", somewhat tested release requires recent Java 1.5 and sshd on a system. The distribution format might change or optionally change in 5.9 so we can provide a "full" albeit untested release for platforms we don't have automation on. - Jay > From: mark at wickensonline.co.uk > To: m3devel at elegosoft.com > Date: Tue, 20 Jul 2010 08:33:09 +0100 > Subject: [M3devel] Another thing > > Hi guys, > > I just subscribed to comp.os.modula3 and noticed the 5.8.6 release note > - does the recent work on Digital Unix/tru64 platform mean that it will > be promoted to an 'official' platform? > > Regards, Mark > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 20 12:31:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 20 Jul 2010 10:31:31 +0000 Subject: [M3devel] some current/hudson problems? Message-ID: 1) Is cm3-current-build-target supposed to build everything, ? or not much more than the compiler? I looked at a a few (I386_OPENBSD, FreeBSD4, LINUXLIBC6) and they aren't building much more than compiler. Or is that supposed to be deferred to test-all? I was wanting to check if I386_OPENBSD hung. ? Either way, I think I have the fix. ? ? 2) cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/INSTALL' cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/fixincludes' I believe this is an artifact of cvs not working well in general. In particular, switching branches, doesn't handle deletes, or something. 3) "/home/hudson/workspace/cm3-current-test-all-pkgs-SOLgnu/ cm3/m3-db/odbc/src/m3makefile", line 4: quake runtime error: undefined variable: configure_system_libs My fault. I'll fix. ?- Jay From jay.krell at cornell.edu Tue Jul 20 12:46:47 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 20 Jul 2010 10:46:47 +0000 Subject: [M3devel] NT386 builds fail on m3cc, was: Fwd: Re: elego-win-vm again In-Reply-To: <20100720082512.3ec0051v4ok8swo0@mail.elegosoft.com> References: <20100720082512.3ec0051v4ok8swo0@mail.elegosoft.com> Message-ID: Olaf, I see what you mean in Hudson/current. I haven't compared to Hudson/release. I haven't pieced much together here as to what is going on. I do see precious few uses of FilterPackages in release or head though. Surprising. ?- Jay ---------------------------------------- > Date: Tue, 20 Jul 2010 08:25:12 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] NT386 builds fail on m3cc, was: Fwd: Re: elego-win-vm again > > It seems that current tries to build m3cc for NT386, which it shouldn't > do and therefore fails. > > Why has this been changed? > > See http://hudson.modula3.com:8080/job/cm3-current-build-NT386/6/console > for details. > > Please fix! > > Olaf > > ----- Forwarded message from michael.anderson at elego.de ----- > Date: Mon, 19 Jul 2010 23:05:53 +0200 > From: Michael Anderson > Reply-To: Michael Anderson > Subject: Re: elego-win-vm again > To: Olaf Wagner > Cc: manderson at elego.de, khaeusler at elego.de > > Quoting Olaf Wagner : > > > Can we somehow get that vm back online for some builds? > > > > http://hudson.modula3.com:8080/computer/elego-win-vm/log > > > > > Well, the vm is alive again, but the cm3-current-build-NT386 job is > dying here: > > > ... > /home/elego/workspace/cm3-current-build-NT386/cm3/scripts/install-cm3-compiler.sh > upgrade > cp /home/elego/work/cm3-inst/wagner/current--release-build/bin/cm3.exe > /home/elego/work/cm3-inst/wagner/current--release-build/bin/cm3-d5.8.2.exe > cp_if: source does not exist: > /home/elego/work/cm3-inst/wagner/current--release-build/bin/cm3cg > Finished: FAILURE > > Where is cm3cg supposed to come from? > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > > > -- > Michael Anderson > IT Services & Support > > elego Software Solutions GmbH > Gustav-Meyer-Allee 25 > Building 12.3 (BIG) room 227 > 13355 Berlin, Germany > > phone +49 30 23 45 86 96 michael.anderson at elegosoft.com > fax +49 30 23 45 86 95 http://www.elegosoft.com > > Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin > Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 > > > > > ----- End forwarded message ----- > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Tue Jul 20 13:26:42 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 20 Jul 2010 11:26:42 +0000 Subject: [M3devel] NT386 builds fail on m3cc, was: Fwd: Re: elego-win-vm again In-Reply-To: References: <20100720082512.3ec0051v4ok8swo0@mail.elegosoft.com>, Message-ID: I had churned sysinfo.sh a lot in head. With some reason -- it was confusing when ? it was defaulting stuff vs. when it was deciding stuff that should affect defaulting. I made it first decide TARGET, then decide what follows from target. It should be clearer now. There was an obvious problem though. if xFOO = BAR instead of xFOO = xBAR or FOO=BAR. And an unclear part, given my ignorance of sh, if the spaces mean anything in a case. Both fixed. We'll see. FilterPackages isn't entirely relevant. UsePackage is similar, and used. ?(I looked at the release console output to get some hints.) Thanks for the heads up, ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Date: Tue, 20 Jul 2010 10:46:47 +0000 > Subject: Re: [M3devel] NT386 builds fail on m3cc, was: Fwd: Re: elego-win-vm again > > > Olaf, I see what you mean in Hudson/current. > I haven't compared to Hudson/release. > I haven't pieced much together here as to what is going on. > I do see precious few uses of FilterPackages in release or head though. Surprising. > > - Jay > > ---------------------------------------- > > Date: Tue, 20 Jul 2010 08:25:12 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: [M3devel] NT386 builds fail on m3cc, was: Fwd: Re: elego-win-vm again > > > > It seems that current tries to build m3cc for NT386, which it shouldn't > > do and therefore fails. > > > > Why has this been changed? > > > > See http://hudson.modula3.com:8080/job/cm3-current-build-NT386/6/console > > for details. > > > > Please fix! > > > > Olaf > > > > ----- Forwarded message from michael.anderson at elego.de ----- > > Date: Mon, 19 Jul 2010 23:05:53 +0200 > > From: Michael Anderson > > Reply-To: Michael Anderson > > Subject: Re: elego-win-vm again > > To: Olaf Wagner > > Cc: manderson at elego.de, khaeusler at elego.de > > > > Quoting Olaf Wagner : > > > > > Can we somehow get that vm back online for some builds? > > > > > > http://hudson.modula3.com:8080/computer/elego-win-vm/log > > > > > > > > > Well, the vm is alive again, but the cm3-current-build-NT386 job is > > dying here: > > > > > > ... > > /home/elego/workspace/cm3-current-build-NT386/cm3/scripts/install-cm3-compiler.sh > > upgrade > > cp /home/elego/work/cm3-inst/wagner/current--release-build/bin/cm3.exe > > /home/elego/work/cm3-inst/wagner/current--release-build/bin/cm3-d5.8.2.exe > > cp_if: source does not exist: > > /home/elego/work/cm3-inst/wagner/current--release-build/bin/cm3cg > > Finished: FAILURE > > > > Where is cm3cg supposed to come from? > > > > > Olaf > > > -- > > > Olaf Wagner -- elego Software Solutions GmbH > > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > > > > > > > -- > > Michael Anderson > > IT Services & Support > > > > elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 > > Building 12.3 (BIG) room 227 > > 13355 Berlin, Germany > > > > phone +49 30 23 45 86 96 michael.anderson at elegosoft.com > > fax +49 30 23 45 86 95 http://www.elegosoft.com > > > > Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin > > Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 > > > > > > > > > > ----- End forwarded message ----- > > > > > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > > From jay.krell at cornell.edu Tue Jul 20 14:28:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 20 Jul 2010 12:28:36 +0000 Subject: [M3devel] LongrealType missed, was: Re: "FreeBSD4" false advertising In-Reply-To: References: <20100714094120.93B001A2098@async.async.caltech.edu>, <20100714114648.nhnwruh008840wso@mail.elegosoft.com>, <20100714100138.631581A2098@async.async.caltech.edu>, <20100714100525.BEE931A2096@async.async.caltech.edu>, , <20100714104312.155351A2098@async.async.caltech.edu>, <20100714125516.1mzfehgnkgcs800w@mail.elegosoft.com>, Message-ID: Mika, did this work for you? ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > CC: mika at async.caltech.edu > Subject: RE: LongrealType missed, was: Re: [M3devel] "FreeBSD4" false advertising > Date: Wed, 14 Jul 2010 11:23:49 +0000 > > > Mika, Please try updating libm3 and see if that works for you. Thanks. > > - Jay > > ---------------------------------------- > > Date: Wed, 14 Jul 2010 12:55:16 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > CC: jay.krell at cornell.edu; mika at async.caltech.edu > > Subject: LongrealType missed, was: Re: [M3devel] "FreeBSD4" false advertising > > > > Quoting Mika Nystrom : > > > > > Argh is it really necessary to break source compatibility here? > > > > > > I also don't like that I as a client have to import IEEE things when all > > > I want is "LONGREAL" (and let Modula-3 do whatever it wants with that). > > > > > > I would propose at least having an interface LongrealType with > > > > > > CONST Hash = Longreal.Hash > > > > > > etc. so as not to force clients to import all the nitty-gritty about > > > various floating point representations. And so as not to break source > > > compatibility! If I change this by removing Type, my code will no longer > > > compile with the old compilers.... > > > > Hm, I'm a little bit out of context here... > > What was the reason for this change? It seems nobody else has bothered > > so far. > > > > This was the commit in question: > > > > 2009-12-23 21:43 hosking > > > > * m3-libs/: m3core/src/m3makefile, libm3/src/types/ASCII.i3, > > libm3/src/types/ASCII.m3, libm3/src/types/Boolean.i3, > > libm3/src/types/Boolean.m3, libm3/src/types/COPYRIGHT-CMASS, > > libm3/src/types/Char.i3, libm3/src/types/Char.m3, > > libm3/src/types/Int32.i3, libm3/src/types/Int32.m3, > > libm3/src/types/Int64.i3, libm3/src/types/Int64.m3, > > libm3/src/types/Integer.i3, libm3/src/types/Integer.m3, > > libm3/src/types/Longint.i3, libm3/src/types/Longint.m3, > > libm3/src/types/LongrealType.i3, libm3/src/types/LongrealType.m3, > > libm3/src/types/RealType.i3, libm3/src/types/RealType.m3, > > libm3/src/types/Refany.i3, libm3/src/types/Refany.m3, > > libm3/src/types/Unicode.i3, libm3/src/types/Unicode.m3, > > libm3/src/types/WideChar.i3, libm3/src/types/WideChar.m3, > > libm3/src/types/m3makefile, m3core/src/float/Common/Extended.m3, > > m3core/src/float/Common/LongReal.m3, m3core/src/float/Common/Real.m3, > > m3core/src/float/IEEE/Extended.i3, m3core/src/float/IEEE/LongReal.i3, > > m3core/src/float/IEEE/Real.i3, m3core/src/float/VAX/Extended.i3, > > m3core/src/float/VAX/LongReal.i3, m3core/src/float/VAX/Real.i3: > > > > Move libm3/src/types into m3core. > > Note that LongrealType and RealType have been folded into m3core/src/float. > > Clients will need adjustment. > > > > Any comments? > > > > Olaf > > > > > Mika > > > > > > Jay K writes: > > >> > > >> Remove "Type" it appears. > > >> > > >> > > >> http://modula3.elegosoft.com/cm3/ChangeLog-2009 > > >> > > >> search for "clients will need". > > >> > > >> e.g. > > >> > > >> +++ cm3/m3-demo/mentor/src/binpack/m3makefile 2009/12/23 22:05:06 1.2 > > >> @@ -10=2C7 +10=2C7 @@ > > >> =20 > > >> import ("zeus") > > >> =20 > > >> -list ("Real"=2C "RealType") > > >> +list ("Real"=2C "Real") > > >> =20 > > >> zume ("Binpack") > > >> oblume ("Binpack"=2C "myview") > > >> > > >> --- cm3/m3-demo/mentor/src/binpack/RealList.i3 2001/01/13 14:18:20 1.1 > > >> +++ cm3/m3-demo/mentor/src/binpack/RealList.i3 2009/12/23 22:05:05 1.2 > > >> @@ -2=2C4 +2=2C4 @@ > > >> (* Distributed only by permission. *) > > >> (* Last modified on Fri Jul 9 16:36:47 PDT 1993 by mhb *) > > >> =20 > > >> -INTERFACE RealList =3D List(RealType) END RealList. > > >> +INTERFACE RealList =3D List(Real) END RealList. > > >> > > >> --- cm3/m3-demo/mentor/src/binpack/RealList.m3 2001/01/13 14:18:20 1.1 > > >> +++ cm3/m3-demo/mentor/src/binpack/RealList.m3 2009/12/23 22:05:06 1.2 > > >> @@ -2=2C4 +2=2C4 @@ > > >> (* All rights reserved. *) > > >> (* See the file COPYRIGHT for a full description. *) > > >> =20 > > >> -MODULE RealList =3D List(RealType) END RealList. > > >> +MODULE RealList =3D List(Real) END RealList. > > >> > > >> =A0- Jay > > >> > > >> ---------------------------------------- > > >>> To: wagner at elegosoft.com > > >>> CC: jay.krell at cornell.edu=3B mika at async.caltech.edu > > >>> Subject: Re: [M3devel] "FreeBSD4" false advertising > > >>> Date: Wed=2C 14 Jul 2010 03:05:25 -0700 > > >>> From: mika at async.async.caltech.edu > > >>> > > >>> I'm not actually sure I understand the intent of the changes in this area= > > >> . > > >>> > > >>> My old m3makefile has: > > >>> > > >>> Table("TextLongReal"=2C "Text"=2C "LongrealType") > > >>> > > >>> What am I supposed to use now? > > >>> > > >>> Mika > > >>> > > >>> Mika Nystrom writes: > > >>> >Olaf Wagner writes: > > >>> >>Quoting Mika Nystrom : > > >>> >> > > >>> >>> Hi Jay=2C Olaf=2C > > >>> >>> > > >>> >>> I actually built everything! After backing out some of my changes > > >>> >>> that I had tried to get 5.8.6-REL to build with=2C it worked=2C and m= > > >> entor > > >>> >>> ran=2C even. > > >>> >> > > >>> >>Great! So it's still possible to build cm3 on FreeBSD 4=2C though > > >>> >>not our release code. > > >>> > > > >>> >The differences relative to the current CVS head are very minor. > > >>> > > > >>> >1. Added FreeBSD4 to thread.quake as a non-pthread platform > > >>> > > > >>> >2. got rid of the -m32 flags in FreeBSD4.conf > > >>> > > > >>> >Everything else that needed to change I think Jay has managed to put in > > >>> >the CVS head. > > >>> > > > >>> >> > > >>> >>> But... what happened to libm3/src/types? Building my own code I get > > >>> >>> the following errors: > > >>> >>> > > >>> >>> new source -> compiling LRInterval.i3 > > >>> >>> "../FreeBSD4/LRInterval.i3 =3D3D> ../src/Interval.ig"=2C line 5: unab= > > >> le to =3D20 > > >>> >>> find interface (LongrealType) > > >>> >>> 1 error encountered > > >>> >>> > > >>> >>> I can't find LongrealType anywhere=2C do I have a broken checkout? We= > > >> ll=2C it > > >>> >>> is in one place=2C in "doc". (Same for RealType=2C maybe others?) > > >>> >> > > >>> >>See =3D20 > > >>> >>http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/t= > > >> ypes/=3D > > >>> >>Attic/LongrealType.i3 > > >>> > > > >>> >Surely this is wrong?? I am looking for an interface that has T =3D > > >>> >LONGREAL=2C not something that lets me muck around with the representati= > > >> on > > >>> >of IEEE=2C VAX=2C etc.=2C floating-point formats. > > >>> > > > >>> >Why is it even in m3core? This seems clearly like libm3 stuff.. I notice= > > >> d > > >>> >Boolean.i3 also moved. > > >>> > > > >>> >Also if there is no importable interface called LongrealType that is goi= > > >> ng > > >>> >to cause endless problems with source that is supposed to compile under > > >>> >different versions of Modula-3. Even relatively recent CM3s required > > >>> >you to use LongrealType to instantiate generics. > > >>> > > > >>> > Mika > > >> = > > > > > > > > > > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 m3 at sol42.com Tue Jul 20 14:28:45 2010 From: m3 at sol42.com (m3 at sol42.com) Date: Tue, 20 Jul 2010 14:28:45 +0200 Subject: [M3devel] spin sources In-Reply-To: <1279608663.2648.3.camel@localhost> References: <1279608663.2648.3.camel@localhost> Message-ID: <27F80E57-716A-47ED-95DE-A73B51E580ED@sol42.com> Hello. I have spin-33.2.tar.gz from many many years ago. It is now available at http://www.sol42.com/spin-33.2.tar.gz Its size is 27.675.835 bytes compressed, 119.961.600 uncompressed. MD5 (spin-33.2.tar.gz) = 8fcd9457f1298eaef8819a21ab931712 GNU tar complains about zero data at the end of the archive, Solaris tar just stops there. Hopefully nothing is missing. Regards. -Daniel From wagner at elegosoft.com Tue Jul 20 14:48:14 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 20 Jul 2010 14:48:14 +0200 Subject: [M3devel] some current/hudson problems? In-Reply-To: References: Message-ID: <20100720144814.p091gtc6g0kggwwg@mail.elegosoft.com> Quoting Jay K : > 1) > Is cm3-current-build-target supposed to build everything, > ? or not much more than the compiler? > > I looked at a a few (I386_OPENBSD, FreeBSD4, LINUXLIBC6) and they > aren't building much more than compiler. Just the core system and perform an `upgrade' if needed. > Or is that supposed to be deferred to test-all? cm3-current-test-all-pkgs will build everything and perform all associated regression tests. If will also write reports in XML and HTML format. > I was wanting to check if I386_OPENBSD hung. > ? Either way, I think I have the fix. > ? > 2) > cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/INSTALL' > cvs update: use `cvs add' to create an entry for > `m3-sys/m3cc/gcc/fixincludes' > > I believe this is an artifact of cvs not working well in general. > In particular, switching branches, doesn't handle deletes, or something. Probably some confused workspace entries; should not be critical. > 3) > "/home/hudson/workspace/cm3-current-test-all-pkgs-SOLgnu/ > cm3/m3-db/odbc/src/m3makefile", line 4: quake runtime error: > undefined variable: > configure_system_libs > > My fault. I'll fix. Fine. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Jul 20 15:26:33 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 20 Jul 2010 09:26:33 -0400 Subject: [M3devel] Just putting it out there... In-Reply-To: <1279610803.1935.1.camel@x60.appsoftint.co.uk> References: , , <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com> , , <20100719090459.4CE191A2084@async.async.caltech.edu> , , <20100719110208.011521A2091@async.async.caltech.edu> , <20100719143844.03al7scsg0g400so@mail.elegosoft.com> <1279610803.1935.1.camel@x60.appsoftint.co.uk> Message-ID: Running Modula-3 on the Sun JVM poses several difficulties, not least that Modula-3 is a systems programming language like C/C++. Getting C, C++, or Modula-3 to run on the JVM would all be the same level of difficulty. The safe subset of Modula-3 would be less difficult, but the unsafe operations would probably be a showstopper. On the other hand, at one point there was a version of Java running in the Modula-3 run-time. On 20 Jul 2010, at 03:26, Mark Wickens wrote: > Hi guys, > > Has there been any discussion/moves about implementing Modula-3 as a > language that runs on the Sun JVM? > > Seems a logical step given the similarities of Java to Modula-3 (I got > that phrase the right way round, didn't I?) > > That is something I would definitely be able to provide help for. > > Regards, Mark. From mark at wickensonline.co.uk Tue Jul 20 15:36:50 2010 From: mark at wickensonline.co.uk (Mark Wickens) Date: Tue, 20 Jul 2010 14:36:50 +0100 Subject: [M3devel] Just putting it out there... In-Reply-To: References: , , <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com> , , <20100719090459.4CE191A2084@async.async.caltech.edu> , , <20100719110208.011521A2091@async.async.caltech.edu> , <20100719143844.03al7scsg0g400so@mail.elegosoft.com> <1279610803.1935.1.camel@x60.appsoftint.co.uk> Message-ID: <1279633010.1935.11.camel@x60.appsoftint.co.uk> Tony, Yes, after I'd written the email and thought about it I realised it was a pretty stupid idea. Mark. On Tue, 2010-07-20 at 09:26 -0400, Tony Hosking wrote: > Running Modula-3 on the Sun JVM poses several difficulties, not least that Modula-3 is a systems programming language like C/C++. Getting C, C++, or Modula-3 to run on the JVM would all be the same level of difficulty. The safe subset of Modula-3 would be less difficult, but the unsafe operations would probably be a showstopper. On the other hand, at one point there was a version of Java running in the Modula-3 run-time. > > On 20 Jul 2010, at 03:26, Mark Wickens wrote: > > > Hi guys, > > > > Has there been any discussion/moves about implementing Modula-3 as a > > language that runs on the Sun JVM? > > > > Seems a logical step given the similarities of Java to Modula-3 (I got > > that phrase the right way round, didn't I?) > > > > That is something I would definitely be able to provide help for. > > > > Regards, Mark. > From jay.krell at cornell.edu Tue Jul 20 15:39:46 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 20 Jul 2010 13:39:46 +0000 Subject: [M3devel] merging gdb from 6.4 to 7.1? Message-ID: The merge of m3cc/gcc from 4.3.0 to 4.3.5 went well enough. I'll volunteer to merge m3gdb from 6.4 to 7.1. Are people interested? I saw some mention of 6.4.3 in our history. But there's no release called that. What is it? Some of the conflicts are about? SYMBOL_TYP vs. LHS_SYMBOL_TYPE. What that a deliberate important change on our port? Thanks, ?- Jay From m3 at sol42.com Tue Jul 20 16:14:30 2010 From: m3 at sol42.com (m3 at sol42.com) Date: Tue, 20 Jul 2010 16:14:30 +0200 Subject: [M3devel] Just putting it out there... In-Reply-To: <1279633010.1935.11.camel@x60.appsoftint.co.uk> References: , , <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com> , , <20100719090459.4CE191A2084@async.async.caltech.edu> , , <20100719110208.011521A2091@async.async.caltech.edu> , <20100719143844.03al7scsg0g400so@mail.elegosoft.com> <1279610803.1935.1.camel@x60.appsoftint.co.uk> <1279633010.1935.11.camel@x60.appsoftint.co.uk> Message-ID: On 20 Jul 2010, at 15:36, Mark Wickens wrote: > Yes, after I'd written the email and thought about it I realised it was > a pretty stupid idea. Well, not stupid at all. Java may suck but the JVM certainly does not. There is a lot of interest now in compiling languages other than Java on the JVM, which has turned out to be a sort of universal runtime. Only that it was designed with Java in mind, and you would end up with something *like* Modula-3, not Modula-3 itself: what you can do in JVM "assembly" is limited, no PACKED types, no BITS x FOR y .. z, LOOPHOLE may or may not be always possible, UNTRACED would be problematic, pointer arithmetic in UNSAFE modules might require JNI and who knows what else, forget about <*EXTERNAL*> C calls, full interoperability with Java would require supporting Java interfaces (at the language level I think)... and these are just the few I can think of right now. On the other hand I would really like to code in this superset-of-a-subset of Modula-3 and run it on a JVM. Regarding the Critical Mass JVM described in Threads 3, are the sources available? Regards. -Daniel From dabenavidesd at yahoo.es Tue Jul 20 16:17:02 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 20 Jul 2010 14:17:02 +0000 (GMT) Subject: [M3devel] Just putting it out there... In-Reply-To: Message-ID: <562804.32217.qm@web23606.mail.ird.yahoo.com> Hi all: Its interesting that after all, being Modula-3 a systems programming language any of its unsafe features are still as it is written in Modula-3 itself no harm to the Modula-3 runtime itself you can isolate the unsafe features to allow pretty clean representation of the system. Java had from the beginning an unsafe feature (not sure what it looks today) for type checking unsound with respect to its static semantics a type rule of array of objects subtyping, but they cleaned the missing check in the JVM as a runtime error. Original JVM M3 implementation had a C based interface to it so you could run things in the native part of a Java execution using Modula-3 runtime fetures which doesn't allow messing with the safe modules but they can play with it. In the other hand SPIN had some small extensions to allow type checking of some extra type rules to allow dynamic conversions in a safe way. It allows a little bit of extra freedom. So both solutions could create a space for executing, for handling unsafe features to pass under safe threshold. Hope it helps --- El mar, 20/7/10, Tony Hosking escribi?: > De: Tony Hosking > Asunto: Re: [M3devel] Just putting it out there... > Para: "Mark Wickens" > CC: "m3devel" > Fecha: martes, 20 de julio, 2010 08:26 > Running Modula-3 on the Sun JVM poses > several difficulties, not least that Modula-3 is a systems > programming language like C/C++. Getting C, C++, or > Modula-3 to run on the JVM would all be the same level of > difficulty. The safe subset of Modula-3 would be less > difficult, but the unsafe operations would probably be a > showstopper. On the other hand, at one point there was > a version of Java running in the Modula-3 run-time. > > On 20 Jul 2010, at 03:26, Mark Wickens wrote: > > > Hi guys, > > > > Has there been any discussion/moves about implementing > Modula-3 as a > > language that runs on the Sun JVM? > > > > Seems a logical step given the similarities of Java to > Modula-3 (I got > > that phrase the right way round, didn't I?) > > > > That is something I would definitely be able to > provide help for. > > > > Regards, Mark. > > From rodney_bates at lcwb.coop Tue Jul 20 17:20:38 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 20 Jul 2010 10:20:38 -0500 Subject: [M3devel] merging gdb from 6.4 to 7.1? In-Reply-To: References: Message-ID: <4C45BEC6.40603@lcwb.coop> I have been thinking about doing this myself for some time, but up to now, have not had the time. I can certainly help, if you want to do it, or maybe take it on myself. I think I will be having more time soon. I have done it a couple of times before. A few things can be hard to figure out, because they rework existing stuff in gdb and it's hard to dig out what the new equivalent of the old mechanism is. A lot of the M3-specific code I either heavily modified or wrote. Jay K wrote: > The merge of m3cc/gcc from 4.3.0 to 4.3.5 went well enough. > > I'll volunteer to merge m3gdb from 6.4 to 7.1. BTW, there is now or will be very soom, a 7.2 gdb. Also, the latest gdb does reverse debugging, by recording snapshots during the forward run. This would be a *very* nice feature to have for Modula-3. > > Are people interested? > > I saw some mention of 6.4.3 in our history. > But there's no release called that. > What is it? I don't remember anything about this. > > Some of the conflicts are about SYMBOL_TYP vs. LHS_SYMBOL_TYPE. > What that a deliberate important change on our port? Yes, this is my change, very deliberate, and gets around a nasty group of dangling pointer bugs. I would have to took at it again, but it used to cache a pointer to a gdb type struct, lazily looked- up the first time, right into an existing field of another gdb struct. When you rerun, gdb reloads the referent structs of such pointers, leaving them dangling. Or maybe I am mixing up two different problems. Anyway, the two macros are essential. I have long thought it might be nice to design a better mechanism, but it's not simple. I strongly recommend not messing with it during merging to a newer gdb. Save that for a subsequent job with a separate CVS tag. It's only a performance matter, and except for debugging work that proceeds without requiring user-types commands all the time, it scarcely matters. Also, we would be a lot better off to dump stabs+ and use whatever latest version of dwarf that gdb already has support for. But that is also a job that should be done separately, with its own tag, after a new merge is working with the existing mechanisms. > > Thanks, > - Jay > > > > > From dabenavidesd at yahoo.es Tue Jul 20 22:13:01 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 20 Jul 2010 20:13:01 +0000 (GMT) Subject: [M3devel] merging gdb from 6.4 to 7.1? In-Reply-To: <4C45BEC6.40603@lcwb.coop> Message-ID: <192662.96738.qm@web23608.mail.ird.yahoo.com> Hi all: Is it possible to include in the m3gdb support for remote debugging like the one introduced by the developers in SPIN (which was based on DEC Firefly teledebug protocol called TTD see doi:10.1145/68210.69219 see doi.org), it is a protocol to remotely debug a target program but in such a case you have the post-mortem abilities is that hard to ask for doing it remotely, though TDD it was implemented for debugging the operating system itself it could be if I'm not wrong easier to debug from a type terminal remotely than in the cellphone or tablet it self when such a target is available for any application. Postmortem would be even nicer since there is general support in high-end cellphones which seem to be a ever increasing range of platforms and operating system versions and vendors. Other version of TTD protocol was used in the ldb debugger, this allowed even to disconnect and connect from cross-platform debugging to target and provide services for the stack walking between other issues its dependence in lcc's c compiler though will it be possible to replace it for an intermediate representation like the one of Modula-3 I just see possible for the m3tk toolkit to do it since support for it would be a nice feature for its debugging features the porting of the M3CG assembly machine language for the lcc framework would be possible, there is support on it for targeting even the CLI .Net framework so it would be good to ask if it isn't too hard to do it for a good reason to do it to host M3CG. Thanks in advance --- El mar, 20/7/10, Rodney M. Bates escribi?: > De: Rodney M. Bates > Asunto: Re: [M3devel] merging gdb from 6.4 to 7.1? > Para: "m3devel" > Fecha: martes, 20 de julio, 2010 10:20 > I have been thinking about doing this > myself for some time, but up to > now, have not had the time. I can certainly help, if > you want to do it, > or maybe take it on myself. I think I will be having > more time soon. > I have done it a couple of times before. A few things > can be hard to > figure out, because they rework existing stuff in gdb and > it's hard to > dig out what the new equivalent of the old mechanism > is. A lot of the > M3-specific code I either heavily modified or wrote. > > Jay K wrote: > > The merge of m3cc/gcc from 4.3.0 to 4.3.5 went well > enough. > > > > I'll volunteer to merge m3gdb from 6.4 to 7.1. > > BTW, there is now or will be very soom, a 7.2 gdb. > Also, the latest gdb does reverse debugging, by recording > snapshots during the forward run. This would be a > *very* > nice feature to have for Modula-3. > > > > > > Are people interested? > > > > I saw some mention of 6.4.3 in our history. > > But there's no release called that. > > What is it? > > I don't remember anything about this. > > > > > Some of the conflicts are about SYMBOL_TYP vs. > LHS_SYMBOL_TYPE. > > What that a deliberate important change on our port? > > Yes, this is my change, very deliberate, and gets around a > nasty > group of dangling pointer bugs. I would have to took > at it again, > but it used to cache a pointer to a gdb type struct, lazily > looked- > up the first time, right into an existing field of another > gdb struct. > When you rerun, gdb reloads the referent structs of such > pointers, > leaving them dangling. Or maybe I am mixing up two > different > problems. Anyway, the two macros are essential. > > I have long thought it might be nice to design a better > mechanism, > but it's not simple. I strongly recommend not messing > with it during > merging to a newer gdb. Save that for a subsequent > job with a separate > CVS tag. It's only a performance matter, and except > for debugging work > that proceeds without requiring user-types commands all the > time, it > scarcely matters. > > Also, we would be a lot better off to dump stabs+ and use > whatever > latest version of dwarf that gdb already has support > for. But that > is also a job that should be done separately, with its own > tag, after > a new merge is working with the existing mechanisms. > > > > > > Thanks, > > - Jay > > > > > > > > > > > > > From jay.krell at cornell.edu Wed Jul 21 04:58:47 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 21 Jul 2010 02:58:47 +0000 Subject: [M3devel] merging gdb from 6.4 to 7.1? In-Reply-To: <4C45BEC6.40603@lcwb.coop> References: , <4C45BEC6.40603@lcwb.coop> Message-ID: Thanks. To be clear then, my initial merge will likely lose some changes, it sounds like you are ok with that, and they can be redone soon thereafter by someone else (e.g. you). I'll be sure it builds and do a minimum of debugging with it. I'll expect it to understand some Modula-3 syntax and esp. decode types. When I use gdb everything is void* so there should be obvious improvement with m3gdb. I'm not sure what the best way to "help" is. I'm not super keen on "sharing diffs" or using branches. Therefore, come up with something reasonable maybe slightly flawed, commit it, someone else can improve it afterward, as long as the initial one isn't too flawed? ok? ok? There is some use of $revision$ and $id$ in there and it makes things slightly messy. There are files we didn't change, but which show as changed because of them. Mostly deleted stuff like hpread.c and the rdi-shared directory. Or we added comments in dwarfread.c which was deleted. I agree -gstabs might not be best. It isn't supported on e.g. HP64_HPUX. But often whenever I try other options like -g or -gcoff or -ggdb or -gdwarf, I get crashes in the backend so I leave the config files with -gstabs+. :( I don't think it matters too much what I merge up to, as long as it is >6.4. 7.1 is out. I didn't see 7.2. Thanks, - Jay > Date: Tue, 20 Jul 2010 10:20:38 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] merging gdb from 6.4 to 7.1? > > I have been thinking about doing this myself for some time, but up to > now, have not had the time. I can certainly help, if you want to do it, > or maybe take it on myself. I think I will be having more time soon. > I have done it a couple of times before. A few things can be hard to > figure out, because they rework existing stuff in gdb and it's hard to > dig out what the new equivalent of the old mechanism is. A lot of the > M3-specific code I either heavily modified or wrote. > > Jay K wrote: > > The merge of m3cc/gcc from 4.3.0 to 4.3.5 went well enough. > > > > I'll volunteer to merge m3gdb from 6.4 to 7.1. > > BTW, there is now or will be very soom, a 7.2 gdb. > Also, the latest gdb does reverse debugging, by recording > snapshots during the forward run. This would be a *very* > nice feature to have for Modula-3. > > > > > > Are people interested? > > > > I saw some mention of 6.4.3 in our history. > > But there's no release called that. > > What is it? > > I don't remember anything about this. > > > > > Some of the conflicts are about SYMBOL_TYP vs. LHS_SYMBOL_TYPE. > > What that a deliberate important change on our port? > > Yes, this is my change, very deliberate, and gets around a nasty > group of dangling pointer bugs. I would have to took at it again, > but it used to cache a pointer to a gdb type struct, lazily looked- > up the first time, right into an existing field of another gdb struct. > When you rerun, gdb reloads the referent structs of such pointers, > leaving them dangling. Or maybe I am mixing up two different > problems. Anyway, the two macros are essential. > > I have long thought it might be nice to design a better mechanism, > but it's not simple. I strongly recommend not messing with it during > merging to a newer gdb. Save that for a subsequent job with a separate > CVS tag. It's only a performance matter, and except for debugging work > that proceeds without requiring user-types commands all the time, it > scarcely matters. > > Also, we would be a lot better off to dump stabs+ and use whatever > latest version of dwarf that gdb already has support for. But that > is also a job that should be done separately, with its own tag, after > a new merge is working with the existing mechanisms. > > > > > > Thanks, > > - Jay > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ttmrichter at gmail.com Wed Jul 21 12:40:55 2010 From: ttmrichter at gmail.com (Michael Richter) Date: Wed, 21 Jul 2010 18:40:55 +0800 Subject: [M3devel] spin sources In-Reply-To: <27F80E57-716A-47ED-95DE-A73B51E580ED@sol42.com> References: <1279608663.2648.3.camel@localhost> <27F80E57-716A-47ED-95DE-A73B51E580ED@sol42.com> Message-ID: OK, Daniel, this is seriously cool! I've been trying to find SPIN source for a while now. On 20 July 2010 20:28, wrote: > Hello. I have spin-33.2.tar.gz from many many years ago. > > It is now available at http://www.sol42.com/spin-33.2.tar.gz > Its size is 27.675.835 bytes compressed, 119.961.600 uncompressed. > MD5 (spin-33.2.tar.gz) = 8fcd9457f1298eaef8819a21ab931712 > > GNU tar complains about zero data at the end of the archive, Solaris tar > just stops there. Hopefully nothing is missing. > > Regards. > -Daniel -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Jul 21 18:57:00 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 21 Jul 2010 16:57:00 +0000 Subject: [M3devel] Alpha/OSF exception handling In-Reply-To: References: , , , Message-ID: It doesn't seem to "just work". Will require some debugging. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Mon, 19 Jul 2010 07:31:22 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Alpha/OSF exception handling > > > I didn't "remove" it, but I did "disable" it. Similar. > I didn't want to have to spend any time debugging it if it didn't work any longer. > I'm sure we have precious few users of this system (2 this month though, quite a surge) and they can probably live with > an equally bad implementation as all the other platforms (except for Solaris/sparc). > Granted, they have slower than average systems, would benefit more perhaps from the optimization. > > We can try it out I guess. > > I do hope we can improve this across the aboard. > Even if we don't use the tree exception handling nodes, we can probably at least use the same runtime support (libunwind in libgcc). > Even then, Alpha/OSF won't be important. > > - Jay > > ---------------------------------------- > > From: hosking at cs.purdue.edu > > Date: Sun, 18 Jul 2010 14:22:41 -0400 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Alpha/OSF exception handling > > > > That is a huge shame. Why did you remove it? It used to be there and functional. > > > > On 18 Jul 2010, at 09:35, Jay K wrote: > > > > > > > > Modula-3 for ALPHA_OSF historically had the best exception handling implementation. > > > > > > With Solaris/sparc32 second best. > > > > > > And then everything else equally bad. > > > > > > > > > > > > > > > > > > The current Alpha/osf is now in the "equally bad" category. > > > Because I'm lazy. > > > > > > It might be worth restoring its former glory. > > > > > > > > > > > > Maybe a small project for someone? > > > > > > > > > The code is still in there. I just tweaked the m3makefiles to avoid trying it. > > > > > > > > > jbook2:runtime jay$ pwd > > > /dev2/cm3/m3-libs/m3core/src/runtime > > > jbook2:runtime jay$ find ALPHA_OSF > > > ALPHA_OSF/m3makefile-old > > > > > > Renaming that m3makefile. > > > > > > Fiddling with this: > > > > > > book2:runtime jay$ grep STACK * > > > m3makefile:readonly HAS_STACK_WALKER = { > > > m3makefile:if defined("M3_USE_STACK_WALKER") > > > m3makefile: if M3_USE_STACK_WALKER and HAS_STACK_WALKER contains TARGET > > > m3makefile: if HAS_STACK_WALKER{TARGET} > > > > > > > > > and this: > > > > > > > > > jbook2:src jay$ pwd > > > /dev2/cm3/m3-sys/m3middle/src > > > > > > > > > book2:src jay$ grep -i _stack *m3 > > > Target.m3: Has_stack_walker := FALSE; > > > Target.m3: Has_stack_walker := TRUE; > > > > > > > > > - Jay > > > > > > From rcolebur at SCIRES.COM Wed Jul 21 20:52:05 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Wed, 21 Jul 2010 14:52:05 -0400 Subject: [M3devel] compiler version number Message-ID: I grabbed the minimal 5.8.6 archive for Windows. Using this archive, "cm3 -version" yields: Critical Mass Modula-3 version 5.8.6 last updated: 2010-04-11 compiled: 2010-07-12 21:11:13 configuration: .\cm3.cfg host: NT386 target: NT386 But, when I use this edition to rebuild everything from the main trunk, "cm3 -version" now yields: Critical Mass Modula-3 version d5.8.2 last updated: 2009-07-15 compiled: 2010-07-21 17:29:53 configuration: C:\cm3\bin\cm3.cfg host: NT386 defaulting to native build: I386_NT target: I386_NT Can someone please explain how the version number and timestamp info get integrated into the compiler? If I can get a handle on the way it's currently done, I'll try to fix the problem I'm having on Windows with the info regressing. Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Jul 21 22:31:42 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 21 Jul 2010 20:31:42 +0000 Subject: [M3devel] compiler version number In-Reply-To: References: Message-ID: It's working on Windows. jbook2:~ jay$ cat /dev2/cm3/scripts/version.quake CM3VERSION = "d5.8.2" CM3VERSIONNUM = "050802" CM3LASTCHANGED = "2009-07-15" jbook2:~ jay$ cat /dev2/cm3/scripts/version CM3VERSION d5.8.2 CM3VERSIONNUM 050802 CM3LASTCHANGED 2009-07-15 ?- Jay ________________________________ > From: rcolebur at SCIRES.COM > To: m3devel at elegosoft.com > Date: Wed, 21 Jul 2010 14:52:05 -0400 > Subject: [M3devel] compiler version number > > > I grabbed the minimal 5.8.6 archive for Windows. > > > > Using this archive, ?cm3 ?version? yields: > > > > Critical Mass Modula-3 version 5.8.6 > > last updated: 2010-04-11 > > compiled: 2010-07-12 21:11:13 > > configuration: .\cm3.cfg > > host: NT386 > > target: NT386 > > > > But, when I use this edition to rebuild everything from the main trunk, > ?cm3 ?version? now yields: > > > > Critical Mass Modula-3 version d5.8.2 > > last updated: 2009-07-15 > > compiled: 2010-07-21 17:29:53 > > configuration: C:\cm3\bin\cm3.cfg > > host: NT386 > > defaulting to native build: I386_NT > > target: I386_NT > > > > Can someone please explain how the version number and timestamp info > get integrated into the compiler? > > > > If I can get a handle on the way it?s currently done, I?ll try to fix > the problem I?m having on Windows with the info regressing. > > > > Regards, > > Randy Coleburn > > From wagner at elegosoft.com Wed Jul 21 22:42:36 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 21 Jul 2010 22:42:36 +0200 Subject: [M3devel] compiler version number In-Reply-To: References: Message-ID: <20100721224236.7jkk3bregwk4w8o8@mail.elegosoft.com> Quoting "Coleburn, Randy" : > I grabbed the minimal 5.8.6 archive for Windows. > > Using this archive, "cm3 -version" yields: > > Critical Mass Modula-3 version 5.8.6 > last updated: 2010-04-11 > compiled: 2010-07-12 21:11:13 > configuration: .\cm3.cfg > host: NT386 > target: NT386 > > But, when I use this edition to rebuild everything from the main > trunk, "cm3 -version" now yields: > > Critical Mass Modula-3 version d5.8.2 > last updated: 2009-07-15 > compiled: 2010-07-21 17:29:53 > configuration: C:\cm3\bin\cm3.cfg > host: NT386 > defaulting to native build: I386_NT > target: I386_NT > > Can someone please explain how the version number and timestamp info > get integrated into the compiler? > > If I can get a handle on the way it's currently done, I'll try to > fix the problem I'm having on Windows with the info regressing. You're right, it's still wrong on the trunk. I've only cared for the release branch during the recent months, but I've just checked in a fix: % cvs -q diff -u Index: version =================================================================== RCS file: /usr/cvs/cm3/scripts/version,v retrieving revision 1.5 diff -u -u -r1.5 version --- version 15 Jul 2009 06:14:01 -0000 1.5 +++ version 21 Jul 2010 20:39:06 -0000 @@ -1,3 +1,3 @@ -CM3VERSION d5.8.2 -CM3VERSIONNUM 050802 -CM3LASTCHANGED 2009-07-15 +CM3VERSION d5.9.0 +CM3VERSIONNUM 050900 +CM3LASTCHANGED 2010-07-21 Index: version.quake =================================================================== RCS file: /usr/cvs/cm3/scripts/version.quake,v retrieving revision 1.1 diff -u -u -r1.1 version.quake --- version.quake 13 Apr 2010 11:14:22 -0000 1.1 +++ version.quake 21 Jul 2010 20:39:06 -0000 @@ -1,3 +1,3 @@ -CM3VERSION = "d5.8.2" -CM3VERSIONNUM = "050802" -CM3LASTCHANGED = "2009-07-15" +CM3VERSION = "d5.9.0" +CM3VERSIONNUM = "050900" +CM3LASTCHANGED = "2010-07-21" luthien [/d/home/wagner/work/cm3/scripts] wagner % cvs commit -m 'fix version number on trunk for 5.9 development' c/usr/cvs/cm3/scripts/version,v <-- version new revision: 1.6; previous revision: 1.5 /usr/cvs/cm3/scripts/version.quake,v <-- version.quake new revision: 1.2; previous revision: 1.1 All scripts should pick up the version from those files. Thanks for the hint, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Jul 22 16:25:06 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 22 Jul 2010 14:25:06 +0000 Subject: [M3devel] Hudson updating config files or not In-Reply-To: References: <20100721155314.E1BC6CC389@birch.elegosoft.com>, , , , <20100722085323.0nmmjnom94osso88@mail.elegosoft.com>, , <20100722091912.bibr9p0z1q88wog4@mail.elegosoft.com>, Message-ID: I'm not sure, but here is some analysis. In the release hudson tasks, we have http://hudson.modula3.com:8080/view/SOLgnu/job/cm3-release-build-SOLgnu/110/consoleFull and http://hudson.modula3.com:8080/view/SOLgnu/job/cm3-build-SOLgnu/163/console "build" and "release-build". I think these are, like, "build from last release" and "build from latest successful build". I'm not sure what they do, but instead of fighting over installs and CVS trees, they should perhaps just each maintain their own. That way, e.g., they could both update config files. ? Well, except if we are low on diskspace, which we are. And it is a defficiency of the system to put outputs in the source tree. ? We should be able to ge by with one source tree per node, and all outputs should go elsewhere, including the PGS files and ? including those install.sh that get generated. The source tree should never be written to, as an option at least. Anyway. In regression/defs.sh I believe they go here: test_build_current ... ? if [ "$1" = "rel" ]; then?? # This is the important recurring thing that makes things different? ? ? "release" goes here, "build" does not ? This path does update config files. ? ? ??? echo " === clean up before cm3 upgrade " ??? if [ -z "$NOCLEAN" ]; then ????? OMIT_GCC=yes ./scripts/do-cm3-core.sh realclean || exit 1 ????? ./scripts/do-pkg.sh realclean cminstall ??? fi ??? echo " === perform cm3 upgrade " ??? UPGRADE_CM3_CFG=yes ./scripts/upgrade.sh || exit 1 ??? echo " >>> OK build_${1}_upgrade ${DS} ${WS}" ? fi and then: ? echo " === build ${BSET} system with current compiler" ? BUILDSCRIPT="./scripts/do-cm3-${BSET}.sh" ? if [ "$1" = "rel" ]; then?? # This is the important recurring thing that makes things different? ??? if [ -z "$NOCLEAN" ]; then ????? OMIT_GCC=yes ./scripts/do-cm3-core.sh realclean || exit 1 ??? fi ? else ??? if [ -z "$NOCLEAN" ]; then ????? $BUILDSCRIPT realclean || exit 1 ??? fi ? fi ? $BUILDSCRIPT buildship || exit 1 or, oh no, now I'm confused, here?: test_build_system ? test_build_system and test_build_current are very similar! Confusing?! ? ? echo " === build core system with current compiler" ? BUILDSCRIPT="./scripts/do-cm3-core.sh" ? if [ -z "$NOCLEAN" ]; then ??? $BUILDSCRIPT realclean || exit 1 ? fi ? if $BUILDSCRIPT build; then ??? echo " >>> OK build_system ${DS} ${WS}; now rebuild and ship" ??? $BUILDSCRIPT buildship ??? echo " === install new compiler" ??? ????? This is what we are running for head, I think. ????? Historically it didn't touch config files. ????? This is what I changed a day or so ago, to update them. ??? if ./scripts/install-cm3-compiler.sh upgrade; then ????? echo "compiler upgraded successfully" ????? cm3 -version ??? else ????? echo "compiler upgrade failed" 1>&2 ????? exit 1 ??? fi ? else ? ??? There is this which will update config files, but only if the previous fails. ??? echo " === perform cm3 upgrade after cleaning everything" ??? $BUILDSCRIPT realclean || exit 1 ??? UPGRADE_CM3_CFG=yes ./scripts/upgrade.sh || exit 1 ??? echo " >>> OK build_upgrade ${DS} ${WS}" ? fi Anyway, it is confusing, release has a pair of tasks and only some paths updated config files, even if other/more/different paths update the compiler. I think: ? - we want the pairs of tasks, at least for testing coverage ? - or, I guess, just build from previous release ??? which can be constraining, it is a policy issue ? - whichever tasks we have, we should have config file updating ? - tangentially: we should get all outputs, *all* outouts out of the source tree ???? The original design was nice, get outputs "per package" outside of source, ???? but it failed to address a multi-package tree. This is a big change I'm proposing. ???? I guess another mail on the topic. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > CC: m3commit at elegosoft.com > Subject: RE: [M3commit] CVS Update: cm3 > Date: Thu, 22 Jul 2010 07:21:33 +0000 > > > (ps: the change I made does do the backup foo-date thing, parallel to cm3 and cm3cg > yes I'll compare the branches, can't promise a full merge though) > > > ---------------------------------------- > > Date: Thu, 22 Jul 2010 09:19:12 +0200 > > From: wagner at elegosoft.com > > To: jay.krell at cornell.edu > > CC: m3commit at elegosoft.com > > Subject: Re: [M3commit] CVS Update: cm3 > > > > I can live with a cm3-local.cfg file which gets included when it exists, > > contains local overrides and is never touched by he installation. > > > > We have to be careful to backup existing configs and informing the > > users before the installation though. > > > > I think upgrade did backups of the config, too. > > > > Can you check the scripts in the release branch if anything needs > > to be merged back? I won't be able to do that today. > > > > Olaf > > > > Quoting Jay K : > > > > > I thought it was too, before I looked at it. > > > Could be that head and release are very divergent. > > > I didn't look at release, oops. > > > I probably will "soon". > > > > > > > > > The config files are "partly part of the compiler", and partly > > > system-specific. > > > So they might have to be updated with the compiler. > > > > > > > > > Perhaps we can have cm3.cfg.user or cm3.cfg.local, that we never edit, > > > and maybe we should constrain it, like very line > > > must have an equals sign, and if it has a percent, percent must > > > follow equals. > > > > > > > > > e.g. > > > m3back_flags = "-custom" > > > SYSTEM_CC = "custom" % comment blah blah > > > SYSTEM_LIBS{"LIBC"} = "custom" > > > SYSTEM_LIBORDER += [custom] > > > > > > But that might not be flexible enough. > > > > > > Another option is that cm3.cfg file do like: > > > if exists("cm3.cfg.user.first") > > > include("cm3.cfg.user.first") > > > end > > > ... > > > if exists("cm3.cfg.user.last") > > > > > > include("cm3.cfg.user.last > > > > > > end > > > > > > > > > > > > which is infinitely flexible and not well defined. > > > Even limiting to assignments is not well defined. > > > You know, there's an interface somewhere in there, but it isn't > > > well specified. My fault. > > > I let things evolve and get discovered gradually, sometimes hard > > > to know ahead of time what the result will be. > > > > > > > > > I've made changes since 5.8.6 released such that config files from > > > prior to 5.8.6 will not suffice. > > > I can undo that, but there is an important policy and architecture question. > > > > > > > > > - Jay > > > > > > ---------------------------------------- > > >> Date: Thu, 22 Jul 2010 08:53:23 +0200 > > >> From: wagner at elegosoft.com > > >> To: m3commit at elegosoft.com > > >> Subject: Re: [M3commit] CVS Update: cm3 > > >> > > >> Quoting Jay K : > > >> > > >> > I've manually updated the config files on SPARC32_LINUX Hudson node > > >> > to try to fix this. > > >> > > >> That should be done by the upgrade script (and it already was AFAIR). > > >> I wouldn't like the script shipping a newly built compiler to > > >> unconditionally overwrite all my local configuration. > > >> > > >> Olaf > > >> > > >> > > > >> > - Jay > > >> > > > >> > ---------------------------------------- > > >> >> Date: Wed, 21 Jul 2010 17:53:14 +0000 > > >> >> To: m3commit at elegosoft.com > > >> >> From: jkrell at elego.de > > >> >> Subject: [M3commit] CVS Update: cm3 > > >> >> > > >> >> CVSROOT: /usr/cvs > > >> >> Changes by: jkrell at birch. 10/07/21 17:53:14 > > >> >> > > >> >> Modified files: > > >> >> cm3/scripts/: install-cm3-compiler.sh > > >> >> > > >> >> Log message: > > >> >> upgrade config files when upgrading compiler > > >> >> > > >> > > > >> > > >> > > >> > > >> -- > > >> Olaf Wagner -- elego Software Solutions GmbH > > >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 jay.krell at cornell.edu Thu Jul 22 16:47:22 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 22 Jul 2010 14:47:22 +0000 Subject: [M3devel] getting outputs out of the source tree? reducing "ship"? Message-ID: Today we have: /cvsroot/pkg1/src outputs to /src/pkg1/target /cvsroot/pkg2/src outputs to /src/pkg2/target This was good for its time, better than e.g. outputs to /cvsroot/pkg1/src ! However I want more. I want /cvsroot to be read only. So how about: ?outputs to /cvsroot-out/pkg1/target This is probably easy to achieve. e.g. introduce BUILD_DIR_ROOT (or OUTPUT_ROOT) and it is defined, prefix to BUILD_DIR. Probably would have to be accompanied by SOURCE_ROOT, prefix it as needed. ?e.g. relative paths that go from output to source would need to be fixed. an maybe much more so, remove ship as a separate step: ? outputs to /cvsroot-out/intermed/pkg1/target/*.mo? ? outputs to /cvsroot-out/inst/lib/libpkg1.so The one and only copy.? ? outputs to /cvsroot-out/inst/pkg/pkg1/src (maybe, separate ship step! because is a waste when still testing) To "clean", you would have a choice of rm -rf /cvsroot-out/* or mkdir /cvsroot-out2 ?and point whatever environment variable at -inst2. ?? (possibly by copying cm3 into out2 and pointing $PATH at it) The buildlocal vs. buildglobal distinction would go away. buildlocal + ship (which you can't do today, except by copying manually) would be equiv of ? set CM3_OUTPUT_ROOT=/cm3-inst.new? (or again, copy cm3/cm3cfg/config and set PATH) ? build everything ? To try it out, either change PATH, or ? mv /cm-inst /cm3-inst.old ? mv /cm3-inst.new /cm3-inst ? unset CM3_OUTPUT_ROOT If you want to build less, and remain isolated like buildlocal: ? cp -pr /cm3-inst $CM3_OUTPUT_ROOT ? build seletctively ? To try it out, either change PATH, or ? mv /cm-inst /cm3-inst.old ? mv /cm3-inst.new /cm3-inst ? unset CM3_OUTPUT_ROOT One of the points is: the immediate output of compilation could have the same structure as the installation. Installation can be just renaming or copying directories. Not reorganizing directory layout. buildglobal would be building into a new empty directory.-- instead of build + don't ship buildglobal would be building top of the in-use directory -- instead of build + ship Positive consequences: ? All unshipped binaries would work even if linked dynamically, e.g. with $ORIGIN, e.g. without static. ? It still doesn't address systems without $ORIGIN though. There are major advantages either way -- ie. without ORIGIN you can "stitch together" binaries whose paths have no relationship to each other, and you can move around at least the executables arbitrarily. ? Though you can't move the libraries at all. ?? chroot is another way people deal with this -- using absolute paths, but isolated from existing files. ??? It is kind of partial cheap virtual machine, chroot. Now, I have to admit, this is more of an intellectual exercise right now, as I don't have the time/inclination to do it soon. :( ? - Jay From rodney_bates at lcwb.coop Thu Jul 22 23:23:51 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 22 Jul 2010 16:23:51 -0500 Subject: [M3devel] merging gdb from 6.4 to 7.1? In-Reply-To: References: , <4C45BEC6.40603@lcwb.coop> Message-ID: <4C48B6E7.6060908@lcwb.coop> This sounds fine with me, as long as there is one branch for the entire merge process, which will be broken for a while. Jay K wrote: > Thanks. To be clear then, my initial merge will likely lose some changes, > it sounds like you are ok with that, and they can be redone soon > thereafter by someone else (e.g. you). > I'll be sure it builds and do a minimum of debugging with it. > I'll expect it to understand some Modula-3 syntax and esp. decode types. > When I use gdb everything is void* so there should be obvious improvement > with m3gdb. > I'm not sure what the best way to "help" is. I'm not super keen on > "sharing diffs" or using branches. Therefore, come up with something > reasonable maybe slightly flawed, commit it, someone else can improve it > afterward, as long as the initial one isn't too flawed? ok? > > > ok? > > > There is some use of $revision$ and $id$ in there and it makes things > slightly messy. > There are files we didn't change, but which show as changed because of them. > Mostly deleted stuff like hpread.c and the rdi-shared directory. > Or we added comments in dwarfread.c which was deleted. > > > I agree -gstabs might not be best. > It isn't supported on e.g. HP64_HPUX. > But often whenever I try other options like -g or -gcoff or -ggdb or > -gdwarf, > I get crashes in the backend so I leave the config files with -gstabs+. :( > > > I don't think it matters too much what I merge up to, as long as it is >6.4. > 7.1 is out. I didn't see 7.2. > > > Thanks, > - Jay > > > > Date: Tue, 20 Jul 2010 10:20:38 -0500 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] merging gdb from 6.4 to 7.1? > > > > I have been thinking about doing this myself for some time, but up to > > now, have not had the time. I can certainly help, if you want to do it, > > or maybe take it on myself. I think I will be having more time soon. > > I have done it a couple of times before. A few things can be hard to > > figure out, because they rework existing stuff in gdb and it's hard to > > dig out what the new equivalent of the old mechanism is. A lot of the > > M3-specific code I either heavily modified or wrote. > > > > Jay K wrote: > > > The merge of m3cc/gcc from 4.3.0 to 4.3.5 went well enough. > > > > > > I'll volunteer to merge m3gdb from 6.4 to 7.1. > > > > BTW, there is now or will be very soom, a 7.2 gdb. > > Also, the latest gdb does reverse debugging, by recording > > snapshots during the forward run. This would be a *very* > > nice feature to have for Modula-3. > > > > > > > > > > Are people interested? > > > > > > I saw some mention of 6.4.3 in our history. > > > But there's no release called that. > > > What is it? > > > > I don't remember anything about this. > > > > > > > > Some of the conflicts are about SYMBOL_TYP vs. LHS_SYMBOL_TYPE. > > > What that a deliberate important change on our port? > > > > Yes, this is my change, very deliberate, and gets around a nasty > > group of dangling pointer bugs. I would have to took at it again, > > but it used to cache a pointer to a gdb type struct, lazily looked- > > up the first time, right into an existing field of another gdb struct. > > When you rerun, gdb reloads the referent structs of such pointers, > > leaving them dangling. Or maybe I am mixing up two different > > problems. Anyway, the two macros are essential. > > > > I have long thought it might be nice to design a better mechanism, > > but it's not simple. I strongly recommend not messing with it during > > merging to a newer gdb. Save that for a subsequent job with a separate > > CVS tag. It's only a performance matter, and except for debugging work > > that proceeds without requiring user-types commands all the time, it > > scarcely matters. > > > > Also, we would be a lot better off to dump stabs+ and use whatever > > latest version of dwarf that gdb already has support for. But that > > is also a job that should be done separately, with its own tag, after > > a new merge is working with the existing mechanisms. > > > > > > > > > > Thanks, > > > - Jay > > > > > > > > > > > > > > > From rodney_bates at lcwb.coop Thu Jul 22 23:48:11 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 22 Jul 2010 16:48:11 -0500 Subject: [M3devel] merging gdb from 6.4 to 7.1? More info on LHS_SYMBOL_TYPE In-Reply-To: <4C45BEC6.40603@lcwb.coop> References: <4C45BEC6.40603@lcwb.coop> Message-ID: <4C48BC9B.4020708@lcwb.coop> Rodney M. Bates wrote: > I have been thinking about doing this myself for some time, but up to > now, have not had the time. I can certainly help, if you want to do it, > or maybe take it on myself. I think I will be having more time soon. > I have done it a couple of times before. A few things can be hard to > figure out, because they rework existing stuff in gdb and it's hard to > dig out what the new equivalent of the old mechanism is. A lot of the > M3-specific code I either heavily modified or wrote. > > Jay K wrote: >> The merge of m3cc/gcc from 4.3.0 to 4.3.5 went well enough. >> >> I'll volunteer to merge m3gdb from 6.4 to 7.1. > > BTW, there is now or will be very soom, a 7.2 gdb. > Also, the latest gdb does reverse debugging, by recording > snapshots during the forward run. This would be a *very* > nice feature to have for Modula-3. > > >> >> Are people interested? >> >> I saw some mention of 6.4.3 in our history. >> But there's no release called that. >> What is it? > > I don't remember anything about this. > >> >> Some of the conflicts are about SYMBOL_TYP vs. LHS_SYMBOL_TYPE. >> What that a deliberate important change on our port? > > Yes, this is my change, very deliberate, and gets around a nasty > group of dangling pointer bugs. I would have to took at it again, > but it used to cache a pointer to a gdb type struct, lazily looked- > up the first time, right into an existing field of another gdb struct. > When you rerun, gdb reloads the referent structs of such pointers, > leaving them dangling. Or maybe I am mixing up two different > problems. Anyway, the two macros are essential. > > I have long thought it might be nice to design a better mechanism, > but it's not simple. I strongly recommend not messing with it during > merging to a newer gdb. Save that for a subsequent job with a separate > CVS tag. It's only a performance matter, and except for debugging work > that proceeds without requiring user-types commands all the time, it > scarcely matters. I looked back at this. Actually, I am not sure the split of SYMBOL_TYPE into LHS_SYMBOL_TYPE and SYMBOL_TYPE was my original doing, but part of the original mods from stock gdb to m3gdb. I just remember having to figure out in a number of places, which occurrences should be which macro. In stock gdb, there is only SYMBOL_TYPE. It expands to an lvalue that denotes the type member of a symbol. It is used both to assign to and to fetch that member. SYMBOL_TYPE, in m3gdb is effectively an accessor or getter function, but it does some computation to resolve the type using a UID, rather than just fetching a field. it expands to a non-lvalue. Use it to get the type when you have a symbol. In m3gdb, LHS_SYMBOL_TYPE is the corresponding mutator or setter function. I think it's actually the same macro as SYMBOL_TYPE is in gdb. Places in stock gdb that assign to the type field need to be changed to use LHS_SYMBOL_TYPE in m3gdb, to work. Except for a couple of places where a null is assigned, all uses of LHS_SYMBOL_TYPE are in code that is non-m3gdb-specific. I guess it would make future merges easier if LHS_SYMBOL_TYPE were changed back to the original SYMBOL_TYPE and the M3-specific accessor were renamed to something else, perhaps M3_SYMBOL_TYPE or M3_RESOLVE_SYMBOL_TYPE. This would move the changes to be merged out of gdb source files that are not m3gdb-specific. The caching that caused the dangling pointer bugs can be seen in the m3gdb version of the definition of SYMBOL_TYPE, but is it commented out. The resolution is always done over every time. If only gdb had a garbage collector, this would be easier. Actually, I suppose it would need weak references to make the caching work. > > Also, we would be a lot better off to dump stabs+ and use whatever > latest version of dwarf that gdb already has support for. But that > is also a job that should be done separately, with its own tag, after > a new merge is working with the existing mechanisms. > > >> >> Thanks, >> - Jay >> >> >> >> >> > From rodney_bates at lcwb.coop Thu Jul 22 23:57:36 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 22 Jul 2010 16:57:36 -0500 Subject: [M3devel] gdb versions to merge m3gdb into Message-ID: <4C48BED0.2020707@lcwb.coop> The following were recently posted on the gdb development mailing list. If we go to all the work of merging a new gdb, it would be worth waiting a bit if necessary, to get the very latest. Otherwise, our m3gdb is outdated before it even gets working. I don't know more than this about the schedule, but new release branches usually become releases fairly quickly. Both these were posted by Joel Brobecker, on 07/07/2010. I don't know what the relationship between 7.2 and 7.1.90 pre-releases is. -------------------------------------------------------------------------- Hello, A quick message to announce that the GDB 7.2 branch has just been created. The prerelease snapshots will be available at: ftp://sourceware.org/pub/gdb/snapshots/branch/gdb.tar.bz2 The sources are also accessible via CVS: cvs -d :pserver:anoncvs at sourceware.org:/cvs/src co -r gdb_7_2-branch gdb This announcement has also been posted on the GDB web site at: http://www.sourceware.org/gdb/ -- Joel -------------------------------------------------------------------------- Hello, I have just finished creating the gdb-7.1.90 pre-release. It is available for download at the following location: ftp://sourceware.org/pub/gdb/snapshots/branch/gdb-7.1.90.tar.bz2 A gzip'ed version is also available: gdb-7.1.90.tar.gz. Please give it a test if you can and report any problems you might find. x64-windows users, please note the following which is not part of this pre-release: http://www.sourceware.org/ml/gdb-patches/2010-07/msg00130.html On behalf of all the GDB contributors, thank you! -- Joel -------------------------------------------------------------------------- From rcolebur at SCIRES.COM Fri Jul 23 06:46:29 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Fri, 23 Jul 2010 00:46:29 -0400 Subject: [M3devel] Just putting it out there... In-Reply-To: References: , , <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com> , , <20100719090459.4CE191A2084@async.async.caltech.edu> , , <20100719110208.011521A2091@async.async.caltech.edu> , <20100719143844.03al7scsg0g400so@mail.elegosoft.com> <1279610803.1935.1.camel@x60.appsoftint.co.uk> <1279633010.1935.11.camel@x60.appsoftint.co.uk> Message-ID: I don't think the sources are available to the M3 JVM, but Olaf would know best on this. If they aren't available, we could check with Farshad Nayeri, one of the original owners/developers of Critical Mass, to see if he might consent to make them available, but this would be a long shot. Regards, Randy Coleburn -----Original Message----- From: m3 at sol42.com [mailto:m3 at sol42.com] Sent: Tuesday, July 20, 2010 10:15 AM To: m3devel Subject: Re: [M3devel] Just putting it out there... On 20 Jul 2010, at 15:36, Mark Wickens wrote: > Yes, after I'd written the email and thought about it I realised it was > a pretty stupid idea. Well, not stupid at all. Java may suck but the JVM certainly does not. There is a lot of interest now in compiling languages other than Java on the JVM, which has turned out to be a sort of universal runtime. Only that it was designed with Java in mind, and you would end up with something *like* Modula-3, not Modula-3 itself: what you can do in JVM "assembly" is limited, no PACKED types, no BITS x FOR y .. z, LOOPHOLE may or may not be always possible, UNTRACED would be problematic, pointer arithmetic in UNSAFE modules might require JNI and who knows what else, forget about <*EXTERNAL*> C calls, full interoperability with Java would require supporting Java interfaces (at the language level I think)... and these are just the few I can think of right now. On the other hand I would really like to code in this superset-of-a-subset of Modula-3 and run it on a JVM. Regarding the Critical Mass JVM described in Threads 3, are the sources available? Regards. -Daniel From wagner at elegosoft.com Fri Jul 23 08:39:49 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 23 Jul 2010 08:39:49 +0200 Subject: [M3devel] Hudson updating config files or not In-Reply-To: References: <20100721155314.E1BC6CC389@birch.elegosoft.com>, , , , <20100722085323.0nmmjnom94osso88@mail.elegosoft.com>, , <20100722091912.bibr9p0z1q88wog4@mail.elegosoft.com>, Message-ID: <20100723083949.l0e85r6j34gks04w@mail.elegosoft.com> The distinction between lastok-build and release-build jobs is obsolete; they have been combined to the -build- jobs ,amy months ago. Just forget about all lastok-build and release-build jobs that may still linger there; they should all be disabled. The -build- jobs should all try a straight forward compile with the cm3 built the last time; if that fails, they will clean everything and start over again with upgrade.sh. That's the only one where configuration files used to get changed. Only the -build- and -test- jobs have been copied over to current. Almost all sources for the hudson jobs should reside in the scripts/regression directory and be under version control. I don't think updates/merges are needed there. Where I wasn't so sure are the scripts one level above. Olaf Quoting Jay K : > I'm not sure, but here is some analysis. > > In the release hudson tasks, we have > http://hudson.modula3.com:8080/view/SOLgnu/job/cm3-release-build-SOLgnu/110/consoleFull > and > http://hudson.modula3.com:8080/view/SOLgnu/job/cm3-build-SOLgnu/163/console > > > "build" and "release-build". > I think these are, like, "build from last release" and "build from > latest successful build". > I'm not sure what they do, but instead of fighting over installs and > CVS trees, they should perhaps just each maintain their own. > That way, e.g., they could both update config files. > > ? Well, except if we are low on diskspace, which we are. And it is a > defficiency of the system to put outputs in the source tree. > ? We should be able to ge by with one source tree per node, and all > outputs should go elsewhere, including the PGS files and > ? including those install.sh that get generated. The source tree > should never be written to, as an option at least. Anyway. > > > In regression/defs.sh I believe they go here: > > > test_build_current > ... > ? if [ "$1" = "rel" ]; then?? # This is the important recurring > thing that makes things different? > ? > ? "release" goes here, "build" does not > ? This path does update config files. > ? > ? > ??? echo " === clean up before cm3 upgrade " > ??? if [ -z "$NOCLEAN" ]; then > ????? OMIT_GCC=yes ./scripts/do-cm3-core.sh realclean || exit 1 > ????? ./scripts/do-pkg.sh realclean cminstall > ??? fi > ??? echo " === perform cm3 upgrade " > ??? UPGRADE_CM3_CFG=yes ./scripts/upgrade.sh || exit 1 > ??? echo " >>> OK build_${1}_upgrade ${DS} ${WS}" > ? fi > > > and then: > > > ? echo " === build ${BSET} system with current compiler" > ? BUILDSCRIPT="./scripts/do-cm3-${BSET}.sh" > ? if [ "$1" = "rel" ]; then?? # This is the important recurring > thing that makes things different? > ??? if [ -z "$NOCLEAN" ]; then > ????? OMIT_GCC=yes ./scripts/do-cm3-core.sh realclean || exit 1 > ??? fi > ? else > ??? if [ -z "$NOCLEAN" ]; then > ????? $BUILDSCRIPT realclean || exit 1 > ??? fi > ? fi > ? $BUILDSCRIPT buildship || exit 1 > > > or, oh no, now I'm confused, here?: > > > test_build_system > > ? test_build_system and test_build_current are very similar! Confusing?! > ? > > ? echo " === build core system with current compiler" > ? BUILDSCRIPT="./scripts/do-cm3-core.sh" > ? if [ -z "$NOCLEAN" ]; then > ??? $BUILDSCRIPT realclean || exit 1 > ? fi > ? if $BUILDSCRIPT build; then > ??? echo " >>> OK build_system ${DS} ${WS}; now rebuild and ship" > ??? $BUILDSCRIPT buildship > ??? echo " === install new compiler" > ??? > ????? This is what we are running for head, I think. > ????? Historically it didn't touch config files. > ????? This is what I changed a day or so ago, to update them. > > ??? if ./scripts/install-cm3-compiler.sh upgrade; then > ????? echo "compiler upgraded successfully" > ????? cm3 -version > ??? else > ????? echo "compiler upgrade failed" 1>&2 > ????? exit 1 > ??? fi > ? else > ? > ??? There is this which will update config files, but only if the > previous fails. > > ??? echo " === perform cm3 upgrade after cleaning everything" > ??? $BUILDSCRIPT realclean || exit 1 > ??? UPGRADE_CM3_CFG=yes ./scripts/upgrade.sh || exit 1 > ??? echo " >>> OK build_upgrade ${DS} ${WS}" > ? fi > > > Anyway, it is confusing, release has a pair of tasks and only some > paths updated config files, even if other/more/different paths > update the compiler. > > > I think: > ? - we want the pairs of tasks, at least for testing coverage > ? - or, I guess, just build from previous release > ??? which can be constraining, it is a policy issue > ? - whichever tasks we have, we should have config file updating > ? - tangentially: we should get all outputs, *all* outouts out of > the source tree > ???? The original design was nice, get outputs "per package" outside > of source, > ???? but it failed to address a multi-package tree. This is a big > change I'm proposing. > ???? I guess another mail on the topic. > > ?- Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com >> CC: m3commit at elegosoft.com >> Subject: RE: [M3commit] CVS Update: cm3 >> Date: Thu, 22 Jul 2010 07:21:33 +0000 >> >> >> (ps: the change I made does do the backup foo-date thing, parallel >> to cm3 and cm3cg >> yes I'll compare the branches, can't promise a full merge though) >> >> >> ---------------------------------------- >> > Date: Thu, 22 Jul 2010 09:19:12 +0200 >> > From: wagner at elegosoft.com >> > To: jay.krell at cornell.edu >> > CC: m3commit at elegosoft.com >> > Subject: Re: [M3commit] CVS Update: cm3 >> > >> > I can live with a cm3-local.cfg file which gets included when it exists, >> > contains local overrides and is never touched by he installation. >> > >> > We have to be careful to backup existing configs and informing the >> > users before the installation though. >> > >> > I think upgrade did backups of the config, too. >> > >> > Can you check the scripts in the release branch if anything needs >> > to be merged back? I won't be able to do that today. >> > >> > Olaf >> > >> > Quoting Jay K : >> > >> > > I thought it was too, before I looked at it. >> > > Could be that head and release are very divergent. >> > > I didn't look at release, oops. >> > > I probably will "soon". >> > > >> > > >> > > The config files are "partly part of the compiler", and partly >> > > system-specific. >> > > So they might have to be updated with the compiler. >> > > >> > > >> > > Perhaps we can have cm3.cfg.user or cm3.cfg.local, that we never edit, >> > > and maybe we should constrain it, like very line >> > > must have an equals sign, and if it has a percent, percent must >> > > follow equals. >> > > >> > > >> > > e.g. >> > > m3back_flags = "-custom" >> > > SYSTEM_CC = "custom" % comment blah blah >> > > SYSTEM_LIBS{"LIBC"} = "custom" >> > > SYSTEM_LIBORDER += [custom] >> > > >> > > But that might not be flexible enough. >> > > >> > > Another option is that cm3.cfg file do like: >> > > if exists("cm3.cfg.user.first") >> > > include("cm3.cfg.user.first") >> > > end >> > > ... >> > > if exists("cm3.cfg.user.last") >> > > >> > > include("cm3.cfg.user.last >> > > >> > > end >> > > >> > > >> > > >> > > which is infinitely flexible and not well defined. >> > > Even limiting to assignments is not well defined. >> > > You know, there's an interface somewhere in there, but it isn't >> > > well specified. My fault. >> > > I let things evolve and get discovered gradually, sometimes hard >> > > to know ahead of time what the result will be. >> > > >> > > >> > > I've made changes since 5.8.6 released such that config files from >> > > prior to 5.8.6 will not suffice. >> > > I can undo that, but there is an important policy and >> architecture question. >> > > >> > > >> > > - Jay >> > > >> > > ---------------------------------------- >> > >> Date: Thu, 22 Jul 2010 08:53:23 +0200 >> > >> From: wagner at elegosoft.com >> > >> To: m3commit at elegosoft.com >> > >> Subject: Re: [M3commit] CVS Update: cm3 >> > >> >> > >> Quoting Jay K : >> > >> >> > >> > I've manually updated the config files on SPARC32_LINUX Hudson node >> > >> > to try to fix this. >> > >> >> > >> That should be done by the upgrade script (and it already was AFAIR). >> > >> I wouldn't like the script shipping a newly built compiler to >> > >> unconditionally overwrite all my local configuration. >> > >> >> > >> Olaf >> > >> >> > >> > >> > >> > - Jay >> > >> > >> > >> > ---------------------------------------- >> > >> >> Date: Wed, 21 Jul 2010 17:53:14 +0000 >> > >> >> To: m3commit at elegosoft.com >> > >> >> From: jkrell at elego.de >> > >> >> Subject: [M3commit] CVS Update: cm3 >> > >> >> >> > >> >> CVSROOT: /usr/cvs >> > >> >> Changes by: jkrell at birch. 10/07/21 17:53:14 >> > >> >> >> > >> >> Modified files: >> > >> >> cm3/scripts/: install-cm3-compiler.sh >> > >> >> >> > >> >> Log message: >> > >> >> upgrade config files when upgrading compiler >> > >> >> >> > >> > >> > >> >> > >> >> > >> >> > >> -- >> > >> Olaf Wagner -- elego Software Solutions GmbH >> > >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> > >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 >> > >> > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Fri Jul 23 09:14:13 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 23 Jul 2010 09:14:13 +0200 Subject: [M3devel] getting outputs out of the source tree? reducing "ship"? In-Reply-To: References: Message-ID: <20100723091413.tjia6l308wks80ks@mail.elegosoft.com> You're writing from a perspective of building the complete CM3 distribution. The designers of the package system intentionally made working in the locality of one package easy. Package local build and ship are two of the abstractions that make M3 well suited for large projects, where the isolation of one package is the working context of one developer. Actually, M3 offers many levels/layers of this kind of abstraction that all have its use: o opaque type definition o partial revelation o modules with interfaces o generics for parametric type abstraction o packages with visible and invisible interfaces I wouldn't wnat to loose any of them. So I'm against changing anything regarding build and ship _as default_. I don't object to beging able to override the output directory of package building to another derived hierarchy, and to use that for building the distribution archives. If anybody wants to work on that, I'd expect it being written and tested in isolation, until it is mature enough to actually replace our existing infrastructure. As you mention, it will be a lot of work. Olaf Quoting Jay K : > Today we have: > > > /cvsroot/pkg1/src > outputs to /src/pkg1/target > > > /cvsroot/pkg2/src > > outputs to /src/pkg2/target > > > > This was good for its time, better than e.g. > outputs to /cvsroot/pkg1/src ! > > > However I want more. > > > I want /cvsroot to be read only. > > > So how about: > ?outputs to /cvsroot-out/pkg1/target > > > This is probably easy to achieve. > e.g. introduce BUILD_DIR_ROOT (or OUTPUT_ROOT) and it is defined, > prefix to BUILD_DIR. > Probably would have to be accompanied by SOURCE_ROOT, prefix it as needed. > ?e.g. relative paths that go from output to source would need to be fixed. > > > > an maybe much more so, remove ship as a separate step: > > > ? outputs to /cvsroot-out/intermed/pkg1/target/*.mo? > ? > > outputs to /cvsroot-out/inst/lib/libpkg1.so The one and only copy.? > ? outputs to /cvsroot-out/inst/pkg/pkg1/src (maybe, separate ship > step! because is a waste when still testing) > > > To "clean", you would have a choice of > > > rm -rf /cvsroot-out/* > > or mkdir /cvsroot-out2 > ?and point whatever environment variable at -inst2. > ?? (possibly by copying cm3 into out2 and pointing $PATH at it) > > > The buildlocal vs. buildglobal distinction would go away. > buildlocal + ship (which you can't do today, except by copying > manually) would be equiv of > ? set CM3_OUTPUT_ROOT=/cm3-inst.new? (or again, copy > cm3/cm3cfg/config and set PATH) > ? build everything > ? To try it out, either change PATH, or > > > ? mv /cm-inst /cm3-inst.old > ? mv /cm3-inst.new /cm3-inst > ? unset CM3_OUTPUT_ROOT > > > > If you want to build less, and remain isolated like buildlocal: > > > ? cp -pr /cm3-inst $CM3_OUTPUT_ROOT > ? build seletctively > ? To try it out, either change PATH, or > > ? mv /cm-inst /cm3-inst.old > > ? mv /cm3-inst.new /cm3-inst > > ? unset CM3_OUTPUT_ROOT > > > > > One of the points is: the immediate output of compilation could have > the same structure as the installation. > Installation can be just renaming or copying directories. Not > reorganizing directory layout. > > > buildglobal would be building into a new empty directory.-- instead > of build + don't ship > buildglobal would be building top of the in-use directory -- instead > of build + ship > > Positive consequences: > ? All unshipped binaries would work even if linked dynamically, e.g. > with $ORIGIN, e.g. without static. > ? It still doesn't address systems without $ORIGIN though. > > > There are major advantages either way -- ie. without ORIGIN you can > "stitch together" binaries whose > paths have no relationship to each other, and you can move around at > least the executables arbitrarily. > ? Though you can't move the libraries at all. > ?? chroot is another way people deal with this -- using absolute > paths, but isolated from existing files. > ??? It is kind of partial cheap virtual machine, chroot. > > > Now, I have to admit, this is more of an intellectual exercise right > now, as I don't have the time/inclination to do it soon. :( > > > ? > - Jay > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Jul 23 21:13:52 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 23 Jul 2010 19:13:52 +0000 Subject: [M3devel] openbsd threading Message-ID: If we use -pthread or -lpthread, the call to sigsuspend hangs. If we don't use -pthread or -lpthread, some tests fail to build. So I think we are stuck going back to setjmp munging, which is what 5.8.6 does. Just for OpenBSD. Darwin/amd64 and old FreeBSD can hopefully still use sigaltstack. Linux, Solaris, Darwin/non-amd64, current FreeBSD can still use get/set/make/swapcontext. Maybe I'll upgrade to OpenBSD 4.7 first and give that a shot. I'm one version behind, 4.6. ?- Jay From wagner at elegosoft.com Sat Jul 24 11:08:17 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 24 Jul 2010 11:08:17 +0200 Subject: [M3devel] m3test failure on FreeBSD Message-ID: <20100724110817.uct40io1sw0ggg88@mail.elegosoft.com> Has anybody any idea why this stubbornly fails on FreeBSD4 in current: http://hudson.modula3.com:8080/job/cm3-current-test-m3tests-FreeBSD4/10/console Obviously, the subdirectory cannot be removed by FSUtils.RmRec; error code 66 means it is not empty. I've written this small test program MODULE rmtest EXPORTS Main; IMPORT IO, FSUtils; CONST d = "/pub/users/hudson/workspace/cm3-current-test-m3tests-FreeBSD4/cm3/m3-sys/m3tests/src/p2/p240/FreeBSD4"; BEGIN TRY FSUtils.RmRec( d ); EXCEPT FSUtils.E(m) => IO.Put( m ); END; END rmtest. and of course it runs without a problem :-/ There is nothing suspicious in that directory after the test, at least I cannot see anything. I haven't noticed this problem on any other platform, and in the release branch the tests ran, too. 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 jay.krell at cornell.edu Sat Jul 24 16:34:55 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 24 Jul 2010 14:34:55 +0000 Subject: [M3devel] m3test failure on FreeBSD In-Reply-To: <20100724110817.uct40io1sw0ggg88@mail.elegosoft.com> References: <20100724110817.uct40io1sw0ggg88@mail.elegosoft.com> Message-ID: Could it be open files subject to garbage collection? Could we get more information reported at the time of the failure? ?- Jay ---------------------------------------- > Date: Sat, 24 Jul 2010 11:08:17 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] m3test failure on FreeBSD > > Has anybody any idea why this stubbornly fails on FreeBSD4 in current: > > > http://hudson.modula3.com:8080/job/cm3-current-test-m3tests-FreeBSD4/10/console > > Obviously, the subdirectory cannot be removed by FSUtils.RmRec; error > code 66 means it is not empty. > > I've written this small test program > > MODULE rmtest EXPORTS Main; > > IMPORT IO, FSUtils; > > CONST d = > "/pub/users/hudson/workspace/cm3-current-test-m3tests-FreeBSD4/cm3/m3-sys/m3tests/src/p2/p240/FreeBSD4"; > > BEGIN > TRY > FSUtils.RmRec( d ); > EXCEPT > FSUtils.E(m) => IO.Put( m ); > END; > END rmtest. > > and of course it runs without a problem :-/ > > There is nothing suspicious in that directory after the test, at least > I cannot see anything. I haven't noticed this problem on any other platform, > and in the release branch the tests ran, too. > > 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 jay.krell at cornell.edu Sun Jul 25 12:58:42 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 25 Jul 2010 10:58:42 +0000 Subject: [M3devel] FreeBSD gc stack? Message-ID: So, my real goal here is I'm reviewing why we can't/don't use pthreads on OpenBSD. ? I have a new system and would rather not do the jmpbuf munging. OpenBSD has suspend/resume like FreeBSD. You can inquire as to the stack, but it looks like you get the whole thing, not just the part currently used. And the FreeBSD code appears similar, and appears to walk it incorrectly (no, see below the code before reading the code)? void ThreadPThread__ProcessStopped (m3_pthread_t mt, void *bottom, void *context, ????????????????????????????? void (*p)(void *start, void *limit)) { ? pthread_attr_t attr; ? char *stackaddr; ? WORD_T stacksize; ? /* process the stacks */ ? if (pthread_attr_init(&attr) != 0) abort(); ? if (pthread_attr_get_np(PTHREAD_FROM_M3(mt), &attr) != 0) abort(); ? if (pthread_attr_getstack(&attr, (void **)&stackaddr, &stacksize) != 0) abort(); ? if (pthread_attr_destroy(&attr) != 0) abort(); #if 0 ? assert(stack_grows_down); /* See ThreadPThreadC.c */ #endif ? assert(context == 0); ? assert((char *)bottom >= stackaddr); ? assert((char *)bottom <= (stackaddr + stacksize)); ? p(stackaddr, bottom); ? /* assume registers are stored in the stack */ ? /* but call p to simulate processing registers: see RTHeapStats.m3 */ ? p(0, 0); } ok..it turns out "bottom" is "top"..probably you can define them either way.. it is the highest address. But still, this does have the unfortunate characteristic of scanning the entire stack, not just the "live" part, right? It looks the like the same compromise is easy to achieve on OpenBSD. I think I'll try pthreads there again. I understand it is still usermode and won't run on multiple processors, but it also provides for better portability (no setjmp munging). ?- Jay From jay.krell at cornell.edu Mon Jul 26 13:18:26 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 26 Jul 2010 11:18:26 +0000 Subject: [M3devel] pthread_self == null? Message-ID: I don't see that the standard prohibits NULL from being a valid pthread_t. ? I happened upon this only due to a problem though: OpenBSD x86 4.6 -lX11 -static gives a broken pthreads. We should add an extra boolean to this code, like, before: VAR ? holder: pthread_t; ? inCritical := 0; PROCEDURE LockHeap () = ? VAR self := pthread_self(); ? BEGIN ??? IF pthread_equal(holder, self) = 0 THEN ????? WITH r = pthread_mutex_lock(heapMu) DO <*ASSERT r=0*> END; ????? holder := self; ??? END; ??? INC(inCritical); ? END LockHeap; PROCEDURE UnlockHeap () = ? BEGIN ??? <*ASSERT pthread_equal(holder, pthread_self()) # 0*> ??? DEC(inCritical); ??? IF inCritical = 0 THEN ????? holder := NIL; ????? WITH r = pthread_mutex_unlock(heapMu) DO <*ASSERT r=0*> END; ??? END; ? END UnlockHeap; after: VAR ? holder: pthread_t; +? holder_valid: BOOLEAN; ? inCritical := 0; PROCEDURE LockHeap () = ? VAR self := pthread_self(); ? BEGIN *??? IF NOT holder_valid OR pthread_equal(holder, self) = 0 THEN ????? WITH r = pthread_mutex_lock(heapMu) DO <*ASSERT r=0*> END; ????? holder := self; +???? holder_valid := TRUE;? ??? END; ??? INC(inCritical); ? END LockHeap; PROCEDURE UnlockHeap () = ? BEGIN *??? <*ASSERT holder_valid AND pthread_equal(holder, pthread_self()) # 0*> ??? DEC(inCritical); ??? IF inCritical = 0 THEN ????? holder := NIL; +???? holder_valid := FALSE? ????? WITH r = pthread_mutex_unlock(heapMu) DO <*ASSERT r=0*> END; ??? END; ? END UnlockHeap; I think so. ?- Jay From jay.krell at cornell.edu Mon Jul 26 14:39:55 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 26 Jul 2010 12:39:55 +0000 Subject: [M3devel] newly discoved quake feature Message-ID: I didn't realize, but hash tables don't have to have values. You can say: {"key1", "key2"} contains "foo" You don't need: {"key1" : 1, "key2" : 1} contains "foo" ?- Jay From hosking at cs.purdue.edu Mon Jul 26 21:00:29 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 26 Jul 2010 15:00:29 -0400 Subject: [M3devel] pthread_self == null? In-Reply-To: References: Message-ID: <8599A6EE-9456-440F-A06D-6A3077E4BF8F@cs.purdue.edu> The standard doesn't even say that a pthread_t is a pointer. It might be an int, in which case 0 might be a valid pthread_t. On 26 Jul 2010, at 07:18, Jay K wrote: > > I don't see that the standard prohibits NULL from being a valid pthread_t. > ? > I happened upon this only due to a problem though: OpenBSD x86 4.6 -lX11 -static gives a broken pthreads. > > > We should add an extra boolean to this code, like, before: > > > VAR > holder: pthread_t; > inCritical := 0; > > PROCEDURE LockHeap () = > VAR self := pthread_self(); > BEGIN > IF pthread_equal(holder, self) = 0 THEN > WITH r = pthread_mutex_lock(heapMu) DO <*ASSERT r=0*> END; > holder := self; > END; > INC(inCritical); > END LockHeap; > > PROCEDURE UnlockHeap () = > BEGIN > <*ASSERT pthread_equal(holder, pthread_self()) # 0*> > DEC(inCritical); > IF inCritical = 0 THEN > holder := NIL; > WITH r = pthread_mutex_unlock(heapMu) DO <*ASSERT r=0*> END; > END; > END UnlockHeap; > > > > after: > > VAR > holder: pthread_t; > + holder_valid: BOOLEAN; > inCritical := 0; > > PROCEDURE LockHeap () = > VAR self := pthread_self(); > BEGIN > * IF NOT holder_valid OR pthread_equal(holder, self) = 0 THEN > WITH r = pthread_mutex_lock(heapMu) DO <*ASSERT r=0*> END; > holder := self; > + holder_valid := TRUE; > END; > INC(inCritical); > END LockHeap; > > PROCEDURE UnlockHeap () = > BEGIN > * <*ASSERT holder_valid AND pthread_equal(holder, pthread_self()) # 0*> > DEC(inCritical); > IF inCritical = 0 THEN > holder := NIL; > + holder_valid := FALSE > > WITH r = pthread_mutex_unlock(heapMu) DO <*ASSERT r=0*> END; > END; > END UnlockHeap; > > > I think so. > > > - Jay > > From jay.krell at cornell.edu Mon Jul 26 22:02:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 26 Jul 2010 20:02:44 +0000 Subject: [M3devel] pthread_self == null? In-Reply-To: <8599A6EE-9456-440F-A06D-6A3077E4BF8F@cs.purdue.edu> References: , <8599A6EE-9456-440F-A06D-6A3077E4BF8F@cs.purdue.edu> Message-ID: Agreed. So agreed with the approximate change? ?- Jay ---------------------------------------- > Subject: Re: [M3devel] pthread_self == null? > From: hosking at cs.purdue.edu > Date: Mon, 26 Jul 2010 15:00:29 -0400 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > The standard doesn't even say that a pthread_t is a pointer. > It might be an int, in which case 0 might be a valid pthread_t. > > On 26 Jul 2010, at 07:18, Jay K wrote: > > > > > I don't see that the standard prohibits NULL from being a valid pthread_t. > > ? > > I happened upon this only due to a problem though: OpenBSD x86 4.6 -lX11 -static gives a broken pthreads. > > > > > > We should add an extra boolean to this code, like, before: > > > > > > VAR > > holder: pthread_t; > > inCritical := 0; > > > > PROCEDURE LockHeap () = > > VAR self := pthread_self(); > > BEGIN > > IF pthread_equal(holder, self) = 0 THEN > > WITH r = pthread_mutex_lock(heapMu) DO <*ASSERT r=0*> END; > > holder := self; > > END; > > INC(inCritical); > > END LockHeap; > > > > PROCEDURE UnlockHeap () = > > BEGIN > > <*ASSERT pthread_equal(holder, pthread_self()) # 0*> > > DEC(inCritical); > > IF inCritical = 0 THEN > > holder := NIL; > > WITH r = pthread_mutex_unlock(heapMu) DO <*ASSERT r=0*> END; > > END; > > END UnlockHeap; > > > > > > > > after: > > > > VAR > > holder: pthread_t; > > + holder_valid: BOOLEAN; > > inCritical := 0; > > > > PROCEDURE LockHeap () = > > VAR self := pthread_self(); > > BEGIN > > * IF NOT holder_valid OR pthread_equal(holder, self) = 0 THEN > > WITH r = pthread_mutex_lock(heapMu) DO <*ASSERT r=0*> END; > > holder := self; > > + holder_valid := TRUE; > > END; > > INC(inCritical); > > END LockHeap; > > > > PROCEDURE UnlockHeap () = > > BEGIN > > * <*ASSERT holder_valid AND pthread_equal(holder, pthread_self()) # 0*> > > DEC(inCritical); > > IF inCritical = 0 THEN > > holder := NIL; > > + holder_valid := FALSE > > > > WITH r = pthread_mutex_unlock(heapMu) DO <*ASSERT r=0*> END; > > END; > > END UnlockHeap; > > > > > > I think so. > > > > > > - Jay > > > > > From wagner at elegosoft.com Tue Jul 27 11:26:02 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 27 Jul 2010 11:26:02 +0200 Subject: [M3devel] m3test failure on FreeBSD In-Reply-To: References: <20100724110817.uct40io1sw0ggg88@mail.elegosoft.com> Message-ID: <20100727112602.hp43lj5a4g8cc0kw@mail.elegosoft.com> Quoting Jay K : > Could it be open files subject to garbage collection? > Could we get more information reported at the time of the failure? See http://hudson.modula3.com:8080/job/cm3-current-test-m3tests-FreeBSD4/12/console The directory is listed directly before the RmRec operation fails. I still don't see anything suspicious :-( Olaf > ?- Jay > > > ---------------------------------------- >> Date: Sat, 24 Jul 2010 11:08:17 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] m3test failure on FreeBSD >> >> Has anybody any idea why this stubbornly fails on FreeBSD4 in current: >> >> >> http://hudson.modula3.com:8080/job/cm3-current-test-m3tests-FreeBSD4/10/console >> >> Obviously, the subdirectory cannot be removed by FSUtils.RmRec; error >> code 66 means it is not empty. >> >> I've written this small test program >> >> MODULE rmtest EXPORTS Main; >> >> IMPORT IO, FSUtils; >> >> CONST d = >> "/pub/users/hudson/workspace/cm3-current-test-m3tests-FreeBSD4/cm3/m3-sys/m3tests/src/p2/p240/FreeBSD4"; >> >> BEGIN >> TRY >> FSUtils.RmRec( d ); >> EXCEPT >> FSUtils.E(m) => IO.Put( m ); >> END; >> END rmtest. >> >> and of course it runs without a problem :-/ >> >> There is nothing suspicious in that directory after the test, at least >> I cannot see anything. I haven't noticed this problem on any other platform, >> and in the release branch the tests ran, too. >> >> 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 >> > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Wed Jul 28 11:35:31 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 28 Jul 2010 11:35:31 +0200 Subject: [M3devel] recent build failures in Hudson Message-ID: <20100728113531.ryhlvr680w8gk880@mail.elegosoft.com> Hi Jay, the recent commits seem to have negative effects on several build jobs. Unfortunately, the Hudson's CVS polling was broken for some days, so it may not be as easy as it should be to pin down the culprit(s). Can you have a look (as you've made of the changes): http://hudson.modula3.com:8080/job/cm3-current-build-AMD64_LINUX/lastBuild http://hudson.modula3.com:8080/job/cm3-current-build-PPC_LINUX/lastBuild http://hudson.modula3.com:8080/job/cm3-current-m3cc-AMD64_LINUX/lastBuild http://hudson.modula3.com:8080/job/cm3-current-m3cc-FreeBSD4/lastBuild/ http://hudson.modula3.com:8080/job/cm3-current-test-all-pkgs-FreeBSD4/lastBuild This has been broken since the start of regression for current: http://hudson.modula3.com:8080/job/cm3-current-build-SPARC32_LINUX/lastBuild Thanks in advance, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 28 12:04:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 28 Jul 2010 10:04:20 +0000 Subject: [M3devel] recent build failures in Hudson In-Reply-To: <20100728113531.ryhlvr680w8gk880@mail.elegosoft.com> References: <20100728113531.ryhlvr680w8gk880@mail.elegosoft.com> Message-ID: Mostly this is again just due to older config files. I thought the config files would have been updated by new. I'll fix it to not need them, for now. SPARC32_LINUX is different, unique to it, I'll get to it (I don't know the *exact* fix, but I understand somewhat the problem), but it isn't urgent. Thanks for the heads up. - Jay > Date: Wed, 28 Jul 2010 11:35:31 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: recent build failures in Hudson > > Hi Jay, > > the recent commits seem to have negative effects on several build jobs. > Unfortunately, the Hudson's CVS polling was broken for some days, so > it may not be as easy as it should be to pin down the culprit(s). > > Can you have a look (as you've made of the changes): > > http://hudson.modula3.com:8080/job/cm3-current-build-AMD64_LINUX/lastBuild > http://hudson.modula3.com:8080/job/cm3-current-build-PPC_LINUX/lastBuild > http://hudson.modula3.com:8080/job/cm3-current-m3cc-AMD64_LINUX/lastBuild > http://hudson.modula3.com:8080/job/cm3-current-m3cc-FreeBSD4/lastBuild/ > > http://hudson.modula3.com:8080/job/cm3-current-test-all-pkgs-FreeBSD4/lastBuild > > This has been broken since the start of regression for current: > > http://hudson.modula3.com:8080/job/cm3-current-build-SPARC32_LINUX/lastBuild > > Thanks in advance, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Jul 28 12:09:27 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 28 Jul 2010 12:09:27 +0200 Subject: [M3devel] recent build failures in Hudson In-Reply-To: References: <20100728113531.ryhlvr680w8gk880@mail.elegosoft.com> Message-ID: <20100728120927.ey5hfhm0xs0c8kg4@mail.elegosoft.com> Quoting Jay K : > Mostly this is again just due to older config files. > I thought the config files would have been updated by new. I'll fix > it to not need them, for now. > SPARC32_LINUX is different, unique to it, I'll get to it (I don't > know the *exact* fix, but > I understand somewhat the problem), but it isn't urgent. OK. I'm still trying to figure out the problem with CVS polling. It seems to work for some nodes, but Hudson keeps displaying its warning that something's wrong. Olaf > Thanks for the heads up. > - Jay > > >> Date: Wed, 28 Jul 2010 11:35:31 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: recent build failures in Hudson >> >> Hi Jay, >> >> the recent commits seem to have negative effects on several build jobs. >> Unfortunately, the Hudson's CVS polling was broken for some days, so >> it may not be as easy as it should be to pin down the culprit(s). >> >> Can you have a look (as you've made of the changes): >> >> http://hudson.modula3.com:8080/job/cm3-current-build-AMD64_LINUX/lastBuild >> http://hudson.modula3.com:8080/job/cm3-current-build-PPC_LINUX/lastBuild >> http://hudson.modula3.com:8080/job/cm3-current-m3cc-AMD64_LINUX/lastBuild >> http://hudson.modula3.com:8080/job/cm3-current-m3cc-FreeBSD4/lastBuild/ >> >> http://hudson.modula3.com:8080/job/cm3-current-test-all-pkgs-FreeBSD4/lastBuild >> >> This has been broken since the start of regression for current: >> >> http://hudson.modula3.com:8080/job/cm3-current-build-SPARC32_LINUX/lastBuild >> >> Thanks in advance, >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 jay.krell at cornell.edu Wed Jul 28 12:08:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 28 Jul 2010 10:08:02 +0000 Subject: [M3devel] recent build failures in Hudson In-Reply-To: References: <20100728113531.ryhlvr680w8gk880@mail.elegosoft.com>, Message-ID: --- building in FreeBSD4 --- ignoring ../src/m3overrides rm ./config.status rm ./.M3SHIP rm ./serdep.tmp rm ./cm3cg rm ./config.log rm ./Makefile rm ./m3make.args rm ./_m3.log rm -rf ./libcpp rm -rf ./build-i586-unknown-freebsd4 rm -rf ./gmp "/pub/users/hudson/workspace/cm3-current-m3cc-FreeBSD4/cm3/m3-sys/m3cc/src/m3makefile", line 369: quake runtime error: cannot remove recursively ./gmp: error traversing directory ./gmp/.libs: errno=2 This is wierd. I think we have good evidence now that RmRec has problems -- that is what is being used here and what is failing on FreeBSD4 tests that you have been asking about. This code in m3cc/src/m3makefile is attempting a clean build, by deleting outputs. For now I'll connect to the machines and manually delete the output directory. This RmRec stuff needs more investigation though. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: RE: recent build failures in Hudson Date: Wed, 28 Jul 2010 10:04:20 +0000 Mostly this is again just due to older config files. I thought the config files would have been updated by new. I'll fix it to not need them, for now. SPARC32_LINUX is different, unique to it, I'll get to it (I don't know the *exact* fix, but I understand somewhat the problem), but it isn't urgent. Thanks for the heads up. - Jay > Date: Wed, 28 Jul 2010 11:35:31 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: recent build failures in Hudson > > Hi Jay, > > the recent commits seem to have negative effects on several build jobs. > Unfortunately, the Hudson's CVS polling was broken for some days, so > it may not be as easy as it should be to pin down the culprit(s). > > Can you have a look (as you've made of the changes): > > http://hudson.modula3.com:8080/job/cm3-current-build-AMD64_LINUX/lastBuild > http://hudson.modula3.com:8080/job/cm3-current-build-PPC_LINUX/lastBuild > http://hudson.modula3.com:8080/job/cm3-current-m3cc-AMD64_LINUX/lastBuild > http://hudson.modula3.com:8080/job/cm3-current-m3cc-FreeBSD4/lastBuild/ > > http://hudson.modula3.com:8080/job/cm3-current-test-all-pkgs-FreeBSD4/lastBuild > > This has been broken since the start of regression for current: > > http://hudson.modula3.com:8080/job/cm3-current-build-SPARC32_LINUX/lastBuild > > Thanks in advance, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Jul 28 12:18:50 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 28 Jul 2010 12:18:50 +0200 Subject: [M3devel] recent build failures in Hudson In-Reply-To: References: <20100728113531.ryhlvr680w8gk880@mail.elegosoft.com>, Message-ID: <20100728121850.uqea76js00oosocg@mail.elegosoft.com> Quoting Jay K : > --- building in FreeBSD4 --- > > ignoring ../src/m3overrides > > rm ./config.status > rm ./.M3SHIP > rm ./serdep.tmp > rm ./cm3cg > rm ./config.log > rm ./Makefile > rm ./m3make.args > rm ./_m3.log > rm -rf ./libcpp > rm -rf ./build-i586-unknown-freebsd4 > rm -rf ./gmp > "/pub/users/hudson/workspace/cm3-current-m3cc-FreeBSD4/cm3/m3-sys/m3cc/src/m3makefile", line 369: quake runtime error: cannot remove recursively ./gmp: error traversing directory ./gmp/.libs: > errno=2 > > This is wierd. > I think we have good evidence now that RmRec has problems -- that is > what is being used here and what is failing on FreeBSD4 tests that > you have been asking about. > > This code in m3cc/src/m3makefile is attempting a clean build, by > deleting outputs. > For now I'll connect to the machines and manually delete the output > directory. > This RmRec stuff needs more investigation though. It didn't fail for FreeBSD before, i.e. on the release branch. And it's only on the i386 machine (running FreeBSD 6.4), not on my amd64 running FreeBSD 8.1. Any ideas what I could check again tonight? Any specific changes for this target? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 28 12:36:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 28 Jul 2010 10:36:32 +0000 Subject: [M3devel] recent build failures in Hudson In-Reply-To: <20100728121850.uqea76js00oosocg@mail.elegosoft.com> References: <20100728113531.ryhlvr680w8gk880@mail.elegosoft.com>, , , <20100728121850.uqea76js00oosocg@mail.elegosoft.com> Message-ID: Oops, to clarify, it isn't only on FreeBSD4, also http://hudson.modula3.com:8080/job/cm3-current-m3cc-AMD64_LINUX/lastBuild/console I might debug this is a bit first, before just deleting the directories. ?- Jay ---------------------------------------- > Date: Wed, 28 Jul 2010 12:18:50 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: recent build failures in Hudson > > Quoting Jay K : > > > --- building in FreeBSD4 --- > > > > ignoring ../src/m3overrides > > > > rm ./config.status > > rm ./.M3SHIP > > rm ./serdep.tmp > > rm ./cm3cg > > rm ./config.log > > rm ./Makefile > > rm ./m3make.args > > rm ./_m3.log > > rm -rf ./libcpp > > rm -rf ./build-i586-unknown-freebsd4 > > rm -rf ./gmp > > "/pub/users/hudson/workspace/cm3-current-m3cc-FreeBSD4/cm3/m3-sys/m3cc/src/m3makefile", line 369: quake runtime error: cannot remove recursively ./gmp: error traversing directory ./gmp/.libs: > > errno=2 > > > > This is wierd. > > I think we have good evidence now that RmRec has problems -- that is > > what is being used here and what is failing on FreeBSD4 tests that > > you have been asking about. > > > > This code in m3cc/src/m3makefile is attempting a clean build, by > > deleting outputs. > > For now I'll connect to the machines and manually delete the output > > directory. > > This RmRec stuff needs more investigation though. > > It didn't fail for FreeBSD before, i.e. on the release branch. > And it's only on the i386 machine (running FreeBSD 6.4), not on > my amd64 running FreeBSD 8.1. > > Any ideas what I could check again tonight? > Any specific changes for this target? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Wed Jul 28 13:13:55 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 28 Jul 2010 11:13:55 +0000 Subject: [M3devel] CVS polling related? Message-ID: CVS polling related? % Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... birch cvs: cvs update: New directory `m3-sys/m3cc/gcc/gcc/config/vax' -- ignored Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... birch cvs: error (1, 0) called recursively.? Second message was: Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... birch cvs: cvs update: New directory `m3-sys/m3cc/gcc/gcc/config/vax' -- ignored Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... birch cvs: error (1, 0) called recursively.? Second message was: Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... birch cvs: error (0, 0) called recursively.? Original message was: Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... birch cvs: cvs [update aborted]: received broken pipe signal Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... birch cvs: error (0, 0) called recursively.? Original message was: Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... birch cvs: cvs [update aborted]: received broken pipe signal Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... birch cvs: Aborting. Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... birch cvs: Aborting. From jay.krell at cornell.edu Wed Jul 28 13:19:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 28 Jul 2010 11:19:08 +0000 Subject: [M3devel] recent build failures in Hudson In-Reply-To: References: <20100728113531.ryhlvr680w8gk880@mail.elegosoft.com>, , , , , , <20100728121850.uqea76js00oosocg@mail.elegosoft.com>, Message-ID: I manually deleted the gmp directory on AMD64_LINUX and will get FreeBSD4. "Very soon" I'll trigger this code again -- but this time, sysutils might report more information before the error. I wonder if it has to do with the symlink in there, but the code looks correct -- it'd treat symlinks as a regular file. We'll see what the sysutils/RTIO reports when we get the failure next. The sysutils/RTIO code might mix up other code, e.g. diffs in the tests. Please ignore that for a bit unless it is too catastrophic -- ie. if building stuff is also broken by it. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > Date: Wed, 28 Jul 2010 10:36:32 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] recent build failures in Hudson > > > Oops, to clarify, it isn't only on FreeBSD4, also http://hudson.modula3.com:8080/job/cm3-current-m3cc-AMD64_LINUX/lastBuild/console > I might debug this is a bit first, before just deleting the directories. > > - Jay > > ---------------------------------------- > > Date: Wed, 28 Jul 2010 12:18:50 +0200 > > From: wagner at elegosoft.com > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: RE: recent build failures in Hudson > > > > Quoting Jay K : > > > > > --- building in FreeBSD4 --- > > > > > > ignoring ../src/m3overrides > > > > > > rm ./config.status > > > rm ./.M3SHIP > > > rm ./serdep.tmp > > > rm ./cm3cg > > > rm ./config.log > > > rm ./Makefile > > > rm ./m3make.args > > > rm ./_m3.log > > > rm -rf ./libcpp > > > rm -rf ./build-i586-unknown-freebsd4 > > > rm -rf ./gmp > > > "/pub/users/hudson/workspace/cm3-current-m3cc-FreeBSD4/cm3/m3-sys/m3cc/src/m3makefile", line 369: quake runtime error: cannot remove recursively ./gmp: error traversing directory ./gmp/.libs: > > > errno=2 > > > > > > This is wierd. > > > I think we have good evidence now that RmRec has problems -- that is > > > what is being used here and what is failing on FreeBSD4 tests that > > > you have been asking about. > > > > > > This code in m3cc/src/m3makefile is attempting a clean build, by > > > deleting outputs. > > > For now I'll connect to the machines and manually delete the output > > > directory. > > > This RmRec stuff needs more investigation though. > > > > It didn't fail for FreeBSD before, i.e. on the release branch. > > And it's only on the i386 machine (running FreeBSD 6.4), not on > > my amd64 running FreeBSD 8.1. > > > > Any ideas what I could check again tonight? > > Any specific changes for this target? > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Wed Jul 28 13:26:55 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 28 Jul 2010 13:26:55 +0200 Subject: [M3devel] CVS polling related? In-Reply-To: References: Message-ID: <20100728132655.e60y0jalckwkw08w@mail.elegosoft.com> Quoting Jay K : > CVS polling related? Probably. The 'cvs: error (1, 0) called recursively' are a known annoyance though. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=386153 http://savannah.nongnu.org/bugs/?26608 for details. Olaf > % > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > birch cvs: cvs update: New directory > `m3-sys/m3cc/gcc/gcc/config/vax' -- ignored > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > birch cvs: error (1, 0) called recursively.? Second message was: > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > birch cvs: cvs update: New directory > `m3-sys/m3cc/gcc/gcc/config/vax' -- ignored > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > birch cvs: error (1, 0) called recursively.? Second message was: > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > birch cvs: error (0, 0) called recursively.? Original message was: > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > birch cvs: cvs [update aborted]: received broken pipe signal > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > birch cvs: error (0, 0) called recursively.? Original message was: > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > birch cvs: cvs [update aborted]: received broken pipe signal > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > birch cvs: Aborting. > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > birch cvs: Aborting. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 28 13:38:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 28 Jul 2010 11:38:31 +0000 Subject: [M3devel] CVS polling related? In-Reply-To: <20100728132655.e60y0jalckwkw08w@mail.elegosoft.com> References: , <20100728132655.e60y0jalckwkw08w@mail.elegosoft.com> Message-ID: bug was reported in 2006. Presumably the fix is to not use CVS! What bothers me about CVS: 1) When there is a multi-file commit, there is no one link to follow to see the diffs. Hudson helps. But I want cvsweb to provide it. This is usually naturally fixed by any system with atomic commit as they identity the multi-file commit with one identifiers. 2) Everything is excruciatingly slow because everything goes to the network. 2a) I want cvs diff to not go to the network. 2b) I want a "cvs revert" command; what I frequently do is rename or delete my edits and then cvs upd to get the file back. In Perforce this is just p4 revert ... 3) I don't want it dropping CVS directories in every single directory. Just at the top of the tree, or preferably just one file or preferably in a parallel location; diffing two checkouts is made awful by this. I believe subversion has the same bug. Perforce does not. More cvs oddity, like, it was missing everything, and printed lots of odd stuff: http://hudson.modula3.com:8080/job/cm3-current-build-PPC_LINUX/25/consoleFull I'll poke at that some. I don't even see the workspace anywhere. ?- Jay ---------------------------------------- > Date: Wed, 28 Jul 2010 13:26:55 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: CVS polling related? > > Quoting Jay K : > > > CVS polling related? > > Probably. The 'cvs: error (1, 0) called recursively' are a > known annoyance though. See > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=386153 > http://savannah.nongnu.org/bugs/?26608 > > for details. > > Olaf > > > % > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > > birch cvs: cvs update: New directory > > `m3-sys/m3cc/gcc/gcc/config/vax' -- ignored > > > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > > birch cvs: error (1, 0) called recursively. Second message was: > > > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > > birch cvs: cvs update: New directory > > `m3-sys/m3cc/gcc/gcc/config/vax' -- ignored > > > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > > birch cvs: error (1, 0) called recursively. Second message was: > > > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > > birch cvs: error (0, 0) called recursively. Original message was: > > > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > > birch cvs: cvs [update aborted]: received broken pipe signal > > > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > > birch cvs: error (0, 0) called recursively. Original message was: > > > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > > birch cvs: cvs [update aborted]: received broken pipe signal > > > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > > birch cvs: Aborting. > > > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > > birch cvs: Aborting. > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Wed Jul 28 16:17:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 28 Jul 2010 14:17:24 +0000 Subject: [M3devel] The various hudson tasks Message-ID: Olaf, it is a bit odd that there are "m3cc" tasks and "other", but yet "other" does build m3cc. e.g.: http://hudson.modula3.com:8080/job/cm3-current-build-SPARC32_LINUX/35/console I seem to always be confused by what the tasks are. :( ?- Jay From wagner at elegosoft.com Wed Jul 28 16:49:21 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 28 Jul 2010 16:49:21 +0200 Subject: [M3devel] The various hudson tasks In-Reply-To: References: Message-ID: <20100728164921.2u9en41kgswgc88k@mail.elegosoft.com> Quoting Jay K : > Olaf, it is a bit odd that there are "m3cc" tasks and "other", but > yet "other" does build m3cc. > e.g.: > > http://hudson.modula3.com:8080/job/cm3-current-build-SPARC32_LINUX/35/console > > I seem to always be confused by what the tasks are. :( There is such a thing as a "standard CM3 system build and if necessary upgrade". This is included in the (1) cm3-current-build-* jobs for the CVS trunk. The build of the gcc backend has been extracted from that task, as it is based on different and differently licensed sources and takes quite a long time compared to M3 builds. The gcc backend builds are contained in the (2) cm3-current-m3cc-* jobs. The result of this job is used by other build jobs if available. There are two classes of test jobs: (3) cm3-current-test-m3tests-* just runs the m3tests package tests for the compiler. (4) cm3-current-test-all-pkgs-* is like a "build world"; i.e. it compiles all packages, compiles all associated test packages, and runs all associated tests if available. Apart from those there are groups of jobs for building distribution archives and for downloading and testing those. Any suggestions for a better setup are welcome. The existing setup has worked reasonably well in the past though. If anybody wants to play with the Hudson job and try something new, he is welcome if he promises not to bring down the existing Hudson tasks and other services. Hudson can be completely controlled via the HTTP GUI. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 28 17:23:29 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 28 Jul 2010 15:23:29 +0000 Subject: [M3devel] cvs warning about gcc/install,fixincludes directories Message-ID: http://hudson.modula3.com:8080/job/cm3-current-build-FreeBSD4/7/console P m3-sys/cm3/src/M3Build.m3 cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/INSTALL' cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/fixincludes' Some CVS weirdness here. I've resorted to deleting these directories on machines I can be hudson on. Then they come back and I think they are ok. i.e. not PPC_LINUX, FreeBSD4. We could also just delete these directories from cvs. - Jay From jay.krell at cornell.edu Wed Jul 28 17:32:23 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 28 Jul 2010 15:32:23 +0000 Subject: [M3devel] The various hudson tasks In-Reply-To: <20100728164921.2u9en41kgswgc88k@mail.elegosoft.com> References: , <20100728164921.2u9en41kgswgc88k@mail.elegosoft.com> Message-ID: m3cc is both in its own task and in the cm3 task. I don't understand why it is in both. This also causes the sources to be duplicated more. Given proper incrementality, the split shouldn't be needed. ? But ok. Splitting might resemble the future distribution form as well -- ie, one that is more like the old DEC SRC one. And I'm sure there are incrementality bugs, e.g. like when files are added/deleted/moved. ? Every time I've moved a file it has caused problems. I kind of think it should always "upgrade" for some definition of that. Always start with cm3/cm3cg/m3core/config files, and I guess libm3. Build up to cm3, skipping cm3cg, m3core, libm3. Copy/install cm3. Build cm3cg incrementally Clean everything but cm3cg. Too expensive? Build m3core up to cm3. Copy/install cm3. clean everything but cm3cg. Too expensive? Build everything. I can see that might be too expensive though. On the other hand, if the compiler changes, you really need to buid everything clean. As I assume incrementality doesn't take into account the compiler's timestamp, and if it did, it'd all be clean anyway. But I'm not keen on changing this stuff. It seems kind of difficult and very time consuming to get working, and extremely nice to have in almost any working form. Thanks, ?- Jay ---------------------------------------- > Date: Wed, 28 Jul 2010 16:49:21 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: The various hudson tasks > > Quoting Jay K : > > > Olaf, it is a bit odd that there are "m3cc" tasks and "other", but > > yet "other" does build m3cc. > > e.g.: > > > > http://hudson.modula3.com:8080/job/cm3-current-build-SPARC32_LINUX/35/console > > > > I seem to always be confused by what the tasks are. :( > > There is such a thing as a "standard CM3 system build and if necessary > upgrade". > This is included in the (1) cm3-current-build-* jobs for the CVS trunk. > > The build of the gcc backend has been extracted from that task, as > it is based on different and differently licensed sources and takes > quite a long time compared to M3 builds. > > The gcc backend builds are contained in the (2) cm3-current-m3cc-* jobs. > The result of this job is used by other build jobs if available. > > There are two classes of test jobs: > > (3) cm3-current-test-m3tests-* just runs the m3tests package tests > for the compiler. > > (4) cm3-current-test-all-pkgs-* is like a "build world"; i.e. it > compiles all packages, compiles all associated test packages, > and runs all associated tests if available. > > Apart from those there are groups of jobs for building distribution > archives and for downloading and testing those. > > Any suggestions for a better setup are welcome. > The existing setup has worked reasonably well in the past though. > > If anybody wants to play with the Hudson job and try something new, > he is welcome if he promises not to bring down the existing Hudson > tasks and other services. Hudson can be completely controlled via > the HTTP GUI. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Wed Jul 28 18:32:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 28 Jul 2010 16:32:10 +0000 Subject: [M3devel] FreeBSD atomics Message-ID: There seems to be a problem where the atomics are all failing on FreeBSD4. http://hudson.modula3.com:8080/job/cm3-current-test-all-pkgs-FreeBSD4/ I'll investigate. All the x86 config files share code: -march=i586. So it is surprising. Possibly in parse.c we should make it at least 586 independent of the command line. ?- Jay From jay.krell at cornell.edu Wed Jul 28 18:38:49 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 28 Jul 2010 16:38:49 +0000 Subject: [M3devel] openbsd/pthread/sigaltstack.. Message-ID: For the record..: Latest experiments: pthreads on OpenBSD hit some problems, assertion failures. I didn't debug. Maybe should. The sigaltstack strategy to portable user threads works. But it hangs on OpenBSD if you use -pthread. I didn't debug the hang. Maybe should. So it seems viable to be portable with sigaltstack and omit -pthread. But if you omit -pthread, then you run into e.g.: http://hudson.modula3.com:8080/job/cm3-current-test-all-pkgs-I386_OPENBSD/3/artifact/cm3-pkg-report-I386_OPENBSD.html#tr_m3-db-odbc /usr/local/lib/libiodbc.so.3.15: undefined reference to `pthread_mutex_unlock' /usr/local/lib/libiodbc.so.3.15: undefined reference to `pthread_self' /usr/local/lib/libiodbc.so.3.15: undefined reference to `pthread_mutex_lock' /usr/local/lib/libiodbc.so.3.15: undefined reference to `pthread_mutex_init' So the choice is unfortunate: much more portability with sigaltstack, or don't support packages such as odbc, or heck, just don't support OpenBSD, or debug the pthread problem (not the hang, though there is that, the problem of using actual pthreads). I'm also not keen on a solutiion that "randomly" stops working when user links with -pthread. It should work the same either way (at least if it links either way). For now I'm ok with jmpbuf hacking, but it disappointing. 5.8.6 used jmpbug hacking. ?- Jay From jay.krell at cornell.edu Wed Jul 28 18:47:56 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 28 Jul 2010 16:47:56 +0000 Subject: [M3devel] OpenBSD/powerpc Message-ID: There are very recent min/all distributions of openbsd/powerpc here: ? http://modula3.elegosoft.com/cm3/uploaded-archives/ I disabled dynamic linking of Modula-3 libraries, via config files, commited. Using -fPIC results in assembly errors all over the place. (Maybe I should try lowercase -fpic?) Not using -fPIC..I get a bunch of "unresolved symbol ''" at runtime -- like that, it reports the symbol name in single quotes and it is empty. Presumably this could be fixed, but presumably it doesn't matter much either. OpenBSD seems to like a pretty nice system (for a Posix system, other than MacOSX...), unless you try to get Modula-3 running on it. ?Then it seems kind of like the odd one out. Current OpenBSD is "stuck" with old gcc 3.x (I think even 2.x for some targets). It might be a good approach to import and patch their gcc fork, if anyone really wanted this to work. ? Or the hypothetical C-generating backend.. Given we already have 3 copies of gcc, I'm reluctant. Maybe when we move from 4.3 to 4.5 and delete one. Java doesn't seem to be available (a systematic problem across a certain range of systems), so Hudson won't be available so just these occasional unofficial releases I think will be it. (nice: 1) it isn't badly fractured like Linux; 2) comes with full source to the system like all *BSD; nice package system like all *BSD 3) easy to install, including you need merely one file locally and everything else can be installed over the net, very good device support.) ?- Jay From wagner at elegosoft.com Wed Jul 28 18:53:51 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 28 Jul 2010 18:53:51 +0200 Subject: [M3devel] The various hudson tasks In-Reply-To: References: , <20100728164921.2u9en41kgswgc88k@mail.elegosoft.com> Message-ID: <20100728185351.c50y1dwpwwcwcw8s@mail.elegosoft.com> Quoting Jay K : > m3cc is both in its own task and in the cm3 task. > I don't understand why it is in both. > This also causes the sources to be duplicated more. I don't follow you here. If the backend has already be built by the m3cc job, it should be used by the M3 builds. > Given proper incrementality, the split shouldn't be needed. ? > But ok. > Splitting might resemble the future distribution form as well -- ie, > one that is more like the old DEC SRC one. > And I'm sure there are incrementality bugs, e.g. like when files are > added/deleted/moved. > ? Every time I've moved a file it has caused problems. Yes. This is a known problem with the package-oriented builder. > I kind of think it should always "upgrade" for some definition of that. > Always start with cm3/cm3cg/m3core/config files, and I guess libm3. > Build up to cm3, skipping cm3cg, m3core, libm3. > Copy/install cm3. > Build cm3cg incrementally > Clean everything but cm3cg. Too expensive? Yes. > Build m3core up to cm3. > Copy/install cm3. > clean everything but cm3cg. Too expensive? > Build everything. > > I can see that might be too expensive though. > On the other hand, if the compiler changes, you really need to buid > everything clean. Yes. I'll be happy if I find an easy way to incorporate this into the existing tasks. If I only had more spare time... > As I assume incrementality doesn't take into account the compiler's > timestamp, and if it did, it'd all be clean anyway. > > But I'm not keen on changing this stuff. > It seems kind of difficult and very time consuming to get working, > and extremely nice to have in almost any working form. Thanks. I'll try to make incremental improvements as I find the time, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 28 19:40:26 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 28 Jul 2010 17:40:26 +0000 Subject: [M3devel] FreeBSD atomics In-Reply-To: References: Message-ID: I don't get it. Maybe old config files still?? It works for me: %./gcc 1.c -march=i586 %cat 1.c long long F1(long long* a, long long b) { ? return __sync_fetch_and_and_8(a, b); } int main() { } %uname -a FreeBSD fbsd4 4.11-RELEASE FreeBSD 4.11-RELEASE #0: Fri Jan 21 17:21:22 GMT 2005???? root at perseus.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC? i386 %./gcc -v Using built-in specs. Target: i386-unknown-freebsd4.11 Configured with: /home/jay/src/gcc-4.3.4/configure -disable-nls -prefix=/home/jay/gcc-4.3.4 Thread model: posix gcc version 4.3.4 (GCC) % I'll wait. Maybe the config files are old. Really this stuff should be the same across all I386 targets, unless maybe sometimes the "operating system" implies a minimum supported processor architecture. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: FreeBSD atomics > Date: Wed, 28 Jul 2010 16:32:10 +0000 > > > There seems to be a problem where the atomics are all failing on FreeBSD4. > > http://hudson.modula3.com:8080/job/cm3-current-test-all-pkgs-FreeBSD4/ > > I'll investigate. > > All the x86 config files share code: -march=i586. > So it is surprising. > Possibly in parse.c we should make it at least 586 independent of the command line. > > - Jay > > > > > From michael.anderson at elego.de Thu Jul 29 13:50:16 2010 From: michael.anderson at elego.de (Michael Anderson) Date: Thu, 29 Jul 2010 13:50:16 +0200 Subject: [M3devel] [elego Server Maintenance] Friday 30.07.2010 20:00 Message-ID: <20100729135016.0wuslzeyccs0cw4k@mail.elego.de> Hello, On Friday, July 30 at 8 PM CEST, we will perform scheduled maintenance on our servers, including the modula3 CVS server and Hudson CI server. Expected duration: 120 Min. We apologize for any inconvenience. - the elego Admins -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From rcolebur at SCIRES.COM Fri Jul 30 03:35:30 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Thu, 29 Jul 2010 21:35:30 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20100728142204.996F52474003@birch.elegosoft.com> References: <20100728142204.996F52474003@birch.elegosoft.com> Message-ID: Jay, before you go removing stuff on an assumption, maybe you should check with the group. I do know what this message means and it does have value. Regards, Randy ________________________________________ From: Jay Krell [jkrell at elego.de] Sent: Wednesday, July 28, 2010 12:22 PM To: m3commit at elegosoft.com Subject: [M3commit] CVS Update: cm3 CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 16:22:03 Modified files: cm3/m3-sys/cm3/src/: M3Build.m3 Log message: remove more of the code for: remove the "ignoring override" print out, I think few people know it means and fewer (nobody) finds it useful From jay.krell at cornell.edu Fri Jul 30 03:58:45 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 30 Jul 2010 01:58:45 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20100728142204.996F52474003@birch.elegosoft.com>, Message-ID: Randy, Without reading the code, what does it mean? My first guess was I believe wrong and based on reading the code I think it is even more pointless than I previously thought. It gets printed *all the time*, when using overrides. Look at any of the Hudson logs. It wouldn't be printed so much in the older way of doing things, where overrides were applied haphazardly and incompletely. Now that they are used fairly consistently/correctly, it always triggers. I hope to eventually replace the overrides mechanism -- if we just put files into a designated root directory, with the same structure as "the install", then "override" is just setting that directory, optionally prepopulating with an entire copy of the current install -- depending on if you want to build up from scratch or selectively override. You could use hardlinks to speed it up, as long as our copy is delete + copy and not just copy (sometimes a copy will share with the original link(s), sometimes it will unshare, depending on the open flags (I think) or if you first delete). And "install" becomes just moving the install root, if the new one is complete. What isn't easy though is "stitching together of multiple sparse pieces". overrides can do that today. $ORIGIN and the old full paths are both at odds with that though. If you make a complete, full paths are wrong. If you make an incomplete copy, $ORIGIN is wrong. "stitching together of multipl sparse pieces" is maybe the job of LD_LIBARY_PATH though, and makes no guarantees (since you might have duplicates and it becomes order-dependent). It might help if the "new" root is symlinks..except it doesn't -- no way for old files to point to new. General point noted. And if I fail, we have m3commit. Gotta run, - Jay > From: rcolebur at SCIRES.COM > To: m3devel at elegosoft.com > Date: Thu, 29 Jul 2010 21:35:30 -0400 > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Jay, before you go removing stuff on an assumption, maybe you should check with the group. I do know what this message means and it does have value. > Regards, > Randy > > ________________________________________ > From: Jay Krell [jkrell at elego.de] > Sent: Wednesday, July 28, 2010 12:22 PM > To: m3commit at elegosoft.com > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/07/28 16:22:03 > > Modified files: > cm3/m3-sys/cm3/src/: M3Build.m3 > > Log message: > remove more of the code for: remove the "ignoring override" print out, I think few people know it means and fewer (nobody) finds it useful -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 30 15:20:40 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 30 Jul 2010 13:20:40 +0000 Subject: [M3devel] rmrec problems Message-ID: Olaf, I suggest that maybe deleting while enumerating is undefined? We should try enumerating first, and then deleting, at least on a per-directory basis, not recursively. ? Even though that is bad in terms of working set -- small constant to unbounded. As well, recursion on the machine stack that is bounded by user input, is to be avoided. User can provide arbitrarily deep input and you blow the stack. Better to use a queue or stack data structure, add elements, and loop while not empty. I can try something here within a week, we can see if it helps. Stopgap might be to double up the rmrec calls and see what happens. Maybe delete while enumerate works under some conditions. Maybe I'm just randomly guessing (yes) and am way off (unknown). ?- Jay From jay.krell at cornell.edu Fri Jul 30 15:23:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 30 Jul 2010 13:23:43 +0000 Subject: [M3devel] rmrec problems In-Reply-To: References: Message-ID: Better theory: readdir uses globals. Suggest readdir_r... ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Subject: rmrec problems > Date: Fri, 30 Jul 2010 13:20:40 +0000 > > > Olaf, I suggest that maybe deleting while enumerating is undefined? > We should try enumerating first, and then deleting, at least on a per-directory basis, not recursively. > Even though that is bad in terms of working set -- small constant to unbounded. > > > As well, recursion on the machine stack that is bounded by user input, is to be avoided. > User can provide arbitrarily deep input and you blow the stack. > Better to use a queue or stack data structure, add elements, and loop while not empty. > > > I can try something here within a week, we can see if it helps. > > > Stopgap might be to double up the rmrec calls and see what happens. > Maybe delete while enumerate works under some conditions. > > > Maybe I'm just randomly guessing (yes) and am way off (unknown). > > - Jay > > > > > From hendrik at topoi.pooq.com Fri Jul 30 23:50:51 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 30 Jul 2010 17:50:51 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: Message-ID: <20100730215051.GA23133@topoi.pooq.com> On Fri, Jul 30, 2010 at 01:58:45AM +0000, Jay K wrote: > > Randy, Without reading the code, what does it mean? > > My first guess was I believe wrong and based on reading the code I think it is even more pointless than I previously thought. > > It gets printed *all the time*, when using overrides. Look at any of the Hudson logs. > > It wouldn't be printed so much in the older way of doing things, where overrides were applied haphazardly and incompletely. Now that they are used fairly consistently/correctly, it always triggers. I hope to eventually replace the overrides mechanism -- if we just put files into a designated root directory, with the same structure as "the install", then "override" is just setting that directory, optionally prepopulating with an entire copy of the current install -- depending on if you want to build up from scratch or selectively override. You could use hardlinks to speed it up, as long as our copy is delete + copy and not just copy (sometimes a copy will share with the original link(s), sometimes it will unshare, depending on the open flags (I think) or if you first delete). And "install" becomes just moving the install root, if the new one is complete. I remember using an override somewhere ... but I don't remember where or why now. But I'd worry if this change broke something. -- hendrik From jay.krell at cornell.edu Thu Jul 1 11:23:01 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 1 Jul 2010 09:23:01 +0000 Subject: [M3devel] m3tests/cmp_fie vs. compare_file Message-ID: I find it confusing that m3-sys/m3tests/src/m3makefile contains both cmp_file and compare_file (unless one was a thin wrapper over the other, not the case) Olaf you added cmp_file in http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3tests/src/m3makefile.diff?r1=1.3;r2=1.4. Presumably they can be merged into one function? ?- Jay From wagner at elegosoft.com Thu Jul 1 11:38:53 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 01 Jul 2010 11:38:53 +0200 Subject: [M3devel] m3tests/cmp_fie vs. compare_file In-Reply-To: References: Message-ID: <20100701113853.cn7e82bwso48oc0s@mail.elegosoft.com> Quoting Jay K : > > I find it confusing that m3-sys/m3tests/src/m3makefile contains both > cmp_file and compare_file (unless one was a thin wrapper over the > other, not the case) > Olaf you added cmp_file in > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3tests/src/m3makefile.diff?r1=1.3;r2=1.4. > > Presumably they can be merged into one function? compare_file() writes output and doesn't return anything meaningful (it's a procedure), while cmp_file is a boolean state function that doesn't write anything to stdout. The first could be based on the second. Of course you can find a common signature, but then you'll have to change all occurences and add a use case parameter, which isn't nice, too. Perhaps you can suggest better names? Please do not change the semantics (i.e. the use of @cmp, for example) though, as that might break the regression tests. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Jul 1 12:26:15 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 1 Jul 2010 10:26:15 +0000 Subject: [M3devel] m3tests/cmp_fie vs. compare_file In-Reply-To: <20100701113853.cn7e82bwso48oc0s@mail.elegosoft.com> References: , <20100701113853.cn7e82bwso48oc0s@mail.elegosoft.com> Message-ID: Understood. They do a lot of the same but merging requires both a decent top-down understanding of the semantics to plan ahead slightly and then a close bottom-up line by line read to merge and preserve meaning. (I seem to be speaking like an MBA this evening. Don't worry. :) ) I don't have the energy for it at the moment. I am extending this area though, the stuff for recording and later comparing assembly output. Background: Fixing more configure -enable-checking seems to regress code /slightly/, in bit insert/extract. So I haven't commited said fix. So I'm going to try the bitfield refs again (that Tony had done). That might both fix and improve the code. Once they are merged the result can probably keep the name compare_file. Thanks for the overview. I'll try to look into this eventually and I'll try not to look into it too soon, before other things that are probably more useful (and more interesting and fun). Btw, there's stuff called "jux" in the code here. Is it rude to request sticking to English? Thanks. ?- Jay ---------------------------------------- > Date: Thu, 1 Jul 2010 11:38:53 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] m3tests/cmp_fie vs. compare_file > > Quoting Jay K : > > > > > I find it confusing that m3-sys/m3tests/src/m3makefile contains both > > cmp_file and compare_file (unless one was a thin wrapper over the > > other, not the case) > > Olaf you added cmp_file in > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3tests/src/m3makefile.diff?r1=1.3;r2=1.4. > > > > Presumably they can be merged into one function? > > compare_file() writes output and doesn't return anything meaningful > (it's a procedure), while cmp_file is a boolean state function that > doesn't write anything to stdout. > > The first could be based on the second. > > Of course you can find a common signature, but then you'll have to > change all occurences and add a use case parameter, which isn't nice, > too. > > Perhaps you can suggest better names? > > Please do not change the semantics (i.e. the use of @cmp, for example) > though, as that might break the regression tests. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Thu Jul 1 16:45:18 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 1 Jul 2010 14:45:18 +0000 Subject: [M3devel] add/subtract in Quake Message-ID: Folks might find this amusing or useful. I actually think I'm going to use it, just for the numbers 0-64.It implements addition and subtraction for a fixed range, here 0-9999Global variables are only used for initialization.Thereafter, just global constants (no enforcement of that, but I think it could be done by having initialization return them). Approach is that adding 1 to a single digit can be done with a small map.Adding 1 to multiple digits can be done using multiple variables and checking for "wraparound" to 0 (the table maps 9 to 0).You count up to 9999, filling in an Add1 and Sub1 hash table as you go up. I don't think quake has an appropriate looping mechanism, so counting up to 9999 is done recursively.Then Add and Sub are implemented recursively like Add1{Add(a, Sub1(b)}. local Add1 = { }local Sub1 = { } local counter0 = 0local counter1 = 0local counter2 = 0local counter3 = 0 local proc Increment() is local inc = { 0:1,1:2,2:3,3:4,4:5, 5:6,6:7,7:8,8:9,9:0 } counter0 = inc{counter0} if equal(counter0, 0) counter1 = inc{counter1} if equal(counter1, 0) counter2 = inc{counter2} if equal(counter2, 0) counter3 = inc{counter3} end end end local c = "" foreach d in [counter3, counter2, counter1, counter0] if not equal(d, 0) or not equal(c, "") c = c & d end end return cend proc InitMath_F1(a, b) is if equal(a, "9999") return end Add1{a} = b Sub1{b} = a InitMath_F1(b, Increment())end proc InitMath() is counter0 = 0 counter1 = 0 counter2 = 0 counter3 = 0 InitMath_F1(0, Increment())end proc Add(a, b) is if equal(a, 0) return b end if equal(b, 0) return a end if equal(a, 1) return Add1{b} end if equal(b, 1) return Add1{a} end return Add1{Add(a, Sub1{b})}end proc Sub(a, b) is if equal(a, 0) return b end if equal(b, 0) return a end if equal(a, 1) return Sub1{b} end if equal(b, 1) return Sub1{a} end return Sub1{Sub(a, Sub1{b})}end InitMath()write("99 - 40 is " & Sub(99, 40), CR)write("6 - 4 is " & Sub(6, 4), CR)write("3 + 2 is " & Add(2, 3), CR) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Thu Jul 1 22:33:13 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 01 Jul 2010 15:33:13 -0500 Subject: [M3devel] Another CVS question: duplicate local copies Message-ID: <4C2CFB89.4000406@lcwb.coop> I understand a release tag is "sticky", meaning once I specify it in a CVS command, the value I gave becomes internal state and will continue to be used in subsequent commands, until I do something explicitly to change it. Where is this state recorded? I particular, is it somewhere in the repository, or on my local disk? The motivation is this: I am now connected through a satellite internet service that has high latency, slow speed, and worst, a restrictive quota on bit volumes. I can scarcely afford the data transfer of frequent switches between the head and release branches. I want to keep a local copy of each. Can I do this? I made a complete copy of my local distribution, currently of the head. In the copy, I did "cvs -z9 -q update -r release_branch_cm3_5_8". So if I do an update in the future from inside the original directory, will I get head versions, and if I do it in my copy that is now the release branch, will I get updates to the release branch? Or do I have to specify tags carefully every time, no matter where I am? Or is this feasible at all? From wagner at elegosoft.com Thu Jul 1 22:51:37 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 01 Jul 2010 22:51:37 +0200 Subject: [M3devel] Another CVS question: duplicate local copies In-Reply-To: <4C2CFB89.4000406@lcwb.coop> References: <4C2CFB89.4000406@lcwb.coop> Message-ID: <20100701225137.lrzkgtfmswgcokcs@mail.elegosoft.com> Quoting "Rodney M. Bates" : > I understand a release tag is "sticky", meaning once I specify it in a > CVS command, the value I gave becomes internal state and will continue > to be used in subsequent commands, until I do something explicitly to > change it. Where is this state recorded? I particular, is it somewhere > in the repository, or on my local disk? It's in the CVS/Entries files; there's a column for sticky tags. It looks like this: % cat m3-libs/binIO/src/CVS/Entries /BinIO.i3/1.1.1.1/Sat Jan 5 16:32:08 2002//Trelease_branch_cm3_5_8 /BinIO.m3/1.1.1.1/Sat Jan 5 16:32:09 2002//Trelease_branch_cm3_5_8 /FastBinIO.i3/1.1.1.1/Sat Jan 5 16:32:09 2002//Trelease_branch_cm3_5_8 /FastBinIO.m3/1.1.1.1/Sat Jan 5 16:32:10 2002//Trelease_branch_cm3_5_8 /m3makefile/1.1.1.1/Sat Mar 27 11:42:57 2004//Trelease_branch_cm3_5_8 /m3overrides/1.2/Sat Jul 25 09:33:14 2009//Trelease_branch_cm3_5_8 D The repository does not know about any workspaces. > The motivation is this: I am now connected through a satellite internet > service that has high latency, slow speed, and worst, a restrictive > quota on bit volumes. I can scarcely afford the data transfer of > frequent switches between the head and release branches. I want to > keep a local copy of each. Can I do this? You can have as many CVS workspaces with different branches and versions as you like. > I made a complete copy of my local distribution, currently of the > head. In the copy, I did "cvs -z9 -q update -r release_branch_cm3_5_8". > So if I do an update in the future from inside the original directory, > will I get head versions, and if I do it in my copy that is now the > release branch, will I get updates to the release branch? Or do I > have to specify tags carefully every time, no matter where I am? > Or is this feasible at all? That should be no problem with CVS. Just be careful not to mess up the CVS directories manually. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Fri Jul 2 09:34:19 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 02 Jul 2010 09:34:19 +0200 Subject: [M3devel] add/subtract in Quake In-Reply-To: References: Message-ID: <20100702093419.0hvbuzj2ysocsk4s@mail.elegosoft.com> Shouldn't we rather define some standard quake functions and implement them in M3, like add, substract, multiply, div, mod? Probably working on TEXT of course... or even introduce a new quake type for integers? I haven't really thought about that, but I've missed integer arithmetics several times in the past, too. Olaf Quoting Jay K : > Folks might find this amusing or useful. I actually think I'm > going to use it, just for the numbers 0-64.It implements addition > and subtraction for a fixed range, here 0-9999Global variables are > only used for initialization.Thereafter, just global constants (no > enforcement of that, but I think it could be done by having > initialization return them). > Approach is that adding 1 to a single digit can be done with a small > map.Adding 1 to multiple digits can be done using multiple > variables and checking for "wraparound" to 0 (the table maps 9 to > 0).You count up to 9999, filling in an Add1 and Sub1 hash table as > you go up. I don't think quake has an appropriate looping > mechanism, so counting up to 9999 is done recursively.Then Add and > Sub are implemented recursively like Add1{Add(a, Sub1(b)}. > > local Add1 = { }local Sub1 = { } > > local counter0 = 0local counter1 = 0local counter2 = 0local counter3 = 0 > > local proc Increment() is local inc = { 0:1,1:2,2:3,3:4,4:5, > 5:6,6:7,7:8,8:9,9:0 } counter0 = inc{counter0} if > equal(counter0, 0) counter1 = inc{counter1} if equal(counter1, > 0) counter2 = inc{counter2} if equal(counter2, 0) > counter3 = inc{counter3} end end end local c = "" foreach > d in [counter3, counter2, counter1, counter0] if not equal(d, 0) > or not equal(c, "") c = c & d end end return cend > > proc InitMath_F1(a, b) is if equal(a, "9999") return end > Add1{a} = b Sub1{b} = a InitMath_F1(b, Increment())end > proc InitMath() is counter0 = 0 counter1 = 0 counter2 = 0 > counter3 = 0 InitMath_F1(0, Increment())end > > proc Add(a, b) is if equal(a, 0) return b end if equal(b, 0) > return a end if equal(a, 1) return Add1{b} end if equal(b, 1) > return Add1{a} end return Add1{Add(a, Sub1{b})}end > > proc Sub(a, b) is if equal(a, 0) return b end if equal(b, 0) > return a end if equal(a, 1) return Sub1{b} end if equal(b, 1) > return Sub1{a} end return Sub1{Sub(a, Sub1{b})}end > > InitMath()write("99 - 40 is " & Sub(99, 40), CR)write("6 - 4 is " & > Sub(6, 4), CR)write("3 + 2 is " & Add(2, 3), CR) -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Jul 2 10:10:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 2 Jul 2010 08:10:10 +0000 Subject: [M3devel] ppc_linux hanging Message-ID: Alas, PPC_LINUX is very prone to hang on head. ?e.g. compiling m3front. ?It doesn't hang with @M3nogc. ?The stack at the time just shows junk, no symbols at all. ? and info threads shows nothing, maybe I mistyped it. I'll try to figure it out. The biggest recent change I think is removing volatile so I'll start by trying with that put back. Also I use Darwin more lately, which has its own thread suspension code. Could be something broke the others. Later, ?- Jay From jay.krell at cornell.edu Fri Jul 2 10:20:26 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 2 Jul 2010 08:20:26 +0000 Subject: [M3devel] add/subtract in Quake In-Reply-To: <20100702093419.0hvbuzj2ysocsk4s@mail.elegosoft.com> References: , <20100702093419.0hvbuzj2ysocsk4s@mail.elegosoft.com> Message-ID: If someone can specify and/or implement, yes. In the meantime I'll proceed without. It appears many newlines were lost from my email rendering it unreadable. Arg. Then we maybe need for loops. And comparison and bitwise operation and shifting -- consider the case of combinatorial test generation...you nested for loop various integers from 0 to 1 and then shift them each a different amount, oring them together to get a test number... Or you loop from 0 to 2^n and you check for a bit set to decide which variation of that variable to generate. Or maybe we need a different scripting language. Python is very good. A friend is telling me about Lua. ? Need to check about portability to OpenBSD/mips64..never quite got Python working there, but close.. :) Or maybe we should use makefile.m3 that gets compiled on-demand or something. ? Really. Maybe. makefile.m3 around m3-sys would have to limit itself to working with old compiler/m3core/libm3. You know.."compiled languages" ought to compete better with "scripting languages".. the distinction belies any technical classification, to me. What is a "scripting language" vs. others? They are often interprted. But not always. Quake is acually compiled in a way. Often dynamically typed. But not always. Often lack tools for turning them into "executables". But not always. Often are slow. But not always. Usually are "safe". Always? ? But so sometimes are others: Modula-3, C#, Java, etc. ?- Jay ---------------------------------------- > Date: Fri, 2 Jul 2010 09:34:19 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] add/subtract in Quake > > Shouldn't we rather define some standard quake functions and implement > them in M3, like add, substract, multiply, div, mod? > Probably working on TEXT of course... or even introduce a new > quake type for integers? > > I haven't really thought about that, but I've missed integer arithmetics > several times in the past, too. > > Olaf > > Quoting Jay K : > > > Folks might find this amusing or useful. I actually think I'm > > going to use it, just for the numbers 0-64.It implements addition > > and subtraction for a fixed range, here 0-9999Global variables are > > only used for initialization.Thereafter, just global constants (no > > enforcement of that, but I think it could be done by having > > initialization return them). > > Approach is that adding 1 to a single digit can be done with a small > > map.Adding 1 to multiple digits can be done using multiple > > variables and checking for "wraparound" to 0 (the table maps 9 to > > 0).You count up to 9999, filling in an Add1 and Sub1 hash table as > > you go up. I don't think quake has an appropriate looping > > mechanism, so counting up to 9999 is done recursively.Then Add and > > Sub are implemented recursively like Add1{Add(a, Sub1(b)}. > > > > local Add1 = { }local Sub1 = { } > > > > local counter0 = 0local counter1 = 0local counter2 = 0local counter3 = 0 > > > > local proc Increment() is local inc = { 0:1,1:2,2:3,3:4,4:5, > > 5:6,6:7,7:8,8:9,9:0 } counter0 = inc{counter0} if > > equal(counter0, 0) counter1 = inc{counter1} if equal(counter1, > > 0) counter2 = inc{counter2} if equal(counter2, 0) > > counter3 = inc{counter3} end end end local c = "" foreach > > d in [counter3, counter2, counter1, counter0] if not equal(d, 0) > > or not equal(c, "") c = c & d end end return cend > > > > proc InitMath_F1(a, b) is if equal(a, "9999") return end > > Add1{a} = b Sub1{b} = a InitMath_F1(b, Increment())end > > proc InitMath() is counter0 = 0 counter1 = 0 counter2 = 0 > > counter3 = 0 InitMath_F1(0, Increment())end > > > > proc Add(a, b) is if equal(a, 0) return b end if equal(b, 0) > > return a end if equal(a, 1) return Add1{b} end if equal(b, 1) > > return Add1{a} end return Add1{Add(a, Sub1{b})}end > > > > proc Sub(a, b) is if equal(a, 0) return b end if equal(b, 0) > > return a end if equal(a, 1) return Sub1{b} end if equal(b, 1) > > return Sub1{a} end return Sub1{Sub(a, Sub1{b})}end > > > > InitMath()write("99 - 40 is " & Sub(99, 40), CR)write("6 - 4 is " & > > Sub(6, 4), CR)write("3 + 2 is " & Add(2, 3), CR) > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Fri Jul 2 12:35:09 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 2 Jul 2010 10:35:09 +0000 Subject: [M3devel] object oriented programming in Quake Message-ID: next in the series of advanced programming in quake... Perl/Python-esque "objects" (aka hash tables) ?- Quake doesn't have lexical scoping. Or therefore closures. ? ??? So you have to pass the this pointer manually. ? - Quake does allow naming a procedure to act like taking its address; it can be stored and called later. ?????? This is really the only thing that helps the situation. ?- I wasn't able to write "void member functions" aka "methods that don't return anything", thus the "a = " ?- There is no private/protected. ?- Similar reduction in making typos static errors: ie: a{"foo"} = 1 vs. a{"food"} = 1, whichever you meant, no matter, ?? you get what you typed, no errors. ? - No "inheritance" demonstrated but er you could probably say there is JavaScript-esque prototyping -- just assign from another object (hash table) proc NewCounter() is ? local proc inc(this) is ??? this{"c"} = Add(this{"c"}, 1) ??? return this ? end ? local proc get(this) is ??? return this{"c"} ? end ? local this = { } ? this{"c"} = 0 ? this{"inc"} = inc ? this{"get"} = get ? return this end local c1 = NewCounter() local c2 = NewCounter() write("c1 is " & c1{"get"}(c1), CR) a = c1{"inc"}(c1) write("c1 is " & c1{"get"}(c1), CR) a = c1{"inc"}(c1) a = c1{"inc"}(c1) write("c1 is " & c1{"get"}(c1), CR) write("c2 is " & c2{"get"}(c2), CR) a = c2{"inc"}(c2) a = c2{"inc"}(c2) a = c2{"inc"}(c2) write("c2 is " & c2{"get"}(c2), CR) ?- Jay From jay.krell at cornell.edu Fri Jul 2 13:04:54 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 2 Jul 2010 11:04:54 +0000 Subject: [M3devel] looping over range of integers in quake Message-ID: Given the lack of lexical scoping and closures, the second form is preferred. ? Actually there is lexical scoping it seems, but not closures. Maybe more on that later. proc For(start, endd, body) is ? if equal(start, endd & "") ??? return ? end ? body(start) ? For(Add(start, 1), endd, body) end For(0, 10, write) write(CR) proc ToString(a) is ? return a & "" end proc Range(start, endd) is % I thought local a good idea here but no. ? proc Helper(result, start, endd) is ??? if equal(start, endd) ????? return result ??? end ??? result += start ??? return Helper(result, Add(start, 1), endd) ? end ? return Helper([ ], ToString(start), ToString(endd)) end foreach i in Range(0, 10) ? write(i, CR) end From jay.krell at cornell.edu Sat Jul 3 12:37:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 3 Jul 2010 10:37:36 +0000 Subject: [M3devel] ppc_linux hanging In-Reply-To: References: Message-ID: Alas, good news, bad news, restoring volatile on every load/store seems to fix this. I wasn't even optimizing. Tony any ideas? I386_LINUX is ok. AMD64_DARWIN is ok. SOLgnu is ok, but that doesn't count. I left volatile on there, was worried for some reason about interaction with stack walker, I forget. So far the debugger is being very uncooperative, can't set any breakpoints..it works for C. Aha.. gcc -gstabs+ -fPIC -pie 2.c (gdb) break main Breakpoint 1 at 0x658: file 2.c, line 3. (gdb) run Starting program: /home/jay/a.out Warning: Cannot insert breakpoint 1. Error accessing memory address 0x658: Input/output error. (gdb) q The program is running.? Exit anyway? (y or n) y jay at plin:~$ gcc -gstabs+ -fPIC 2.c jay at plin:~$ gdb ./a.out GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.? Type "show copying" and "show warranty" for details. This GDB was configured as "powerpc-linux-gnu"... (gdb) break main Breakpoint 1 at 0x10000448: file 2.c, line 3. (gdb) run Starting program: /home/jay/a.out Breakpoint 1, main () at 2.c:3 3??? } So lame.. ? - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: ppc_linux hanging > Date: Fri, 2 Jul 2010 08:10:10 +0000 > > > Alas, PPC_LINUX is very prone to hang on head. > e.g. compiling m3front. > It doesn't hang with @M3nogc. > The stack at the time just shows junk, no symbols at all. > and info threads shows nothing, maybe I mistyped it. > > > I'll try to figure it out. > The biggest recent change I think is removing volatile so I'll start > by trying with that put back. > > > Also I use Darwin more lately, which has its own thread suspension code. > Could be something broke the others. > > > Later, > - Jay > > From jay.krell at cornell.edu Sat Jul 3 13:21:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 3 Jul 2010 11:21:44 +0000 Subject: [M3devel] quake continue Message-ID: It'd be very nice if quake had "continue". I find myself having to indent loops further and further and further when continue is really want I want. You can fake it by moving code into a function and using return but... ?- Jay From jay.krell at cornell.edu Sat Jul 3 17:13:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 3 Jul 2010 15:13:20 +0000 Subject: [M3devel] Could not find a legal alignment for the packed type? Message-ID: "../I386_LINUX/bitfield.m3", line 16078: Could not find a legal alignment for the packed type. <*NOWARN*>TYPE BitField_offset63_count1 = RECORD ?offset:BITS 63 FOR? [0L .. Long.RightShift(Long.Not(0L), 1)]; ?value:BITS 1 FOR? [0L .. Long.RightShift(Long.Not(0L), 63)]; END; ? Does that make sense? Obviously? the record contains one LONGINT broken up into a 1 bit field and a 63 bit field. I'll try removing the "BITS FOR". ? - Jay From rodney_bates at lcwb.coop Sat Jul 3 18:09:27 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 03 Jul 2010 11:09:27 -0500 Subject: [M3devel] Another CVS question: duplicate local copies In-Reply-To: <20100701225137.lrzkgtfmswgcokcs@mail.elegosoft.com> References: <4C2CFB89.4000406@lcwb.coop> <20100701225137.lrzkgtfmswgcokcs@mail.elegosoft.com> Message-ID: <4C2F60B7.3070903@lcwb.coop> OK, thanks. I had since noticed the tags in .../CVS/Entries files. It seems to be working, after I remembered to add -dAP to my cvs update command. Olaf Wagner wrote: > Quoting "Rodney M. Bates" : > >> I understand a release tag is "sticky", meaning once I specify it in a >> CVS command, the value I gave becomes internal state and will continue >> to be used in subsequent commands, until I do something explicitly to >> change it. Where is this state recorded? I particular, is it somewhere >> in the repository, or on my local disk? > > It's in the CVS/Entries files; there's a column for sticky tags. > It looks like this: > > % cat m3-libs/binIO/src/CVS/Entries > /BinIO.i3/1.1.1.1/Sat Jan 5 16:32:08 2002//Trelease_branch_cm3_5_8 > /BinIO.m3/1.1.1.1/Sat Jan 5 16:32:09 2002//Trelease_branch_cm3_5_8 > /FastBinIO.i3/1.1.1.1/Sat Jan 5 16:32:09 2002//Trelease_branch_cm3_5_8 > /FastBinIO.m3/1.1.1.1/Sat Jan 5 16:32:10 2002//Trelease_branch_cm3_5_8 > /m3makefile/1.1.1.1/Sat Mar 27 11:42:57 2004//Trelease_branch_cm3_5_8 > /m3overrides/1.2/Sat Jul 25 09:33:14 2009//Trelease_branch_cm3_5_8 > D > > The repository does not know about any workspaces. > >> The motivation is this: I am now connected through a satellite internet >> service that has high latency, slow speed, and worst, a restrictive >> quota on bit volumes. I can scarcely afford the data transfer of >> frequent switches between the head and release branches. I want to >> keep a local copy of each. Can I do this? > > You can have as many CVS workspaces with different branches and > versions as you like. > >> I made a complete copy of my local distribution, currently of the >> head. In the copy, I did "cvs -z9 -q update -r release_branch_cm3_5_8". >> So if I do an update in the future from inside the original directory, >> will I get head versions, and if I do it in my copy that is now the >> release branch, will I get updates to the release branch? Or do I >> have to specify tags carefully every time, no matter where I am? >> Or is this feasible at all? > > That should be no problem with CVS. > Just be careful not to mess up the CVS directories manually. > > Olaf From jay.krell at cornell.edu Sun Jul 4 02:03:05 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 00:03:05 +0000 Subject: [M3devel] "exact codegen" testing Message-ID: m3-sys/m3tests now has infrastructure for "exact codegen" testing. An interesting thing I just realized, is that it is, well, it is trivial. And it is applicable to any test. If the "expected" directory exists, then it gets compared. ? Now, probably in such cases you want to "trim" the code some, such as by turning off or reducing symbols. This can be used for cross builds -- since assembly is what cross builds produce on the host, and assembly is what this looks at. Probably then what is needed is a script to loop through all architectures and update whichever tests have checked in assembly. Or a two step, produce them all, present diff to human, update them all. There is a temporary problem right now that I made the "c" tests run. They include one with an infinite loop. I'll undo that now. "p" tests are now subtely redefined. Previously: Programs whose output is interesting or for which running them is interesting. Now: "code" tests that are safe to run (ie. they need not do anything), i.e should always be built and run, even if running them doesn't do anything interesting, building them does. I'll move c135 to be a "p" test. c135 should probably be expanded further. Specifically with the goal of covering every single M3CG_Op and every boolean parameter combination thereof. ? i.e. extract with sign extend both true and false, though for example extract_n(sign_extend=true) is never ? used by the frontend. Iterating through integer values can't be done for all values, but booleans can be. There's still a fair amount missing. Though other tests and building the system itself should provide much/all of it. ?- Jay From hosking at cs.purdue.edu Sun Jul 4 02:29:00 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 3 Jul 2010 20:29:00 -0400 Subject: [M3devel] ppc_linux hanging In-Reply-To: References: Message-ID: <9B486681-F277-414E-8A67-F2A63E2BC4CD@cs.purdue.edu> Is there something about the memory model on PPC? It manifests as a hang, correct? On 3 Jul 2010, at 06:37, Jay K wrote: > > Alas, good news, bad news, restoring volatile on every load/store seems to fix this. > I wasn't even optimizing. > > Tony any ideas? > > I386_LINUX is ok. AMD64_DARWIN is ok. > SOLgnu is ok, but that doesn't count. I left volatile on there, was worried for some reason about interaction with stack walker, I forget. > > So far the debugger is being very uncooperative, can't set any breakpoints..it works for C. > > Aha.. > > gcc -gstabs+ -fPIC -pie 2.c > (gdb) break main > Breakpoint 1 at 0x658: file 2.c, line 3. > (gdb) run > Starting program: /home/jay/a.out > Warning: > Cannot insert breakpoint 1. > Error accessing memory address 0x658: Input/output error. > > > (gdb) q > The program is running. Exit anyway? (y or n) y > jay at plin:~$ gcc -gstabs+ -fPIC 2.c > jay at plin:~$ gdb ./a.out > GNU gdb 6.8-debian > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "powerpc-linux-gnu"... > (gdb) break main > Breakpoint 1 at 0x10000448: file 2.c, line 3. > (gdb) run > Starting program: /home/jay/a.out > > Breakpoint 1, main () at 2.c:3 > 3 } > > > So lame.. > > - Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Subject: ppc_linux hanging >> Date: Fri, 2 Jul 2010 08:10:10 +0000 >> >> >> Alas, PPC_LINUX is very prone to hang on head. >> e.g. compiling m3front. >> It doesn't hang with @M3nogc. >> The stack at the time just shows junk, no symbols at all. >> and info threads shows nothing, maybe I mistyped it. >> >> >> I'll try to figure it out. >> The biggest recent change I think is removing volatile so I'll start >> by trying with that put back. >> >> >> Also I use Darwin more lately, which has its own thread suspension code. >> Could be something broke the others. >> >> >> Later, >> - Jay >> >> > From jay.krell at cornell.edu Sun Jul 4 02:38:16 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 00:38:16 +0000 Subject: [M3devel] ppc_linux hanging In-Reply-To: <9B486681-F277-414E-8A67-F2A63E2BC4CD@cs.purdue.edu> References: , , <9B486681-F277-414E-8A67-F2A63E2BC4CD@cs.purdue.edu> Message-ID: I'm afraid I just don't know. Now I'm seeing: Fatal Error: bad version stamps: TextClass.i3 version stamp mismatch: M3_BUILTIN.TEXT ? <61b2d19ae7136110> => TextClass.i3 ? => M3_BUILTIN.i3? ?*** execution of [, From: hosking at cs.purdue.edu > Date: Sat, 3 Jul 2010 20:29:00 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] ppc_linux hanging > > Is there something about the memory model on PPC? It manifests as a hang, correct? > > On 3 Jul 2010, at 06:37, Jay K wrote: > > > > > Alas, good news, bad news, restoring volatile on every load/store seems to fix this. > > I wasn't even optimizing. > > > > Tony any ideas? > > > > I386_LINUX is ok. AMD64_DARWIN is ok. > > SOLgnu is ok, but that doesn't count. I left volatile on there, was worried for some reason about interaction with stack walker, I forget. > > > > So far the debugger is being very uncooperative, can't set any breakpoints..it works for C. > > > > Aha.. > > > > gcc -gstabs+ -fPIC -pie 2.c > > (gdb) break main > > Breakpoint 1 at 0x658: file 2.c, line 3. > > (gdb) run > > Starting program: /home/jay/a.out > > Warning: > > Cannot insert breakpoint 1. > > Error accessing memory address 0x658: Input/output error. > > > > > > (gdb) q > > The program is running. Exit anyway? (y or n) y > > jay at plin:~$ gcc -gstabs+ -fPIC 2.c > > jay at plin:~$ gdb ./a.out > > GNU gdb 6.8-debian > > Copyright (C) 2008 Free Software Foundation, Inc. > > License GPLv3+: GNU GPL version 3 or later > > This is free software: you are free to change and redistribute it. > > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > > and "show warranty" for details. > > This GDB was configured as "powerpc-linux-gnu"... > > (gdb) break main > > Breakpoint 1 at 0x10000448: file 2.c, line 3. > > (gdb) run > > Starting program: /home/jay/a.out > > > > Breakpoint 1, main () at 2.c:3 > > 3 } > > > > > > So lame.. > > > > - Jay > > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: m3devel at elegosoft.com > >> Subject: ppc_linux hanging > >> Date: Fri, 2 Jul 2010 08:10:10 +0000 > >> > >> > >> Alas, PPC_LINUX is very prone to hang on head. > >> e.g. compiling m3front. > >> It doesn't hang with @M3nogc. > >> The stack at the time just shows junk, no symbols at all. > >> and info threads shows nothing, maybe I mistyped it. > >> > >> > >> I'll try to figure it out. > >> The biggest recent change I think is removing volatile so I'll start > >> by trying with that put back. > >> > >> > >> Also I use Darwin more lately, which has its own thread suspension code. > >> Could be something broke the others. > >> > >> > >> Later, > >> - Jay > >> > >> > > > From jay.krell at cornell.edu Sun Jul 4 03:16:23 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 01:16:23 +0000 Subject: [M3devel] aliases/optimization In-Reply-To: <00538FB2-00DA-4C0E-82F3-D151B9A85A0E@cs.purdue.edu> References: <20100703105709.DBD2E2474003@birch.elegosoft.com>, , , , , , <00538FB2-00DA-4C0E-82F3-D151B9A85A0E@cs.purdue.edu> Message-ID: aha you just reminded me of something that we need to remember a bit and apply soon. Depending on compilers, optimization, etc. gcc doesn't like: float f; int i; i = *(int*)&f; though I think that's perfectly reasonable..anyway the equivalent form of code that gcc is explicitly ok with is: float f; int i; union { ? float f; ? int i; } u; u.f = f; i = u.i; So, point being, we should try changing LOOPHOLE to compile like that. You know, cons up the union type on-demand, make a local, etc. If we are lucky, that might solve some of our problems. Not the PPC ones. But that I left some systematic use of volatile in, like for all floating point, or something. And maybe it'll fix some of the optimizations I disabled. ? It'd still leave "unit at a time" broken. ? Possibly in tree-nested we can remove any notion of the functions being nested and ?? maybe that'll help.. Search the for "gcc type punning" ?=> wikipedia ?=> link at the bottom http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Optimize-Options.html#index-fstrict_002daliasing-542 There is a subtlty there though..we'd have use member_ref on the union. They also give some pointer to what to do "for real". I can follow up, later. Disabling unit at a time is also lame. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Sat, 3 Jul 2010 20:50:11 -0400 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > I added it a long time back only because I saw failures with optimisation turned on. Something to do with the alias analysis (and lack of proper type information) as far as I recall. > > > On 3 Jul 2010, at 20:44, Jay K wrote: > > > > > Tony, just to be clear..you/I are disturbed by volatile, but it has also, I believe, like always been there. > > It has been gone only very briefly, and its non-use is probably limited for other reasons (how many people are > > using it, on how many platforms?). > > > > > > - Jay > > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: hosking at cs.purdue.edu; jkrell at elego.de > >> CC: m3commit at elegosoft.com > >> Subject: RE: [M3commit] CVS Update: cm3 > >> Date: Sun, 4 Jul 2010 00:42:20 +0000 > >> > >> > >> Not a multiprocessor. > >> Still interested in selective volatile? > >> > >> > >> This all bothers me too. > >> I don't want volatile. It makes the optimized code terrible. > >> But I don't want to debug any problem from removing it, beyond compilation failure. > >> > >> > >> I can try a few things. > >> This is all wierd. I swear I saw it hang several times. > >> I swear I'm trying to to change "too many" variables at a time. Yes, I know, 2 is too many. > >> > >> > >> Once I started getting version stamp mismatch, I resorted to using a cross built cm3. > >> Out of necessity sort of, but that causes more flucuation of variables. > >> > >> Let me try again with volatile and see if it is solid. > >> Then I'll try with only volatile stores. > >> > >> I've been trying optimized and unoptimized, and not kept good track of which when. > >> > >> > >> - Jay > >> > >> > >> ---------------------------------------- > >>> From: hosking at cs.purdue.edu > >>> Date: Sat, 3 Jul 2010 20:36:20 -0400 > >>> To: jkrell at elego.de > >>> CC: m3commit at elegosoft.com > >>> Subject: Re: [M3commit] CVS Update: cm3 > >>> > >>> I am very disturbed that volatile is needed here. Can we selectively turn it on for thread-critical files like ThreadPThread and see if it fixes the problem. I wonder if the double-checked locking is broken for PPC memory model. Is this on a multi-processor? > >>> > >>> On 3 Jul 2010, at 12:57, Jay Krell wrote: > >>> > >>>> CVSROOT: /usr/cvs > >>>> Changes by: jkrell at birch. 10/07/03 12:57:09 > >>>> > >>>> Modified files: > >>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > >>>> > >>>> Log message: > >>>> restore volatile for powerpc and powerpc64 platforms > >>>> This seems to fix PPC_LINUX hanging. > >>>> This needs further debugging, but I'm not eager. > >>>> This will also affect PPC_DARWIN, PPC64_DARWIN, PPC32_OPENBSD, > >>>> PPC32_NETBSD, PPC32_FREEBSD, etc., but these platforms are little used or > >>>> nonexistant. > >>>> > >>>> Having volatile like has been the very long standing situation though. > >>>> The result is that the optimizer does basically nothing. > >>> > >> > > > From jay.krell at cornell.edu Sun Jul 4 10:14:47 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 08:14:47 +0000 Subject: [M3devel] aliases/optimization In-Reply-To: References: <20100703105709.DBD2E2474003@birch.elegosoft.com>, , , , , , <00538FB2-00DA-4C0E-82F3-D151B9A85A0E@cs.purdue.edu>, Message-ID: It appears this behavior is part of the C frontend, not the backend. It appears..that maybe..we should provide a langhook get_alias_set that always returns 0. The default is always -1. Not clear to me. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: aliases/optimization > Date: Sun, 4 Jul 2010 01:16:23 +0000 > > > aha you just reminded me of something that we need to remember a bit and apply soon. > > > Depending on compilers, optimization, etc. gcc doesn't like: > > > float f; > int i; > i = *(int*)&f; > > though I think that's perfectly reasonable..anyway the equivalent form of code that gcc is explicitly ok with is: > > float f; > > int i; > union { > float f; > int i; > } u; > u.f = f; > i = u.i; > > So, point being, we should try changing LOOPHOLE to compile like that. > You know, cons up the union type on-demand, make a local, etc. > > If we are lucky, that might solve some of our problems. > Not the PPC ones. > But that I left some systematic use of volatile in, like for all floating point, or something. > And maybe it'll fix some of the optimizations I disabled. > It'd still leave "unit at a time" broken. > Possibly in tree-nested we can remove any notion of the functions being nested and > maybe that'll help.. > > Search the for "gcc type punning" > => wikipedia > => link at the bottom > > http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Optimize-Options.html#index-fstrict_002daliasing-542 > > There is a subtlty there though..we'd have use member_ref on the union. > They also give some pointer to what to do "for real". I can follow up, later. > > > Disabling unit at a time is also lame. > > > - Jay > > ---------------------------------------- > > From: hosking at cs.purdue.edu > > Date: Sat, 3 Jul 2010 20:50:11 -0400 > > To: jay.krell at cornell.edu > > CC: m3commit at elegosoft.com > > Subject: Re: [M3commit] CVS Update: cm3 > > > > I added it a long time back only because I saw failures with optimisation turned on. Something to do with the alias analysis (and lack of proper type information) as far as I recall. > > > > > > On 3 Jul 2010, at 20:44, Jay K wrote: > > > > > > > > Tony, just to be clear..you/I are disturbed by volatile, but it has also, I believe, like always been there. > > > It has been gone only very briefly, and its non-use is probably limited for other reasons (how many people are > > > using it, on how many platforms?). > > > > > > > > > - Jay > > > > > > ---------------------------------------- > > >> From: jay.krell at cornell.edu > > >> To: hosking at cs.purdue.edu; jkrell at elego.de > > >> CC: m3commit at elegosoft.com > > >> Subject: RE: [M3commit] CVS Update: cm3 > > >> Date: Sun, 4 Jul 2010 00:42:20 +0000 > > >> > > >> > > >> Not a multiprocessor. > > >> Still interested in selective volatile? > > >> > > >> > > >> This all bothers me too. > > >> I don't want volatile. It makes the optimized code terrible. > > >> But I don't want to debug any problem from removing it, beyond compilation failure. > > >> > > >> > > >> I can try a few things. > > >> This is all wierd. I swear I saw it hang several times. > > >> I swear I'm trying to to change "too many" variables at a time. Yes, I know, 2 is too many. > > >> > > >> > > >> Once I started getting version stamp mismatch, I resorted to using a cross built cm3. > > >> Out of necessity sort of, but that causes more flucuation of variables. > > >> > > >> Let me try again with volatile and see if it is solid. > > >> Then I'll try with only volatile stores. > > >> > > >> I've been trying optimized and unoptimized, and not kept good track of which when. > > >> > > >> > > >> - Jay > > >> > > >> > > >> ---------------------------------------- > > >>> From: hosking at cs.purdue.edu > > >>> Date: Sat, 3 Jul 2010 20:36:20 -0400 > > >>> To: jkrell at elego.de > > >>> CC: m3commit at elegosoft.com > > >>> Subject: Re: [M3commit] CVS Update: cm3 > > >>> > > >>> I am very disturbed that volatile is needed here. Can we selectively turn it on for thread-critical files like ThreadPThread and see if it fixes the problem. I wonder if the double-checked locking is broken for PPC memory model. Is this on a multi-processor? > > >>> > > >>> On 3 Jul 2010, at 12:57, Jay Krell wrote: > > >>> > > >>>> CVSROOT: /usr/cvs > > >>>> Changes by: jkrell at birch. 10/07/03 12:57:09 > > >>>> > > >>>> Modified files: > > >>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > >>>> > > >>>> Log message: > > >>>> restore volatile for powerpc and powerpc64 platforms > > >>>> This seems to fix PPC_LINUX hanging. > > >>>> This needs further debugging, but I'm not eager. > > >>>> This will also affect PPC_DARWIN, PPC64_DARWIN, PPC32_OPENBSD, > > >>>> PPC32_NETBSD, PPC32_FREEBSD, etc., but these platforms are little used or > > >>>> nonexistant. > > >>>> > > >>>> Having volatile like has been the very long standing situation though. > > >>>> The result is that the optimizer does basically nothing. > > >>> > > >> > > > > > > From jay.krell at cornell.edu Sun Jul 4 10:18:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 08:18:31 +0000 Subject: [M3devel] aliases/optimization In-Reply-To: References: <20100703105709.DBD2E2474003@birch.elegosoft.com>, , , , , , <00538FB2-00DA-4C0E-82F3-D151B9A85A0E@cs.purdue.edu>, , Message-ID: er, well, clearly, if we just assign flag_strict_aliasing = false, this stuff all falls away. That I will try. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: aliases/optimization > Date: Sun, 4 Jul 2010 08:14:47 +0000 > > > It appears this behavior is part of the C frontend, not the backend. > It appears..that maybe..we should provide a langhook get_alias_set that always returns 0. > The default is always -1. > Not clear to me. > > - Jay > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: hosking at cs.purdue.edu > > CC: m3devel at elegosoft.com > > Subject: aliases/optimization > > Date: Sun, 4 Jul 2010 01:16:23 +0000 > > > > > > aha you just reminded me of something that we need to remember a bit and apply soon. > > > > > > Depending on compilers, optimization, etc. gcc doesn't like: > > > > > > float f; > > int i; > > i = *(int*)&f; > > > > though I think that's perfectly reasonable..anyway the equivalent form of code that gcc is explicitly ok with is: > > > > float f; > > > > int i; > > union { > > float f; > > int i; > > } u; > > u.f = f; > > i = u.i; > > > > So, point being, we should try changing LOOPHOLE to compile like that. > > You know, cons up the union type on-demand, make a local, etc. > > > > If we are lucky, that might solve some of our problems. > > Not the PPC ones. > > But that I left some systematic use of volatile in, like for all floating point, or something. > > And maybe it'll fix some of the optimizations I disabled. > > It'd still leave "unit at a time" broken. > > Possibly in tree-nested we can remove any notion of the functions being nested and > > maybe that'll help.. > > > > Search the for "gcc type punning" > > => wikipedia > > => link at the bottom > > > > http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Optimize-Options.html#index-fstrict_002daliasing-542 > > > > There is a subtlty there though..we'd have use member_ref on the union. > > They also give some pointer to what to do "for real". I can follow up, later. > > > > > > Disabling unit at a time is also lame. > > > > > > - Jay > > > > ---------------------------------------- > > > From: hosking at cs.purdue.edu > > > Date: Sat, 3 Jul 2010 20:50:11 -0400 > > > To: jay.krell at cornell.edu > > > CC: m3commit at elegosoft.com > > > Subject: Re: [M3commit] CVS Update: cm3 > > > > > > I added it a long time back only because I saw failures with optimisation turned on. Something to do with the alias analysis (and lack of proper type information) as far as I recall. > > > > > > > > > On 3 Jul 2010, at 20:44, Jay K wrote: > > > > > > > > > > > Tony, just to be clear..you/I are disturbed by volatile, but it has also, I believe, like always been there. > > > > It has been gone only very briefly, and its non-use is probably limited for other reasons (how many people are > > > > using it, on how many platforms?). > > > > > > > > > > > > - Jay > > > > > > > > ---------------------------------------- > > > >> From: jay.krell at cornell.edu > > > >> To: hosking at cs.purdue.edu; jkrell at elego.de > > > >> CC: m3commit at elegosoft.com > > > >> Subject: RE: [M3commit] CVS Update: cm3 > > > >> Date: Sun, 4 Jul 2010 00:42:20 +0000 > > > >> > > > >> > > > >> Not a multiprocessor. > > > >> Still interested in selective volatile? > > > >> > > > >> > > > >> This all bothers me too. > > > >> I don't want volatile. It makes the optimized code terrible. > > > >> But I don't want to debug any problem from removing it, beyond compilation failure. > > > >> > > > >> > > > >> I can try a few things. > > > >> This is all wierd. I swear I saw it hang several times. > > > >> I swear I'm trying to to change "too many" variables at a time. Yes, I know, 2 is too many. > > > >> > > > >> > > > >> Once I started getting version stamp mismatch, I resorted to using a cross built cm3. > > > >> Out of necessity sort of, but that causes more flucuation of variables. > > > >> > > > >> Let me try again with volatile and see if it is solid. > > > >> Then I'll try with only volatile stores. > > > >> > > > >> I've been trying optimized and unoptimized, and not kept good track of which when. > > > >> > > > >> > > > >> - Jay > > > >> > > > >> > > > >> ---------------------------------------- > > > >>> From: hosking at cs.purdue.edu > > > >>> Date: Sat, 3 Jul 2010 20:36:20 -0400 > > > >>> To: jkrell at elego.de > > > >>> CC: m3commit at elegosoft.com > > > >>> Subject: Re: [M3commit] CVS Update: cm3 > > > >>> > > > >>> I am very disturbed that volatile is needed here. Can we selectively turn it on for thread-critical files like ThreadPThread and see if it fixes the problem. I wonder if the double-checked locking is broken for PPC memory model. Is this on a multi-processor? > > > >>> > > > >>> On 3 Jul 2010, at 12:57, Jay Krell wrote: > > > >>> > > > >>>> CVSROOT: /usr/cvs > > > >>>> Changes by: jkrell at birch. 10/07/03 12:57:09 > > > >>>> > > > >>>> Modified files: > > > >>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > >>>> > > > >>>> Log message: > > > >>>> restore volatile for powerpc and powerpc64 platforms > > > >>>> This seems to fix PPC_LINUX hanging. > > > >>>> This needs further debugging, but I'm not eager. > > > >>>> This will also affect PPC_DARWIN, PPC64_DARWIN, PPC32_OPENBSD, > > > >>>> PPC32_NETBSD, PPC32_FREEBSD, etc., but these platforms are little used or > > > >>>> nonexistant. > > > >>>> > > > >>>> Having volatile like has been the very long standing situation though. > > > >>>> The result is that the optimizer does basically nothing. > > > >>> > > > >> > > > > > > > > > > From jay.krell at cornell.edu Sun Jul 4 16:25:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 14:25:04 +0000 Subject: [M3devel] eliminating volatile on floats Message-ID: Through simple trial/error I've tracked a need (the only need?) for floats down: If I set flag_tree_ter = 0, I can compile m3core where I couldn't before, with -O3. I suspect due to: builtins.c: int get_pointer_alignment (tree exp, unsigned int max_align) { ? unsigned int align, inner; ? /* We rely on TER to compute accurate alignment information.? */ ? if (!(optimize && flag_tree_ter)) ??? return 0; Another thing to try is #if 0 out this block of code (it is not in parse,c but "gcc? itself"). That should yield more optimization, but more patch to gcc. I'm inclined to try that. There should be additional options, like getting the alignment correct or such. The code that fails to compile is: /dev2/cm3/m3-libs/m3core/src/float/IEEE/LongFloat.m3 PROCEDURE CopySign (x, y: T): T = ? VAR res := x; ? BEGIN ??? LOOPHOLE (res, Rep.T).sign := LOOPHOLE (y, Rep.T).sign; ??? RETURN res; ? END CopySign; I also tried some other options like adding volatile and/or temporaries on loophole's using t_struct. (To be clear, we only have volatile on float loads, not stores, though I think only stores would be preferable to only loads. "reads are more common than writes", "consider the registers to be a write-through cache") ?- Jay From jay.krell at cornell.edu Sun Jul 4 16:44:26 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 14:44:26 +0000 Subject: [M3devel] other optimizations to think about? Message-ID: Given that we know vaguely what these things are: ??? flag_strict_aliasing = 0; ??? flag_strict_overflow = 0; I'm inclined to turn them off in m3cg/parse.c like how a few others are. They sound kind of scary and not valuable. strict_aliasing I believe is something like where if you have pointers to integers and pointers to floats, writes through one are assumed to not affect reads through the other. ? So the reads can be cached in registers across the writes. Tony has mentioned a need for alias analysis a few times, so.. Or we could just turn it off in unsafe modules or once we see a loophole, perhaps. strict_overflow is something like where the compiler assumes there shall be no signed integer overflow, ?or that signed integer overflow doesn't trap?, and then make optimizations based on that assumption. I don't feel I'm yet willing to give up a possibly systematic that signed oveflow silently overflow. This optimization in fact I believe/thought defeats the obvious ways to check for overflow. int add(int a, int b) { int c = a + b; ?? if (c < a) ????? error_and_exit("overflow"); ? return c; } strict overflow means c can't be less than a, so the check can be optimized away. I wasn't able to reproduce this, granted, with: ?Apple gcc 4.2 ? Debian 5.0 gcc 4.3 ? self-built gcc 4.5 http://gcc.gnu.org/gcc-4.2/changes.html does sound like what I'm saying though. er, wait, what I showed is the unsigned algorithm, duh. void overflow(void); int add(int a, int b) { ? int c = (a + b); ? int asign = (a < 0); ? if (asign == (b < 0) && asign != (c < 0)) ??? overflow(); ? return c; } still, doesn't have a problem. (explanation: overflow occured if inputs have same sign and output differs from their sign overflow cannot occur if inputs have different sign sign(x) equivalent to (x < 0) (maps one to one: negative => 1, positive => 0) ) ?- Jay From jay.krell at cornell.edu Sun Jul 4 16:54:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 14:54:03 +0000 Subject: [M3devel] other optimizations to think about? In-Reply-To: References: Message-ID: proofreading... > strict_overflow is something like where the compiler assumes there shall be no signed integer overflow, ?or that signed integer overflow doesn't trap?, and then make optimizations based on that assumption. > I don't feel I'm yet willing to give up a possibly systematic that signed oveflow silently overflow. DOES trap systematic ASSUMPTION ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: other optimizations to think about? > Date: Sun, 4 Jul 2010 14:44:26 +0000 > > > Given that we know vaguely what these things are: > flag_strict_aliasing = 0; > flag_strict_overflow = 0; > > > I'm inclined to turn them off in m3cg/parse.c like how a few others are. > They sound kind of scary and not valuable. > > > strict_aliasing I believe is something like where if you have pointers to integers and pointers to floats, writes through one are assumed to not affect reads through the other. > So the reads can be cached in registers across the writes. > Tony has mentioned a need for alias analysis a few times, so.. > Or we could just turn it off in unsafe modules or once we see a loophole, perhaps. > > > strict_overflow is something like where the compiler assumes there shall be no signed integer overflow, ?or that signed integer overflow doesn't trap?, and then make optimizations based on that assumption. > I don't feel I'm yet willing to give up a possibly systematic that signed oveflow silently overflow. > This optimization in fact I believe/thought defeats the obvious ways to check for overflow. > int add(int a, int b) > { int c = a + b; > if (c < a) > error_and_exit("overflow"); > return c; > } > > strict overflow means c can't be less than a, so the check can be optimized away. > > I wasn't able to reproduce this, granted, with: > Apple gcc 4.2 > Debian 5.0 gcc 4.3 > self-built gcc 4.5 > > http://gcc.gnu.org/gcc-4.2/changes.html > > does sound like what I'm saying though. > > er, wait, what I showed is the unsigned algorithm, duh. > > void overflow(void); > > int add(int a, int b) > { > int c = (a + b); > int asign = (a < 0); > if (asign == (b < 0) && asign != (c < 0)) > overflow(); > return c; > } > > still, doesn't have a problem. > > (explanation: > overflow occured if inputs have same sign and output differs from their sign > overflow cannot occur if inputs have different sign > sign(x) equivalent to (x < 0) (maps one to one: negative => 1, positive => 0) > ) > > > - Jay > From hosking at cs.purdue.edu Sun Jul 4 16:49:55 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 4 Jul 2010 10:49:55 -0400 Subject: [M3devel] eliminating volatile on floats In-Reply-To: References: Message-ID: I don't understand what we would need to do to fix this without the hack of commenting out gcc functionality. Better to give gcc something it likes than to hack it. On 4 Jul 2010, at 10:25, Jay K wrote: > > Through simple trial/error I've tracked a need (the only need?) for floats down: > > If I set flag_tree_ter = 0, I can compile m3core where I couldn't before, with -O3. > > > I suspect due to: > > builtins.c: > > int > get_pointer_alignment (tree exp, unsigned int max_align) > { > unsigned int align, inner; > > /* We rely on TER to compute accurate alignment information. */ > if (!(optimize && flag_tree_ter)) > return 0; > > > Another thing to try is #if 0 out this block of code (it is not in parse,c but "gcc itself"). > That should yield more optimization, but more patch to gcc. > I'm inclined to try that. > > > There should be additional options, like getting the alignment correct or such. > > > The code that fails to compile is: > /dev2/cm3/m3-libs/m3core/src/float/IEEE/LongFloat.m3 > > > PROCEDURE CopySign (x, y: T): T = > VAR res := x; > BEGIN > LOOPHOLE (res, Rep.T).sign := LOOPHOLE (y, Rep.T).sign; > RETURN res; > END CopySign; > > > I also tried some other options like adding volatile and/or temporaries on loophole's using t_struct. > > > (To be clear, we only have volatile on float loads, not stores, though I think only stores would be preferable to only loads. > "reads are more common than writes", "consider the registers to be a write-through cache") > > > - Jay > From hosking at cs.purdue.edu Sun Jul 4 16:47:50 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 4 Jul 2010 10:47:50 -0400 Subject: [M3devel] aliases/optimization In-Reply-To: References: <20100703105709.DBD2E2474003@birch.elegosoft.com>, , , , , , <00538FB2-00DA-4C0E-82F3-D151B9A85A0E@cs.purdue.edu>, Message-ID: I thought I already implemented one of those. On 4 Jul 2010, at 04:14, Jay K wrote: > > It appears this behavior is part of the C frontend, not the backend. > It appears..that maybe..we should provide a langhook get_alias_set that always returns 0. > The default is always -1. > Not clear to me. > > - Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: aliases/optimization >> Date: Sun, 4 Jul 2010 01:16:23 +0000 >> >> >> aha you just reminded me of something that we need to remember a bit and apply soon. >> >> >> Depending on compilers, optimization, etc. gcc doesn't like: >> >> >> float f; >> int i; >> i = *(int*)&f; >> >> though I think that's perfectly reasonable..anyway the equivalent form of code that gcc is explicitly ok with is: >> >> float f; >> >> int i; >> union { >> float f; >> int i; >> } u; >> u.f = f; >> i = u.i; >> >> So, point being, we should try changing LOOPHOLE to compile like that. >> You know, cons up the union type on-demand, make a local, etc. >> >> If we are lucky, that might solve some of our problems. >> Not the PPC ones. >> But that I left some systematic use of volatile in, like for all floating point, or something. >> And maybe it'll fix some of the optimizations I disabled. >> It'd still leave "unit at a time" broken. >> Possibly in tree-nested we can remove any notion of the functions being nested and >> maybe that'll help.. >> >> Search the for "gcc type punning" >> => wikipedia >> => link at the bottom >> >> http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Optimize-Options.html#index-fstrict_002daliasing-542 >> >> There is a subtlty there though..we'd have use member_ref on the union. >> They also give some pointer to what to do "for real". I can follow up, later. >> >> >> Disabling unit at a time is also lame. >> >> >> - Jay >> >> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> Date: Sat, 3 Jul 2010 20:50:11 -0400 >>> To: jay.krell at cornell.edu >>> CC: m3commit at elegosoft.com >>> Subject: Re: [M3commit] CVS Update: cm3 >>> >>> I added it a long time back only because I saw failures with optimisation turned on. Something to do with the alias analysis (and lack of proper type information) as far as I recall. >>> >>> >>> On 3 Jul 2010, at 20:44, Jay K wrote: >>> >>>> >>>> Tony, just to be clear..you/I are disturbed by volatile, but it has also, I believe, like always been there. >>>> It has been gone only very briefly, and its non-use is probably limited for other reasons (how many people are >>>> using it, on how many platforms?). >>>> >>>> >>>> - Jay >>>> >>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: hosking at cs.purdue.edu; jkrell at elego.de >>>>> CC: m3commit at elegosoft.com >>>>> Subject: RE: [M3commit] CVS Update: cm3 >>>>> Date: Sun, 4 Jul 2010 00:42:20 +0000 >>>>> >>>>> >>>>> Not a multiprocessor. >>>>> Still interested in selective volatile? >>>>> >>>>> >>>>> This all bothers me too. >>>>> I don't want volatile. It makes the optimized code terrible. >>>>> But I don't want to debug any problem from removing it, beyond compilation failure. >>>>> >>>>> >>>>> I can try a few things. >>>>> This is all wierd. I swear I saw it hang several times. >>>>> I swear I'm trying to to change "too many" variables at a time. Yes, I know, 2 is too many. >>>>> >>>>> >>>>> Once I started getting version stamp mismatch, I resorted to using a cross built cm3. >>>>> Out of necessity sort of, but that causes more flucuation of variables. >>>>> >>>>> Let me try again with volatile and see if it is solid. >>>>> Then I'll try with only volatile stores. >>>>> >>>>> I've been trying optimized and unoptimized, and not kept good track of which when. >>>>> >>>>> >>>>> - Jay >>>>> >>>>> >>>>> ---------------------------------------- >>>>>> From: hosking at cs.purdue.edu >>>>>> Date: Sat, 3 Jul 2010 20:36:20 -0400 >>>>>> To: jkrell at elego.de >>>>>> CC: m3commit at elegosoft.com >>>>>> Subject: Re: [M3commit] CVS Update: cm3 >>>>>> >>>>>> I am very disturbed that volatile is needed here. Can we selectively turn it on for thread-critical files like ThreadPThread and see if it fixes the problem. I wonder if the double-checked locking is broken for PPC memory model. Is this on a multi-processor? >>>>>> >>>>>> On 3 Jul 2010, at 12:57, Jay Krell wrote: >>>>>> >>>>>>> CVSROOT: /usr/cvs >>>>>>> Changes by: jkrell at birch. 10/07/03 12:57:09 >>>>>>> >>>>>>> Modified files: >>>>>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >>>>>>> >>>>>>> Log message: >>>>>>> restore volatile for powerpc and powerpc64 platforms >>>>>>> This seems to fix PPC_LINUX hanging. >>>>>>> This needs further debugging, but I'm not eager. >>>>>>> This will also affect PPC_DARWIN, PPC64_DARWIN, PPC32_OPENBSD, >>>>>>> PPC32_NETBSD, PPC32_FREEBSD, etc., but these platforms are little used or >>>>>>> nonexistant. >>>>>>> >>>>>>> Having volatile like has been the very long standing situation though. >>>>>>> The result is that the optimizer does basically nothing. >>>>>> >>>>> >>>> >>> >> > From jay.krell at cornell.edu Sun Jul 4 16:57:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 14:57:24 +0000 Subject: [M3devel] aliases/optimization In-Reply-To: <393E6607-54BD-4776-AB1E-D68BDA6F6906@cs.purdue.edu> References: <20100703105709.DBD2E2474003@birch.elegosoft.com>, , , , , , <00538FB2-00DA-4C0E-82F3-D151B9A85A0E@cs.purdue.edu> , <393E6607-54BD-4776-AB1E-D68BDA6F6906@cs.purdue.edu> Message-ID: Further research suggests this is frontend behavior, not backend. Oops my mistake. I read the C compiler documentation and forget about that division. Though I haven't tried this, it appears maybe a "lang hook" get_alias_set that returns 0 might be an easy win pessimistic win. Perhaps, again, only in unsafe modules and/or modules that use loophole (yes, I realize loophole implies unsafe). It's not clear to me yet what the default alias analysis is. -1 seems to mean "the default" and 0 seems to mean "pessimisic" Oh I didn't realize, we have: alias_set_type m3_get_alias_set (tree ARG_UNUSED (t)) { ? return 0; } which I'm pretty sure means pessimistic. ?- Jay ---------------------------------------- > Subject: Re: aliases/optimization > From: hosking at cs.purdue.edu > Date: Sun, 4 Jul 2010 10:47:03 -0400 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > Yes, that's right! > > On 3 Jul 2010, at 21:16, Jay K wrote: > > > > > aha you just reminded me of something that we need to remember a bit and apply soon. > > > > > > Depending on compilers, optimization, etc. gcc doesn't like: > > > > > > float f; > > int i; > > i = *(int*)&f; > > > > though I think that's perfectly reasonable..anyway the equivalent form of code that gcc is explicitly ok with is: > > > > float f; > > > > int i; > > union { > > float f; > > int i; > > } u; > > u.f = f; > > i = u.i; > > > > So, point being, we should try changing LOOPHOLE to compile like that. > > You know, cons up the union type on-demand, make a local, etc. > > > > If we are lucky, that might solve some of our problems. > > Not the PPC ones. > > But that I left some systematic use of volatile in, like for all floating point, or something. > > And maybe it'll fix some of the optimizations I disabled. > > It'd still leave "unit at a time" broken. > > Possibly in tree-nested we can remove any notion of the functions being nested and > > maybe that'll help.. > > > > Search the for "gcc type punning" > > => wikipedia > > => link at the bottom > > > > http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Optimize-Options.html#index-fstrict_002daliasing-542 > > > > There is a subtlty there though..we'd have use member_ref on the union. > > They also give some pointer to what to do "for real". I can follow up, later. > > > > > > Disabling unit at a time is also lame. > > > > > > - Jay > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Sat, 3 Jul 2010 20:50:11 -0400 > >> To: jay.krell at cornell.edu > >> CC: m3commit at elegosoft.com > >> Subject: Re: [M3commit] CVS Update: cm3 > >> > >> I added it a long time back only because I saw failures with optimisation turned on. Something to do with the alias analysis (and lack of proper type information) as far as I recall. > >> > >> > >> On 3 Jul 2010, at 20:44, Jay K wrote: > >> > >>> > >>> Tony, just to be clear..you/I are disturbed by volatile, but it has also, I believe, like always been there. > >>> It has been gone only very briefly, and its non-use is probably limited for other reasons (how many people are > >>> using it, on how many platforms?). > >>> > >>> > >>> - Jay > >>> > >>> ---------------------------------------- > >>>> From: jay.krell at cornell.edu > >>>> To: hosking at cs.purdue.edu; jkrell at elego.de > >>>> CC: m3commit at elegosoft.com > >>>> Subject: RE: [M3commit] CVS Update: cm3 > >>>> Date: Sun, 4 Jul 2010 00:42:20 +0000 > >>>> > >>>> > >>>> Not a multiprocessor. > >>>> Still interested in selective volatile? > >>>> > >>>> > >>>> This all bothers me too. > >>>> I don't want volatile. It makes the optimized code terrible. > >>>> But I don't want to debug any problem from removing it, beyond compilation failure. > >>>> > >>>> > >>>> I can try a few things. > >>>> This is all wierd. I swear I saw it hang several times. > >>>> I swear I'm trying to to change "too many" variables at a time. Yes, I know, 2 is too many. > >>>> > >>>> > >>>> Once I started getting version stamp mismatch, I resorted to using a cross built cm3. > >>>> Out of necessity sort of, but that causes more flucuation of variables. > >>>> > >>>> Let me try again with volatile and see if it is solid. > >>>> Then I'll try with only volatile stores. > >>>> > >>>> I've been trying optimized and unoptimized, and not kept good track of which when. > >>>> > >>>> > >>>> - Jay > >>>> > >>>> > >>>> ---------------------------------------- > >>>>> From: hosking at cs.purdue.edu > >>>>> Date: Sat, 3 Jul 2010 20:36:20 -0400 > >>>>> To: jkrell at elego.de > >>>>> CC: m3commit at elegosoft.com > >>>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>>> > >>>>> I am very disturbed that volatile is needed here. Can we selectively turn it on for thread-critical files like ThreadPThread and see if it fixes the problem. I wonder if the double-checked locking is broken for PPC memory model. Is this on a multi-processor? > >>>>> > >>>>> On 3 Jul 2010, at 12:57, Jay Krell wrote: > >>>>> > >>>>>> CVSROOT: /usr/cvs > >>>>>> Changes by: jkrell at birch. 10/07/03 12:57:09 > >>>>>> > >>>>>> Modified files: > >>>>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > >>>>>> > >>>>>> Log message: > >>>>>> restore volatile for powerpc and powerpc64 platforms > >>>>>> This seems to fix PPC_LINUX hanging. > >>>>>> This needs further debugging, but I'm not eager. > >>>>>> This will also affect PPC_DARWIN, PPC64_DARWIN, PPC32_OPENBSD, > >>>>>> PPC32_NETBSD, PPC32_FREEBSD, etc., but these platforms are little used or > >>>>>> nonexistant. > >>>>>> > >>>>>> Having volatile like has been the very long standing situation though. > >>>>>> The result is that the optimizer does basically nothing. > >>>>> > >>>> > >>> > >> > > > From jay.krell at cornell.edu Sun Jul 4 16:57:49 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 14:57:49 +0000 Subject: [M3devel] aliases/optimization In-Reply-To: References: <20100703105709.DBD2E2474003@birch.elegosoft.com>, ,,, , , , , , , <00538FB2-00DA-4C0E-82F3-D151B9A85A0E@cs.purdue.edu>, , , , Message-ID: Yep I just noticed, finally. ?- Jay --------------------------------------- > From: hosking at cs.purdue.edu > Date: Sun, 4 Jul 2010 10:47:50 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] aliases/optimization > > I thought I already implemented one of those. > > On 4 Jul 2010, at 04:14, Jay K wrote: > > > > > It appears this behavior is part of the C frontend, not the backend. > > It appears..that maybe..we should provide a langhook get_alias_set that always returns 0. > > The default is always -1. > > Not clear to me. > > > > - Jay > > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: hosking at cs.purdue.edu > >> CC: m3devel at elegosoft.com > >> Subject: aliases/optimization > >> Date: Sun, 4 Jul 2010 01:16:23 +0000 > >> > >> > >> aha you just reminded me of something that we need to remember a bit and apply soon. > >> > >> > >> Depending on compilers, optimization, etc. gcc doesn't like: > >> > >> > >> float f; > >> int i; > >> i = *(int*)&f; > >> > >> though I think that's perfectly reasonable..anyway the equivalent form of code that gcc is explicitly ok with is: > >> > >> float f; > >> > >> int i; > >> union { > >> float f; > >> int i; > >> } u; > >> u.f = f; > >> i = u.i; > >> > >> So, point being, we should try changing LOOPHOLE to compile like that. > >> You know, cons up the union type on-demand, make a local, etc. > >> > >> If we are lucky, that might solve some of our problems. > >> Not the PPC ones. > >> But that I left some systematic use of volatile in, like for all floating point, or something. > >> And maybe it'll fix some of the optimizations I disabled. > >> It'd still leave "unit at a time" broken. > >> Possibly in tree-nested we can remove any notion of the functions being nested and > >> maybe that'll help.. > >> > >> Search the for "gcc type punning" > >> => wikipedia > >> => link at the bottom > >> > >> http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Optimize-Options.html#index-fstrict_002daliasing-542 > >> > >> There is a subtlty there though..we'd have use member_ref on the union. > >> They also give some pointer to what to do "for real". I can follow up, later. > >> > >> > >> Disabling unit at a time is also lame. > >> > >> > >> - Jay > >> > >> ---------------------------------------- > >>> From: hosking at cs.purdue.edu > >>> Date: Sat, 3 Jul 2010 20:50:11 -0400 > >>> To: jay.krell at cornell.edu > >>> CC: m3commit at elegosoft.com > >>> Subject: Re: [M3commit] CVS Update: cm3 > >>> > >>> I added it a long time back only because I saw failures with optimisation turned on. Something to do with the alias analysis (and lack of proper type information) as far as I recall. > >>> > >>> > >>> On 3 Jul 2010, at 20:44, Jay K wrote: > >>> > >>>> > >>>> Tony, just to be clear..you/I are disturbed by volatile, but it has also, I believe, like always been there. > >>>> It has been gone only very briefly, and its non-use is probably limited for other reasons (how many people are > >>>> using it, on how many platforms?). > >>>> > >>>> > >>>> - Jay > >>>> > >>>> ---------------------------------------- > >>>>> From: jay.krell at cornell.edu > >>>>> To: hosking at cs.purdue.edu; jkrell at elego.de > >>>>> CC: m3commit at elegosoft.com > >>>>> Subject: RE: [M3commit] CVS Update: cm3 > >>>>> Date: Sun, 4 Jul 2010 00:42:20 +0000 > >>>>> > >>>>> > >>>>> Not a multiprocessor. > >>>>> Still interested in selective volatile? > >>>>> > >>>>> > >>>>> This all bothers me too. > >>>>> I don't want volatile. It makes the optimized code terrible. > >>>>> But I don't want to debug any problem from removing it, beyond compilation failure. > >>>>> > >>>>> > >>>>> I can try a few things. > >>>>> This is all wierd. I swear I saw it hang several times. > >>>>> I swear I'm trying to to change "too many" variables at a time. Yes, I know, 2 is too many. > >>>>> > >>>>> > >>>>> Once I started getting version stamp mismatch, I resorted to using a cross built cm3. > >>>>> Out of necessity sort of, but that causes more flucuation of variables. > >>>>> > >>>>> Let me try again with volatile and see if it is solid. > >>>>> Then I'll try with only volatile stores. > >>>>> > >>>>> I've been trying optimized and unoptimized, and not kept good track of which when. > >>>>> > >>>>> > >>>>> - Jay > >>>>> > >>>>> > >>>>> ---------------------------------------- > >>>>>> From: hosking at cs.purdue.edu > >>>>>> Date: Sat, 3 Jul 2010 20:36:20 -0400 > >>>>>> To: jkrell at elego.de > >>>>>> CC: m3commit at elegosoft.com > >>>>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>>>> > >>>>>> I am very disturbed that volatile is needed here. Can we selectively turn it on for thread-critical files like ThreadPThread and see if it fixes the problem. I wonder if the double-checked locking is broken for PPC memory model. Is this on a multi-processor? > >>>>>> > >>>>>> On 3 Jul 2010, at 12:57, Jay Krell wrote: > >>>>>> > >>>>>>> CVSROOT: /usr/cvs > >>>>>>> Changes by: jkrell at birch. 10/07/03 12:57:09 > >>>>>>> > >>>>>>> Modified files: > >>>>>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > >>>>>>> > >>>>>>> Log message: > >>>>>>> restore volatile for powerpc and powerpc64 platforms > >>>>>>> This seems to fix PPC_LINUX hanging. > >>>>>>> This needs further debugging, but I'm not eager. > >>>>>>> This will also affect PPC_DARWIN, PPC64_DARWIN, PPC32_OPENBSD, > >>>>>>> PPC32_NETBSD, PPC32_FREEBSD, etc., but these platforms are little used or > >>>>>>> nonexistant. > >>>>>>> > >>>>>>> Having volatile like has been the very long standing situation though. > >>>>>>> The result is that the optimizer does basically nothing. > >>>>>> > >>>>> > >>>> > >>> > >> > > > From hosking at cs.purdue.edu Sun Jul 4 16:47:03 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 4 Jul 2010 10:47:03 -0400 Subject: [M3devel] aliases/optimization In-Reply-To: References: <20100703105709.DBD2E2474003@birch.elegosoft.com>, , , , , , <00538FB2-00DA-4C0E-82F3-D151B9A85A0E@cs.purdue.edu> Message-ID: <393E6607-54BD-4776-AB1E-D68BDA6F6906@cs.purdue.edu> Yes, that's right! On 3 Jul 2010, at 21:16, Jay K wrote: > > aha you just reminded me of something that we need to remember a bit and apply soon. > > > Depending on compilers, optimization, etc. gcc doesn't like: > > > float f; > int i; > i = *(int*)&f; > > though I think that's perfectly reasonable..anyway the equivalent form of code that gcc is explicitly ok with is: > > float f; > > int i; > union { > float f; > int i; > } u; > u.f = f; > i = u.i; > > So, point being, we should try changing LOOPHOLE to compile like that. > You know, cons up the union type on-demand, make a local, etc. > > If we are lucky, that might solve some of our problems. > Not the PPC ones. > But that I left some systematic use of volatile in, like for all floating point, or something. > And maybe it'll fix some of the optimizations I disabled. > It'd still leave "unit at a time" broken. > Possibly in tree-nested we can remove any notion of the functions being nested and > maybe that'll help.. > > Search the for "gcc type punning" > => wikipedia > => link at the bottom > > http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Optimize-Options.html#index-fstrict_002daliasing-542 > > There is a subtlty there though..we'd have use member_ref on the union. > They also give some pointer to what to do "for real". I can follow up, later. > > > Disabling unit at a time is also lame. > > > - Jay > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Sat, 3 Jul 2010 20:50:11 -0400 >> To: jay.krell at cornell.edu >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> I added it a long time back only because I saw failures with optimisation turned on. Something to do with the alias analysis (and lack of proper type information) as far as I recall. >> >> >> On 3 Jul 2010, at 20:44, Jay K wrote: >> >>> >>> Tony, just to be clear..you/I are disturbed by volatile, but it has also, I believe, like always been there. >>> It has been gone only very briefly, and its non-use is probably limited for other reasons (how many people are >>> using it, on how many platforms?). >>> >>> >>> - Jay >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: hosking at cs.purdue.edu; jkrell at elego.de >>>> CC: m3commit at elegosoft.com >>>> Subject: RE: [M3commit] CVS Update: cm3 >>>> Date: Sun, 4 Jul 2010 00:42:20 +0000 >>>> >>>> >>>> Not a multiprocessor. >>>> Still interested in selective volatile? >>>> >>>> >>>> This all bothers me too. >>>> I don't want volatile. It makes the optimized code terrible. >>>> But I don't want to debug any problem from removing it, beyond compilation failure. >>>> >>>> >>>> I can try a few things. >>>> This is all wierd. I swear I saw it hang several times. >>>> I swear I'm trying to to change "too many" variables at a time. Yes, I know, 2 is too many. >>>> >>>> >>>> Once I started getting version stamp mismatch, I resorted to using a cross built cm3. >>>> Out of necessity sort of, but that causes more flucuation of variables. >>>> >>>> Let me try again with volatile and see if it is solid. >>>> Then I'll try with only volatile stores. >>>> >>>> I've been trying optimized and unoptimized, and not kept good track of which when. >>>> >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>>> From: hosking at cs.purdue.edu >>>>> Date: Sat, 3 Jul 2010 20:36:20 -0400 >>>>> To: jkrell at elego.de >>>>> CC: m3commit at elegosoft.com >>>>> Subject: Re: [M3commit] CVS Update: cm3 >>>>> >>>>> I am very disturbed that volatile is needed here. Can we selectively turn it on for thread-critical files like ThreadPThread and see if it fixes the problem. I wonder if the double-checked locking is broken for PPC memory model. Is this on a multi-processor? >>>>> >>>>> On 3 Jul 2010, at 12:57, Jay Krell wrote: >>>>> >>>>>> CVSROOT: /usr/cvs >>>>>> Changes by: jkrell at birch. 10/07/03 12:57:09 >>>>>> >>>>>> Modified files: >>>>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >>>>>> >>>>>> Log message: >>>>>> restore volatile for powerpc and powerpc64 platforms >>>>>> This seems to fix PPC_LINUX hanging. >>>>>> This needs further debugging, but I'm not eager. >>>>>> This will also affect PPC_DARWIN, PPC64_DARWIN, PPC32_OPENBSD, >>>>>> PPC32_NETBSD, PPC32_FREEBSD, etc., but these platforms are little used or >>>>>> nonexistant. >>>>>> >>>>>> Having volatile like has been the very long standing situation though. >>>>>> The result is that the optimizer does basically nothing. >>>>> >>>> >>> >> > From jay.krell at cornell.edu Sun Jul 4 17:01:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 15:01:53 +0000 Subject: [M3devel] eliminating volatile on floats In-Reply-To: References: , Message-ID: The #if 0 didn't seem to work. I'll go with ter = 0 for now. Then maybe look at what equivalent C does. I still think the problem is maybe something about alignment, more than type punning/aliases, though they are related. I checked some obvious things, like, if alignment of int/long/float/double/void* were other than I expected in C. I'll go with ter = 0 for now. I think I'll commit that as some steps forward and backward but not a bad tradeoff. Granted, I don't know really what ter is and how effective it is, but O1, O2, O3 are each a "bundle" of quite a number of optimizations. Throwing out some of them seems not too terrible. Throwing in volatile definitely defeats a lot, and probably not the ones I turn off. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Sun, 4 Jul 2010 10:49:55 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] eliminating volatile on floats > > I don't understand what we would need to do to fix this without the hack of commenting out gcc functionality. Better to give gcc something it likes than to hack it. > > On 4 Jul 2010, at 10:25, Jay K wrote: > > > > > Through simple trial/error I've tracked a need (the only need?) for floats down: > > > > If I set flag_tree_ter = 0, I can compile m3core where I couldn't before, with -O3. > > > > > > I suspect due to: > > > > builtins.c: > > > > int > > get_pointer_alignment (tree exp, unsigned int max_align) > > { > > unsigned int align, inner; > > > > /* We rely on TER to compute accurate alignment information. */ > > if (!(optimize && flag_tree_ter)) > > return 0; > > > > > > Another thing to try is #if 0 out this block of code (it is not in parse,c but "gcc itself"). > > That should yield more optimization, but more patch to gcc. > > I'm inclined to try that. > > > > > > There should be additional options, like getting the alignment correct or such. > > > > > > The code that fails to compile is: > > /dev2/cm3/m3-libs/m3core/src/float/IEEE/LongFloat.m3 > > > > > > PROCEDURE CopySign (x, y: T): T = > > VAR res := x; > > BEGIN > > LOOPHOLE (res, Rep.T).sign := LOOPHOLE (y, Rep.T).sign; > > RETURN res; > > END CopySign; > > > > > > I also tried some other options like adding volatile and/or temporaries on loophole's using t_struct. > > > > > > (To be clear, we only have volatile on float loads, not stores, though I think only stores would be preferable to only loads. > > "reads are more common than writes", "consider the registers to be a write-through cache") > > > > > > - Jay > > > From jay.krell at cornell.edu Sun Jul 4 17:50:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 15:50:03 +0000 Subject: [M3devel] volatile float/ter/copysign Message-ID: This is the code that often fails to compile. Aha, well look at that. PROCEDURE CopySign (x, y: T): T = ? VAR res := x; ? BEGIN ??? LOOPHOLE (res, Rep.T).sign := LOOPHOLE (y, Rep.T).sign; ??? RETURN res; ? END CopySign; There's no loophole! Store lreal, load int64->word8 => insert_mn => store int64->word8. There are several other ways to write this code, but I guess that's not the point. (552) begin_procedure ? procedure LongFloat__CopySign ?LongFloat__CopySign(553) set_source_line ? source line? 117 (554) load ? type:lreal ? type:lreal ? m3cg_load (M3_CtKayy_x): offset 0x0, convert lreal -> lreal (555) store ? type:lreal ? type:lreal ? store (M3_CtKayy_res) offset:0x0 src_t:lreal dst_t:lreal (556) set_source_line ? source line? 119 (557) load ? type:word8 ? type:int64 ? m3cg_load (M3_CtKayy_y): offset 0x38, convert word8 -> int64 (558) extract_mn ? type:int64 ?extract_mn offset:7 count:1 sign_extend:0 (559) load ? type:word8 ? type:int64 ? m3cg_load (M3_CtKayy_res): offset 0x38, convert word8 -> int64 (560) swap ? type:int64 ? type:int64 (561) insert_mn ? type:int64 ?insert_mn offset:7 count:1 (562) store ? type:int64 ? type:word8 ? store (M3_CtKayy_res) offset:0x38 src_t:int64 dst_t:word8 (563) set_source_line ? source line? 120 (564) load ? type:lreal ? type:lreal ? m3cg_load (M3_CtKayy_res): offset 0x0, convert lreal -> lreal (565) exit_proc ? type:lreal (566) end_procedure ?- Jay From jay.krell at cornell.edu Sun Jul 4 18:20:01 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 16:20:01 +0000 Subject: [M3devel] licensing (gcc patches) Message-ID: licensing "for the record" I don't necessarily want to discuss it.. It has been speculated here that our gcc patches weren't acceptable because our license is more restrictive than GPL. I believe it is more like the opposite. Our patches not accepted because our license is /less/ restrictive. ?To most of the code. Not to the patch or files added to gcc. ?? They can't really be. In particular, by splitting cm3 from m3cg, the license "boundary" is stopped. parse.c is/must be GPL. All the various *.m3 files not. GPL advocates would prefer GPL code be linked to more code, thus forcing more code to be GPL. Doing something like splitting "something" into two processes is kind of a deliberate anti-GPL move. It may or may not make good engineering sense. (It does and it doesn't, in fact. It is good for development/testing, bad for performance.) Lately they allow "plugins", though they must be GPL. Gcc faces "competition", e.g. LLVM. Maybe things are more relaxed now. Besides all that, non-trivial gcc patches require signing FSF papers. Something I at least am very unlikely able to do. But the vast bulk of the work I had nothing to do with. And you can remove my changs with little effect. Alternatively of course, LLVM has a more liberal license. Generating C has no licening problem. Porting m3back to more targets ditto.. ?- Jay From hendrik at topoi.pooq.com Sun Jul 4 22:04:18 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 4 Jul 2010 16:04:18 -0400 Subject: [M3devel] licensing (gcc patches) In-Reply-To: References: Message-ID: <20100704200418.GC22573@topoi.pooq.com> On Sun, Jul 04, 2010 at 04:20:01PM +0000, Jay K wrote: > > licensing > > > "for the record" > I don't necessarily want to discuss it.. > > > It has been speculated here that > our gcc patches weren't acceptable > because our license is more restrictive than GPL. > > > I believe it is more like the opposite. > Our patches not accepted because our license is /less/ restrictive. The restriction I see in the modula 3 license is everyone dealing in Modula 3 code has to allow SRC to do anything they want to any of it. This 'requirement to allow' is a restriction that doesn't apply to GPL, so in that sense we're more restrictive. In pretty well all other ways, we're less restrictive. > ?To most of the code. Not to the patch or files added to gcc. > ?They can't really be. Of course any code we *add* at this point can be dual-licensed, letting people who get it use one license, or the other, or both, at their option. -- hendrik From wagner at elegosoft.com Mon Jul 5 09:32:30 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 05 Jul 2010 09:32:30 +0200 Subject: [M3devel] licensing (gcc patches) In-Reply-To: <20100704200418.GC22573@topoi.pooq.com> References: <20100704200418.GC22573@topoi.pooq.com> Message-ID: <20100705093230.k462uhajq8cc8kkw@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Sun, Jul 04, 2010 at 04:20:01PM +0000, Jay K wrote: >> >> licensing >> >> "for the record" >> I don't necessarily want to discuss it.. >> >> >> It has been speculated here that >> our gcc patches weren't acceptable >> because our license is more restrictive than GPL. >> >> I believe it is more like the opposite. >> Our patches not accepted because our license is /less/ restrictive. > > The restriction I see in the modula 3 license is everyone dealing in > Modula 3 code has to allow SRC to do anything they want to any of it. > This 'requirement to allow' is a restriction that doesn't apply to GPL, > so in that sense we're more restrictive. > > In pretty well all other ways, we're less restrictive. The M3 licence allows free use and distribution of the code in source and binary format. There is no restriction that source must be provided if it is changed or sold or just used as a service by anyone, i.e. it is no viral license. The only provision is that _if_ patches are returned to the copyright owner (which can be DEC, Critical Mass, or others), they may use them for any purpose they wish without any restriction, too. Actually, both DEC and Critical Mass won't (any more). At least as far as I can see... >> ?To most of the code. Not to the patch or files added to gcc. >> ?They can't really be. > > Of course any code we *add* at this point can be dual-licensed, letting > people who get it use one license, or the other, or both, at their > option. Code linked with gcc must be under GPL. That's why DEC went to all this fuss with two-phase compilation using two processes. Otherwise all the M3 compiler code would need to be distributed as source by anyone who uses it, too. GPL is still pretty much a no-go for commercial use. In fact that's the reason why the FSF never accepted the M3 extensions for gcc; they didn't approve of the license `workaround'. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Jul 5 09:39:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 07:39:44 +0000 Subject: [M3devel] licensing (gcc patches) In-Reply-To: <20100704200418.GC22573@topoi.pooq.com> References: , <20100704200418.GC22573@topoi.pooq.com> Message-ID: > Of course any code we *add* at this point can be dual-licensed, letting I find "dual license" confusing. I like the BSD way, esp. OpenBSD way.Besides being "liberal", they also significantly favor "simplicity". Simple, short, clear, and also widely used. I'm talking about the license, not the code.That is, if you come up with a new license, and claim it is liberal, but it takes too muchtime/effort/money/lawyer to read and interpret, then they reject it.They reject for example Apache 2.x. Thus they stick with Apache 1.x.I kind of wish they wouldn't stick with Apache 1.x, it seems "dangerous" to lingerback on "old" versions, but I understand the reason.I don't know if they stuck with gcc 3.x to avoid bloat or to avoid GPL 3. I don't think we have a choice in the licensing of what we add, parse.c in particular.I suspect parts of it are copied from the GPL gcc C front end.That is ok. - Jay > Date: Sun, 4 Jul 2010 16:04:18 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] licensing (gcc patches) > > On Sun, Jul 04, 2010 at 04:20:01PM +0000, Jay K wrote: > > > > licensing > > > > > > "for the record" > > I don't necessarily want to discuss it.. > > > > > > It has been speculated here that > > our gcc patches weren't acceptable > > because our license is more restrictive than GPL. > > > > > > I believe it is more like the opposite. > > Our patches not accepted because our license is /less/ restrictive. > > The restriction I see in the modula 3 license is everyone dealing in > Modula 3 code has to allow SRC to do anything they want to any of it. > This 'requirement to allow' is a restriction that doesn't apply to GPL, > so in that sense we're more restrictive. > > In pretty well all other ways, we're less restrictive. > > > To most of the code. Not to the patch or files added to gcc. > > They can't really be. > > Of course any code we *add* at this point can be dual-licensed, letting > people who get it use one license, or the other, or both, at their > option. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jul 5 11:24:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 09:24:20 +0000 Subject: [M3devel] loophole/copysign Message-ID: Our codegen is remarkably low level. That is, lower level earlier than C. gcc/m3cg -ftree-dump-all As early as LongFloat.mc.003t.original, the first file dumped, we have: LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) { ? xreel M3_CtKayy__result; ? xreel M3_CtKayy_res; ??? xreel M3_CtKayy__result; ??? xreel M3_CtKayy_res; ? M3_CtKayy_res = M3_CtKayy_x; ? BIT_FIELD_REF = (word_8) ((int_64) ? BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); ? = M3_CtKayy_res; ? return ; } compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: copy_sign_f (from, to) { ? float res; ? float D.1918; ? D.1917; ? struct float_t * from.1; ? struct float_t * res.0; : ? res = to_1; ? res.0_4 = (struct float_t *) &res; ? from.1_5 = (struct float_t *) &from; ? D.1917_6 = from.1_5->sign; ? res.0_4->sign = D.1917_6; ? D.1918_7 = res; ? return D.1918_7; } See, you know, from gcc's point of view, we don't have any records/structs/unions. Just integers and offsets from them mostly. The right fix is to build up types. That way also debugging with gdb will have a chance. Perhaps not a small amount of work. But maybe not too bad. For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. At least if one type but not the other is floating point. I don't know if that will work, but maybe. Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or store volatile. ?- Jay From jay.krell at cornell.edu Mon Jul 5 12:42:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 10:42:57 +0000 Subject: [M3devel] loophole/copysign In-Reply-To: References: Message-ID: Tony, et. al.. in m3front/src/exprs/CastExpr.m3..what's the difference between a "designator" and a "value"? http://www-plan.cs.colorado.edu/diwan/modula3/designators.html An identifier is a writable designator if it is declared as a variable, is a VAR or VALUE parameter, is a local of a TYPECASE or TRY EXCEPT statement, or is a WITH local that is bound to a writable designator. An identifier is a readonly designator if it is a READONLY parameter, a local of a FOR statement, or a WITH local bound to a non-designator or readonly designator. I guess a designator is what I would think of a "variable" or "read only variable"? Something that either is "in memory" or can "reasonably" be put there? 1 + 2 is not a designator. Or, generally, a "variable", but that includes such similar things as parameters, "with variables", "for variables", "TYPECASE vairables", "TRY variables" Anything with a name??? (not functions/modules/generics -- "named data") Anyway, the next questions include: In CastExpr.m3 would it be terrible and/or wrong to treat "designators" the same as "values"? ?I realize, probably a deoptimization. ?I think this lets the backend work. ? And really, more to the point...shouldn't CastExpr.m3 use cg.loophole far more? I haven't had much luck with that. I always get the cg stack out of balance or with the wrong types, even though it seems like it should be easy. I have more testing to do, but classifying the loophole as V_to_S (value to structure) in place of D_to_S (designator to structure), at least if either side is one of the three float types, seems reasonable and correct, albeit slight deoptimization -- in unsafe code dealing with floating point..should be rare.. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 5 Jul 2010 09:24:20 +0000 > Subject: [M3devel] loophole/copysign > > > Our codegen is remarkably low level. That is, lower level earlier than C. > > > gcc/m3cg -ftree-dump-all > > > As early as LongFloat.mc.003t.original, the first file dumped, we have: > > LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) > { > xreel M3_CtKayy__result; > xreel M3_CtKayy_res; > > xreel M3_CtKayy__result; > xreel M3_CtKayy_res; > M3_CtKayy_res = M3_CtKayy_x; > BIT_FIELD_REF = (word_8) ((int_64) > BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); > = M3_CtKayy_res; > return ; > } > > compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: > > copy_sign_f (from, to) > { > float res; > float D.1918; > D.1917; > struct float_t * from.1; > struct float_t * res.0; > > : > res = to_1; > res.0_4 = (struct float_t *) &res; > from.1_5 = (struct float_t *) &from; > D.1917_6 = from.1_5->sign; > res.0_4->sign = D.1917_6; > D.1918_7 = res; > return D.1918_7; > > } > > > See, you know, from gcc's point of view, we don't have any records/structs/unions. > Just integers and offsets from them mostly. > > > The right fix is to build up types. > That way also debugging with gdb will have a chance. > Perhaps not a small amount of work. But maybe not too bad. > > > For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. > At least if one type but not the other is floating point. > I don't know if that will work, but maybe. > > Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or > store volatile. > > - Jay > From jay.krell at cornell.edu Mon Jul 5 13:25:19 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 11:25:19 +0000 Subject: [M3devel] loophole/copysign In-Reply-To: References: , Message-ID: Hm. it seems that it might be important to preserve the "designatorness", like in: libm3/...RandomReal.m3: ? VAR frac, exp: INTEGER; result: LONGREAL; ??? (* Repack as LONGREAL: *) ??? WITH lr = LOOPHOLE (result, LongRealRep.T) DO ????? lr.sign := 0; ????? lr.exponent := exp; ????? lr.significand0 := Word.Shift (Word.And (frac, 16_7fffffff), ????????????????????????????????????? -(WordSize - 1 - FractionBits)); ????? lr.significand1 := r.integer (min := -16_7fffffff-1, max :=16_7fffffff); ??? END; ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 5 Jul 2010 10:42:57 +0000 > Subject: Re: [M3devel] loophole/copysign > > > Tony, et. al.. in m3front/src/exprs/CastExpr.m3..what's the difference between a "designator" and a "value"? > > > http://www-plan.cs.colorado.edu/diwan/modula3/designators.html > > An identifier is a writable designator > if it is declared as a variable, > is a VAR or VALUE parameter, > is a local of a TYPECASE > or TRY EXCEPT statement, > or is a WITH local that is bound to a writable designator. > An identifier is a readonly designator if it is > a READONLY parameter, > a local of a FOR statement, > or a WITH local bound to a non-designator or > readonly designator. > > > > I guess a designator is what I would think of a "variable" or "read only variable"? > Something that either is "in memory" or can "reasonably" be put there? > > > 1 + 2 is not a designator. > > > Or, generally, a "variable", but that includes such similar things as parameters, "with variables", "for variables", "TYPECASE vairables", "TRY variables" > > > Anything with a name??? (not functions/modules/generics -- "named data") > > > Anyway, the next questions include: > > > In CastExpr.m3 would it be terrible and/or wrong to treat "designators" the same as "values"? > I realize, probably a deoptimization. > I think this lets the backend work. > > > And really, more to the point...shouldn't CastExpr.m3 use cg.loophole far more? > I haven't had much luck with that. I always get the cg stack out of balance or with the wrong types, even though it seems like it should be easy. > > > I have more testing to do, but classifying the loophole as V_to_S (value to structure) in place of D_to_S (designator to structure), at least if either side is one of the three float types, seems reasonable and correct, albeit slight deoptimization -- in unsafe code dealing with floating point..should be rare.. > > > - Jay > > > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Date: Mon, 5 Jul 2010 09:24:20 +0000 > > Subject: [M3devel] loophole/copysign > > > > > > Our codegen is remarkably low level. That is, lower level earlier than C. > > > > > > gcc/m3cg -ftree-dump-all > > > > > > As early as LongFloat.mc.003t.original, the first file dumped, we have: > > > > LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) > > { > > xreel M3_CtKayy__result; > > xreel M3_CtKayy_res; > > > > xreel M3_CtKayy__result; > > xreel M3_CtKayy_res; > > M3_CtKayy_res = M3_CtKayy_x; > > BIT_FIELD_REF = (word_8) ((int_64) > > BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); > > = M3_CtKayy_res; > > return ; > > } > > > > compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: > > > > copy_sign_f (from, to) > > { > > float res; > > float D.1918; > > D.1917; > > struct float_t * from.1; > > struct float_t * res.0; > > > > : > > res = to_1; > > res.0_4 = (struct float_t *) &res; > > from.1_5 = (struct float_t *) &from; > > D.1917_6 = from.1_5->sign; > > res.0_4->sign = D.1917_6; > > D.1918_7 = res; > > return D.1918_7; > > > > } > > > > > > See, you know, from gcc's point of view, we don't have any records/structs/unions. > > Just integers and offsets from them mostly. > > > > > > The right fix is to build up types. > > That way also debugging with gdb will have a chance. > > Perhaps not a small amount of work. But maybe not too bad. > > > > > > For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. > > At least if one type but not the other is floating point. > > I don't know if that will work, but maybe. > > > > Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or > > store volatile. > > > > - Jay > > > From jay.krell at cornell.edu Mon Jul 5 13:36:11 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 11:36:11 +0000 Subject: [M3devel] loophole/copysign In-Reply-To: References: , , , Message-ID: another idea: let's not use bitfield ref for float/double ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 5 Jul 2010 11:25:19 +0000 > Subject: Re: [M3devel] loophole/copysign > > > Hm. it seems that it might be important to preserve the "designatorness", like in: > > libm3/...RandomReal.m3: > > VAR frac, exp: INTEGER; result: LONGREAL; > > (* Repack as LONGREAL: *) > WITH lr = LOOPHOLE (result, LongRealRep.T) DO > lr.sign := 0; > lr.exponent := exp; > lr.significand0 := Word.Shift (Word.And (frac, 16_7fffffff), > -(WordSize - 1 - FractionBits)); > lr.significand1 := r.integer (min := -16_7fffffff-1, max :=16_7fffffff); > END; > > > - Jay > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Date: Mon, 5 Jul 2010 10:42:57 +0000 > > Subject: Re: [M3devel] loophole/copysign > > > > > > Tony, et. al.. in m3front/src/exprs/CastExpr.m3..what's the difference between a "designator" and a "value"? > > > > > > http://www-plan.cs.colorado.edu/diwan/modula3/designators.html > > > > An identifier is a writable designator > > if it is declared as a variable, > > is a VAR or VALUE parameter, > > is a local of a TYPECASE > > or TRY EXCEPT statement, > > or is a WITH local that is bound to a writable designator. > > An identifier is a readonly designator if it is > > a READONLY parameter, > > a local of a FOR statement, > > or a WITH local bound to a non-designator or > > readonly designator. > > > > > > > > I guess a designator is what I would think of a "variable" or "read only variable"? > > Something that either is "in memory" or can "reasonably" be put there? > > > > > > 1 + 2 is not a designator. > > > > > > Or, generally, a "variable", but that includes such similar things as parameters, "with variables", "for variables", "TYPECASE vairables", "TRY variables" > > > > > > Anything with a name??? (not functions/modules/generics -- "named data") > > > > > > Anyway, the next questions include: > > > > > > In CastExpr.m3 would it be terrible and/or wrong to treat "designators" the same as "values"? > > I realize, probably a deoptimization. > > I think this lets the backend work. > > > > > > And really, more to the point...shouldn't CastExpr.m3 use cg.loophole far more? > > I haven't had much luck with that. I always get the cg stack out of balance or with the wrong types, even though it seems like it should be easy. > > > > > > I have more testing to do, but classifying the loophole as V_to_S (value to structure) in place of D_to_S (designator to structure), at least if either side is one of the three float types, seems reasonable and correct, albeit slight deoptimization -- in unsafe code dealing with floating point..should be rare.. > > > > > > - Jay > > > > > > > > ---------------------------------------- > > > From: jay.krell at cornell.edu > > > To: m3devel at elegosoft.com > > > Date: Mon, 5 Jul 2010 09:24:20 +0000 > > > Subject: [M3devel] loophole/copysign > > > > > > > > > Our codegen is remarkably low level. That is, lower level earlier than C. > > > > > > > > > gcc/m3cg -ftree-dump-all > > > > > > > > > As early as LongFloat.mc.003t.original, the first file dumped, we have: > > > > > > LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) > > > { > > > xreel M3_CtKayy__result; > > > xreel M3_CtKayy_res; > > > > > > xreel M3_CtKayy__result; > > > xreel M3_CtKayy_res; > > > M3_CtKayy_res = M3_CtKayy_x; > > > BIT_FIELD_REF = (word_8) ((int_64) > > > BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); > > > = M3_CtKayy_res; > > > return ; > > > } > > > > > > compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: > > > > > > copy_sign_f (from, to) > > > { > > > float res; > > > float D.1918; > > > D.1917; > > > struct float_t * from.1; > > > struct float_t * res.0; > > > > > > : > > > res = to_1; > > > res.0_4 = (struct float_t *) &res; > > > from.1_5 = (struct float_t *) &from; > > > D.1917_6 = from.1_5->sign; > > > res.0_4->sign = D.1917_6; > > > D.1918_7 = res; > > > return D.1918_7; > > > > > > } > > > > > > > > > See, you know, from gcc's point of view, we don't have any records/structs/unions. > > > Just integers and offsets from them mostly. > > > > > > > > > The right fix is to build up types. > > > That way also debugging with gdb will have a chance. > > > Perhaps not a small amount of work. But maybe not too bad. > > > > > > > > > For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. > > > At least if one type but not the other is floating point. > > > I don't know if that will work, but maybe. > > > > > > Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or > > > store volatile. > > > > > > - Jay > > > > > > From hendrik at topoi.pooq.com Mon Jul 5 14:24:15 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 5 Jul 2010 08:24:15 -0400 Subject: [M3devel] licensing (gcc patches) In-Reply-To: <20100705093230.k462uhajq8cc8kkw@mail.elegosoft.com> References: <20100704200418.GC22573@topoi.pooq.com> <20100705093230.k462uhajq8cc8kkw@mail.elegosoft.com> Message-ID: <20100705122414.GB27490@topoi.pooq.com> On Mon, Jul 05, 2010 at 09:32:30AM +0200, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > >> On Sun, Jul 04, 2010 at 04:20:01PM +0000, Jay K wrote: >>> >>> licensing >>> >>> "for the record" >>> I don't necessarily want to discuss it.. >>> >>> >>> It has been speculated here that >>> our gcc patches weren't acceptable >>> because our license is more restrictive than GPL. >>> >>> I believe it is more like the opposite. >>> Our patches not accepted because our license is /less/ restrictive. >> >> The restriction I see in the modula 3 license is everyone dealing in >> Modula 3 code has to allow SRC to do anything they want to any of it. >> This 'requirement to allow' is a restriction that doesn't apply to GPL, >> so in that sense we're more restrictive. >> >> In pretty well all other ways, we're less restrictive. > > The M3 licence allows free use and distribution of the code in source > and binary format. There is no restriction that source must be provided > if it is changed or sold or just used as a service by anyone, i.e. it is > no viral license. > > The only provision is that _if_ patches are returned to the copyright owner > (which can be DEC, Critical Mass, or others), they may use them for any > purpose they wish without any restriction, too. > > Actually, both DEC and Critical Mass won't (any more). At least as far > as I can see... > >>> ?To most of the code. Not to the patch or files added to gcc. >>> ?They can't really be. >> >> Of course any code we *add* at this point can be dual-licensed, letting >> people who get it use one license, or the other, or both, at their >> option. > > Code linked with gcc must be under GPL. That's why DEC went to all > this fuss with two-phase compilation using two processes. Otherwise all > the M3 compiler code would need to be distributed as source by anyone > who uses it, too. But code can be released under more than one licence, the SRC license *and* the GPL, for example. Of course, that would require the copyright holders to do that. > GPL is still pretty much a no-go for commercial use. > > In fact that's the reason why the FSF never accepted the M3 extensions > for gcc; they didn't approve of the license `workaround'. So the issue here is not wiether the M3 extensions to gcc are GPL'd, butwhether the FSF is willing to accept them into their gcc distribution? -- hendrik. From hendrik at topoi.pooq.com Mon Jul 5 14:39:55 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 5 Jul 2010 08:39:55 -0400 Subject: [M3devel] licensing (gcc patches) In-Reply-To: References: <20100704200418.GC22573@topoi.pooq.com> Message-ID: <20100705123955.GC27490@topoi.pooq.com> On Mon, Jul 05, 2010 at 07:39:44AM +0000, Jay K wrote: > > > Of course any code we *add* at this point can be dual-licensed, letting > I find "dual license" confusing. Each licence gives potential clients certain rights. If they follow the restrictions in either licence, they have the privileges granted by that licence. If they follow the restrictions of both, they have the privileges granted by both. If all of out new code were to be dual-licensed, we'd be compatible with the SRC licence (pretty easy to be), and our new code could be taken by anyone and used and redistributed under the GPL on its own. Whether it would be useful on its own is another question. GPL becomes restrictive is when you don't have the permission of all the copyright holders to change licenses. As in our case, where we, as far as I can tell, can't get it from SRC, perhaps only because they just don't care at all about the matter any more. > > I like the BSD way, esp. OpenBSD way.Besides being "liberal", they > also significantly favor "simplicity". Simple, short, clear, and also > widely used. I'm talking about the license, not the code.That is, if > you come up with a new license, and claim it is liberal, but it takes > too muchtime/effort/money/lawyer to read and interpret, then they > reject it.They reject for example Apache 2.x. Thus they stick with > Apache 1.x.I kind of wish they wouldn't stick with Apache 1.x, it > seems "dangerous" to lingerback on "old" versions, but I understand > the reason.I don't know if they stuck with gcc 3.x to avoid bloat or > to avoid GPL 3. > > I don't think we have a choice in the licensing of what we add, > parse.c in particular. I suspect parts of it are copied from the GPL > gcc C front end. That is ok. And that restricts us from distributing parse.c other than under the GPL. We can't dual-licence that bit. Is parse.c part of our modified gcc back end? If so, yes, that is OK. -- hendrik From jay.krell at cornell.edu Mon Jul 5 14:49:18 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 12:49:18 +0000 Subject: [M3devel] licensing (gcc patches) In-Reply-To: <20100705123955.GC27490@topoi.pooq.com> References: <20100704200418.GC22573@topoi.pooq.com>, , <20100705123955.GC27490@topoi.pooq.com> Message-ID: Yes parse.c is a new file added to gcc and contains the bulk of our work on gcc. There are some other small files and small diffs, but parse.c is really it. parse.c: the name seems wrong, but if you consider that from gcc's point of view, we are a front end, then it makes sense. As a front end to gcc, our "source language" is very odd, it is binary files encoding the sequence of function calls the "actual" frontend would have me to an "actual" backend. ?- Jay ---------------------------------------- > Date: Mon, 5 Jul 2010 08:39:55 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] licensing (gcc patches) > > On Mon, Jul 05, 2010 at 07:39:44AM +0000, Jay K wrote: > > > > > Of course any code we *add* at this point can be dual-licensed, letting > > I find "dual license" confusing. > > Each licence gives potential clients certain rights. If they follow > the restrictions in either licence, they have the privileges granted by > that licence. If they follow the restrictions of both, they have the > privileges granted by both. > > If all of out new code were to be dual-licensed, we'd be compatible with > the SRC licence (pretty easy to be), and our new code could be taken by > anyone and used and redistributed under the GPL on its own. Whether it > would be useful on its own is another question. > > GPL becomes restrictive is when you don't have the permission of all the > copyright holders to change licenses. As in our case, where we, as far > as I can tell, can't get it from SRC, perhaps only because they just > don't care at all about the matter any more. > > > > > I like the BSD way, esp. OpenBSD way.Besides being "liberal", they > > also significantly favor "simplicity". Simple, short, clear, and also > > widely used. I'm talking about the license, not the code.That is, if > > you come up with a new license, and claim it is liberal, but it takes > > too muchtime/effort/money/lawyer to read and interpret, then they > > reject it.They reject for example Apache 2.x. Thus they stick with > > Apache 1.x.I kind of wish they wouldn't stick with Apache 1.x, it > > seems "dangerous" to lingerback on "old" versions, but I understand > > the reason.I don't know if they stuck with gcc 3.x to avoid bloat or > > to avoid GPL 3. > > > > I don't think we have a choice in the licensing of what we add, > > parse.c in particular. I suspect parts of it are copied from the GPL > > gcc C front end. That is ok. > > And that restricts us from distributing parse.c other than under the > GPL. We can't dual-licence that bit. Is parse.c part of our modified > gcc back end? If so, yes, that is OK. > > -- hendrik From jay.krell at cornell.edu Mon Jul 5 14:56:23 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 12:56:23 +0000 Subject: [M3devel] loophole/copysign In-Reply-To: References: , , , , Message-ID: nope. I know this is gross, but how about we addd CG.make_volatile that front end can call very sparingly, that acts just like generating a call to setjmp or vfork -- in that it makes locals, parameters, temporaries in current function as volatile? CastExpr.m3 would call it for D_to_S and FloatType[src] # FloatType[dest]. It would be available as a desparate measure if we find other problems. To selectively inhibit optimization a function at a time. ? Which, granted, is generally overkill. I'm trying this now.. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: RE: [M3devel] loophole/copysign > Date: Mon, 5 Jul 2010 11:36:11 +0000 > > > another idea: let's not use bitfield ref for float/double > > - Jay > > > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Date: Mon, 5 Jul 2010 11:25:19 +0000 > > Subject: Re: [M3devel] loophole/copysign > > > > > > Hm. it seems that it might be important to preserve the "designatorness", like in: > > > > libm3/...RandomReal.m3: > > > > VAR frac, exp: INTEGER; result: LONGREAL; > > > > (* Repack as LONGREAL: *) > > WITH lr = LOOPHOLE (result, LongRealRep.T) DO > > lr.sign := 0; > > lr.exponent := exp; > > lr.significand0 := Word.Shift (Word.And (frac, 16_7fffffff), > > -(WordSize - 1 - FractionBits)); > > lr.significand1 := r.integer (min := -16_7fffffff-1, max :=16_7fffffff); > > END; > > > > > > - Jay > > > > ---------------------------------------- > > > From: jay.krell at cornell.edu > > > To: m3devel at elegosoft.com > > > Date: Mon, 5 Jul 2010 10:42:57 +0000 > > > Subject: Re: [M3devel] loophole/copysign > > > > > > > > > Tony, et. al.. in m3front/src/exprs/CastExpr.m3..what's the difference between a "designator" and a "value"? > > > > > > > > > http://www-plan.cs.colorado.edu/diwan/modula3/designators.html > > > > > > An identifier is a writable designator > > > if it is declared as a variable, > > > is a VAR or VALUE parameter, > > > is a local of a TYPECASE > > > or TRY EXCEPT statement, > > > or is a WITH local that is bound to a writable designator. > > > An identifier is a readonly designator if it is > > > a READONLY parameter, > > > a local of a FOR statement, > > > or a WITH local bound to a non-designator or > > > readonly designator. > > > > > > > > > > > > I guess a designator is what I would think of a "variable" or "read only variable"? > > > Something that either is "in memory" or can "reasonably" be put there? > > > > > > > > > 1 + 2 is not a designator. > > > > > > > > > Or, generally, a "variable", but that includes such similar things as parameters, "with variables", "for variables", "TYPECASE vairables", "TRY variables" > > > > > > > > > Anything with a name??? (not functions/modules/generics -- "named data") > > > > > > > > > Anyway, the next questions include: > > > > > > > > > In CastExpr.m3 would it be terrible and/or wrong to treat "designators" the same as "values"? > > > I realize, probably a deoptimization. > > > I think this lets the backend work. > > > > > > > > > And really, more to the point...shouldn't CastExpr.m3 use cg.loophole far more? > > > I haven't had much luck with that. I always get the cg stack out of balance or with the wrong types, even though it seems like it should be easy. > > > > > > > > > I have more testing to do, but classifying the loophole as V_to_S (value to structure) in place of D_to_S (designator to structure), at least if either side is one of the three float types, seems reasonable and correct, albeit slight deoptimization -- in unsafe code dealing with floating point..should be rare.. > > > > > > > > > - Jay > > > > > > > > > > > > ---------------------------------------- > > > > From: jay.krell at cornell.edu > > > > To: m3devel at elegosoft.com > > > > Date: Mon, 5 Jul 2010 09:24:20 +0000 > > > > Subject: [M3devel] loophole/copysign > > > > > > > > > > > > Our codegen is remarkably low level. That is, lower level earlier than C. > > > > > > > > > > > > gcc/m3cg -ftree-dump-all > > > > > > > > > > > > As early as LongFloat.mc.003t.original, the first file dumped, we have: > > > > > > > > LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) > > > > { > > > > xreel M3_CtKayy__result; > > > > xreel M3_CtKayy_res; > > > > > > > > xreel M3_CtKayy__result; > > > > xreel M3_CtKayy_res; > > > > M3_CtKayy_res = M3_CtKayy_x; > > > > BIT_FIELD_REF = (word_8) ((int_64) > > > > BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); > > > > = M3_CtKayy_res; > > > > return ; > > > > } > > > > > > > > compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: > > > > > > > > copy_sign_f (from, to) > > > > { > > > > float res; > > > > float D.1918; > > > > D.1917; > > > > struct float_t * from.1; > > > > struct float_t * res.0; > > > > > > > > : > > > > res = to_1; > > > > res.0_4 = (struct float_t *) &res; > > > > from.1_5 = (struct float_t *) &from; > > > > D.1917_6 = from.1_5->sign; > > > > res.0_4->sign = D.1917_6; > > > > D.1918_7 = res; > > > > return D.1918_7; > > > > > > > > } > > > > > > > > > > > > See, you know, from gcc's point of view, we don't have any records/structs/unions. > > > > Just integers and offsets from them mostly. > > > > > > > > > > > > The right fix is to build up types. > > > > That way also debugging with gdb will have a chance. > > > > Perhaps not a small amount of work. But maybe not too bad. > > > > > > > > > > > > For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. > > > > At least if one type but not the other is floating point. > > > > I don't know if that will work, but maybe. > > > > > > > > Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or > > > > store volatile. > > > > > > > > - Jay > > > > > > > > > > From hendrik at topoi.pooq.com Mon Jul 5 17:25:07 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 5 Jul 2010 11:25:07 -0400 Subject: [M3devel] licensing (gcc patches) In-Reply-To: References: <20100705123955.GC27490@topoi.pooq.com> Message-ID: <20100705152506.GE27490@topoi.pooq.com> On Mon, Jul 05, 2010 at 12:49:18PM +0000, Jay K wrote: > > Yes parse.c is a new file added to gcc and contains the bulk of our work on gcc. > There are some other small files and small diffs, but parse.c is really it. > > parse.c: the name seems wrong, but if you consider that from gcc's point of view, > we are a front end, then it makes sense. As a front end to gcc, our "source language" > is very odd, it is binary files encoding the sequence of function calls the "actual" > frontend would have me to an "actual" backend. I like that technique. It's similar to the intermediate code the coq proof checker produces after it's proved a theorem -- a file coding the sequence of calls to the elementary proof rules that turned out to be actually needed to get to the conclusion. It stores these files in a library, so it can read them in later and reprove the theorem quickly in case you need it again. It beats cryptographic signatures for security. I wonder if the FSF gang would look at parse.c differently if there were other compilers, GPLed ones, that use your back end. -- hendrik From dabenavidesd at yahoo.es Mon Jul 5 19:17:26 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 5 Jul 2010 17:17:26 +0000 (GMT) Subject: [M3devel] licensing (gcc patches) In-Reply-To: <20100705152506.GE27490@topoi.pooq.com> Message-ID: <495012.96539.qm@web23608.mail.ird.yahoo.com> Hi all: I think as is pointed out original developers copyright holders must be at the public domain as they are not present anymore and nobody seems to reclaim if there is any wanting to hold them as they don't have nobody who uses it as far as we know. So it probably needs to be a process of release of this holders to the public domain and especially the owners of the linked code would not regret having the hold as far as they return what they did to the originals which I believe don't or wouldn't hesitate to receive. If they do hesitate to receive they would be admitting they are not anymore owners of it and the changes would and shall be returned to somebody who will receive for them as to allow any wanting to do changes. I don't think FSF would accept to do that procedure. What shall we do then? --- El lun, 5/7/10, hendrik at topoi.pooq.com escribi?: > De: hendrik at topoi.pooq.com > Asunto: Re: [M3devel] licensing (gcc patches) > Para: m3devel at elegosoft.com > Fecha: lunes, 5 de julio, 2010 10:25 > On Mon, Jul 05, 2010 at 12:49:18PM > +0000, Jay K wrote: > > > > Yes parse.c is a new file added to gcc and contains > the bulk of our work on gcc. > > There are some other small files and small diffs, but > parse.c is really it. > > > > parse.c: the name seems wrong, but if you consider > that from gcc's point of view, > > we are a front end, then it makes sense. As a front > end to gcc, our "source language" > > is very odd, it is binary files encoding the sequence > of function calls the "actual" > > frontend would have me to an "actual" backend. > > I like that technique. It's similar to the > intermediate code the coq > proof checker produces after it's proved a theorem -- a > file > coding the sequence of calls to the elementary proof rules > that turned > out to be actually needed to get to the conclusion. > It stores these > files in a library, so it can read them in later and > reprove the theorem > quickly in case you need it again. It beats > cryptographic signatures > for security. > > I wonder if the FSF gang would look at parse.c differently > if there were > other compilers, GPLed ones, that use your back end. > > -- hendrik > From hosking at cs.purdue.edu Mon Jul 5 20:24:01 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 14:24:01 -0400 Subject: [M3devel] loophole/copysign In-Reply-To: References: Message-ID: <3267416E-1152-4A3D-A4C0-491F2C5FF74D@cs.purdue.edu> We shouldn't need a barrier here. That is for memory operations, whereas these need not be. I would hate to make this change. Why can't we produce gcc trees that accomplish what we need? On 5 Jul 2010, at 05:24, Jay K wrote: > > Our codegen is remarkably low level. That is, lower level earlier than C. > > > gcc/m3cg -ftree-dump-all > > > As early as LongFloat.mc.003t.original, the first file dumped, we have: > > LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) > { > xreel M3_CtKayy__result; > xreel M3_CtKayy_res; > > xreel M3_CtKayy__result; > xreel M3_CtKayy_res; > M3_CtKayy_res = M3_CtKayy_x; > BIT_FIELD_REF = (word_8) ((int_64) > BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); > = M3_CtKayy_res; > return ; > } > > compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: > > copy_sign_f (from, to) > { > float res; > float D.1918; > D.1917; > struct float_t * from.1; > struct float_t * res.0; > > : > res = to_1; > res.0_4 = (struct float_t *) &res; > from.1_5 = (struct float_t *) &from; > D.1917_6 = from.1_5->sign; > res.0_4->sign = D.1917_6; > D.1918_7 = res; > return D.1918_7; > > } > > > See, you know, from gcc's point of view, we don't have any records/structs/unions. > Just integers and offsets from them mostly. > > > The right fix is to build up types. > That way also debugging with gdb will have a chance. > Perhaps not a small amount of work. But maybe not too bad. > > > For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. > At least if one type but not the other is floating point. > I don't know if that will work, but maybe. > > Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or > store volatile. > > - Jay > From hosking at cs.purdue.edu Mon Jul 5 20:24:56 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 14:24:56 -0400 Subject: [M3devel] loophole/copysign In-Reply-To: References: Message-ID: <2F356C4B-5541-489B-B957-E3D295F549F5@cs.purdue.edu> A designator is something that can be assigned to as well as read from. It says nothing about it being in memory. A value cannot be assigned to. On 5 Jul 2010, at 06:42, Jay K wrote: > > Tony, et. al.. in m3front/src/exprs/CastExpr.m3..what's the difference between a "designator" and a "value"? > > > http://www-plan.cs.colorado.edu/diwan/modula3/designators.html > > An identifier is a writable designator > if it is declared as a variable, > is a VAR or VALUE parameter, > is a local of a TYPECASE > or TRY EXCEPT statement, > or is a WITH local that is bound to a writable designator. > An identifier is a readonly designator if it is > a READONLY parameter, > a local of a FOR statement, > or a WITH local bound to a non-designator or > readonly designator. > > > > I guess a designator is what I would think of a "variable" or "read only variable"? > Something that either is "in memory" or can "reasonably" be put there? > > > 1 + 2 is not a designator. > > > Or, generally, a "variable", but that includes such similar things as parameters, "with variables", "for variables", "TYPECASE vairables", "TRY variables" > > > Anything with a name??? (not functions/modules/generics -- "named data") > > > Anyway, the next questions include: > > > In CastExpr.m3 would it be terrible and/or wrong to treat "designators" the same as "values"? > I realize, probably a deoptimization. > I think this lets the backend work. > > > And really, more to the point...shouldn't CastExpr.m3 use cg.loophole far more? > I haven't had much luck with that. I always get the cg stack out of balance or with the wrong types, even though it seems like it should be easy. > > > I have more testing to do, but classifying the loophole as V_to_S (value to structure) in place of D_to_S (designator to structure), at least if either side is one of the three float types, seems reasonable and correct, albeit slight deoptimization -- in unsafe code dealing with floating point..should be rare.. > > > - Jay > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Date: Mon, 5 Jul 2010 09:24:20 +0000 >> Subject: [M3devel] loophole/copysign >> >> >> Our codegen is remarkably low level. That is, lower level earlier than C. >> >> >> gcc/m3cg -ftree-dump-all >> >> >> As early as LongFloat.mc.003t.original, the first file dumped, we have: >> >> LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) >> { >> xreel M3_CtKayy__result; >> xreel M3_CtKayy_res; >> >> xreel M3_CtKayy__result; >> xreel M3_CtKayy_res; >> M3_CtKayy_res = M3_CtKayy_x; >> BIT_FIELD_REF = (word_8) ((int_64) >> BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); >> = M3_CtKayy_res; >> return ; >> } >> >> compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: >> >> copy_sign_f (from, to) >> { >> float res; >> float D.1918; >> D.1917; >> struct float_t * from.1; >> struct float_t * res.0; >> >> : >> res = to_1; >> res.0_4 = (struct float_t *) &res; >> from.1_5 = (struct float_t *) &from; >> D.1917_6 = from.1_5->sign; >> res.0_4->sign = D.1917_6; >> D.1918_7 = res; >> return D.1918_7; >> >> } >> >> >> See, you know, from gcc's point of view, we don't have any records/structs/unions. >> Just integers and offsets from them mostly. >> >> >> The right fix is to build up types. >> That way also debugging with gdb will have a chance. >> Perhaps not a small amount of work. But maybe not too bad. >> >> >> For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. >> At least if one type but not the other is floating point. >> I don't know if that will work, but maybe. >> >> Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or >> store volatile. >> >> - Jay >> > From hosking at cs.purdue.edu Mon Jul 5 20:25:17 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 14:25:17 -0400 Subject: [M3devel] loophole/copysign In-Reply-To: References: , , , Message-ID: <01D93A8D-8D43-4D9A-A753-6B2D41C03F52@cs.purdue.edu> Yes, maybe that is the best way forward. On 5 Jul 2010, at 07:36, Jay K wrote: > > another idea: let's not use bitfield ref for float/double > > - Jay > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Date: Mon, 5 Jul 2010 11:25:19 +0000 >> Subject: Re: [M3devel] loophole/copysign >> >> >> Hm. it seems that it might be important to preserve the "designatorness", like in: >> >> libm3/...RandomReal.m3: >> >> VAR frac, exp: INTEGER; result: LONGREAL; >> >> (* Repack as LONGREAL: *) >> WITH lr = LOOPHOLE (result, LongRealRep.T) DO >> lr.sign := 0; >> lr.exponent := exp; >> lr.significand0 := Word.Shift (Word.And (frac, 16_7fffffff), >> -(WordSize - 1 - FractionBits)); >> lr.significand1 := r.integer (min := -16_7fffffff-1, max :=16_7fffffff); >> END; >> >> >> - Jay >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: m3devel at elegosoft.com >>> Date: Mon, 5 Jul 2010 10:42:57 +0000 >>> Subject: Re: [M3devel] loophole/copysign >>> >>> >>> Tony, et. al.. in m3front/src/exprs/CastExpr.m3..what's the difference between a "designator" and a "value"? >>> >>> >>> http://www-plan.cs.colorado.edu/diwan/modula3/designators.html >>> >>> An identifier is a writable designator >>> if it is declared as a variable, >>> is a VAR or VALUE parameter, >>> is a local of a TYPECASE >>> or TRY EXCEPT statement, >>> or is a WITH local that is bound to a writable designator. >>> An identifier is a readonly designator if it is >>> a READONLY parameter, >>> a local of a FOR statement, >>> or a WITH local bound to a non-designator or >>> readonly designator. >>> >>> >>> >>> I guess a designator is what I would think of a "variable" or "read only variable"? >>> Something that either is "in memory" or can "reasonably" be put there? >>> >>> >>> 1 + 2 is not a designator. >>> >>> >>> Or, generally, a "variable", but that includes such similar things as parameters, "with variables", "for variables", "TYPECASE vairables", "TRY variables" >>> >>> >>> Anything with a name??? (not functions/modules/generics -- "named data") >>> >>> >>> Anyway, the next questions include: >>> >>> >>> In CastExpr.m3 would it be terrible and/or wrong to treat "designators" the same as "values"? >>> I realize, probably a deoptimization. >>> I think this lets the backend work. >>> >>> >>> And really, more to the point...shouldn't CastExpr.m3 use cg.loophole far more? >>> I haven't had much luck with that. I always get the cg stack out of balance or with the wrong types, even though it seems like it should be easy. >>> >>> >>> I have more testing to do, but classifying the loophole as V_to_S (value to structure) in place of D_to_S (designator to structure), at least if either side is one of the three float types, seems reasonable and correct, albeit slight deoptimization -- in unsafe code dealing with floating point..should be rare.. >>> >>> >>> - Jay >>> >>> >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: m3devel at elegosoft.com >>>> Date: Mon, 5 Jul 2010 09:24:20 +0000 >>>> Subject: [M3devel] loophole/copysign >>>> >>>> >>>> Our codegen is remarkably low level. That is, lower level earlier than C. >>>> >>>> >>>> gcc/m3cg -ftree-dump-all >>>> >>>> >>>> As early as LongFloat.mc.003t.original, the first file dumped, we have: >>>> >>>> LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) >>>> { >>>> xreel M3_CtKayy__result; >>>> xreel M3_CtKayy_res; >>>> >>>> xreel M3_CtKayy__result; >>>> xreel M3_CtKayy_res; >>>> M3_CtKayy_res = M3_CtKayy_x; >>>> BIT_FIELD_REF = (word_8) ((int_64) >>>> BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); >>>> = M3_CtKayy_res; >>>> return ; >>>> } >>>> >>>> compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: >>>> >>>> copy_sign_f (from, to) >>>> { >>>> float res; >>>> float D.1918; >>>> D.1917; >>>> struct float_t * from.1; >>>> struct float_t * res.0; >>>> >>>> : >>>> res = to_1; >>>> res.0_4 = (struct float_t *) &res; >>>> from.1_5 = (struct float_t *) &from; >>>> D.1917_6 = from.1_5->sign; >>>> res.0_4->sign = D.1917_6; >>>> D.1918_7 = res; >>>> return D.1918_7; >>>> >>>> } >>>> >>>> >>>> See, you know, from gcc's point of view, we don't have any records/structs/unions. >>>> Just integers and offsets from them mostly. >>>> >>>> >>>> The right fix is to build up types. >>>> That way also debugging with gdb will have a chance. >>>> Perhaps not a small amount of work. But maybe not too bad. >>>> >>>> >>>> For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. >>>> At least if one type but not the other is floating point. >>>> I don't know if that will work, but maybe. >>>> >>>> Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or >>>> store volatile. >>>> >>>> - Jay >>>> >>> >> > From hosking at cs.purdue.edu Mon Jul 5 20:25:33 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 14:25:33 -0400 Subject: [M3devel] loophole/copysign In-Reply-To: References: , Message-ID: <195E2A33-B6BD-4554-9FAD-47E0445FBB46@cs.purdue.edu> Indeed. On 5 Jul 2010, at 07:25, Jay K wrote: > > Hm. it seems that it might be important to preserve the "designatorness", like in: > > libm3/...RandomReal.m3: > > VAR frac, exp: INTEGER; result: LONGREAL; > > (* Repack as LONGREAL: *) > WITH lr = LOOPHOLE (result, LongRealRep.T) DO > lr.sign := 0; > lr.exponent := exp; > lr.significand0 := Word.Shift (Word.And (frac, 16_7fffffff), > -(WordSize - 1 - FractionBits)); > lr.significand1 := r.integer (min := -16_7fffffff-1, max :=16_7fffffff); > END; > > > - Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Date: Mon, 5 Jul 2010 10:42:57 +0000 >> Subject: Re: [M3devel] loophole/copysign >> >> >> Tony, et. al.. in m3front/src/exprs/CastExpr.m3..what's the difference between a "designator" and a "value"? >> >> >> http://www-plan.cs.colorado.edu/diwan/modula3/designators.html >> >> An identifier is a writable designator >> if it is declared as a variable, >> is a VAR or VALUE parameter, >> is a local of a TYPECASE >> or TRY EXCEPT statement, >> or is a WITH local that is bound to a writable designator. >> An identifier is a readonly designator if it is >> a READONLY parameter, >> a local of a FOR statement, >> or a WITH local bound to a non-designator or >> readonly designator. >> >> >> >> I guess a designator is what I would think of a "variable" or "read only variable"? >> Something that either is "in memory" or can "reasonably" be put there? >> >> >> 1 + 2 is not a designator. >> >> >> Or, generally, a "variable", but that includes such similar things as parameters, "with variables", "for variables", "TYPECASE vairables", "TRY variables" >> >> >> Anything with a name??? (not functions/modules/generics -- "named data") >> >> >> Anyway, the next questions include: >> >> >> In CastExpr.m3 would it be terrible and/or wrong to treat "designators" the same as "values"? >> I realize, probably a deoptimization. >> I think this lets the backend work. >> >> >> And really, more to the point...shouldn't CastExpr.m3 use cg.loophole far more? >> I haven't had much luck with that. I always get the cg stack out of balance or with the wrong types, even though it seems like it should be easy. >> >> >> I have more testing to do, but classifying the loophole as V_to_S (value to structure) in place of D_to_S (designator to structure), at least if either side is one of the three float types, seems reasonable and correct, albeit slight deoptimization -- in unsafe code dealing with floating point..should be rare.. >> >> >> - Jay >> >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: m3devel at elegosoft.com >>> Date: Mon, 5 Jul 2010 09:24:20 +0000 >>> Subject: [M3devel] loophole/copysign >>> >>> >>> Our codegen is remarkably low level. That is, lower level earlier than C. >>> >>> >>> gcc/m3cg -ftree-dump-all >>> >>> >>> As early as LongFloat.mc.003t.original, the first file dumped, we have: >>> >>> LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) >>> { >>> xreel M3_CtKayy__result; >>> xreel M3_CtKayy_res; >>> >>> xreel M3_CtKayy__result; >>> xreel M3_CtKayy_res; >>> M3_CtKayy_res = M3_CtKayy_x; >>> BIT_FIELD_REF = (word_8) ((int_64) >>> BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); >>> = M3_CtKayy_res; >>> return ; >>> } >>> >>> compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: >>> >>> copy_sign_f (from, to) >>> { >>> float res; >>> float D.1918; >>> D.1917; >>> struct float_t * from.1; >>> struct float_t * res.0; >>> >>> : >>> res = to_1; >>> res.0_4 = (struct float_t *) &res; >>> from.1_5 = (struct float_t *) &from; >>> D.1917_6 = from.1_5->sign; >>> res.0_4->sign = D.1917_6; >>> D.1918_7 = res; >>> return D.1918_7; >>> >>> } >>> >>> >>> See, you know, from gcc's point of view, we don't have any records/structs/unions. >>> Just integers and offsets from them mostly. >>> >>> >>> The right fix is to build up types. >>> That way also debugging with gdb will have a chance. >>> Perhaps not a small amount of work. But maybe not too bad. >>> >>> >>> For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. >>> At least if one type but not the other is floating point. >>> I don't know if that will work, but maybe. >>> >>> Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or >>> store volatile. >>> >>> - Jay >>> >> > From hosking at cs.purdue.edu Mon Jul 5 20:26:29 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 14:26:29 -0400 Subject: [M3devel] loophole/copysign In-Reply-To: References: , , , , Message-ID: We really don't want to do this. We need to figure out what needs to be generated as gcc trees. Perhaps an anonymous struct will suffice. On 5 Jul 2010, at 08:56, Jay K wrote: > > nope. > I know this is gross, but how about we addd CG.make_volatile that front end can call very sparingly, > that acts just like generating a call to setjmp or vfork -- in that it makes locals, parameters, temporaries > in current function as volatile? > > CastExpr.m3 would call it for D_to_S and FloatType[src] # FloatType[dest]. > > It would be available as a desparate measure if we find other problems. > To selectively inhibit optimization a function at a time. > Which, granted, is generally overkill. > > I'm trying this now.. > - Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Subject: RE: [M3devel] loophole/copysign >> Date: Mon, 5 Jul 2010 11:36:11 +0000 >> >> >> another idea: let's not use bitfield ref for float/double >> >> - Jay >> >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: m3devel at elegosoft.com >>> Date: Mon, 5 Jul 2010 11:25:19 +0000 >>> Subject: Re: [M3devel] loophole/copysign >>> >>> >>> Hm. it seems that it might be important to preserve the "designatorness", like in: >>> >>> libm3/...RandomReal.m3: >>> >>> VAR frac, exp: INTEGER; result: LONGREAL; >>> >>> (* Repack as LONGREAL: *) >>> WITH lr = LOOPHOLE (result, LongRealRep.T) DO >>> lr.sign := 0; >>> lr.exponent := exp; >>> lr.significand0 := Word.Shift (Word.And (frac, 16_7fffffff), >>> -(WordSize - 1 - FractionBits)); >>> lr.significand1 := r.integer (min := -16_7fffffff-1, max :=16_7fffffff); >>> END; >>> >>> >>> - Jay >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: m3devel at elegosoft.com >>>> Date: Mon, 5 Jul 2010 10:42:57 +0000 >>>> Subject: Re: [M3devel] loophole/copysign >>>> >>>> >>>> Tony, et. al.. in m3front/src/exprs/CastExpr.m3..what's the difference between a "designator" and a "value"? >>>> >>>> >>>> http://www-plan.cs.colorado.edu/diwan/modula3/designators.html >>>> >>>> An identifier is a writable designator >>>> if it is declared as a variable, >>>> is a VAR or VALUE parameter, >>>> is a local of a TYPECASE >>>> or TRY EXCEPT statement, >>>> or is a WITH local that is bound to a writable designator. >>>> An identifier is a readonly designator if it is >>>> a READONLY parameter, >>>> a local of a FOR statement, >>>> or a WITH local bound to a non-designator or >>>> readonly designator. >>>> >>>> >>>> >>>> I guess a designator is what I would think of a "variable" or "read only variable"? >>>> Something that either is "in memory" or can "reasonably" be put there? >>>> >>>> >>>> 1 + 2 is not a designator. >>>> >>>> >>>> Or, generally, a "variable", but that includes such similar things as parameters, "with variables", "for variables", "TYPECASE vairables", "TRY variables" >>>> >>>> >>>> Anything with a name??? (not functions/modules/generics -- "named data") >>>> >>>> >>>> Anyway, the next questions include: >>>> >>>> >>>> In CastExpr.m3 would it be terrible and/or wrong to treat "designators" the same as "values"? >>>> I realize, probably a deoptimization. >>>> I think this lets the backend work. >>>> >>>> >>>> And really, more to the point...shouldn't CastExpr.m3 use cg.loophole far more? >>>> I haven't had much luck with that. I always get the cg stack out of balance or with the wrong types, even though it seems like it should be easy. >>>> >>>> >>>> I have more testing to do, but classifying the loophole as V_to_S (value to structure) in place of D_to_S (designator to structure), at least if either side is one of the three float types, seems reasonable and correct, albeit slight deoptimization -- in unsafe code dealing with floating point..should be rare.. >>>> >>>> >>>> - Jay >>>> >>>> >>>> >>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: m3devel at elegosoft.com >>>>> Date: Mon, 5 Jul 2010 09:24:20 +0000 >>>>> Subject: [M3devel] loophole/copysign >>>>> >>>>> >>>>> Our codegen is remarkably low level. That is, lower level earlier than C. >>>>> >>>>> >>>>> gcc/m3cg -ftree-dump-all >>>>> >>>>> >>>>> As early as LongFloat.mc.003t.original, the first file dumped, we have: >>>>> >>>>> LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) >>>>> { >>>>> xreel M3_CtKayy__result; >>>>> xreel M3_CtKayy_res; >>>>> >>>>> xreel M3_CtKayy__result; >>>>> xreel M3_CtKayy_res; >>>>> M3_CtKayy_res = M3_CtKayy_x; >>>>> BIT_FIELD_REF = (word_8) ((int_64) >>>>> BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); >>>>> = M3_CtKayy_res; >>>>> return ; >>>>> } >>>>> >>>>> compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: >>>>> >>>>> copy_sign_f (from, to) >>>>> { >>>>> float res; >>>>> float D.1918; >>>>> D.1917; >>>>> struct float_t * from.1; >>>>> struct float_t * res.0; >>>>> >>>>> : >>>>> res = to_1; >>>>> res.0_4 = (struct float_t *) &res; >>>>> from.1_5 = (struct float_t *) &from; >>>>> D.1917_6 = from.1_5->sign; >>>>> res.0_4->sign = D.1917_6; >>>>> D.1918_7 = res; >>>>> return D.1918_7; >>>>> >>>>> } >>>>> >>>>> >>>>> See, you know, from gcc's point of view, we don't have any records/structs/unions. >>>>> Just integers and offsets from them mostly. >>>>> >>>>> >>>>> The right fix is to build up types. >>>>> That way also debugging with gdb will have a chance. >>>>> Perhaps not a small amount of work. But maybe not too bad. >>>>> >>>>> >>>>> For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. >>>>> At least if one type but not the other is floating point. >>>>> I don't know if that will work, but maybe. >>>>> >>>>> Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or >>>>> store volatile. >>>>> >>>>> - Jay >>>>> >>>> >>> >> > From jay.krell at cornell.edu Mon Jul 5 22:44:45 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 20:44:45 +0000 Subject: [M3devel] loophole/copysign In-Reply-To: <3267416E-1152-4A3D-A4C0-491F2C5FF74D@cs.purdue.edu> References: , <3267416E-1152-4A3D-A4C0-491F2C5FF74D@cs.purdue.edu> Message-ID: I don't think a barrier worked. The thing is, I don't think a change in parse.c alone can work. It isn't being given enough information. Or, well, it does have enough information, but, like, it is information it never uses. It has some type information. It would have to notice that the most recent store to a variable was of a different type than a load. ?- Jay ---------------------------------------- > Subject: Re: [M3devel] loophole/copysign > From: hosking at cs.purdue.edu > Date: Mon, 5 Jul 2010 14:24:01 -0400 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > We shouldn't need a barrier here. That is for memory operations, whereas these need not be. I would hate to make this change. Why can't we produce gcc trees that accomplish what we need? > > On 5 Jul 2010, at 05:24, Jay K wrote: > > > > > Our codegen is remarkably low level. That is, lower level earlier than C. > > > > > > gcc/m3cg -ftree-dump-all > > > > > > As early as LongFloat.mc.003t.original, the first file dumped, we have: > > > > LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) > > { > > xreel M3_CtKayy__result; > > xreel M3_CtKayy_res; > > > > xreel M3_CtKayy__result; > > xreel M3_CtKayy_res; > > M3_CtKayy_res = M3_CtKayy_x; > > BIT_FIELD_REF = (word_8) ((int_64) > > BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); > > = M3_CtKayy_res; > > return ; > > } > > > > compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: > > > > copy_sign_f (from, to) > > { > > float res; > > float D.1918; > > D.1917; > > struct float_t * from.1; > > struct float_t * res.0; > > > > : > > res = to_1; > > res.0_4 = (struct float_t *) &res; > > from.1_5 = (struct float_t *) &from; > > D.1917_6 = from.1_5->sign; > > res.0_4->sign = D.1917_6; > > D.1918_7 = res; > > return D.1918_7; > > > > } > > > > > > See, you know, from gcc's point of view, we don't have any records/structs/unions. > > Just integers and offsets from them mostly. > > > > > > The right fix is to build up types. > > That way also debugging with gdb will have a chance. > > Perhaps not a small amount of work. But maybe not too bad. > > > > > > For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. > > At least if one type but not the other is floating point. > > I don't know if that will work, but maybe. > > > > Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or > > store volatile. > > > > - Jay > > > From jay.krell at cornell.edu Mon Jul 5 22:49:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 20:49:14 +0000 Subject: [M3devel] loophole/copysign In-Reply-To: References: , , , , , , , , , Message-ID: The make_volatile idea seems to work. I agree it isn't great. I only inserted one call to it, for loophole + d_to_s + floattype src # dest. Let me know if attached is ok to commit. The front end all but needs to change here somehow, as the backend isn't being given much information -- no loophole call at all. Thanks, ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Mon, 5 Jul 2010 14:26:29 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] loophole/copysign > > We really don't want to do this. We need to figure out what needs to be generated as gcc trees. Perhaps an anonymous struct will suffice. > > > On 5 Jul 2010, at 08:56, Jay K wrote: > > > > > nope. > > I know this is gross, but how about we addd CG.make_volatile that front end can call very sparingly, > > that acts just like generating a call to setjmp or vfork -- in that it makes locals, parameters, temporaries > > in current function as volatile? > > > > CastExpr.m3 would call it for D_to_S and FloatType[src] # FloatType[dest]. > > > > It would be available as a desparate measure if we find other problems. > > To selectively inhibit optimization a function at a time. > > Which, granted, is generally overkill. > > > > I'm trying this now.. > > - Jay > > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: m3devel at elegosoft.com > >> Subject: RE: [M3devel] loophole/copysign > >> Date: Mon, 5 Jul 2010 11:36:11 +0000 > >> > >> > >> another idea: let's not use bitfield ref for float/double > >> > >> - Jay > >> > >> > >> > >> ---------------------------------------- > >>> From: jay.krell at cornell.edu > >>> To: m3devel at elegosoft.com > >>> Date: Mon, 5 Jul 2010 11:25:19 +0000 > >>> Subject: Re: [M3devel] loophole/copysign > >>> > >>> > >>> Hm. it seems that it might be important to preserve the "designatorness", like in: > >>> > >>> libm3/...RandomReal.m3: > >>> > >>> VAR frac, exp: INTEGER; result: LONGREAL; > >>> > >>> (* Repack as LONGREAL: *) > >>> WITH lr = LOOPHOLE (result, LongRealRep.T) DO > >>> lr.sign := 0; > >>> lr.exponent := exp; > >>> lr.significand0 := Word.Shift (Word.And (frac, 16_7fffffff), > >>> -(WordSize - 1 - FractionBits)); > >>> lr.significand1 := r.integer (min := -16_7fffffff-1, max :=16_7fffffff); > >>> END; > >>> > >>> > >>> - Jay > >>> > >>> ---------------------------------------- > >>>> From: jay.krell at cornell.edu > >>>> To: m3devel at elegosoft.com > >>>> Date: Mon, 5 Jul 2010 10:42:57 +0000 > >>>> Subject: Re: [M3devel] loophole/copysign > >>>> > >>>> > >>>> Tony, et. al.. in m3front/src/exprs/CastExpr.m3..what's the difference between a "designator" and a "value"? > >>>> > >>>> > >>>> http://www-plan.cs.colorado.edu/diwan/modula3/designators.html > >>>> > >>>> An identifier is a writable designator > >>>> if it is declared as a variable, > >>>> is a VAR or VALUE parameter, > >>>> is a local of a TYPECASE > >>>> or TRY EXCEPT statement, > >>>> or is a WITH local that is bound to a writable designator. > >>>> An identifier is a readonly designator if it is > >>>> a READONLY parameter, > >>>> a local of a FOR statement, > >>>> or a WITH local bound to a non-designator or > >>>> readonly designator. > >>>> > >>>> > >>>> > >>>> I guess a designator is what I would think of a "variable" or "read only variable"? > >>>> Something that either is "in memory" or can "reasonably" be put there? > >>>> > >>>> > >>>> 1 + 2 is not a designator. > >>>> > >>>> > >>>> Or, generally, a "variable", but that includes such similar things as parameters, "with variables", "for variables", "TYPECASE vairables", "TRY variables" > >>>> > >>>> > >>>> Anything with a name??? (not functions/modules/generics -- "named data") > >>>> > >>>> > >>>> Anyway, the next questions include: > >>>> > >>>> > >>>> In CastExpr.m3 would it be terrible and/or wrong to treat "designators" the same as "values"? > >>>> I realize, probably a deoptimization. > >>>> I think this lets the backend work. > >>>> > >>>> > >>>> And really, more to the point...shouldn't CastExpr.m3 use cg.loophole far more? > >>>> I haven't had much luck with that. I always get the cg stack out of balance or with the wrong types, even though it seems like it should be easy. > >>>> > >>>> > >>>> I have more testing to do, but classifying the loophole as V_to_S (value to structure) in place of D_to_S (designator to structure), at least if either side is one of the three float types, seems reasonable and correct, albeit slight deoptimization -- in unsafe code dealing with floating point..should be rare.. > >>>> > >>>> > >>>> - Jay > >>>> > >>>> > >>>> > >>>> ---------------------------------------- > >>>>> From: jay.krell at cornell.edu > >>>>> To: m3devel at elegosoft.com > >>>>> Date: Mon, 5 Jul 2010 09:24:20 +0000 > >>>>> Subject: [M3devel] loophole/copysign > >>>>> > >>>>> > >>>>> Our codegen is remarkably low level. That is, lower level earlier than C. > >>>>> > >>>>> > >>>>> gcc/m3cg -ftree-dump-all > >>>>> > >>>>> > >>>>> As early as LongFloat.mc.003t.original, the first file dumped, we have: > >>>>> > >>>>> LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) > >>>>> { > >>>>> xreel M3_CtKayy__result; > >>>>> xreel M3_CtKayy_res; > >>>>> > >>>>> xreel M3_CtKayy__result; > >>>>> xreel M3_CtKayy_res; > >>>>> M3_CtKayy_res = M3_CtKayy_x; > >>>>> BIT_FIELD_REF = (word_8) ((int_64) > >>>>> BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); > >>>>> = M3_CtKayy_res; > >>>>> return ; > >>>>> } > >>>>> > >>>>> compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: > >>>>> > >>>>> copy_sign_f (from, to) > >>>>> { > >>>>> float res; > >>>>> float D.1918; > >>>>> D.1917; > >>>>> struct float_t * from.1; > >>>>> struct float_t * res.0; > >>>>> > >>>>> : > >>>>> res = to_1; > >>>>> res.0_4 = (struct float_t *) &res; > >>>>> from.1_5 = (struct float_t *) &from; > >>>>> D.1917_6 = from.1_5->sign; > >>>>> res.0_4->sign = D.1917_6; > >>>>> D.1918_7 = res; > >>>>> return D.1918_7; > >>>>> > >>>>> } > >>>>> > >>>>> > >>>>> See, you know, from gcc's point of view, we don't have any records/structs/unions. > >>>>> Just integers and offsets from them mostly. > >>>>> > >>>>> > >>>>> The right fix is to build up types. > >>>>> That way also debugging with gdb will have a chance. > >>>>> Perhaps not a small amount of work. But maybe not too bad. > >>>>> > >>>>> > >>>>> For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. > >>>>> At least if one type but not the other is floating point. > >>>>> I don't know if that will work, but maybe. > >>>>> > >>>>> Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or > >>>>> store volatile. > >>>>> > >>>>> - Jay > >>>>> > >>>> > >>> > >> > > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: volatile.txt URL: From jay.krell at cornell.edu Mon Jul 5 22:51:25 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 20:51:25 +0000 Subject: [M3devel] loophole/copysign In-Reply-To: <01D93A8D-8D43-4D9A-A753-6B2D41C03F52@cs.purdue.edu> References: , , , , , , , <01D93A8D-8D43-4D9A-A753-6B2D41C03F52@cs.purdue.edu> Message-ID: I think this is still a good idea but I don't think relevant here. There's no offset or type mismatch to trigger that path, in this code, I'm pretty sure. I think a temporary would still work, in the "LV" D_to_S variant. But a temporary is wrong for the non-LV case, due the need to preserve writes to the original. But I didn't read through how the compiler choses LV or not-LV so not yet keen on making that sort of change. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Mon, 5 Jul 2010 14:25:17 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] loophole/copysign > > Yes, maybe that is the best way forward. > > On 5 Jul 2010, at 07:36, Jay K wrote: > > > > > another idea: let's not use bitfield ref for float/double > > > > - Jay > > > > > > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: m3devel at elegosoft.com > >> Date: Mon, 5 Jul 2010 11:25:19 +0000 > >> Subject: Re: [M3devel] loophole/copysign > >> > >> > >> Hm. it seems that it might be important to preserve the "designatorness", like in: > >> > >> libm3/...RandomReal.m3: > >> > >> VAR frac, exp: INTEGER; result: LONGREAL; > >> > >> (* Repack as LONGREAL: *) > >> WITH lr = LOOPHOLE (result, LongRealRep.T) DO > >> lr.sign := 0; > >> lr.exponent := exp; > >> lr.significand0 := Word.Shift (Word.And (frac, 16_7fffffff), > >> -(WordSize - 1 - FractionBits)); > >> lr.significand1 := r.integer (min := -16_7fffffff-1, max :=16_7fffffff); > >> END; > >> > >> > >> - Jay > >> > >> ---------------------------------------- > >>> From: jay.krell at cornell.edu > >>> To: m3devel at elegosoft.com > >>> Date: Mon, 5 Jul 2010 10:42:57 +0000 > >>> Subject: Re: [M3devel] loophole/copysign > >>> > >>> > >>> Tony, et. al.. in m3front/src/exprs/CastExpr.m3..what's the difference between a "designator" and a "value"? > >>> > >>> > >>> http://www-plan.cs.colorado.edu/diwan/modula3/designators.html > >>> > >>> An identifier is a writable designator > >>> if it is declared as a variable, > >>> is a VAR or VALUE parameter, > >>> is a local of a TYPECASE > >>> or TRY EXCEPT statement, > >>> or is a WITH local that is bound to a writable designator. > >>> An identifier is a readonly designator if it is > >>> a READONLY parameter, > >>> a local of a FOR statement, > >>> or a WITH local bound to a non-designator or > >>> readonly designator. > >>> > >>> > >>> > >>> I guess a designator is what I would think of a "variable" or "read only variable"? > >>> Something that either is "in memory" or can "reasonably" be put there? > >>> > >>> > >>> 1 + 2 is not a designator. > >>> > >>> > >>> Or, generally, a "variable", but that includes such similar things as parameters, "with variables", "for variables", "TYPECASE vairables", "TRY variables" > >>> > >>> > >>> Anything with a name??? (not functions/modules/generics -- "named data") > >>> > >>> > >>> Anyway, the next questions include: > >>> > >>> > >>> In CastExpr.m3 would it be terrible and/or wrong to treat "designators" the same as "values"? > >>> I realize, probably a deoptimization. > >>> I think this lets the backend work. > >>> > >>> > >>> And really, more to the point...shouldn't CastExpr.m3 use cg.loophole far more? > >>> I haven't had much luck with that. I always get the cg stack out of balance or with the wrong types, even though it seems like it should be easy. > >>> > >>> > >>> I have more testing to do, but classifying the loophole as V_to_S (value to structure) in place of D_to_S (designator to structure), at least if either side is one of the three float types, seems reasonable and correct, albeit slight deoptimization -- in unsafe code dealing with floating point..should be rare.. > >>> > >>> > >>> - Jay > >>> > >>> > >>> > >>> ---------------------------------------- > >>>> From: jay.krell at cornell.edu > >>>> To: m3devel at elegosoft.com > >>>> Date: Mon, 5 Jul 2010 09:24:20 +0000 > >>>> Subject: [M3devel] loophole/copysign > >>>> > >>>> > >>>> Our codegen is remarkably low level. That is, lower level earlier than C. > >>>> > >>>> > >>>> gcc/m3cg -ftree-dump-all > >>>> > >>>> > >>>> As early as LongFloat.mc.003t.original, the first file dumped, we have: > >>>> > >>>> LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) > >>>> { > >>>> xreel M3_CtKayy__result; > >>>> xreel M3_CtKayy_res; > >>>> > >>>> xreel M3_CtKayy__result; > >>>> xreel M3_CtKayy_res; > >>>> M3_CtKayy_res = M3_CtKayy_x; > >>>> BIT_FIELD_REF = (word_8) ((int_64) > >>>> BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); > >>>> = M3_CtKayy_res; > >>>> return ; > >>>> } > >>>> > >>>> compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: > >>>> > >>>> copy_sign_f (from, to) > >>>> { > >>>> float res; > >>>> float D.1918; > >>>> D.1917; > >>>> struct float_t * from.1; > >>>> struct float_t * res.0; > >>>> > >>>> : > >>>> res = to_1; > >>>> res.0_4 = (struct float_t *) &res; > >>>> from.1_5 = (struct float_t *) &from; > >>>> D.1917_6 = from.1_5->sign; > >>>> res.0_4->sign = D.1917_6; > >>>> D.1918_7 = res; > >>>> return D.1918_7; > >>>> > >>>> } > >>>> > >>>> > >>>> See, you know, from gcc's point of view, we don't have any records/structs/unions. > >>>> Just integers and offsets from them mostly. > >>>> > >>>> > >>>> The right fix is to build up types. > >>>> That way also debugging with gdb will have a chance. > >>>> Perhaps not a small amount of work. But maybe not too bad. > >>>> > >>>> > >>>> For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. > >>>> At least if one type but not the other is floating point. > >>>> I don't know if that will work, but maybe. > >>>> > >>>> Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or > >>>> store volatile. > >>>> > >>>> - Jay > >>>> > >>> > >> > > > From hosking at cs.purdue.edu Mon Jul 5 23:32:44 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 17:32:44 -0400 Subject: [M3devel] loophole/copysign In-Reply-To: References: , , , , , , , , , Message-ID: <19A59BEE-60F0-4A37-8FF8-69FBC74AB153@cs.purdue.edu> Are you saying that conversion of floats is not generating a loophole? The volatilise idea is overkill, and I don't want to see it contaminate the M3CG interfaces. Can you point me at the problematic code in CastExpr? On 5 Jul 2010, at 16:49, Jay K wrote: > > The make_volatile idea seems to work. I agree it isn't great. I only inserted one call to it, for loophole + d_to_s + floattype src # dest. > Let me know if attached is ok to commit. > The front end all but needs to change here somehow, as the backend isn't being given much information -- no loophole call at all. > > Thanks, > - Jay > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Mon, 5 Jul 2010 14:26:29 -0400 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] loophole/copysign >> >> We really don't want to do this. We need to figure out what needs to be generated as gcc trees. Perhaps an anonymous struct will suffice. >> >> >> On 5 Jul 2010, at 08:56, Jay K wrote: >> >>> >>> nope. >>> I know this is gross, but how about we addd CG.make_volatile that front end can call very sparingly, >>> that acts just like generating a call to setjmp or vfork -- in that it makes locals, parameters, temporaries >>> in current function as volatile? >>> >>> CastExpr.m3 would call it for D_to_S and FloatType[src] # FloatType[dest]. >>> >>> It would be available as a desparate measure if we find other problems. >>> To selectively inhibit optimization a function at a time. >>> Which, granted, is generally overkill. >>> >>> I'm trying this now.. >>> - Jay >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: m3devel at elegosoft.com >>>> Subject: RE: [M3devel] loophole/copysign >>>> Date: Mon, 5 Jul 2010 11:36:11 +0000 >>>> >>>> >>>> another idea: let's not use bitfield ref for float/double >>>> >>>> - Jay >>>> >>>> >>>> >>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: m3devel at elegosoft.com >>>>> Date: Mon, 5 Jul 2010 11:25:19 +0000 >>>>> Subject: Re: [M3devel] loophole/copysign >>>>> >>>>> >>>>> Hm. it seems that it might be important to preserve the "designatorness", like in: >>>>> >>>>> libm3/...RandomReal.m3: >>>>> >>>>> VAR frac, exp: INTEGER; result: LONGREAL; >>>>> >>>>> (* Repack as LONGREAL: *) >>>>> WITH lr = LOOPHOLE (result, LongRealRep.T) DO >>>>> lr.sign := 0; >>>>> lr.exponent := exp; >>>>> lr.significand0 := Word.Shift (Word.And (frac, 16_7fffffff), >>>>> -(WordSize - 1 - FractionBits)); >>>>> lr.significand1 := r.integer (min := -16_7fffffff-1, max :=16_7fffffff); >>>>> END; >>>>> >>>>> >>>>> - Jay >>>>> >>>>> ---------------------------------------- >>>>>> From: jay.krell at cornell.edu >>>>>> To: m3devel at elegosoft.com >>>>>> Date: Mon, 5 Jul 2010 10:42:57 +0000 >>>>>> Subject: Re: [M3devel] loophole/copysign >>>>>> >>>>>> >>>>>> Tony, et. al.. in m3front/src/exprs/CastExpr.m3..what's the difference between a "designator" and a "value"? >>>>>> >>>>>> >>>>>> http://www-plan.cs.colorado.edu/diwan/modula3/designators.html >>>>>> >>>>>> An identifier is a writable designator >>>>>> if it is declared as a variable, >>>>>> is a VAR or VALUE parameter, >>>>>> is a local of a TYPECASE >>>>>> or TRY EXCEPT statement, >>>>>> or is a WITH local that is bound to a writable designator. >>>>>> An identifier is a readonly designator if it is >>>>>> a READONLY parameter, >>>>>> a local of a FOR statement, >>>>>> or a WITH local bound to a non-designator or >>>>>> readonly designator. >>>>>> >>>>>> >>>>>> >>>>>> I guess a designator is what I would think of a "variable" or "read only variable"? >>>>>> Something that either is "in memory" or can "reasonably" be put there? >>>>>> >>>>>> >>>>>> 1 + 2 is not a designator. >>>>>> >>>>>> >>>>>> Or, generally, a "variable", but that includes such similar things as parameters, "with variables", "for variables", "TYPECASE vairables", "TRY variables" >>>>>> >>>>>> >>>>>> Anything with a name??? (not functions/modules/generics -- "named data") >>>>>> >>>>>> >>>>>> Anyway, the next questions include: >>>>>> >>>>>> >>>>>> In CastExpr.m3 would it be terrible and/or wrong to treat "designators" the same as "values"? >>>>>> I realize, probably a deoptimization. >>>>>> I think this lets the backend work. >>>>>> >>>>>> >>>>>> And really, more to the point...shouldn't CastExpr.m3 use cg.loophole far more? >>>>>> I haven't had much luck with that. I always get the cg stack out of balance or with the wrong types, even though it seems like it should be easy. >>>>>> >>>>>> >>>>>> I have more testing to do, but classifying the loophole as V_to_S (value to structure) in place of D_to_S (designator to structure), at least if either side is one of the three float types, seems reasonable and correct, albeit slight deoptimization -- in unsafe code dealing with floating point..should be rare.. >>>>>> >>>>>> >>>>>> - Jay >>>>>> >>>>>> >>>>>> >>>>>> ---------------------------------------- >>>>>>> From: jay.krell at cornell.edu >>>>>>> To: m3devel at elegosoft.com >>>>>>> Date: Mon, 5 Jul 2010 09:24:20 +0000 >>>>>>> Subject: [M3devel] loophole/copysign >>>>>>> >>>>>>> >>>>>>> Our codegen is remarkably low level. That is, lower level earlier than C. >>>>>>> >>>>>>> >>>>>>> gcc/m3cg -ftree-dump-all >>>>>>> >>>>>>> >>>>>>> As early as LongFloat.mc.003t.original, the first file dumped, we have: >>>>>>> >>>>>>> LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) >>>>>>> { >>>>>>> xreel M3_CtKayy__result; >>>>>>> xreel M3_CtKayy_res; >>>>>>> >>>>>>> xreel M3_CtKayy__result; >>>>>>> xreel M3_CtKayy_res; >>>>>>> M3_CtKayy_res = M3_CtKayy_x; >>>>>>> BIT_FIELD_REF = (word_8) ((int_64) >>>>>>> BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); >>>>>>> = M3_CtKayy_res; >>>>>>> return ; >>>>>>> } >>>>>>> >>>>>>> compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: >>>>>>> >>>>>>> copy_sign_f (from, to) >>>>>>> { >>>>>>> float res; >>>>>>> float D.1918; >>>>>>> D.1917; >>>>>>> struct float_t * from.1; >>>>>>> struct float_t * res.0; >>>>>>> >>>>>>> : >>>>>>> res = to_1; >>>>>>> res.0_4 = (struct float_t *) &res; >>>>>>> from.1_5 = (struct float_t *) &from; >>>>>>> D.1917_6 = from.1_5->sign; >>>>>>> res.0_4->sign = D.1917_6; >>>>>>> D.1918_7 = res; >>>>>>> return D.1918_7; >>>>>>> >>>>>>> } >>>>>>> >>>>>>> >>>>>>> See, you know, from gcc's point of view, we don't have any records/structs/unions. >>>>>>> Just integers and offsets from them mostly. >>>>>>> >>>>>>> >>>>>>> The right fix is to build up types. >>>>>>> That way also debugging with gdb will have a chance. >>>>>>> Perhaps not a small amount of work. But maybe not too bad. >>>>>>> >>>>>>> >>>>>>> For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. >>>>>>> At least if one type but not the other is floating point. >>>>>>> I don't know if that will work, but maybe. >>>>>>> >>>>>>> Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or >>>>>>> store volatile. >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>> >>>>> >>>> >>> >> > From hosking at cs.purdue.edu Mon Jul 5 23:34:20 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 17:34:20 -0400 Subject: [M3devel] loophole/copysign In-Reply-To: References: , , , , , , , <01D93A8D-8D43-4D9A-A753-6B2D41C03F52@cs.purdue.edu> Message-ID: None of this is making much sense to me... On 5 Jul 2010, at 16:51, Jay K wrote: > > I think this is still a good idea but I don't think relevant here. > There's no offset or type mismatch to trigger that path, in this code, I'm pretty sure. > > I think a temporary would still work, in the "LV" D_to_S variant. > But a temporary is wrong for the non-LV case, due the need to preserve writes to the original. > But I didn't read through how the compiler choses LV or not-LV so not yet keen on making that sort of change. > > - Jay > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Mon, 5 Jul 2010 14:25:17 -0400 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] loophole/copysign >> >> Yes, maybe that is the best way forward. >> >> On 5 Jul 2010, at 07:36, Jay K wrote: >> >>> >>> another idea: let's not use bitfield ref for float/double >>> >>> - Jay >>> >>> >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: m3devel at elegosoft.com >>>> Date: Mon, 5 Jul 2010 11:25:19 +0000 >>>> Subject: Re: [M3devel] loophole/copysign >>>> >>>> >>>> Hm. it seems that it might be important to preserve the "designatorness", like in: >>>> >>>> libm3/...RandomReal.m3: >>>> >>>> VAR frac, exp: INTEGER; result: LONGREAL; >>>> >>>> (* Repack as LONGREAL: *) >>>> WITH lr = LOOPHOLE (result, LongRealRep.T) DO >>>> lr.sign := 0; >>>> lr.exponent := exp; >>>> lr.significand0 := Word.Shift (Word.And (frac, 16_7fffffff), >>>> -(WordSize - 1 - FractionBits)); >>>> lr.significand1 := r.integer (min := -16_7fffffff-1, max :=16_7fffffff); >>>> END; >>>> >>>> >>>> - Jay >>>> >>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: m3devel at elegosoft.com >>>>> Date: Mon, 5 Jul 2010 10:42:57 +0000 >>>>> Subject: Re: [M3devel] loophole/copysign >>>>> >>>>> >>>>> Tony, et. al.. in m3front/src/exprs/CastExpr.m3..what's the difference between a "designator" and a "value"? >>>>> >>>>> >>>>> http://www-plan.cs.colorado.edu/diwan/modula3/designators.html >>>>> >>>>> An identifier is a writable designator >>>>> if it is declared as a variable, >>>>> is a VAR or VALUE parameter, >>>>> is a local of a TYPECASE >>>>> or TRY EXCEPT statement, >>>>> or is a WITH local that is bound to a writable designator. >>>>> An identifier is a readonly designator if it is >>>>> a READONLY parameter, >>>>> a local of a FOR statement, >>>>> or a WITH local bound to a non-designator or >>>>> readonly designator. >>>>> >>>>> >>>>> >>>>> I guess a designator is what I would think of a "variable" or "read only variable"? >>>>> Something that either is "in memory" or can "reasonably" be put there? >>>>> >>>>> >>>>> 1 + 2 is not a designator. >>>>> >>>>> >>>>> Or, generally, a "variable", but that includes such similar things as parameters, "with variables", "for variables", "TYPECASE vairables", "TRY variables" >>>>> >>>>> >>>>> Anything with a name??? (not functions/modules/generics -- "named data") >>>>> >>>>> >>>>> Anyway, the next questions include: >>>>> >>>>> >>>>> In CastExpr.m3 would it be terrible and/or wrong to treat "designators" the same as "values"? >>>>> I realize, probably a deoptimization. >>>>> I think this lets the backend work. >>>>> >>>>> >>>>> And really, more to the point...shouldn't CastExpr.m3 use cg.loophole far more? >>>>> I haven't had much luck with that. I always get the cg stack out of balance or with the wrong types, even though it seems like it should be easy. >>>>> >>>>> >>>>> I have more testing to do, but classifying the loophole as V_to_S (value to structure) in place of D_to_S (designator to structure), at least if either side is one of the three float types, seems reasonable and correct, albeit slight deoptimization -- in unsafe code dealing with floating point..should be rare.. >>>>> >>>>> >>>>> - Jay >>>>> >>>>> >>>>> >>>>> ---------------------------------------- >>>>>> From: jay.krell at cornell.edu >>>>>> To: m3devel at elegosoft.com >>>>>> Date: Mon, 5 Jul 2010 09:24:20 +0000 >>>>>> Subject: [M3devel] loophole/copysign >>>>>> >>>>>> >>>>>> Our codegen is remarkably low level. That is, lower level earlier than C. >>>>>> >>>>>> >>>>>> gcc/m3cg -ftree-dump-all >>>>>> >>>>>> >>>>>> As early as LongFloat.mc.003t.original, the first file dumped, we have: >>>>>> >>>>>> LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) >>>>>> { >>>>>> xreel M3_CtKayy__result; >>>>>> xreel M3_CtKayy_res; >>>>>> >>>>>> xreel M3_CtKayy__result; >>>>>> xreel M3_CtKayy_res; >>>>>> M3_CtKayy_res = M3_CtKayy_x; >>>>>> BIT_FIELD_REF = (word_8) ((int_64) >>>>>> BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); >>>>>> = M3_CtKayy_res; >>>>>> return ; >>>>>> } >>>>>> >>>>>> compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: >>>>>> >>>>>> copy_sign_f (from, to) >>>>>> { >>>>>> float res; >>>>>> float D.1918; >>>>>> D.1917; >>>>>> struct float_t * from.1; >>>>>> struct float_t * res.0; >>>>>> >>>>>> : >>>>>> res = to_1; >>>>>> res.0_4 = (struct float_t *) &res; >>>>>> from.1_5 = (struct float_t *) &from; >>>>>> D.1917_6 = from.1_5->sign; >>>>>> res.0_4->sign = D.1917_6; >>>>>> D.1918_7 = res; >>>>>> return D.1918_7; >>>>>> >>>>>> } >>>>>> >>>>>> >>>>>> See, you know, from gcc's point of view, we don't have any records/structs/unions. >>>>>> Just integers and offsets from them mostly. >>>>>> >>>>>> >>>>>> The right fix is to build up types. >>>>>> That way also debugging with gdb will have a chance. >>>>>> Perhaps not a small amount of work. But maybe not too bad. >>>>>> >>>>>> >>>>>> For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. >>>>>> At least if one type but not the other is floating point. >>>>>> I don't know if that will work, but maybe. >>>>>> >>>>>> Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or >>>>>> store volatile. >>>>>> >>>>>> - Jay >>>>>> >>>>> >>>> >>> >> > From hosking at cs.purdue.edu Mon Jul 5 23:33:43 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 17:33:43 -0400 Subject: [M3devel] loophole/copysign In-Reply-To: References: , <3267416E-1152-4A3D-A4C0-491F2C5FF74D@cs.purdue.edu> Message-ID: <6BF4E7E7-1068-4623-AE86-6687E2B7B385@cs.purdue.edu> Surely we should instead give it the type conversion from what was stored to what is loaded. Can you point me at the problem code in CastExpr? On 5 Jul 2010, at 16:44, Jay K wrote: > > I don't think a barrier worked. > The thing is, I don't think a change in parse.c alone can work. It isn't being given enough information. > Or, well, it does have enough information, but, like, it is information it never uses. > It has some type information. It would have to notice that the most recent store to a variable was > of a different type than a load. > > - Jay > > > > ---------------------------------------- >> Subject: Re: [M3devel] loophole/copysign >> From: hosking at cs.purdue.edu >> Date: Mon, 5 Jul 2010 14:24:01 -0400 >> CC: m3devel at elegosoft.com >> To: jay.krell at cornell.edu >> >> We shouldn't need a barrier here. That is for memory operations, whereas these need not be. I would hate to make this change. Why can't we produce gcc trees that accomplish what we need? >> >> On 5 Jul 2010, at 05:24, Jay K wrote: >> >>> >>> Our codegen is remarkably low level. That is, lower level earlier than C. >>> >>> >>> gcc/m3cg -ftree-dump-all >>> >>> >>> As early as LongFloat.mc.003t.original, the first file dumped, we have: >>> >>> LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) >>> { >>> xreel M3_CtKayy__result; >>> xreel M3_CtKayy_res; >>> >>> xreel M3_CtKayy__result; >>> xreel M3_CtKayy_res; >>> M3_CtKayy_res = M3_CtKayy_x; >>> BIT_FIELD_REF = (word_8) ((int_64) >>> BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); >>> = M3_CtKayy_res; >>> return ; >>> } >>> >>> compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: >>> >>> copy_sign_f (from, to) >>> { >>> float res; >>> float D.1918; >>> D.1917; >>> struct float_t * from.1; >>> struct float_t * res.0; >>> >>> : >>> res = to_1; >>> res.0_4 = (struct float_t *) &res; >>> from.1_5 = (struct float_t *) &from; >>> D.1917_6 = from.1_5->sign; >>> res.0_4->sign = D.1917_6; >>> D.1918_7 = res; >>> return D.1918_7; >>> >>> } >>> >>> >>> See, you know, from gcc's point of view, we don't have any records/structs/unions. >>> Just integers and offsets from them mostly. >>> >>> >>> The right fix is to build up types. >>> That way also debugging with gdb will have a chance. >>> Perhaps not a small amount of work. But maybe not too bad. >>> >>> >>> For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. >>> At least if one type but not the other is floating point. >>> I don't know if that will work, but maybe. >>> >>> Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or >>> store volatile. >>> >>> - Jay >>> >> > From jay.krell at cornell.edu Mon Jul 5 23:42:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 21:42:43 +0000 Subject: [M3devel] loophole/copysign In-Reply-To: <6BF4E7E7-1068-4623-AE86-6687E2B7B385@cs.purdue.edu> References: , , <3267416E-1152-4A3D-A4C0-491F2C5FF74D@cs.purdue.edu>, , <6BF4E7E7-1068-4623-AE86-6687E2B7B385@cs.purdue.edu> Message-ID: CastExpr.m3 has precious few calls to CG.Loophole, including none for this case. cm3cg -y output for m3core/LongReal.mc CopySign has no calls to loophole. We store into a local as one type and read it back as another type. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Mon, 5 Jul 2010 17:33:43 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] loophole/copysign > > Surely we should instead give it the type conversion from what was stored to what is loaded. Can you point me at the problem code in CastExpr? > > On 5 Jul 2010, at 16:44, Jay K wrote: > > > > > I don't think a barrier worked. > > The thing is, I don't think a change in parse.c alone can work. It isn't being given enough information. > > Or, well, it does have enough information, but, like, it is information it never uses. > > It has some type information. It would have to notice that the most recent store to a variable was > > of a different type than a load. > > > > - Jay > > > > > > > > ---------------------------------------- > >> Subject: Re: [M3devel] loophole/copysign > >> From: hosking at cs.purdue.edu > >> Date: Mon, 5 Jul 2010 14:24:01 -0400 > >> CC: m3devel at elegosoft.com > >> To: jay.krell at cornell.edu > >> > >> We shouldn't need a barrier here. That is for memory operations, whereas these need not be. I would hate to make this change. Why can't we produce gcc trees that accomplish what we need? > >> > >> On 5 Jul 2010, at 05:24, Jay K wrote: > >> > >>> > >>> Our codegen is remarkably low level. That is, lower level earlier than C. > >>> > >>> > >>> gcc/m3cg -ftree-dump-all > >>> > >>> > >>> As early as LongFloat.mc.003t.original, the first file dumped, we have: > >>> > >>> LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) > >>> { > >>> xreel M3_CtKayy__result; > >>> xreel M3_CtKayy_res; > >>> > >>> xreel M3_CtKayy__result; > >>> xreel M3_CtKayy_res; > >>> M3_CtKayy_res = M3_CtKayy_x; > >>> BIT_FIELD_REF = (word_8) ((int_64) > >>> BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); > >>> = M3_CtKayy_res; > >>> return ; > >>> } > >>> > >>> compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: > >>> > >>> copy_sign_f (from, to) > >>> { > >>> float res; > >>> float D.1918; > >>> D.1917; > >>> struct float_t * from.1; > >>> struct float_t * res.0; > >>> > >>> : > >>> res = to_1; > >>> res.0_4 = (struct float_t *) &res; > >>> from.1_5 = (struct float_t *) &from; > >>> D.1917_6 = from.1_5->sign; > >>> res.0_4->sign = D.1917_6; > >>> D.1918_7 = res; > >>> return D.1918_7; > >>> > >>> } > >>> > >>> > >>> See, you know, from gcc's point of view, we don't have any records/structs/unions. > >>> Just integers and offsets from them mostly. > >>> > >>> > >>> The right fix is to build up types. > >>> That way also debugging with gdb will have a chance. > >>> Perhaps not a small amount of work. But maybe not too bad. > >>> > >>> > >>> For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. > >>> At least if one type but not the other is floating point. > >>> I don't know if that will work, but maybe. > >>> > >>> Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or > >>> store volatile. > >>> > >>> - Jay > >>> > >> > > > From jay.krell at cornell.edu Tue Jul 6 00:20:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 22:20:20 +0000 Subject: [M3devel] loophole/copysign In-Reply-To: References: , , <3267416E-1152-4A3D-A4C0-491F2C5FF74D@cs.purdue.edu>, , <6BF4E7E7-1068-4623-AE86-6687E2B7B385@cs.purdue.edu>, Message-ID: Specifically it goes down the "D_to_S" and "LV" paths (PrepLV, CompileLV, and not Prep and Compile, no temporary, no loophole) ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] loophole/copysign > Date: Mon, 5 Jul 2010 21:42:43 +0000 > > > CastExpr.m3 has precious few calls to CG.Loophole, including none for this case. > cm3cg -y output for m3core/LongReal.mc CopySign has no calls to loophole. > We store into a local as one type and read it back as another type. > > - Jay > > ---------------------------------------- > > From: hosking at cs.purdue.edu > > Date: Mon, 5 Jul 2010 17:33:43 -0400 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] loophole/copysign > > > > Surely we should instead give it the type conversion from what was stored to what is loaded. Can you point me at the problem code in CastExpr? > > > > On 5 Jul 2010, at 16:44, Jay K wrote: > > > > > > > > I don't think a barrier worked. > > > The thing is, I don't think a change in parse.c alone can work. It isn't being given enough information. > > > Or, well, it does have enough information, but, like, it is information it never uses. > > > It has some type information. It would have to notice that the most recent store to a variable was > > > of a different type than a load. > > > > > > - Jay > > > > > > > > > > > > ---------------------------------------- > > >> Subject: Re: [M3devel] loophole/copysign > > >> From: hosking at cs.purdue.edu > > >> Date: Mon, 5 Jul 2010 14:24:01 -0400 > > >> CC: m3devel at elegosoft.com > > >> To: jay.krell at cornell.edu > > >> > > >> We shouldn't need a barrier here. That is for memory operations, whereas these need not be. I would hate to make this change. Why can't we produce gcc trees that accomplish what we need? > > >> > > >> On 5 Jul 2010, at 05:24, Jay K wrote: > > >> > > >>> > > >>> Our codegen is remarkably low level. That is, lower level earlier than C. > > >>> > > >>> > > >>> gcc/m3cg -ftree-dump-all > > >>> > > >>> > > >>> As early as LongFloat.mc.003t.original, the first file dumped, we have: > > >>> > > >>> LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) > > >>> { > > >>> xreel M3_CtKayy__result; > > >>> xreel M3_CtKayy_res; > > >>> > > >>> xreel M3_CtKayy__result; > > >>> xreel M3_CtKayy_res; > > >>> M3_CtKayy_res = M3_CtKayy_x; > > >>> BIT_FIELD_REF = (word_8) ((int_64) > > >>> BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); > > >>> = M3_CtKayy_res; > > >>> return ; > > >>> } > > >>> > > >>> compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: > > >>> > > >>> copy_sign_f (from, to) > > >>> { > > >>> float res; > > >>> float D.1918; > > >>> D.1917; > > >>> struct float_t * from.1; > > >>> struct float_t * res.0; > > >>> > > >>> : > > >>> res = to_1; > > >>> res.0_4 = (struct float_t *) &res; > > >>> from.1_5 = (struct float_t *) &from; > > >>> D.1917_6 = from.1_5->sign; > > >>> res.0_4->sign = D.1917_6; > > >>> D.1918_7 = res; > > >>> return D.1918_7; > > >>> > > >>> } > > >>> > > >>> > > >>> See, you know, from gcc's point of view, we don't have any records/structs/unions. > > >>> Just integers and offsets from them mostly. > > >>> > > >>> > > >>> The right fix is to build up types. > > >>> That way also debugging with gdb will have a chance. > > >>> Perhaps not a small amount of work. But maybe not too bad. > > >>> > > >>> > > >>> For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. > > >>> At least if one type but not the other is floating point. > > >>> I don't know if that will work, but maybe. > > >>> > > >>> Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or > > >>> store volatile. > > >>> > > >>> - Jay > > >>> > > >> > > > > > > From hosking at cs.purdue.edu Tue Jul 6 00:27:10 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 18:27:10 -0400 Subject: [M3devel] loophole/copysign In-Reply-To: References: , , <3267416E-1152-4A3D-A4C0-491F2C5FF74D@cs.purdue.edu>, , <6BF4E7E7-1068-4623-AE86-6687E2B7B385@cs.purdue.edu> Message-ID: OK, so now I begin to understand. What you are saying is that gcc needs to have a union type capturing the fact that the variable is accessed using 2 different types. What happens in C code where you cast a memory location from one type to another? How does gcc cope with that? Presumably it gets some sort of type aliasing information? On 5 Jul 2010, at 17:42, Jay K wrote: > > CastExpr.m3 has precious few calls to CG.Loophole, including none for this case. > cm3cg -y output for m3core/LongReal.mc CopySign has no calls to loophole. > We store into a local as one type and read it back as another type. > > - Jay > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Mon, 5 Jul 2010 17:33:43 -0400 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] loophole/copysign >> >> Surely we should instead give it the type conversion from what was stored to what is loaded. Can you point me at the problem code in CastExpr? >> >> On 5 Jul 2010, at 16:44, Jay K wrote: >> >>> >>> I don't think a barrier worked. >>> The thing is, I don't think a change in parse.c alone can work. It isn't being given enough information. >>> Or, well, it does have enough information, but, like, it is information it never uses. >>> It has some type information. It would have to notice that the most recent store to a variable was >>> of a different type than a load. >>> >>> - Jay >>> >>> >>> >>> ---------------------------------------- >>>> Subject: Re: [M3devel] loophole/copysign >>>> From: hosking at cs.purdue.edu >>>> Date: Mon, 5 Jul 2010 14:24:01 -0400 >>>> CC: m3devel at elegosoft.com >>>> To: jay.krell at cornell.edu >>>> >>>> We shouldn't need a barrier here. That is for memory operations, whereas these need not be. I would hate to make this change. Why can't we produce gcc trees that accomplish what we need? >>>> >>>> On 5 Jul 2010, at 05:24, Jay K wrote: >>>> >>>>> >>>>> Our codegen is remarkably low level. That is, lower level earlier than C. >>>>> >>>>> >>>>> gcc/m3cg -ftree-dump-all >>>>> >>>>> >>>>> As early as LongFloat.mc.003t.original, the first file dumped, we have: >>>>> >>>>> LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) >>>>> { >>>>> xreel M3_CtKayy__result; >>>>> xreel M3_CtKayy_res; >>>>> >>>>> xreel M3_CtKayy__result; >>>>> xreel M3_CtKayy_res; >>>>> M3_CtKayy_res = M3_CtKayy_x; >>>>> BIT_FIELD_REF = (word_8) ((int_64) >>>>> BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); >>>>> = M3_CtKayy_res; >>>>> return ; >>>>> } >>>>> >>>>> compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: >>>>> >>>>> copy_sign_f (from, to) >>>>> { >>>>> float res; >>>>> float D.1918; >>>>> D.1917; >>>>> struct float_t * from.1; >>>>> struct float_t * res.0; >>>>> >>>>> : >>>>> res = to_1; >>>>> res.0_4 = (struct float_t *) &res; >>>>> from.1_5 = (struct float_t *) &from; >>>>> D.1917_6 = from.1_5->sign; >>>>> res.0_4->sign = D.1917_6; >>>>> D.1918_7 = res; >>>>> return D.1918_7; >>>>> >>>>> } >>>>> >>>>> >>>>> See, you know, from gcc's point of view, we don't have any records/structs/unions. >>>>> Just integers and offsets from them mostly. >>>>> >>>>> >>>>> The right fix is to build up types. >>>>> That way also debugging with gdb will have a chance. >>>>> Perhaps not a small amount of work. But maybe not too bad. >>>>> >>>>> >>>>> For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. >>>>> At least if one type but not the other is floating point. >>>>> I don't know if that will work, but maybe. >>>>> >>>>> Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or >>>>> store volatile. >>>>> >>>>> - Jay >>>>> >>>> >>> >> > From jay.krell at cornell.edu Tue Jul 6 00:50:38 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 22:50:38 +0000 Subject: [M3devel] loophole/copysign In-Reply-To: References: , , <3267416E-1152-4A3D-A4C0-491F2C5FF74D@cs.purdue.edu>, , <6BF4E7E7-1068-4623-AE86-6687E2B7B385@cs.purdue.edu> , Message-ID: The C trees are much higher level. First, cm3/m3-libs/m3core/src/float/test_copysign.c which is analogous to CopySign, the C code: typedef struct { ??????? unsigned rest : 31; ??????? unsigned sign : 1; } float_t; float copy_sign_f(float from, float to) { ??????? float res = to; ??????? ((float_t*)&res)->sign = ((float_t*)&from)->sign; ??????? return res; } is what we should somehow strive for. It yields a tree with almost everything preserved (typedefs fall out). gcc-4.2 -fdump-tree-all -c test_copysign.c test_copysign.c.003t.original: ;; Function copy_sign_f (copy_sign_f) ;; enabled by -tree-original { ? float res = to; ??? float res = to; ? ((struct float_t *) &res)->sign = ((struct float_t *) &from)->sign; ? return res; } which is nothing like what we produce. We don't have structs/member_refs ever, I believe. To maybe answer your question..well..: int reinterpret(float f) { ? return *(int*)&f; } gcc-4.2 -ftree-dump-all -c 5.c well, the tree is high super high fidelity, nearly indistinguishable from the input C: ;; Function reinterpret (reinterpret) ;; enabled by -tree-original { ? return *(int *) &f; } I think we would produce about the same thing if we went down the non-bitfield path in load or store. You know ... we don't even need to do loophole, but we need to do just one load or one store, with a conversion, instead of storing one way and loading the other. You could imagine parse.c might buffer up one load or store and then if the next instruction is not store or load, just flush it, but if it is store or load, merge them. Well, it depends on what load or store is to of course. ?- Jay ---------------------------------------- > Subject: Re: [M3devel] loophole/copysign > From: hosking at cs.purdue.edu > Date: Mon, 5 Jul 2010 18:27:10 -0400 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > OK, so now I begin to understand. What you are saying is that gcc needs to have a union type capturing the fact that the variable is accessed using 2 different types. What happens in C code where you cast a memory location from one type to another? How does gcc cope with that? Presumably it gets some sort of type aliasing information? > > On 5 Jul 2010, at 17:42, Jay K wrote: > > > > > CastExpr.m3 has precious few calls to CG.Loophole, including none for this case. > > cm3cg -y output for m3core/LongReal.mc CopySign has no calls to loophole. > > We store into a local as one type and read it back as another type. > > > > - Jay > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Mon, 5 Jul 2010 17:33:43 -0400 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] loophole/copysign > >> > >> Surely we should instead give it the type conversion from what was stored to what is loaded. Can you point me at the problem code in CastExpr? > >> > >> On 5 Jul 2010, at 16:44, Jay K wrote: > >> > >>> > >>> I don't think a barrier worked. > >>> The thing is, I don't think a change in parse.c alone can work. It isn't being given enough information. > >>> Or, well, it does have enough information, but, like, it is information it never uses. > >>> It has some type information. It would have to notice that the most recent store to a variable was > >>> of a different type than a load. > >>> > >>> - Jay > >>> > >>> > >>> > >>> ---------------------------------------- > >>>> Subject: Re: [M3devel] loophole/copysign > >>>> From: hosking at cs.purdue.edu > >>>> Date: Mon, 5 Jul 2010 14:24:01 -0400 > >>>> CC: m3devel at elegosoft.com > >>>> To: jay.krell at cornell.edu > >>>> > >>>> We shouldn't need a barrier here. That is for memory operations, whereas these need not be. I would hate to make this change. Why can't we produce gcc trees that accomplish what we need? > >>>> > >>>> On 5 Jul 2010, at 05:24, Jay K wrote: > >>>> > >>>>> > >>>>> Our codegen is remarkably low level. That is, lower level earlier than C. > >>>>> > >>>>> > >>>>> gcc/m3cg -ftree-dump-all > >>>>> > >>>>> > >>>>> As early as LongFloat.mc.003t.original, the first file dumped, we have: > >>>>> > >>>>> LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) > >>>>> { > >>>>> xreel M3_CtKayy__result; > >>>>> xreel M3_CtKayy_res; > >>>>> > >>>>> xreel M3_CtKayy__result; > >>>>> xreel M3_CtKayy_res; > >>>>> M3_CtKayy_res = M3_CtKayy_x; > >>>>> BIT_FIELD_REF = (word_8) ((int_64) > >>>>> BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); > >>>>> = M3_CtKayy_res; > >>>>> return ; > >>>>> } > >>>>> > >>>>> compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: > >>>>> > >>>>> copy_sign_f (from, to) > >>>>> { > >>>>> float res; > >>>>> float D.1918; > >>>>> D.1917; > >>>>> struct float_t * from.1; > >>>>> struct float_t * res.0; > >>>>> > >>>>> : > >>>>> res = to_1; > >>>>> res.0_4 = (struct float_t *) &res; > >>>>> from.1_5 = (struct float_t *) &from; > >>>>> D.1917_6 = from.1_5->sign; > >>>>> res.0_4->sign = D.1917_6; > >>>>> D.1918_7 = res; > >>>>> return D.1918_7; > >>>>> > >>>>> } > >>>>> > >>>>> > >>>>> See, you know, from gcc's point of view, we don't have any records/structs/unions. > >>>>> Just integers and offsets from them mostly. > >>>>> > >>>>> > >>>>> The right fix is to build up types. > >>>>> That way also debugging with gdb will have a chance. > >>>>> Perhaps not a small amount of work. But maybe not too bad. > >>>>> > >>>>> > >>>>> For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. > >>>>> At least if one type but not the other is floating point. > >>>>> I don't know if that will work, but maybe. > >>>>> > >>>>> Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or > >>>>> store volatile. > >>>>> > >>>>> - Jay > >>>>> > >>>> > >>> > >> > > > From jay.krell at cornell.edu Tue Jul 6 01:06:29 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 23:06:29 +0000 Subject: [M3devel] loophole/copysign In-Reply-To: References: , , <3267416E-1152-4A3D-A4C0-491F2C5FF74D@cs.purdue.edu>, , <6BF4E7E7-1068-4623-AE86-6687E2B7B385@cs.purdue.edu>, , , Message-ID: I'm not sure we need to be too fancy: not sure we need a union. I think merely taking the address and casting and derefing it might suffice. For aliasing we just always return 0, so presumably..any pointers are pessimistic. The alias information seems to be that any "decl" could be a variable, or a type..is in a "set". Sets are integer indices into an array of sets. Same integer => same set. But I think that we just return 0 all the time makes these easy and adequate. Could be better. But probably ok. Perhaps the better way would be: ? if file uses loophole anywhere, same as today ?? loophole in the front end or backend ?if file doesn't use loophole, we can probably at least put every? type in its own set? ? Er, not exactly: not subranges enums integers. ? But still probably some easy stuff? ?Anyway, just having everything in the same alias set should be ok for now. ?We're still digging out of a big hole: volatile everywhere.. no unit at a time.. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] loophole/copysign > Date: Mon, 5 Jul 2010 22:50:38 +0000 > > > The C trees are much higher level. > > First, cm3/m3-libs/m3core/src/float/test_copysign.c which is analogous to CopySign, the C code: > > typedef struct { > unsigned rest : 31; > unsigned sign : 1; > } float_t; > > float copy_sign_f(float from, float to) > { > float res = to; > ((float_t*)&res)->sign = ((float_t*)&from)->sign; > return res; > } > > is what we should somehow strive for. > > It yields a tree with almost everything preserved (typedefs fall out). > gcc-4.2 -fdump-tree-all -c test_copysign.c > > test_copysign.c.003t.original: > > ;; Function copy_sign_f (copy_sign_f) > ;; enabled by -tree-original > > { > float res = to; > > float res = to; > ((struct float_t *) &res)->sign = ((struct float_t *) &from)->sign; > return res; > } > > which is nothing like what we produce. > We don't have structs/member_refs ever, I believe. > > > To maybe answer your question..well..: > > int reinterpret(float f) > { > return *(int*)&f; > } > > gcc-4.2 -ftree-dump-all -c 5.c well, the tree is high super high fidelity, nearly > indistinguishable from the input C: > > > ;; Function reinterpret (reinterpret) > ;; enabled by -tree-original > { > return *(int *) &f; > } > > > I think we would produce about the same thing if we went down the non-bitfield path in load or store. > You know ... we don't even need to do loophole, but we need to do just one load or one store, with a conversion, > instead of storing one way and loading the other. > > > You could imagine parse.c might buffer up one load or store and then if the next instruction is not store or load, just flush it, > but if it is store or load, merge them. Well, it depends on what load or store is to of course. > > > - Jay > > ---------------------------------------- > > Subject: Re: [M3devel] loophole/copysign > > From: hosking at cs.purdue.edu > > Date: Mon, 5 Jul 2010 18:27:10 -0400 > > CC: m3devel at elegosoft.com > > To: jay.krell at cornell.edu > > > > OK, so now I begin to understand. What you are saying is that gcc needs to have a union type capturing the fact that the variable is accessed using 2 different types. What happens in C code where you cast a memory location from one type to another? How does gcc cope with that? Presumably it gets some sort of type aliasing information? > > > > On 5 Jul 2010, at 17:42, Jay K wrote: > > > > > > > > CastExpr.m3 has precious few calls to CG.Loophole, including none for this case. > > > cm3cg -y output for m3core/LongReal.mc CopySign has no calls to loophole. > > > We store into a local as one type and read it back as another type. > > > > > > - Jay > > > > > > ---------------------------------------- > > >> From: hosking at cs.purdue.edu > > >> Date: Mon, 5 Jul 2010 17:33:43 -0400 > > >> To: jay.krell at cornell.edu > > >> CC: m3devel at elegosoft.com > > >> Subject: Re: [M3devel] loophole/copysign > > >> > > >> Surely we should instead give it the type conversion from what was stored to what is loaded. Can you point me at the problem code in CastExpr? > > >> > > >> On 5 Jul 2010, at 16:44, Jay K wrote: > > >> > > >>> > > >>> I don't think a barrier worked. > > >>> The thing is, I don't think a change in parse.c alone can work. It isn't being given enough information. > > >>> Or, well, it does have enough information, but, like, it is information it never uses. > > >>> It has some type information. It would have to notice that the most recent store to a variable was > > >>> of a different type than a load. > > >>> > > >>> - Jay > > >>> > > >>> > > >>> > > >>> ---------------------------------------- > > >>>> Subject: Re: [M3devel] loophole/copysign > > >>>> From: hosking at cs.purdue.edu > > >>>> Date: Mon, 5 Jul 2010 14:24:01 -0400 > > >>>> CC: m3devel at elegosoft.com > > >>>> To: jay.krell at cornell.edu > > >>>> > > >>>> We shouldn't need a barrier here. That is for memory operations, whereas these need not be. I would hate to make this change. Why can't we produce gcc trees that accomplish what we need? > > >>>> > > >>>> On 5 Jul 2010, at 05:24, Jay K wrote: > > >>>> > > >>>>> > > >>>>> Our codegen is remarkably low level. That is, lower level earlier than C. > > >>>>> > > >>>>> > > >>>>> gcc/m3cg -ftree-dump-all > > >>>>> > > >>>>> > > >>>>> As early as LongFloat.mc.003t.original, the first file dumped, we have: > > >>>>> > > >>>>> LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) > > >>>>> { > > >>>>> xreel M3_CtKayy__result; > > >>>>> xreel M3_CtKayy_res; > > >>>>> > > >>>>> xreel M3_CtKayy__result; > > >>>>> xreel M3_CtKayy_res; > > >>>>> M3_CtKayy_res = M3_CtKayy_x; > > >>>>> BIT_FIELD_REF = (word_8) ((int_64) > > >>>>> BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); > > >>>>> = M3_CtKayy_res; > > >>>>> return ; > > >>>>> } > > >>>>> > > >>>>> compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: > > >>>>> > > >>>>> copy_sign_f (from, to) > > >>>>> { > > >>>>> float res; > > >>>>> float D.1918; > > >>>>> D.1917; > > >>>>> struct float_t * from.1; > > >>>>> struct float_t * res.0; > > >>>>> > > >>>>> : > > >>>>> res = to_1; > > >>>>> res.0_4 = (struct float_t *) &res; > > >>>>> from.1_5 = (struct float_t *) &from; > > >>>>> D.1917_6 = from.1_5->sign; > > >>>>> res.0_4->sign = D.1917_6; > > >>>>> D.1918_7 = res; > > >>>>> return D.1918_7; > > >>>>> > > >>>>> } > > >>>>> > > >>>>> > > >>>>> See, you know, from gcc's point of view, we don't have any records/structs/unions. > > >>>>> Just integers and offsets from them mostly. > > >>>>> > > >>>>> > > >>>>> The right fix is to build up types. > > >>>>> That way also debugging with gdb will have a chance. > > >>>>> Perhaps not a small amount of work. But maybe not too bad. > > >>>>> > > >>>>> > > >>>>> For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. > > >>>>> At least if one type but not the other is floating point. > > >>>>> I don't know if that will work, but maybe. > > >>>>> > > >>>>> Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or > > >>>>> store volatile. > > >>>>> > > >>>>> - Jay > > >>>>> > > >>>> > > >>> > > >> > > > > > > From mika at async.async.caltech.edu Tue Jul 6 07:58:33 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Mon, 05 Jul 2010 22:58:33 -0700 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20100705132228.0E6D52474003@birch.elegosoft.com>, <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu>, , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu>, , <6331F39C-AA28-4AC1-8C87-3D47D52D0C55@cs.purdue.edu>, , <02F12035-7271-4004-BE67-3DAB17C37B3B@cs.purdue.edu> Message-ID: <20100706055833.118D21A2080@async.async.caltech.edu> As I've said before, When I write: VAR a : INTEGER; BEGIN ... .... a := .. ... ... END that means I am putting you, the reader, on notice that I have no particularly meaningful idea of what a's initial value is. If I were to write VAR a := 0; BEGIN ... END I would mislead you into thinking that 0 is a somehow important initial value. Which it's not. It's just garbage, and it better not show up in the computation! Programs are mainly meant to be read by humans, not computers. Mika Jay K writes: >--_d2468f3b-9666-4291-98b5-5414421f54d9_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >We are going in circles. From jay.krell at cornell.edu Tue Jul 6 08:22:50 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Jul 2010 06:22:50 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20100706055833.118D21A2080@async.async.caltech.edu> References: <20100705132228.0E6D52474003@birch.elegosoft.com>, , <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , , , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu>, , , , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu>, , , , <6331F39C-AA28-4AC1-8C87-3D47D52D0C55@cs.purdue.edu>, , , , <02F12035-7271-4004-BE67-3DAB17C37B3B@cs.purdue.edu>, , <20100706055833.118D21A2080@async.async.caltech.edu> Message-ID: Programmers are notorious for making mistakes. When you write VAR a:INTEGER; you make the human proofreading your code have to work much harder to do the data/control flow analysis to make sure you didn't use the uninitialized value. Using the a := 0 value might still be "wrong", but is it at least consistent and the penalty for getting it wrong is generally less severe. Now, I don't want there to be a bug either way, but I feel that a consistent 0 is much "safer" than uninitialized. Either is typesafe, sure, but type safe is just the bare minimum expectation for my code. It must not only be type safe, but act correctly. Again, compiler isn't generally a program proofer, but the little it can do, let it do. Here is how I write C code: void function_with_two_temporary_buffers() { ? void* p = { 0 }; ? void* q = { 0 }; ? if (!(p = malloc(...))) ??? goto exit; ? if (!(q = malloc(...))) ??? goto exit; ... exit: ?? free(p); ?? free(q); } or void function_that_returns_two_buffers(void** a, void** b) { ? void* p = { 0 }; ? void* q = { 0 }; ? ? *a = p; ? *b = q; ? if (!(p = malloc(...)) ?? goto Exit; ? if (!(q = malloc(...)) ?? goto Exit; ??? .... ? *a = p; ?? p = 0; ?? *b = q; ?? q = 0; Exit: ? free(p); ? free(q); } In reality malloc is generally a function that returns an integer, negative for success. So it is more like: #define CHECK(expr) do { if ((status = (expr)) < 0) goto Exit; } while(0) ? CHECK(MemoryAlloc(..., &q)); See, the style is written to be easy for a human to verify the correctness of. Locals are always initialized. Ownership of resources is always clear. This is contrast with other styles: ?if (p = malloc(...)) ? { ????? ... ???? if (q = malloc(...)) ??? { ???????? ... ??????? free(q); ??? } ?? free(p); } where one has to follow the ever further indented blob of ifs. It doesn't scale. Every resource allocation makes the code incrementally harder for a human to read. Whereas the style that includes initializing all locals has no such incremental cost. (And this hard to read style is in fact somewhat encouraged by the "with" feature of Modula-3. C++'s equivalent -- declaring variables anywhere -- doesn't suggest ever increasing indentation. ) ?- Jay ---------------------------------------- > To: jay.krell at cornell.edu > Date: Mon, 5 Jul 2010 22:58:33 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > As I've said before, > > When I write: > > VAR > a : INTEGER; > BEGIN > > ... > > .... a := .. ... > > ... > > END > > that means I am putting you, the reader, on notice that I have no > particularly meaningful idea of what a's initial value is. > > If I were to write > > VAR > a := 0; > BEGIN > ... > END > > I would mislead you into thinking that 0 is a somehow important > initial value. Which it's not. It's just garbage, and it better > not show up in the computation! > > Programs are mainly meant to be read by humans, not computers. > > Mika > > > Jay K writes: > >--_d2468f3b-9666-4291-98b5-5414421f54d9_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >We are going in circles. From mika at async.async.caltech.edu Tue Jul 6 08:34:58 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Mon, 05 Jul 2010 23:34:58 -0700 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20100705132228.0E6D52474003@birch.elegosoft.com>, , <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , , , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu>, , , , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu>, , , , <6331F39C-AA28-4AC1-8C87-3D47D52D0C55@cs.purdue.edu>, , , , <02F12035-7271-4004-BE67-3DAB17C37B3B@cs.purdue.edu>, , <20100706055833.118D21A2080@async.async.caltech.edu> Message-ID: <20100706063458.DCFF41A2080@async.async.caltech.edu> Jay, I agree with the general premise that splitting declaration and initialization is bad coding style. I use WITH or the initialization of a procedure entry as much as possible to declare my variables. And if they have to change during the course of their lifetime, I do try to initialize them in the VAR. But... you're wrong :-) Imagine you have a variable whose initial value (i.e., the value it has before the first time it is used) is critical for the correctness of your algorithm. The initial value depends on something else, something that has to be computed. In this case, which does happen, at least in my code, there is no static value that is better than any other. VAR x : INTEGER; BEGIN is the right way to code that. VAR x := 0; BEGIN accomplishes exactly one thing: it obfuscates the code---it misleads the reader into thinking that x=0 is somehow relevant to the code, without adding anything at all to its correctness. As I said, the declaration that isn't initialized is to be used *sparingly* and whenever it is used it should be a giant red flag to the reader that the variable x is going to be initialized with a value that the programmer doesn't know at the time of declaration. What on earth do you gain from x := 0? A "little correctness"? Mika Jay K writes: > >Programmers are notorious for making mistakes. > > >When you write VAR a:INTEGER=3B >you make the human proofreading your code have to work much harder >to do the data/control flow analysis to make sure you didn't >use the uninitialized value. > > >Using the a :=3D 0 value might still be "wrong"=2C but is it at least consi= >stent >and the penalty for getting it wrong is generally less severe. > >Now=2C I don't want there to be a bug either way=2C but I feel that a consi= >stent 0 is much "safer" >than uninitialized. Either is typesafe=2C sure=2C but type safe is just the= > bare minimum expectation >for my code. It must not only be type safe=2C but act correctly. > >Again=2C compiler isn't generally a program proofer=2C but the little it ca= >n do=2C let it do. > > > >Here is how I write C code: > >void function_with_two_temporary_buffers() >{ >=A0 void* p =3D { 0 }=3B >=A0 void* q =3D { 0 }=3B > >=A0 if (!(p =3D malloc(...))) >=A0=A0=A0 goto exit=3B > >=A0 if (!(q =3D malloc(...))) > >=A0=A0=A0 goto exit=3B > > > >... > >exit: >=A0=A0 free(p)=3B >=A0=A0 free(q)=3B >} > >or >void function_that_returns_two_buffers(void** a=2C void** b) >{ >=A0 void* p =3D { 0 }=3B >=A0 void* q =3D { 0 }=3B >=A0=20 >=A0 *a =3D p=3B >=A0 *b =3D q=3B > >=A0 if (!(p =3D malloc(...)) >=A0=A0 goto Exit=3B > >=A0 if (!(q =3D malloc(...)) > >=A0=A0 goto Exit=3B > > > >=A0=A0=A0 .... >=A0 *a =3D p=3B >=A0=A0 p =3D 0=3B >=A0=A0 *b =3D q=3B >=A0=A0 q =3D 0=3B > >Exit:=20 >=A0 free(p)=3B >=A0 free(q)=3B > >} > >In reality malloc is generally a function that returns an integer=2C negati= >ve for success. >So it is more like: >#define CHECK(expr) do { if ((status =3D (expr)) < 0) goto Exit=3B } while(= >0) > > >=A0 CHECK(MemoryAlloc(...=2C &q))=3B > >See=2C the style is written to be easy for a human to verify the correctnes= >s of. >Locals are always initialized. Ownership of resources is always clear. > >This is contrast with other styles: > >=A0if (p =3D malloc(...)) >=A0 { >=A0=A0=A0=A0=A0 ... >=A0=A0=A0=A0 if (q =3D malloc(...)) >=A0=A0=A0 { >=A0=A0=A0=A0=A0=A0=A0=A0 ... >=A0=A0=A0=A0=A0=A0=A0 free(q)=3B >=A0=A0=A0 } >=A0=A0 free(p)=3B >} > >where one has to follow the ever further indented blob of ifs. >It doesn't scale. Every resource allocation makes the code incrementally ha= >rder for a human to read. >Whereas the style that includes initializing all locals has no such increme= >ntal cost. > >(And this hard to read style is in fact somewhat encouraged by the "with" f= >eature of Modula-3. >C++'s equivalent -- declaring variables anywhere -- doesn't suggest ever in= >creasing indentation. >) > > >=A0- Jay > > > >---------------------------------------- >> To: jay.krell at cornell.edu >> Date: Mon=2C 5 Jul 2010 22:58:33 -0700 >> From: mika at async.async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] [M3commit] CVS Update: cm3 >> >> >> As I've said before=2C >> >> When I write: >> >> VAR >> a : INTEGER=3B >> BEGIN >> >> ... >> >> .... a :=3D .. ... >> >> ... >> >> END >> >> that means I am putting you=2C the reader=2C on notice that I have no >> particularly meaningful idea of what a's initial value is. >> >> If I were to write >> >> VAR >> a :=3D 0=3B >> BEGIN >> ... >> END >> >> I would mislead you into thinking that 0 is a somehow important >> initial value. Which it's not. It's just garbage=2C and it better >> not show up in the computation! >> >> Programs are mainly meant to be read by humans=2C not computers. >> >> Mika >> >> >> Jay K writes: >> >--_d2468f3b-9666-4291-98b5-5414421f54d9_ >> >Content-Type: text/plain=3B charset=3D"iso-8859-1" >> >Content-Transfer-Encoding: quoted-printable >> > >> > >> >We are going in circles. > = From mika at async.async.caltech.edu Tue Jul 6 08:35:47 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Mon, 05 Jul 2010 23:35:47 -0700 Subject: [M3devel] [M3commit] CVS Update: cm3 Message-ID: <20100706063547.81FC21A2080@async.async.caltech.edu> >When you write VAR a:INTEGER=3B >you make the human proofreading your code have to work much harder >to do the data/control flow analysis to make sure you didn't >use the uninitialized value. And yes, that's precisely the point! From jay.krell at cornell.edu Tue Jul 6 12:05:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Jul 2010 10:05:43 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20100706063458.DCFF41A2080@async.async.caltech.edu> References: <20100705132228.0E6D52474003@birch.elegosoft.com>, , <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , , , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu>, , , , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu>, , , , <6331F39C-AA28-4AC1-8C87-3D47D52D0C55@cs.purdue.edu>, , , , <02F12035-7271-4004-BE67-3DAB17C37B3B@cs.purdue.edu>, , <20100706055833.118D21A2080@async.async.caltech.edu> , <20100706063458.DCFF41A2080@async.async.caltech.edu> Message-ID: > used it should be a giant red flag to the reader that the variable x is > going to be initialized with a value that the programmer doesn't know > at the time of declaration. What on earth do you gain from x := 0? > A "little correctness"? You are making the code more expensive to maintain, by making it harder for a human to analyze. For the benefit of microoptimization. ?- Jay ---------------------------------------- > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > Date: Mon, 5 Jul 2010 23:34:58 -0700 > From: mika at async.async.caltech.edu > > > Jay, I agree with the general premise that splitting declaration and > initialization is bad coding style. I use WITH or the initialization > of a procedure entry as much as possible to declare my variables. > And if they have to change during the course of their lifetime, > I do try to initialize them in the VAR. > > But... you're wrong :-) > > Imagine you have a variable whose initial value (i.e., the value it has > before the first time it is used) is critical for the correctness of > your algorithm. The initial value depends on something else, something > that has to be computed. In this case, which does happen, at least > in my code, there is no static value that is better than any other. > VAR x : INTEGER; BEGIN is the right way to code that. VAR x := 0; BEGIN > accomplishes exactly one thing: it obfuscates the code---it misleads the > reader into thinking that x=0 is somehow relevant to the code, without > adding anything at all to its correctness. As I said, the declaration > that isn't initialized is to be used *sparingly* and whenever it is > used it should be a giant red flag to the reader that the variable x is > going to be initialized with a value that the programmer doesn't know > at the time of declaration. What on earth do you gain from x := 0? > A "little correctness"? > > Mika > > Jay K writes: > > > >Programmers are notorious for making mistakes. > > > > > >When you write VAR a:INTEGER=3B > >you make the human proofreading your code have to work much harder > >to do the data/control flow analysis to make sure you didn't > >use the uninitialized value. > > > > > >Using the a :=3D 0 value might still be "wrong"=2C but is it at least consi= > >stent > >and the penalty for getting it wrong is generally less severe. > > > >Now=2C I don't want there to be a bug either way=2C but I feel that a consi= > >stent 0 is much "safer" > >than uninitialized. Either is typesafe=2C sure=2C but type safe is just the= > > bare minimum expectation > >for my code. It must not only be type safe=2C but act correctly. > > > >Again=2C compiler isn't generally a program proofer=2C but the little it ca= > >n do=2C let it do. > > > > > > > >Here is how I write C code: > > > >void function_with_two_temporary_buffers() > >{ > >=A0 void* p =3D { 0 }=3B > >=A0 void* q =3D { 0 }=3B > > > >=A0 if (!(p =3D malloc(...))) > >=A0=A0=A0 goto exit=3B > > > >=A0 if (!(q =3D malloc(...))) > > > >=A0=A0=A0 goto exit=3B > > > > > > > >... > > > >exit: > >=A0=A0 free(p)=3B > >=A0=A0 free(q)=3B > >} > > > >or > >void function_that_returns_two_buffers(void** a=2C void** b) > >{ > >=A0 void* p =3D { 0 }=3B > >=A0 void* q =3D { 0 }=3B > >=A0=20 > >=A0 *a =3D p=3B > >=A0 *b =3D q=3B > > > >=A0 if (!(p =3D malloc(...)) > >=A0=A0 goto Exit=3B > > > >=A0 if (!(q =3D malloc(...)) > > > >=A0=A0 goto Exit=3B > > > > > > > >=A0=A0=A0 .... > >=A0 *a =3D p=3B > >=A0=A0 p =3D 0=3B > >=A0=A0 *b =3D q=3B > >=A0=A0 q =3D 0=3B > > > >Exit:=20 > >=A0 free(p)=3B > >=A0 free(q)=3B > > > >} > > > >In reality malloc is generally a function that returns an integer=2C negati= > >ve for success. > >So it is more like: > >#define CHECK(expr) do { if ((status =3D (expr)) < 0) goto Exit=3B } while(= > >0) > > > > > >=A0 CHECK(MemoryAlloc(...=2C &q))=3B > > > >See=2C the style is written to be easy for a human to verify the correctnes= > >s of. > >Locals are always initialized. Ownership of resources is always clear. > > > >This is contrast with other styles: > > > >=A0if (p =3D malloc(...)) > >=A0 { > >=A0=A0=A0=A0=A0 ... > >=A0=A0=A0=A0 if (q =3D malloc(...)) > >=A0=A0=A0 { > >=A0=A0=A0=A0=A0=A0=A0=A0 ... > >=A0=A0=A0=A0=A0=A0=A0 free(q)=3B > >=A0=A0=A0 } > >=A0=A0 free(p)=3B > >} > > > >where one has to follow the ever further indented blob of ifs. > >It doesn't scale. Every resource allocation makes the code incrementally ha= > >rder for a human to read. > >Whereas the style that includes initializing all locals has no such increme= > >ntal cost. > > > >(And this hard to read style is in fact somewhat encouraged by the "with" f= > >eature of Modula-3. > >C++'s equivalent -- declaring variables anywhere -- doesn't suggest ever in= > >creasing indentation. > >) > > > > > >=A0- Jay > > > > > > > >---------------------------------------- > >> To: jay.krell at cornell.edu > >> Date: Mon=2C 5 Jul 2010 22:58:33 -0700 > >> From: mika at async.async.caltech.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > >> > >> > >> As I've said before=2C > >> > >> When I write: > >> > >> VAR > >> a : INTEGER=3B > >> BEGIN > >> > >> ... > >> > >> .... a :=3D .. ... > >> > >> ... > >> > >> END > >> > >> that means I am putting you=2C the reader=2C on notice that I have no > >> particularly meaningful idea of what a's initial value is. > >> > >> If I were to write > >> > >> VAR > >> a :=3D 0=3B > >> BEGIN > >> ... > >> END > >> > >> I would mislead you into thinking that 0 is a somehow important > >> initial value. Which it's not. It's just garbage=2C and it better > >> not show up in the computation! > >> > >> Programs are mainly meant to be read by humans=2C not computers. > >> > >> Mika > >> > >> > >> Jay K writes: > >> >--_d2468f3b-9666-4291-98b5-5414421f54d9_ > >> >Content-Type: text/plain=3B charset=3D"iso-8859-1" > >> >Content-Transfer-Encoding: quoted-printable > >> > > >> > > >> >We are going in circles. > > = From jay.krell at cornell.edu Tue Jul 6 12:08:30 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Jul 2010 10:08:30 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20100706063547.81FC21A2080@async.async.caltech.edu> References: <20100706063547.81FC21A2080@async.async.caltech.edu> Message-ID: ---------------------------------------- > To: jay > CC: m3devel > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > Date: Mon, 5 Jul 2010 23:35:47 -0700 > From: mikau > > >When you write VAR a:INTEGER=3B > >you make the human proofreading your code have to work much harder > >to do the data/control flow analysis to make sure you didn't > >use the uninitialized value. > > And yes, that's precisely the point! You are just adding to the maintenance cost of the code. If something makes it much more difficult to analyze by a human, and doesn't provide much benefit, don't do it. Esp. when a large fraction of the time, the compiler with far more cycles to burn, will be able to make the micro optimization. And another fraction of the time, the computer running the program will have plenty of cycles. ?(granted, the code is larger, and disk cycles are scarce). ?- Jay From jay.krell at cornell.edu Tue Jul 6 14:28:34 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Jul 2010 12:28:34 +0000 Subject: [M3devel] yet another proposed fix.. careful insertion of one instance of CG.Force() in CastExpr.m3 Message-ID: Ok, this is interesting. I think. Finally. I need to test more, but it is looking very promising. I think you'll like it (Tony). I still don't understand all the flow around the front end. I had to try out some guesses. It certainly appears that m3front/src/misc/CG.m3 is in the business of optimizations. This change might actually be too conservative. It defeats optimization in CG.m3. It limits it to D_to_S when one type is float and the other isn't. ?I guess S (struct) can't really be float. The assertion failure in gcc btw, was gcc_assert( something_is_float == other_is_float). So the conservativeness is somewhat sensible. Limiting it to D_to_S, though, unclear. The change is just inserting CG.Force(). OK? (Let me test a bit more -- build the entire tree.) This appears to let me leave "ter" on. I can try leaving other optimizations on. Index: exprs/CastExpr.m3 =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/CastExpr.m3,v retrieving revision 1.9 diff -u -r1.9 CastExpr.m3 --- exprs/CastExpr.m3??? 5 Jul 2010 11:28:32 -0000??? 1.9 +++ exprs/CastExpr.m3??? 6 Jul 2010 12:23:14 -0000 @@ -10,6 +10,7 @@ ? ?IMPORT M3Buf, CG, Expr, ExprRep, Type, Error, OpenArrayType; ?IMPORT M3, M3ID, M3RT, Target, TInt; +FROM Target IMPORT FloatType; ? ?TYPE ?? Kind = { @@ -394,7 +395,7 @@ ???? u? := Expr.TypeOf (e); ???? t? := p.tipe; ???? sz, t_align, u_align, z_align: INTEGER; -??? u_cg: CG.Type; +??? u_cg, t_cg: CG.Type; ???? u_info, t_info: Type.Info; ?? BEGIN ???? u := Type.CheckInfo (u, u_info); @@ -403,6 +404,7 @@ ???? u_align := u_info.alignment; ???? z_align := MAX (t_align, u_align); ???? u_cg := u_info.stk_type; +??? t_cg := t_info.stk_type; ???? sz := u_info.size; ???? Type.Compile (t); ???? Type.Compile (u); @@ -416,6 +418,15 @@ ?????? Kind.V_to_V => ???????? Expr.CompileLValue (p.expr, traced); ???????? CG.Boost_alignment (t_align); +(* Inhibit some optimization that causes compilation to fail. e.g. m3core: +../src/float/IEEE/RealFloat.m3: In function 'RealFloat__CopySign': +../src/float/IEEE/RealFloat.m3:96: internal compiler error: in convert_move, at expr.c:371 +../src/float/IEEE/LongFloat.m3: In function 'LongFloat__CopySign': +../src/float/IEEE/LongFloat.m3:116: internal compiler error: in convert_move, at expr.c:371 +*) +??????? IF p.kind = Kind.D_to_S AND FloatType[u_cg] # FloatType[t_cg] THEN +????????? CG.Force (); +??????? END; ? ???? | Kind.D_to_A, ?????? Kind.S_to_A, (577) begin_procedure ? procedure LongFloat__CopySign ?LongFloat__CopySign(578) set_source_line ? source line? 117 (579) load ? type:lreal ? type:lreal ? m3cg_load (M3_CtKayy_x): offset 0x0, convert lreal -> lreal (580) store ? type:lreal ? type:lreal ? store (M3_CtKayy_res) offset:0x0 src_t:lreal dst_t:lreal (581) set_source_line ? source line? 119 now notice we have use of load_address and load_indirect here, where before we had no address and load (direct) (582) load_address ? load address (M3_CtKayy_res) offset 0x0 (583) load_address ? load address (M3_CtKayy_y) offset 0x0 (584) load_indirect ? type:word8 ? type:int64 ? load address offset:0x38 src_t:word8 dst_t:int64 (585) extract_mn ? type:int64 ?extract_mn offset:7 count:1 sign_extend:0 (586) swap ? type:addr ? type:int64 (587) declare_temp ? type:addr ? temp var type:addr size:0x40 alignment:0x40 (588) store ? type:addr ? type:addr ? store (noname) offset:0x0 src_t:addr dst_t:addr (589) load ? type:addr ? type:addr ? m3cg_load (noname): offset 0x0, convert addr -> addr (590) load_indirect ? type:word8 ? type:int64 ? load address offset:0x38 src_t:word8 dst_t:int64 (591) swap ? type:int64 ? type:word8 (592) insert_mn ? type:int64 ?insert_mn offset:7 count:1 (593) load ? type:addr ? type:addr ? m3cg_load (noname): offset 0x0, convert addr -> addr (594) swap ? type:word8 ? type:addr (595) store_indirect ? type:int64 ? type:word8 ? store indirect offset:0x38 src_t:int64 dst_t:word8 (596) set_source_line ? source line? 120 (597) load ? type:lreal ? type:lreal ? m3cg_load (M3_CtKayy_res): offset 0x0, convert lreal -> lreal (598) exit_proc ? type:lreal (599) free_temp (600) end_procedure ? procedure LongFloat__CopySign ?- Jay From hosking at cs.purdue.edu Tue Jul 6 15:50:33 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 6 Jul 2010 09:50:33 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20100706055833.118D21A2080@async.async.caltech.edu> References: <20100705132228.0E6D52474003@birch.elegosoft.com>, <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu>, , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu>, , <6331F39C-AA28-4AC1-8C87-3D47D52D0C55@cs.purdue.edu>, , <02F12035-7271-4004-BE67-3DAB17C37B3B@cs.purdue.edu> <20100706055833.118D21A2080@async.async.caltech.edu> Message-ID: Thanks Mika, That's what I was hoping to express but I was too tired. I don't think we can convince Jay, but I do want him to understand at least that there is strong resistance to his desire to add all of these value initialisers, and that it really is not a priority. On 6 Jul 2010, at 01:58, Mika Nystrom wrote: > > As I've said before, > > When I write: > > VAR > a : INTEGER; > BEGIN > > ... > > .... a := .. ... > > ... > > END > > that means I am putting you, the reader, on notice that I have no > particularly meaningful idea of what a's initial value is. > > If I were to write > > VAR > a := 0; > BEGIN > ... > END > > I would mislead you into thinking that 0 is a somehow important > initial value. Which it's not. It's just garbage, and it better > not show up in the computation! > > Programs are mainly meant to be read by humans, not computers. > > Mika > > > Jay K writes: >> --_d2468f3b-9666-4291-98b5-5414421f54d9_ >> Content-Type: text/plain; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> >> We are going in circles. From hosking at cs.purdue.edu Tue Jul 6 15:58:19 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 6 Jul 2010 09:58:19 -0400 Subject: [M3devel] yet another proposed fix.. careful insertion of one instance of CG.Force() in CastExpr.m3 In-Reply-To: References: Message-ID: <0FABE0B5-71CE-49F8-BD07-688EA9DC1C17@cs.purdue.edu> I wonder if we should be forcing all D_to_S? Is it really only floats that cause this problem? Why would that be the case? On 6 Jul 2010, at 08:28, Jay K wrote: > > Ok, this is interesting. I think. Finally. > I need to test more, but it is looking very promising. I think you'll like it (Tony). > I still don't understand all the flow around the front end. I had to try out some guesses. > It certainly appears that m3front/src/misc/CG.m3 is in the business of optimizations. > This change might actually be too conservative. > It defeats optimization in CG.m3. It limits it to D_to_S when one type is float and the other isn't. > I guess S (struct) can't really be float. > > > The assertion failure in gcc btw, was gcc_assert( something_is_float == other_is_float). > So the conservativeness is somewhat sensible. > Limiting it to D_to_S, though, unclear. > > > The change is just inserting CG.Force(). > > > OK? (Let me test a bit more -- build the entire tree.) > > This appears to let me leave "ter" on. > I can try leaving other optimizations on. > > > Index: exprs/CastExpr.m3 > =================================================================== > RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/CastExpr.m3,v > retrieving revision 1.9 > diff -u -r1.9 CastExpr.m3 > --- exprs/CastExpr.m3 5 Jul 2010 11:28:32 -0000 1.9 > +++ exprs/CastExpr.m3 6 Jul 2010 12:23:14 -0000 > @@ -10,6 +10,7 @@ > > IMPORT M3Buf, CG, Expr, ExprRep, Type, Error, OpenArrayType; > IMPORT M3, M3ID, M3RT, Target, TInt; > +FROM Target IMPORT FloatType; > > TYPE > Kind = { > @@ -394,7 +395,7 @@ > u := Expr.TypeOf (e); > t := p.tipe; > sz, t_align, u_align, z_align: INTEGER; > - u_cg: CG.Type; > + u_cg, t_cg: CG.Type; > u_info, t_info: Type.Info; > BEGIN > u := Type.CheckInfo (u, u_info); > @@ -403,6 +404,7 @@ > u_align := u_info.alignment; > z_align := MAX (t_align, u_align); > u_cg := u_info.stk_type; > + t_cg := t_info.stk_type; > sz := u_info.size; > Type.Compile (t); > Type.Compile (u); > @@ -416,6 +418,15 @@ > Kind.V_to_V => > Expr.CompileLValue (p.expr, traced); > CG.Boost_alignment (t_align); > +(* Inhibit some optimization that causes compilation to fail. e.g. m3core: > +../src/float/IEEE/RealFloat.m3: In function 'RealFloat__CopySign': > +../src/float/IEEE/RealFloat.m3:96: internal compiler error: in convert_move, at expr.c:371 > +../src/float/IEEE/LongFloat.m3: In function 'LongFloat__CopySign': > +../src/float/IEEE/LongFloat.m3:116: internal compiler error: in convert_move, at expr.c:371 > +*) > + IF p.kind = Kind.D_to_S AND FloatType[u_cg] # FloatType[t_cg] THEN > + CG.Force (); > + END; > > | Kind.D_to_A, > Kind.S_to_A, > > > > (577) begin_procedure > procedure LongFloat__CopySign > LongFloat__CopySign(578) set_source_line > source line 117 > (579) load > type:lreal > type:lreal > m3cg_load (M3_CtKayy_x): offset 0x0, convert lreal -> lreal > (580) store > type:lreal > type:lreal > store (M3_CtKayy_res) offset:0x0 src_t:lreal dst_t:lreal > (581) set_source_line > source line 119 > > > now notice we have use of load_address and load_indirect here, where before we had no address and load (direct) > > > (582) load_address > load address (M3_CtKayy_res) offset 0x0 > (583) load_address > load address (M3_CtKayy_y) offset 0x0 > (584) load_indirect > type:word8 > type:int64 > load address offset:0x38 src_t:word8 dst_t:int64 > (585) extract_mn > type:int64 > extract_mn offset:7 count:1 sign_extend:0 > (586) swap > type:addr > type:int64 > (587) declare_temp > type:addr > temp var type:addr size:0x40 alignment:0x40 > (588) store > type:addr > type:addr > store (noname) offset:0x0 src_t:addr dst_t:addr > (589) load > type:addr > type:addr > m3cg_load (noname): offset 0x0, convert addr -> addr > (590) load_indirect > type:word8 > type:int64 > load address offset:0x38 src_t:word8 dst_t:int64 > (591) swap > type:int64 > type:word8 > (592) insert_mn > type:int64 > insert_mn offset:7 count:1 > (593) load > type:addr > type:addr > m3cg_load (noname): offset 0x0, convert addr -> addr > (594) swap > type:word8 > type:addr > (595) store_indirect > type:int64 > type:word8 > store indirect offset:0x38 src_t:int64 dst_t:word8 > (596) set_source_line > source line 120 > (597) load > type:lreal > type:lreal > m3cg_load (M3_CtKayy_res): offset 0x0, convert lreal -> lreal > (598) exit_proc > type:lreal > (599) free_temp > (600) end_procedure > procedure LongFloat__CopySign > > > > - Jay > > From rodney_bates at lcwb.coop Tue Jul 6 17:11:55 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 06 Jul 2010 10:11:55 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20100706055833.118D21A2080@async.async.caltech.edu> References: <20100705132228.0E6D52474003@birch.elegosoft.com>, <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu>, , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu>, , <6331F39C-AA28-4AC1-8C87-3D47D52D0C55@cs.purdue.edu>, , <02F12035-7271-4004-BE67-3DAB17C37B3B@cs.purdue.edu> <20100706055833.118D21A2080@async.async.caltech.edu> Message-ID: <4C3347BB.3050206@lcwb.coop> Mika Nystrom wrote: > As I've said before, > > When I write: > > VAR > a : INTEGER; > BEGIN > > ... > > .... a := .. ... > > ... > > END > > that means I am putting you, the reader, on notice that I have no > particularly meaningful idea of what a's initial value is. > > If I were to write > > VAR > a := 0; > BEGIN > ... > END > > I would mislead you into thinking that 0 is a somehow important > initial value. Which it's not. It's just garbage, and it better > not show up in the computation! I often write an initialization in a variable declaration that I fully expect will be overwritten before it is used, assuming I don't make a mistake elsewhere. I do this probably more often in field declarations of record and object types than in variables. I do it because it makes bugs more likely to be repeatable. This is at the cost that it may occasionally make a bug go unnoticed altogether because the initial value happens to suppress an obvious symptom. *But*, if it's code I wrote in the last ten years, or maybe fifteen, such initializations always have (* Paranoid. *) or (* Defensive. *) or a similar comment, for exactly Mika's reason. It tells a reader that this value is intended not be algorithmically significant. I suppose one could assume that an implementation of Modula-3 would initialize things consistently, but that relies on something that is not a rule of the language. Moreover, it is very likely not true for a type where all bit patterns represent members of the type. Sometimes I try to pick a really weird value, just so it will be more conspicuous and more likely to trigger a symptom, if it ever gets mistakenly used. This also helps in a debugger just to see if a real algorithmic initialization has ever been reached. For many types, I often reserve a distinct value to mean "unknown" or "meaningless", for some reason or other. Sometimes I even have more than one such special value. > > Programs are mainly meant to be read by humans, not computers. > > Mika > > > Jay K writes: >> --_d2468f3b-9666-4291-98b5-5414421f54d9_ >> Content-Type: text/plain; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> >> We are going in circles. > From hosking at cs.purdue.edu Tue Jul 6 17:45:21 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 6 Jul 2010 11:45:21 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <4C3347BB.3050206@lcwb.coop> References: <20100705132228.0E6D52474003@birch.elegosoft.com>, <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu>, , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu>, , <6331F39C-AA28-4AC1-8C87-3D47D52D0C55@cs.purdue.edu>, , <02F12035-7271-4004-BE67-3DAB17C37B3B@cs.purdue.edu> <20100706055833.118D21A2080@async.async.caltech.edu> <4C3347BB.3050206@lcwb.coop> Message-ID: <0B0BBBE5-3841-48BF-BB4F-E27EBDFBBEEF@cs.purdue.edu> I guess I just don't see the difference between writing: := 0 or := 1234567 or := -1 other than perhaps efficiency. In which case, excepting that you have a *known* initial value, writing: : INTEGER is no less expressive. On 6 Jul 2010, at 11:11, Rodney M. Bates wrote: > > > Mika Nystrom wrote: >> As I've said before, >> When I write: >> VAR a : INTEGER; >> BEGIN >> ... >> .... a := .. ... >> ... >> END >> that means I am putting you, the reader, on notice that I have no >> particularly meaningful idea of what a's initial value is. >> If I were to write VAR a := 0; >> BEGIN >> ... >> END >> I would mislead you into thinking that 0 is a somehow important >> initial value. Which it's not. It's just garbage, and it better >> not show up in the computation! > > I often write an initialization in a variable declaration that I > fully expect will be overwritten before it is used, assuming I > don't make a mistake elsewhere. I do this probably more often > in field declarations of record and object types than in variables. > > I do it because it makes bugs more likely to be repeatable. > This is at the cost that it may occasionally make a bug go > unnoticed altogether because the initial value happens to > suppress an obvious symptom. > > *But*, if it's code I wrote in the last ten years, or > maybe fifteen, such initializations always have (* Paranoid. *) > or (* Defensive. *) or a similar comment, for exactly Mika's > reason. It tells a reader that this value is intended not be > algorithmically significant. > > I suppose one could assume that an implementation of Modula-3 > would initialize things consistently, but that relies on > something that is not a rule of the language. Moreover, it > is very likely not true for a type where all bit patterns > represent members of the type. > > Sometimes I try to pick a really weird value, just so > it will be more conspicuous and more likely to trigger > a symptom, if it ever gets mistakenly used. This also helps > in a debugger just to see if a real algorithmic initialization > has ever been reached. > > For many types, I often reserve a distinct value to mean "unknown" > or "meaningless", for some reason or other. Sometimes I even > have more than one such special value. > > >> Programs are mainly meant to be read by humans, not computers. >> Mika >> Jay K writes: >>> --_d2468f3b-9666-4291-98b5-5414421f54d9_ >>> Content-Type: text/plain; charset="iso-8859-1" >>> Content-Transfer-Encoding: quoted-printable >>> >>> >>> We are going in circles. From hendrik at topoi.pooq.com Tue Jul 6 18:53:56 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 6 Jul 2010 12:53:56 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20100706055833.118D21A2080@async.async.caltech.edu> <20100706063458.DCFF41A2080@async.async.caltech.edu> Message-ID: <20100706165355.GA1520@topoi.pooq.com> On Tue, Jul 06, 2010 at 10:05:43AM +0000, Jay K wrote: > > > used it should be a giant red flag to the reader that the variable x is > > going to be initialized with a value that the programmer doesn't know > > at the time of declaration. What on earth do you gain from x := 0? > > A "little correctness"? > > You are making the code more expensive to maintain, by making > it harder for a human to analyze. For the benefit of microoptimization. Microoptimisation as a purpose? Didn't he just explain that VAR x : INTEGER; is intended to signal to the *reader* that the initial value is irrelevant? The fact that a naive compiler might compile it slightly more efficiently is a side effect, not a purpose. If he were interested in microoptimisation, he would better feed it into a flow-analysing compiler, which could even detect when an explicit initialization like VAR x := 0; is irrelevant and suppress it. It's not *about* optimisation. Indeed, they syntactic awkwardness of declaring variables with WITH (to make sure they're initialized where they're declared) is one of the problems of Modula 3, and one of the few places where C did it better. Granted C, didn't do this at all initially, and took it from Algol 68 in one of C's rounds of standardisation. -- hendrik From hendrik at topoi.pooq.com Tue Jul 6 19:02:28 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 6 Jul 2010 13:02:28 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20100706055833.118D21A2080@async.async.caltech.edu> Message-ID: <20100706170228.GB1520@topoi.pooq.com> On Tue, Jul 06, 2010 at 06:22:50AM +0000, Jay K wrote: > > Programmers are notorious for making mistakes. > > > When you write VAR a:INTEGER; > you make the human proofreading your code have to work much harder > to do the data/control flow analysis to make sure you didn't > use the uninitialized value. > > > Using the a := 0 value might still be "wrong", but is it at least consistent > and the penalty for getting it wrong is generally less severe. > > Now, I don't want there to be a bug either way, but I feel that a consistent 0 is much "safer" > than uninitialized. Either is typesafe, sure, but type safe is just the bare minimum expectation > for my code. It must not only be type safe, but act correctly. > > Again, compiler isn't generally a program proofer, but the little it can do, let it do. Agree with letting the compiler find flaws by flow analysis and report them, if it can. But explicitly initializing it so zero so that (a) the ocmpiler won't notice it's really uninitilized, and (b) it's going to have less of a penalty for getting it wrong? I disagree with this. If there's a bug in my program I want to find it so I can fix it. I don't want it masked by an arbitrary but innocuous initial value. Here's where letting the ocmpiler initialize undefined integer variables to something like 1683002888 might actually contribute to debugging, especially if it chooses this consistently so you can rerun the program reliable while you close in on the error. But for the programmer to write VAR x := 1683002888; would likely confuse the human reader, who would spend ages pondering why *that* value. - hendrik From hosking at cs.purdue.edu Tue Jul 6 19:00:21 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 6 Jul 2010 13:00:21 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20100706165355.GA1520@topoi.pooq.com> References: <20100706055833.118D21A2080@async.async.caltech.edu> <20100706063458.DCFF41A2080@async.async.caltech.edu> <20100706165355.GA1520@topoi.pooq.com> Message-ID: I agree. If Modula-3 was being designed today it would impose the same ban on uninitialized use of variables that Java does. We have a language that does not impose that ban, but instead assures that every ininitialized variable holds a valid value. I much prefer to see VAR x: INTEGER as an *explicit* marker that the variable holds an indeterminate but valid value. Seeing VAR x := 0 implies to me that there is something especially significant about the initial value 0. On 6 Jul 2010, at 12:53, hendrik at topoi.pooq.com wrote: > On Tue, Jul 06, 2010 at 10:05:43AM +0000, Jay K wrote: >> >>> used it should be a giant red flag to the reader that the variable x is >>> going to be initialized with a value that the programmer doesn't know >>> at the time of declaration. What on earth do you gain from x := 0? >>> A "little correctness"? >> >> You are making the code more expensive to maintain, by making >> it harder for a human to analyze. For the benefit of microoptimization. > > Microoptimisation as a purpose? Didn't he just explain that > VAR x : INTEGER; > is intended to signal to the *reader* that the initial value is > irrelevant? The fact that a naive compiler might compile it slightly > more efficiently is a side effect, not a purpose. If he were interested > in microoptimisation, he would better feed it into a flow-analysing > compiler, which could even detect when an explicit initialization like > VAR x := 0; > is irrelevant and suppress it. > > It's not *about* optimisation. > > Indeed, they syntactic awkwardness of declaring variables with WITH > (to make sure they're initialized where they're declared) is one of > the problems of Modula 3, and one of the few places where C did it > better. Granted C, didn't do this at all initially, and took it from > Algol 68 in one of C's rounds of standardisation. > > -- hendrik From hosking at cs.purdue.edu Tue Jul 6 19:04:36 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 6 Jul 2010 13:04:36 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20100706170228.GB1520@topoi.pooq.com> References: <20100706055833.118D21A2080@async.async.caltech.edu> <20100706170228.GB1520@topoi.pooq.com> Message-ID: So, here is a proposal. Why not have a flag to the M3 compiler that tells it to initialise every value with zero for numbers, NIL for references, or FIRST(T) for enumerations/subranges? I am sure we can come up with something reasonable for all the primitive types. This would be an aid to debugging, but avoid the need for explicit initialisation be expressed in the code. Then, if you find yourself wondering if an uninitialised variable is the culprit for some bug then you can simply turn on the flag. It would also have the side-effect of passing the flag Jay is using to the cm3cg backend. On 6 Jul 2010, at 13:02, hendrik at topoi.pooq.com wrote: > On Tue, Jul 06, 2010 at 06:22:50AM +0000, Jay K wrote: >> >> Programmers are notorious for making mistakes. >> >> >> When you write VAR a:INTEGER; >> you make the human proofreading your code have to work much harder >> to do the data/control flow analysis to make sure you didn't >> use the uninitialized value. >> >> >> Using the a := 0 value might still be "wrong", but is it at least consistent >> and the penalty for getting it wrong is generally less severe. >> >> Now, I don't want there to be a bug either way, but I feel that a consistent 0 is much "safer" >> than uninitialized. Either is typesafe, sure, but type safe is just the bare minimum expectation >> for my code. It must not only be type safe, but act correctly. >> >> Again, compiler isn't generally a program proofer, but the little it can do, let it do. > > Agree with letting the compiler find flaws by flow analysis and > report them, if it can. > > But explicitly initializing it so zero so that (a) the ocmpiler won't > notice it's really uninitilized, and (b) it's going to have less of a > penalty for getting it wrong? I disagree with this. If there's a bug > in my program I want to find it so I can fix it. I don't want it > masked by an arbitrary but innocuous initial value. > > Here's where letting the ocmpiler initialize undefined integer > variables to something like 1683002888 might actually contribute to > debugging, especially if it chooses this consistently so you can rerun > the program reliable while you close in on the error. > > But for the programmer to write > > VAR x := 1683002888; > > would likely confuse the human reader, who would spend ages pondering > why *that* value. > > - hendrik From hosking at cs.purdue.edu Tue Jul 6 19:10:34 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 6 Jul 2010 13:10:34 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20100706055833.118D21A2080@async.async.caltech.edu> <20100706170228.GB1520@topoi.pooq.com> Message-ID: Or, alternatively, we could turn it around and have a flag that turns off (for performance if desired) well-defined initialisations (much like nochecks does to turn off other runtime checks). This would be in the spirit of the language spec, which says simply that some legal value is present, and simply go one step further in making the initialised value deterministic. As far as I can tell, this changes only the behaviour of "automatic" variables (function-scope local variables) whose initial value can be any combination of bits in the variable. All other variables get deterministic initial values already. On 6 Jul 2010, at 13:04, Tony Hosking wrote: > So, here is a proposal. > Why not have a flag to the M3 compiler that tells it to initialise every value with zero for numbers, NIL for references, or FIRST(T) for enumerations/subranges? I am sure we can come up with something reasonable for all the primitive types. > This would be an aid to debugging, but avoid the need for explicit initialisation be expressed in the code. > > Then, if you find yourself wondering if an uninitialised variable is the culprit for some bug then you can simply turn on the flag. > It would also have the side-effect of passing the flag Jay is using to the cm3cg backend. > > On 6 Jul 2010, at 13:02, hendrik at topoi.pooq.com wrote: > >> On Tue, Jul 06, 2010 at 06:22:50AM +0000, Jay K wrote: >>> >>> Programmers are notorious for making mistakes. >>> >>> >>> When you write VAR a:INTEGER; >>> you make the human proofreading your code have to work much harder >>> to do the data/control flow analysis to make sure you didn't >>> use the uninitialized value. >>> >>> >>> Using the a := 0 value might still be "wrong", but is it at least consistent >>> and the penalty for getting it wrong is generally less severe. >>> >>> Now, I don't want there to be a bug either way, but I feel that a consistent 0 is much "safer" >>> than uninitialized. Either is typesafe, sure, but type safe is just the bare minimum expectation >>> for my code. It must not only be type safe, but act correctly. >>> >>> Again, compiler isn't generally a program proofer, but the little it can do, let it do. >> >> Agree with letting the compiler find flaws by flow analysis and >> report them, if it can. >> >> But explicitly initializing it so zero so that (a) the ocmpiler won't >> notice it's really uninitilized, and (b) it's going to have less of a >> penalty for getting it wrong? I disagree with this. If there's a bug >> in my program I want to find it so I can fix it. I don't want it >> masked by an arbitrary but innocuous initial value. >> >> Here's where letting the ocmpiler initialize undefined integer >> variables to something like 1683002888 might actually contribute to >> debugging, especially if it chooses this consistently so you can rerun >> the program reliable while you close in on the error. >> >> But for the programmer to write >> >> VAR x := 1683002888; >> >> would likely confuse the human reader, who would spend ages pondering >> why *that* value. >> >> - hendrik > From hendrik at topoi.pooq.com Tue Jul 6 19:23:05 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 6 Jul 2010 13:23:05 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20100706055833.118D21A2080@async.async.caltech.edu> <20100706170228.GB1520@topoi.pooq.com> Message-ID: <20100706172305.GC1520@topoi.pooq.com> On Tue, Jul 06, 2010 at 01:10:34PM -0400, Tony Hosking wrote: > Or, alternatively, we could turn it around and have a flag that turns off (for performance if desired) well-defined initialisations (much like nochecks does to turn off other runtime checks). This would be in the spirit of the language spec, which says simply that some legal value is present, and simply go one step further in making the initialised value deterministic. As far as I can tell, this changes only the behaviour of "automatic" variables (function-scope local variables) whose initial value can be any combination of bits in the variable. All other variables get deterministic initial values already. A flag like that that uses a consistent junk value would also be useful, since it's less likely to be accidentally masked. Zero is far too commonly valid for the application, and not just valid for the language. -- hendrik From hosking at cs.purdue.edu Tue Jul 6 21:18:26 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 6 Jul 2010 15:18:26 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20100706172305.GC1520@topoi.pooq.com> References: <20100706055833.118D21A2080@async.async.caltech.edu> <20100706170228.GB1520@topoi.pooq.com> <20100706172305.GC1520@topoi.pooq.com> Message-ID: <4147B852-EA8F-49A7-94DF-81EFE5F76EDA@cs.purdue.edu> I was proposing a 0 value in the common case (where 0 bits are valid for the type). On 6 Jul 2010, at 13:23, hendrik at topoi.pooq.com wrote: > On Tue, Jul 06, 2010 at 01:10:34PM -0400, Tony Hosking wrote: >> Or, alternatively, we could turn it around and have a flag that turns off (for performance if desired) well-defined initialisations (much like nochecks does to turn off other runtime checks). This would be in the spirit of the language spec, which says simply that some legal value is present, and simply go one step further in making the initialised value deterministic. As far as I can tell, this changes only the behaviour of "automatic" variables (function-scope local variables) whose initial value can be any combination of bits in the variable. All other variables get deterministic initial values already. > > A flag like that that uses a consistent junk value would also be > useful, since it's less likely to be accidentally masked. Zero is far > too commonly valid for the application, and not just valid for the > language. > > -- hendrik From jay.krell at cornell.edu Tue Jul 6 21:20:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Jul 2010 19:20:04 +0000 Subject: [M3devel] yet another proposed fix.. careful insertion of one instance of CG.Force() in CastExpr.m3 In-Reply-To: <0FABE0B5-71CE-49F8-BD07-688EA9DC1C17@cs.purdue.edu> References: , <0FABE0B5-71CE-49F8-BD07-688EA9DC1C17@cs.purdue.edu> Message-ID: Right, that's what I meant by "too conservative". The change is acceptable as a start asis, right? We can soon thereafter evaluate expanding it? ? Well, the danger in being too conservative, is I'll allow "ter" optimization, and then bad code could creep in when optimizing. ? I can build the system this way and Juno, mentor minimally work. I could have sworn mentor wasn't "running" (the ? algorithms weren't showing anything in the GUI), but I deleted ~/.zeusState and rebuilt again and it seems ok now) btw, I forgot to say, the nice thing about that make_volatile change is, it'd be available to us in a pinch to inhibit optimizations if/when they cause other problems. ?- Jay ---------------------------------------- > Subject: Re: yet another proposed fix.. careful insertion of one instance of CG.Force() in CastExpr.m3 > From: hosking at cs.purdue.edu > Date: Tue, 6 Jul 2010 09:58:19 -0400 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > I wonder if we should be forcing all D_to_S? Is it really only floats that cause this problem? Why would that be the case? > > On 6 Jul 2010, at 08:28, Jay K wrote: > > > > > Ok, this is interesting. I think. Finally. > > I need to test more, but it is looking very promising. I think you'll like it (Tony). > > I still don't understand all the flow around the front end. I had to try out some guesses. > > It certainly appears that m3front/src/misc/CG.m3 is in the business of optimizations. > > This change might actually be too conservative. > > It defeats optimization in CG.m3. It limits it to D_to_S when one type is float and the other isn't. > > I guess S (struct) can't really be float. > > > > > > The assertion failure in gcc btw, was gcc_assert( something_is_float == other_is_float). > > So the conservativeness is somewhat sensible. > > Limiting it to D_to_S, though, unclear. > > > > > > The change is just inserting CG.Force(). > > > > > > OK? (Let me test a bit more -- build the entire tree.) > > > > This appears to let me leave "ter" on. > > I can try leaving other optimizations on. > > > > > > Index: exprs/CastExpr.m3 > > =================================================================== > > RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/CastExpr.m3,v > > retrieving revision 1.9 > > diff -u -r1.9 CastExpr.m3 > > --- exprs/CastExpr.m3 5 Jul 2010 11:28:32 -0000 1.9 > > +++ exprs/CastExpr.m3 6 Jul 2010 12:23:14 -0000 > > @@ -10,6 +10,7 @@ > > > > IMPORT M3Buf, CG, Expr, ExprRep, Type, Error, OpenArrayType; > > IMPORT M3, M3ID, M3RT, Target, TInt; > > +FROM Target IMPORT FloatType; > > > > TYPE > > Kind = { > > @@ -394,7 +395,7 @@ > > u := Expr.TypeOf (e); > > t := p.tipe; > > sz, t_align, u_align, z_align: INTEGER; > > - u_cg: CG.Type; > > + u_cg, t_cg: CG.Type; > > u_info, t_info: Type.Info; > > BEGIN > > u := Type.CheckInfo (u, u_info); > > @@ -403,6 +404,7 @@ > > u_align := u_info.alignment; > > z_align := MAX (t_align, u_align); > > u_cg := u_info.stk_type; > > + t_cg := t_info.stk_type; > > sz := u_info.size; > > Type.Compile (t); > > Type.Compile (u); > > @@ -416,6 +418,15 @@ > > Kind.V_to_V => > > Expr.CompileLValue (p.expr, traced); > > CG.Boost_alignment (t_align); > > +(* Inhibit some optimization that causes compilation to fail. e.g. m3core: > > +../src/float/IEEE/RealFloat.m3: In function 'RealFloat__CopySign': > > +../src/float/IEEE/RealFloat.m3:96: internal compiler error: in convert_move, at expr.c:371 > > +../src/float/IEEE/LongFloat.m3: In function 'LongFloat__CopySign': > > +../src/float/IEEE/LongFloat.m3:116: internal compiler error: in convert_move, at expr.c:371 > > +*) > > + IF p.kind = Kind.D_to_S AND FloatType[u_cg] # FloatType[t_cg] THEN > > + CG.Force (); > > + END; > > > > | Kind.D_to_A, > > Kind.S_to_A, > > > > > > > > (577) begin_procedure > > procedure LongFloat__CopySign > > LongFloat__CopySign(578) set_source_line > > source line 117 > > (579) load > > type:lreal > > type:lreal > > m3cg_load (M3_CtKayy_x): offset 0x0, convert lreal -> lreal > > (580) store > > type:lreal > > type:lreal > > store (M3_CtKayy_res) offset:0x0 src_t:lreal dst_t:lreal > > (581) set_source_line > > source line 119 > > > > > > now notice we have use of load_address and load_indirect here, where before we had no address and load (direct) > > > > > > (582) load_address > > load address (M3_CtKayy_res) offset 0x0 > > (583) load_address > > load address (M3_CtKayy_y) offset 0x0 > > (584) load_indirect > > type:word8 > > type:int64 > > load address offset:0x38 src_t:word8 dst_t:int64 > > (585) extract_mn > > type:int64 > > extract_mn offset:7 count:1 sign_extend:0 > > (586) swap > > type:addr > > type:int64 > > (587) declare_temp > > type:addr > > temp var type:addr size:0x40 alignment:0x40 > > (588) store > > type:addr > > type:addr > > store (noname) offset:0x0 src_t:addr dst_t:addr > > (589) load > > type:addr > > type:addr > > m3cg_load (noname): offset 0x0, convert addr -> addr > > (590) load_indirect > > type:word8 > > type:int64 > > load address offset:0x38 src_t:word8 dst_t:int64 > > (591) swap > > type:int64 > > type:word8 > > (592) insert_mn > > type:int64 > > insert_mn offset:7 count:1 > > (593) load > > type:addr > > type:addr > > m3cg_load (noname): offset 0x0, convert addr -> addr > > (594) swap > > type:word8 > > type:addr > > (595) store_indirect > > type:int64 > > type:word8 > > store indirect offset:0x38 src_t:int64 dst_t:word8 > > (596) set_source_line > > source line 120 > > (597) load > > type:lreal > > type:lreal > > m3cg_load (M3_CtKayy_res): offset 0x0, convert lreal -> lreal > > (598) exit_proc > > type:lreal > > (599) free_temp > > (600) end_procedure > > procedure LongFloat__CopySign > > > > > > > > - Jay > > > > > From hosking at cs.purdue.edu Tue Jul 6 21:23:47 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 6 Jul 2010 15:23:47 -0400 Subject: [M3devel] yet another proposed fix.. careful insertion of one instance of CG.Force() in CastExpr.m3 In-Reply-To: References: , <0FABE0B5-71CE-49F8-BD07-688EA9DC1C17@cs.purdue.edu> Message-ID: <2A836943-BEB7-4D5C-928B-65FD2098DF6D@cs.purdue.edu> On 6 Jul 2010, at 15:20, Jay K wrote: > Right, that's what I meant by "too conservative". I am ok with forcing in all D_to_S cases. > The change is acceptable as a start asis, right? We can soon thereafter evaluate expanding it? > Well, the danger in being too conservative, is I'll allow "ter" optimization, and then bad code could creep in when optimising. I don't think that will happen with the force, since we will make it in memory for gcc which will probably then be much happier. > I can build the system this way and Juno, mentor minimally work. I could have sworn mentor wasn't "running" (the > algorithms weren't showing anything in the GUI), but I deleted ~/.zeusState and rebuilt again and it seems ok now) OK, great. > btw, I forgot to say, the nice thing about that make_volatile change is, it'd be available to us in a pinch to inhibit > optimizations if/when they cause other problems. I am extremely leery of introducing hacks into the IR that we will later regret. The rot will set in... > > - Jay > > ---------------------------------------- >> Subject: Re: yet another proposed fix.. careful insertion of one instance of CG.Force() in CastExpr.m3 >> From: hosking at cs.purdue.edu >> Date: Tue, 6 Jul 2010 09:58:19 -0400 >> CC: m3devel at elegosoft.com >> To: jay.krell at cornell.edu >> >> I wonder if we should be forcing all D_to_S? Is it really only floats that cause this problem? Why would that be the case? >> >> On 6 Jul 2010, at 08:28, Jay K wrote: >> >>> >>> Ok, this is interesting. I think. Finally. >>> I need to test more, but it is looking very promising. I think you'll like it (Tony). >>> I still don't understand all the flow around the front end. I had to try out some guesses. >>> It certainly appears that m3front/src/misc/CG.m3 is in the business of optimizations. >>> This change might actually be too conservative. >>> It defeats optimization in CG.m3. It limits it to D_to_S when one type is float and the other isn't. >>> I guess S (struct) can't really be float. >>> >>> >>> The assertion failure in gcc btw, was gcc_assert( something_is_float == other_is_float). >>> So the conservativeness is somewhat sensible. >>> Limiting it to D_to_S, though, unclear. >>> >>> >>> The change is just inserting CG.Force(). >>> >>> >>> OK? (Let me test a bit more -- build the entire tree.) >>> >>> This appears to let me leave "ter" on. >>> I can try leaving other optimizations on. >>> >>> >>> Index: exprs/CastExpr.m3 >>> =================================================================== >>> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/CastExpr.m3,v >>> retrieving revision 1.9 >>> diff -u -r1.9 CastExpr.m3 >>> --- exprs/CastExpr.m3 5 Jul 2010 11:28:32 -0000 1.9 >>> +++ exprs/CastExpr.m3 6 Jul 2010 12:23:14 -0000 >>> @@ -10,6 +10,7 @@ >>> >>> IMPORT M3Buf, CG, Expr, ExprRep, Type, Error, OpenArrayType; >>> IMPORT M3, M3ID, M3RT, Target, TInt; >>> +FROM Target IMPORT FloatType; >>> >>> TYPE >>> Kind = { >>> @@ -394,7 +395,7 @@ >>> u := Expr.TypeOf (e); >>> t := p.tipe; >>> sz, t_align, u_align, z_align: INTEGER; >>> - u_cg: CG.Type; >>> + u_cg, t_cg: CG.Type; >>> u_info, t_info: Type.Info; >>> BEGIN >>> u := Type.CheckInfo (u, u_info); >>> @@ -403,6 +404,7 @@ >>> u_align := u_info.alignment; >>> z_align := MAX (t_align, u_align); >>> u_cg := u_info.stk_type; >>> + t_cg := t_info.stk_type; >>> sz := u_info.size; >>> Type.Compile (t); >>> Type.Compile (u); >>> @@ -416,6 +418,15 @@ >>> Kind.V_to_V => >>> Expr.CompileLValue (p.expr, traced); >>> CG.Boost_alignment (t_align); >>> +(* Inhibit some optimization that causes compilation to fail. e.g. m3core: >>> +../src/float/IEEE/RealFloat.m3: In function 'RealFloat__CopySign': >>> +../src/float/IEEE/RealFloat.m3:96: internal compiler error: in convert_move, at expr.c:371 >>> +../src/float/IEEE/LongFloat.m3: In function 'LongFloat__CopySign': >>> +../src/float/IEEE/LongFloat.m3:116: internal compiler error: in convert_move, at expr.c:371 >>> +*) >>> + IF p.kind = Kind.D_to_S AND FloatType[u_cg] # FloatType[t_cg] THEN >>> + CG.Force (); >>> + END; >>> >>> | Kind.D_to_A, >>> Kind.S_to_A, >>> >>> >>> >>> (577) begin_procedure >>> procedure LongFloat__CopySign >>> LongFloat__CopySign(578) set_source_line >>> source line 117 >>> (579) load >>> type:lreal >>> type:lreal >>> m3cg_load (M3_CtKayy_x): offset 0x0, convert lreal -> lreal >>> (580) store >>> type:lreal >>> type:lreal >>> store (M3_CtKayy_res) offset:0x0 src_t:lreal dst_t:lreal >>> (581) set_source_line >>> source line 119 >>> >>> >>> now notice we have use of load_address and load_indirect here, where before we had no address and load (direct) >>> >>> >>> (582) load_address >>> load address (M3_CtKayy_res) offset 0x0 >>> (583) load_address >>> load address (M3_CtKayy_y) offset 0x0 >>> (584) load_indirect >>> type:word8 >>> type:int64 >>> load address offset:0x38 src_t:word8 dst_t:int64 >>> (585) extract_mn >>> type:int64 >>> extract_mn offset:7 count:1 sign_extend:0 >>> (586) swap >>> type:addr >>> type:int64 >>> (587) declare_temp >>> type:addr >>> temp var type:addr size:0x40 alignment:0x40 >>> (588) store >>> type:addr >>> type:addr >>> store (noname) offset:0x0 src_t:addr dst_t:addr >>> (589) load >>> type:addr >>> type:addr >>> m3cg_load (noname): offset 0x0, convert addr -> addr >>> (590) load_indirect >>> type:word8 >>> type:int64 >>> load address offset:0x38 src_t:word8 dst_t:int64 >>> (591) swap >>> type:int64 >>> type:word8 >>> (592) insert_mn >>> type:int64 >>> insert_mn offset:7 count:1 >>> (593) load >>> type:addr >>> type:addr >>> m3cg_load (noname): offset 0x0, convert addr -> addr >>> (594) swap >>> type:word8 >>> type:addr >>> (595) store_indirect >>> type:int64 >>> type:word8 >>> store indirect offset:0x38 src_t:int64 dst_t:word8 >>> (596) set_source_line >>> source line 120 >>> (597) load >>> type:lreal >>> type:lreal >>> m3cg_load (M3_CtKayy_res): offset 0x0, convert lreal -> lreal >>> (598) exit_proc >>> type:lreal >>> (599) free_temp >>> (600) end_procedure >>> procedure LongFloat__CopySign >>> >>> >>> >>> - Jay >>> >>> >> > From jay.krell at cornell.edu Tue Jul 6 22:21:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Jul 2010 20:21:08 +0000 Subject: [M3devel] fault reports beyond 100mill lines? Message-ID: It appears that if a file has over around 100 million lines, that fault reports (nil deref, subrange out of bounds, etc.) get the wrong line number. Leave it as ("qualit of implementation"?) or fail an assertion in the compiler earlier (leaving anyone with a huge file kind of stuck (generated?) or, unlikely, expand the range? The line number is in an integer along with a 5 bit fault code. ? We could also allow much larger numbers on 64bit targets. This is just because there's a "FIXME" comment in parse.c. The code is basically right and I'm adding comments and perhaps assertions. Certainly we can assert that the fault code is in range. I think I prefer silently losing bits in the line number, or conveting it to 0 if it is out of bounds or pinning it to maxint. ? Though it'd be maxint? / 32 which is less "special" looking if someone ever saw it.. though the runtime could ? report maxint / 32 as maxint. ?- Jay From jay.krell at cornell.edu Tue Jul 6 22:35:45 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Jul 2010 20:35:45 +0000 Subject: [M3devel] fault reports beyond 100mill lines? In-Reply-To: References: Message-ID: I'm pretty settled on silently losing line numbers over 100 million. If the host and target are 64 bits it preserves far more. If someone produces such a file, and it compiles and runs, but gets a runtime error in their code on the wrong line, they can claim they found a compiler bug... ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Tue, 6 Jul 2010 20:21:08 +0000 > Subject: [M3devel] fault reports beyond 100mill lines? > > > It appears that if a file has over around 100 million lines, that fault reports (nil deref, subrange out of bounds, etc.) get the wrong line number. > Leave it as ("qualit of implementation"?) or fail an assertion in the compiler earlier (leaving anyone with a huge file kind of stuck (generated?) or, unlikely, expand the range? > The line number is in an integer along with a 5 bit fault code. > We could also allow much larger numbers on 64bit targets. > > > This is just because there's a "FIXME" comment in parse.c. > The code is basically right and I'm adding comments and perhaps assertions. > Certainly we can assert that the fault code is in range. > > > I think I prefer silently losing bits in the line number, or conveting it to 0 if it is out of bounds or pinning it to maxint. > Though it'd be maxint / 32 which is less "special" looking if someone ever saw it.. though the runtime could > report maxint / 32 as maxint. > > - Jay > > From rcolebur at SCIRES.COM Wed Jul 7 00:19:45 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Tue, 6 Jul 2010 18:19:45 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20100706055833.118D21A2080@async.async.caltech.edu> <20100706063458.DCFF41A2080@async.async.caltech.edu> <20100706165355.GA1520@topoi.pooq.com> Message-ID: I agree also. Let's not change the language here, and let's not change the compiler's behavior to no longer match the language. I don't have a problem with selectively turning on a warning level at compile time for compiler to warn me that I might be using a variable before it is initialized, but I don't want compiler choosing to initialize it for me. --Randy -----Original Message----- From: Tony Hosking [mailto:hosking at cs.purdue.edu] Sent: Tuesday, July 06, 2010 1:00 PM To: hendrik at topoi.pooq.com Cc: m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 I agree. If Modula-3 was being designed today it would impose the same ban on uninitialized use of variables that Java does. We have a language that does not impose that ban, but instead assures that every ininitialized variable holds a valid value. I much prefer to see VAR x: INTEGER as an *explicit* marker that the variable holds an indeterminate but valid value. Seeing VAR x := 0 implies to me that there is something especially significant about the initial value 0. On 6 Jul 2010, at 12:53, hendrik at topoi.pooq.com wrote: > On Tue, Jul 06, 2010 at 10:05:43AM +0000, Jay K wrote: >> >>> used it should be a giant red flag to the reader that the variable x is >>> going to be initialized with a value that the programmer doesn't know >>> at the time of declaration. What on earth do you gain from x := 0? >>> A "little correctness"? >> >> You are making the code more expensive to maintain, by making >> it harder for a human to analyze. For the benefit of microoptimization. > > Microoptimisation as a purpose? Didn't he just explain that > VAR x : INTEGER; > is intended to signal to the *reader* that the initial value is > irrelevant? The fact that a naive compiler might compile it slightly > more efficiently is a side effect, not a purpose. If he were interested > in microoptimisation, he would better feed it into a flow-analysing > compiler, which could even detect when an explicit initialization like > VAR x := 0; > is irrelevant and suppress it. > > It's not *about* optimisation. > > Indeed, they syntactic awkwardness of declaring variables with WITH > (to make sure they're initialized where they're declared) is one of > the problems of Modula 3, and one of the few places where C did it > better. Granted C, didn't do this at all initially, and took it from > Algol 68 in one of C's rounds of standardisation. > > -- hendrik From rodney_bates at lcwb.coop Wed Jul 7 00:41:55 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 06 Jul 2010 17:41:55 -0500 Subject: [M3devel] loophole/copysign In-Reply-To: <2F356C4B-5541-489B-B957-E3D295F549F5@cs.purdue.edu> References: <2F356C4B-5541-489B-B957-E3D295F549F5@cs.purdue.edu> Message-ID: <4C33B133.8020107@lcwb.coop> Tony Hosking wrote: > A designator is something that can be assigned to as well as read from. > It says nothing about it being in memory. A value cannot be assigned to. > Not necessarily. There are writable designators and readonly designators. The only things I find that can spontaneously produce a readonly designator are a READONLY formal and a FOR local. Several things produce writable designators, Lots of things propagate designator-ness around, and sometimes writability too. E.g., subscripting an array propagates each of these properties independently from the array to the selected element. ADR, BITSIZE, BYTESIZE, and ADRSIZE can be applied to a readonly designator (but not to a non-designator). Assignment, passing to a VAR formal, and DISPOSE require a writable designator. Although it is really an implementation- level distinction, these pretty well imply that a designator will have to be in memory. Not necessarily the converse, as, for example, a compiler could very well store the result of A+B in memory, but the language still forbids applying ADR to it, etc., leaving the compiler a choice. > On 5 Jul 2010, at 06:42, Jay K wrote: > >> Tony, et. al.. in m3front/src/exprs/CastExpr.m3..what's the difference between a "designator" and a "value"? > From hendrik at topoi.pooq.com Wed Jul 7 01:01:16 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 6 Jul 2010 19:01:16 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <4147B852-EA8F-49A7-94DF-81EFE5F76EDA@cs.purdue.edu> References: <20100706055833.118D21A2080@async.async.caltech.edu> <20100706170228.GB1520@topoi.pooq.com> <20100706172305.GC1520@topoi.pooq.com> <4147B852-EA8F-49A7-94DF-81EFE5F76EDA@cs.purdue.edu> Message-ID: <20100706230115.GA3124@topoi.pooq.com> On Tue, Jul 06, 2010 at 03:18:26PM -0400, Tony Hosking wrote: > I was proposing a 0 value in the common case (where 0 bits are valid for the type). Yes, I understood that. I'm pointing out that a nonzero value (also where valid) is likely to find more errors than a zero value, and that a consistent nonzero value will make it easier to actually find the errors, instead of just detect them. And it's less likely to lead to programs that run successfully only when you specify the option. -- hendrik From ttmrichter at gmail.com Wed Jul 7 05:56:43 2010 From: ttmrichter at gmail.com (Michael Richter) Date: Wed, 7 Jul 2010 11:56:43 +0800 Subject: [M3devel] fault reports beyond 100mill lines? In-Reply-To: References: Message-ID: Why the magic number of 100,000,000? Why not 4 billion, say? On 7 July 2010 04:35, Jay K wrote: > > I'm pretty settled on silently losing line numbers over 100 million. > If the host and target are 64 bits it preserves far more. > If someone produces such a file, and it compiles and runs, but gets a > runtime error in their code on the wrong line, they can claim they found a > compiler bug... > > - Jay > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Date: Tue, 6 Jul 2010 20:21:08 +0000 > > Subject: [M3devel] fault reports beyond 100mill lines? > > > > > > It appears that if a file has over around 100 million lines, that fault > reports (nil deref, subrange out of bounds, etc.) get the wrong line number. > > Leave it as ("qualit of implementation"?) or fail an assertion in the > compiler earlier (leaving anyone with a huge file kind of stuck (generated?) > or, unlikely, expand the range? > > The line number is in an integer along with a 5 bit fault code. > > We could also allow much larger numbers on 64bit targets. > > > > > > This is just because there's a "FIXME" comment in parse.c. > > The code is basically right and I'm adding comments and perhaps > assertions. > > Certainly we can assert that the fault code is in range. > > > > > > I think I prefer silently losing bits in the line number, or conveting it > to 0 if it is out of bounds or pinning it to maxint. > > Though it'd be maxint / 32 which is less "special" looking if someone > ever saw it.. though the runtime could > > report maxint / 32 as maxint. > > > > - Jay > > > > > > -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Jul 7 06:03:42 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 7 Jul 2010 04:03:42 +0000 Subject: [M3devel] fault reports beyond 100mill lines? In-Reply-To: References: , , Message-ID: See below: >> The line number is in an integer along with a 5 bit fault code. Maybe that isn't clear -- they are in the same integer, 32bits or 64bits. 4 billion / 32 is roughly 100 million. - Jay Date: Wed, 7 Jul 2010 11:56:43 +0800 From: ttmrichter at gmail.com To: m3devel at elegosoft.com Subject: Re: [M3devel] fault reports beyond 100mill lines? Why the magic number of 100,000,000? Why not 4 billion, say? On 7 July 2010 04:35, Jay K wrote: I'm pretty settled on silently losing line numbers over 100 million. If the host and target are 64 bits it preserves far more. If someone produces such a file, and it compiles and runs, but gets a runtime error in their code on the wrong line, they can claim they found a compiler bug... - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Tue, 6 Jul 2010 20:21:08 +0000 > Subject: [M3devel] fault reports beyond 100mill lines? > > > It appears that if a file has over around 100 million lines, that fault reports (nil deref, subrange out of bounds, etc.) get the wrong line number. > Leave it as ("qualit of implementation"?) or fail an assertion in the compiler earlier (leaving anyone with a huge file kind of stuck (generated?) or, unlikely, expand the range? > The line number is in an integer along with a 5 bit fault code. > We could also allow much larger numbers on 64bit targets. > > > This is just because there's a "FIXME" comment in parse.c. > The code is basically right and I'm adding comments and perhaps assertions. > Certainly we can assert that the fault code is in range. > > > I think I prefer silently losing bits in the line number, or conveting it to 0 if it is out of bounds or pinning it to maxint. > Though it'd be maxint / 32 which is less "special" looking if someone ever saw it.. though the runtime could > report maxint / 32 as maxint. > > - Jay > > -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Wed Jul 7 06:30:06 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 7 Jul 2010 04:30:06 +0000 (GMT) Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: Message-ID: <4898.91283.qm@web23608.mail.ird.yahoo.com> Hi all: I could be wrong but if the mapped structures of original CM3 v4.1 were to detect compile time errors and runtime errors those ones no checked in M3 would be like to be checked at the CM3 JVM runtime (which abide CM3 itself at the time) then as the runtime JVM micro-ops were even possibly checked at java process runtime and possibly scanned at the lowest Modula-3 execution trace lower levels, we can I guess map those of the M3CG (even if are at the lowest level they did something like to match some structures at least they did that level of matching of two semantic structures and work as one like the CISC stack based JVM machine and the "RISC" stack class machine of M3CG) at the compile time back traces and so on interpretation (it would be not just not a M3CG VM like JVM but to get type info of the system and detect the probably undetectable otherwise Modula-3 runtime overflows i.e map some undetectable otherwise expressions meant to be not overflowed actually overflowed in the runtime). I guess in that way we can reserve more energies for both tasks compiler enhancement and m3cg tracing tree debugger ability if thats what you are looking for. In other short words I am proposing instead of the idea of initialize everything either manually or semi automatically get into the idea of a proper type system for M3CG and get rid of this kind of errors people are seeing meaningful if someone tells what else. I have a history of Modula-3, Java and JVM friendly leaving but to get into this properly I guess I would need more than energies I would like to get to check specially the implementation of the JVM lower level of CM3 and even better than that state or propose a type system for M3CG assembly language if we can call like that so no matters what we can have a better and systematic and reasonable (as JVM does) way of checking the M3CG code checking and generation if at all changes. Let me have a chance of asking of this more, probably first I need to check this paper wrote in DEC SRC about 1998 to see if the type system is pretty straight forward http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-158.pdf Thanks in advance --- El mar, 6/7/10, Tony Hosking escribi?: > De: Tony Hosking > Asunto: Re: [M3devel] [M3commit] CVS Update: cm3 > Para: hendrik at topoi.pooq.com > CC: m3devel at elegosoft.com > Fecha: martes, 6 de julio, 2010 12:00 > I agree. > > If Modula-3 was being designed today it would impose the > same ban on uninitialized use of variables that Java does. > We have a language that does not impose that ban, but > instead assures that every ininitialized variable holds a > valid value. > I much prefer to see > > VAR x: INTEGER > > as an *explicit* marker that the variable holds an > indeterminate but valid value. > > Seeing > > VAR x := 0 > > implies to me that there is something especially > significant about the initial value 0. > > > On 6 Jul 2010, at 12:53, hendrik at topoi.pooq.com > wrote: > > > On Tue, Jul 06, 2010 at 10:05:43AM +0000, Jay K > wrote: > >> > >>> used it should be a giant red flag to the > reader that the variable x is > >>> going to be initialized with a value that the > programmer doesn't know > >>> at the time of declaration. What on earth do > you gain from x := 0? > >>> A "little correctness"? > >> > >> You are making the code more expensive to > maintain, by making > >> it harder for a human to analyze. For the benefit > of microoptimization. > > > > Microoptimisation as a purpose? Didn't he just > explain that > > VAR x : INTEGER; > > is intended to signal to the *reader* that the initial > value is > > irrelevant? The fact that a naive compiler might > compile it slightly > > more efficiently is a side effect, not a > purpose. If he were interested > > in microoptimisation, he would better feed it into a > flow-analysing > > compiler, which could even detect when an explicit > initialization like > > VAR x := 0; > > is irrelevant and suppress it. > > > > It's not *about* optimisation. > > > > Indeed, they syntactic awkwardness of declaring > variables with WITH > > (to make sure they're initialized where they're > declared) is one of > > the problems of Modula 3, and one of the few places > where C did it > > better. Granted C, didn't do this at all > initially, and took it from > > Algol 68 in one of C's rounds of standardisation. > > > > -- hendrik > > From mika at async.async.caltech.edu Wed Jul 7 09:37:53 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Wed, 07 Jul 2010 00:37:53 -0700 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20100706063547.81FC21A2080@async.async.caltech.edu> Message-ID: <20100707073753.8A8F21A207C@async.async.caltech.edu> Jay K writes: > ... >> >When you write VAR a:INTEGER=3D3B >> >you make the human proofreading your code have to work much harder >> >to do the data/control flow analysis to make sure you didn't >> >use the uninitialized value. >> >> And yes=2C that's precisely the point! > > >You are just adding to the maintenance cost of the code. >If something makes it much more difficult to analyze by a human=2C and does= >n't >provide much benefit=2C don't do it. > Sorry to keep beating a dead horse but I meant precisely the opposite. If you ever see code that I have written that says: VAR x : INTEGER; BEGIN ... END that means *precisely* that there is no initial value of x for which the code is more correct than for any other initial value. I couldn't care less (99.9% of the time) about the insignficant time the compiler spends initializing the variable. It's all about readability. If it says VAR x := 0; BEGIN ... END it's really rather a mystery what that 0 means until the human has analyzed the code and realizes that on every path, x is written before it is read! And hey if you introduce a bug in the program where you forget to initialize x as you thought, the naive reader will assume the code is correct, because you did initialize it to zero (how clever, that zero value must be very special!) If you leave out the extra initialization, the bug will be fairly obvious even to someone who doesn't know exactly what the program is doing. I think you are just trading a set of moderately easy to analyze bugs for a set of very difficult bugs if you insist on initializing every variable including those without good initial values. Mika From jay.krell at cornell.edu Wed Jul 7 23:01:33 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 7 Jul 2010 21:01:33 +0000 Subject: [M3devel] try/finally and ter optimization? Message-ID: This is an example that crashes the backend if ter is enabled. TryFinStmt has three modes: Compile1, Compile2, Compile3. ?- stack walker ?- two other modes depending on the form of the function (I didn't read closely). ? One of them calls setjmp, one does not. ? In this case, no call to setjmp. ? Needs further investigation. ?Even if I put code in the finally block, same thing. ?TryStmt.m3 only has two modes, stack walker and not. ?So I think the problem is somewhere in TryFinStmt -- it doesn't generate a call to setjmp (Marker.CaptureState) (* Compiling this program has crashed some backends. ?* (gcc backend with -O3, no volatile, 'ter') ?* This is reduced from libm3/Formatter.m3 ?* The point therefore is merely to compile it without crashing. ?*) MODULE Main; ? VAR NoAlignOp: CARDINAL; PROCEDURE PeekOp(<*NOWARN*> i: CARDINAL): CARDINAL = ? BEGIN RETURN NoAlignOp; END PeekOp; VAR pos1: CARDINAL := 0; <*NOWARN*> PROCEDURE PrintAlign(VAR pos: CARDINAL) = ? VAR op, endRun: CARDINAL := 0; ? BEGIN ??? TRY ????? LOOP ??????? op := PeekOp(pos); ??????? LOOP ????????? IF op = NoAlignOp THEN ??????????? IF endRun = pos THEN ????????????? INC(endRun); ??????????? END; ??????????? EXIT; ????????? END; ????????? op := PeekOp(pos1); ??????? END; ????? END; ??? FINALLY ??? END; ? END PrintAlign; BEGIN END Main. From jay.krell at cornell.edu Thu Jul 8 12:22:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 8 Jul 2010 10:22:32 +0000 Subject: [M3devel] try/finally and ter optimization? In-Reply-To: References: Message-ID: To be clear, in several emails and commit comments, I mixed up "pre" and "ter". ?"ter" allowed now. ?"pre" is the problem. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: try/finally and ter optimization? > Date: Wed, 7 Jul 2010 21:01:33 +0000 > > > This is an example that crashes the backend if ter is enabled. > TryFinStmt has three modes: Compile1, Compile2, Compile3. > - stack walker > - two other modes depending on the form of the function (I didn't read closely). > One of them calls setjmp, one does not. > In this case, no call to setjmp. > Needs further investigation. > Even if I put code in the finally block, same thing. > TryStmt.m3 only has two modes, stack walker and not. > So I think the problem is somewhere in TryFinStmt -- it doesn't generate a call to setjmp (Marker.CaptureState) > > > > (* Compiling this program has crashed some backends. > * (gcc backend with -O3, no volatile, 'ter') > * This is reduced from libm3/Formatter.m3 > * The point therefore is merely to compile it without crashing. > *) > > MODULE Main; > > VAR NoAlignOp: CARDINAL; > > PROCEDURE PeekOp(<*NOWARN*> i: CARDINAL): CARDINAL = > BEGIN RETURN NoAlignOp; END PeekOp; > > VAR pos1: CARDINAL := 0; > > <*NOWARN*> PROCEDURE PrintAlign(VAR pos: CARDINAL) = > VAR op, endRun: CARDINAL := 0; > BEGIN > TRY > LOOP > op := PeekOp(pos); > LOOP > IF op = NoAlignOp THEN > IF endRun = pos THEN > INC(endRun); > END; > EXIT; > END; > op := PeekOp(pos1); > END; > END; > FINALLY > END; > END PrintAlign; > > BEGIN > END Main. > > From rcolebur at SCIRES.COM Thu Jul 8 18:42:58 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Thu, 8 Jul 2010 12:42:58 -0400 Subject: [M3devel] head branch can't compile on Windows Message-ID: I am no longer able to build the head branch on Windows. --Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 9 10:20:37 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 9 Jul 2010 08:20:37 +0000 Subject: [M3devel] head branch can't compile on Windows In-Reply-To: References: Message-ID: Randy is this what you see: "..\src\runtime\common\RTHeapStats.m3", line 203: unknown qualification '.' (And) "..\src\runtime\common\RTHeapStats.m3", line 207: unknown qualification '.' (T) "..\src\runtime\common\RTHeapStats.m3", line 208: unknown qualification '.' (T) "..\src\runtime\common\RTHeapStats.m3", line 209: unknown qualification '.' (LeftShift) "..\src\runtime\common\RTHeapStats.m3", line 210: unknown qualification '.' (And) "..\src\runtime\common\RTHeapStats.m3", line 212: unknown qualification '.' (Or) Yes, something is very wrong. - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com Date: Thu, 8 Jul 2010 12:42:58 -0400 Subject: [M3devel] head branch can't compile on Windows I am no longer able to build the head branch on Windows. --Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 9 14:01:16 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 9 Jul 2010 12:01:16 +0000 Subject: [M3devel] head branch can't compile on Windows In-Reply-To: References: , Message-ID: Randy, please try again, with the change to m3front/misc/Scanner.m3 (ie: version 1.13 or 1.11, not version 1.12). Tony, this was yours. Thanks, - Jay From: jay.krell at cornell.edu To: rcolebur at scires.com; m3devel at elegosoft.com Subject: RE: [M3devel] head branch can't compile on Windows Date: Fri, 9 Jul 2010 08:20:37 +0000 Randy is this what you see: "..\src\runtime\common\RTHeapStats.m3", line 203: unknown qualification '.' (And) "..\src\runtime\common\RTHeapStats.m3", line 207: unknown qualification '.' (T) "..\src\runtime\common\RTHeapStats.m3", line 208: unknown qualification '.' (T) "..\src\runtime\common\RTHeapStats.m3", line 209: unknown qualification '.' (LeftShift) "..\src\runtime\common\RTHeapStats.m3", line 210: unknown qualification '.' (And) "..\src\runtime\common\RTHeapStats.m3", line 212: unknown qualification '.' (Or) Yes, something is very wrong. - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com Date: Thu, 8 Jul 2010 12:42:58 -0400 Subject: [M3devel] head branch can't compile on Windows I am no longer able to build the head branch on Windows. --Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jul 11 13:46:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 11 Jul 2010 11:46:43 +0000 Subject: [M3devel] barrier labels? Message-ID: Tony, six years ago you introduce what is now: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c.diff?r1=1.5;r2=1.6 static void m3cg_set_label (void) { ... ? if (barrier) ??? { ... ????? { ??????? rtx list = DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels; ??????? DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels ????????? = gen_rtx_EXPR_LIST (VOIDmode, r, list); ????? } ... I'm not sure what to do here for gcc 4.5. ? The data has moved around and isn't available this early. I suppose we could hang some information on and ??? deal with it later in compilation. DECL_NONLOCAL(l) = true; seems promising, but it caused very bad code to be produced (incorrect, not inefficient). I didn't look into why. The bad code was changing the stack pointer where it should leave it alone. gcc-4.5 is working for me now (cm3 built with it can built itself), at least with -O1, AMD64_DARWIN. And Juno/mentor/tetris work without optimization, I'll test optimized later. Next I'll test -O2, -O3, m3-sys/m3tests. Do we have good exception handling tests? I know that cm3 uses exceptions, like, looking for cm3.cfg. I'll poke around more.. ?- Jay From hosking at cs.purdue.edu Sun Jul 11 22:25:41 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 11 Jul 2010 16:25:41 -0400 Subject: [M3devel] barrier labels? In-Reply-To: References: Message-ID: I extracted that usage from what C++ was doing for exception labels. The point is to make sure that flow analysis knows that the exception handler label targets are important "non-local" label targets. I do remember that DECL_NONLOCAL was *not* the right thing to do (that is used for proper non-local outer-scope goto targets for nested functions) and I remember the SP hacks being used with that (they need to recover from targeting from an inner-scope function and clean up the stack accordingly). I suggest poking around in what the C++ exception handling now does with table-driven exception targets. On 11 Jul 2010, at 07:46, Jay K wrote: > > Tony, six years ago you introduce what is now: > > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c.diff?r1=1.5;r2=1.6 > > > static void > m3cg_set_label (void) > { > ... > if (barrier) > { > ... > { > rtx list = DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels; > DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels > = gen_rtx_EXPR_LIST (VOIDmode, r, list); > } > ... > > > I'm not sure what to do here for gcc 4.5. > The data has moved around and isn't available this early. I suppose we could hang some information on and > deal with it later in compilation. > > > DECL_NONLOCAL(l) = true; seems promising, but it caused very bad code to be produced (incorrect, not inefficient). > I didn't look into why. The bad code was changing the stack pointer where it should leave it alone. > > > gcc-4.5 is working for me now (cm3 built with it can built itself), at least with -O1, AMD64_DARWIN. > And Juno/mentor/tetris work without optimization, I'll test optimized later. > Next I'll test -O2, -O3, m3-sys/m3tests. > > > Do we have good exception handling tests? > I know that cm3 uses exceptions, like, looking for cm3.cfg. > > > I'll poke around more.. > > > - Jay > From jay.krell at cornell.edu Mon Jul 12 01:41:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 11 Jul 2010 23:41:20 +0000 Subject: [M3devel] barrier labels? In-Reply-To: References: , Message-ID: Tony, thanks for the pointer..though I haven't been able to find it yet. I also looked for related code in 3.3 and 3.4, as I think 3.3 was current at the time. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Sun, 11 Jul 2010 16:25:41 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] barrier labels? > > I extracted that usage from what C++ was doing for exception labels. The point is to make sure that flow analysis knows that the exception handler label targets are important "non-local" label targets. I do remember that DECL_NONLOCAL was *not* the right thing to do (that is used for proper non-local outer-scope goto targets for nested functions) and I remember the SP hacks being used with that (they need to recover from targeting from an inner-scope function and clean up the stack accordingly). I suggest poking around in what the C++ exception handling now does with table-driven exception targets. > > On 11 Jul 2010, at 07:46, Jay K wrote: > > > > > Tony, six years ago you introduce what is now: > > > > > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c.diff?r1=1.5;r2=1.6 > > > > > > static void > > m3cg_set_label (void) > > { > > ... > > if (barrier) > > { > > ... > > { > > rtx list = DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels; > > DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels > > = gen_rtx_EXPR_LIST (VOIDmode, r, list); > > } > > ... > > > > > > I'm not sure what to do here for gcc 4.5. > > The data has moved around and isn't available this early. I suppose we could hang some information on and > > deal with it later in compilation. > > > > > > DECL_NONLOCAL(l) = true; seems promising, but it caused very bad code to be produced (incorrect, not inefficient). > > I didn't look into why. The bad code was changing the stack pointer where it should leave it alone. > > > > > > gcc-4.5 is working for me now (cm3 built with it can built itself), at least with -O1, AMD64_DARWIN. > > And Juno/mentor/tetris work without optimization, I'll test optimized later. > > Next I'll test -O2, -O3, m3-sys/m3tests. > > > > > > Do we have good exception handling tests? > > I know that cm3 uses exceptions, like, looking for cm3.cfg. > > > > > > I'll poke around more.. > > > > > > - Jay > > > From jay.krell at cornell.edu Mon Jul 12 01:51:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 11 Jul 2010 23:51:43 +0000 Subject: [M3devel] gcc 4.5 Message-ID: I'm inclined to make gcc 4.5 the default backend very soon. AMD64_DARWIN, I386_LINUX, SOLgnu are looking ok. ? I could also test PPC, like PPC_LINUX. SOLgnu leaves everything volatile (same as 4.3) so maybe isn't much validation. I doubt there is much value in testing other operating systems, mainly just other processors. ?? Though there is sometimes, e.g. I think I386_DARWIN uses sse for floating point and other I386 systems don't. ?? I should also test SPARC_LINUX to get sparc w/o volatile. There are many other targets. OpenBSD, NetBSD, FreeBSD, OSF/1, I386/AMD64_SOLARIS, ARMEL_LINUX, Cygwin, MinGW, etc. Others can test them? There is some downside, in particular I disable more optimization at -O3 than with gcc 4.3. One of the additional optimizations perhaps doesn't exist in 4.3 though. The label/barrier thing still isn't resolved. I haven't run through m3-sys/m3tests. But that the system can build itself is a good sign, though sometimes I overvalue it. And I tested some gui apps at least unoptimized. The "man vs. boy" test works. The 4.3 backend will remain available via cm3 -DGCC43 in the m3cc directory. ? You have to be careful about cm3cfg.common probing around and finding the intended one, ? such as by deleting all others. ?- Jay From hosking at cs.purdue.edu Mon Jul 12 02:52:25 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 11 Jul 2010 20:52:25 -0400 Subject: [M3devel] barrier labels? In-Reply-To: References: , Message-ID: <08509C7F-5EC5-4679-8094-6985A70CC7C6@cs.purdue.edu> No, that code came from 4.x... On 11 Jul 2010, at 19:41, Jay K wrote: > > Tony, thanks for the pointer..though I haven't been able to find it yet. > I also looked for related code in 3.3 and 3.4, as I think 3.3 was current at the time. > > - Jay > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Sun, 11 Jul 2010 16:25:41 -0400 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] barrier labels? >> >> I extracted that usage from what C++ was doing for exception labels. The point is to make sure that flow analysis knows that the exception handler label targets are important "non-local" label targets. I do remember that DECL_NONLOCAL was *not* the right thing to do (that is used for proper non-local outer-scope goto targets for nested functions) and I remember the SP hacks being used with that (they need to recover from targeting from an inner-scope function and clean up the stack accordingly). I suggest poking around in what the C++ exception handling now does with table-driven exception targets. >> >> On 11 Jul 2010, at 07:46, Jay K wrote: >> >>> >>> Tony, six years ago you introduce what is now: >>> >>> >>> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c.diff?r1=1.5;r2=1.6 >>> >>> >>> static void >>> m3cg_set_label (void) >>> { >>> ... >>> if (barrier) >>> { >>> ... >>> { >>> rtx list = DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels; >>> DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels >>> = gen_rtx_EXPR_LIST (VOIDmode, r, list); >>> } >>> ... >>> >>> >>> I'm not sure what to do here for gcc 4.5. >>> The data has moved around and isn't available this early. I suppose we could hang some information on and >>> deal with it later in compilation. >>> >>> >>> DECL_NONLOCAL(l) = true; seems promising, but it caused very bad code to be produced (incorrect, not inefficient). >>> I didn't look into why. The bad code was changing the stack pointer where it should leave it alone. >>> >>> >>> gcc-4.5 is working for me now (cm3 built with it can built itself), at least with -O1, AMD64_DARWIN. >>> And Juno/mentor/tetris work without optimization, I'll test optimized later. >>> Next I'll test -O2, -O3, m3-sys/m3tests. >>> >>> >>> Do we have good exception handling tests? >>> I know that cm3 uses exceptions, like, looking for cm3.cfg. >>> >>> >>> I'll poke around more.. >>> >>> >>> - Jay >>> >> > From jay.krell at cornell.edu Mon Jul 12 03:58:52 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 12 Jul 2010 01:58:52 +0000 Subject: [M3devel] import from same .so or not Message-ID: It seems to me, an important bit of information is not provided to the backend. The backend is told "import" or "export". But this is about "modules", .m3 files to .m3 files. It isn't about .so files to .so files, or .dlls to .dlls. It's really tristate, not boolean: ? private to just this source file? ? private to this source file and those it statically links to ? public for all Granted, you might statically link "everything". There isn't enforcement of the middle state, and symbols still need to be as unique as the third state. But it is definitely useful. In particular we don't use DECL_VISIBILITY (p) = VISIBILITY_HIDDEN enough. ? For a long time we never used it. e.g. in the release branch. Agreed? Anyone volunteer to fix? Or mind if I try? ?- Jay From jay.krell at cornell.edu Mon Jul 12 05:03:58 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 12 Jul 2010 03:03:58 +0000 Subject: [M3devel] barrier labels? In-Reply-To: <08509C7F-5EC5-4679-8094-6985A70CC7C6@cs.purdue.edu> References: , , , , <08509C7F-5EC5-4679-8094-6985A70CC7C6@cs.purdue.edu> Message-ID: I still don't see it, in the C++ frontend. There is: void expand_label (tree label) { ... ? if (DECL_NONLOCAL (label)) ??? { ... ???? nonlocal_goto_handler_labels ??? = gen_rtx_EXPR_LIST (VOIDmode, label_r, ??? ??? ??? ???? nonlocal_goto_handler_labels); ??? } but I don't think this works until later. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Sun, 11 Jul 2010 20:52:25 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] barrier labels? > > No, that code came from 4.x... > > > > > On 11 Jul 2010, at 19:41, Jay K wrote: > > > > > Tony, thanks for the pointer..though I haven't been able to find it yet. > > I also looked for related code in 3.3 and 3.4, as I think 3.3 was current at the time. > > > > - Jay > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Sun, 11 Jul 2010 16:25:41 -0400 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] barrier labels? > >> > >> I extracted that usage from what C++ was doing for exception labels. The point is to make sure that flow analysis knows that the exception handler label targets are important "non-local" label targets. I do remember that DECL_NONLOCAL was *not* the right thing to do (that is used for proper non-local outer-scope goto targets for nested functions) and I remember the SP hacks being used with that (they need to recover from targeting from an inner-scope function and clean up the stack accordingly). I suggest poking around in what the C++ exception handling now does with table-driven exception targets. > >> > >> On 11 Jul 2010, at 07:46, Jay K wrote: > >> > >>> > >>> Tony, six years ago you introduce what is now: > >>> > >>> > >>> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c.diff?r1=1.5;r2=1.6 > >>> > >>> > >>> static void > >>> m3cg_set_label (void) > >>> { > >>> ... > >>> if (barrier) > >>> { > >>> ... > >>> { > >>> rtx list = DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels; > >>> DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels > >>> = gen_rtx_EXPR_LIST (VOIDmode, r, list); > >>> } > >>> ... > >>> > >>> > >>> I'm not sure what to do here for gcc 4.5. > >>> The data has moved around and isn't available this early. I suppose we could hang some information on and > >>> deal with it later in compilation. > >>> > >>> > >>> DECL_NONLOCAL(l) = true; seems promising, but it caused very bad code to be produced (incorrect, not inefficient). > >>> I didn't look into why. The bad code was changing the stack pointer where it should leave it alone. > >>> > >>> > >>> gcc-4.5 is working for me now (cm3 built with it can built itself), at least with -O1, AMD64_DARWIN. > >>> And Juno/mentor/tetris work without optimization, I'll test optimized later. > >>> Next I'll test -O2, -O3, m3-sys/m3tests. > >>> > >>> > >>> Do we have good exception handling tests? > >>> I know that cm3 uses exceptions, like, looking for cm3.cfg. > >>> > >>> > >>> I'll poke around more.. > >>> > >>> > >>> - Jay > >>> > >> > > > From hosking at cs.purdue.edu Mon Jul 12 15:28:43 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jul 2010 09:28:43 -0400 Subject: [M3devel] import from same .so or not In-Reply-To: References: Message-ID: It seems to me this would require massive reworking of the build infrastructure! On 11 Jul 2010, at 21:58, Jay K wrote: > > It seems to me, an important bit of information is not provided to the backend. > > The backend is told "import" or "export". > But this is about "modules", .m3 files to .m3 files. > > It isn't about .so files to .so files, or .dlls to .dlls. > > It's really tristate, not boolean: > private to just this source file > private to this source file and those it statically links to > public for all > > Granted, you might statically link "everything". > There isn't enforcement of the middle state, and symbols still need to be as unique as the third state. > But it is definitely useful. > > In particular we don't use DECL_VISIBILITY (p) = VISIBILITY_HIDDEN enough. > For a long time we never used it. e.g. in the release branch. > > Agreed? > Anyone volunteer to fix? > Or mind if I try? > > > - Jay > > From hosking at cs.purdue.edu Mon Jul 12 15:43:01 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jul 2010 09:43:01 -0400 Subject: [M3devel] barrier labels? In-Reply-To: References: , , , , <08509C7F-5EC5-4679-8094-6985A70CC7C6@cs.purdue.edu> Message-ID: Perhaps we just need FORCED_LABEL for these: /* In a LABEL_DECL, nonzero means this label had its address taken and therefore can never be deleted and is a jump target for computed gotos. */ On 11 Jul 2010, at 23:03, Jay K wrote: > > I still don't see it, in the C++ frontend. > > There is: > > void > expand_label (tree label) > { > ... > if (DECL_NONLOCAL (label)) > { > ... nonlocal_goto_handler_labels > = gen_rtx_EXPR_LIST (VOIDmode, label_r, > nonlocal_goto_handler_labels); > } > > but I don't think this works until later. > > - Jay > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Sun, 11 Jul 2010 20:52:25 -0400 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] barrier labels? >> >> No, that code came from 4.x... >> >> >> >> >> On 11 Jul 2010, at 19:41, Jay K wrote: >> >>> >>> Tony, thanks for the pointer..though I haven't been able to find it yet. >>> I also looked for related code in 3.3 and 3.4, as I think 3.3 was current at the time. >>> >>> - Jay >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> Date: Sun, 11 Jul 2010 16:25:41 -0400 >>>> To: jay.krell at cornell.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] barrier labels? >>>> >>>> I extracted that usage from what C++ was doing for exception labels. The point is to make sure that flow analysis knows that the exception handler label targets are important "non-local" label targets. I do remember that DECL_NONLOCAL was *not* the right thing to do (that is used for proper non-local outer-scope goto targets for nested functions) and I remember the SP hacks being used with that (they need to recover from targeting from an inner-scope function and clean up the stack accordingly). I suggest poking around in what the C++ exception handling now does with table-driven exception targets. >>>> >>>> On 11 Jul 2010, at 07:46, Jay K wrote: >>>> >>>>> >>>>> Tony, six years ago you introduce what is now: >>>>> >>>>> >>>>> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c.diff?r1=1.5;r2=1.6 >>>>> >>>>> >>>>> static void >>>>> m3cg_set_label (void) >>>>> { >>>>> ... >>>>> if (barrier) >>>>> { >>>>> ... >>>>> { >>>>> rtx list = DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels; >>>>> DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels >>>>> = gen_rtx_EXPR_LIST (VOIDmode, r, list); >>>>> } >>>>> ... >>>>> >>>>> >>>>> I'm not sure what to do here for gcc 4.5. >>>>> The data has moved around and isn't available this early. I suppose we could hang some information on and >>>>> deal with it later in compilation. >>>>> >>>>> >>>>> DECL_NONLOCAL(l) = true; seems promising, but it caused very bad code to be produced (incorrect, not inefficient). >>>>> I didn't look into why. The bad code was changing the stack pointer where it should leave it alone. >>>>> >>>>> >>>>> gcc-4.5 is working for me now (cm3 built with it can built itself), at least with -O1, AMD64_DARWIN. >>>>> And Juno/mentor/tetris work without optimization, I'll test optimized later. >>>>> Next I'll test -O2, -O3, m3-sys/m3tests. >>>>> >>>>> >>>>> Do we have good exception handling tests? >>>>> I know that cm3 uses exceptions, like, looking for cm3.cfg. >>>>> >>>>> >>>>> I'll poke around more.. >>>>> >>>>> >>>>> - Jay >>>>> >>>> >>> >> > From jay.krell at cornell.edu Tue Jul 13 01:53:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 12 Jul 2010 23:53:57 +0000 Subject: [M3devel] import from same .so or not In-Reply-To: References: , Message-ID: I don't know. I hope not. The information is there: lowercase interface vs. uppercase Interface, lowercase module vs. uppercase Module, derived_interface(hidden or private). I haven't looked at where all it is sent around. - Jay > Subject: Re: [M3devel] import from same .so or not > From: hosking at cs.purdue.edu > Date: Mon, 12 Jul 2010 09:28:43 -0400 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > It seems to me this would require massive reworking of the build infrastructure! > > On 11 Jul 2010, at 21:58, Jay K wrote: > > > > > It seems to me, an important bit of information is not provided to the backend. > > > > The backend is told "import" or "export". > > But this is about "modules", .m3 files to .m3 files. > > > > It isn't about .so files to .so files, or .dlls to .dlls. > > > > It's really tristate, not boolean: > > private to just this source file > > private to this source file and those it statically links to > > public for all > > > > Granted, you might statically link "everything". > > There isn't enforcement of the middle state, and symbols still need to be as unique as the third state. > > But it is definitely useful. > > > > In particular we don't use DECL_VISIBILITY (p) = VISIBILITY_HIDDEN enough. > > For a long time we never used it. e.g. in the release branch. > > > > Agreed? > > Anyone volunteer to fix? > > Or mind if I try? > > > > > > - Jay > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Jul 13 02:14:39 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jul 2010 20:14:39 -0400 Subject: [M3devel] import from same .so or not In-Reply-To: References: , Message-ID: <9241B253-8004-4DDD-B1EF-A7D02A3FEAFD@cs.purdue.edu> There question is where and how to communicate it back to gcc. Does it mean putting all the module units on the same command line for compilation by a single instance of cm3cg? Or do you communicate it some other way? On 12 Jul 2010, at 19:53, Jay K wrote: > I don't know. I hope not. The information is there: lowercase interface vs. uppercase Interface, lowercase module vs. uppercase Module, derived_interface(hidden or private). > I haven't looked at where all it is sent around. > > - Jay > > > > Subject: Re: [M3devel] import from same .so or not > > From: hosking at cs.purdue.edu > > Date: Mon, 12 Jul 2010 09:28:43 -0400 > > CC: m3devel at elegosoft.com > > To: jay.krell at cornell.edu > > > > It seems to me this would require massive reworking of the build infrastructure! > > > > On 11 Jul 2010, at 21:58, Jay K wrote: > > > > > > > > It seems to me, an important bit of information is not provided to the backend. > > > > > > The backend is told "import" or "export". > > > But this is about "modules", .m3 files to .m3 files. > > > > > > It isn't about .so files to .so files, or .dlls to .dlls. > > > > > > It's really tristate, not boolean: > > > private to just this source file > > > private to this source file and those it statically links to > > > public for all > > > > > > Granted, you might statically link "everything". > > > There isn't enforcement of the middle state, and symbols still need to be as unique as the third state. > > > But it is definitely useful. > > > > > > In particular we don't use DECL_VISIBILITY (p) = VISIBILITY_HIDDEN enough. > > > For a long time we never used it. e.g. in the release branch. > > > > > > Agreed? > > > Anyone volunteer to fix? > > > Or mind if I try? > > > > > > > > > - Jay > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 13 02:50:47 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 13 Jul 2010 00:50:47 +0000 Subject: [M3devel] import from same .so or not In-Reply-To: <9241B253-8004-4DDD-B1EF-A7D02A3FEAFD@cs.purdue.edu> References: , , <9241B253-8004-4DDD-B1EF-A7D02A3FEAFD@cs.purdue.edu> Message-ID: I think it'd be another boolean or expansion of a boolean to an integer to declare/import/begin_procedure/constant/variable. Not passing all the files at once. Passing all the files at once is attractive for reasons of compilation perf and optimizing codegen but I believe it requires a lot of other work. Similarly, passing all the C files at once to the C compiler is also attractive, and more work. LTCG/LTO provide similar benefits, but we aren't setup to use LTO and honestly I'm trying to ignore it. I'll settle for -O1/2/3. - Jay Subject: Re: [M3devel] import from same .so or not From: hosking at cs.purdue.edu Date: Mon, 12 Jul 2010 20:14:39 -0400 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu There question is where and how to communicate it back to gcc. Does it mean putting all the module units on the same command line for compilation by a single instance of cm3cg? Or do you communicate it some other way? On 12 Jul 2010, at 19:53, Jay K wrote: I don't know. I hope not. The information is there: lowercase interface vs. uppercase Interface, lowercase module vs. uppercase Module, derived_interface(hidden or private). I haven't looked at where all it is sent around. - Jay > Subject: Re: [M3devel] import from same .so or not > From: hosking at cs.purdue.edu > Date: Mon, 12 Jul 2010 09:28:43 -0400 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > It seems to me this would require massive reworking of the build infrastructure! > > On 11 Jul 2010, at 21:58, Jay K wrote: > > > > > It seems to me, an important bit of information is not provided to the backend. > > > > The backend is told "import" or "export". > > But this is about "modules", .m3 files to .m3 files. > > > > It isn't about .so files to .so files, or .dlls to .dlls. > > > > It's really tristate, not boolean: > > private to just this source file > > private to this source file and those it statically links to > > public for all > > > > Granted, you might statically link "everything". > > There isn't enforcement of the middle state, and symbols still need to be as unique as the third state. > > But it is definitely useful. > > > > In particular we don't use DECL_VISIBILITY (p) = VISIBILITY_HIDDEN enough. > > For a long time we never used it. e.g. in the release branch. > > > > Agreed? > > Anyone volunteer to fix? > > Or mind if I try? > > > > > > - Jay > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Tue Jul 13 05:35:19 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Mon, 12 Jul 2010 23:35:19 -0400 Subject: [M3devel] still having compile problems with HEAD branch Message-ID: I'm still unable to build the HEAD branch on Windows. I'm getting some version mismatch errors early on in the build process. Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 13 06:36:01 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 13 Jul 2010 04:36:01 +0000 Subject: [M3devel] still having compile problems with HEAD branch In-Reply-To: References: Message-ID: Randy, you probably need to go back to a working state, such as by reinstalling a release, and restart upgrade.py. - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com Date: Mon, 12 Jul 2010 23:35:19 -0400 Subject: [M3devel] still having compile problems with HEAD branch I?m still unable to build the HEAD branch on Windows. I?m getting some version mismatch errors early on in the build process. Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 13 08:38:05 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 13 Jul 2010 06:38:05 +0000 Subject: [M3devel] barrier labels? In-Reply-To: References: , , , , , , , <08509C7F-5EC5-4679-8094-6985A70CC7C6@cs.purdue.edu>, , Message-ID: I don't know. There is so much unknown here. It is frustrating and difficult. We could use an extensive set of test cases. ? Or know more about the test cases we do have. And it'd be nice to see if anything varies in the 4.3 path if we put the labels on that list or not. tangent: I'd like automation that compiles the whole system, multiple architectures, and puts all the *s files in one flat directory per architecture. I guess it's just a matter of a little code. ??? It should just skip the few errors that are cross problems, which I should fix anyway. ??? That particular problem makes me a little nervous, but I suppose I can code it to use both INTEGER and Target.Int ?? ??? if doing a native build, and assert that the results match. I hit a snag yesterday, can't build any tests (just to assembly) without first shipping m3core/libm3. Can't ship m3core/libm3 for cross building. I guess, and I forgot this, I should have used -x for override. Duh. That's why I tried I386_DARWIN for some current 4.5 problems vs. SOLgnu, to escape cross building. Oops. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Mon, 12 Jul 2010 09:43:01 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] barrier labels? > > Perhaps we just need FORCED_LABEL for these: > > /* In a LABEL_DECL, nonzero means this label had its address taken > and therefore can never be deleted and is a jump target for > computed gotos. */ > > > On 11 Jul 2010, at 23:03, Jay K wrote: > > > > > I still don't see it, in the C++ frontend. > > > > There is: > > > > void > > expand_label (tree label) > > { > > ... > > if (DECL_NONLOCAL (label)) > > { > > ... nonlocal_goto_handler_labels > > = gen_rtx_EXPR_LIST (VOIDmode, label_r, > > nonlocal_goto_handler_labels); > > } > > > > but I don't think this works until later. > > > > - Jay > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Sun, 11 Jul 2010 20:52:25 -0400 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] barrier labels? > >> > >> No, that code came from 4.x... > >> > >> > >> > >> > >> On 11 Jul 2010, at 19:41, Jay K wrote: > >> > >>> > >>> Tony, thanks for the pointer..though I haven't been able to find it yet. > >>> I also looked for related code in 3.3 and 3.4, as I think 3.3 was current at the time. > >>> > >>> - Jay > >>> > >>> ---------------------------------------- > >>>> From: hosking at cs.purdue.edu > >>>> Date: Sun, 11 Jul 2010 16:25:41 -0400 > >>>> To: jay.krell at cornell.edu > >>>> CC: m3devel at elegosoft.com > >>>> Subject: Re: [M3devel] barrier labels? > >>>> > >>>> I extracted that usage from what C++ was doing for exception labels. The point is to make sure that flow analysis knows that the exception handler label targets are important "non-local" label targets. I do remember that DECL_NONLOCAL was *not* the right thing to do (that is used for proper non-local outer-scope goto targets for nested functions) and I remember the SP hacks being used with that (they need to recover from targeting from an inner-scope function and clean up the stack accordingly). I suggest poking around in what the C++ exception handling now does with table-driven exception targets. > >>>> > >>>> On 11 Jul 2010, at 07:46, Jay K wrote: > >>>> > >>>>> > >>>>> Tony, six years ago you introduce what is now: > >>>>> > >>>>> > >>>>> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c.diff?r1=1.5;r2=1.6 > >>>>> > >>>>> > >>>>> static void > >>>>> m3cg_set_label (void) > >>>>> { > >>>>> ... > >>>>> if (barrier) > >>>>> { > >>>>> ... > >>>>> { > >>>>> rtx list = DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels; > >>>>> DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels > >>>>> = gen_rtx_EXPR_LIST (VOIDmode, r, list); > >>>>> } > >>>>> ... > >>>>> > >>>>> > >>>>> I'm not sure what to do here for gcc 4.5. > >>>>> The data has moved around and isn't available this early. I suppose we could hang some information on and > >>>>> deal with it later in compilation. > >>>>> > >>>>> > >>>>> DECL_NONLOCAL(l) = true; seems promising, but it caused very bad code to be produced (incorrect, not inefficient). > >>>>> I didn't look into why. The bad code was changing the stack pointer where it should leave it alone. > >>>>> > >>>>> > >>>>> gcc-4.5 is working for me now (cm3 built with it can built itself), at least with -O1, AMD64_DARWIN. > >>>>> And Juno/mentor/tetris work without optimization, I'll test optimized later. > >>>>> Next I'll test -O2, -O3, m3-sys/m3tests. > >>>>> > >>>>> > >>>>> Do we have good exception handling tests? > >>>>> I know that cm3 uses exceptions, like, looking for cm3.cfg. > >>>>> > >>>>> > >>>>> I'll poke around more.. > >>>>> > >>>>> > >>>>> - Jay > >>>>> > >>>> > >>> > >> > > > From mika at async.async.caltech.edu Tue Jul 13 10:11:58 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Tue, 13 Jul 2010 01:11:58 -0700 Subject: [M3devel] "FreeBSD4" false advertising Message-ID: <20100713081158.D3E221A20A4@async.async.caltech.edu> Hi Modula-3ers, I am again (for the "umpteenth" time) attempting to move a medium-sized under-development software repository from PM3 to CM3. Things are looking better! But of course there is one snake in paradise. Can I upgrade the software without installing new OSes as well (at the same time)? The installation archive marked "FreeBSD4" does *not* work on FreeBSD 4/i386 nor on FreeBSD 5. Is it from 6 or 7? As I have mentioned before, FreeBSD is pretty good about being backward-compatible (FreeBSD 4 binaries and even compilers will work fine on 5 or 6), but it's not at all forwards-compatible. You simply cannot compile something on FreeBSD 6 and expect it to work on an earlier release of the OS. I have the following on a bona fide FreeBSD 4.11-RELEASE system: (62)trs80:~>cm3 -version Critical Mass Modula-3 version d0.0.0 last updated: unknown compiled: 2009-04-25 02:28:01 configuration: /usr/local/cm3/bin/cm3.cfg (63)trs80:~> My bootstrapping instructions I received from Tony do not work. Quake has changed so I get an error even cm3 trying to read the m3makefiles.... so how would I go about bootstrapping the latest CM3 on this? I wouldn't trust Python on it either. (I have Python but an old old version.) Yes I do want to get rid of FreeBSD-4.11 but one thing at a time would be my preference. Right now I seem to have all the software happy with CM3 (for once!) Mika From wagner at elegosoft.com Tue Jul 13 11:11:31 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 13 Jul 2010 11:11:31 +0200 Subject: [M3devel] "FreeBSD4" false advertising Message-ID: <20100713111131.lf9wqsz9eo0ckko0@mail.elegosoft.com> Quoting Mika Nystrom : > Hi Modula-3ers, > > I am again (for the "umpteenth" time) attempting to move a medium-sized > under-development software repository from PM3 to CM3. Things are looking > better! > > But of course there is one snake in paradise. Can I upgrade the software > without installing new OSes as well (at the same time)? > > The installation archive marked "FreeBSD4" does *not* work on FreeBSD 4/i386 > nor on FreeBSD 5. Is it from 6 or 7? > > As I have mentioned before, FreeBSD is pretty good about being > backward-compatible (FreeBSD 4 binaries and even compilers will work fine > on 5 or 6), but it's not at all forwards-compatible. You simply cannot > compile something on FreeBSD 6 and expect it to work on an earlier release > of the OS. Hi Mika, you're completely right about that. The name FreeBSD4 is currently wrong; nobody has added a new platform for every new release of FreeBSD since the time 4.x came out. It should long have been renamed to I386_FREEBSD. We also need to document the actual OS version an installation archive has been built on. I'll try to do that for the next release, but for 5.8 I think we simply need to rename and/or document the build systems (probably not before tomorrow evening though). The FreeBSD4 archives are actually built on a FreeBSD 6 system: FreeBSD new.elego.de 6.4-RELEASE-p5 FreeBSD 6.4-RELEASE-p5 #1: Sun Jun 14 14:03:37 CEST 2009 I'll try to rename them on birch, at least for the release and RC5, but I'm afraid I haven't got an actual FreeBSD 4.x system for build purposes anymore. The last version that may be directly useful I find on the web pages is FreeBSD 4.x and later: cm3-min-POSIX-FreeBSD4-d5.5.0.tgz (built on FreeBSD 4.11 i686) at http://www.modula3.com/cm3/cm3-min-POSIX-FreeBSD4-d5.5.0.tgz This could be used together with the upgrade.sh script to built the 5.8 release sources. > I have the following on a bona fide FreeBSD 4.11-RELEASE system: > > (62)trs80:~>cm3 -version > Critical Mass Modula-3 version d0.0.0 > last updated: unknown > compiled: 2009-04-25 02:28:01 > configuration: /usr/local/cm3/bin/cm3.cfg As the version string is actually undefined, this doesn't tell us very much :-( > (63)trs80:~> > > My bootstrapping instructions I received from Tony do not work. Quake has > changed so I get an error even cm3 trying to read the m3makefiles.... so > how would I go about bootstrapping the latest CM3 on this? I wouldn't > trust Python on it either. (I have Python but an old old version.) What exactly is the error you get? Can you try with the installation archives mentioned above? > Yes I do want to get rid of FreeBSD-4.11 but one thing at a time would be > my preference. Right now I seem to have all the software happy with CM3 > (for once!) I'd like to provide real FreeBSD4 archives, so if you get it to work, I'd ask you to run scripts/make-dist.sh to build and ship them (after the current FreeBSD4 archives have been renamed). If you get stuck, I'll try to help as I can; if you can provide remote access, I'd even try to build a working system myself. Sorry for the inconveniences, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 mika at async.async.caltech.edu Tue Jul 13 11:20:43 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Tue, 13 Jul 2010 02:20:43 -0700 Subject: [M3devel] "FreeBSD4" false advertising In-Reply-To: <20100713111131.lf9wqsz9eo0ckko0@mail.elegosoft.com> References: <20100713111131.lf9wqsz9eo0ckko0@mail.elegosoft.com> Message-ID: <20100713092043.808181A20A2@async.async.caltech.edu> Olaf Wagner writes: ... >FreeBSD 4.x and later: cm3-min-POSIX-FreeBSD4-d5.5.0.tgz >(built on FreeBSD 4.11 i686) at > > http://www.modula3.com/cm3/cm3-min-POSIX-FreeBSD4-d5.5.0.tgz > >This could be used together with the upgrade.sh script to built the >5.8 release sources. > >> I have the following on a bona fide FreeBSD 4.11-RELEASE system: >> >> (62)trs80:~>cm3 -version >> Critical Mass Modula-3 version d0.0.0 >> last updated: unknown >> compiled: 2009-04-25 02:28:01 >> configuration: /usr/local/cm3/bin/cm3.cfg > >As the version string is actually undefined, this doesn't tell us very =20 >much :-( Olaf, I'm pretty sure that release archive is a tarred up version of my system. (I built it on this machine!) How do I use upgrade.sh? I've been doing things manually following Tony's recommendations from a few years ago and that doesn't work. Well I'll try the obvious thing :-) Mika From jay.krell at cornell.edu Tue Jul 13 12:33:46 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 13 Jul 2010 10:33:46 +0000 Subject: [M3devel] "FreeBSD4" false advertising In-Reply-To: <20100713092043.808181A20A2@async.async.caltech.edu> References: <20100713111131.lf9wqsz9eo0ckko0@mail.elegosoft.com>, <20100713092043.808181A20A2@async.async.caltech.edu> Message-ID: The compatibility story on FreeBSD and some uncertain others is incredibly disappointing. When I build something on Windows 7, by default it works on older Windows systems. The ABI doesn't change. New functions are added. "Behavioral compability", *that* is the tricky part. Apple does similar, but also a hybrid of the "Unix model". Anyway, just do a cross build. It is fairly easy. ? If it is too hard, complain and suggest changes. Get the current source on the FreeBSD 4 machine and on nearly any other machine. ?? They don't actually have to be identical, I believe, because this won't be an "upgrade" but ??? eventually on the target will build up the entire system from "scratch", from just cm3, no libraries, ??? and cm3 no longer is tied to the libraries it is building at all (it used to be, it was bad). The second machine should have a working cm3. You can download a release. cd scripts/python ./boot1.py FreeBSD4 ?or ./boot1.py I386_FREEBSD wait a bit you'll have cme-boot-I386_FREEBSD-timestamp.tgz or such. Copy (scp) that to the FreeBSD 4 machine. Extract it. cd into it. Maybe look at the top of Makefile. ?Sometimes it isn't quite right. Using autoconf/libtool just a bit here is a good idea for future. make, maybe gnumake or gmake, though it is a very simple Makefile. result is cm3 in current directory ? ./cm3 ? It should say "unable to find cm3.cfg". ? If so, good, continue. ? If not, something didn't work and you'll have to investigate. mkdir -p $HOME/cm3/bin?? # or whatever cp cm3 $HOME/cm3/bin export PATH=$HOME/cm3/bin:$PATH cd scripts/python ./boot2.sh wait a while, a while result should be a working system, that built itself as well (look at boot2.sh) http://modula3.elegosoft.com/cm3/uploaded-archives/index.html You should be able to start from here: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-FreeBSD4-1.tar.gz or, er...here http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-FreeBSD4-1-userthreads.tar.gz Does FreeBSD4 have any sort of pthreads? If not, in the above instructions, you will need to make an edit in m3-libs/m3core/src/thread.quake. In the current tree, it looks pretty obvious what to do, since it is here that OpenBSD is pointed at user threads. In head,? I have added support and significantly tested a bunch of "fixed names": ? I386_LINUX, I386_FREEBSD, I386_NETBSD, I386_NT, I386_CYGWIN, I386_MINGW. Did I miss any? These are good names, right? esp. the last three? The one lagging point though is what to do about "SPARC32_SOLARIS". I think probably use cc by default but make swtiching to gcc just be a one line change in the config file. Maybe provide config files SPARC32_SOLARIS and SPARC32_SOLARIS_gcc. ?But they'd have the same TARGET and BUILD_DIR: SPARC32_SOLARIS. And maybe it should be SPARC_SOLARIS. ?- Jay ---------------------------------------- > To: wagner at elegosoft.com > Date: Tue, 13 Jul 2010 02:20:43 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] "FreeBSD4" false advertising > > Olaf Wagner writes: > ... > >FreeBSD 4.x and later: cm3-min-POSIX-FreeBSD4-d5.5.0.tgz > >(built on FreeBSD 4.11 i686) at > > > > http://www.modula3.com/cm3/cm3-min-POSIX-FreeBSD4-d5.5.0.tgz > > > >This could be used together with the upgrade.sh script to built the > >5.8 release sources. > > > >> I have the following on a bona fide FreeBSD 4.11-RELEASE system: > >> > >> (62)trs80:~>cm3 -version > >> Critical Mass Modula-3 version d0.0.0 > >> last updated: unknown > >> compiled: 2009-04-25 02:28:01 > >> configuration: /usr/local/cm3/bin/cm3.cfg > > > >As the version string is actually undefined, this doesn't tell us very =20 > >much :-( > > Olaf, I'm pretty sure that release archive is a tarred up version of my > system. (I built it on this machine!) > > How do I use upgrade.sh? I've been doing things manually following Tony's > recommendations from a few years ago and that doesn't work. > > Well I'll try the obvious thing :-) > > Mika From hosking at cs.purdue.edu Tue Jul 13 16:36:11 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 13 Jul 2010 10:36:11 -0400 Subject: [M3devel] import from same .so or not In-Reply-To: References: , , <9241B253-8004-4DDD-B1EF-A7D02A3FEAFD@cs.purdue.edu> Message-ID: <76827F66-451E-410E-9AF0-200D9538AFA1@cs.purdue.edu> OK, so what you want is for the build system (cm3/src/M3Build.m3) to pass a flag saying that a given module is package visible. Shouldn't be too hard to do. On 12 Jul 2010, at 20:50, Jay K wrote: > I think it'd be another boolean or expansion of a boolean to an integer to declare/import/begin_procedure/constant/variable. > Not passing all the files at once. > > > Passing all the files at once is attractive for reasons of compilation perf and optimizing codegen but I believe it requires a lot of other work. > > > Similarly, passing all the C files at once to the C compiler is also attractive, and more work. > > > LTCG/LTO provide similar benefits, but we aren't setup to use LTO and honestly I'm trying to ignore it. > I'll settle for -O1/2/3. > > > - Jay > > Subject: Re: [M3devel] import from same .so or not > From: hosking at cs.purdue.edu > Date: Mon, 12 Jul 2010 20:14:39 -0400 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > There question is where and how to communicate it back to gcc. Does it mean putting all the module units on the same command line for compilation by a single instance of cm3cg? Or do you communicate it some other way? > > On 12 Jul 2010, at 19:53, Jay K wrote: > > I don't know. I hope not. The information is there: lowercase interface vs. uppercase Interface, lowercase module vs. uppercase Module, derived_interface(hidden or private). > I haven't looked at where all it is sent around. > > - Jay > > > > Subject: Re: [M3devel] import from same .so or not > > From: hosking at cs.purdue.edu > > Date: Mon, 12 Jul 2010 09:28:43 -0400 > > CC: m3devel at elegosoft.com > > To: jay.krell at cornell.edu > > > > It seems to me this would require massive reworking of the build infrastructure! > > > > On 11 Jul 2010, at 21:58, Jay K wrote: > > > > > > > > It seems to me, an important bit of information is not provided to the backend. > > > > > > The backend is told "import" or "export". > > > But this is about "modules", .m3 files to .m3 files. > > > > > > It isn't about .so files to .so files, or .dlls to .dlls. > > > > > > It's really tristate, not boolean: > > > private to just this source file > > > private to this source file and those it statically links to > > > public for all > > > > > > Granted, you might statically link "everything". > > > There isn't enforcement of the middle state, and symbols still need to be as unique as the third state. > > > But it is definitely useful. > > > > > > In particular we don't use DECL_VISIBILITY (p) = VISIBILITY_HIDDEN enough. > > > For a long time we never used it. e.g. in the release branch. > > > > > > Agreed? > > > Anyone volunteer to fix? > > > Or mind if I try? > > > > > > > > > - Jay > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at wickensonline.co.uk Tue Jul 13 21:19:15 2010 From: mark at wickensonline.co.uk (Mark Wickens) Date: Tue, 13 Jul 2010 20:19:15 +0100 Subject: [M3devel] CM3 on Alpha tru64 4.0G In-Reply-To: <76827F66-451E-410E-9AF0-200D9538AFA1@cs.purdue.edu> References: , , <9241B253-8004-4DDD-B1EF-A7D02A3FEAFD@cs.purdue.edu> <76827F66-451E-410E-9AF0-200D9538AFA1@cs.purdue.edu> Message-ID: <1279048755.1793.13.camel@x60.appsoftint.co.uk> Hi Guys, I've been trying unsuccessfully to build various version of Modula-3 (DEC-SRC, PM3, CM3) on a DEC Alpha 300 running tru64 4.0G and was wondering whether anyone could give some guidance of what is possible, indeed sensible. I've received a couple of helpful emails for Daniel, but what I'd really like clarified are the following: 1. Is this sensible, or is tru64 5+ the only realistic tru64 platform to attempt? 2. The executables for tru64 uploaded to the opencm3 website in cm3-min-ALPHA_OSF-d5.8.2-20100612.tar.gz don't work for me - I get a decthreads exception. Does anyone know what version of tru64 these were built with? 3. Is it possible to build CM3 from scratch, or do I need some version of the M3 build tools? Many thanks for the help. I used DEC-SRC Modula-3 around 1995 and am trying to get it compiled up for a recent project, but on an original platform. Some may call me crazy, and they'd be totally justified. I'm not sure whether back-in-the-day I had it running on tru64 (well back then it would have been Digital Unix 3.2C) or whether it was on a linux box. Thanks for the help, Mark. From hosking at cs.purdue.edu Tue Jul 13 22:31:39 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 13 Jul 2010 16:31:39 -0400 Subject: [M3devel] CM3 on Alpha tru64 4.0G In-Reply-To: <1279048755.1793.13.camel@x60.appsoftint.co.uk> References: , , <9241B253-8004-4DDD-B1EF-A7D02A3FEAFD@cs.purdue.edu> <76827F66-451E-410E-9AF0-200D9538AFA1@cs.purdue.edu> <1279048755.1793.13.camel@x60.appsoftint.co.uk> Message-ID: <8E02058D-1A62-48FF-8DA7-B2C40C53B048@cs.purdue.edu> This should be entirely doable, so long as reasonable pthread APIs exist on 4.x Tru64. What was the decthreads exception? On 13 Jul 2010, at 15:19, Mark Wickens wrote: > Hi Guys, > > I've been trying unsuccessfully to build various version of Modula-3 > (DEC-SRC, PM3, CM3) on a DEC Alpha 300 running tru64 4.0G and was > wondering whether anyone could give some guidance of what is possible, > indeed sensible. > > I've received a couple of helpful emails for Daniel, but what I'd really > like clarified are the following: > > 1. Is this sensible, or is tru64 5+ the only realistic tru64 platform to > attempt? > > 2. The executables for tru64 uploaded to the opencm3 website in > cm3-min-ALPHA_OSF-d5.8.2-20100612.tar.gz don't work for me - I get a > decthreads exception. Does anyone know what version of tru64 these were > built with? > > 3. Is it possible to build CM3 from scratch, or do I need some version > of the M3 build tools? > > Many thanks for the help. I used DEC-SRC Modula-3 around 1995 and am > trying to get it compiled up for a recent project, but on an original > platform. Some may call me crazy, and they'd be totally justified. I'm > not sure whether back-in-the-day I had it running on tru64 (well back > then it would have been Digital Unix 3.2C) or whether it was on a linux > box. > > Thanks for the help, > > Mark. From mark at wickensonline.co.uk Tue Jul 13 22:40:28 2010 From: mark at wickensonline.co.uk (Mark Wickens) Date: Tue, 13 Jul 2010 21:40:28 +0100 Subject: [M3devel] CM3 on Alpha tru64 4.0G In-Reply-To: <8E02058D-1A62-48FF-8DA7-B2C40C53B048@cs.purdue.edu> References: , , <9241B253-8004-4DDD-B1EF-A7D02A3FEAFD@cs.purdue.edu> <76827F66-451E-410E-9AF0-200D9538AFA1@cs.purdue.edu> <1279048755.1793.13.camel@x60.appsoftint.co.uk> <8E02058D-1A62-48FF-8DA7-B2C40C53B048@cs.purdue.edu> Message-ID: <1279053628.1793.15.camel@x60.appsoftint.co.uk> Hi Tony, the exception I get is as follows: >From cm3-min-ALPHA_OSF-d5.8.2-20100612/bin bash-3.2$ ./cm3 %DECthreads bugcheck (version V3.18-037), terminating execution. % Reason: stkGet: (4) nxm_stack_create (0,5251072,16384,8192) % Running on OSF1 V4.0(1530) on AlphaServer 300 4/266, 256Mb; 1 CPUs, pid 21360 From jay.krell at cornell.edu Wed Jul 14 01:04:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 13 Jul 2010 23:04:20 +0000 Subject: [M3devel] CM3 on Alpha tru64 4.0G In-Reply-To: <1279053628.1793.15.camel@x60.appsoftint.co.uk> References: ,, , , , <9241B253-8004-4DDD-B1EF-A7D02A3FEAFD@cs.purdue.edu>, , <76827F66-451E-410E-9AF0-200D9538AFA1@cs.purdue.edu>, <1279048755.1793.13.camel@x60.appsoftint.co.uk>, <8E02058D-1A62-48FF-8DA7-B2C40C53B048@cs.purdue.edu>, <1279053628.1793.15.camel@x60.appsoftint.co.uk> Message-ID: Things to try: cross build, user threads. Do you have a "modern" system with a working cm3? Do you have cvs and a working C compiler/linker on this older system? ?- Jay ---------------------------------------- > From: mark at wickensonline.co.uk > To: hosking at cs.purdue.edu > Date: Tue, 13 Jul 2010 21:40:28 +0100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] CM3 on Alpha tru64 4.0G > > Hi Tony, the exception I get is as follows: > > >From cm3-min-ALPHA_OSF-d5.8.2-20100612/bin > > bash-3.2$ ./cm3 > %DECthreads bugcheck (version V3.18-037), terminating execution. > % Reason: stkGet: (4) nxm_stack_create (0,5251072,16384,8192) > % Running on OSF1 V4.0(1530) on AlphaServer 300 4/266, 256Mb; 1 CPUs, > pid 21360 > > From jay.krell at cornell.edu Wed Jul 14 01:27:51 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 13 Jul 2010 23:27:51 +0000 Subject: [M3devel] CM3 on Alpha tru64 4.0G In-Reply-To: References: , , , , , , , , <9241B253-8004-4DDD-B1EF-A7D02A3FEAFD@cs.purdue.edu>, , , , <76827F66-451E-410E-9AF0-200D9538AFA1@cs.purdue.edu>, , <1279048755.1793.13.camel@x60.appsoftint.co.uk>, , <8E02058D-1A62-48FF-8DA7-B2C40C53B048@cs.purdue.edu>, , <1279053628.1793.15.camel@x60.appsoftint.co.uk>, Message-ID: > Things to try: cross build, user threads. http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-ALPHA_OSF-pthreads-d5.8.2-20100713.tgz or http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-ALPHA_OSF-userthreads-d5.8.2-20100713.tgz ? And in userthreads, if there is no get/set/make/swapcontext, you can change the #if at the top of ThreadPosixC.c to try sigaltstack. Also the userthreads Makefile has -lpthread in it, which you'll maybe want to remove...depending on if there is pthread_atfork, i.e. you? might want to tweak this: jbook2:cm3-boot-ALPHA_OSF-d5.8.2-20100713 jay$ grep pthread_atfork *c RTProcessC.c:????? int i = pthread_atfork(prepare, parent, child); but try the pthread version first? These will give you a cm3 and if it prints "unable to find cm3.cfg", good. Tru64 4.x isn't officially supported by gcc any longer, but I noticed recent test results posted anyway. You just have to configure -enable-obsolete or somesuch. Can you give me ssh access? That's a good and bad thing. Should be doable without such direct help by me.. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: mark at wickensonline.co.uk; hosking at cs.purdue.edu > Date: Tue, 13 Jul 2010 23:04:20 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] CM3 on Alpha tru64 4.0G > > > Things to try: cross build, user threads. > Do you have a "modern" system with a working cm3? > Do you have cvs and a working C compiler/linker on this older system? > > - Jay > > ---------------------------------------- > > From: mark at wickensonline.co.uk > > To: hosking at cs.purdue.edu > > Date: Tue, 13 Jul 2010 21:40:28 +0100 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] CM3 on Alpha tru64 4.0G > > > > Hi Tony, the exception I get is as follows: > > > > >From cm3-min-ALPHA_OSF-d5.8.2-20100612/bin > > > > bash-3.2$ ./cm3 > > %DECthreads bugcheck (version V3.18-037), terminating execution. > > % Reason: stkGet: (4) nxm_stack_create (0,5251072,16384,8192) > > % Running on OSF1 V4.0(1530) on AlphaServer 300 4/266, 256Mb; 1 CPUs, > > pid 21360 > > > > > From jay.krell at cornell.edu Wed Jul 14 11:17:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Jul 2010 09:17:57 +0000 Subject: [M3devel] -pthread vs. -pthreads arg Message-ID: Just a note: Some versions of gcc accept -pthread, some -pthreads, some both. Lame. In particular, from the few systems I've tested: Darwin either Solaris pthreads FreeBSD OpenBSD Linux pthread ??? probably NetBSD, Interix, Cygwin same but I didn't check Solaris cc use -mt instead ?- Jay From mark at wickensonline.co.uk Wed Jul 14 11:40:23 2010 From: mark at wickensonline.co.uk (Mark Wickens) Date: Wed, 14 Jul 2010 10:40:23 +0100 Subject: [M3devel] -pthread vs. -pthreads arg In-Reply-To: References: Message-ID: <1279100423.1793.22.camel@x60.appsoftint.co.uk> On Wed, 2010-07-14 at 09:17 +0000, Jay K wrote: > Just a note: > Some versions of gcc accept -pthread, some -pthreads, some both. Lame. > In particular, from the few systems I've tested: > > Darwin either > Solaris pthreads > FreeBSD OpenBSD Linux pthread > probably NetBSD, Interix, Cygwin same but I didn't check > Solaris cc use -mt instead > > > - Jay > > Hi Jay, So what would you recommend as the best thing to try first? Cross-compile? I installed the debian based package on a 32 bit ubuntu 10.4 install and that works fine. I am also happy to give you remote access to the box - that is no problem at all. Regards, Mark. From wagner at elegosoft.com Wed Jul 14 12:55:16 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 14 Jul 2010 12:55:16 +0200 Subject: [M3devel] LongrealType missed, was: Re: "FreeBSD4" false advertising In-Reply-To: <20100714104312.155351A2098@async.async.caltech.edu> References: <20100714094120.93B001A2098@async.async.caltech.edu> <20100714114648.nhnwruh008840wso@mail.elegosoft.com> <20100714100138.631581A2098@async.async.caltech.edu>, <20100714100525.BEE931A2096@async.async.caltech.edu> <20100714104312.155351A2098@async.async.caltech.edu> Message-ID: <20100714125516.1mzfehgnkgcs800w@mail.elegosoft.com> Quoting Mika Nystrom : > Argh is it really necessary to break source compatibility here? > > I also don't like that I as a client have to import IEEE things when all > I want is "LONGREAL" (and let Modula-3 do whatever it wants with that). > > I would propose at least having an interface LongrealType with > > CONST Hash = Longreal.Hash > > etc. so as not to force clients to import all the nitty-gritty about > various floating point representations. And so as not to break source > compatibility! If I change this by removing Type, my code will no longer > compile with the old compilers.... Hm, I'm a little bit out of context here... What was the reason for this change? It seems nobody else has bothered so far. This was the commit in question: 2009-12-23 21:43 hosking * m3-libs/: m3core/src/m3makefile, libm3/src/types/ASCII.i3, libm3/src/types/ASCII.m3, libm3/src/types/Boolean.i3, libm3/src/types/Boolean.m3, libm3/src/types/COPYRIGHT-CMASS, libm3/src/types/Char.i3, libm3/src/types/Char.m3, libm3/src/types/Int32.i3, libm3/src/types/Int32.m3, libm3/src/types/Int64.i3, libm3/src/types/Int64.m3, libm3/src/types/Integer.i3, libm3/src/types/Integer.m3, libm3/src/types/Longint.i3, libm3/src/types/Longint.m3, libm3/src/types/LongrealType.i3, libm3/src/types/LongrealType.m3, libm3/src/types/RealType.i3, libm3/src/types/RealType.m3, libm3/src/types/Refany.i3, libm3/src/types/Refany.m3, libm3/src/types/Unicode.i3, libm3/src/types/Unicode.m3, libm3/src/types/WideChar.i3, libm3/src/types/WideChar.m3, libm3/src/types/m3makefile, m3core/src/float/Common/Extended.m3, m3core/src/float/Common/LongReal.m3, m3core/src/float/Common/Real.m3, m3core/src/float/IEEE/Extended.i3, m3core/src/float/IEEE/LongReal.i3, m3core/src/float/IEEE/Real.i3, m3core/src/float/VAX/Extended.i3, m3core/src/float/VAX/LongReal.i3, m3core/src/float/VAX/Real.i3: Move libm3/src/types into m3core. Note that LongrealType and RealType have been folded into m3core/src/float. Clients will need adjustment. Any comments? Olaf > Mika > > Jay K writes: >> >> Remove "Type" it appears. >> >> >> http://modula3.elegosoft.com/cm3/ChangeLog-2009 >> >> search for "clients will need". >> >> e.g. >> >> +++ cm3/m3-demo/mentor/src/binpack/m3makefile 2009/12/23 22:05:06 1.2 >> @@ -10=2C7 +10=2C7 @@ >> =20 >> import ("zeus") >> =20 >> -list ("Real"=2C "RealType") >> +list ("Real"=2C "Real") >> =20 >> zume ("Binpack") >> oblume ("Binpack"=2C "myview") >> >> --- cm3/m3-demo/mentor/src/binpack/RealList.i3 2001/01/13 14:18:20 1.1 >> +++ cm3/m3-demo/mentor/src/binpack/RealList.i3 2009/12/23 22:05:05 1.2 >> @@ -2=2C4 +2=2C4 @@ >> (* Distributed only by permission. *) >> (* Last modified on Fri Jul 9 16:36:47 PDT 1993 by mhb *) >> =20 >> -INTERFACE RealList =3D List(RealType) END RealList. >> +INTERFACE RealList =3D List(Real) END RealList. >> >> --- cm3/m3-demo/mentor/src/binpack/RealList.m3 2001/01/13 14:18:20 1.1 >> +++ cm3/m3-demo/mentor/src/binpack/RealList.m3 2009/12/23 22:05:06 1.2 >> @@ -2=2C4 +2=2C4 @@ >> (* All rights reserved. *) >> (* See the file COPYRIGHT for a full description. *) >> =20 >> -MODULE RealList =3D List(RealType) END RealList. >> +MODULE RealList =3D List(Real) END RealList. >> >> =A0- Jay >> >> ---------------------------------------- >>> To: wagner at elegosoft.com >>> CC: jay.krell at cornell.edu=3B mika at async.caltech.edu >>> Subject: Re: [M3devel] "FreeBSD4" false advertising >>> Date: Wed=2C 14 Jul 2010 03:05:25 -0700 >>> From: mika at async.async.caltech.edu >>> >>> I'm not actually sure I understand the intent of the changes in this area= >> . >>> >>> My old m3makefile has: >>> >>> Table("TextLongReal"=2C "Text"=2C "LongrealType") >>> >>> What am I supposed to use now? >>> >>> Mika >>> >>> Mika Nystrom writes: >>> >Olaf Wagner writes: >>> >>Quoting Mika Nystrom : >>> >> >>> >>> Hi Jay=2C Olaf=2C >>> >>> >>> >>> I actually built everything! After backing out some of my changes >>> >>> that I had tried to get 5.8.6-REL to build with=2C it worked=2C and m= >> entor >>> >>> ran=2C even. >>> >> >>> >>Great! So it's still possible to build cm3 on FreeBSD 4=2C though >>> >>not our release code. >>> > >>> >The differences relative to the current CVS head are very minor. >>> > >>> >1. Added FreeBSD4 to thread.quake as a non-pthread platform >>> > >>> >2. got rid of the -m32 flags in FreeBSD4.conf >>> > >>> >Everything else that needed to change I think Jay has managed to put in >>> >the CVS head. >>> > >>> >> >>> >>> But... what happened to libm3/src/types? Building my own code I get >>> >>> the following errors: >>> >>> >>> >>> new source -> compiling LRInterval.i3 >>> >>> "../FreeBSD4/LRInterval.i3 =3D3D> ../src/Interval.ig"=2C line 5: unab= >> le to =3D20 >>> >>> find interface (LongrealType) >>> >>> 1 error encountered >>> >>> >>> >>> I can't find LongrealType anywhere=2C do I have a broken checkout? We= >> ll=2C it >>> >>> is in one place=2C in "doc". (Same for RealType=2C maybe others?) >>> >> >>> >>See =3D20 >>> >>http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/t= >> ypes/=3D >>> >>Attic/LongrealType.i3 >>> > >>> >Surely this is wrong?? I am looking for an interface that has T =3D >>> >LONGREAL=2C not something that lets me muck around with the representati= >> on >>> >of IEEE=2C VAX=2C etc.=2C floating-point formats. >>> > >>> >Why is it even in m3core? This seems clearly like libm3 stuff.. I notice= >> d >>> >Boolean.i3 also moved. >>> > >>> >Also if there is no importable interface called LongrealType that is goi= >> ng >>> >to cause endless problems with source that is supposed to compile under >>> >different versions of Modula-3. Even relatively recent CM3s required >>> >you to use LongrealType to instantiate generics. >>> > >>> > Mika >> = > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 14 13:23:49 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Jul 2010 11:23:49 +0000 Subject: [M3devel] LongrealType missed, was: Re: "FreeBSD4" false advertising In-Reply-To: <20100714125516.1mzfehgnkgcs800w@mail.elegosoft.com> References: <20100714094120.93B001A2098@async.async.caltech.edu>, <20100714114648.nhnwruh008840wso@mail.elegosoft.com>, <20100714100138.631581A2098@async.async.caltech.edu>, <20100714100525.BEE931A2096@async.async.caltech.edu>, , <20100714104312.155351A2098@async.async.caltech.edu>, <20100714125516.1mzfehgnkgcs800w@mail.elegosoft.com> Message-ID: Mika, Please try updating libm3 and see if that works for you. Thanks. ?- Jay ---------------------------------------- > Date: Wed, 14 Jul 2010 12:55:16 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > CC: jay.krell at cornell.edu; mika at async.caltech.edu > Subject: LongrealType missed, was: Re: [M3devel] "FreeBSD4" false advertising > > Quoting Mika Nystrom : > > > Argh is it really necessary to break source compatibility here? > > > > I also don't like that I as a client have to import IEEE things when all > > I want is "LONGREAL" (and let Modula-3 do whatever it wants with that). > > > > I would propose at least having an interface LongrealType with > > > > CONST Hash = Longreal.Hash > > > > etc. so as not to force clients to import all the nitty-gritty about > > various floating point representations. And so as not to break source > > compatibility! If I change this by removing Type, my code will no longer > > compile with the old compilers.... > > Hm, I'm a little bit out of context here... > What was the reason for this change? It seems nobody else has bothered > so far. > > This was the commit in question: > > 2009-12-23 21:43 hosking > > * m3-libs/: m3core/src/m3makefile, libm3/src/types/ASCII.i3, > libm3/src/types/ASCII.m3, libm3/src/types/Boolean.i3, > libm3/src/types/Boolean.m3, libm3/src/types/COPYRIGHT-CMASS, > libm3/src/types/Char.i3, libm3/src/types/Char.m3, > libm3/src/types/Int32.i3, libm3/src/types/Int32.m3, > libm3/src/types/Int64.i3, libm3/src/types/Int64.m3, > libm3/src/types/Integer.i3, libm3/src/types/Integer.m3, > libm3/src/types/Longint.i3, libm3/src/types/Longint.m3, > libm3/src/types/LongrealType.i3, libm3/src/types/LongrealType.m3, > libm3/src/types/RealType.i3, libm3/src/types/RealType.m3, > libm3/src/types/Refany.i3, libm3/src/types/Refany.m3, > libm3/src/types/Unicode.i3, libm3/src/types/Unicode.m3, > libm3/src/types/WideChar.i3, libm3/src/types/WideChar.m3, > libm3/src/types/m3makefile, m3core/src/float/Common/Extended.m3, > m3core/src/float/Common/LongReal.m3, m3core/src/float/Common/Real.m3, > m3core/src/float/IEEE/Extended.i3, m3core/src/float/IEEE/LongReal.i3, > m3core/src/float/IEEE/Real.i3, m3core/src/float/VAX/Extended.i3, > m3core/src/float/VAX/LongReal.i3, m3core/src/float/VAX/Real.i3: > > Move libm3/src/types into m3core. > Note that LongrealType and RealType have been folded into m3core/src/float. > Clients will need adjustment. > > Any comments? > > Olaf > > > Mika > > > > Jay K writes: > >> > >> Remove "Type" it appears. > >> > >> > >> http://modula3.elegosoft.com/cm3/ChangeLog-2009 > >> > >> search for "clients will need". > >> > >> e.g. > >> > >> +++ cm3/m3-demo/mentor/src/binpack/m3makefile 2009/12/23 22:05:06 1.2 > >> @@ -10=2C7 +10=2C7 @@ > >> =20 > >> import ("zeus") > >> =20 > >> -list ("Real"=2C "RealType") > >> +list ("Real"=2C "Real") > >> =20 > >> zume ("Binpack") > >> oblume ("Binpack"=2C "myview") > >> > >> --- cm3/m3-demo/mentor/src/binpack/RealList.i3 2001/01/13 14:18:20 1.1 > >> +++ cm3/m3-demo/mentor/src/binpack/RealList.i3 2009/12/23 22:05:05 1.2 > >> @@ -2=2C4 +2=2C4 @@ > >> (* Distributed only by permission. *) > >> (* Last modified on Fri Jul 9 16:36:47 PDT 1993 by mhb *) > >> =20 > >> -INTERFACE RealList =3D List(RealType) END RealList. > >> +INTERFACE RealList =3D List(Real) END RealList. > >> > >> --- cm3/m3-demo/mentor/src/binpack/RealList.m3 2001/01/13 14:18:20 1.1 > >> +++ cm3/m3-demo/mentor/src/binpack/RealList.m3 2009/12/23 22:05:06 1.2 > >> @@ -2=2C4 +2=2C4 @@ > >> (* All rights reserved. *) > >> (* See the file COPYRIGHT for a full description. *) > >> =20 > >> -MODULE RealList =3D List(RealType) END RealList. > >> +MODULE RealList =3D List(Real) END RealList. > >> > >> =A0- Jay > >> > >> ---------------------------------------- > >>> To: wagner at elegosoft.com > >>> CC: jay.krell at cornell.edu=3B mika at async.caltech.edu > >>> Subject: Re: [M3devel] "FreeBSD4" false advertising > >>> Date: Wed=2C 14 Jul 2010 03:05:25 -0700 > >>> From: mika at async.async.caltech.edu > >>> > >>> I'm not actually sure I understand the intent of the changes in this area= > >> . > >>> > >>> My old m3makefile has: > >>> > >>> Table("TextLongReal"=2C "Text"=2C "LongrealType") > >>> > >>> What am I supposed to use now? > >>> > >>> Mika > >>> > >>> Mika Nystrom writes: > >>> >Olaf Wagner writes: > >>> >>Quoting Mika Nystrom : > >>> >> > >>> >>> Hi Jay=2C Olaf=2C > >>> >>> > >>> >>> I actually built everything! After backing out some of my changes > >>> >>> that I had tried to get 5.8.6-REL to build with=2C it worked=2C and m= > >> entor > >>> >>> ran=2C even. > >>> >> > >>> >>Great! So it's still possible to build cm3 on FreeBSD 4=2C though > >>> >>not our release code. > >>> > > >>> >The differences relative to the current CVS head are very minor. > >>> > > >>> >1. Added FreeBSD4 to thread.quake as a non-pthread platform > >>> > > >>> >2. got rid of the -m32 flags in FreeBSD4.conf > >>> > > >>> >Everything else that needed to change I think Jay has managed to put in > >>> >the CVS head. > >>> > > >>> >> > >>> >>> But... what happened to libm3/src/types? Building my own code I get > >>> >>> the following errors: > >>> >>> > >>> >>> new source -> compiling LRInterval.i3 > >>> >>> "../FreeBSD4/LRInterval.i3 =3D3D> ../src/Interval.ig"=2C line 5: unab= > >> le to =3D20 > >>> >>> find interface (LongrealType) > >>> >>> 1 error encountered > >>> >>> > >>> >>> I can't find LongrealType anywhere=2C do I have a broken checkout? We= > >> ll=2C it > >>> >>> is in one place=2C in "doc". (Same for RealType=2C maybe others?) > >>> >> > >>> >>See =3D20 > >>> >>http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/t= > >> ypes/=3D > >>> >>Attic/LongrealType.i3 > >>> > > >>> >Surely this is wrong?? I am looking for an interface that has T =3D > >>> >LONGREAL=2C not something that lets me muck around with the representati= > >> on > >>> >of IEEE=2C VAX=2C etc.=2C floating-point formats. > >>> > > >>> >Why is it even in m3core? This seems clearly like libm3 stuff.. I notice= > >> d > >>> >Boolean.i3 also moved. > >>> > > >>> >Also if there is no importable interface called LongrealType that is goi= > >> ng > >>> >to cause endless problems with source that is supposed to compile under > >>> >different versions of Modula-3. Even relatively recent CM3s required > >>> >you to use LongrealType to instantiate generics. > >>> > > >>> > Mika > >> = > > > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Wed Jul 14 15:19:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Jul 2010 13:19:31 +0000 Subject: [M3devel] SOLgnu not working Message-ID: Just a note, that I'm aware, SOLgnu appears to be broken in head. = package /home/jay/dev2/cm3/m3-win/import-libs == ?+++ /cm3/bin/cm3??? -build -DROOT=/home/jay/dev2/cm3 +++ *** *** runtime error: ***??? Unhandled exception: OSError.E ***??? file "../src/os/POSIX/OSErrorPosix.m3", line 50 *** Abort - core dumped No ETA on a fix. But it is? important. ?- Jay From jay.krell at cornell.edu Wed Jul 14 17:03:55 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Jul 2010 15:03:55 +0000 Subject: [M3devel] SOLgnu not working In-Reply-To: References: Message-ID: Oh, sorry, it's probably ok. ? Debugging it... I was in user threads..because I had bootstrapped from 5.4.0. Maybe 5.4.0 is broken, don't care. ? Tried SOLsun..working better. ? Compared them..discovered this SOLgnu used the 4.5.0 backend, which isn't yet enabled. ! ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: SOLgnu not working > Date: Wed, 14 Jul 2010 13:19:31 +0000 > > > Just a note, that I'm aware, SOLgnu appears to be broken in head. > > = package /home/jay/dev2/cm3/m3-win/import-libs == > > +++ /cm3/bin/cm3 -build -DROOT=/home/jay/dev2/cm3 +++ > > > *** > *** runtime error: > *** Unhandled exception: OSError.E > *** file "../src/os/POSIX/OSErrorPosix.m3", line 50 > *** > > Abort - core dumped > > No ETA on a fix. But it is important. > > - Jay > > > > > From wagner at elegosoft.com Thu Jul 15 14:43:43 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 15 Jul 2010 14:43:43 +0200 Subject: [M3devel] minor problems on the release branch Message-ID: <20100715144343.qby2zwskgg4kok48@mail.elegosoft.com> While checking the status of the final 5.8.6 release of CM3, I found several minor problems, which would benefit from attention nonetheless. Investigating these should also be a good starting point for newbies and others lurking on the list and waiting for something to do: Why did this change? http://hudson.modula3.com:8080/view/cm3/job/cm3-test-m3tests-AMD64_LINUX/lastBuild/testReport/(root)/m3tests/p040__binary_____ASCII_conversion_routines (failing since Build #556 (Apr 29, 2010 9:35:06 PM)) same issue: http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-m3tests-I386_OPENBSD/lastBuild/testReport/(root)/m3tests/p040__binary_____ASCII_conversion_routines (failing since Build #28 (Nov 22, 2009 7:43:34 AM)) http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-m3tests-LINUXLIBC6/lastBuild/testReport/(root)/m3tests/p040__binary_____ASCII_conversion_routines (failing since Build #276 (Jul 9, 2010 11:40:25 AM)) The shipping tests on Nt386 seem to have never worked: http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-m3tests-NT386/374/testReport/ Test reporting ist still more or less completely broken on SOLsun :-( http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-m3tests-SOLsun/lastBuild Failed packages on I386_OPENBSD: http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-all-pkgs-I386_OPENBSD/44/testReport/ Failed packages on NT386: http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-all-pkgs-NT386/182/testReport/ m3gdb build fails on PPC_LINUX and SPARC32_LINUX: http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-all-pkgs-PPC_LINUX/18/testReport/ http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-all-pkgs-SPARC32_LINUX/lastBuild/testReport/ Failed package tests on SOLgnu and SOLsun: http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-all-pkgs-SOLgnu/lastBuild/testReport/ http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-all-pkgs-SOLsun/lastBuild/testReport/ Regards, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 bugs at elego.de Thu Jul 15 15:21:30 2010 From: bugs at elego.de (CM3) Date: Thu, 15 Jul 2010 13:21:30 -0000 Subject: [M3devel] [CM3] #1068: Segmentation violation in String8.m3 In-Reply-To: <062.b174f7e6cb17a55b692f50f311e18b17@elego.de> References: <062.b174f7e6cb17a55b692f50f311e18b17@elego.de> Message-ID: <071.f664d53a4c2a0572384dcc425bb5f2da@elego.de> #1068: Segmentation violation in String8.m3 ------------------------------------------+--------------------------------- Reporter: peter.mckinna@? | Owner: wagner Type: sw-bug | Status: assigned Priority: medium | Milestone: CM3 Release 5.9 Component: comm | Version: 5.8-RC3 Severity: serious | Keywords: pickles, 64 to 32 bit Relnote: | Org: Estimatedhours: 0.0 | Hours: 0 Billable: 1 | Totalhours: 0 Internal: 0 | ------------------------------------------+--------------------------------- Htr: Fix: Env: ------------------------------------------+--------------------------------- Changes (by wagner): * owner: rbates => wagner * milestone: CM3 release 5.8 => CM3 Release 5.9 -- Ticket URL: CM3 Critical Mass Modula3 Compiler From bugs at elego.de Thu Jul 15 15:22:23 2010 From: bugs at elego.de (CM3) Date: Thu, 15 Jul 2010 13:22:23 -0000 Subject: [M3devel] [CM3] #1068: Segmentation violation in String8.m3 In-Reply-To: <062.b174f7e6cb17a55b692f50f311e18b17@elego.de> References: <062.b174f7e6cb17a55b692f50f311e18b17@elego.de> Message-ID: <071.7f4f89c8c47fb8f7fdd347237342be4a@elego.de> #1068: Segmentation violation in String8.m3 ------------------------------------------+--------------------------------- Reporter: peter.mckinna@? | Owner: rbates Type: sw-bug | Status: assigned Priority: medium | Milestone: CM3 Release 5.9 Component: comm | Version: 5.8-RC3 Severity: serious | Keywords: pickles, 64 to 32 bit Relnote: | Org: Estimatedhours: 0.0 | Hours: 0 Billable: 1 | Totalhours: 0 Internal: 0 | ------------------------------------------+--------------------------------- Htr: Fix: Env: ------------------------------------------+--------------------------------- Changes (by wagner): * owner: wagner => rbates -- Ticket URL: CM3 Critical Mass Modula3 Compiler From jay.krell at cornell.edu Thu Jul 15 15:39:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 15 Jul 2010 13:39:04 +0000 Subject: [M3devel] branches in changelog? Message-ID: http://www.opencm3.net/ChangeLog-2009 indicates when a file is added to release branch, but not modified. That might help track down..e.g. what happened circa November 21 2009. Thanks, ?- Jay From jay.krell at cornell.edu Thu Jul 15 15:56:55 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 15 Jul 2010 13:56:55 +0000 Subject: [M3devel] minor problems on the release branch In-Reply-To: <20100715144343.qby2zwskgg4kok48@mail.elegosoft.com> References: <20100715144343.qby2zwskgg4kok48@mail.elegosoft.com> Message-ID: I believe the .M3SHIP tests have always failed because they look for Posix paths in the output. You can likely now create correct stdout.pgm-NT386 and they will work. It's not just the slashes, but also libfoo.a vs. foo.lib, foo.exe vs. foo. I think. I vaguely recall noticing that and that the tests not the functionality was broken. To the extent that the tests are looking for "back substitution" to work and don't care about the others, change the slashes, remove the last path element, and declare that correct output? The float<>string conversion worries me some. I wish we had noticed it earlier. At a certain level, it's not a big deal: the resulting strings are certainly "reasonable". But programs could legitimately take a pretty close dependency on the behavior here. Right? ? Until/unless VAX support comes back, in which case we'll probably get varying results. To debug this, a bit tedious, but someone might consider getting the release branch to just before the failure and verifying it works, then just after the failure, verify it doens't work. Then compare the two branches. SOLsun fails for a minor reason: +cc: Warning: -xarch=v8plus is deprecated, use -m32 -xarch=sparc instead I probably just have to redirect it to >/dev/null. I don't just change the config file. The config file works with a range of cc versions and probes their behavior. ? (something we might consider in a more autoconf-sh way, i.e. less often, though it isn't all that often, and ? someone can upgrade their cc at almost any time, so...) Lots to work through.. ?? - Jay ---------------------------------------- > Date: Thu, 15 Jul 2010 14:43:43 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] minor problems on the release branch > > While checking the status of the final 5.8.6 release of CM3, I found > several minor problems, which would benefit from attention nonetheless. > > Investigating these should also be a good starting point for newbies and > others lurking on the list and waiting for something to do: > > Why did this change? > > > http://hudson.modula3.com:8080/view/cm3/job/cm3-test-m3tests-AMD64_LINUX/lastBuild/testReport/(root)/m3tests/p040__binary_____ASCII_conversion_routines > (failing since Build #556 (Apr 29, 2010 9:35:06 PM)) > > same issue: > > > http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-m3tests-I386_OPENBSD/lastBuild/testReport/(root)/m3tests/p040__binary_____ASCII_conversion_routines > (failing since Build #28 (Nov 22, 2009 7:43:34 AM)) > > > http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-m3tests-LINUXLIBC6/lastBuild/testReport/(root)/m3tests/p040__binary_____ASCII_conversion_routines > (failing since Build #276 (Jul 9, 2010 11:40:25 AM)) > > The shipping tests on Nt386 seem to have never worked: > > http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-m3tests-NT386/374/testReport/ > > Test reporting ist still more or less completely broken on SOLsun :-( > > > http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-m3tests-SOLsun/lastBuild > > Failed packages on I386_OPENBSD: > > > http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-all-pkgs-I386_OPENBSD/44/testReport/ > > Failed packages on NT386: > > > http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-all-pkgs-NT386/182/testReport/ > > m3gdb build fails on PPC_LINUX and SPARC32_LINUX: > > > http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-all-pkgs-PPC_LINUX/18/testReport/ > > http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-all-pkgs-SPARC32_LINUX/lastBuild/testReport/ > > Failed package tests on SOLgnu and SOLsun: > > > http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-all-pkgs-SOLgnu/lastBuild/testReport/ > > http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-all-pkgs-SOLsun/lastBuild/testReport/ > > Regards, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Thu Jul 15 17:18:08 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 15 Jul 2010 17:18:08 +0200 Subject: [M3devel] CM3 5.8 RELEASE (5.8.6) Message-ID: <20100715171808.ftd7ycx6tcoog8gk@mail.elegosoft.com> Finally I've declared the last state of the release branch as the final CM3 5.8 release! There have been almost no changes in the recent weeks, and it's unlikely that much improvements will be added if we wait any longer. So I've closed the milestone in trac, and retargeted the remaining 3 or 4 issues to the 5.9 release. https://projects.elego.de/cm3/milestone/CM3%20release%205.8 I've also moved the target date for 5.9 to end of June 2011 ;-) https://projects.elego.de/cm3/milestone/CM3%20Release%205.9 The 5.8 release archives can be downloaded here: http://www.modula3.com/cm3/releng/download.html All related information should be available via that link, too. Some more general information can be found at http://www.modula3.com/cm3/download.html I know this has taken longer than ever before, but we've managed it after all. Thanks to everybody who helped with this release. If you still find bugs, please report them here: https://projects.elego.de/cm3/newticket In the next week, I'll change the Hudson jobs to follow the CVS main trunk again. Best regards, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Jul 16 14:58:42 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 16 Jul 2010 12:58:42 +0000 Subject: [M3devel] $ORIGIN? Message-ID: So I can build a distribution FreeBSD 4.11... But it looks like FreeBSD didn't support $ORIGIN until very recently: 8.0. This is evidenced from two places: http://www.freebsd.org/releases/8.0R/relnotes-detailed.html ? indicates it is new and http://www.freebsd.org/cgi/man.cgi lets you specify version. The ld-elf.so manpage doesn't mention it until 8.0. This means, something like: ? FreeBSD users using < 8.0 will need/want to set LD_LIBRARY_PATH. ? I don't think the distributed binaries have any hardcoded paths in them, except for the $ORIGIN stuff, ?? which I think will just be ignored. "Normally" they do, but the distribution build specifically ?? tries to omit them. This "puts pressure" on considering "this problem" more/again? ? NetBSD < 5.0, FreeBSD < 8.0 ... enough to do something about? ? I've been looking into autoconf and libtool some, but i haven't yet, like.. ? what I'd like to see very clearly is them do the "relink before install" behavior. ? Once confirmed to be there.. maybe our "binary" packages are a bunch of .o files? ? Interesting compromise? ? Or, really, maybe we somewhat give up on "relocatability" and hardcode /usr/local/cm3? ? ?? I realize, official Debian packages need to be at /usr. ? Anyone building from source, can put the files anywhere. ? We can also only "give up" on FreeBSD and/or NetBSD -- where $ORIGIN is more recent introduction. I also seem to recall OSF/1 supports arbitrary environment variables, but doesn't define anything for you like $ORIGIN. Some system is that way. For that can invent custom names and wrapper scripts perhaps. I know, a likely question, it has been asked for, "what is common?" i.e. portable, works the same "everywhere"? ? That would be hardcoded paths, no relocatability. $ORIGIN is very common, but less so. I'm the one who opened this can of worms here. ?The previous -rpath was a mess with lots of directories. That could at least be changed to something short. ? $ORIGIN is indeed very promising and fairly portable, but not perfectly portable nor perfectly "behaved". ? I don't think any solution is perfectly "behaved", there are contradictory goals. ?- Jay From wagner at elegosoft.com Fri Jul 16 15:10:02 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 16 Jul 2010 15:10:02 +0200 Subject: [M3devel] $ORIGIN? In-Reply-To: References: Message-ID: <20100716151002.ygdg5pakxwc0kwwc@mail.elegosoft.com> Quoting Jay K : > So I can build a distribution FreeBSD 4.11... > > But it looks like FreeBSD didn't support $ORIGIN until very recently: 8.0. > > This is evidenced from two places: > > http://www.freebsd.org/releases/8.0R/relnotes-detailed.html > ? indicates it is new > > and http://www.freebsd.org/cgi/man.cgi lets you specify version. > The ld-elf.so manpage doesn't mention it until 8.0. That's correct. Alas, there's no common standard shared by all the systems we support. > This means, something like: > ? FreeBSD users using < 8.0 will need/want to set LD_LIBRARY_PATH. We should document that as a workaround. > ? I don't think the distributed binaries have any hardcoded paths in > them, except for the $ORIGIN stuff, > ?? which I think will just be ignored. "Normally" they do, but the > distribution build specifically > ?? tries to omit them. > This "puts pressure" on considering "this problem" more/again? > ? NetBSD < 5.0, FreeBSD < 8.0 ... enough to do something about? > ? I've been looking into autoconf and libtool some, but i haven't yet, like.. > ? what I'd like to see very clearly is them do the "relink before > install" behavior. > ? Once confirmed to be there.. maybe our "binary" packages are a > bunch of .o files? > ? Interesting compromise? > ? Or, really, maybe we somewhat give up on "relocatability" and > hardcode /usr/local/cm3? > ? ?? I realize, official Debian packages need to be at /usr. > ? Anyone building from source, can put the files anywhere. > ? We can also only "give up" on FreeBSD and/or NetBSD -- where > $ORIGIN is more recent introduction. We should keep that for the time being. > I also seem to recall OSF/1 supports arbitrary environment > variables, but doesn't define anything for you like $ORIGIN. > Some system is that way. > For that can invent custom names and wrapper scripts perhaps. > > I know, a likely question, it has been asked for, "what is common?" > i.e. portable, works the same "everywhere"? > ? That would be hardcoded paths, no relocatability. > $ORIGIN is very common, but less so. > > I'm the one who opened this can of worms here. > ?The previous -rpath was a mess with lots of directories. That could > at least be changed to something short. > ? $ORIGIN is indeed very promising and fairly portable, but not > perfectly portable nor perfectly "behaved". > ? I don't think any solution is perfectly "behaved", there are > contradictory goals. /usr/local/cm3 was the original one standard location when we first published the sources from Critical Mass. But lots of people complained and wanted more flexibility, or rather their platform-specific different standard setups. We haven't got the ressources to fulfill all wishes currently. I'd vote to keep the status quo until someone either has a great idea or implements something better, or we'll keep changing solutions back and forth. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Jul 16 15:47:46 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 16 Jul 2010 13:47:46 +0000 Subject: [M3devel] $ORIGIN? In-Reply-To: <20100716151002.ygdg5pakxwc0kwwc@mail.elegosoft.com> References: , <20100716151002.ygdg5pakxwc0kwwc@mail.elegosoft.com> Message-ID: > We should document that as a workaround. It sort of is, but it is a bit vague. We can fill in specifics: FreeBSD < 8.0 NetBSD < 5.0 (but we don't have NetBSD distributions so..) no problem on Linux, Solaris, MacOSX, NT. Basically, I have to say..I think we might have zero NetBSD users so I thought we were well covered. I didn't realize FreeBSD was late here. That was surprising. > But lots of people complained > and wanted more flexibility, or rather their platform-specific different > standard setups. This is a critical distinction of course. Using /opt/cm3 on Solaris. ? /usr/pkg on NetBSD. ? etc. is trivial. I'm guessing $HOME and $HOME/cm3 are common though too. ?? I keep getting non-root access to machines and using that. :) As well, for a long time, the answer was LD_LIBRARY_PATH, which despite going by a few different names, does seem common. But I'm not sure I prefer it. Obviously you can read all the distaste for it on the web. I'm *guessing* that non-NT users are mostly Linux users, and I'm *guessing* that $ORIGIN has been there a while. Solaris has also had it a while. FreeBSD as I said, not. NetBSD since 5.0 (current). OpenBSD I don't know. Building "static" -- "partly static" also evades this. Except for OpenBSD, "static" is only relative to Modula-3 libraries. But it is overkill, wasteful, bigger, slower. And lots of people don't build the system themselves, right? > We haven't got the resources to fulfill all wishes currently. Hehe. I want world peace and a few million dollars. :) > I'd vote to keep the status quo until someone either has a great idea > or implements something better, or we'll keep changing solutions back > and forth. Ok. I think all the ideas are known here. :) Ultimately I like the idea of generating C, and then using autoconf and libtool to fill in some cracks. But the C backend is a big missing in action piece. I'm largely talk, less action. Time passing helps, people will converge more on systems having $ORIGIN support. ? - Jay ---------------------------------------- > Date: Fri, 16 Jul 2010 15:10:02 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] $ORIGIN? > > Quoting Jay K : > > > So I can build a distribution FreeBSD 4.11... > > > > But it looks like FreeBSD didn't support $ORIGIN until very recently: 8.0. > > > > This is evidenced from two places: > > > > http://www.freebsd.org/releases/8.0R/relnotes-detailed.html > > indicates it is new > > > > and http://www.freebsd.org/cgi/man.cgi lets you specify version. > > The ld-elf.so manpage doesn't mention it until 8.0. > > That's correct. > > Alas, there's no common standard shared by all the systems we support. > > > This means, something like: > > FreeBSD users using < 8.0 will need/want to set LD_LIBRARY_PATH. > > We should document that as a workaround. > > > I don't think the distributed binaries have any hardcoded paths in > > them, except for the $ORIGIN stuff, > > which I think will just be ignored. "Normally" they do, but the > > distribution build specifically > > tries to omit them. > > > This "puts pressure" on considering "this problem" more/again? > > NetBSD < 5.0, FreeBSD < 8.0 ... enough to do something about? > > I've been looking into autoconf and libtool some, but i haven't yet, like.. > > what I'd like to see very clearly is them do the "relink before > > install" behavior. > > Once confirmed to be there.. maybe our "binary" packages are a > > bunch of .o files? > > Interesting compromise? > > Or, really, maybe we somewhat give up on "relocatability" and > > hardcode /usr/local/cm3? > > I realize, official Debian packages need to be at /usr. > > Anyone building from source, can put the files anywhere. > > We can also only "give up" on FreeBSD and/or NetBSD -- where > > $ORIGIN is more recent introduction. > > We should keep that for the time being. > > > I also seem to recall OSF/1 supports arbitrary environment > > variables, but doesn't define anything for you like $ORIGIN. > > Some system is that way. > > For that can invent custom names and wrapper scripts perhaps. > > > > I know, a likely question, it has been asked for, "what is common?" > > i.e. portable, works the same "everywhere"? > > That would be hardcoded paths, no relocatability. > > $ORIGIN is very common, but less so. > > > > I'm the one who opened this can of worms here. > > The previous -rpath was a mess with lots of directories. That could > > at least be changed to something short. > > $ORIGIN is indeed very promising and fairly portable, but not > > perfectly portable nor perfectly "behaved". > > I don't think any solution is perfectly "behaved", there are > > contradictory goals. > > /usr/local/cm3 was the original one standard location when we first > published the sources from Critical Mass. But lots of people complained > and wanted more flexibility, or rather their platform-specific different > standard setups. > > We haven't got the ressources to fulfill all wishes currently. > > I'd vote to keep the status quo until someone either has a great idea > or implements something better, or we'll keep changing solutions back > and forth. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Fri Jul 16 16:16:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 16 Jul 2010 14:16:36 +0000 Subject: [M3devel] FreeBSD 4 Message-ID: Mika already got this working himself, but anyway: http://modula3.elegosoft.com/cm3/uploaded-archives/ => http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-I386_FREEBSD-d5.8.2-FreeBSD4.11-20100715.tar.gz http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-all-I386_FREEBSD-d5.8.2-FreeBSD4.11-20100715.tar.gz They have "no runpath". You must set LD_LIBRARY_PATH. They use userthreads. But FreeBSD4 does have pthreads. Maybe they are adequate. I wasn't able to test gui apps. (Mika did.) System builds itself, so it largely works. ?- Jay From mika at async.async.caltech.edu Fri Jul 16 16:42:43 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Fri, 16 Jul 2010 07:42:43 -0700 Subject: [M3devel] $ORIGIN? In-Reply-To: References: Message-ID: <20100716144243.E10F81A20A7@async.async.caltech.edu> Jay K writes: > >So I can build a distribution FreeBSD 4.11... > > >But it looks like FreeBSD didn't support $ORIGIN until very recently: 8.0. > > >This is evidenced from two places: > > >http://www.freebsd.org/releases/8.0R/relnotes-detailed.html >=A0 indicates it is new > > >and http://www.freebsd.org/cgi/man.cgi lets you specify version. >The ld-elf.so manpage doesn't mention it until 8.0. > > >This means=2C something like: >=A0 FreeBSD users using < 8.0 will need/want to set LD_LIBRARY_PATH. >=A0 I don't think the distributed binaries have any hardcoded paths in them= >=2C except for the $ORIGIN stuff=2C >=A0=A0 which I think will just be ignored. "Normally" they do=2C but the di= >stribution build specifically >=A0=A0 tries to omit them. I have been using Modula-3 on FreeBSD since 2.x and have never needed to set LD_LIBRARY_PATH. And I (almost) always compile outside the /usr/local/... (m3build -O or cm3 -x) Mika From jay.krell at cornell.edu Fri Jul 16 21:19:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 16 Jul 2010 19:19:32 +0000 Subject: [M3devel] $ORIGIN? In-Reply-To: <20100716144243.E10F81A20A7@async.async.caltech.edu> References: , <20100716144243.E10F81A20A7@async.async.caltech.edu> Message-ID: > I have been using Modula-3 on FreeBSD since 2.x and have never needed > to set LD_LIBRARY_PATH. > > And I (almost) always compile outside the /usr/local/... (m3build -O or cm3 -x) If you build it yourself, sure. If I build it for someone else to use and I don't know where they are going to install it, that's when it is needed. ?- Jay ---------------------------------------- > To: jay.krell > CC: m3devel > Subject: Re: [M3devel] $ORIGIN? > Date: Fri, 16 Jul 2010 07:42:43 -0700 > From: mika > ... From jay.krell at cornell.edu Sun Jul 18 03:30:09 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 18 Jul 2010 01:30:09 +0000 Subject: [M3devel] compiler behavior under "low memory"? Message-ID: Mark had a machine with low memory. It has more swap now. Our behavior was: Compiling m3tk would make good progress, complete many files, then fail for ?lack of memory. Manual retry would start over due to ?"missing version information" or such. Thus progress was "impossible". By editing down m3makefile I was able to make progress. ?Some stuff would fail due to missing interfaces, but ?whatever I left in would get the version information saved. ? ? Perhaps we should write out the version information every "few" files? ?For some definition of "few"? 10? 10% of the total? ? ? That would at least let such situations progress via manual retry. ? (unless not even a "few" fit in memory) I also wonder about reducing memory used, or why indeed we run out, ?but that is a thornier problem. You know, all we should need to ?continue forward progress is to hold all interfaces in memory and ?one implementation at a time. Now, there are a few unknowns here. ?It is possible Mark's machine didn't have enough memory for ?all the relevant interfaces, and that we only "load" them on-demand. ? ?It is also likely, I should add, that virtual address space is the ? problem, not working set. Some systems want to commit room ? in swap for all allocated virtual memory, like, to be sure ? ahead of time that everything can be paged out so other ? code can progress. Something like that. I'm not sure here. ? That is, I suspect we don't care. Virtual address space is probably ? reasonable to deem cheap. No problem using almost 2GB of address space ? as long as working set isn't that large (ie: to fit in 31bit address space). ? If some OSes don't see it that way, oh well. This might just ? be a design/policy thing in Tru64. ? ? (I'm well aware of virtual memory vs. physical memory vs. working set. But for whatever reason, we were failing due to memory use. All that *should* matter is that address space usage stays within around 2GB and that working set isn't huge. Working set I've recently come to understand can be managed like so: ? - random access over set of memory that fits in physical memory ? - sequential access over arbitrary memory (up to 2GB) ? - hybrid of previous ????? ie. sequential accesses over multiple separate areas As long as access is sequential, you shouldn't "thrash". It is only random access over data that doesn't fit in physical memory ?that causes thrashing.) ?- Jay From jay.krell at cornell.edu Sun Jul 18 03:34:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 18 Jul 2010 01:34:14 +0000 Subject: [M3devel] multithreaded compiler? Message-ID: It should be reasonably easy to have the gcc backend run on multiple separate threads. ?- Jay From dabenavidesd at yahoo.es Sun Jul 18 05:28:54 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 18 Jul 2010 03:28:54 +0000 (GMT) Subject: [M3devel] compiler behavior under "low memory"? In-Reply-To: Message-ID: <583206.38293.qm@web23608.mail.ird.yahoo.com> Hi: If it only had such small memory requirements I suppose less than 64 MB RAM I didn't get the number of interfaces is about the same (probably a 10 % larger by now with new added packages), probably the best way forward is not just to change the swap memory as its a common sense to double the RAM but in that case you would need such a thing for one process less the rest of operating system, i.e solution is not general, If I understand well Mark 's Alpha DEC machine had the same machine and probably with M3 running in top of it in 1995. I wonder how these years have expanded the compilers proficiency (as time is against space and vice-versa, that is, less time is more memory like to make a recursive program to unfold in a sequential one) in such a memory constrained environments could be solved I can remember now that there was a change in Amer Diwan Whole program optimizer to grab in a pickled AST to later unpickle it and compile to M3CG-machine assembly optimized see: http://www.modula3.org/threads/1/#advanced and also a proposed or to-do of DEC-SRC M3 days about Cache policy it mentioned see: http://www.cs.arizona.edu/~collberg/Research/Modula-3/modula-3/html/todo.html AST cache policy. The current driver keeps an in-memory cache of compiled interfaces, but never flushes entries, this refers to the simple problem of big heap which another application generated out of memory back in those days the ESC/Modula-3 checker available for Alphas see: http://web.archive.org/web/20030704143617/http://research.compaq.com/SRC/esc/escm3/bin/Esc.alpha.bin.Z (which was user of Simplify theorem prover http://portal.acm.org/citation.cfm?id=1066100.1066102 or doi:0.1145/1066100.1066102 as it should be cited and also used m3tk toolkit ) and they managed to solve by means of calling the collector to scan and throw away the uncollected things at least in Simplify, years later I retired the line with no problem in Simplify and all run in good benchmarks tests of Simplify with no problems see too http://qpq.csl.sri.com/downloads/simplify_benchmarks-tar.gz/view The result was that they created a tool to understand where the memory heap was being actually ran out of memory and they manage to solve I believe by managing the same way besides clearing stuff not needed something is useful in any garbage collected type language http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.49.3474&rep=rep1&type=pdf see slides onhttp://labs.oracle.com/people/detlefs/papers/detlefs-coots95-slides.ps and extra figures http://labs.oracle.com/people/detlefs/papers/detlefs-coots95-slides2.ps In our case in that case as it can't throw away AST representations before M3CG-machine tough there is separate compilation we don't manage to type check all m3tk in runtime eliminating when is compiled and not used code generation currently the problem might be solved in the compilation server written for pm3 (see: http://arxiv.org/pdf/cs/0506035 ) or as Amer Diwan solved to manage for his particular purposes (see ftp://ftp.cs.umass.edu/pub/osl/papers/diwan-dissertation.ps.gz) because in any case of low resources limits it would be stored pickled or in swaped memory in the disc but in non-low memory limits it would be in both memory and disk as it is now (at some point you need to bring from copy from disk the needed bytes back to memory). Besides that the implemented behavior on VM exhaustion should be not taken in false as guys didn't in those days http://modula3.elegosoft.com/pm3/intro/questions/new.html An implemented solution but actually not used not seen here: http://web.archive.org/web/19980613063641/www.vlsi.polymtl.ca/m3/pkg/contrib/whenNEWfails/.ghindex.html Thanks for any corrections in advance if so --- El s?b, 17/7/10, Jay K escribi?: > De: Jay K > Asunto: [M3devel] compiler behavior under "low memory"? > Para: "m3devel" > Fecha: s?bado, 17 de julio, 2010 20:30 > > Mark had a machine with low memory. > It has more swap now. > > > Our behavior was: > > > Compiling m3tk would make good progress, complete many > files, then fail for > lack of memory. > > > Manual retry would start over due to > "missing version information" or such. > > > Thus progress was "impossible". > By editing down m3makefile I was able to make progress. > Some stuff would fail due to missing interfaces, but > whatever I left in would get the version information > saved. > > > Perhaps we should write out the version information every > "few" files? > For some definition of "few"? 10? 10% of the total? > > > That would at least let such situations progress via manual > retry. > (unless not even a "few" fit in memory) > > > I also wonder about reducing memory used, or why indeed we > run out, > but that is a thornier problem. You know, all we should > need to > continue forward progress is to hold all interfaces in > memory and > one implementation at a time. Now, there are a few > unknowns here. > It is possible Mark's machine didn't have enough memory > for > all the relevant interfaces, and that we only "load" them > on-demand. > > > It is also likely, I should add, that virtual address > space is the > problem, not working set. Some systems want to commit > room > in swap for all allocated virtual memory, like, to be > sure > ahead of time that everything can be paged out so other > code can progress. Something like that. I'm not sure > here. > That is, I suspect we don't care. Virtual address space > is probably > reasonable to deem cheap. No problem using almost 2GB of > address space > as long as working set isn't that large (ie: to fit in > 31bit address space). > If some OSes don't see it that way, oh well. This might > just > be a design/policy thing in Tru64. > > > (I'm well aware of virtual memory vs. physical memory vs. > working set. > But for whatever reason, we were failing due to memory > use. > All that *should* matter is that address space usage stays > within > around 2GB and that working set isn't huge. Working set > I've recently > come to understand can be managed like so: > - random access over set of memory that fits in physical > memory > - sequential access over arbitrary memory (up to 2GB) > - hybrid of previous > ie. sequential accesses over multiple separate > areas > > As long as access is sequential, you shouldn't "thrash". > It is only random access over data that doesn't fit in > physical memory > that causes thrashing.) > > > - Jay > > > > From jay.krell at cornell.edu Sun Jul 18 06:02:46 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 18 Jul 2010 04:02:46 +0000 Subject: [M3devel] compiler behavior under "low memory"? In-Reply-To: <583206.38293.qm@web23608.mail.ird.yahoo.com> References: , <583206.38293.qm@web23608.mail.ird.yahoo.com> Message-ID: Daniel I have a hard time understanding you. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.49.3474&rep=rep1&type=pdf Is interesting though. We should make sure that stuff still works, and fix it if not. i.e. the heap debugging tools embedded in the runtime (shownew, etc.) ?- Jay ---------------------------------------- > Date: Sun, 18 Jul 2010 03:28:54 +0000 > From: dabenavidesd at yahoo.es > To: m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] compiler behavior under "low memory"? > > Hi: > If it only had such small memory requirements I suppose less than 64 MB RAM I didn't get the number of interfaces is about the same (probably a 10 % larger by now with new added packages), probably the best way forward is not just to change the swap memory as its a common sense to double the RAM but in that case you would need such a thing for one process less the rest of operating system, i.e solution is not general, If I understand well Mark 's Alpha DEC machine had the same machine and probably with M3 running in top of it in 1995. I wonder how these years have expanded the compilers proficiency (as time is against space and vice-versa, that is, less time is more memory like to make a recursive program to unfold in a sequential one) in such a memory constrained environments could be solved I can remember now that there was a change in Amer Diwan Whole program optimizer to grab in a pickled AST to later unpickle it and compile to M3CG-machine assembly > optimized see: > http://www.modula3.org/threads/1/#advanced > and also a proposed or to-do of DEC-SRC M3 days about Cache policy it mentioned see: > http://www.cs.arizona.edu/~collberg/Research/Modula-3/modula-3/html/todo.html > AST cache policy. The current driver keeps an in-memory cache of compiled interfaces, but never flushes entries, this refers to the simple problem of big heap which another application generated out of memory back in those days the ESC/Modula-3 checker available for Alphas see: > http://web.archive.org/web/20030704143617/http://research.compaq.com/SRC/esc/escm3/bin/Esc.alpha.bin.Z (which was user of Simplify theorem prover http://portal.acm.org/citation.cfm?id=1066100.1066102 > or doi:0.1145/1066100.1066102 as it should be cited and also used m3tk toolkit ) and they managed to solve by means of calling the collector to scan and throw away the uncollected things at least in Simplify, years later I retired the line with no problem in Simplify and all run in good benchmarks tests of Simplify with no problems see too http://qpq.csl.sri.com/downloads/simplify_benchmarks-tar.gz/view > The result was that they created a tool to understand where the memory heap was being actually ran out of memory and they manage to solve I believe by managing the same way besides clearing stuff not needed something is useful in any garbage collected type language http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.49.3474&rep=rep1&type=pdf > see slides onhttp://labs.oracle.com/people/detlefs/papers/detlefs-coots95-slides.ps and extra figures http://labs.oracle.com/people/detlefs/papers/detlefs-coots95-slides2.ps > In our case in that case as it can't throw away AST representations before M3CG-machine tough there is separate compilation we don't manage to type check all m3tk in runtime eliminating when is compiled and not used code generation currently the problem might be solved in the compilation server written for pm3 (see: > http://arxiv.org/pdf/cs/0506035 ) > or as Amer Diwan solved to manage for his particular purposes (see ftp://ftp.cs.umass.edu/pub/osl/papers/diwan-dissertation.ps.gz) because in any case of low resources limits it would be stored pickled or in swaped memory in the disc but in non-low memory limits it would be in both memory and disk as it is now (at some point you need to bring from copy from disk the needed bytes back to memory). > Besides that the implemented behavior on VM exhaustion should be not taken in false as guys didn't in those days > http://modula3.elegosoft.com/pm3/intro/questions/new.html > An implemented solution but actually not used not seen here: > > http://web.archive.org/web/19980613063641/www.vlsi.polymtl.ca/m3/pkg/contrib/whenNEWfails/.ghindex.html > > Thanks for any corrections in advance if so > > > > > > --- El s?b, 17/7/10, Jay K escribi?: > > > De: Jay K > > Asunto: [M3devel] compiler behavior under "low memory"? > > Para: "m3devel" > > Fecha: s?bado, 17 de julio, 2010 20:30 > > > > Mark had a machine with low memory. > > It has more swap now. > > > > > > Our behavior was: > > > > > > Compiling m3tk would make good progress, complete many > > files, then fail for > > lack of memory. > > > > > > Manual retry would start over due to > > "missing version information" or such. > > > > > > Thus progress was "impossible". > > By editing down m3makefile I was able to make progress. > > Some stuff would fail due to missing interfaces, but > > whatever I left in would get the version information > > saved. > > > > > > Perhaps we should write out the version information every > > "few" files? > > For some definition of "few"? 10? 10% of the total? > > > > > > That would at least let such situations progress via manual > > retry. > > (unless not even a "few" fit in memory) > > > > > > I also wonder about reducing memory used, or why indeed we > > run out, > > but that is a thornier problem. You know, all we should > > need to > > continue forward progress is to hold all interfaces in > > memory and > > one implementation at a time. Now, there are a few > > unknowns here. > > It is possible Mark's machine didn't have enough memory > > for > > all the relevant interfaces, and that we only "load" them > > on-demand. > > > > > > It is also likely, I should add, that virtual address > > space is the > > problem, not working set. Some systems want to commit > > room > > in swap for all allocated virtual memory, like, to be > > sure > > ahead of time that everything can be paged out so other > > code can progress. Something like that. I'm not sure > > here. > > That is, I suspect we don't care. Virtual address space > > is probably > > reasonable to deem cheap. No problem using almost 2GB of > > address space > > as long as working set isn't that large (ie: to fit in > > 31bit address space). > > If some OSes don't see it that way, oh well. This might > > just > > be a design/policy thing in Tru64. > > > > > > (I'm well aware of virtual memory vs. physical memory vs. > > working set. > > But for whatever reason, we were failing due to memory > > use. > > All that *should* matter is that address space usage stays > > within > > around 2GB and that working set isn't huge. Working set > > I've recently > > come to understand can be managed like so: > > - random access over set of memory that fits in physical > > memory > > - sequential access over arbitrary memory (up to 2GB) > > - hybrid of previous > > ie. sequential accesses over multiple separate > > areas > > > > As long as access is sequential, you shouldn't "thrash". > > It is only random access over data that doesn't fit in > > physical memory > > that causes thrashing.) > > > > > > - Jay > > > > > > > > > > > > From jay.krell at cornell.edu Sun Jul 18 08:36:45 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 18 Jul 2010 06:36:45 +0000 Subject: [M3devel] Modula-3 condition variables vs. pthread/Win32 condition variables? Message-ID: I was thinking of writing "ThreadWin6.m3". We'd check GetVersion and if it is >= 6.0, use it instead. This would give us: ? smaller locks ? condition variables ? likely isomorphic code with ThreadPThread.m3 Question, probably a repeat: (I'll check the archives) ? Why aren't Modula-3 condition variables a thinner wrapper over pthread condition variables? One difference I see is alert. Can't alert just signal the condition being waited on? Might need interlocked operations against alertable and alerted, and maybe also thread.cond? ? (Should be viable, even within one word, use the lower two bits of thread.cond?) ? ?- Jay From jay.krell at cornell.edu Sun Jul 18 14:00:05 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 18 Jul 2010 12:00:05 +0000 Subject: [M3devel] moving to new target names, in Hudson? Message-ID: Olaf, can I request that if/when you move Hudson to head, that you also switch to I386_LINUX, I386_FREEBSD, I386_NT, and whatever we decide for SPARC32_SOLARIS? I've mostly switched to them myself. It wasn't difficult. (I always say that). I think for SPARC32_SOLARIS we should either have SPARC32_SOLARIS that is the equivalent of today's SOLsun. Effectively dropping SOLgnu. Or we also add SPARC32_SOLARIS_gcc, which is just a configuration file and not a target. This is like the "experiment" I did with NT386/NT386GNU, which I think I regret, except SPARC32_SOLARIS / SPARC32_SOLAROS_gcc are far far more similar than those. All their platform-specific code is identical. Their backend is identical. etc. A related option is SPARC32_SOLARIS_cc or SPARC32_SOLARIS_suncc, and SPARC32_SOLARIS_gcc. Config files. But the compiler only know about SPARC32_SOLARIS. Just putting the two config files more as peers, so to speak. The way I switched targets was probably doing a cross build. That is overkill. You can probably just export CM3_TARGET to the name you want. And maybe fiddle with shipping of cm3cg or settings its build_dir -- i.e. leave it as just host and host-target. Thanks, ?- Jay From jay.krell at cornell.edu Sun Jul 18 14:44:25 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 18 Jul 2010 12:44:25 +0000 Subject: [M3devel] div/mod Message-ID: ok, this is a really minor thing. Very esoteric, waste of time probably. Div and mod are defined in terms of each other. In the "real world", any integer mod negative 1 is 0. ? All integers are "evenly divisible" by 1 and negative 1. So INT_MIN mod -1 is 0. One can code that to be the case. Some versions of the code do. ? I'm not sure about the current code, as we don't call the C functions any longer, except for int64 on NT386. ? The older div/mod helpers, depending on optimization, would either return 0 ?? or generate an overflow exception. In our computer world, INT_MIN div -1 is not computable, and generates ? the same exception. Even with current code. If div and mod are defined in terms of each other, and one of them is not computable, ? is it wrong to be able to compute the other? ?- Jay From jay.krell at cornell.edu Sun Jul 18 15:35:51 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 18 Jul 2010 13:35:51 +0000 Subject: [M3devel] Alpha/OSF exception handling Message-ID: Modula-3 for ALPHA_OSF historically had the best exception handling implementation. With Solaris/sparc32 second best. And then everything else equally bad. The current Alpha/osf is now in the "equally bad" category. Because I'm lazy. It might be worth restoring its former glory. Maybe a small project for someone? The code is still in there. I just tweaked the m3makefiles to avoid trying it. jbook2:runtime jay$ pwd /dev2/cm3/m3-libs/m3core/src/runtime jbook2:runtime jay$ find ALPHA_OSF ALPHA_OSF/m3makefile-old Renaming that m3makefile. Fiddling with this: book2:runtime jay$ grep STACK * m3makefile:readonly HAS_STACK_WALKER = { m3makefile:if defined("M3_USE_STACK_WALKER") m3makefile:? if M3_USE_STACK_WALKER and HAS_STACK_WALKER contains TARGET m3makefile:??? if HAS_STACK_WALKER{TARGET} and this: jbook2:src jay$ pwd /dev2/cm3/m3-sys/m3middle/src book2:src jay$ grep -i _stack *m3 Target.m3:??? Has_stack_walker????????? := FALSE; Target.m3:???????????????? Has_stack_walker := TRUE; ?- Jay From wagner at elegosoft.com Sun Jul 18 16:55:13 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 18 Jul 2010 16:55:13 +0200 Subject: [M3devel] Hudson regression for current cm3 / incompatibilities Message-ID: <20100718165513.gug2fuk04k8cww0o@mail.elegosoft.com> I've disabled the existing cm3 build and test jobs on Hudson and copied them to new ones all named cm3-current-*; I've also added a new view cm3-current that is now displayed by default. The now disabled jobs may be used again for the next release. However, already some incompatibilities seen to habe crept in. Neither the m3cc nor the build jobs succeed; i.e. the current sources cannot be built with the latest release version, even with the upgrade script. This should be fixed. Please have a look at http://hudson.modula3.com:8080/ When everything looks good again, I'll start to rename some of the jobs to new platform names as Jay requested (if we can all agree on them). However, this will take some more time and a better connection than that I currently have here from my mobile notebook. And now for something completely different again (it's weekend after all), Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Jul 18 17:04:26 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 18 Jul 2010 17:04:26 +0200 Subject: [M3devel] moving to new target names, in Hudson? In-Reply-To: References: Message-ID: <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com> Quoting Jay K : > Olaf, can I request that if/when you move Hudson to head, that you > also switch to I386_LINUX, I386_FREEBSD, I386_NT, > and whatever we decide for SPARC32_SOLARIS? > I've mostly switched to them myself. It wasn't difficult. (I always > say that). It will require a lot of manual work, compared to the more or less automated transition I just made from release to current for all the jobs. The target platform names are part of the jobs, and are also used in various places in the build scripts, so that many things are likely to break. My guess is that it will take some days for every target move given my current attention pattern for cm3, i.e. have a look at how things work out now and then between other work. Let's wait until all the jobs work again with their old target names, Olaf > I think for SPARC32_SOLARIS we should either have SPARC32_SOLARIS > that is the equivalent of today's SOLsun. > Effectively dropping SOLgnu. > > > Or we also add SPARC32_SOLARIS_gcc, which is just a configuration > file and not a target. > This is like the "experiment" I did with NT386/NT386GNU, which I > think I regret, except > SPARC32_SOLARIS / SPARC32_SOLAROS_gcc are far far more similar than those. > All their platform-specific code is identical. Their backend is > identical. etc. > > > A related option is SPARC32_SOLARIS_cc or SPARC32_SOLARIS_suncc, and > SPARC32_SOLARIS_gcc. > Config files. > But the compiler only know about SPARC32_SOLARIS. > Just putting the two config files more as peers, so to speak. > > > The way I switched targets was probably doing a cross build. > That is overkill. You can probably just export CM3_TARGET to the > name you want. > And maybe fiddle with shipping of cm3cg or settings its build_dir -- > i.e. leave it as just host and host-target. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sun Jul 18 18:16:15 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 18 Jul 2010 16:16:15 +0000 Subject: [M3devel] Hudson regression for current cm3 / incompatibilities In-Reply-To: <20100718165513.gug2fuk04k8cww0o@mail.elegosoft.com> References: <20100718165513.gug2fuk04k8cww0o@mail.elegosoft.com> Message-ID: This is great Olaf, having this already going, no matter the target names. I'll watch it. Thanks, ?- Jay ---------------------------------------- > Date: Sun, 18 Jul 2010 16:55:13 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] Hudson regression for current cm3 / incompatibilities > > I've disabled the existing cm3 build and test jobs on Hudson and copied > them to new ones all named cm3-current-*; I've also added a new view > cm3-current that is now displayed by default. > The now disabled jobs may be used again for the next release. > > However, already some incompatibilities seen to habe crept in. > Neither the m3cc nor the build jobs succeed; i.e. the current sources > cannot be built with the latest release version, even with the > upgrade script. > > This should be fixed. > > Please have a look at > > http://hudson.modula3.com:8080/ > > When everything looks good again, I'll start to rename some of the > jobs to new platform names as Jay requested (if we can all agree on them). > However, this will take some more time and a better connection than that > I currently have here from my mobile notebook. > > And now for something completely different again (it's weekend after all), > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Sun Jul 18 18:25:35 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 18 Jul 2010 16:25:35 +0000 Subject: [M3devel] CM3 on Alpha tru64 4.0G In-Reply-To: References: , , ,,, ,,,,, , <9241B253-8004-4DDD-B1EF-A7D02A3FEAFD@cs.purdue.edu>, ,,, ,,<76827F66-451E-410E-9AF0-200D9538AFA1@cs.purdue.edu>, ,,<1279048755.1793.13.camel@x60.appsoftint.co.uk>, ,,<8E02058D-1A62-48FF-8DA7-B2C40C53B048@cs.purdue.edu>, , , <1279053628.1793.15.camel@x60.appsoftint.co.uk>, , , Message-ID: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-all-ALPHA_OSF-d5.8.2-OSF1V4.0-20100718.tar.gz http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-ALPHA_OSF-d5.8.2-OSF1V4.0-20100718.tar.gz System built itself natively on Mark's machine. Using pthreads. But no stack walker (I'm lazy and didn't even try it). Mark reports some GUI apps working. Would be cool to get this in Hudson but I think the current machines have too old Java. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: mark at wickensonline.co.uk; hosking at cs.purdue.edu > Date: Tue, 13 Jul 2010 23:27:51 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] CM3 on Alpha tru64 4.0G > > > > Things to try: cross build, user threads. > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-ALPHA_OSF-pthreads-d5.8.2-20100713.tgz > or > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-ALPHA_OSF-userthreads-d5.8.2-20100713.tgz > > ? > > And in userthreads, if there is no get/set/make/swapcontext, you can change the #if at the top of ThreadPosixC.c to try sigaltstack. > Also the userthreads Makefile has -lpthread in it, which you'll maybe want to remove...depending on if there is pthread_atfork, i.e. you might want to tweak this: > jbook2:cm3-boot-ALPHA_OSF-d5.8.2-20100713 jay$ grep pthread_atfork *c > RTProcessC.c: int i = pthread_atfork(prepare, parent, child); > > > but try the pthread version first? > > These will give you a cm3 and if it prints "unable to find cm3.cfg", good. > > Tru64 4.x isn't officially supported by gcc any longer, but I noticed recent test results posted anyway. > You just have to configure -enable-obsolete or somesuch. > > Can you give me ssh access? That's a good and bad thing. Should be doable without such direct help by me.. > > - Jay > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: mark at wickensonline.co.uk; hosking at cs.purdue.edu > > Date: Tue, 13 Jul 2010 23:04:20 +0000 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] CM3 on Alpha tru64 4.0G > > > > > > Things to try: cross build, user threads. > > Do you have a "modern" system with a working cm3? > > Do you have cvs and a working C compiler/linker on this older system? > > > > - Jay > > > > ---------------------------------------- > > > From: mark at wickensonline.co.uk > > > To: hosking at cs.purdue.edu > > > Date: Tue, 13 Jul 2010 21:40:28 +0100 > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] CM3 on Alpha tru64 4.0G > > > > > > Hi Tony, the exception I get is as follows: > > > > > > >From cm3-min-ALPHA_OSF-d5.8.2-20100612/bin > > > > > > bash-3.2$ ./cm3 > > > %DECthreads bugcheck (version V3.18-037), terminating execution. > > > % Reason: stkGet: (4) nxm_stack_create (0,5251072,16384,8192) > > > % Running on OSF1 V4.0(1530) on AlphaServer 300 4/266, 256Mb; 1 CPUs, > > > pid 21360 > > > > > > > > > From hosking at cs.purdue.edu Sun Jul 18 20:21:32 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 18 Jul 2010 14:21:32 -0400 Subject: [M3devel] Modula-3 condition variables vs. pthread/Win32 condition variables? In-Reply-To: References: Message-ID: <1908F6C1-08D0-46FE-89DE-D0B5BDEBDC59@cs.purdue.edu> On 18 Jul 2010, at 02:36, Jay K wrote: > > I was thinking of writing "ThreadWin6.m3". > We'd check GetVersion and if it is >= 6.0, use it instead. > This would give us: > smaller locks > condition variables > likely isomorphic code with ThreadPThread.m3 > > > Question, probably a repeat: (I'll check the archives) > Why aren't Modula-3 condition variables a thinner wrapper over pthread condition variables? Because there is no reliable way to alert a thread waiting on a condition variable. And we need a uniform way to handshake with a thread for GC, etc. Better just to build on the per-thread CV. > One difference I see is alert. Can't alert just signal the condition being waited on? > > > Might need interlocked operations against alertable and alerted, and maybe also thread.cond? > (Should be viable, even within one word, use the lower two bits of thread.cond?) Again, probably not a good idea going forward -- we will ultimately build M3 mutex/CV with non-blocking primitives where possible and inflate to pthread mutex only rarely. > > ? > > > - Jay > > > > > From hosking at cs.purdue.edu Sun Jul 18 20:22:41 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 18 Jul 2010 14:22:41 -0400 Subject: [M3devel] Alpha/OSF exception handling In-Reply-To: References: Message-ID: That is a huge shame. Why did you remove it? It used to be there and functional. On 18 Jul 2010, at 09:35, Jay K wrote: > > Modula-3 for ALPHA_OSF historically had the best exception handling implementation. > > With Solaris/sparc32 second best. > > And then everything else equally bad. > > > > > > The current Alpha/osf is now in the "equally bad" category. > Because I'm lazy. > > It might be worth restoring its former glory. > > > > Maybe a small project for someone? > > > The code is still in there. I just tweaked the m3makefiles to avoid trying it. > > > jbook2:runtime jay$ pwd > /dev2/cm3/m3-libs/m3core/src/runtime > jbook2:runtime jay$ find ALPHA_OSF > ALPHA_OSF/m3makefile-old > > Renaming that m3makefile. > > Fiddling with this: > > book2:runtime jay$ grep STACK * > m3makefile:readonly HAS_STACK_WALKER = { > m3makefile:if defined("M3_USE_STACK_WALKER") > m3makefile: if M3_USE_STACK_WALKER and HAS_STACK_WALKER contains TARGET > m3makefile: if HAS_STACK_WALKER{TARGET} > > > and this: > > > jbook2:src jay$ pwd > /dev2/cm3/m3-sys/m3middle/src > > > book2:src jay$ grep -i _stack *m3 > Target.m3: Has_stack_walker := FALSE; > Target.m3: Has_stack_walker := TRUE; > > > - Jay > From rodney_bates at lcwb.coop Mon Jul 19 00:41:43 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 18 Jul 2010 17:41:43 -0500 Subject: [M3devel] div/mod In-Reply-To: References: Message-ID: <4C438327.1070907@lcwb.coop> Jay K wrote: > ok, this is a really minor thing. Very esoteric, waste of time probably. > > > Div and mod are defined in terms of each other. > > > In the "real world", any integer mod negative 1 is 0. > All integers are "evenly divisible" by 1 and negative 1. > > So INT_MIN mod -1 is 0. > > > One can code that to be the case. Some versions of the code do. > I'm not sure about the current code, as we don't call the C functions any longer, except for int64 on NT386. > The older div/mod helpers, depending on optimization, would either return 0 > or generate an overflow exception. > > > In our computer world, INT_MIN div -1 is not computable, and generates > the same exception. Even with current code. My view of this is that the only reason INT_MIN DIV -1 raises an exception is that the mathematical result is not in INTEGER. The definitions of all the arithmetic operators in the language should be viewed as using the (unlimited range) operations of mathematics, with overflow happening if this lies outside the range of the result type. In fact, I doubt you can sensibly interpret the definitions in the language any other way. So it makes perfect sense for the DIV to raise the exception and the MOD not, since 0 is indeed in INTEGER. > > > If div and mod are defined in terms of each other, and one of them is not computable, > is it wrong to be able to compute the other? > > > - Jay > > From jay.krell at cornell.edu Mon Jul 19 02:16:46 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Jul 2010 00:16:46 +0000 Subject: [M3devel] Hudson regression for current cm3 / incompatibilities In-Reply-To: References: <20100718165513.gug2fuk04k8cww0o@mail.elegosoft.com>, Message-ID: Things are better now. Several jobs have succeeded. e.g. lots of I386_DARWIN, AMD64_LINUX, LINUXLIBC. Not all platforms have tried anything though. I just kicked some. e.g. SOLgnu. Not all platforms have new jobs. e.g. AMD64_DARWIN, NT386, SOLsun, PPC_DARWIN, PPC_LINUX, I386_OPENBSD. SPARC32_LINUX is still broken for reasons specific to it or at least sparc-specific. I'll look at it. cm3-current-build-FreeBSD4 seems hung. Thanks, ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Subject: RE: [M3devel] Hudson regression for current cm3 / incompatibilities > Date: Sun, 18 Jul 2010 16:16:15 +0000 > > > This is great Olaf, having this already going, no matter the target names. > I'll watch it. > > Thanks, > - Jay > > ---------------------------------------- > > Date: Sun, 18 Jul 2010 16:55:13 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: [M3devel] Hudson regression for current cm3 / incompatibilities > > > > I've disabled the existing cm3 build and test jobs on Hudson and copied > > them to new ones all named cm3-current-*; I've also added a new view > > cm3-current that is now displayed by default. > > The now disabled jobs may be used again for the next release. > > > > However, already some incompatibilities seen to habe crept in. > > Neither the m3cc nor the build jobs succeed; i.e. the current sources > > cannot be built with the latest release version, even with the > > upgrade script. > > > > This should be fixed. > > > > Please have a look at > > > > http://hudson.modula3.com:8080/ > > > > When everything looks good again, I'll start to rename some of the > > jobs to new platform names as Jay requested (if we can all agree on them). > > However, this will take some more time and a better connection than that > > I currently have here from my mobile notebook. > > > > And now for something completely different again (it's weekend after all), > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > > From jay.krell at cornell.edu Mon Jul 19 02:20:05 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Jul 2010 00:20:05 +0000 Subject: [M3devel] Hudson regression for current cm3 / incompatibilities In-Reply-To: References: <20100718165513.gug2fuk04k8cww0o@mail.elegosoft.com>, , , Message-ID: Oops. I was looking at the platform views instead of the cm3-current view. Things are better and worse than I said. More jobs exist, more jobs have succeeded, more jobs have also failed (that exist!) and I need to look at, e.g. PPC_DARWIN. I understand the PPC_DARWIN problem already -- related to building on older platform and my forcing autoconf to believe features are there. I know what to do. Thanks, ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Date: Mon, 19 Jul 2010 00:16:46 +0000 > Subject: Re: [M3devel] Hudson regression for current cm3 / incompatibilities > > > Things are better now. Several jobs have succeeded. e.g. lots of I386_DARWIN, AMD64_LINUX, LINUXLIBC. > Not all platforms have tried anything though. I just kicked some. e.g. SOLgnu. > Not all platforms have new jobs. e.g. AMD64_DARWIN, NT386, SOLsun, PPC_DARWIN, PPC_LINUX, I386_OPENBSD. > SPARC32_LINUX is still broken for reasons specific to it or at least sparc-specific. I'll look at it. > cm3-current-build-FreeBSD4 seems hung. > > Thanks, > - Jay > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com; m3devel at elegosoft.com > > Subject: RE: [M3devel] Hudson regression for current cm3 / incompatibilities > > Date: Sun, 18 Jul 2010 16:16:15 +0000 > > > > > > This is great Olaf, having this already going, no matter the target names. > > I'll watch it. > > > > Thanks, > > - Jay > > > > ---------------------------------------- > > > Date: Sun, 18 Jul 2010 16:55:13 +0200 > > > From: wagner at elegosoft.com > > > To: m3devel at elegosoft.com > > > Subject: [M3devel] Hudson regression for current cm3 / incompatibilities > > > > > > I've disabled the existing cm3 build and test jobs on Hudson and copied > > > them to new ones all named cm3-current-*; I've also added a new view > > > cm3-current that is now displayed by default. > > > The now disabled jobs may be used again for the next release. > > > > > > However, already some incompatibilities seen to habe crept in. > > > Neither the m3cc nor the build jobs succeed; i.e. the current sources > > > cannot be built with the latest release version, even with the > > > upgrade script. > > > > > > This should be fixed. > > > > > > Please have a look at > > > > > > http://hudson.modula3.com:8080/ > > > > > > When everything looks good again, I'll start to rename some of the > > > jobs to new platform names as Jay requested (if we can all agree on them). > > > However, this will take some more time and a better connection than that > > > I currently have here from my mobile notebook. > > > > > > And now for something completely different again (it's weekend after all), > > > > > > Olaf > > > -- > > > Olaf Wagner -- elego Software Solutions GmbH > > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > > > > > From jay.krell at cornell.edu Mon Jul 19 03:33:05 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Jul 2010 01:33:05 +0000 Subject: [M3devel] Hudson m3cc clean? In-Reply-To: <20100719012318.ABC2E2474003@birch.elegosoft.com> References: <20100719012318.ABC2E2474003@birch.elegosoft.com> Message-ID: Olaf, the m3cc tasks should run "clean" with this -- configure needs to rerun. It seems some have such a check mark option, some do not. Platforms that are succeeding I guess can be left alone, but the ppc/sparc ones.. The ones on my machines I can fiddle with, but PPC_DARWIN.. Thanks, ?- Jay ---------------------------------------- > Date: Mon, 19 Jul 2010 03:23:16 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/07/19 03:23:16 > > Modified files: > cm3/m3-sys/m3cc/src/: m3makefile > cm3/m3-sys/m3cc/gcc/gcc/config/: darwin.h > > Log message: > m3makefile, basically undo: > Revision 1.162 > always specify -build, -host, -target, for cross and native > consistent but experimenta/unorthodox > Usually people let config.guess do all the work for native > and always for build. > Default build to host, not target. > > Revision 1.161 > Always specify -target. > in native builds, always specify -build and -host. > This should provide for more consistency, > though is also a bit experimental and unorthodox. > > darwin.h, undo > Revision 1.2 > always support hidden aka private extern aka don't export every function > > This should fix PPC_DARWIN and maybe maybe others (SPARC32_LINUX). > > Possibly relatd, I've noticed SOLsun using sparc-sun-solaris2.10-gcc > to build cm3cg, when I was hoping it'd use Sun cc. This will > at least change it to plain gcc, but same thing. > From jay.krell at cornell.edu Mon Jul 19 05:53:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Jul 2010 03:53:08 +0000 Subject: [M3devel] Hudson m3cc clean? In-Reply-To: References: <20100719012318.ABC2E2474003@birch.elegosoft.com>, Message-ID: They should probably all be clean. Given also the merge to 4.3.5. And that I put back dependency tracking. I think I'll put something in m3cc/src/m3makefile with a timestamp or guid, checked in by developer, copied to an output file in build_dir, and if they vary, delete everything. So checking in a deliberate edit to m3cc/src/m3makefile will trigger clean. In the mean time did *some* ssh root@ ; cd ~hudson; rm -rf */*/m3cc/{PPC_LINUX,SPARC32_LINUX} on my machines. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Subject: Hudson m3cc clean? > Date: Mon, 19 Jul 2010 01:33:05 +0000 > > > Olaf, the m3cc tasks should run "clean" with this -- configure needs to rerun. > It seems some have such a check mark option, some do not. > Platforms that are succeeding I guess can be left alone, but the ppc/sparc ones.. > The ones on my machines I can fiddle with, but PPC_DARWIN.. > > Thanks, > - Jay > > ---------------------------------------- > > Date: Mon, 19 Jul 2010 03:23:16 +0000 > > To: m3commit at elegosoft.com > > From: jkrell at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 10/07/19 03:23:16 > > > > Modified files: > > cm3/m3-sys/m3cc/src/: m3makefile > > cm3/m3-sys/m3cc/gcc/gcc/config/: darwin.h > > > > Log message: > > m3makefile, basically undo: > > Revision 1.162 > > always specify -build, -host, -target, for cross and native > > consistent but experimenta/unorthodox > > Usually people let config.guess do all the work for native > > and always for build. > > Default build to host, not target. > > > > Revision 1.161 > > Always specify -target. > > in native builds, always specify -build and -host. > > This should provide for more consistency, > > though is also a bit experimental and unorthodox. > > > > darwin.h, undo > > Revision 1.2 > > always support hidden aka private extern aka don't export every function > > > > This should fix PPC_DARWIN and maybe maybe others (SPARC32_LINUX). > > > > Possibly relatd, I've noticed SOLsun using sparc-sun-solaris2.10-gcc > > to build cm3cg, when I was hoping it'd use Sun cc. This will > > at least change it to plain gcc, but same thing. > > > From jay.krell at cornell.edu Mon Jul 19 08:10:58 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Jul 2010 06:10:58 +0000 Subject: [M3devel] clean in m3cc Message-ID: Too dangerous: m3cc/src/m3makefile if stale(build_dir & "/clean_marker.txt", "../src/clean_marker.txt") or defined ("FORCE") ? m3cc_Run(["rm -rf " & build_dir & "/*"]) ? cp_if("../src/clean_marker.txt", build_dir & "/clean_marker.txt") end ? If build_dir has a space..? ?- Jay From jay.krell at cornell.edu Mon Jul 19 08:17:29 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Jul 2010 06:17:29 +0000 Subject: [M3devel] clean in m3cc In-Reply-To: References: Message-ID: nevermind ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 19 Jul 2010 06:10:58 +0000 > Subject: [M3devel] clean in m3cc > > > Too dangerous: > > m3cc/src/m3makefile > > if stale(build_dir & "/clean_marker.txt", "../src/clean_marker.txt") or defined ("FORCE") > m3cc_Run(["rm -rf " & build_dir & "/*"]) > cp_if("../src/clean_marker.txt", build_dir & "/clean_marker.txt") > end > > ? > > If build_dir has a space..? > > > - Jay > > From wagner at elegosoft.com Mon Jul 19 08:27:13 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 19 Jul 2010 08:27:13 +0200 Subject: [M3devel] compiler behavior under "low memory"? In-Reply-To: References: Message-ID: <20100719082713.yjrrwn53b40sw0gc@mail.elegosoft.com> Perhaps a small limit was set on the system? (bash: ulimit, csh: limit) As for a fix, perhaps we could catch the exception in the builder and write out all known version information acquired so far (FINALLY block)? Olaf Quoting Jay K : > Mark had a machine with low memory. > It has more swap now. > > Our behavior was: > > Compiling m3tk would make good progress, complete many files, then fail for > ?lack of memory. > > Manual retry would start over due to > ?"missing version information" or such. > > Thus progress was "impossible". > By editing down m3makefile I was able to make progress. > ?Some stuff would fail due to missing interfaces, but > ?whatever I left in would get the version information saved. > ? > Perhaps we should write out the version information every "few" files? > ?For some definition of "few"? 10? 10% of the total? > ? > ? > That would at least let such situations progress via manual retry. > ? (unless not even a "few" fit in memory) > > > I also wonder about reducing memory used, or why indeed we run out, > ?but that is a thornier problem. You know, all we should need to > ?continue forward progress is to hold all interfaces in memory and > ?one implementation at a time. Now, there are a few unknowns here. > ?It is possible Mark's machine didn't have enough memory for > ?all the relevant interfaces, and that we only "load" them on-demand. > > ? > ?It is also likely, I should add, that virtual address space is the > ? problem, not working set. Some systems want to commit room > ? in swap for all allocated virtual memory, like, to be sure > ? ahead of time that everything can be paged out so other > ? code can progress. Something like that. I'm not sure here. > ? That is, I suspect we don't care. Virtual address space is probably > ? reasonable to deem cheap. No problem using almost 2GB of address space > ? as long as working set isn't that large (ie: to fit in 31bit > address space). > ? If some OSes don't see it that way, oh well. This might just > ? be a design/policy thing in Tru64. > ? > ? > (I'm well aware of virtual memory vs. physical memory vs. working set. > But for whatever reason, we were failing due to memory use. > All that *should* matter is that address space usage stays within > around 2GB and that working set isn't huge. Working set I've recently > come to understand can be managed like so: > ? - random access over set of memory that fits in physical memory > ? - sequential access over arbitrary memory (up to 2GB) > ? - hybrid of previous > ????? ie. sequential accesses over multiple separate areas > > As long as access is sequential, you shouldn't "thrash". > It is only random access over data that doesn't fit in physical memory > ?that causes thrashing.) > > > ?- 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 wagner at elegosoft.com Mon Jul 19 08:30:13 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 19 Jul 2010 08:30:13 +0200 Subject: [M3devel] multithreaded compiler? In-Reply-To: References: Message-ID: <20100719083013.uediq2tuogowg04g@mail.elegosoft.com> Quoting Jay K : > It should be reasonably easy to have the gcc backend run on multiple > separate threads. This won't necessarily speed things up, but could be an interesting option (-j ) depending on the machine in use. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Jul 19 09:31:22 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Jul 2010 07:31:22 +0000 Subject: [M3devel] Alpha/OSF exception handling In-Reply-To: References: , Message-ID: I didn't "remove" it, but I did "disable" it. Similar. I didn't want to have to spend any time debugging it if it didn't work any longer. I'm sure we have precious few users of this system (2 this month though, quite a surge) and they can probably live with an equally bad implementation as all the other platforms (except for Solaris/sparc). ? Granted, they have slower than average systems, would benefit more perhaps from the optimization. We can try it out I guess. I do hope we can improve this across the aboard. ? Even if we don't use the tree exception handling nodes, we can probably at least use the same runtime support (libunwind in libgcc). ? Even then, Alpha/OSF won't be important. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Sun, 18 Jul 2010 14:22:41 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Alpha/OSF exception handling > > That is a huge shame. Why did you remove it? It used to be there and functional. > > On 18 Jul 2010, at 09:35, Jay K wrote: > > > > > Modula-3 for ALPHA_OSF historically had the best exception handling implementation. > > > > With Solaris/sparc32 second best. > > > > And then everything else equally bad. > > > > > > > > > > > > The current Alpha/osf is now in the "equally bad" category. > > Because I'm lazy. > > > > It might be worth restoring its former glory. > > > > > > > > Maybe a small project for someone? > > > > > > The code is still in there. I just tweaked the m3makefiles to avoid trying it. > > > > > > jbook2:runtime jay$ pwd > > /dev2/cm3/m3-libs/m3core/src/runtime > > jbook2:runtime jay$ find ALPHA_OSF > > ALPHA_OSF/m3makefile-old > > > > Renaming that m3makefile. > > > > Fiddling with this: > > > > book2:runtime jay$ grep STACK * > > m3makefile:readonly HAS_STACK_WALKER = { > > m3makefile:if defined("M3_USE_STACK_WALKER") > > m3makefile: if M3_USE_STACK_WALKER and HAS_STACK_WALKER contains TARGET > > m3makefile: if HAS_STACK_WALKER{TARGET} > > > > > > and this: > > > > > > jbook2:src jay$ pwd > > /dev2/cm3/m3-sys/m3middle/src > > > > > > book2:src jay$ grep -i _stack *m3 > > Target.m3: Has_stack_walker := FALSE; > > Target.m3: Has_stack_walker := TRUE; > > > > > > - Jay > > > From wagner at elegosoft.com Mon Jul 19 09:49:59 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 19 Jul 2010 09:49:59 +0200 Subject: [M3devel] Hudson regression for current cm3 / incompatibilities In-Reply-To: References: <20100718165513.gug2fuk04k8cww0o@mail.elegosoft.com>, , , Message-ID: <20100719094959.plxt7b5u8c0og8o8@mail.elegosoft.com> Quoting Jay K : > Oops. I was looking at the platform views instead of the cm3-current view. > Things are better and worse than I said. More jobs exist, more jobs > have succeeded, more jobs have also failed (that exist!) and I need > to look at, e.g. PPC_DARWIN. > I understand the PPC_DARWIN problem already -- related to building > on older platform and my forcing autoconf to believe features are > there. > I know what to do. O know that my script missed NT386 jobs, but the others should all be there. I'll add that manually today. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Jul 19 10:17:15 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 19 Jul 2010 10:17:15 +0200 Subject: [M3devel] clean in m3cc In-Reply-To: References: Message-ID: <20100719101715.r4k0ubcc0oo80oso@mail.elegosoft.com> I've added a Hudson build variable CLEAN to all cm3-current-m3cc-* jobs. Olaf Quoting Jay K : > nevermind > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Date: Mon, 19 Jul 2010 06:10:58 +0000 >> Subject: [M3devel] clean in m3cc >> >> >> Too dangerous: >> >> m3cc/src/m3makefile >> >> if stale(build_dir & "/clean_marker.txt", >> "../src/clean_marker.txt") or defined ("FORCE") >> m3cc_Run(["rm -rf " & build_dir & "/*"]) >> cp_if("../src/clean_marker.txt", build_dir & "/clean_marker.txt") >> end >> >> ? >> >> If build_dir has a space..? >> >> >> - 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 mika at async.async.caltech.edu Mon Jul 19 11:01:10 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Mon, 19 Jul 2010 02:01:10 -0700 Subject: [M3devel] div/mod In-Reply-To: References: Message-ID: <20100719090110.8ED961A2084@async.async.caltech.edu> No, aborting is always something the implementation is permitted to do if it can't do the sensible thing. If it can do something sensible, it may still be permitted to abort, but is not under the obligation to do so. I think this is a general principle. Mika Jay K writes: > >ok=2C this is a really minor thing. Very esoteric=2C waste of time probably= >. > > >Div and mod are defined in terms of each other. > > >In the "real world"=2C any integer mod negative 1 is 0.=20 >=A0 All integers are "evenly divisible" by 1 and negative 1. > >So INT_MIN mod -1 is 0. > > >One can code that to be the case. Some versions of the code do. >=A0 I'm not sure about the current code=2C as we don't call the C functions= > any longer=2C except for int64 on NT386. >=A0 The older div/mod helpers=2C depending on optimization=2C would either = >return 0 >=A0=A0 or generate an overflow exception. > > >In our computer world=2C INT_MIN div -1 is not computable=2C and generates >=A0 the same exception. Even with current code. > > >If div and mod are defined in terms of each other=2C and one of them is not= > computable=2C >=A0 is it wrong to be able to compute the other? > > >=A0- Jay > > = From mika at async.async.caltech.edu Mon Jul 19 11:04:59 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Mon, 19 Jul 2010 02:04:59 -0700 Subject: [M3devel] moving to new target names, in Hudson? In-Reply-To: <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com> References: <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com> Message-ID: <20100719090459.4CE191A2084@async.async.caltech.edu> Can I also add that changing the target names is going to require work---perhaps quite a bit of work---among users of CM3... now they will no longer match PM3, or a version of CM3 older than a particular, arbitrary date. All sorts of configuration and setup scripts will have to be fixed. I would hope this sort of thing would be done for a new version number or something else that is easily testable... I suppose you can grep through the output of cm3 -version. But m3build doesn't print the target, so the scripts really do become quite a bit more complicated.... Mika Olaf Wagner writes: >Quoting Jay K : > >> Olaf, can I request that if/when you move Hudson to head, that you =20 >> also switch to I386_LINUX, I386_FREEBSD, I386_NT, >> and whatever we decide for SPARC32_SOLARIS? >> I've mostly switched to them myself. It wasn't difficult. (I always =20 >> say that). > >It will require a lot of manual work, compared to the more or less >automated transition I just made from release to current for all the >jobs. The target platform names are part of the jobs, and are also used >in various places in the build scripts, so that many things are likely >to break. > >My guess is that it will take some days for every target move given my >current attention pattern for cm3, i.e. have a look at how things work >out now and then between other work. > >Let's wait until all the jobs work again with their old target names, > >Olaf > >> I think for SPARC32_SOLARIS we should either have SPARC32_SOLARIS =20 >> that is the equivalent of today's SOLsun. >> Effectively dropping SOLgnu. >> >> >> Or we also add SPARC32_SOLARIS_gcc, which is just a configuration =20 >> file and not a target. >> This is like the "experiment" I did with NT386/NT386GNU, which I =20 >> think I regret, except >> SPARC32_SOLARIS / SPARC32_SOLAROS_gcc are far far more similar than those. >> All their platform-specific code is identical. Their backend is =20 >> identical. etc. >> >> >> A related option is SPARC32_SOLARIS_cc or SPARC32_SOLARIS_suncc, and =20 >> SPARC32_SOLARIS_gcc. >> Config files. >> But the compiler only know about SPARC32_SOLARIS. >> Just putting the two config files more as peers, so to speak. >> >> >> The way I switched targets was probably doing a cross build. >> That is overkill. You can probably just export CM3_TARGET to the =20 >> name you want. >> And maybe fiddle with shipping of cm3cg or settings its build_dir -- =20 >> i.e. leave it as just host and host-target. >--=20 >Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb=C3=A4ude 12, 13355 Berlin, Germa= >ny >phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch=C3=A4ftsf=C3=BChrer: Olaf Wagner | Sitz= >: Berlin >Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Jul 19 12:48:38 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Jul 2010 10:48:38 +0000 Subject: [M3devel] moving to new target names, in Hudson? In-Reply-To: <20100719090459.4CE191A2084@async.async.caltech.edu> References: , <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com>, <20100719090459.4CE191A2084@async.async.caltech.edu> Message-ID: The old target names are still available. I agree something like cm3 -version should be more useful. Notice: ? gcc -dumpmachine ? gcc -dumpspecs ? gcc -dumpversion ? gcc -print-search-dirs *However* notice that cm3 is *not* preconfigured/predisposed for any particular target. It has a list of targets and it can handle any of them. The config file decides the target. ?In fact, neither cm3 nor the config files are particularly knowledable about targets. ? The config files vary a little in how they run the compiler or linker. ? cm3 varies mainly in word size, endianness, and jmpbuf size. ? All the real work of knowing about targets is buried in gcc. ? And a smattering of #ifdefs in C code. Some of which could be pushed to autoconf. The old names confuse people -- you, for example. They are inconsistent. They don't specify processor architecture. What pain did you all go through when FreeBSD changed to FreeBSD2 changed to FreeBSD3 changed to FreeBSD4? Or LINUX to LINUXELF to LINUXLIBC6? So long ago nobody remembers? I used LINUXELF a little, built it, went away, came back and there was LINUXLIBC6. I had no code. It didn't matter to me. ?- Jay ---------------------------------------- > To: wagner at elegosoft.com > Date: Mon, 19 Jul 2010 02:04:59 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] moving to new target names, in Hudson? > > > Can I also add that changing the target names is going to require > work---perhaps quite a bit of work---among users of CM3... now they will > no longer match PM3, or a version of CM3 older than a particular, arbitrary > date. All sorts of configuration and setup scripts will have to be fixed. > I would hope this sort of thing would be done for a new version number > or something else that is easily testable... I suppose you can grep through > the output of cm3 -version. But m3build doesn't print the target, so the > scripts really do become quite a bit more complicated.... > > Mika > > Olaf Wagner writes: > >Quoting Jay K : > > > >> Olaf, can I request that if/when you move Hudson to head, that you =20 > >> also switch to I386_LINUX, I386_FREEBSD, I386_NT, > >> and whatever we decide for SPARC32_SOLARIS? > >> I've mostly switched to them myself. It wasn't difficult. (I always =20 > >> say that). > > > >It will require a lot of manual work, compared to the more or less > >automated transition I just made from release to current for all the > >jobs. The target platform names are part of the jobs, and are also used > >in various places in the build scripts, so that many things are likely > >to break. > > > >My guess is that it will take some days for every target move given my > >current attention pattern for cm3, i.e. have a look at how things work > >out now and then between other work. > > > >Let's wait until all the jobs work again with their old target names, > > > >Olaf > > > >> I think for SPARC32_SOLARIS we should either have SPARC32_SOLARIS =20 > >> that is the equivalent of today's SOLsun. > >> Effectively dropping SOLgnu. > >> > >> > >> Or we also add SPARC32_SOLARIS_gcc, which is just a configuration =20 > >> file and not a target. > >> This is like the "experiment" I did with NT386/NT386GNU, which I =20 > >> think I regret, except > >> SPARC32_SOLARIS / SPARC32_SOLAROS_gcc are far far more similar than those. > >> All their platform-specific code is identical. Their backend is =20 > >> identical. etc. > >> > >> > >> A related option is SPARC32_SOLARIS_cc or SPARC32_SOLARIS_suncc, and =20 > >> SPARC32_SOLARIS_gcc. > >> Config files. > >> But the compiler only know about SPARC32_SOLARIS. > >> Just putting the two config files more as peers, so to speak. > >> > >> > >> The way I switched targets was probably doing a cross build. > >> That is overkill. You can probably just export CM3_TARGET to the =20 > >> name you want. > >> And maybe fiddle with shipping of cm3cg or settings its build_dir -- =20 > >> i.e. leave it as just host and host-target. > >--=20 > >Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb=C3=A4ude 12, 13355 Berlin, Germa= > >ny > >phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > http://www.elegosoft.com | Gesch=C3=A4ftsf=C3=BChrer: Olaf Wagner | Sitz= > >: Berlin > >Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Jul 19 12:50:37 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Jul 2010 10:50:37 +0000 Subject: [M3devel] clean in m3cc In-Reply-To: <20100719101715.r4k0ubcc0oo80oso@mail.elegosoft.com> References: , , <20100719101715.r4k0ubcc0oo80oso@mail.elegosoft.com> Message-ID: I put in another mechanism. If someone makes a change such that they want m3cc to build clean, edit m3-sys/m3cc/src/clean-marker.txt arbitrarily. I'm not sure though, the stuff at the top of m3cc/src/m3makefile might need to be adjusted to honor it. I probably should do even better -- the configure command line should be saved and if it changes, go clean. I didn't do that yet. ?- Jay ---------------------------------------- > Date: Mon, 19 Jul 2010 10:17:15 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] clean in m3cc > > I've added a Hudson build variable CLEAN to all cm3-current-m3cc-* jobs. > > Olaf > > Quoting Jay K : > > > nevermind > > > > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: m3devel at elegosoft.com > >> Date: Mon, 19 Jul 2010 06:10:58 +0000 > >> Subject: [M3devel] clean in m3cc > >> > >> > >> Too dangerous: > >> > >> m3cc/src/m3makefile > >> > >> if stale(build_dir & "/clean_marker.txt", > >> "../src/clean_marker.txt") or defined ("FORCE") > >> m3cc_Run(["rm -rf " & build_dir & "/*"]) > >> cp_if("../src/clean_marker.txt", build_dir & "/clean_marker.txt") > >> end > >> > >> ? > >> > >> If build_dir has a space..? > >> > >> > >> - 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 mika at async.async.caltech.edu Mon Jul 19 13:02:07 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Mon, 19 Jul 2010 04:02:07 -0700 Subject: [M3devel] moving to new target names, in Hudson? In-Reply-To: References: , <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com>, <20100719090459.4CE191A2084@async.async.caltech.edu> Message-ID: <20100719110208.011521A2091@async.async.caltech.edu> Jay K writes: > >The old target names are still available. > > ... > >*However* notice that cm3 is *not* preconfigured/predisposed for any partic= >ular target. cm3 -version prints a target... > > >It has a list of targets and it can handle any of them. The config file dec= >ides the target. >=A0In fact=2C neither cm3 nor the config files are particularly knowledable= > about targets. >=A0 The config files vary a little in how they run the compiler or linker. >=A0 cm3 varies mainly in word size=2C endianness=2C and jmpbuf size. >=A0 All the real work of knowing about targets is buried in gcc. >=A0 And a smattering of #ifdefs in C code. Some of which could be pushed to= > autoconf. > > >The old names confuse people -- you=2C for example. >They are inconsistent. >They don't specify processor architecture. > Well I agree with that much.. > >What pain did you all go through when FreeBSD changed to FreeBSD2 changed t= >o FreeBSD3 changed to FreeBSD4? >Or LINUX to LINUXELF to LINUXLIBC6? >So long ago nobody remembers? >I used LINUXELF a little=2C built it=2C went away=2C came back and there wa= >s LINUXLIBC6. I had no code. It didn't matter to me. > The point of these names, I thought, was that they were supposed to map to binary-incompatible systems. I remember having FreeBSD2 and FreeBSD3 at the same time. We had a cluster with machines with both OSes, which were not binary compatible. The point is so that you can run cm3/m3build for both in the same repository (even concurrently), and not have them interfere with each other. It's not a pain to have different names if they actually mean different things. If you just call everything I386_FREEBSD all hell will break loose in that situation... (just as when I by mistake run "FreeBSD4" (really FreeBSD6) CM3 in a directory where I have already compiled things with "FreeBSD4" (really FreeBSD4) PM3...) Or am I misunderstanding something here? I would have thought you really wanted to have a different name for each binary-incompatible system so you can build them all in the same place. Consistency in naming would be nice but I think it is secondary. Mika From jay.krell at cornell.edu Mon Jul 19 13:51:28 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Jul 2010 11:51:28 +0000 Subject: [M3devel] moving to new target names, in Hudson? In-Reply-To: <20100719110208.011521A2091@async.async.caltech.edu> References: , , <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com>, , <20100719090459.4CE191A2084@async.async.caltech.edu>, , <20100719110208.011521A2091@async.async.caltech.edu> Message-ID: Well, from the compiler (cm3, cm3cg) and libraries (m3core/*.m3, etc.) point of view, now, all I386_FREEBSD are the same. ?They are all little endian, 32bit word, have the same jmpbuf, and no stack walker. ?(Ok, there's a small difference in that older FreeBSD might not have decent enough pthreads. ? So we should really maybe have I386_FREEBSD_pthreads and I386_FREEBSD_userthreads. ??? But this still is overkill. They are still identical in cm3 and cm3cg. They vary only in m3core/*/m3makefile. ?? I think this is best done by making the "thread library" a variable that the user can edit in config file. ?? And maybe gets appended to BUILD_DIR. But TARGET is unchanged.) Any differences or binary compatibilities aren't present until m3core/*.c #includes varying headers. I think it makes more sense probably for people to start editing BUILD_DIR in their config files. ? I386_FREEBSD1 ? I386_FREEBSD2 ? I386_FREEBSD3 ? I386_FREEBSD4 ? I386_FREEBSD5 ? I386_FREEBSD6 ? I386_FREEBSD7 ? I386_FREEBSD8 ? I386_SOLARIS2.8 ? ? I386_SOLARIS2.9? ? I386_SOLARIS2.10 ? I386_SOLARIS2.11? Exposing this explosion in more than maybe one directory, I quite dislike. They could be config files that set BUILD_DIR, maybe THREAD_LIBRARY (which I just made up) and then include(I386_FREEBSD). I like to think they are "configurations", lightweight toplevel things, many of them, that quickly devolve into a small number of "targets". Maybe what we should really, like, is run config.guess and use its entire output: i386-unknown-freebsd4.11 Unknown is unsightly.. Specifically for BUILD_DIR. TARGET would be somehow computed from that? BUILD_DIR is arbitrary. See how profiling appends "p" to it? Not that I ever use that. Perhaps not that anyone ever has TARGET != BUILD_DIR. ? Though that is how Modula-3 works for Cygwin. I am slowly believing in the way of autoconf and the GNU build system. It must be observed. On one hand that exposes a combinatorial explosion of configurations. On the other, it avoids canonizing any particular combination as special. If cm3 were to discover jmpbuf size in some sort of autoconf-ish thing, and record that merely in the config file, we'd be left with basically only four architectures in cm3: little endian32, little endian64, big endian32, big endian64. Heck, it doesn't even need to be autoconfish. It just needs to be in the config files. And a very small number of other things: the name of setjmp (_setjmp or setjmp), if there is a stack walker (usually false but sometimes true). ?- Jay ---------------------------------------- > To: jay.krell at cornell.edu > Date: Mon, 19 Jul 2010 04:02:07 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] moving to new target names, in Hudson? > > Jay K writes: > > > >The old target names are still available. > > > > > ... > > > >*However* notice that cm3 is *not* preconfigured/predisposed for any partic= > >ular target. > > cm3 -version prints a target... > > > > > > >It has a list of targets and it can handle any of them. The config file dec= > >ides the target. > >=A0In fact=2C neither cm3 nor the config files are particularly knowledable= > > about targets. > >=A0 The config files vary a little in how they run the compiler or linker. > >=A0 cm3 varies mainly in word size=2C endianness=2C and jmpbuf size. > >=A0 All the real work of knowing about targets is buried in gcc. > >=A0 And a smattering of #ifdefs in C code. Some of which could be pushed to= > > autoconf. > > > > > >The old names confuse people -- you=2C for example. > >They are inconsistent. > >They don't specify processor architecture. > > > > Well I agree with that much.. > > > > >What pain did you all go through when FreeBSD changed to FreeBSD2 changed t= > >o FreeBSD3 changed to FreeBSD4? > >Or LINUX to LINUXELF to LINUXLIBC6? > >So long ago nobody remembers? > >I used LINUXELF a little=2C built it=2C went away=2C came back and there wa= > >s LINUXLIBC6. I had no code. It didn't matter to me. > > > > The point of these names, I thought, was that they were supposed to map > to binary-incompatible systems. I remember having FreeBSD2 and FreeBSD3 > at the same time. We had a cluster with machines with both OSes, which > were not binary compatible. The point is so that you can run cm3/m3build > for both in the same repository (even concurrently), and not have them > interfere with each other. It's not a pain to have different names > if they actually mean different things. If you just call everything > I386_FREEBSD all hell will break loose in that situation... (just as when > I by mistake run "FreeBSD4" (really FreeBSD6) CM3 in a directory where > I have already compiled things with "FreeBSD4" (really FreeBSD4) PM3...) > > Or am I misunderstanding something here? I would have thought you really > wanted to have a different name for each binary-incompatible system so > you can build them all in the same place. Consistency in naming would be > nice but I think it is secondary. > > Mika From wagner at elegosoft.com Mon Jul 19 14:38:44 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 19 Jul 2010 14:38:44 +0200 Subject: [M3devel] moving to new target names, in Hudson? In-Reply-To: <20100719110208.011521A2091@async.async.caltech.edu> References: , <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com>, <20100719090459.4CE191A2084@async.async.caltech.edu> <20100719110208.011521A2091@async.async.caltech.edu> Message-ID: <20100719143844.03al7scsg0g400so@mail.elegosoft.com> Quoting Mika Nystrom : [...] > The point of these names, I thought, was that they were supposed to map > to binary-incompatible systems. I remember having FreeBSD2 and FreeBSD3 > at the same time. We had a cluster with machines with both OSes, which > were not binary compatible. The point is so that you can run cm3/m3build > for both in the same repository (even concurrently), and not have them > interfere with each other. It's not a pain to have different names > if they actually mean different things. If you just call everything > I386_FREEBSD all hell will break loose in that situation... (just as when > I by mistake run "FreeBSD4" (really FreeBSD6) CM3 in a directory where > I have already compiled things with "FreeBSD4" (really FreeBSD4) PM3...) > > Or am I misunderstanding something here? I would have thought you really > wanted to have a different name for each binary-incompatible system so > you can build them all in the same place. Consistency in naming would be > nice but I think it is secondary. In theory, yes, but it hasn't always worked out in practice. Binary compatibility works at least in two directions: (a) Allow applications compiled on an older system with older tools and libraries to be run on a newer system. (b) Allow applications compiled on a newer system to run on all or certain selected older system versions. Usually (a) is provided by Open Source systems like Linux, FreeBSD etc., at least within a major release line, sometimes also crossing boundaries (remember the switch from aout to elf format in FreeBSD). (b) is often partially provided by commercial systems like Windows, though in practice this doesn't always work as expected, too. It would be nice if we really could follow all binary compatibility changes in all supported operating system targets with a new unique name, but I'm afraid we haven't been able to do that in the past nor will we succeed to do that in the future. You have experienced one failure as you tried the FreeBSD4 packages built on FreeBSD 6.4 on an actual FreeBSD 4.11 system. We may get better if we distinguish between different uses of the target platform name though: (1) TARGET as a choice for compilation variants that cm3 distinguishes internally (2) TARGET as a name for the directories containing derived files (which is already configurable in quake config files). For example, the profiling setups I made some years ago added a `p' to the TARGET name. (3) TARGET as an indicator for installation or other binary packages on which system these binaries may run (3) should include as many information as possible, though it is not clear to me where to stop here. Do we actually want the X version or the GUI support libraries to be included there? What if different loadable formats are supported, as under Darwin (PPC, I386, combined) or Windows (com, exe (coff))? I would tend to start with something like the output of uname -rsm here: o FreeBSD 8.0-STABLE amd64 o Linux 2.6.26-2-amd64 x86_64 o FreeBSD 6.4-RELEASE-p5 i386 o Darwin 9.8.0 i386 o Darwin 8.11.0 Power Macintosh We could also add a more or less unspecified variant part there, for example, if we need to distinguish between aout/coff/elf format. (1) should be the list of distinctions we need to make to support different target platforms. The current compromise seems to be that this is a combination of processor/machine architecture (like I386, AMD64) and operating system name (not version). Then (2) could be an installation-specific choice: either just use the more generic name from (1), or a combination of (1) and (3), or some arbitrary name. It's not completely thought through yet, so suggestions on what exactly would be required or great are welcome. I've already added the information of (3) to the CM3 5.8.6 download pages; the next release should include it in the actual package names. (1) should be consistently standardized if possible (i.e. FreeBSD1/2/3/4 --> I386_FREEBSD etc.). Many actual configuration options may be determined by auto-configuration then. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Jul 19 15:32:22 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Jul 2010 13:32:22 +0000 Subject: [M3devel] moving to new target names, in Hudson? In-Reply-To: <20100719143844.03al7scsg0g400so@mail.elegosoft.com> References: , , <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com>, , <20100719090459.4CE191A2084@async.async.caltech.edu>, , <20100719110208.011521A2091@async.async.caltech.edu>, <20100719143844.03al7scsg0g400so@mail.elegosoft.com> Message-ID: Clearly this stuff is hard to describe. I think both Olaf and I sound like we're rambling. Esp. me. :) Olaf clearly gets my point of view though. :) > (b) is often partially provided by commercial systems like Windows, though > in practice this doesn't always work as expected, too. Yes it does! That's tangential though. ?> What if different loadable > formats are supported, as under Darwin (PPC, I386, combined) Let's table the "universal binaries" subject for now. I think it is slightly interesting, but nobody has asked for it, and it is fairly unique to Darwin. ?It can be done either by building everything twice, or by combing files after the fact. ? Nice thing about combining after the fact is basically nothing changes. > or Windows (com, exe (coff))? No, really, no. But I'll explain since you brought it up. There are two or so formats of MS-DOS file. A .com file is just under 64K of bytes loaded anywhere, all addresses are relative and <= 64K. That is, there is no file format. It just must be small. This is for 16bit code only. We don't support 16bit MS-DOS. There is MS-DOS .exe files which can be large and are relocatable. Again, this is a 16bit thing. In more general reality, people write their own loaders for MS-DOS. There's a DOS extender that loads Win32 files for example. Now, in Windows there is just one file format, PE, COFF, PE/COFF, whatever. All the same thing. The file *name* of such a file is arbitrary and varies. "more.com" is of the same file format as "findstr.exe". It just has that wierdo extension for compatibility. It is not a .com file like in MS-DOS. P in PE is "portable", as in all versions of NT: MIPS, PowerPC, 32bit Alpha, x86, use the same format. Later there was some revision, PE was renamed PE32, PE32+ was introduced. It is almost the same thing, but a few fields were widened to 64bits. Still, 64bit Alpha, IA64, AMD64 all use the same format. So there are only two formats: 32bit and 64bit. That's still nicely pretty "portable". So, short story, drop executable file format as a variable, at least on Windows. I understand some Unixes switched from a.out to ELF. That is/was relevant. LINUX => LINUXELF. But 32bit Windows never switched formats for files containing 32bit code. True, Win3.1 and OS/2 had various NE (new executable?), LE (linear executable?) but I don't think we care. Maybe at some point we'll have I386_OS2_NE, I386_OS2_LE but I don't know enough to say. More likely we'd have I386_WIN31, with one file format, I386_OS2 with one file format. > I would tend to start with something like the > output of uname -rsm here: > > o FreeBSD 8.0-STABLE amd64 > o Linux 2.6.26-2-amd64 x86_64 > o FreeBSD 6.4-RELEASE-p5 i386 > o Darwin 9.8.0 i386 > o Darwin 8.11.0 Power Macintosh I mostly agree, but I think it is maybe a little two much information in some cases. Should just be e.g. FreeBSD 8.0 amd64. FreeBSD 6.4 i386 -- does RELEASE p5 really help? I think you should look at the output (not the code) of the GNU config.guess file. I think it is mostly the way to go. It has those dumb "unknown" and "pc" things, and the "vendor" (apple, sun, dec) is generally meaningless. But the first and third/fourth parts are good. It is similar to your uname -srm. There are things beyond uname, like "sizer" on Alpha/OSF. config.guess finds the "g" in 4.0g, but uname doesn't. I'll admit another evidence of the problem. PPC64_DARWIN ?I think the last release added a bunch. ?So PPC64_DARWIN < 10.5 wouldn't have any Trestle/X stuff. ?But PPC64_DARWIN10.5 would. >From an implementation/compiler/library point of view, this can be implemented by having the config/m3makefiles probe at config/install/runtime. I've been putting probes in at runtime. Stuff that possibly belongs in config or install. Now, there is this this thorny issue you mention. We build binaries for redistribution. This does in a sense resemble a cross build. Building on machine X to run on machine Y, which may be more or less the same. If you consider something like Debian where they produce tons of binary packages, or even FreeBSD/NetBSD/OpenBSD, they have a luxury. They aren't really doing cross builds. They know the packages will be installed on the same OS release. They rebuild all the packages for each release. And Ubuntu vs. Debian are different builds. What do we do? Perhaps we sort of go back to the old model where customers do their own build? Or partly their own build? I think this is a definite possibility. And we use autoconf a bit in there? I think definitely maybe. The "boot" packages I build are a possible start. Though they need to come with matching Modula-3 source tree, including m3cc. ? => Just like the 3.6 DEC SRC release. Should we work towards that? Does it stink too much to make people build it? It has upside and downside. Upside is we get largely out of this configuration problem. Downside is they have to be much more patient before using the system. Perhaps we provide similar to what we already have, but with "overspecified configuration" names. If we have an exact match for you, great. If not, you build it yourself? I don't know about these Linux kernel version numbers. I hope/think Linux might have good compatibility? Our usage is fairly light. This is partly why i was interested in Modula-3 threads over Linux, instead of over glibc. So we could avoid the ARMEL_LINUX_glibc vs ARMEL_LINUX_uclibc vs. ARMEL_LINUX_bionic (Android) question. I'm rambling terribly, I realize. Sorry. In conclusion...I think we probably do something like uname -srm or config.guess, distribute "boot" + m3src.tar.gz + m3cc.tar.gz like DEC SRC did, we provide some binaries. User can rename build_dir to whatever he/she wants, but we'd start with something like config.guess? ?? Things like word size, endian, jmpbuf size, setjmp name, move to config file? ? Try to configure these things with autoconf? Make my "boot" packages use autoconf? e.g. to compile the C? ? To find libraries and build the config file and fill out SYSTEM_LIBS? i.e. to replace cminstall? Remove all target knowledge from Target.m3? ???? It's a bunch of work, makes these confusing (as autoconf does), but it does solve some problems I don't know. ?- Jay ---------------------------------------- > Date: Mon, 19 Jul 2010 14:38:44 +0200 > From: wagner at elegosoft.com > To: mika at async.async.caltech.edu > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > Subject: Re: [M3devel] moving to new target names, in Hudson? > > Quoting Mika Nystrom : > [...] > > The point of these names, I thought, was that they were supposed to map > > to binary-incompatible systems. I remember having FreeBSD2 and FreeBSD3 > > at the same time. We had a cluster with machines with both OSes, which > > were not binary compatible. The point is so that you can run cm3/m3build > > for both in the same repository (even concurrently), and not have them > > interfere with each other. It's not a pain to have different names > > if they actually mean different things. If you just call everything > > I386_FREEBSD all hell will break loose in that situation... (just as when > > I by mistake run "FreeBSD4" (really FreeBSD6) CM3 in a directory where > > I have already compiled things with "FreeBSD4" (really FreeBSD4) PM3...) > > > > Or am I misunderstanding something here? I would have thought you really > > wanted to have a different name for each binary-incompatible system so > > you can build them all in the same place. Consistency in naming would be > > nice but I think it is secondary. > > In theory, yes, but it hasn't always worked out in practice. > Binary compatibility works at least in two directions: > > (a) Allow applications compiled on an older system with older tools > and libraries to be run on a newer system. > > (b) Allow applications compiled on a newer system to run on all or > certain selected older system versions. > > Usually (a) is provided by Open Source systems like Linux, FreeBSD etc., > at least within a major release line, sometimes also crossing boundaries > (remember the switch from aout to elf format in FreeBSD). > > (b) is often partially provided by commercial systems like Windows, though > in practice this doesn't always work as expected, too. > > It would be nice if we really could follow all binary compatibility > changes in all supported operating system targets with a new unique > name, but I'm afraid we haven't been able to do that in the past nor > will we succeed to do that in the future. > > You have experienced one failure as you tried the FreeBSD4 packages > built on FreeBSD 6.4 on an actual FreeBSD 4.11 system. > > We may get better if we distinguish between different uses of the target > platform name though: > > (1) TARGET as a choice for compilation variants that cm3 distinguishes > internally > > (2) TARGET as a name for the directories containing derived files (which is > already configurable in quake config files). For example, the profiling > setups I made some years ago added a `p' to the TARGET name. > > (3) TARGET as an indicator for installation or other binary packages > on which system these binaries may run > > (3) should include as many information as possible, though it is not > clear to me where to stop here. Do we actually want the X version or > the GUI support libraries to be included there? What if different loadable > formats are supported, as under Darwin (PPC, I386, combined) or Windows > (com, exe (coff))? I would tend to start with something like the > output of uname -rsm here: > > o FreeBSD 8.0-STABLE amd64 > o Linux 2.6.26-2-amd64 x86_64 > o FreeBSD 6.4-RELEASE-p5 i386 > o Darwin 9.8.0 i386 > o Darwin 8.11.0 Power Macintosh > > We could also add a more or less unspecified variant part there, for > example, if we need to distinguish between aout/coff/elf format. > > (1) should be the list of distinctions we need to make to support > different target platforms. The current compromise seems to be that > this is a combination of processor/machine architecture (like I386, AMD64) > and operating system name (not version). > > Then (2) could be an installation-specific choice: either just use > the more generic name from (1), or a combination of (1) and (3), or > some arbitrary name. It's not completely thought through yet, so suggestions > on what exactly would be required or great are welcome. > > I've already added the information of (3) to the CM3 5.8.6 download > pages; the next release should include it in the actual package names. > > (1) should be consistently standardized if possible (i.e. FreeBSD1/2/3/4 > --> I386_FREEBSD etc.). Many actual configuration options may be > determined by auto-configuration then. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From wagner at elegosoft.com Mon Jul 19 16:28:35 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 19 Jul 2010 16:28:35 +0200 Subject: [M3devel] moving to new target names, in Hudson? In-Reply-To: References: , , <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com>, , <20100719090459.4CE191A2084@async.async.caltech.edu>, , <20100719110208.011521A2091@async.async.caltech.edu>, <20100719143844.03al7scsg0g400so@mail.elegosoft.com> Message-ID: <20100719162835.j0mnd9q3fo4s0g4g@mail.elegosoft.com> Hi Jay, I've learned several new things about Windows again; but in general, I don't think we disagree very much about the options and things to do. I agree that config.guess might be a good short-time option for the installation package names. I also agree that we could provide assembled packages for everything like PM3 did and rely on auto-configuration for everything else. This might be some more work for Windows though, as it uses a different backend than all other platforms. We'd need to create completely different Makefiles and scripts for Windows than for Unix and Unix-like systems. Or rely on some other tooling as prerequisite (either perl, python, Cygwin, ... you name it). I wouldn't like that very much though. I'm not sure yet if that would be welcome by all users and be seen as a step forward. I wouldn't mind it though. If it is generally accepted as a good idea, we should build up the infrastructure for that kind of packages and installations in parallel to what we have now. It would definitely not be the native Windows-installer user experience then ;-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Jul 19 16:34:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Jul 2010 14:34:02 +0000 Subject: [M3devel] I386_OPENBSD hangs in stubgen Message-ID: I386_OPENBSD hangs in stubgen Problem seems to be in the "rewritten" user threads (ie: using the sigaltstack approach instead of poking at the jmpbuf) here: ??? sigemptyset(&sigs); ??? sigaddset(&sigs, SIGUSR1); ??? sigprocmask(SIG_BLOCK, &sigs, &osigs); ... ??? kill(getpid(), SIGUSR1); ??? sigfillset(&sigs); ??? sigdelset(&sigs, SIGUSR1); ??? while (!mctx_called) ??????? sigsuspend(&sigs); The kill seems to come in immdiately, even though sigusr1 is blocked. And then sigsuspend hangs waiting forever. I forgot to eheck if mctx_called has changed, or if the check is optimized out. It seems ok if the kill comes in right away actually. I thought I had tested all this already on OpenBSD/x86 but I guess maybe not. I thought maybe the -pthread vs. -lpthread did it, but it seems not. I'll poke around more. I might resort to putting back the jmpbuf hacking, which would be unfortunate. (OpenBSD doesn't implement get/set/make/swapcontext, at least as of previous release 4.6.) ?- Jay From mika at async.async.caltech.edu Mon Jul 19 16:47:22 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Mon, 19 Jul 2010 07:47:22 -0700 Subject: [M3devel] moving to new target names, in Hudson? In-Reply-To: References: , , <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com>, , <20100719090459.4CE191A2084@async.async.caltech.edu>, , <20100719110208.011521A2091@async.async.caltech.edu> Message-ID: <20100719144722.81DB41A208C@async.async.caltech.edu> Well Jay, from the user's point of view it really doesn't matter whether cm3 is one binary or many... BUILD_DIR has more to do with whether the binaries that it produces can run on one platform or many. But from what I gather from your email, the idea seems to be that you can have many targets in one compiler and the user of the compiler can set BUILD_DIR himself, as he pleases? That would be wonderful... Does it work to do that? Can I just change BUILD_DIR to, say, MIKAS_ENVIRONMENT_USING_CM3_5_8_6_WITH_THREADS_HACKS_ON_FREEBSD_4_11_I386 and have everything work for me? Mika Jay K writes: > >Well=2C from the compiler (cm3=2C cm3cg) and libraries (m3core/*.m3=2C etc.= >) point of view=2C now=2C all I386_FREEBSD are the same. >=A0They are all little endian=2C 32bit word=2C have the same jmpbuf=2C and = >no stack walker. >=A0(Ok=2C there's a small difference in that older FreeBSD might not have d= >ecent enough pthreads. >=A0 So we should really maybe have I386_FREEBSD_pthreads and I386_FREEBSD_u= >serthreads. >=A0=A0=A0 But this still is overkill. They are still identical in cm3 and c= >m3cg. They vary only in m3core/*/m3makefile. >=A0=A0 I think this is best done by making the "thread library" a variable = >that the user can edit in config file. >=A0=A0 And maybe gets appended to BUILD_DIR. But TARGET is unchanged.) > > >Any differences or binary compatibilities aren't present until m3core/*.c #= >includes varying headers. >I think it makes more sense probably for people to start editing BUILD_DIR = >in their config files. >=A0 I386_FREEBSD1=20 >=A0 I386_FREEBSD2=20 >=A0 >I386_FREEBSD3=20 >=A0 >I386_FREEBSD4=20 >=A0 >I386_FREEBSD5=20 >=A0 >I386_FREEBSD6=20 >=A0 >I386_FREEBSD7=20 >=A0 I386_FREEBSD8 >=A0 I386_SOLARIS2.8 =A0=20 > > > >=A0 I386_SOLARIS2.9=A0=20 > > >=A0 I386_SOLARIS2.10=20 > > > >=A0 I386_SOLARIS2.11=A0=20 > > > > >Exposing this explosion in more than maybe one directory=2C I quite dislike= >. >They could be config files that set BUILD_DIR=2C maybe THREAD_LIBRARY (whic= >h I just made up) and then include(I386_FREEBSD). >I like to think they are "configurations"=2C lightweight toplevel things=2C= > many of them=2C that quickly devolve into a small number of "targets". > > > >Maybe what we should really=2C like=2C is run config.guess and use its enti= >re output: i386-unknown-freebsd4.11 >Unknown is unsightly.. Specifically for BUILD_DIR. TARGET would be somehow = >computed from that? > > > > >BUILD_DIR is arbitrary. See how profiling appends "p" to it? Not that I eve= >r use that. >Perhaps not that anyone ever has TARGET !=3D BUILD_DIR. >=A0 Though that is how Modula-3 works for Cygwin. > > >I am slowly believing in the way of autoconf and the GNU build system. It m= >ust be observed. >On one hand that exposes a combinatorial explosion of configurations. >On the other=2C it avoids canonizing any particular combination as special.= >=20 > > >If cm3 were to discover jmpbuf size in some sort of autoconf-ish thing=2C a= >nd record that merely in the config file=2C >we'd be left with basically only four architectures in cm3: little endian32= >=2C little endian64=2C big endian32=2C big endian64. > > >Heck=2C it doesn't even need to be autoconfish. It just needs to be in the = >config files. >And a very small number of other things: the name of setjmp (_setjmp or set= >jmp)=2C if there is a stack walker (usually false but sometimes true). > > > >=A0- Jay > >---------------------------------------- >> To: jay.krell at cornell.edu >> Date: Mon=2C 19 Jul 2010 04:02:07 -0700 >> From: mika at async.async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] moving to new target names=2C in Hudson? >> >> Jay K writes: >> > >> >The old target names are still available. >> > >> > >> ... >> > >> >*However* notice that cm3 is *not* preconfigured/predisposed for any par= >tic=3D >> >ular target. >> >> cm3 -version prints a target... >> >> > >> > >> >It has a list of targets and it can handle any of them. The config file = >dec=3D >> >ides the target. >> >=3DA0In fact=3D2C neither cm3 nor the config files are particularly know= >ledable=3D >> > about targets. >> >=3DA0 The config files vary a little in how they run the compiler or lin= >ker. >> >=3DA0 cm3 varies mainly in word size=3D2C endianness=3D2C and jmpbuf siz= >e. >> >=3DA0 All the real work of knowing about targets is buried in gcc. >> >=3DA0 And a smattering of #ifdefs in C code. Some of which could be push= >ed to=3D >> > autoconf. >> > >> > >> >The old names confuse people -- you=3D2C for example. >> >They are inconsistent. >> >They don't specify processor architecture. >> > >> >> Well I agree with that much.. >> >> > >> >What pain did you all go through when FreeBSD changed to FreeBSD2 change= >d t=3D >> >o FreeBSD3 changed to FreeBSD4? >> >Or LINUX to LINUXELF to LINUXLIBC6? >> >So long ago nobody remembers? >> >I used LINUXELF a little=3D2C built it=3D2C went away=3D2C came back and= > there wa=3D >> >s LINUXLIBC6. I had no code. It didn't matter to me. >> > >> >> The point of these names=2C I thought=2C was that they were supposed to m= >ap >> to binary-incompatible systems. I remember having FreeBSD2 and FreeBSD3 >> at the same time. We had a cluster with machines with both OSes=2C which >> were not binary compatible. The point is so that you can run cm3/m3build >> for both in the same repository (even concurrently)=2C and not have them >> interfere with each other. It's not a pain to have different names >> if they actually mean different things. If you just call everything >> I386_FREEBSD all hell will break loose in that situation... (just as when >> I by mistake run "FreeBSD4" (really FreeBSD6) CM3 in a directory where >> I have already compiled things with "FreeBSD4" (really FreeBSD4) PM3...) >> >> Or am I misunderstanding something here? I would have thought you really >> wanted to have a different name for each binary-incompatible system so >> you can build them all in the same place. Consistency in naming would be >> nice but I think it is secondary. >> >> Mika > = From jay.krell at cornell.edu Mon Jul 19 16:56:15 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Jul 2010 14:56:15 +0000 Subject: [M3devel] moving to new target names, in Hudson? In-Reply-To: <20100719162835.j0mnd9q3fo4s0g4g@mail.elegosoft.com> References: , ,,<20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com>, , , <20100719090459.4CE191A2084@async.async.caltech.edu>, , , , <20100719110208.011521A2091@async.async.caltech.edu>, , <20100719143844.03al7scsg0g400so@mail.elegosoft.com>, , <20100719162835.j0mnd9q3fo4s0g4g@mail.elegosoft.com> Message-ID: I agree we agree, on the issues. ? I know I've been rambly though, so I'm not sure others understand. ? I had made these points earlier for Cygwin vs. native NT, but they were less valid there. ? The systems resembled each other less. I'm nervous about my own suggestion though. Don't worry about Windows here. It has excellent binary compatibility and the existing static configuration will work fine. There is a similar matter with the C runtime version, which is also tied to the compiler version. You see I already handled that in terms of archive names. I also got "boot" archives working for I386_NT. The Makefile works with Microsoft nmake and is very simple. The "boot" process produces .objs instead assembly source, which is fine and good -- because of the integrated backend. To be clear, on NT, I think having the user build the system is fine and good. But instead of config.guess, probably just use "I386_NT_VC70", "I386_NT_VC80", "I386_NT_VC90", "I386_NT_VC100" You can see in pylib.py I probe the compiler version trivially. I guess I'll rewrite that in .cmd or JScript embedded in .cmd. ?That will do fine. And like my proposal where we build a few Posix packages (maybe very few), we can build a few/very few .msis. And just to remind everyone, m3src.tar.gz is split from m3cc.tar.gz, so that I386_NT users don't have to download m3cc.tar.gz which they don't use. Also to point out the obvious once you think about it: ?We can use DEC SRC for "guidance" but we cannot actually just go back to how it worked. ? In particular, because quake was written in C back then. They distributed C source to it. ? Small different really, as I believe they still distributed assembly of m3build. Let's sit and think/talk about this longer before implementing something we decide we don't like. I did start playing with autconf finally..been a long time coming. Thing is..I don't think we need the full machinery of automake and even GNU make. Depending on..another matter.. If you look at the existing boot archives, they just build cm3, Makefile is pretty simple. autoconf will help, to find the C compiler, flags for -pthreads. I put some annotations in m3core.h of stuff autoconf can figure out. Question then: do we extend this and ship the entire system as assembly + C + makefiles? That is, make user build m3cc, but then just assemble? Or, only ship assembly for cm3? I don't see a big difference either way. Except that full system assembly + C dovetails nicely into things like iphone where you want to "finish" the build not on the target, but using the "native cross" toolset. ie: it is probably useful automation to have. Independent of if we distribute it. But this does remind me...another thing autoconf can do...not autoconf actually, but libtool can be of use. A bit of the config files is how to run the linker, shared vs. static. libtool is kind of gross and slow. But this is what it does. (Again, I just wouldn't do it for NT.) "and another thing" We can perhaps distribute patches to gcc instead of the full gcc tree. State what version they are against, give a URL. ? We'd keep our tree for development convenience though. "and another thing" Back in the existing scheme of things..I was considering a go at upgrading m3gdb.. I'm still nervous. Maybe we wait and see how much success/failure there is with the current release's binary distribution. Mika's FreeBSD 4 problems and Mark's problem with 5.1 binaries on 4.0g aren't really enough to warrant doing much. Except that we do understand the problem. "and another thing" To whatever extent systems are x86/amd64 and runnable in VMs, and to whatever extent they have good backward compatibility, and to whatever extent Java is available on older systems. just building on "oldest common denominator" might be good. (I just up the term. :) ) Probably this new stuff can be worked on and pondered..completely without upsetting the status quo. I think so. Good. I've had a big mental hurdle around autoconf/libtool for a long time but I'm finally starting to clear it.. I think they are part of the solution. This will address the $ORIGIN stuff also of course, largely. ?(We still might provide a few binaries; maybe only for systems with $ORIGIN.) ?- Jay ---------------------------------------- > Date: Mon, 19 Jul 2010 16:28:35 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] moving to new target names, in Hudson? > > Hi Jay, > > I've learned several new things about Windows again; but in general, > I don't think we disagree very much about the options and things to do. > > I agree that config.guess might be a good short-time option for the > installation package names. > > I also agree that we could provide assembled packages for everything > like PM3 did and rely on auto-configuration for everything else. > This might be some more work for Windows though, as it uses a different > backend than all other platforms. We'd need to create completely different > Makefiles and scripts for Windows than for Unix and Unix-like systems. > Or rely on some other tooling as prerequisite (either perl, python, > Cygwin, ... you name it). I wouldn't like that very much though. > > I'm not sure yet if that would be welcome by all users and be seen > as a step forward. I wouldn't mind it though. > If it is generally accepted as a good idea, we should build up the > infrastructure for that kind of packages and installations in parallel > to what we have now. > > It would definitely not be the native Windows-installer user experience > then ;-) > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Mon Jul 19 17:04:22 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Jul 2010 15:04:22 +0000 Subject: [M3devel] moving to new target names, in Hudson? In-Reply-To: <20100719144722.81DB41A208C@async.async.caltech.edu> References: , , <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com>, , <20100719090459.4CE191A2084@async.async.caltech.edu>, , <20100719110208.011521A2091@async.async.caltech.edu> , <20100719144722.81DB41A208C@async.async.caltech.edu> Message-ID: BUILD_DIR = "MIKAS_ENVIRONMENT_USING_CM3_5_8_6_WITH_THREADS_HACKS_ON_FREEBSD_4_11_I386" TARGET = "FreeBSD4" yes. I can't say I've ever done it, but it is supposed to work, and there is the profile precedent Olaf mentioned. Now, let's ask ourselves something important. Where does it ship to? Either it ships to BUILD_DIR, good, you get to rebuild everything (m3core, libm3, etc.) whenever you change BUILD_DIR. Or it ships to TARGET and my story is completely wrong. Unless we change it to BUILD_DOR. Let me see. We ship to build_dor. And I'm proposing...devil will in the details, actually doing it, seeing if it works out..if the config file sets word size (it already does, long ago), endian (I added recently), jmpbuf size... then TARGET might become even less meaningful. I think the alignments are all the same. The types are all the same, given word size. The floating point types are all the same, for now (I'm threatening to add VAX and 80bit x86 long double), but still that could be config file... then the compiler (cm3) is left knowing nothing of any predefined targets.. Currently TARGET must be from within a list the compiler knows about. BUILD_DIR is supposed to be arbitrary. The "ship no resolution" stuff has some dependency that build_dir == target, but that's ok. ?- Jay ---------------------------------------- > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] moving to new target names, in Hudson? > Date: Mon, 19 Jul 2010 07:47:22 -0700 > From: mika at async.async.caltech.edu > > > Well Jay, from the user's point of view it really doesn't matter whether > cm3 is one binary or many... BUILD_DIR has more to do with whether > the binaries that it produces can run on one platform or many. > > But from what I gather from your email, the idea seems to be that you > can have many targets in one compiler and the user of the compiler > can set BUILD_DIR himself, as he pleases? That would be wonderful... > Does it work to do that? Can I just change BUILD_DIR to, say, > > MIKAS_ENVIRONMENT_USING_CM3_5_8_6_WITH_THREADS_HACKS_ON_FREEBSD_4_11_I386 > > and have everything work for me? > > Mika > > Jay K writes: > > > >Well=2C from the compiler (cm3=2C cm3cg) and libraries (m3core/*.m3=2C etc.= > >) point of view=2C now=2C all I386_FREEBSD are the same. > >=A0They are all little endian=2C 32bit word=2C have the same jmpbuf=2C and = > >no stack walker. > >=A0(Ok=2C there's a small difference in that older FreeBSD might not have d= > >ecent enough pthreads. > >=A0 So we should really maybe have I386_FREEBSD_pthreads and I386_FREEBSD_u= > >serthreads. > >=A0=A0=A0 But this still is overkill. They are still identical in cm3 and c= > >m3cg. They vary only in m3core/*/m3makefile. > >=A0=A0 I think this is best done by making the "thread library" a variable = > >that the user can edit in config file. > >=A0=A0 And maybe gets appended to BUILD_DIR. But TARGET is unchanged.) > > > > > >Any differences or binary compatibilities aren't present until m3core/*.c #= > >includes varying headers. > >I think it makes more sense probably for people to start editing BUILD_DIR = > >in their config files. > >=A0 I386_FREEBSD1=20 > >=A0 I386_FREEBSD2=20 > >=A0 > >I386_FREEBSD3=20 > >=A0 > >I386_FREEBSD4=20 > >=A0 > >I386_FREEBSD5=20 > >=A0 > >I386_FREEBSD6=20 > >=A0 > >I386_FREEBSD7=20 > >=A0 I386_FREEBSD8 > >=A0 I386_SOLARIS2.8 =A0=20 > > > > > > > >=A0 I386_SOLARIS2.9=A0=20 > > > > > >=A0 I386_SOLARIS2.10=20 > > > > > > > >=A0 I386_SOLARIS2.11=A0=20 > > > > > > > > > >Exposing this explosion in more than maybe one directory=2C I quite dislike= > >. > >They could be config files that set BUILD_DIR=2C maybe THREAD_LIBRARY (whic= > >h I just made up) and then include(I386_FREEBSD). > >I like to think they are "configurations"=2C lightweight toplevel things=2C= > > many of them=2C that quickly devolve into a small number of "targets". > > > > > > > >Maybe what we should really=2C like=2C is run config.guess and use its enti= > >re output: i386-unknown-freebsd4.11 > >Unknown is unsightly.. Specifically for BUILD_DIR. TARGET would be somehow = > >computed from that? > > > > > > > > > >BUILD_DIR is arbitrary. See how profiling appends "p" to it? Not that I eve= > >r use that. > >Perhaps not that anyone ever has TARGET !=3D BUILD_DIR. > >=A0 Though that is how Modula-3 works for Cygwin. > > > > > >I am slowly believing in the way of autoconf and the GNU build system. It m= > >ust be observed. > >On one hand that exposes a combinatorial explosion of configurations. > >On the other=2C it avoids canonizing any particular combination as special.= > >=20 > > > > > >If cm3 were to discover jmpbuf size in some sort of autoconf-ish thing=2C a= > >nd record that merely in the config file=2C > >we'd be left with basically only four architectures in cm3: little endian32= > >=2C little endian64=2C big endian32=2C big endian64. > > > > > >Heck=2C it doesn't even need to be autoconfish. It just needs to be in the = > >config files. > >And a very small number of other things: the name of setjmp (_setjmp or set= > >jmp)=2C if there is a stack walker (usually false but sometimes true). > > > > > > > >=A0- Jay > > > >---------------------------------------- > >> To: jay.krell at cornell.edu > >> Date: Mon=2C 19 Jul 2010 04:02:07 -0700 > >> From: mika at async.async.caltech.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] moving to new target names=2C in Hudson? > >> > >> Jay K writes: > >> > > >> >The old target names are still available. > >> > > >> > > >> ... > >> > > >> >*However* notice that cm3 is *not* preconfigured/predisposed for any par= > >tic=3D > >> >ular target. > >> > >> cm3 -version prints a target... > >> > >> > > >> > > >> >It has a list of targets and it can handle any of them. The config file = > >dec=3D > >> >ides the target. > >> >=3DA0In fact=3D2C neither cm3 nor the config files are particularly know= > >ledable=3D > >> > about targets. > >> >=3DA0 The config files vary a little in how they run the compiler or lin= > >ker. > >> >=3DA0 cm3 varies mainly in word size=3D2C endianness=3D2C and jmpbuf siz= > >e. > >> >=3DA0 All the real work of knowing about targets is buried in gcc. > >> >=3DA0 And a smattering of #ifdefs in C code. Some of which could be push= > >ed to=3D > >> > autoconf. > >> > > >> > > >> >The old names confuse people -- you=3D2C for example. > >> >They are inconsistent. > >> >They don't specify processor architecture. > >> > > >> > >> Well I agree with that much.. > >> > >> > > >> >What pain did you all go through when FreeBSD changed to FreeBSD2 change= > >d t=3D > >> >o FreeBSD3 changed to FreeBSD4? > >> >Or LINUX to LINUXELF to LINUXLIBC6? > >> >So long ago nobody remembers? > >> >I used LINUXELF a little=3D2C built it=3D2C went away=3D2C came back and= > > there wa=3D > >> >s LINUXLIBC6. I had no code. It didn't matter to me. > >> > > >> > >> The point of these names=2C I thought=2C was that they were supposed to m= > >ap > >> to binary-incompatible systems. I remember having FreeBSD2 and FreeBSD3 > >> at the same time. We had a cluster with machines with both OSes=2C which > >> were not binary compatible. The point is so that you can run cm3/m3build > >> for both in the same repository (even concurrently)=2C and not have them > >> interfere with each other. It's not a pain to have different names > >> if they actually mean different things. If you just call everything > >> I386_FREEBSD all hell will break loose in that situation... (just as when > >> I by mistake run "FreeBSD4" (really FreeBSD6) CM3 in a directory where > >> I have already compiled things with "FreeBSD4" (really FreeBSD4) PM3...) > >> > >> Or am I misunderstanding something here? I would have thought you really > >> wanted to have a different name for each binary-incompatible system so > >> you can build them all in the same place. Consistency in naming would be > >> nice but I think it is secondary. > >> > >> Mika > > = From wagner at elegosoft.com Tue Jul 20 08:25:12 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 20 Jul 2010 08:25:12 +0200 Subject: [M3devel] NT386 builds fail on m3cc, was: Fwd: Re: elego-win-vm again Message-ID: <20100720082512.3ec0051v4ok8swo0@mail.elegosoft.com> It seems that current tries to build m3cc for NT386, which it shouldn't do and therefore fails. Why has this been changed? See http://hudson.modula3.com:8080/job/cm3-current-build-NT386/6/console for details. Please fix! Olaf ----- Forwarded message from michael.anderson at elego.de ----- Date: Mon, 19 Jul 2010 23:05:53 +0200 From: Michael Anderson Reply-To: Michael Anderson Subject: Re: elego-win-vm again To: Olaf Wagner Cc: manderson at elego.de, khaeusler at elego.de Quoting Olaf Wagner : > Can we somehow get that vm back online for some builds? > > http://hudson.modula3.com:8080/computer/elego-win-vm/log > Well, the vm is alive again, but the cm3-current-build-NT386 job is dying here: ... /home/elego/workspace/cm3-current-build-NT386/cm3/scripts/install-cm3-compiler.sh upgrade cp /home/elego/work/cm3-inst/wagner/current--release-build/bin/cm3.exe /home/elego/work/cm3-inst/wagner/current--release-build/bin/cm3-d5.8.2.exe cp_if: source does not exist: /home/elego/work/cm3-inst/wagner/current--release-build/bin/cm3cg Finished: FAILURE Where is cm3cg supposed to come from? > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 ----- End forwarded message ----- -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Tue Jul 20 08:51:03 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 20 Jul 2010 08:51:03 +0200 Subject: [M3devel] spin sources Message-ID: <1279608663.2648.3.camel@localhost> I tried to get them few moments ago, and download link is dead... Does anybody have them? -- Dragi?a Duri? From mark at wickensonline.co.uk Tue Jul 20 09:26:43 2010 From: mark at wickensonline.co.uk (Mark Wickens) Date: Tue, 20 Jul 2010 08:26:43 +0100 Subject: [M3devel] Just putting it out there... In-Reply-To: References: , , <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com> , , <20100719090459.4CE191A2084@async.async.caltech.edu> , , <20100719110208.011521A2091@async.async.caltech.edu> , <20100719143844.03al7scsg0g400so@mail.elegosoft.com> Message-ID: <1279610803.1935.1.camel@x60.appsoftint.co.uk> Hi guys, Has there been any discussion/moves about implementing Modula-3 as a language that runs on the Sun JVM? Seems a logical step given the similarities of Java to Modula-3 (I got that phrase the right way round, didn't I?) That is something I would definitely be able to provide help for. Regards, Mark. From mark at wickensonline.co.uk Tue Jul 20 09:33:09 2010 From: mark at wickensonline.co.uk (Mark Wickens) Date: Tue, 20 Jul 2010 08:33:09 +0100 Subject: [M3devel] Another thing Message-ID: <1279611189.1935.3.camel@x60.appsoftint.co.uk> Hi guys, I just subscribed to comp.os.modula3 and noticed the 5.8.6 release note - does the recent work on Digital Unix/tru64 platform mean that it will be promoted to an 'official' platform? Regards, Mark From jay.krell at cornell.edu Tue Jul 20 11:22:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 20 Jul 2010 09:22:39 +0000 Subject: [M3devel] Another thing In-Reply-To: <1279611189.1935.3.camel@x60.appsoftint.co.uk> References: <1279611189.1935.3.camel@x60.appsoftint.co.uk> Message-ID: Not for 5.8.6. It is already done and the changes for Mika and you are in "head". Maybe for the 5.9 release. I'm not sure the distinction matters. I don't think many people are using OSF1 any longer. You have a working system. Modulo the inefficient exception handling, like all other platforms (with one exception). Will you be using it much/long? Maybe you can try building it yourself, and then stay up to date with CVS and rebuild/test? Currently to do a "proper", "full", somewhat tested release requires recent Java 1.5 and sshd on a system. The distribution format might change or optionally change in 5.9 so we can provide a "full" albeit untested release for platforms we don't have automation on. - Jay > From: mark at wickensonline.co.uk > To: m3devel at elegosoft.com > Date: Tue, 20 Jul 2010 08:33:09 +0100 > Subject: [M3devel] Another thing > > Hi guys, > > I just subscribed to comp.os.modula3 and noticed the 5.8.6 release note > - does the recent work on Digital Unix/tru64 platform mean that it will > be promoted to an 'official' platform? > > Regards, Mark > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 20 12:31:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 20 Jul 2010 10:31:31 +0000 Subject: [M3devel] some current/hudson problems? Message-ID: 1) Is cm3-current-build-target supposed to build everything, ? or not much more than the compiler? I looked at a a few (I386_OPENBSD, FreeBSD4, LINUXLIBC6) and they aren't building much more than compiler. Or is that supposed to be deferred to test-all? I was wanting to check if I386_OPENBSD hung. ? Either way, I think I have the fix. ? ? 2) cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/INSTALL' cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/fixincludes' I believe this is an artifact of cvs not working well in general. In particular, switching branches, doesn't handle deletes, or something. 3) "/home/hudson/workspace/cm3-current-test-all-pkgs-SOLgnu/ cm3/m3-db/odbc/src/m3makefile", line 4: quake runtime error: undefined variable: configure_system_libs My fault. I'll fix. ?- Jay From jay.krell at cornell.edu Tue Jul 20 12:46:47 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 20 Jul 2010 10:46:47 +0000 Subject: [M3devel] NT386 builds fail on m3cc, was: Fwd: Re: elego-win-vm again In-Reply-To: <20100720082512.3ec0051v4ok8swo0@mail.elegosoft.com> References: <20100720082512.3ec0051v4ok8swo0@mail.elegosoft.com> Message-ID: Olaf, I see what you mean in Hudson/current. I haven't compared to Hudson/release. I haven't pieced much together here as to what is going on. I do see precious few uses of FilterPackages in release or head though. Surprising. ?- Jay ---------------------------------------- > Date: Tue, 20 Jul 2010 08:25:12 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] NT386 builds fail on m3cc, was: Fwd: Re: elego-win-vm again > > It seems that current tries to build m3cc for NT386, which it shouldn't > do and therefore fails. > > Why has this been changed? > > See http://hudson.modula3.com:8080/job/cm3-current-build-NT386/6/console > for details. > > Please fix! > > Olaf > > ----- Forwarded message from michael.anderson at elego.de ----- > Date: Mon, 19 Jul 2010 23:05:53 +0200 > From: Michael Anderson > Reply-To: Michael Anderson > Subject: Re: elego-win-vm again > To: Olaf Wagner > Cc: manderson at elego.de, khaeusler at elego.de > > Quoting Olaf Wagner : > > > Can we somehow get that vm back online for some builds? > > > > http://hudson.modula3.com:8080/computer/elego-win-vm/log > > > > > Well, the vm is alive again, but the cm3-current-build-NT386 job is > dying here: > > > ... > /home/elego/workspace/cm3-current-build-NT386/cm3/scripts/install-cm3-compiler.sh > upgrade > cp /home/elego/work/cm3-inst/wagner/current--release-build/bin/cm3.exe > /home/elego/work/cm3-inst/wagner/current--release-build/bin/cm3-d5.8.2.exe > cp_if: source does not exist: > /home/elego/work/cm3-inst/wagner/current--release-build/bin/cm3cg > Finished: FAILURE > > Where is cm3cg supposed to come from? > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > > > -- > Michael Anderson > IT Services & Support > > elego Software Solutions GmbH > Gustav-Meyer-Allee 25 > Building 12.3 (BIG) room 227 > 13355 Berlin, Germany > > phone +49 30 23 45 86 96 michael.anderson at elegosoft.com > fax +49 30 23 45 86 95 http://www.elegosoft.com > > Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin > Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 > > > > > ----- End forwarded message ----- > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Tue Jul 20 13:26:42 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 20 Jul 2010 11:26:42 +0000 Subject: [M3devel] NT386 builds fail on m3cc, was: Fwd: Re: elego-win-vm again In-Reply-To: References: <20100720082512.3ec0051v4ok8swo0@mail.elegosoft.com>, Message-ID: I had churned sysinfo.sh a lot in head. With some reason -- it was confusing when ? it was defaulting stuff vs. when it was deciding stuff that should affect defaulting. I made it first decide TARGET, then decide what follows from target. It should be clearer now. There was an obvious problem though. if xFOO = BAR instead of xFOO = xBAR or FOO=BAR. And an unclear part, given my ignorance of sh, if the spaces mean anything in a case. Both fixed. We'll see. FilterPackages isn't entirely relevant. UsePackage is similar, and used. ?(I looked at the release console output to get some hints.) Thanks for the heads up, ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Date: Tue, 20 Jul 2010 10:46:47 +0000 > Subject: Re: [M3devel] NT386 builds fail on m3cc, was: Fwd: Re: elego-win-vm again > > > Olaf, I see what you mean in Hudson/current. > I haven't compared to Hudson/release. > I haven't pieced much together here as to what is going on. > I do see precious few uses of FilterPackages in release or head though. Surprising. > > - Jay > > ---------------------------------------- > > Date: Tue, 20 Jul 2010 08:25:12 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: [M3devel] NT386 builds fail on m3cc, was: Fwd: Re: elego-win-vm again > > > > It seems that current tries to build m3cc for NT386, which it shouldn't > > do and therefore fails. > > > > Why has this been changed? > > > > See http://hudson.modula3.com:8080/job/cm3-current-build-NT386/6/console > > for details. > > > > Please fix! > > > > Olaf > > > > ----- Forwarded message from michael.anderson at elego.de ----- > > Date: Mon, 19 Jul 2010 23:05:53 +0200 > > From: Michael Anderson > > Reply-To: Michael Anderson > > Subject: Re: elego-win-vm again > > To: Olaf Wagner > > Cc: manderson at elego.de, khaeusler at elego.de > > > > Quoting Olaf Wagner : > > > > > Can we somehow get that vm back online for some builds? > > > > > > http://hudson.modula3.com:8080/computer/elego-win-vm/log > > > > > > > > > Well, the vm is alive again, but the cm3-current-build-NT386 job is > > dying here: > > > > > > ... > > /home/elego/workspace/cm3-current-build-NT386/cm3/scripts/install-cm3-compiler.sh > > upgrade > > cp /home/elego/work/cm3-inst/wagner/current--release-build/bin/cm3.exe > > /home/elego/work/cm3-inst/wagner/current--release-build/bin/cm3-d5.8.2.exe > > cp_if: source does not exist: > > /home/elego/work/cm3-inst/wagner/current--release-build/bin/cm3cg > > Finished: FAILURE > > > > Where is cm3cg supposed to come from? > > > > > Olaf > > > -- > > > Olaf Wagner -- elego Software Solutions GmbH > > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > > > > > > > -- > > Michael Anderson > > IT Services & Support > > > > elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 > > Building 12.3 (BIG) room 227 > > 13355 Berlin, Germany > > > > phone +49 30 23 45 86 96 michael.anderson at elegosoft.com > > fax +49 30 23 45 86 95 http://www.elegosoft.com > > > > Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin > > Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 > > > > > > > > > > ----- End forwarded message ----- > > > > > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > > From jay.krell at cornell.edu Tue Jul 20 14:28:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 20 Jul 2010 12:28:36 +0000 Subject: [M3devel] LongrealType missed, was: Re: "FreeBSD4" false advertising In-Reply-To: References: <20100714094120.93B001A2098@async.async.caltech.edu>, <20100714114648.nhnwruh008840wso@mail.elegosoft.com>, <20100714100138.631581A2098@async.async.caltech.edu>, <20100714100525.BEE931A2096@async.async.caltech.edu>, , <20100714104312.155351A2098@async.async.caltech.edu>, <20100714125516.1mzfehgnkgcs800w@mail.elegosoft.com>, Message-ID: Mika, did this work for you? ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > CC: mika at async.caltech.edu > Subject: RE: LongrealType missed, was: Re: [M3devel] "FreeBSD4" false advertising > Date: Wed, 14 Jul 2010 11:23:49 +0000 > > > Mika, Please try updating libm3 and see if that works for you. Thanks. > > - Jay > > ---------------------------------------- > > Date: Wed, 14 Jul 2010 12:55:16 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > CC: jay.krell at cornell.edu; mika at async.caltech.edu > > Subject: LongrealType missed, was: Re: [M3devel] "FreeBSD4" false advertising > > > > Quoting Mika Nystrom : > > > > > Argh is it really necessary to break source compatibility here? > > > > > > I also don't like that I as a client have to import IEEE things when all > > > I want is "LONGREAL" (and let Modula-3 do whatever it wants with that). > > > > > > I would propose at least having an interface LongrealType with > > > > > > CONST Hash = Longreal.Hash > > > > > > etc. so as not to force clients to import all the nitty-gritty about > > > various floating point representations. And so as not to break source > > > compatibility! If I change this by removing Type, my code will no longer > > > compile with the old compilers.... > > > > Hm, I'm a little bit out of context here... > > What was the reason for this change? It seems nobody else has bothered > > so far. > > > > This was the commit in question: > > > > 2009-12-23 21:43 hosking > > > > * m3-libs/: m3core/src/m3makefile, libm3/src/types/ASCII.i3, > > libm3/src/types/ASCII.m3, libm3/src/types/Boolean.i3, > > libm3/src/types/Boolean.m3, libm3/src/types/COPYRIGHT-CMASS, > > libm3/src/types/Char.i3, libm3/src/types/Char.m3, > > libm3/src/types/Int32.i3, libm3/src/types/Int32.m3, > > libm3/src/types/Int64.i3, libm3/src/types/Int64.m3, > > libm3/src/types/Integer.i3, libm3/src/types/Integer.m3, > > libm3/src/types/Longint.i3, libm3/src/types/Longint.m3, > > libm3/src/types/LongrealType.i3, libm3/src/types/LongrealType.m3, > > libm3/src/types/RealType.i3, libm3/src/types/RealType.m3, > > libm3/src/types/Refany.i3, libm3/src/types/Refany.m3, > > libm3/src/types/Unicode.i3, libm3/src/types/Unicode.m3, > > libm3/src/types/WideChar.i3, libm3/src/types/WideChar.m3, > > libm3/src/types/m3makefile, m3core/src/float/Common/Extended.m3, > > m3core/src/float/Common/LongReal.m3, m3core/src/float/Common/Real.m3, > > m3core/src/float/IEEE/Extended.i3, m3core/src/float/IEEE/LongReal.i3, > > m3core/src/float/IEEE/Real.i3, m3core/src/float/VAX/Extended.i3, > > m3core/src/float/VAX/LongReal.i3, m3core/src/float/VAX/Real.i3: > > > > Move libm3/src/types into m3core. > > Note that LongrealType and RealType have been folded into m3core/src/float. > > Clients will need adjustment. > > > > Any comments? > > > > Olaf > > > > > Mika > > > > > > Jay K writes: > > >> > > >> Remove "Type" it appears. > > >> > > >> > > >> http://modula3.elegosoft.com/cm3/ChangeLog-2009 > > >> > > >> search for "clients will need". > > >> > > >> e.g. > > >> > > >> +++ cm3/m3-demo/mentor/src/binpack/m3makefile 2009/12/23 22:05:06 1.2 > > >> @@ -10=2C7 +10=2C7 @@ > > >> =20 > > >> import ("zeus") > > >> =20 > > >> -list ("Real"=2C "RealType") > > >> +list ("Real"=2C "Real") > > >> =20 > > >> zume ("Binpack") > > >> oblume ("Binpack"=2C "myview") > > >> > > >> --- cm3/m3-demo/mentor/src/binpack/RealList.i3 2001/01/13 14:18:20 1.1 > > >> +++ cm3/m3-demo/mentor/src/binpack/RealList.i3 2009/12/23 22:05:05 1.2 > > >> @@ -2=2C4 +2=2C4 @@ > > >> (* Distributed only by permission. *) > > >> (* Last modified on Fri Jul 9 16:36:47 PDT 1993 by mhb *) > > >> =20 > > >> -INTERFACE RealList =3D List(RealType) END RealList. > > >> +INTERFACE RealList =3D List(Real) END RealList. > > >> > > >> --- cm3/m3-demo/mentor/src/binpack/RealList.m3 2001/01/13 14:18:20 1.1 > > >> +++ cm3/m3-demo/mentor/src/binpack/RealList.m3 2009/12/23 22:05:06 1.2 > > >> @@ -2=2C4 +2=2C4 @@ > > >> (* All rights reserved. *) > > >> (* See the file COPYRIGHT for a full description. *) > > >> =20 > > >> -MODULE RealList =3D List(RealType) END RealList. > > >> +MODULE RealList =3D List(Real) END RealList. > > >> > > >> =A0- Jay > > >> > > >> ---------------------------------------- > > >>> To: wagner at elegosoft.com > > >>> CC: jay.krell at cornell.edu=3B mika at async.caltech.edu > > >>> Subject: Re: [M3devel] "FreeBSD4" false advertising > > >>> Date: Wed=2C 14 Jul 2010 03:05:25 -0700 > > >>> From: mika at async.async.caltech.edu > > >>> > > >>> I'm not actually sure I understand the intent of the changes in this area= > > >> . > > >>> > > >>> My old m3makefile has: > > >>> > > >>> Table("TextLongReal"=2C "Text"=2C "LongrealType") > > >>> > > >>> What am I supposed to use now? > > >>> > > >>> Mika > > >>> > > >>> Mika Nystrom writes: > > >>> >Olaf Wagner writes: > > >>> >>Quoting Mika Nystrom : > > >>> >> > > >>> >>> Hi Jay=2C Olaf=2C > > >>> >>> > > >>> >>> I actually built everything! After backing out some of my changes > > >>> >>> that I had tried to get 5.8.6-REL to build with=2C it worked=2C and m= > > >> entor > > >>> >>> ran=2C even. > > >>> >> > > >>> >>Great! So it's still possible to build cm3 on FreeBSD 4=2C though > > >>> >>not our release code. > > >>> > > > >>> >The differences relative to the current CVS head are very minor. > > >>> > > > >>> >1. Added FreeBSD4 to thread.quake as a non-pthread platform > > >>> > > > >>> >2. got rid of the -m32 flags in FreeBSD4.conf > > >>> > > > >>> >Everything else that needed to change I think Jay has managed to put in > > >>> >the CVS head. > > >>> > > > >>> >> > > >>> >>> But... what happened to libm3/src/types? Building my own code I get > > >>> >>> the following errors: > > >>> >>> > > >>> >>> new source -> compiling LRInterval.i3 > > >>> >>> "../FreeBSD4/LRInterval.i3 =3D3D> ../src/Interval.ig"=2C line 5: unab= > > >> le to =3D20 > > >>> >>> find interface (LongrealType) > > >>> >>> 1 error encountered > > >>> >>> > > >>> >>> I can't find LongrealType anywhere=2C do I have a broken checkout? We= > > >> ll=2C it > > >>> >>> is in one place=2C in "doc". (Same for RealType=2C maybe others?) > > >>> >> > > >>> >>See =3D20 > > >>> >>http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/t= > > >> ypes/=3D > > >>> >>Attic/LongrealType.i3 > > >>> > > > >>> >Surely this is wrong?? I am looking for an interface that has T =3D > > >>> >LONGREAL=2C not something that lets me muck around with the representati= > > >> on > > >>> >of IEEE=2C VAX=2C etc.=2C floating-point formats. > > >>> > > > >>> >Why is it even in m3core? This seems clearly like libm3 stuff.. I notice= > > >> d > > >>> >Boolean.i3 also moved. > > >>> > > > >>> >Also if there is no importable interface called LongrealType that is goi= > > >> ng > > >>> >to cause endless problems with source that is supposed to compile under > > >>> >different versions of Modula-3. Even relatively recent CM3s required > > >>> >you to use LongrealType to instantiate generics. > > >>> > > > >>> > Mika > > >> = > > > > > > > > > > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 m3 at sol42.com Tue Jul 20 14:28:45 2010 From: m3 at sol42.com (m3 at sol42.com) Date: Tue, 20 Jul 2010 14:28:45 +0200 Subject: [M3devel] spin sources In-Reply-To: <1279608663.2648.3.camel@localhost> References: <1279608663.2648.3.camel@localhost> Message-ID: <27F80E57-716A-47ED-95DE-A73B51E580ED@sol42.com> Hello. I have spin-33.2.tar.gz from many many years ago. It is now available at http://www.sol42.com/spin-33.2.tar.gz Its size is 27.675.835 bytes compressed, 119.961.600 uncompressed. MD5 (spin-33.2.tar.gz) = 8fcd9457f1298eaef8819a21ab931712 GNU tar complains about zero data at the end of the archive, Solaris tar just stops there. Hopefully nothing is missing. Regards. -Daniel From wagner at elegosoft.com Tue Jul 20 14:48:14 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 20 Jul 2010 14:48:14 +0200 Subject: [M3devel] some current/hudson problems? In-Reply-To: References: Message-ID: <20100720144814.p091gtc6g0kggwwg@mail.elegosoft.com> Quoting Jay K : > 1) > Is cm3-current-build-target supposed to build everything, > ? or not much more than the compiler? > > I looked at a a few (I386_OPENBSD, FreeBSD4, LINUXLIBC6) and they > aren't building much more than compiler. Just the core system and perform an `upgrade' if needed. > Or is that supposed to be deferred to test-all? cm3-current-test-all-pkgs will build everything and perform all associated regression tests. If will also write reports in XML and HTML format. > I was wanting to check if I386_OPENBSD hung. > ? Either way, I think I have the fix. > ? > 2) > cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/INSTALL' > cvs update: use `cvs add' to create an entry for > `m3-sys/m3cc/gcc/fixincludes' > > I believe this is an artifact of cvs not working well in general. > In particular, switching branches, doesn't handle deletes, or something. Probably some confused workspace entries; should not be critical. > 3) > "/home/hudson/workspace/cm3-current-test-all-pkgs-SOLgnu/ > cm3/m3-db/odbc/src/m3makefile", line 4: quake runtime error: > undefined variable: > configure_system_libs > > My fault. I'll fix. Fine. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Jul 20 15:26:33 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 20 Jul 2010 09:26:33 -0400 Subject: [M3devel] Just putting it out there... In-Reply-To: <1279610803.1935.1.camel@x60.appsoftint.co.uk> References: , , <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com> , , <20100719090459.4CE191A2084@async.async.caltech.edu> , , <20100719110208.011521A2091@async.async.caltech.edu> , <20100719143844.03al7scsg0g400so@mail.elegosoft.com> <1279610803.1935.1.camel@x60.appsoftint.co.uk> Message-ID: Running Modula-3 on the Sun JVM poses several difficulties, not least that Modula-3 is a systems programming language like C/C++. Getting C, C++, or Modula-3 to run on the JVM would all be the same level of difficulty. The safe subset of Modula-3 would be less difficult, but the unsafe operations would probably be a showstopper. On the other hand, at one point there was a version of Java running in the Modula-3 run-time. On 20 Jul 2010, at 03:26, Mark Wickens wrote: > Hi guys, > > Has there been any discussion/moves about implementing Modula-3 as a > language that runs on the Sun JVM? > > Seems a logical step given the similarities of Java to Modula-3 (I got > that phrase the right way round, didn't I?) > > That is something I would definitely be able to provide help for. > > Regards, Mark. From mark at wickensonline.co.uk Tue Jul 20 15:36:50 2010 From: mark at wickensonline.co.uk (Mark Wickens) Date: Tue, 20 Jul 2010 14:36:50 +0100 Subject: [M3devel] Just putting it out there... In-Reply-To: References: , , <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com> , , <20100719090459.4CE191A2084@async.async.caltech.edu> , , <20100719110208.011521A2091@async.async.caltech.edu> , <20100719143844.03al7scsg0g400so@mail.elegosoft.com> <1279610803.1935.1.camel@x60.appsoftint.co.uk> Message-ID: <1279633010.1935.11.camel@x60.appsoftint.co.uk> Tony, Yes, after I'd written the email and thought about it I realised it was a pretty stupid idea. Mark. On Tue, 2010-07-20 at 09:26 -0400, Tony Hosking wrote: > Running Modula-3 on the Sun JVM poses several difficulties, not least that Modula-3 is a systems programming language like C/C++. Getting C, C++, or Modula-3 to run on the JVM would all be the same level of difficulty. The safe subset of Modula-3 would be less difficult, but the unsafe operations would probably be a showstopper. On the other hand, at one point there was a version of Java running in the Modula-3 run-time. > > On 20 Jul 2010, at 03:26, Mark Wickens wrote: > > > Hi guys, > > > > Has there been any discussion/moves about implementing Modula-3 as a > > language that runs on the Sun JVM? > > > > Seems a logical step given the similarities of Java to Modula-3 (I got > > that phrase the right way round, didn't I?) > > > > That is something I would definitely be able to provide help for. > > > > Regards, Mark. > From jay.krell at cornell.edu Tue Jul 20 15:39:46 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 20 Jul 2010 13:39:46 +0000 Subject: [M3devel] merging gdb from 6.4 to 7.1? Message-ID: The merge of m3cc/gcc from 4.3.0 to 4.3.5 went well enough. I'll volunteer to merge m3gdb from 6.4 to 7.1. Are people interested? I saw some mention of 6.4.3 in our history. But there's no release called that. What is it? Some of the conflicts are about? SYMBOL_TYP vs. LHS_SYMBOL_TYPE. What that a deliberate important change on our port? Thanks, ?- Jay From m3 at sol42.com Tue Jul 20 16:14:30 2010 From: m3 at sol42.com (m3 at sol42.com) Date: Tue, 20 Jul 2010 16:14:30 +0200 Subject: [M3devel] Just putting it out there... In-Reply-To: <1279633010.1935.11.camel@x60.appsoftint.co.uk> References: , , <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com> , , <20100719090459.4CE191A2084@async.async.caltech.edu> , , <20100719110208.011521A2091@async.async.caltech.edu> , <20100719143844.03al7scsg0g400so@mail.elegosoft.com> <1279610803.1935.1.camel@x60.appsoftint.co.uk> <1279633010.1935.11.camel@x60.appsoftint.co.uk> Message-ID: On 20 Jul 2010, at 15:36, Mark Wickens wrote: > Yes, after I'd written the email and thought about it I realised it was > a pretty stupid idea. Well, not stupid at all. Java may suck but the JVM certainly does not. There is a lot of interest now in compiling languages other than Java on the JVM, which has turned out to be a sort of universal runtime. Only that it was designed with Java in mind, and you would end up with something *like* Modula-3, not Modula-3 itself: what you can do in JVM "assembly" is limited, no PACKED types, no BITS x FOR y .. z, LOOPHOLE may or may not be always possible, UNTRACED would be problematic, pointer arithmetic in UNSAFE modules might require JNI and who knows what else, forget about <*EXTERNAL*> C calls, full interoperability with Java would require supporting Java interfaces (at the language level I think)... and these are just the few I can think of right now. On the other hand I would really like to code in this superset-of-a-subset of Modula-3 and run it on a JVM. Regarding the Critical Mass JVM described in Threads 3, are the sources available? Regards. -Daniel From dabenavidesd at yahoo.es Tue Jul 20 16:17:02 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 20 Jul 2010 14:17:02 +0000 (GMT) Subject: [M3devel] Just putting it out there... In-Reply-To: Message-ID: <562804.32217.qm@web23606.mail.ird.yahoo.com> Hi all: Its interesting that after all, being Modula-3 a systems programming language any of its unsafe features are still as it is written in Modula-3 itself no harm to the Modula-3 runtime itself you can isolate the unsafe features to allow pretty clean representation of the system. Java had from the beginning an unsafe feature (not sure what it looks today) for type checking unsound with respect to its static semantics a type rule of array of objects subtyping, but they cleaned the missing check in the JVM as a runtime error. Original JVM M3 implementation had a C based interface to it so you could run things in the native part of a Java execution using Modula-3 runtime fetures which doesn't allow messing with the safe modules but they can play with it. In the other hand SPIN had some small extensions to allow type checking of some extra type rules to allow dynamic conversions in a safe way. It allows a little bit of extra freedom. So both solutions could create a space for executing, for handling unsafe features to pass under safe threshold. Hope it helps --- El mar, 20/7/10, Tony Hosking escribi?: > De: Tony Hosking > Asunto: Re: [M3devel] Just putting it out there... > Para: "Mark Wickens" > CC: "m3devel" > Fecha: martes, 20 de julio, 2010 08:26 > Running Modula-3 on the Sun JVM poses > several difficulties, not least that Modula-3 is a systems > programming language like C/C++. Getting C, C++, or > Modula-3 to run on the JVM would all be the same level of > difficulty. The safe subset of Modula-3 would be less > difficult, but the unsafe operations would probably be a > showstopper. On the other hand, at one point there was > a version of Java running in the Modula-3 run-time. > > On 20 Jul 2010, at 03:26, Mark Wickens wrote: > > > Hi guys, > > > > Has there been any discussion/moves about implementing > Modula-3 as a > > language that runs on the Sun JVM? > > > > Seems a logical step given the similarities of Java to > Modula-3 (I got > > that phrase the right way round, didn't I?) > > > > That is something I would definitely be able to > provide help for. > > > > Regards, Mark. > > From rodney_bates at lcwb.coop Tue Jul 20 17:20:38 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 20 Jul 2010 10:20:38 -0500 Subject: [M3devel] merging gdb from 6.4 to 7.1? In-Reply-To: References: Message-ID: <4C45BEC6.40603@lcwb.coop> I have been thinking about doing this myself for some time, but up to now, have not had the time. I can certainly help, if you want to do it, or maybe take it on myself. I think I will be having more time soon. I have done it a couple of times before. A few things can be hard to figure out, because they rework existing stuff in gdb and it's hard to dig out what the new equivalent of the old mechanism is. A lot of the M3-specific code I either heavily modified or wrote. Jay K wrote: > The merge of m3cc/gcc from 4.3.0 to 4.3.5 went well enough. > > I'll volunteer to merge m3gdb from 6.4 to 7.1. BTW, there is now or will be very soom, a 7.2 gdb. Also, the latest gdb does reverse debugging, by recording snapshots during the forward run. This would be a *very* nice feature to have for Modula-3. > > Are people interested? > > I saw some mention of 6.4.3 in our history. > But there's no release called that. > What is it? I don't remember anything about this. > > Some of the conflicts are about SYMBOL_TYP vs. LHS_SYMBOL_TYPE. > What that a deliberate important change on our port? Yes, this is my change, very deliberate, and gets around a nasty group of dangling pointer bugs. I would have to took at it again, but it used to cache a pointer to a gdb type struct, lazily looked- up the first time, right into an existing field of another gdb struct. When you rerun, gdb reloads the referent structs of such pointers, leaving them dangling. Or maybe I am mixing up two different problems. Anyway, the two macros are essential. I have long thought it might be nice to design a better mechanism, but it's not simple. I strongly recommend not messing with it during merging to a newer gdb. Save that for a subsequent job with a separate CVS tag. It's only a performance matter, and except for debugging work that proceeds without requiring user-types commands all the time, it scarcely matters. Also, we would be a lot better off to dump stabs+ and use whatever latest version of dwarf that gdb already has support for. But that is also a job that should be done separately, with its own tag, after a new merge is working with the existing mechanisms. > > Thanks, > - Jay > > > > > From dabenavidesd at yahoo.es Tue Jul 20 22:13:01 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 20 Jul 2010 20:13:01 +0000 (GMT) Subject: [M3devel] merging gdb from 6.4 to 7.1? In-Reply-To: <4C45BEC6.40603@lcwb.coop> Message-ID: <192662.96738.qm@web23608.mail.ird.yahoo.com> Hi all: Is it possible to include in the m3gdb support for remote debugging like the one introduced by the developers in SPIN (which was based on DEC Firefly teledebug protocol called TTD see doi:10.1145/68210.69219 see doi.org), it is a protocol to remotely debug a target program but in such a case you have the post-mortem abilities is that hard to ask for doing it remotely, though TDD it was implemented for debugging the operating system itself it could be if I'm not wrong easier to debug from a type terminal remotely than in the cellphone or tablet it self when such a target is available for any application. Postmortem would be even nicer since there is general support in high-end cellphones which seem to be a ever increasing range of platforms and operating system versions and vendors. Other version of TTD protocol was used in the ldb debugger, this allowed even to disconnect and connect from cross-platform debugging to target and provide services for the stack walking between other issues its dependence in lcc's c compiler though will it be possible to replace it for an intermediate representation like the one of Modula-3 I just see possible for the m3tk toolkit to do it since support for it would be a nice feature for its debugging features the porting of the M3CG assembly machine language for the lcc framework would be possible, there is support on it for targeting even the CLI .Net framework so it would be good to ask if it isn't too hard to do it for a good reason to do it to host M3CG. Thanks in advance --- El mar, 20/7/10, Rodney M. Bates escribi?: > De: Rodney M. Bates > Asunto: Re: [M3devel] merging gdb from 6.4 to 7.1? > Para: "m3devel" > Fecha: martes, 20 de julio, 2010 10:20 > I have been thinking about doing this > myself for some time, but up to > now, have not had the time. I can certainly help, if > you want to do it, > or maybe take it on myself. I think I will be having > more time soon. > I have done it a couple of times before. A few things > can be hard to > figure out, because they rework existing stuff in gdb and > it's hard to > dig out what the new equivalent of the old mechanism > is. A lot of the > M3-specific code I either heavily modified or wrote. > > Jay K wrote: > > The merge of m3cc/gcc from 4.3.0 to 4.3.5 went well > enough. > > > > I'll volunteer to merge m3gdb from 6.4 to 7.1. > > BTW, there is now or will be very soom, a 7.2 gdb. > Also, the latest gdb does reverse debugging, by recording > snapshots during the forward run. This would be a > *very* > nice feature to have for Modula-3. > > > > > > Are people interested? > > > > I saw some mention of 6.4.3 in our history. > > But there's no release called that. > > What is it? > > I don't remember anything about this. > > > > > Some of the conflicts are about SYMBOL_TYP vs. > LHS_SYMBOL_TYPE. > > What that a deliberate important change on our port? > > Yes, this is my change, very deliberate, and gets around a > nasty > group of dangling pointer bugs. I would have to took > at it again, > but it used to cache a pointer to a gdb type struct, lazily > looked- > up the first time, right into an existing field of another > gdb struct. > When you rerun, gdb reloads the referent structs of such > pointers, > leaving them dangling. Or maybe I am mixing up two > different > problems. Anyway, the two macros are essential. > > I have long thought it might be nice to design a better > mechanism, > but it's not simple. I strongly recommend not messing > with it during > merging to a newer gdb. Save that for a subsequent > job with a separate > CVS tag. It's only a performance matter, and except > for debugging work > that proceeds without requiring user-types commands all the > time, it > scarcely matters. > > Also, we would be a lot better off to dump stabs+ and use > whatever > latest version of dwarf that gdb already has support > for. But that > is also a job that should be done separately, with its own > tag, after > a new merge is working with the existing mechanisms. > > > > > > Thanks, > > - Jay > > > > > > > > > > > > > From jay.krell at cornell.edu Wed Jul 21 04:58:47 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 21 Jul 2010 02:58:47 +0000 Subject: [M3devel] merging gdb from 6.4 to 7.1? In-Reply-To: <4C45BEC6.40603@lcwb.coop> References: , <4C45BEC6.40603@lcwb.coop> Message-ID: Thanks. To be clear then, my initial merge will likely lose some changes, it sounds like you are ok with that, and they can be redone soon thereafter by someone else (e.g. you). I'll be sure it builds and do a minimum of debugging with it. I'll expect it to understand some Modula-3 syntax and esp. decode types. When I use gdb everything is void* so there should be obvious improvement with m3gdb. I'm not sure what the best way to "help" is. I'm not super keen on "sharing diffs" or using branches. Therefore, come up with something reasonable maybe slightly flawed, commit it, someone else can improve it afterward, as long as the initial one isn't too flawed? ok? ok? There is some use of $revision$ and $id$ in there and it makes things slightly messy. There are files we didn't change, but which show as changed because of them. Mostly deleted stuff like hpread.c and the rdi-shared directory. Or we added comments in dwarfread.c which was deleted. I agree -gstabs might not be best. It isn't supported on e.g. HP64_HPUX. But often whenever I try other options like -g or -gcoff or -ggdb or -gdwarf, I get crashes in the backend so I leave the config files with -gstabs+. :( I don't think it matters too much what I merge up to, as long as it is >6.4. 7.1 is out. I didn't see 7.2. Thanks, - Jay > Date: Tue, 20 Jul 2010 10:20:38 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] merging gdb from 6.4 to 7.1? > > I have been thinking about doing this myself for some time, but up to > now, have not had the time. I can certainly help, if you want to do it, > or maybe take it on myself. I think I will be having more time soon. > I have done it a couple of times before. A few things can be hard to > figure out, because they rework existing stuff in gdb and it's hard to > dig out what the new equivalent of the old mechanism is. A lot of the > M3-specific code I either heavily modified or wrote. > > Jay K wrote: > > The merge of m3cc/gcc from 4.3.0 to 4.3.5 went well enough. > > > > I'll volunteer to merge m3gdb from 6.4 to 7.1. > > BTW, there is now or will be very soom, a 7.2 gdb. > Also, the latest gdb does reverse debugging, by recording > snapshots during the forward run. This would be a *very* > nice feature to have for Modula-3. > > > > > > Are people interested? > > > > I saw some mention of 6.4.3 in our history. > > But there's no release called that. > > What is it? > > I don't remember anything about this. > > > > > Some of the conflicts are about SYMBOL_TYP vs. LHS_SYMBOL_TYPE. > > What that a deliberate important change on our port? > > Yes, this is my change, very deliberate, and gets around a nasty > group of dangling pointer bugs. I would have to took at it again, > but it used to cache a pointer to a gdb type struct, lazily looked- > up the first time, right into an existing field of another gdb struct. > When you rerun, gdb reloads the referent structs of such pointers, > leaving them dangling. Or maybe I am mixing up two different > problems. Anyway, the two macros are essential. > > I have long thought it might be nice to design a better mechanism, > but it's not simple. I strongly recommend not messing with it during > merging to a newer gdb. Save that for a subsequent job with a separate > CVS tag. It's only a performance matter, and except for debugging work > that proceeds without requiring user-types commands all the time, it > scarcely matters. > > Also, we would be a lot better off to dump stabs+ and use whatever > latest version of dwarf that gdb already has support for. But that > is also a job that should be done separately, with its own tag, after > a new merge is working with the existing mechanisms. > > > > > > Thanks, > > - Jay > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ttmrichter at gmail.com Wed Jul 21 12:40:55 2010 From: ttmrichter at gmail.com (Michael Richter) Date: Wed, 21 Jul 2010 18:40:55 +0800 Subject: [M3devel] spin sources In-Reply-To: <27F80E57-716A-47ED-95DE-A73B51E580ED@sol42.com> References: <1279608663.2648.3.camel@localhost> <27F80E57-716A-47ED-95DE-A73B51E580ED@sol42.com> Message-ID: OK, Daniel, this is seriously cool! I've been trying to find SPIN source for a while now. On 20 July 2010 20:28, wrote: > Hello. I have spin-33.2.tar.gz from many many years ago. > > It is now available at http://www.sol42.com/spin-33.2.tar.gz > Its size is 27.675.835 bytes compressed, 119.961.600 uncompressed. > MD5 (spin-33.2.tar.gz) = 8fcd9457f1298eaef8819a21ab931712 > > GNU tar complains about zero data at the end of the archive, Solaris tar > just stops there. Hopefully nothing is missing. > > Regards. > -Daniel -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Jul 21 18:57:00 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 21 Jul 2010 16:57:00 +0000 Subject: [M3devel] Alpha/OSF exception handling In-Reply-To: References: , , , Message-ID: It doesn't seem to "just work". Will require some debugging. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Mon, 19 Jul 2010 07:31:22 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Alpha/OSF exception handling > > > I didn't "remove" it, but I did "disable" it. Similar. > I didn't want to have to spend any time debugging it if it didn't work any longer. > I'm sure we have precious few users of this system (2 this month though, quite a surge) and they can probably live with > an equally bad implementation as all the other platforms (except for Solaris/sparc). > Granted, they have slower than average systems, would benefit more perhaps from the optimization. > > We can try it out I guess. > > I do hope we can improve this across the aboard. > Even if we don't use the tree exception handling nodes, we can probably at least use the same runtime support (libunwind in libgcc). > Even then, Alpha/OSF won't be important. > > - Jay > > ---------------------------------------- > > From: hosking at cs.purdue.edu > > Date: Sun, 18 Jul 2010 14:22:41 -0400 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Alpha/OSF exception handling > > > > That is a huge shame. Why did you remove it? It used to be there and functional. > > > > On 18 Jul 2010, at 09:35, Jay K wrote: > > > > > > > > Modula-3 for ALPHA_OSF historically had the best exception handling implementation. > > > > > > With Solaris/sparc32 second best. > > > > > > And then everything else equally bad. > > > > > > > > > > > > > > > > > > The current Alpha/osf is now in the "equally bad" category. > > > Because I'm lazy. > > > > > > It might be worth restoring its former glory. > > > > > > > > > > > > Maybe a small project for someone? > > > > > > > > > The code is still in there. I just tweaked the m3makefiles to avoid trying it. > > > > > > > > > jbook2:runtime jay$ pwd > > > /dev2/cm3/m3-libs/m3core/src/runtime > > > jbook2:runtime jay$ find ALPHA_OSF > > > ALPHA_OSF/m3makefile-old > > > > > > Renaming that m3makefile. > > > > > > Fiddling with this: > > > > > > book2:runtime jay$ grep STACK * > > > m3makefile:readonly HAS_STACK_WALKER = { > > > m3makefile:if defined("M3_USE_STACK_WALKER") > > > m3makefile: if M3_USE_STACK_WALKER and HAS_STACK_WALKER contains TARGET > > > m3makefile: if HAS_STACK_WALKER{TARGET} > > > > > > > > > and this: > > > > > > > > > jbook2:src jay$ pwd > > > /dev2/cm3/m3-sys/m3middle/src > > > > > > > > > book2:src jay$ grep -i _stack *m3 > > > Target.m3: Has_stack_walker := FALSE; > > > Target.m3: Has_stack_walker := TRUE; > > > > > > > > > - Jay > > > > > > From rcolebur at SCIRES.COM Wed Jul 21 20:52:05 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Wed, 21 Jul 2010 14:52:05 -0400 Subject: [M3devel] compiler version number Message-ID: I grabbed the minimal 5.8.6 archive for Windows. Using this archive, "cm3 -version" yields: Critical Mass Modula-3 version 5.8.6 last updated: 2010-04-11 compiled: 2010-07-12 21:11:13 configuration: .\cm3.cfg host: NT386 target: NT386 But, when I use this edition to rebuild everything from the main trunk, "cm3 -version" now yields: Critical Mass Modula-3 version d5.8.2 last updated: 2009-07-15 compiled: 2010-07-21 17:29:53 configuration: C:\cm3\bin\cm3.cfg host: NT386 defaulting to native build: I386_NT target: I386_NT Can someone please explain how the version number and timestamp info get integrated into the compiler? If I can get a handle on the way it's currently done, I'll try to fix the problem I'm having on Windows with the info regressing. Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Jul 21 22:31:42 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 21 Jul 2010 20:31:42 +0000 Subject: [M3devel] compiler version number In-Reply-To: References: Message-ID: It's working on Windows. jbook2:~ jay$ cat /dev2/cm3/scripts/version.quake CM3VERSION = "d5.8.2" CM3VERSIONNUM = "050802" CM3LASTCHANGED = "2009-07-15" jbook2:~ jay$ cat /dev2/cm3/scripts/version CM3VERSION d5.8.2 CM3VERSIONNUM 050802 CM3LASTCHANGED 2009-07-15 ?- Jay ________________________________ > From: rcolebur at SCIRES.COM > To: m3devel at elegosoft.com > Date: Wed, 21 Jul 2010 14:52:05 -0400 > Subject: [M3devel] compiler version number > > > I grabbed the minimal 5.8.6 archive for Windows. > > > > Using this archive, ?cm3 ?version? yields: > > > > Critical Mass Modula-3 version 5.8.6 > > last updated: 2010-04-11 > > compiled: 2010-07-12 21:11:13 > > configuration: .\cm3.cfg > > host: NT386 > > target: NT386 > > > > But, when I use this edition to rebuild everything from the main trunk, > ?cm3 ?version? now yields: > > > > Critical Mass Modula-3 version d5.8.2 > > last updated: 2009-07-15 > > compiled: 2010-07-21 17:29:53 > > configuration: C:\cm3\bin\cm3.cfg > > host: NT386 > > defaulting to native build: I386_NT > > target: I386_NT > > > > Can someone please explain how the version number and timestamp info > get integrated into the compiler? > > > > If I can get a handle on the way it?s currently done, I?ll try to fix > the problem I?m having on Windows with the info regressing. > > > > Regards, > > Randy Coleburn > > From wagner at elegosoft.com Wed Jul 21 22:42:36 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 21 Jul 2010 22:42:36 +0200 Subject: [M3devel] compiler version number In-Reply-To: References: Message-ID: <20100721224236.7jkk3bregwk4w8o8@mail.elegosoft.com> Quoting "Coleburn, Randy" : > I grabbed the minimal 5.8.6 archive for Windows. > > Using this archive, "cm3 -version" yields: > > Critical Mass Modula-3 version 5.8.6 > last updated: 2010-04-11 > compiled: 2010-07-12 21:11:13 > configuration: .\cm3.cfg > host: NT386 > target: NT386 > > But, when I use this edition to rebuild everything from the main > trunk, "cm3 -version" now yields: > > Critical Mass Modula-3 version d5.8.2 > last updated: 2009-07-15 > compiled: 2010-07-21 17:29:53 > configuration: C:\cm3\bin\cm3.cfg > host: NT386 > defaulting to native build: I386_NT > target: I386_NT > > Can someone please explain how the version number and timestamp info > get integrated into the compiler? > > If I can get a handle on the way it's currently done, I'll try to > fix the problem I'm having on Windows with the info regressing. You're right, it's still wrong on the trunk. I've only cared for the release branch during the recent months, but I've just checked in a fix: % cvs -q diff -u Index: version =================================================================== RCS file: /usr/cvs/cm3/scripts/version,v retrieving revision 1.5 diff -u -u -r1.5 version --- version 15 Jul 2009 06:14:01 -0000 1.5 +++ version 21 Jul 2010 20:39:06 -0000 @@ -1,3 +1,3 @@ -CM3VERSION d5.8.2 -CM3VERSIONNUM 050802 -CM3LASTCHANGED 2009-07-15 +CM3VERSION d5.9.0 +CM3VERSIONNUM 050900 +CM3LASTCHANGED 2010-07-21 Index: version.quake =================================================================== RCS file: /usr/cvs/cm3/scripts/version.quake,v retrieving revision 1.1 diff -u -u -r1.1 version.quake --- version.quake 13 Apr 2010 11:14:22 -0000 1.1 +++ version.quake 21 Jul 2010 20:39:06 -0000 @@ -1,3 +1,3 @@ -CM3VERSION = "d5.8.2" -CM3VERSIONNUM = "050802" -CM3LASTCHANGED = "2009-07-15" +CM3VERSION = "d5.9.0" +CM3VERSIONNUM = "050900" +CM3LASTCHANGED = "2010-07-21" luthien [/d/home/wagner/work/cm3/scripts] wagner % cvs commit -m 'fix version number on trunk for 5.9 development' c/usr/cvs/cm3/scripts/version,v <-- version new revision: 1.6; previous revision: 1.5 /usr/cvs/cm3/scripts/version.quake,v <-- version.quake new revision: 1.2; previous revision: 1.1 All scripts should pick up the version from those files. Thanks for the hint, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Jul 22 16:25:06 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 22 Jul 2010 14:25:06 +0000 Subject: [M3devel] Hudson updating config files or not In-Reply-To: References: <20100721155314.E1BC6CC389@birch.elegosoft.com>, , , , <20100722085323.0nmmjnom94osso88@mail.elegosoft.com>, , <20100722091912.bibr9p0z1q88wog4@mail.elegosoft.com>, Message-ID: I'm not sure, but here is some analysis. In the release hudson tasks, we have http://hudson.modula3.com:8080/view/SOLgnu/job/cm3-release-build-SOLgnu/110/consoleFull and http://hudson.modula3.com:8080/view/SOLgnu/job/cm3-build-SOLgnu/163/console "build" and "release-build". I think these are, like, "build from last release" and "build from latest successful build". I'm not sure what they do, but instead of fighting over installs and CVS trees, they should perhaps just each maintain their own. That way, e.g., they could both update config files. ? Well, except if we are low on diskspace, which we are. And it is a defficiency of the system to put outputs in the source tree. ? We should be able to ge by with one source tree per node, and all outputs should go elsewhere, including the PGS files and ? including those install.sh that get generated. The source tree should never be written to, as an option at least. Anyway. In regression/defs.sh I believe they go here: test_build_current ... ? if [ "$1" = "rel" ]; then?? # This is the important recurring thing that makes things different? ? ? "release" goes here, "build" does not ? This path does update config files. ? ? ??? echo " === clean up before cm3 upgrade " ??? if [ -z "$NOCLEAN" ]; then ????? OMIT_GCC=yes ./scripts/do-cm3-core.sh realclean || exit 1 ????? ./scripts/do-pkg.sh realclean cminstall ??? fi ??? echo " === perform cm3 upgrade " ??? UPGRADE_CM3_CFG=yes ./scripts/upgrade.sh || exit 1 ??? echo " >>> OK build_${1}_upgrade ${DS} ${WS}" ? fi and then: ? echo " === build ${BSET} system with current compiler" ? BUILDSCRIPT="./scripts/do-cm3-${BSET}.sh" ? if [ "$1" = "rel" ]; then?? # This is the important recurring thing that makes things different? ??? if [ -z "$NOCLEAN" ]; then ????? OMIT_GCC=yes ./scripts/do-cm3-core.sh realclean || exit 1 ??? fi ? else ??? if [ -z "$NOCLEAN" ]; then ????? $BUILDSCRIPT realclean || exit 1 ??? fi ? fi ? $BUILDSCRIPT buildship || exit 1 or, oh no, now I'm confused, here?: test_build_system ? test_build_system and test_build_current are very similar! Confusing?! ? ? echo " === build core system with current compiler" ? BUILDSCRIPT="./scripts/do-cm3-core.sh" ? if [ -z "$NOCLEAN" ]; then ??? $BUILDSCRIPT realclean || exit 1 ? fi ? if $BUILDSCRIPT build; then ??? echo " >>> OK build_system ${DS} ${WS}; now rebuild and ship" ??? $BUILDSCRIPT buildship ??? echo " === install new compiler" ??? ????? This is what we are running for head, I think. ????? Historically it didn't touch config files. ????? This is what I changed a day or so ago, to update them. ??? if ./scripts/install-cm3-compiler.sh upgrade; then ????? echo "compiler upgraded successfully" ????? cm3 -version ??? else ????? echo "compiler upgrade failed" 1>&2 ????? exit 1 ??? fi ? else ? ??? There is this which will update config files, but only if the previous fails. ??? echo " === perform cm3 upgrade after cleaning everything" ??? $BUILDSCRIPT realclean || exit 1 ??? UPGRADE_CM3_CFG=yes ./scripts/upgrade.sh || exit 1 ??? echo " >>> OK build_upgrade ${DS} ${WS}" ? fi Anyway, it is confusing, release has a pair of tasks and only some paths updated config files, even if other/more/different paths update the compiler. I think: ? - we want the pairs of tasks, at least for testing coverage ? - or, I guess, just build from previous release ??? which can be constraining, it is a policy issue ? - whichever tasks we have, we should have config file updating ? - tangentially: we should get all outputs, *all* outouts out of the source tree ???? The original design was nice, get outputs "per package" outside of source, ???? but it failed to address a multi-package tree. This is a big change I'm proposing. ???? I guess another mail on the topic. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > CC: m3commit at elegosoft.com > Subject: RE: [M3commit] CVS Update: cm3 > Date: Thu, 22 Jul 2010 07:21:33 +0000 > > > (ps: the change I made does do the backup foo-date thing, parallel to cm3 and cm3cg > yes I'll compare the branches, can't promise a full merge though) > > > ---------------------------------------- > > Date: Thu, 22 Jul 2010 09:19:12 +0200 > > From: wagner at elegosoft.com > > To: jay.krell at cornell.edu > > CC: m3commit at elegosoft.com > > Subject: Re: [M3commit] CVS Update: cm3 > > > > I can live with a cm3-local.cfg file which gets included when it exists, > > contains local overrides and is never touched by he installation. > > > > We have to be careful to backup existing configs and informing the > > users before the installation though. > > > > I think upgrade did backups of the config, too. > > > > Can you check the scripts in the release branch if anything needs > > to be merged back? I won't be able to do that today. > > > > Olaf > > > > Quoting Jay K : > > > > > I thought it was too, before I looked at it. > > > Could be that head and release are very divergent. > > > I didn't look at release, oops. > > > I probably will "soon". > > > > > > > > > The config files are "partly part of the compiler", and partly > > > system-specific. > > > So they might have to be updated with the compiler. > > > > > > > > > Perhaps we can have cm3.cfg.user or cm3.cfg.local, that we never edit, > > > and maybe we should constrain it, like very line > > > must have an equals sign, and if it has a percent, percent must > > > follow equals. > > > > > > > > > e.g. > > > m3back_flags = "-custom" > > > SYSTEM_CC = "custom" % comment blah blah > > > SYSTEM_LIBS{"LIBC"} = "custom" > > > SYSTEM_LIBORDER += [custom] > > > > > > But that might not be flexible enough. > > > > > > Another option is that cm3.cfg file do like: > > > if exists("cm3.cfg.user.first") > > > include("cm3.cfg.user.first") > > > end > > > ... > > > if exists("cm3.cfg.user.last") > > > > > > include("cm3.cfg.user.last > > > > > > end > > > > > > > > > > > > which is infinitely flexible and not well defined. > > > Even limiting to assignments is not well defined. > > > You know, there's an interface somewhere in there, but it isn't > > > well specified. My fault. > > > I let things evolve and get discovered gradually, sometimes hard > > > to know ahead of time what the result will be. > > > > > > > > > I've made changes since 5.8.6 released such that config files from > > > prior to 5.8.6 will not suffice. > > > I can undo that, but there is an important policy and architecture question. > > > > > > > > > - Jay > > > > > > ---------------------------------------- > > >> Date: Thu, 22 Jul 2010 08:53:23 +0200 > > >> From: wagner at elegosoft.com > > >> To: m3commit at elegosoft.com > > >> Subject: Re: [M3commit] CVS Update: cm3 > > >> > > >> Quoting Jay K : > > >> > > >> > I've manually updated the config files on SPARC32_LINUX Hudson node > > >> > to try to fix this. > > >> > > >> That should be done by the upgrade script (and it already was AFAIR). > > >> I wouldn't like the script shipping a newly built compiler to > > >> unconditionally overwrite all my local configuration. > > >> > > >> Olaf > > >> > > >> > > > >> > - Jay > > >> > > > >> > ---------------------------------------- > > >> >> Date: Wed, 21 Jul 2010 17:53:14 +0000 > > >> >> To: m3commit at elegosoft.com > > >> >> From: jkrell at elego.de > > >> >> Subject: [M3commit] CVS Update: cm3 > > >> >> > > >> >> CVSROOT: /usr/cvs > > >> >> Changes by: jkrell at birch. 10/07/21 17:53:14 > > >> >> > > >> >> Modified files: > > >> >> cm3/scripts/: install-cm3-compiler.sh > > >> >> > > >> >> Log message: > > >> >> upgrade config files when upgrading compiler > > >> >> > > >> > > > >> > > >> > > >> > > >> -- > > >> Olaf Wagner -- elego Software Solutions GmbH > > >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 jay.krell at cornell.edu Thu Jul 22 16:47:22 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 22 Jul 2010 14:47:22 +0000 Subject: [M3devel] getting outputs out of the source tree? reducing "ship"? Message-ID: Today we have: /cvsroot/pkg1/src outputs to /src/pkg1/target /cvsroot/pkg2/src outputs to /src/pkg2/target This was good for its time, better than e.g. outputs to /cvsroot/pkg1/src ! However I want more. I want /cvsroot to be read only. So how about: ?outputs to /cvsroot-out/pkg1/target This is probably easy to achieve. e.g. introduce BUILD_DIR_ROOT (or OUTPUT_ROOT) and it is defined, prefix to BUILD_DIR. Probably would have to be accompanied by SOURCE_ROOT, prefix it as needed. ?e.g. relative paths that go from output to source would need to be fixed. an maybe much more so, remove ship as a separate step: ? outputs to /cvsroot-out/intermed/pkg1/target/*.mo? ? outputs to /cvsroot-out/inst/lib/libpkg1.so The one and only copy.? ? outputs to /cvsroot-out/inst/pkg/pkg1/src (maybe, separate ship step! because is a waste when still testing) To "clean", you would have a choice of rm -rf /cvsroot-out/* or mkdir /cvsroot-out2 ?and point whatever environment variable at -inst2. ?? (possibly by copying cm3 into out2 and pointing $PATH at it) The buildlocal vs. buildglobal distinction would go away. buildlocal + ship (which you can't do today, except by copying manually) would be equiv of ? set CM3_OUTPUT_ROOT=/cm3-inst.new? (or again, copy cm3/cm3cfg/config and set PATH) ? build everything ? To try it out, either change PATH, or ? mv /cm-inst /cm3-inst.old ? mv /cm3-inst.new /cm3-inst ? unset CM3_OUTPUT_ROOT If you want to build less, and remain isolated like buildlocal: ? cp -pr /cm3-inst $CM3_OUTPUT_ROOT ? build seletctively ? To try it out, either change PATH, or ? mv /cm-inst /cm3-inst.old ? mv /cm3-inst.new /cm3-inst ? unset CM3_OUTPUT_ROOT One of the points is: the immediate output of compilation could have the same structure as the installation. Installation can be just renaming or copying directories. Not reorganizing directory layout. buildglobal would be building into a new empty directory.-- instead of build + don't ship buildglobal would be building top of the in-use directory -- instead of build + ship Positive consequences: ? All unshipped binaries would work even if linked dynamically, e.g. with $ORIGIN, e.g. without static. ? It still doesn't address systems without $ORIGIN though. There are major advantages either way -- ie. without ORIGIN you can "stitch together" binaries whose paths have no relationship to each other, and you can move around at least the executables arbitrarily. ? Though you can't move the libraries at all. ?? chroot is another way people deal with this -- using absolute paths, but isolated from existing files. ??? It is kind of partial cheap virtual machine, chroot. Now, I have to admit, this is more of an intellectual exercise right now, as I don't have the time/inclination to do it soon. :( ? - Jay From rodney_bates at lcwb.coop Thu Jul 22 23:23:51 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 22 Jul 2010 16:23:51 -0500 Subject: [M3devel] merging gdb from 6.4 to 7.1? In-Reply-To: References: , <4C45BEC6.40603@lcwb.coop> Message-ID: <4C48B6E7.6060908@lcwb.coop> This sounds fine with me, as long as there is one branch for the entire merge process, which will be broken for a while. Jay K wrote: > Thanks. To be clear then, my initial merge will likely lose some changes, > it sounds like you are ok with that, and they can be redone soon > thereafter by someone else (e.g. you). > I'll be sure it builds and do a minimum of debugging with it. > I'll expect it to understand some Modula-3 syntax and esp. decode types. > When I use gdb everything is void* so there should be obvious improvement > with m3gdb. > I'm not sure what the best way to "help" is. I'm not super keen on > "sharing diffs" or using branches. Therefore, come up with something > reasonable maybe slightly flawed, commit it, someone else can improve it > afterward, as long as the initial one isn't too flawed? ok? > > > ok? > > > There is some use of $revision$ and $id$ in there and it makes things > slightly messy. > There are files we didn't change, but which show as changed because of them. > Mostly deleted stuff like hpread.c and the rdi-shared directory. > Or we added comments in dwarfread.c which was deleted. > > > I agree -gstabs might not be best. > It isn't supported on e.g. HP64_HPUX. > But often whenever I try other options like -g or -gcoff or -ggdb or > -gdwarf, > I get crashes in the backend so I leave the config files with -gstabs+. :( > > > I don't think it matters too much what I merge up to, as long as it is >6.4. > 7.1 is out. I didn't see 7.2. > > > Thanks, > - Jay > > > > Date: Tue, 20 Jul 2010 10:20:38 -0500 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] merging gdb from 6.4 to 7.1? > > > > I have been thinking about doing this myself for some time, but up to > > now, have not had the time. I can certainly help, if you want to do it, > > or maybe take it on myself. I think I will be having more time soon. > > I have done it a couple of times before. A few things can be hard to > > figure out, because they rework existing stuff in gdb and it's hard to > > dig out what the new equivalent of the old mechanism is. A lot of the > > M3-specific code I either heavily modified or wrote. > > > > Jay K wrote: > > > The merge of m3cc/gcc from 4.3.0 to 4.3.5 went well enough. > > > > > > I'll volunteer to merge m3gdb from 6.4 to 7.1. > > > > BTW, there is now or will be very soom, a 7.2 gdb. > > Also, the latest gdb does reverse debugging, by recording > > snapshots during the forward run. This would be a *very* > > nice feature to have for Modula-3. > > > > > > > > > > Are people interested? > > > > > > I saw some mention of 6.4.3 in our history. > > > But there's no release called that. > > > What is it? > > > > I don't remember anything about this. > > > > > > > > Some of the conflicts are about SYMBOL_TYP vs. LHS_SYMBOL_TYPE. > > > What that a deliberate important change on our port? > > > > Yes, this is my change, very deliberate, and gets around a nasty > > group of dangling pointer bugs. I would have to took at it again, > > but it used to cache a pointer to a gdb type struct, lazily looked- > > up the first time, right into an existing field of another gdb struct. > > When you rerun, gdb reloads the referent structs of such pointers, > > leaving them dangling. Or maybe I am mixing up two different > > problems. Anyway, the two macros are essential. > > > > I have long thought it might be nice to design a better mechanism, > > but it's not simple. I strongly recommend not messing with it during > > merging to a newer gdb. Save that for a subsequent job with a separate > > CVS tag. It's only a performance matter, and except for debugging work > > that proceeds without requiring user-types commands all the time, it > > scarcely matters. > > > > Also, we would be a lot better off to dump stabs+ and use whatever > > latest version of dwarf that gdb already has support for. But that > > is also a job that should be done separately, with its own tag, after > > a new merge is working with the existing mechanisms. > > > > > > > > > > Thanks, > > > - Jay > > > > > > > > > > > > > > > From rodney_bates at lcwb.coop Thu Jul 22 23:48:11 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 22 Jul 2010 16:48:11 -0500 Subject: [M3devel] merging gdb from 6.4 to 7.1? More info on LHS_SYMBOL_TYPE In-Reply-To: <4C45BEC6.40603@lcwb.coop> References: <4C45BEC6.40603@lcwb.coop> Message-ID: <4C48BC9B.4020708@lcwb.coop> Rodney M. Bates wrote: > I have been thinking about doing this myself for some time, but up to > now, have not had the time. I can certainly help, if you want to do it, > or maybe take it on myself. I think I will be having more time soon. > I have done it a couple of times before. A few things can be hard to > figure out, because they rework existing stuff in gdb and it's hard to > dig out what the new equivalent of the old mechanism is. A lot of the > M3-specific code I either heavily modified or wrote. > > Jay K wrote: >> The merge of m3cc/gcc from 4.3.0 to 4.3.5 went well enough. >> >> I'll volunteer to merge m3gdb from 6.4 to 7.1. > > BTW, there is now or will be very soom, a 7.2 gdb. > Also, the latest gdb does reverse debugging, by recording > snapshots during the forward run. This would be a *very* > nice feature to have for Modula-3. > > >> >> Are people interested? >> >> I saw some mention of 6.4.3 in our history. >> But there's no release called that. >> What is it? > > I don't remember anything about this. > >> >> Some of the conflicts are about SYMBOL_TYP vs. LHS_SYMBOL_TYPE. >> What that a deliberate important change on our port? > > Yes, this is my change, very deliberate, and gets around a nasty > group of dangling pointer bugs. I would have to took at it again, > but it used to cache a pointer to a gdb type struct, lazily looked- > up the first time, right into an existing field of another gdb struct. > When you rerun, gdb reloads the referent structs of such pointers, > leaving them dangling. Or maybe I am mixing up two different > problems. Anyway, the two macros are essential. > > I have long thought it might be nice to design a better mechanism, > but it's not simple. I strongly recommend not messing with it during > merging to a newer gdb. Save that for a subsequent job with a separate > CVS tag. It's only a performance matter, and except for debugging work > that proceeds without requiring user-types commands all the time, it > scarcely matters. I looked back at this. Actually, I am not sure the split of SYMBOL_TYPE into LHS_SYMBOL_TYPE and SYMBOL_TYPE was my original doing, but part of the original mods from stock gdb to m3gdb. I just remember having to figure out in a number of places, which occurrences should be which macro. In stock gdb, there is only SYMBOL_TYPE. It expands to an lvalue that denotes the type member of a symbol. It is used both to assign to and to fetch that member. SYMBOL_TYPE, in m3gdb is effectively an accessor or getter function, but it does some computation to resolve the type using a UID, rather than just fetching a field. it expands to a non-lvalue. Use it to get the type when you have a symbol. In m3gdb, LHS_SYMBOL_TYPE is the corresponding mutator or setter function. I think it's actually the same macro as SYMBOL_TYPE is in gdb. Places in stock gdb that assign to the type field need to be changed to use LHS_SYMBOL_TYPE in m3gdb, to work. Except for a couple of places where a null is assigned, all uses of LHS_SYMBOL_TYPE are in code that is non-m3gdb-specific. I guess it would make future merges easier if LHS_SYMBOL_TYPE were changed back to the original SYMBOL_TYPE and the M3-specific accessor were renamed to something else, perhaps M3_SYMBOL_TYPE or M3_RESOLVE_SYMBOL_TYPE. This would move the changes to be merged out of gdb source files that are not m3gdb-specific. The caching that caused the dangling pointer bugs can be seen in the m3gdb version of the definition of SYMBOL_TYPE, but is it commented out. The resolution is always done over every time. If only gdb had a garbage collector, this would be easier. Actually, I suppose it would need weak references to make the caching work. > > Also, we would be a lot better off to dump stabs+ and use whatever > latest version of dwarf that gdb already has support for. But that > is also a job that should be done separately, with its own tag, after > a new merge is working with the existing mechanisms. > > >> >> Thanks, >> - Jay >> >> >> >> >> > From rodney_bates at lcwb.coop Thu Jul 22 23:57:36 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 22 Jul 2010 16:57:36 -0500 Subject: [M3devel] gdb versions to merge m3gdb into Message-ID: <4C48BED0.2020707@lcwb.coop> The following were recently posted on the gdb development mailing list. If we go to all the work of merging a new gdb, it would be worth waiting a bit if necessary, to get the very latest. Otherwise, our m3gdb is outdated before it even gets working. I don't know more than this about the schedule, but new release branches usually become releases fairly quickly. Both these were posted by Joel Brobecker, on 07/07/2010. I don't know what the relationship between 7.2 and 7.1.90 pre-releases is. -------------------------------------------------------------------------- Hello, A quick message to announce that the GDB 7.2 branch has just been created. The prerelease snapshots will be available at: ftp://sourceware.org/pub/gdb/snapshots/branch/gdb.tar.bz2 The sources are also accessible via CVS: cvs -d :pserver:anoncvs at sourceware.org:/cvs/src co -r gdb_7_2-branch gdb This announcement has also been posted on the GDB web site at: http://www.sourceware.org/gdb/ -- Joel -------------------------------------------------------------------------- Hello, I have just finished creating the gdb-7.1.90 pre-release. It is available for download at the following location: ftp://sourceware.org/pub/gdb/snapshots/branch/gdb-7.1.90.tar.bz2 A gzip'ed version is also available: gdb-7.1.90.tar.gz. Please give it a test if you can and report any problems you might find. x64-windows users, please note the following which is not part of this pre-release: http://www.sourceware.org/ml/gdb-patches/2010-07/msg00130.html On behalf of all the GDB contributors, thank you! -- Joel -------------------------------------------------------------------------- From rcolebur at SCIRES.COM Fri Jul 23 06:46:29 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Fri, 23 Jul 2010 00:46:29 -0400 Subject: [M3devel] Just putting it out there... In-Reply-To: References: , , <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com> , , <20100719090459.4CE191A2084@async.async.caltech.edu> , , <20100719110208.011521A2091@async.async.caltech.edu> , <20100719143844.03al7scsg0g400so@mail.elegosoft.com> <1279610803.1935.1.camel@x60.appsoftint.co.uk> <1279633010.1935.11.camel@x60.appsoftint.co.uk> Message-ID: I don't think the sources are available to the M3 JVM, but Olaf would know best on this. If they aren't available, we could check with Farshad Nayeri, one of the original owners/developers of Critical Mass, to see if he might consent to make them available, but this would be a long shot. Regards, Randy Coleburn -----Original Message----- From: m3 at sol42.com [mailto:m3 at sol42.com] Sent: Tuesday, July 20, 2010 10:15 AM To: m3devel Subject: Re: [M3devel] Just putting it out there... On 20 Jul 2010, at 15:36, Mark Wickens wrote: > Yes, after I'd written the email and thought about it I realised it was > a pretty stupid idea. Well, not stupid at all. Java may suck but the JVM certainly does not. There is a lot of interest now in compiling languages other than Java on the JVM, which has turned out to be a sort of universal runtime. Only that it was designed with Java in mind, and you would end up with something *like* Modula-3, not Modula-3 itself: what you can do in JVM "assembly" is limited, no PACKED types, no BITS x FOR y .. z, LOOPHOLE may or may not be always possible, UNTRACED would be problematic, pointer arithmetic in UNSAFE modules might require JNI and who knows what else, forget about <*EXTERNAL*> C calls, full interoperability with Java would require supporting Java interfaces (at the language level I think)... and these are just the few I can think of right now. On the other hand I would really like to code in this superset-of-a-subset of Modula-3 and run it on a JVM. Regarding the Critical Mass JVM described in Threads 3, are the sources available? Regards. -Daniel From wagner at elegosoft.com Fri Jul 23 08:39:49 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 23 Jul 2010 08:39:49 +0200 Subject: [M3devel] Hudson updating config files or not In-Reply-To: References: <20100721155314.E1BC6CC389@birch.elegosoft.com>, , , , <20100722085323.0nmmjnom94osso88@mail.elegosoft.com>, , <20100722091912.bibr9p0z1q88wog4@mail.elegosoft.com>, Message-ID: <20100723083949.l0e85r6j34gks04w@mail.elegosoft.com> The distinction between lastok-build and release-build jobs is obsolete; they have been combined to the -build- jobs ,amy months ago. Just forget about all lastok-build and release-build jobs that may still linger there; they should all be disabled. The -build- jobs should all try a straight forward compile with the cm3 built the last time; if that fails, they will clean everything and start over again with upgrade.sh. That's the only one where configuration files used to get changed. Only the -build- and -test- jobs have been copied over to current. Almost all sources for the hudson jobs should reside in the scripts/regression directory and be under version control. I don't think updates/merges are needed there. Where I wasn't so sure are the scripts one level above. Olaf Quoting Jay K : > I'm not sure, but here is some analysis. > > In the release hudson tasks, we have > http://hudson.modula3.com:8080/view/SOLgnu/job/cm3-release-build-SOLgnu/110/consoleFull > and > http://hudson.modula3.com:8080/view/SOLgnu/job/cm3-build-SOLgnu/163/console > > > "build" and "release-build". > I think these are, like, "build from last release" and "build from > latest successful build". > I'm not sure what they do, but instead of fighting over installs and > CVS trees, they should perhaps just each maintain their own. > That way, e.g., they could both update config files. > > ? Well, except if we are low on diskspace, which we are. And it is a > defficiency of the system to put outputs in the source tree. > ? We should be able to ge by with one source tree per node, and all > outputs should go elsewhere, including the PGS files and > ? including those install.sh that get generated. The source tree > should never be written to, as an option at least. Anyway. > > > In regression/defs.sh I believe they go here: > > > test_build_current > ... > ? if [ "$1" = "rel" ]; then?? # This is the important recurring > thing that makes things different? > ? > ? "release" goes here, "build" does not > ? This path does update config files. > ? > ? > ??? echo " === clean up before cm3 upgrade " > ??? if [ -z "$NOCLEAN" ]; then > ????? OMIT_GCC=yes ./scripts/do-cm3-core.sh realclean || exit 1 > ????? ./scripts/do-pkg.sh realclean cminstall > ??? fi > ??? echo " === perform cm3 upgrade " > ??? UPGRADE_CM3_CFG=yes ./scripts/upgrade.sh || exit 1 > ??? echo " >>> OK build_${1}_upgrade ${DS} ${WS}" > ? fi > > > and then: > > > ? echo " === build ${BSET} system with current compiler" > ? BUILDSCRIPT="./scripts/do-cm3-${BSET}.sh" > ? if [ "$1" = "rel" ]; then?? # This is the important recurring > thing that makes things different? > ??? if [ -z "$NOCLEAN" ]; then > ????? OMIT_GCC=yes ./scripts/do-cm3-core.sh realclean || exit 1 > ??? fi > ? else > ??? if [ -z "$NOCLEAN" ]; then > ????? $BUILDSCRIPT realclean || exit 1 > ??? fi > ? fi > ? $BUILDSCRIPT buildship || exit 1 > > > or, oh no, now I'm confused, here?: > > > test_build_system > > ? test_build_system and test_build_current are very similar! Confusing?! > ? > > ? echo " === build core system with current compiler" > ? BUILDSCRIPT="./scripts/do-cm3-core.sh" > ? if [ -z "$NOCLEAN" ]; then > ??? $BUILDSCRIPT realclean || exit 1 > ? fi > ? if $BUILDSCRIPT build; then > ??? echo " >>> OK build_system ${DS} ${WS}; now rebuild and ship" > ??? $BUILDSCRIPT buildship > ??? echo " === install new compiler" > ??? > ????? This is what we are running for head, I think. > ????? Historically it didn't touch config files. > ????? This is what I changed a day or so ago, to update them. > > ??? if ./scripts/install-cm3-compiler.sh upgrade; then > ????? echo "compiler upgraded successfully" > ????? cm3 -version > ??? else > ????? echo "compiler upgrade failed" 1>&2 > ????? exit 1 > ??? fi > ? else > ? > ??? There is this which will update config files, but only if the > previous fails. > > ??? echo " === perform cm3 upgrade after cleaning everything" > ??? $BUILDSCRIPT realclean || exit 1 > ??? UPGRADE_CM3_CFG=yes ./scripts/upgrade.sh || exit 1 > ??? echo " >>> OK build_upgrade ${DS} ${WS}" > ? fi > > > Anyway, it is confusing, release has a pair of tasks and only some > paths updated config files, even if other/more/different paths > update the compiler. > > > I think: > ? - we want the pairs of tasks, at least for testing coverage > ? - or, I guess, just build from previous release > ??? which can be constraining, it is a policy issue > ? - whichever tasks we have, we should have config file updating > ? - tangentially: we should get all outputs, *all* outouts out of > the source tree > ???? The original design was nice, get outputs "per package" outside > of source, > ???? but it failed to address a multi-package tree. This is a big > change I'm proposing. > ???? I guess another mail on the topic. > > ?- Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com >> CC: m3commit at elegosoft.com >> Subject: RE: [M3commit] CVS Update: cm3 >> Date: Thu, 22 Jul 2010 07:21:33 +0000 >> >> >> (ps: the change I made does do the backup foo-date thing, parallel >> to cm3 and cm3cg >> yes I'll compare the branches, can't promise a full merge though) >> >> >> ---------------------------------------- >> > Date: Thu, 22 Jul 2010 09:19:12 +0200 >> > From: wagner at elegosoft.com >> > To: jay.krell at cornell.edu >> > CC: m3commit at elegosoft.com >> > Subject: Re: [M3commit] CVS Update: cm3 >> > >> > I can live with a cm3-local.cfg file which gets included when it exists, >> > contains local overrides and is never touched by he installation. >> > >> > We have to be careful to backup existing configs and informing the >> > users before the installation though. >> > >> > I think upgrade did backups of the config, too. >> > >> > Can you check the scripts in the release branch if anything needs >> > to be merged back? I won't be able to do that today. >> > >> > Olaf >> > >> > Quoting Jay K : >> > >> > > I thought it was too, before I looked at it. >> > > Could be that head and release are very divergent. >> > > I didn't look at release, oops. >> > > I probably will "soon". >> > > >> > > >> > > The config files are "partly part of the compiler", and partly >> > > system-specific. >> > > So they might have to be updated with the compiler. >> > > >> > > >> > > Perhaps we can have cm3.cfg.user or cm3.cfg.local, that we never edit, >> > > and maybe we should constrain it, like very line >> > > must have an equals sign, and if it has a percent, percent must >> > > follow equals. >> > > >> > > >> > > e.g. >> > > m3back_flags = "-custom" >> > > SYSTEM_CC = "custom" % comment blah blah >> > > SYSTEM_LIBS{"LIBC"} = "custom" >> > > SYSTEM_LIBORDER += [custom] >> > > >> > > But that might not be flexible enough. >> > > >> > > Another option is that cm3.cfg file do like: >> > > if exists("cm3.cfg.user.first") >> > > include("cm3.cfg.user.first") >> > > end >> > > ... >> > > if exists("cm3.cfg.user.last") >> > > >> > > include("cm3.cfg.user.last >> > > >> > > end >> > > >> > > >> > > >> > > which is infinitely flexible and not well defined. >> > > Even limiting to assignments is not well defined. >> > > You know, there's an interface somewhere in there, but it isn't >> > > well specified. My fault. >> > > I let things evolve and get discovered gradually, sometimes hard >> > > to know ahead of time what the result will be. >> > > >> > > >> > > I've made changes since 5.8.6 released such that config files from >> > > prior to 5.8.6 will not suffice. >> > > I can undo that, but there is an important policy and >> architecture question. >> > > >> > > >> > > - Jay >> > > >> > > ---------------------------------------- >> > >> Date: Thu, 22 Jul 2010 08:53:23 +0200 >> > >> From: wagner at elegosoft.com >> > >> To: m3commit at elegosoft.com >> > >> Subject: Re: [M3commit] CVS Update: cm3 >> > >> >> > >> Quoting Jay K : >> > >> >> > >> > I've manually updated the config files on SPARC32_LINUX Hudson node >> > >> > to try to fix this. >> > >> >> > >> That should be done by the upgrade script (and it already was AFAIR). >> > >> I wouldn't like the script shipping a newly built compiler to >> > >> unconditionally overwrite all my local configuration. >> > >> >> > >> Olaf >> > >> >> > >> > >> > >> > - Jay >> > >> > >> > >> > ---------------------------------------- >> > >> >> Date: Wed, 21 Jul 2010 17:53:14 +0000 >> > >> >> To: m3commit at elegosoft.com >> > >> >> From: jkrell at elego.de >> > >> >> Subject: [M3commit] CVS Update: cm3 >> > >> >> >> > >> >> CVSROOT: /usr/cvs >> > >> >> Changes by: jkrell at birch. 10/07/21 17:53:14 >> > >> >> >> > >> >> Modified files: >> > >> >> cm3/scripts/: install-cm3-compiler.sh >> > >> >> >> > >> >> Log message: >> > >> >> upgrade config files when upgrading compiler >> > >> >> >> > >> > >> > >> >> > >> >> > >> >> > >> -- >> > >> Olaf Wagner -- elego Software Solutions GmbH >> > >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> > >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 >> > >> > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Fri Jul 23 09:14:13 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 23 Jul 2010 09:14:13 +0200 Subject: [M3devel] getting outputs out of the source tree? reducing "ship"? In-Reply-To: References: Message-ID: <20100723091413.tjia6l308wks80ks@mail.elegosoft.com> You're writing from a perspective of building the complete CM3 distribution. The designers of the package system intentionally made working in the locality of one package easy. Package local build and ship are two of the abstractions that make M3 well suited for large projects, where the isolation of one package is the working context of one developer. Actually, M3 offers many levels/layers of this kind of abstraction that all have its use: o opaque type definition o partial revelation o modules with interfaces o generics for parametric type abstraction o packages with visible and invisible interfaces I wouldn't wnat to loose any of them. So I'm against changing anything regarding build and ship _as default_. I don't object to beging able to override the output directory of package building to another derived hierarchy, and to use that for building the distribution archives. If anybody wants to work on that, I'd expect it being written and tested in isolation, until it is mature enough to actually replace our existing infrastructure. As you mention, it will be a lot of work. Olaf Quoting Jay K : > Today we have: > > > /cvsroot/pkg1/src > outputs to /src/pkg1/target > > > /cvsroot/pkg2/src > > outputs to /src/pkg2/target > > > > This was good for its time, better than e.g. > outputs to /cvsroot/pkg1/src ! > > > However I want more. > > > I want /cvsroot to be read only. > > > So how about: > ?outputs to /cvsroot-out/pkg1/target > > > This is probably easy to achieve. > e.g. introduce BUILD_DIR_ROOT (or OUTPUT_ROOT) and it is defined, > prefix to BUILD_DIR. > Probably would have to be accompanied by SOURCE_ROOT, prefix it as needed. > ?e.g. relative paths that go from output to source would need to be fixed. > > > > an maybe much more so, remove ship as a separate step: > > > ? outputs to /cvsroot-out/intermed/pkg1/target/*.mo? > ? > > outputs to /cvsroot-out/inst/lib/libpkg1.so The one and only copy.? > ? outputs to /cvsroot-out/inst/pkg/pkg1/src (maybe, separate ship > step! because is a waste when still testing) > > > To "clean", you would have a choice of > > > rm -rf /cvsroot-out/* > > or mkdir /cvsroot-out2 > ?and point whatever environment variable at -inst2. > ?? (possibly by copying cm3 into out2 and pointing $PATH at it) > > > The buildlocal vs. buildglobal distinction would go away. > buildlocal + ship (which you can't do today, except by copying > manually) would be equiv of > ? set CM3_OUTPUT_ROOT=/cm3-inst.new? (or again, copy > cm3/cm3cfg/config and set PATH) > ? build everything > ? To try it out, either change PATH, or > > > ? mv /cm-inst /cm3-inst.old > ? mv /cm3-inst.new /cm3-inst > ? unset CM3_OUTPUT_ROOT > > > > If you want to build less, and remain isolated like buildlocal: > > > ? cp -pr /cm3-inst $CM3_OUTPUT_ROOT > ? build seletctively > ? To try it out, either change PATH, or > > ? mv /cm-inst /cm3-inst.old > > ? mv /cm3-inst.new /cm3-inst > > ? unset CM3_OUTPUT_ROOT > > > > > One of the points is: the immediate output of compilation could have > the same structure as the installation. > Installation can be just renaming or copying directories. Not > reorganizing directory layout. > > > buildglobal would be building into a new empty directory.-- instead > of build + don't ship > buildglobal would be building top of the in-use directory -- instead > of build + ship > > Positive consequences: > ? All unshipped binaries would work even if linked dynamically, e.g. > with $ORIGIN, e.g. without static. > ? It still doesn't address systems without $ORIGIN though. > > > There are major advantages either way -- ie. without ORIGIN you can > "stitch together" binaries whose > paths have no relationship to each other, and you can move around at > least the executables arbitrarily. > ? Though you can't move the libraries at all. > ?? chroot is another way people deal with this -- using absolute > paths, but isolated from existing files. > ??? It is kind of partial cheap virtual machine, chroot. > > > Now, I have to admit, this is more of an intellectual exercise right > now, as I don't have the time/inclination to do it soon. :( > > > ? > - Jay > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Jul 23 21:13:52 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 23 Jul 2010 19:13:52 +0000 Subject: [M3devel] openbsd threading Message-ID: If we use -pthread or -lpthread, the call to sigsuspend hangs. If we don't use -pthread or -lpthread, some tests fail to build. So I think we are stuck going back to setjmp munging, which is what 5.8.6 does. Just for OpenBSD. Darwin/amd64 and old FreeBSD can hopefully still use sigaltstack. Linux, Solaris, Darwin/non-amd64, current FreeBSD can still use get/set/make/swapcontext. Maybe I'll upgrade to OpenBSD 4.7 first and give that a shot. I'm one version behind, 4.6. ?- Jay From wagner at elegosoft.com Sat Jul 24 11:08:17 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 24 Jul 2010 11:08:17 +0200 Subject: [M3devel] m3test failure on FreeBSD Message-ID: <20100724110817.uct40io1sw0ggg88@mail.elegosoft.com> Has anybody any idea why this stubbornly fails on FreeBSD4 in current: http://hudson.modula3.com:8080/job/cm3-current-test-m3tests-FreeBSD4/10/console Obviously, the subdirectory cannot be removed by FSUtils.RmRec; error code 66 means it is not empty. I've written this small test program MODULE rmtest EXPORTS Main; IMPORT IO, FSUtils; CONST d = "/pub/users/hudson/workspace/cm3-current-test-m3tests-FreeBSD4/cm3/m3-sys/m3tests/src/p2/p240/FreeBSD4"; BEGIN TRY FSUtils.RmRec( d ); EXCEPT FSUtils.E(m) => IO.Put( m ); END; END rmtest. and of course it runs without a problem :-/ There is nothing suspicious in that directory after the test, at least I cannot see anything. I haven't noticed this problem on any other platform, and in the release branch the tests ran, too. 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 jay.krell at cornell.edu Sat Jul 24 16:34:55 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 24 Jul 2010 14:34:55 +0000 Subject: [M3devel] m3test failure on FreeBSD In-Reply-To: <20100724110817.uct40io1sw0ggg88@mail.elegosoft.com> References: <20100724110817.uct40io1sw0ggg88@mail.elegosoft.com> Message-ID: Could it be open files subject to garbage collection? Could we get more information reported at the time of the failure? ?- Jay ---------------------------------------- > Date: Sat, 24 Jul 2010 11:08:17 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] m3test failure on FreeBSD > > Has anybody any idea why this stubbornly fails on FreeBSD4 in current: > > > http://hudson.modula3.com:8080/job/cm3-current-test-m3tests-FreeBSD4/10/console > > Obviously, the subdirectory cannot be removed by FSUtils.RmRec; error > code 66 means it is not empty. > > I've written this small test program > > MODULE rmtest EXPORTS Main; > > IMPORT IO, FSUtils; > > CONST d = > "/pub/users/hudson/workspace/cm3-current-test-m3tests-FreeBSD4/cm3/m3-sys/m3tests/src/p2/p240/FreeBSD4"; > > BEGIN > TRY > FSUtils.RmRec( d ); > EXCEPT > FSUtils.E(m) => IO.Put( m ); > END; > END rmtest. > > and of course it runs without a problem :-/ > > There is nothing suspicious in that directory after the test, at least > I cannot see anything. I haven't noticed this problem on any other platform, > and in the release branch the tests ran, too. > > 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 jay.krell at cornell.edu Sun Jul 25 12:58:42 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 25 Jul 2010 10:58:42 +0000 Subject: [M3devel] FreeBSD gc stack? Message-ID: So, my real goal here is I'm reviewing why we can't/don't use pthreads on OpenBSD. ? I have a new system and would rather not do the jmpbuf munging. OpenBSD has suspend/resume like FreeBSD. You can inquire as to the stack, but it looks like you get the whole thing, not just the part currently used. And the FreeBSD code appears similar, and appears to walk it incorrectly (no, see below the code before reading the code)? void ThreadPThread__ProcessStopped (m3_pthread_t mt, void *bottom, void *context, ????????????????????????????? void (*p)(void *start, void *limit)) { ? pthread_attr_t attr; ? char *stackaddr; ? WORD_T stacksize; ? /* process the stacks */ ? if (pthread_attr_init(&attr) != 0) abort(); ? if (pthread_attr_get_np(PTHREAD_FROM_M3(mt), &attr) != 0) abort(); ? if (pthread_attr_getstack(&attr, (void **)&stackaddr, &stacksize) != 0) abort(); ? if (pthread_attr_destroy(&attr) != 0) abort(); #if 0 ? assert(stack_grows_down); /* See ThreadPThreadC.c */ #endif ? assert(context == 0); ? assert((char *)bottom >= stackaddr); ? assert((char *)bottom <= (stackaddr + stacksize)); ? p(stackaddr, bottom); ? /* assume registers are stored in the stack */ ? /* but call p to simulate processing registers: see RTHeapStats.m3 */ ? p(0, 0); } ok..it turns out "bottom" is "top"..probably you can define them either way.. it is the highest address. But still, this does have the unfortunate characteristic of scanning the entire stack, not just the "live" part, right? It looks the like the same compromise is easy to achieve on OpenBSD. I think I'll try pthreads there again. I understand it is still usermode and won't run on multiple processors, but it also provides for better portability (no setjmp munging). ?- Jay From jay.krell at cornell.edu Mon Jul 26 13:18:26 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 26 Jul 2010 11:18:26 +0000 Subject: [M3devel] pthread_self == null? Message-ID: I don't see that the standard prohibits NULL from being a valid pthread_t. ? I happened upon this only due to a problem though: OpenBSD x86 4.6 -lX11 -static gives a broken pthreads. We should add an extra boolean to this code, like, before: VAR ? holder: pthread_t; ? inCritical := 0; PROCEDURE LockHeap () = ? VAR self := pthread_self(); ? BEGIN ??? IF pthread_equal(holder, self) = 0 THEN ????? WITH r = pthread_mutex_lock(heapMu) DO <*ASSERT r=0*> END; ????? holder := self; ??? END; ??? INC(inCritical); ? END LockHeap; PROCEDURE UnlockHeap () = ? BEGIN ??? <*ASSERT pthread_equal(holder, pthread_self()) # 0*> ??? DEC(inCritical); ??? IF inCritical = 0 THEN ????? holder := NIL; ????? WITH r = pthread_mutex_unlock(heapMu) DO <*ASSERT r=0*> END; ??? END; ? END UnlockHeap; after: VAR ? holder: pthread_t; +? holder_valid: BOOLEAN; ? inCritical := 0; PROCEDURE LockHeap () = ? VAR self := pthread_self(); ? BEGIN *??? IF NOT holder_valid OR pthread_equal(holder, self) = 0 THEN ????? WITH r = pthread_mutex_lock(heapMu) DO <*ASSERT r=0*> END; ????? holder := self; +???? holder_valid := TRUE;? ??? END; ??? INC(inCritical); ? END LockHeap; PROCEDURE UnlockHeap () = ? BEGIN *??? <*ASSERT holder_valid AND pthread_equal(holder, pthread_self()) # 0*> ??? DEC(inCritical); ??? IF inCritical = 0 THEN ????? holder := NIL; +???? holder_valid := FALSE? ????? WITH r = pthread_mutex_unlock(heapMu) DO <*ASSERT r=0*> END; ??? END; ? END UnlockHeap; I think so. ?- Jay From jay.krell at cornell.edu Mon Jul 26 14:39:55 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 26 Jul 2010 12:39:55 +0000 Subject: [M3devel] newly discoved quake feature Message-ID: I didn't realize, but hash tables don't have to have values. You can say: {"key1", "key2"} contains "foo" You don't need: {"key1" : 1, "key2" : 1} contains "foo" ?- Jay From hosking at cs.purdue.edu Mon Jul 26 21:00:29 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 26 Jul 2010 15:00:29 -0400 Subject: [M3devel] pthread_self == null? In-Reply-To: References: Message-ID: <8599A6EE-9456-440F-A06D-6A3077E4BF8F@cs.purdue.edu> The standard doesn't even say that a pthread_t is a pointer. It might be an int, in which case 0 might be a valid pthread_t. On 26 Jul 2010, at 07:18, Jay K wrote: > > I don't see that the standard prohibits NULL from being a valid pthread_t. > ? > I happened upon this only due to a problem though: OpenBSD x86 4.6 -lX11 -static gives a broken pthreads. > > > We should add an extra boolean to this code, like, before: > > > VAR > holder: pthread_t; > inCritical := 0; > > PROCEDURE LockHeap () = > VAR self := pthread_self(); > BEGIN > IF pthread_equal(holder, self) = 0 THEN > WITH r = pthread_mutex_lock(heapMu) DO <*ASSERT r=0*> END; > holder := self; > END; > INC(inCritical); > END LockHeap; > > PROCEDURE UnlockHeap () = > BEGIN > <*ASSERT pthread_equal(holder, pthread_self()) # 0*> > DEC(inCritical); > IF inCritical = 0 THEN > holder := NIL; > WITH r = pthread_mutex_unlock(heapMu) DO <*ASSERT r=0*> END; > END; > END UnlockHeap; > > > > after: > > VAR > holder: pthread_t; > + holder_valid: BOOLEAN; > inCritical := 0; > > PROCEDURE LockHeap () = > VAR self := pthread_self(); > BEGIN > * IF NOT holder_valid OR pthread_equal(holder, self) = 0 THEN > WITH r = pthread_mutex_lock(heapMu) DO <*ASSERT r=0*> END; > holder := self; > + holder_valid := TRUE; > END; > INC(inCritical); > END LockHeap; > > PROCEDURE UnlockHeap () = > BEGIN > * <*ASSERT holder_valid AND pthread_equal(holder, pthread_self()) # 0*> > DEC(inCritical); > IF inCritical = 0 THEN > holder := NIL; > + holder_valid := FALSE > > WITH r = pthread_mutex_unlock(heapMu) DO <*ASSERT r=0*> END; > END; > END UnlockHeap; > > > I think so. > > > - Jay > > From jay.krell at cornell.edu Mon Jul 26 22:02:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 26 Jul 2010 20:02:44 +0000 Subject: [M3devel] pthread_self == null? In-Reply-To: <8599A6EE-9456-440F-A06D-6A3077E4BF8F@cs.purdue.edu> References: , <8599A6EE-9456-440F-A06D-6A3077E4BF8F@cs.purdue.edu> Message-ID: Agreed. So agreed with the approximate change? ?- Jay ---------------------------------------- > Subject: Re: [M3devel] pthread_self == null? > From: hosking at cs.purdue.edu > Date: Mon, 26 Jul 2010 15:00:29 -0400 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > The standard doesn't even say that a pthread_t is a pointer. > It might be an int, in which case 0 might be a valid pthread_t. > > On 26 Jul 2010, at 07:18, Jay K wrote: > > > > > I don't see that the standard prohibits NULL from being a valid pthread_t. > > ? > > I happened upon this only due to a problem though: OpenBSD x86 4.6 -lX11 -static gives a broken pthreads. > > > > > > We should add an extra boolean to this code, like, before: > > > > > > VAR > > holder: pthread_t; > > inCritical := 0; > > > > PROCEDURE LockHeap () = > > VAR self := pthread_self(); > > BEGIN > > IF pthread_equal(holder, self) = 0 THEN > > WITH r = pthread_mutex_lock(heapMu) DO <*ASSERT r=0*> END; > > holder := self; > > END; > > INC(inCritical); > > END LockHeap; > > > > PROCEDURE UnlockHeap () = > > BEGIN > > <*ASSERT pthread_equal(holder, pthread_self()) # 0*> > > DEC(inCritical); > > IF inCritical = 0 THEN > > holder := NIL; > > WITH r = pthread_mutex_unlock(heapMu) DO <*ASSERT r=0*> END; > > END; > > END UnlockHeap; > > > > > > > > after: > > > > VAR > > holder: pthread_t; > > + holder_valid: BOOLEAN; > > inCritical := 0; > > > > PROCEDURE LockHeap () = > > VAR self := pthread_self(); > > BEGIN > > * IF NOT holder_valid OR pthread_equal(holder, self) = 0 THEN > > WITH r = pthread_mutex_lock(heapMu) DO <*ASSERT r=0*> END; > > holder := self; > > + holder_valid := TRUE; > > END; > > INC(inCritical); > > END LockHeap; > > > > PROCEDURE UnlockHeap () = > > BEGIN > > * <*ASSERT holder_valid AND pthread_equal(holder, pthread_self()) # 0*> > > DEC(inCritical); > > IF inCritical = 0 THEN > > holder := NIL; > > + holder_valid := FALSE > > > > WITH r = pthread_mutex_unlock(heapMu) DO <*ASSERT r=0*> END; > > END; > > END UnlockHeap; > > > > > > I think so. > > > > > > - Jay > > > > > From wagner at elegosoft.com Tue Jul 27 11:26:02 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 27 Jul 2010 11:26:02 +0200 Subject: [M3devel] m3test failure on FreeBSD In-Reply-To: References: <20100724110817.uct40io1sw0ggg88@mail.elegosoft.com> Message-ID: <20100727112602.hp43lj5a4g8cc0kw@mail.elegosoft.com> Quoting Jay K : > Could it be open files subject to garbage collection? > Could we get more information reported at the time of the failure? See http://hudson.modula3.com:8080/job/cm3-current-test-m3tests-FreeBSD4/12/console The directory is listed directly before the RmRec operation fails. I still don't see anything suspicious :-( Olaf > ?- Jay > > > ---------------------------------------- >> Date: Sat, 24 Jul 2010 11:08:17 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] m3test failure on FreeBSD >> >> Has anybody any idea why this stubbornly fails on FreeBSD4 in current: >> >> >> http://hudson.modula3.com:8080/job/cm3-current-test-m3tests-FreeBSD4/10/console >> >> Obviously, the subdirectory cannot be removed by FSUtils.RmRec; error >> code 66 means it is not empty. >> >> I've written this small test program >> >> MODULE rmtest EXPORTS Main; >> >> IMPORT IO, FSUtils; >> >> CONST d = >> "/pub/users/hudson/workspace/cm3-current-test-m3tests-FreeBSD4/cm3/m3-sys/m3tests/src/p2/p240/FreeBSD4"; >> >> BEGIN >> TRY >> FSUtils.RmRec( d ); >> EXCEPT >> FSUtils.E(m) => IO.Put( m ); >> END; >> END rmtest. >> >> and of course it runs without a problem :-/ >> >> There is nothing suspicious in that directory after the test, at least >> I cannot see anything. I haven't noticed this problem on any other platform, >> and in the release branch the tests ran, too. >> >> 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 >> > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Wed Jul 28 11:35:31 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 28 Jul 2010 11:35:31 +0200 Subject: [M3devel] recent build failures in Hudson Message-ID: <20100728113531.ryhlvr680w8gk880@mail.elegosoft.com> Hi Jay, the recent commits seem to have negative effects on several build jobs. Unfortunately, the Hudson's CVS polling was broken for some days, so it may not be as easy as it should be to pin down the culprit(s). Can you have a look (as you've made of the changes): http://hudson.modula3.com:8080/job/cm3-current-build-AMD64_LINUX/lastBuild http://hudson.modula3.com:8080/job/cm3-current-build-PPC_LINUX/lastBuild http://hudson.modula3.com:8080/job/cm3-current-m3cc-AMD64_LINUX/lastBuild http://hudson.modula3.com:8080/job/cm3-current-m3cc-FreeBSD4/lastBuild/ http://hudson.modula3.com:8080/job/cm3-current-test-all-pkgs-FreeBSD4/lastBuild This has been broken since the start of regression for current: http://hudson.modula3.com:8080/job/cm3-current-build-SPARC32_LINUX/lastBuild Thanks in advance, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 28 12:04:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 28 Jul 2010 10:04:20 +0000 Subject: [M3devel] recent build failures in Hudson In-Reply-To: <20100728113531.ryhlvr680w8gk880@mail.elegosoft.com> References: <20100728113531.ryhlvr680w8gk880@mail.elegosoft.com> Message-ID: Mostly this is again just due to older config files. I thought the config files would have been updated by new. I'll fix it to not need them, for now. SPARC32_LINUX is different, unique to it, I'll get to it (I don't know the *exact* fix, but I understand somewhat the problem), but it isn't urgent. Thanks for the heads up. - Jay > Date: Wed, 28 Jul 2010 11:35:31 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: recent build failures in Hudson > > Hi Jay, > > the recent commits seem to have negative effects on several build jobs. > Unfortunately, the Hudson's CVS polling was broken for some days, so > it may not be as easy as it should be to pin down the culprit(s). > > Can you have a look (as you've made of the changes): > > http://hudson.modula3.com:8080/job/cm3-current-build-AMD64_LINUX/lastBuild > http://hudson.modula3.com:8080/job/cm3-current-build-PPC_LINUX/lastBuild > http://hudson.modula3.com:8080/job/cm3-current-m3cc-AMD64_LINUX/lastBuild > http://hudson.modula3.com:8080/job/cm3-current-m3cc-FreeBSD4/lastBuild/ > > http://hudson.modula3.com:8080/job/cm3-current-test-all-pkgs-FreeBSD4/lastBuild > > This has been broken since the start of regression for current: > > http://hudson.modula3.com:8080/job/cm3-current-build-SPARC32_LINUX/lastBuild > > Thanks in advance, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Jul 28 12:09:27 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 28 Jul 2010 12:09:27 +0200 Subject: [M3devel] recent build failures in Hudson In-Reply-To: References: <20100728113531.ryhlvr680w8gk880@mail.elegosoft.com> Message-ID: <20100728120927.ey5hfhm0xs0c8kg4@mail.elegosoft.com> Quoting Jay K : > Mostly this is again just due to older config files. > I thought the config files would have been updated by new. I'll fix > it to not need them, for now. > SPARC32_LINUX is different, unique to it, I'll get to it (I don't > know the *exact* fix, but > I understand somewhat the problem), but it isn't urgent. OK. I'm still trying to figure out the problem with CVS polling. It seems to work for some nodes, but Hudson keeps displaying its warning that something's wrong. Olaf > Thanks for the heads up. > - Jay > > >> Date: Wed, 28 Jul 2010 11:35:31 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: recent build failures in Hudson >> >> Hi Jay, >> >> the recent commits seem to have negative effects on several build jobs. >> Unfortunately, the Hudson's CVS polling was broken for some days, so >> it may not be as easy as it should be to pin down the culprit(s). >> >> Can you have a look (as you've made of the changes): >> >> http://hudson.modula3.com:8080/job/cm3-current-build-AMD64_LINUX/lastBuild >> http://hudson.modula3.com:8080/job/cm3-current-build-PPC_LINUX/lastBuild >> http://hudson.modula3.com:8080/job/cm3-current-m3cc-AMD64_LINUX/lastBuild >> http://hudson.modula3.com:8080/job/cm3-current-m3cc-FreeBSD4/lastBuild/ >> >> http://hudson.modula3.com:8080/job/cm3-current-test-all-pkgs-FreeBSD4/lastBuild >> >> This has been broken since the start of regression for current: >> >> http://hudson.modula3.com:8080/job/cm3-current-build-SPARC32_LINUX/lastBuild >> >> Thanks in advance, >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 jay.krell at cornell.edu Wed Jul 28 12:08:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 28 Jul 2010 10:08:02 +0000 Subject: [M3devel] recent build failures in Hudson In-Reply-To: References: <20100728113531.ryhlvr680w8gk880@mail.elegosoft.com>, Message-ID: --- building in FreeBSD4 --- ignoring ../src/m3overrides rm ./config.status rm ./.M3SHIP rm ./serdep.tmp rm ./cm3cg rm ./config.log rm ./Makefile rm ./m3make.args rm ./_m3.log rm -rf ./libcpp rm -rf ./build-i586-unknown-freebsd4 rm -rf ./gmp "/pub/users/hudson/workspace/cm3-current-m3cc-FreeBSD4/cm3/m3-sys/m3cc/src/m3makefile", line 369: quake runtime error: cannot remove recursively ./gmp: error traversing directory ./gmp/.libs: errno=2 This is wierd. I think we have good evidence now that RmRec has problems -- that is what is being used here and what is failing on FreeBSD4 tests that you have been asking about. This code in m3cc/src/m3makefile is attempting a clean build, by deleting outputs. For now I'll connect to the machines and manually delete the output directory. This RmRec stuff needs more investigation though. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: RE: recent build failures in Hudson Date: Wed, 28 Jul 2010 10:04:20 +0000 Mostly this is again just due to older config files. I thought the config files would have been updated by new. I'll fix it to not need them, for now. SPARC32_LINUX is different, unique to it, I'll get to it (I don't know the *exact* fix, but I understand somewhat the problem), but it isn't urgent. Thanks for the heads up. - Jay > Date: Wed, 28 Jul 2010 11:35:31 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: recent build failures in Hudson > > Hi Jay, > > the recent commits seem to have negative effects on several build jobs. > Unfortunately, the Hudson's CVS polling was broken for some days, so > it may not be as easy as it should be to pin down the culprit(s). > > Can you have a look (as you've made of the changes): > > http://hudson.modula3.com:8080/job/cm3-current-build-AMD64_LINUX/lastBuild > http://hudson.modula3.com:8080/job/cm3-current-build-PPC_LINUX/lastBuild > http://hudson.modula3.com:8080/job/cm3-current-m3cc-AMD64_LINUX/lastBuild > http://hudson.modula3.com:8080/job/cm3-current-m3cc-FreeBSD4/lastBuild/ > > http://hudson.modula3.com:8080/job/cm3-current-test-all-pkgs-FreeBSD4/lastBuild > > This has been broken since the start of regression for current: > > http://hudson.modula3.com:8080/job/cm3-current-build-SPARC32_LINUX/lastBuild > > Thanks in advance, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Jul 28 12:18:50 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 28 Jul 2010 12:18:50 +0200 Subject: [M3devel] recent build failures in Hudson In-Reply-To: References: <20100728113531.ryhlvr680w8gk880@mail.elegosoft.com>, Message-ID: <20100728121850.uqea76js00oosocg@mail.elegosoft.com> Quoting Jay K : > --- building in FreeBSD4 --- > > ignoring ../src/m3overrides > > rm ./config.status > rm ./.M3SHIP > rm ./serdep.tmp > rm ./cm3cg > rm ./config.log > rm ./Makefile > rm ./m3make.args > rm ./_m3.log > rm -rf ./libcpp > rm -rf ./build-i586-unknown-freebsd4 > rm -rf ./gmp > "/pub/users/hudson/workspace/cm3-current-m3cc-FreeBSD4/cm3/m3-sys/m3cc/src/m3makefile", line 369: quake runtime error: cannot remove recursively ./gmp: error traversing directory ./gmp/.libs: > errno=2 > > This is wierd. > I think we have good evidence now that RmRec has problems -- that is > what is being used here and what is failing on FreeBSD4 tests that > you have been asking about. > > This code in m3cc/src/m3makefile is attempting a clean build, by > deleting outputs. > For now I'll connect to the machines and manually delete the output > directory. > This RmRec stuff needs more investigation though. It didn't fail for FreeBSD before, i.e. on the release branch. And it's only on the i386 machine (running FreeBSD 6.4), not on my amd64 running FreeBSD 8.1. Any ideas what I could check again tonight? Any specific changes for this target? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 28 12:36:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 28 Jul 2010 10:36:32 +0000 Subject: [M3devel] recent build failures in Hudson In-Reply-To: <20100728121850.uqea76js00oosocg@mail.elegosoft.com> References: <20100728113531.ryhlvr680w8gk880@mail.elegosoft.com>, , , <20100728121850.uqea76js00oosocg@mail.elegosoft.com> Message-ID: Oops, to clarify, it isn't only on FreeBSD4, also http://hudson.modula3.com:8080/job/cm3-current-m3cc-AMD64_LINUX/lastBuild/console I might debug this is a bit first, before just deleting the directories. ?- Jay ---------------------------------------- > Date: Wed, 28 Jul 2010 12:18:50 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: recent build failures in Hudson > > Quoting Jay K : > > > --- building in FreeBSD4 --- > > > > ignoring ../src/m3overrides > > > > rm ./config.status > > rm ./.M3SHIP > > rm ./serdep.tmp > > rm ./cm3cg > > rm ./config.log > > rm ./Makefile > > rm ./m3make.args > > rm ./_m3.log > > rm -rf ./libcpp > > rm -rf ./build-i586-unknown-freebsd4 > > rm -rf ./gmp > > "/pub/users/hudson/workspace/cm3-current-m3cc-FreeBSD4/cm3/m3-sys/m3cc/src/m3makefile", line 369: quake runtime error: cannot remove recursively ./gmp: error traversing directory ./gmp/.libs: > > errno=2 > > > > This is wierd. > > I think we have good evidence now that RmRec has problems -- that is > > what is being used here and what is failing on FreeBSD4 tests that > > you have been asking about. > > > > This code in m3cc/src/m3makefile is attempting a clean build, by > > deleting outputs. > > For now I'll connect to the machines and manually delete the output > > directory. > > This RmRec stuff needs more investigation though. > > It didn't fail for FreeBSD before, i.e. on the release branch. > And it's only on the i386 machine (running FreeBSD 6.4), not on > my amd64 running FreeBSD 8.1. > > Any ideas what I could check again tonight? > Any specific changes for this target? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Wed Jul 28 13:13:55 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 28 Jul 2010 11:13:55 +0000 Subject: [M3devel] CVS polling related? Message-ID: CVS polling related? % Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... birch cvs: cvs update: New directory `m3-sys/m3cc/gcc/gcc/config/vax' -- ignored Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... birch cvs: error (1, 0) called recursively.? Second message was: Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... birch cvs: cvs update: New directory `m3-sys/m3cc/gcc/gcc/config/vax' -- ignored Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... birch cvs: error (1, 0) called recursively.? Second message was: Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... birch cvs: error (0, 0) called recursively.? Original message was: Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... birch cvs: cvs [update aborted]: received broken pipe signal Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... birch cvs: error (0, 0) called recursively.? Original message was: Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... birch cvs: cvs [update aborted]: received broken pipe signal Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... birch cvs: Aborting. Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... birch cvs: Aborting. From jay.krell at cornell.edu Wed Jul 28 13:19:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 28 Jul 2010 11:19:08 +0000 Subject: [M3devel] recent build failures in Hudson In-Reply-To: References: <20100728113531.ryhlvr680w8gk880@mail.elegosoft.com>, , , , , , <20100728121850.uqea76js00oosocg@mail.elegosoft.com>, Message-ID: I manually deleted the gmp directory on AMD64_LINUX and will get FreeBSD4. "Very soon" I'll trigger this code again -- but this time, sysutils might report more information before the error. I wonder if it has to do with the symlink in there, but the code looks correct -- it'd treat symlinks as a regular file. We'll see what the sysutils/RTIO reports when we get the failure next. The sysutils/RTIO code might mix up other code, e.g. diffs in the tests. Please ignore that for a bit unless it is too catastrophic -- ie. if building stuff is also broken by it. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > Date: Wed, 28 Jul 2010 10:36:32 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] recent build failures in Hudson > > > Oops, to clarify, it isn't only on FreeBSD4, also http://hudson.modula3.com:8080/job/cm3-current-m3cc-AMD64_LINUX/lastBuild/console > I might debug this is a bit first, before just deleting the directories. > > - Jay > > ---------------------------------------- > > Date: Wed, 28 Jul 2010 12:18:50 +0200 > > From: wagner at elegosoft.com > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: RE: recent build failures in Hudson > > > > Quoting Jay K : > > > > > --- building in FreeBSD4 --- > > > > > > ignoring ../src/m3overrides > > > > > > rm ./config.status > > > rm ./.M3SHIP > > > rm ./serdep.tmp > > > rm ./cm3cg > > > rm ./config.log > > > rm ./Makefile > > > rm ./m3make.args > > > rm ./_m3.log > > > rm -rf ./libcpp > > > rm -rf ./build-i586-unknown-freebsd4 > > > rm -rf ./gmp > > > "/pub/users/hudson/workspace/cm3-current-m3cc-FreeBSD4/cm3/m3-sys/m3cc/src/m3makefile", line 369: quake runtime error: cannot remove recursively ./gmp: error traversing directory ./gmp/.libs: > > > errno=2 > > > > > > This is wierd. > > > I think we have good evidence now that RmRec has problems -- that is > > > what is being used here and what is failing on FreeBSD4 tests that > > > you have been asking about. > > > > > > This code in m3cc/src/m3makefile is attempting a clean build, by > > > deleting outputs. > > > For now I'll connect to the machines and manually delete the output > > > directory. > > > This RmRec stuff needs more investigation though. > > > > It didn't fail for FreeBSD before, i.e. on the release branch. > > And it's only on the i386 machine (running FreeBSD 6.4), not on > > my amd64 running FreeBSD 8.1. > > > > Any ideas what I could check again tonight? > > Any specific changes for this target? > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Wed Jul 28 13:26:55 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 28 Jul 2010 13:26:55 +0200 Subject: [M3devel] CVS polling related? In-Reply-To: References: Message-ID: <20100728132655.e60y0jalckwkw08w@mail.elegosoft.com> Quoting Jay K : > CVS polling related? Probably. The 'cvs: error (1, 0) called recursively' are a known annoyance though. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=386153 http://savannah.nongnu.org/bugs/?26608 for details. Olaf > % > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > birch cvs: cvs update: New directory > `m3-sys/m3cc/gcc/gcc/config/vax' -- ignored > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > birch cvs: error (1, 0) called recursively.? Second message was: > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > birch cvs: cvs update: New directory > `m3-sys/m3cc/gcc/gcc/config/vax' -- ignored > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > birch cvs: error (1, 0) called recursively.? Second message was: > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > birch cvs: error (0, 0) called recursively.? Original message was: > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > birch cvs: cvs [update aborted]: received broken pipe signal > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > birch cvs: error (0, 0) called recursively.? Original message was: > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > birch cvs: cvs [update aborted]: received broken pipe signal > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > birch cvs: Aborting. > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > birch cvs: Aborting. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 28 13:38:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 28 Jul 2010 11:38:31 +0000 Subject: [M3devel] CVS polling related? In-Reply-To: <20100728132655.e60y0jalckwkw08w@mail.elegosoft.com> References: , <20100728132655.e60y0jalckwkw08w@mail.elegosoft.com> Message-ID: bug was reported in 2006. Presumably the fix is to not use CVS! What bothers me about CVS: 1) When there is a multi-file commit, there is no one link to follow to see the diffs. Hudson helps. But I want cvsweb to provide it. This is usually naturally fixed by any system with atomic commit as they identity the multi-file commit with one identifiers. 2) Everything is excruciatingly slow because everything goes to the network. 2a) I want cvs diff to not go to the network. 2b) I want a "cvs revert" command; what I frequently do is rename or delete my edits and then cvs upd to get the file back. In Perforce this is just p4 revert ... 3) I don't want it dropping CVS directories in every single directory. Just at the top of the tree, or preferably just one file or preferably in a parallel location; diffing two checkouts is made awful by this. I believe subversion has the same bug. Perforce does not. More cvs oddity, like, it was missing everything, and printed lots of odd stuff: http://hudson.modula3.com:8080/job/cm3-current-build-PPC_LINUX/25/consoleFull I'll poke at that some. I don't even see the workspace anywhere. ?- Jay ---------------------------------------- > Date: Wed, 28 Jul 2010 13:26:55 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: CVS polling related? > > Quoting Jay K : > > > CVS polling related? > > Probably. The 'cvs: error (1, 0) called recursively' are a > known annoyance though. See > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=386153 > http://savannah.nongnu.org/bugs/?26608 > > for details. > > Olaf > > > % > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > > birch cvs: cvs update: New directory > > `m3-sys/m3cc/gcc/gcc/config/vax' -- ignored > > > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > > birch cvs: error (1, 0) called recursively. Second message was: > > > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > > birch cvs: cvs update: New directory > > `m3-sys/m3cc/gcc/gcc/config/vax' -- ignored > > > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > > birch cvs: error (1, 0) called recursively. Second message was: > > > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > > birch cvs: error (0, 0) called recursively. Original message was: > > > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > > birch cvs: cvs [update aborted]: received broken pipe signal > > > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > > birch cvs: error (0, 0) called recursively. Original message was: > > > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > > birch cvs: cvs [update aborted]: received broken pipe signal > > > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > > birch cvs: Aborting. > > > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > > birch cvs: Aborting. > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Wed Jul 28 16:17:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 28 Jul 2010 14:17:24 +0000 Subject: [M3devel] The various hudson tasks Message-ID: Olaf, it is a bit odd that there are "m3cc" tasks and "other", but yet "other" does build m3cc. e.g.: http://hudson.modula3.com:8080/job/cm3-current-build-SPARC32_LINUX/35/console I seem to always be confused by what the tasks are. :( ?- Jay From wagner at elegosoft.com Wed Jul 28 16:49:21 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 28 Jul 2010 16:49:21 +0200 Subject: [M3devel] The various hudson tasks In-Reply-To: References: Message-ID: <20100728164921.2u9en41kgswgc88k@mail.elegosoft.com> Quoting Jay K : > Olaf, it is a bit odd that there are "m3cc" tasks and "other", but > yet "other" does build m3cc. > e.g.: > > http://hudson.modula3.com:8080/job/cm3-current-build-SPARC32_LINUX/35/console > > I seem to always be confused by what the tasks are. :( There is such a thing as a "standard CM3 system build and if necessary upgrade". This is included in the (1) cm3-current-build-* jobs for the CVS trunk. The build of the gcc backend has been extracted from that task, as it is based on different and differently licensed sources and takes quite a long time compared to M3 builds. The gcc backend builds are contained in the (2) cm3-current-m3cc-* jobs. The result of this job is used by other build jobs if available. There are two classes of test jobs: (3) cm3-current-test-m3tests-* just runs the m3tests package tests for the compiler. (4) cm3-current-test-all-pkgs-* is like a "build world"; i.e. it compiles all packages, compiles all associated test packages, and runs all associated tests if available. Apart from those there are groups of jobs for building distribution archives and for downloading and testing those. Any suggestions for a better setup are welcome. The existing setup has worked reasonably well in the past though. If anybody wants to play with the Hudson job and try something new, he is welcome if he promises not to bring down the existing Hudson tasks and other services. Hudson can be completely controlled via the HTTP GUI. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 28 17:23:29 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 28 Jul 2010 15:23:29 +0000 Subject: [M3devel] cvs warning about gcc/install,fixincludes directories Message-ID: http://hudson.modula3.com:8080/job/cm3-current-build-FreeBSD4/7/console P m3-sys/cm3/src/M3Build.m3 cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/INSTALL' cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/fixincludes' Some CVS weirdness here. I've resorted to deleting these directories on machines I can be hudson on. Then they come back and I think they are ok. i.e. not PPC_LINUX, FreeBSD4. We could also just delete these directories from cvs. - Jay From jay.krell at cornell.edu Wed Jul 28 17:32:23 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 28 Jul 2010 15:32:23 +0000 Subject: [M3devel] The various hudson tasks In-Reply-To: <20100728164921.2u9en41kgswgc88k@mail.elegosoft.com> References: , <20100728164921.2u9en41kgswgc88k@mail.elegosoft.com> Message-ID: m3cc is both in its own task and in the cm3 task. I don't understand why it is in both. This also causes the sources to be duplicated more. Given proper incrementality, the split shouldn't be needed. ? But ok. Splitting might resemble the future distribution form as well -- ie, one that is more like the old DEC SRC one. And I'm sure there are incrementality bugs, e.g. like when files are added/deleted/moved. ? Every time I've moved a file it has caused problems. I kind of think it should always "upgrade" for some definition of that. Always start with cm3/cm3cg/m3core/config files, and I guess libm3. Build up to cm3, skipping cm3cg, m3core, libm3. Copy/install cm3. Build cm3cg incrementally Clean everything but cm3cg. Too expensive? Build m3core up to cm3. Copy/install cm3. clean everything but cm3cg. Too expensive? Build everything. I can see that might be too expensive though. On the other hand, if the compiler changes, you really need to buid everything clean. As I assume incrementality doesn't take into account the compiler's timestamp, and if it did, it'd all be clean anyway. But I'm not keen on changing this stuff. It seems kind of difficult and very time consuming to get working, and extremely nice to have in almost any working form. Thanks, ?- Jay ---------------------------------------- > Date: Wed, 28 Jul 2010 16:49:21 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: The various hudson tasks > > Quoting Jay K : > > > Olaf, it is a bit odd that there are "m3cc" tasks and "other", but > > yet "other" does build m3cc. > > e.g.: > > > > http://hudson.modula3.com:8080/job/cm3-current-build-SPARC32_LINUX/35/console > > > > I seem to always be confused by what the tasks are. :( > > There is such a thing as a "standard CM3 system build and if necessary > upgrade". > This is included in the (1) cm3-current-build-* jobs for the CVS trunk. > > The build of the gcc backend has been extracted from that task, as > it is based on different and differently licensed sources and takes > quite a long time compared to M3 builds. > > The gcc backend builds are contained in the (2) cm3-current-m3cc-* jobs. > The result of this job is used by other build jobs if available. > > There are two classes of test jobs: > > (3) cm3-current-test-m3tests-* just runs the m3tests package tests > for the compiler. > > (4) cm3-current-test-all-pkgs-* is like a "build world"; i.e. it > compiles all packages, compiles all associated test packages, > and runs all associated tests if available. > > Apart from those there are groups of jobs for building distribution > archives and for downloading and testing those. > > Any suggestions for a better setup are welcome. > The existing setup has worked reasonably well in the past though. > > If anybody wants to play with the Hudson job and try something new, > he is welcome if he promises not to bring down the existing Hudson > tasks and other services. Hudson can be completely controlled via > the HTTP GUI. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Wed Jul 28 18:32:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 28 Jul 2010 16:32:10 +0000 Subject: [M3devel] FreeBSD atomics Message-ID: There seems to be a problem where the atomics are all failing on FreeBSD4. http://hudson.modula3.com:8080/job/cm3-current-test-all-pkgs-FreeBSD4/ I'll investigate. All the x86 config files share code: -march=i586. So it is surprising. Possibly in parse.c we should make it at least 586 independent of the command line. ?- Jay From jay.krell at cornell.edu Wed Jul 28 18:38:49 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 28 Jul 2010 16:38:49 +0000 Subject: [M3devel] openbsd/pthread/sigaltstack.. Message-ID: For the record..: Latest experiments: pthreads on OpenBSD hit some problems, assertion failures. I didn't debug. Maybe should. The sigaltstack strategy to portable user threads works. But it hangs on OpenBSD if you use -pthread. I didn't debug the hang. Maybe should. So it seems viable to be portable with sigaltstack and omit -pthread. But if you omit -pthread, then you run into e.g.: http://hudson.modula3.com:8080/job/cm3-current-test-all-pkgs-I386_OPENBSD/3/artifact/cm3-pkg-report-I386_OPENBSD.html#tr_m3-db-odbc /usr/local/lib/libiodbc.so.3.15: undefined reference to `pthread_mutex_unlock' /usr/local/lib/libiodbc.so.3.15: undefined reference to `pthread_self' /usr/local/lib/libiodbc.so.3.15: undefined reference to `pthread_mutex_lock' /usr/local/lib/libiodbc.so.3.15: undefined reference to `pthread_mutex_init' So the choice is unfortunate: much more portability with sigaltstack, or don't support packages such as odbc, or heck, just don't support OpenBSD, or debug the pthread problem (not the hang, though there is that, the problem of using actual pthreads). I'm also not keen on a solutiion that "randomly" stops working when user links with -pthread. It should work the same either way (at least if it links either way). For now I'm ok with jmpbuf hacking, but it disappointing. 5.8.6 used jmpbug hacking. ?- Jay From jay.krell at cornell.edu Wed Jul 28 18:47:56 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 28 Jul 2010 16:47:56 +0000 Subject: [M3devel] OpenBSD/powerpc Message-ID: There are very recent min/all distributions of openbsd/powerpc here: ? http://modula3.elegosoft.com/cm3/uploaded-archives/ I disabled dynamic linking of Modula-3 libraries, via config files, commited. Using -fPIC results in assembly errors all over the place. (Maybe I should try lowercase -fpic?) Not using -fPIC..I get a bunch of "unresolved symbol ''" at runtime -- like that, it reports the symbol name in single quotes and it is empty. Presumably this could be fixed, but presumably it doesn't matter much either. OpenBSD seems to like a pretty nice system (for a Posix system, other than MacOSX...), unless you try to get Modula-3 running on it. ?Then it seems kind of like the odd one out. Current OpenBSD is "stuck" with old gcc 3.x (I think even 2.x for some targets). It might be a good approach to import and patch their gcc fork, if anyone really wanted this to work. ? Or the hypothetical C-generating backend.. Given we already have 3 copies of gcc, I'm reluctant. Maybe when we move from 4.3 to 4.5 and delete one. Java doesn't seem to be available (a systematic problem across a certain range of systems), so Hudson won't be available so just these occasional unofficial releases I think will be it. (nice: 1) it isn't badly fractured like Linux; 2) comes with full source to the system like all *BSD; nice package system like all *BSD 3) easy to install, including you need merely one file locally and everything else can be installed over the net, very good device support.) ?- Jay From wagner at elegosoft.com Wed Jul 28 18:53:51 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 28 Jul 2010 18:53:51 +0200 Subject: [M3devel] The various hudson tasks In-Reply-To: References: , <20100728164921.2u9en41kgswgc88k@mail.elegosoft.com> Message-ID: <20100728185351.c50y1dwpwwcwcw8s@mail.elegosoft.com> Quoting Jay K : > m3cc is both in its own task and in the cm3 task. > I don't understand why it is in both. > This also causes the sources to be duplicated more. I don't follow you here. If the backend has already be built by the m3cc job, it should be used by the M3 builds. > Given proper incrementality, the split shouldn't be needed. ? > But ok. > Splitting might resemble the future distribution form as well -- ie, > one that is more like the old DEC SRC one. > And I'm sure there are incrementality bugs, e.g. like when files are > added/deleted/moved. > ? Every time I've moved a file it has caused problems. Yes. This is a known problem with the package-oriented builder. > I kind of think it should always "upgrade" for some definition of that. > Always start with cm3/cm3cg/m3core/config files, and I guess libm3. > Build up to cm3, skipping cm3cg, m3core, libm3. > Copy/install cm3. > Build cm3cg incrementally > Clean everything but cm3cg. Too expensive? Yes. > Build m3core up to cm3. > Copy/install cm3. > clean everything but cm3cg. Too expensive? > Build everything. > > I can see that might be too expensive though. > On the other hand, if the compiler changes, you really need to buid > everything clean. Yes. I'll be happy if I find an easy way to incorporate this into the existing tasks. If I only had more spare time... > As I assume incrementality doesn't take into account the compiler's > timestamp, and if it did, it'd all be clean anyway. > > But I'm not keen on changing this stuff. > It seems kind of difficult and very time consuming to get working, > and extremely nice to have in almost any working form. Thanks. I'll try to make incremental improvements as I find the time, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 28 19:40:26 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 28 Jul 2010 17:40:26 +0000 Subject: [M3devel] FreeBSD atomics In-Reply-To: References: Message-ID: I don't get it. Maybe old config files still?? It works for me: %./gcc 1.c -march=i586 %cat 1.c long long F1(long long* a, long long b) { ? return __sync_fetch_and_and_8(a, b); } int main() { } %uname -a FreeBSD fbsd4 4.11-RELEASE FreeBSD 4.11-RELEASE #0: Fri Jan 21 17:21:22 GMT 2005???? root at perseus.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC? i386 %./gcc -v Using built-in specs. Target: i386-unknown-freebsd4.11 Configured with: /home/jay/src/gcc-4.3.4/configure -disable-nls -prefix=/home/jay/gcc-4.3.4 Thread model: posix gcc version 4.3.4 (GCC) % I'll wait. Maybe the config files are old. Really this stuff should be the same across all I386 targets, unless maybe sometimes the "operating system" implies a minimum supported processor architecture. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: FreeBSD atomics > Date: Wed, 28 Jul 2010 16:32:10 +0000 > > > There seems to be a problem where the atomics are all failing on FreeBSD4. > > http://hudson.modula3.com:8080/job/cm3-current-test-all-pkgs-FreeBSD4/ > > I'll investigate. > > All the x86 config files share code: -march=i586. > So it is surprising. > Possibly in parse.c we should make it at least 586 independent of the command line. > > - Jay > > > > > From michael.anderson at elego.de Thu Jul 29 13:50:16 2010 From: michael.anderson at elego.de (Michael Anderson) Date: Thu, 29 Jul 2010 13:50:16 +0200 Subject: [M3devel] [elego Server Maintenance] Friday 30.07.2010 20:00 Message-ID: <20100729135016.0wuslzeyccs0cw4k@mail.elego.de> Hello, On Friday, July 30 at 8 PM CEST, we will perform scheduled maintenance on our servers, including the modula3 CVS server and Hudson CI server. Expected duration: 120 Min. We apologize for any inconvenience. - the elego Admins -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From rcolebur at SCIRES.COM Fri Jul 30 03:35:30 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Thu, 29 Jul 2010 21:35:30 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20100728142204.996F52474003@birch.elegosoft.com> References: <20100728142204.996F52474003@birch.elegosoft.com> Message-ID: Jay, before you go removing stuff on an assumption, maybe you should check with the group. I do know what this message means and it does have value. Regards, Randy ________________________________________ From: Jay Krell [jkrell at elego.de] Sent: Wednesday, July 28, 2010 12:22 PM To: m3commit at elegosoft.com Subject: [M3commit] CVS Update: cm3 CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 16:22:03 Modified files: cm3/m3-sys/cm3/src/: M3Build.m3 Log message: remove more of the code for: remove the "ignoring override" print out, I think few people know it means and fewer (nobody) finds it useful From jay.krell at cornell.edu Fri Jul 30 03:58:45 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 30 Jul 2010 01:58:45 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20100728142204.996F52474003@birch.elegosoft.com>, Message-ID: Randy, Without reading the code, what does it mean? My first guess was I believe wrong and based on reading the code I think it is even more pointless than I previously thought. It gets printed *all the time*, when using overrides. Look at any of the Hudson logs. It wouldn't be printed so much in the older way of doing things, where overrides were applied haphazardly and incompletely. Now that they are used fairly consistently/correctly, it always triggers. I hope to eventually replace the overrides mechanism -- if we just put files into a designated root directory, with the same structure as "the install", then "override" is just setting that directory, optionally prepopulating with an entire copy of the current install -- depending on if you want to build up from scratch or selectively override. You could use hardlinks to speed it up, as long as our copy is delete + copy and not just copy (sometimes a copy will share with the original link(s), sometimes it will unshare, depending on the open flags (I think) or if you first delete). And "install" becomes just moving the install root, if the new one is complete. What isn't easy though is "stitching together of multiple sparse pieces". overrides can do that today. $ORIGIN and the old full paths are both at odds with that though. If you make a complete, full paths are wrong. If you make an incomplete copy, $ORIGIN is wrong. "stitching together of multipl sparse pieces" is maybe the job of LD_LIBARY_PATH though, and makes no guarantees (since you might have duplicates and it becomes order-dependent). It might help if the "new" root is symlinks..except it doesn't -- no way for old files to point to new. General point noted. And if I fail, we have m3commit. Gotta run, - Jay > From: rcolebur at SCIRES.COM > To: m3devel at elegosoft.com > Date: Thu, 29 Jul 2010 21:35:30 -0400 > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Jay, before you go removing stuff on an assumption, maybe you should check with the group. I do know what this message means and it does have value. > Regards, > Randy > > ________________________________________ > From: Jay Krell [jkrell at elego.de] > Sent: Wednesday, July 28, 2010 12:22 PM > To: m3commit at elegosoft.com > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/07/28 16:22:03 > > Modified files: > cm3/m3-sys/cm3/src/: M3Build.m3 > > Log message: > remove more of the code for: remove the "ignoring override" print out, I think few people know it means and fewer (nobody) finds it useful -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 30 15:20:40 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 30 Jul 2010 13:20:40 +0000 Subject: [M3devel] rmrec problems Message-ID: Olaf, I suggest that maybe deleting while enumerating is undefined? We should try enumerating first, and then deleting, at least on a per-directory basis, not recursively. ? Even though that is bad in terms of working set -- small constant to unbounded. As well, recursion on the machine stack that is bounded by user input, is to be avoided. User can provide arbitrarily deep input and you blow the stack. Better to use a queue or stack data structure, add elements, and loop while not empty. I can try something here within a week, we can see if it helps. Stopgap might be to double up the rmrec calls and see what happens. Maybe delete while enumerate works under some conditions. Maybe I'm just randomly guessing (yes) and am way off (unknown). ?- Jay From jay.krell at cornell.edu Fri Jul 30 15:23:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 30 Jul 2010 13:23:43 +0000 Subject: [M3devel] rmrec problems In-Reply-To: References: Message-ID: Better theory: readdir uses globals. Suggest readdir_r... ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Subject: rmrec problems > Date: Fri, 30 Jul 2010 13:20:40 +0000 > > > Olaf, I suggest that maybe deleting while enumerating is undefined? > We should try enumerating first, and then deleting, at least on a per-directory basis, not recursively. > Even though that is bad in terms of working set -- small constant to unbounded. > > > As well, recursion on the machine stack that is bounded by user input, is to be avoided. > User can provide arbitrarily deep input and you blow the stack. > Better to use a queue or stack data structure, add elements, and loop while not empty. > > > I can try something here within a week, we can see if it helps. > > > Stopgap might be to double up the rmrec calls and see what happens. > Maybe delete while enumerate works under some conditions. > > > Maybe I'm just randomly guessing (yes) and am way off (unknown). > > - Jay > > > > > From hendrik at topoi.pooq.com Fri Jul 30 23:50:51 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 30 Jul 2010 17:50:51 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: Message-ID: <20100730215051.GA23133@topoi.pooq.com> On Fri, Jul 30, 2010 at 01:58:45AM +0000, Jay K wrote: > > Randy, Without reading the code, what does it mean? > > My first guess was I believe wrong and based on reading the code I think it is even more pointless than I previously thought. > > It gets printed *all the time*, when using overrides. Look at any of the Hudson logs. > > It wouldn't be printed so much in the older way of doing things, where overrides were applied haphazardly and incompletely. Now that they are used fairly consistently/correctly, it always triggers. I hope to eventually replace the overrides mechanism -- if we just put files into a designated root directory, with the same structure as "the install", then "override" is just setting that directory, optionally prepopulating with an entire copy of the current install -- depending on if you want to build up from scratch or selectively override. You could use hardlinks to speed it up, as long as our copy is delete + copy and not just copy (sometimes a copy will share with the original link(s), sometimes it will unshare, depending on the open flags (I think) or if you first delete). And "install" becomes just moving the install root, if the new one is complete. I remember using an override somewhere ... but I don't remember where or why now. But I'd worry if this change broke something. -- hendrik From jay.krell at cornell.edu Thu Jul 1 11:23:01 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 1 Jul 2010 09:23:01 +0000 Subject: [M3devel] m3tests/cmp_fie vs. compare_file Message-ID: I find it confusing that m3-sys/m3tests/src/m3makefile contains both cmp_file and compare_file (unless one was a thin wrapper over the other, not the case) Olaf you added cmp_file in http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3tests/src/m3makefile.diff?r1=1.3;r2=1.4. Presumably they can be merged into one function? ?- Jay From wagner at elegosoft.com Thu Jul 1 11:38:53 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 01 Jul 2010 11:38:53 +0200 Subject: [M3devel] m3tests/cmp_fie vs. compare_file In-Reply-To: References: Message-ID: <20100701113853.cn7e82bwso48oc0s@mail.elegosoft.com> Quoting Jay K : > > I find it confusing that m3-sys/m3tests/src/m3makefile contains both > cmp_file and compare_file (unless one was a thin wrapper over the > other, not the case) > Olaf you added cmp_file in > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3tests/src/m3makefile.diff?r1=1.3;r2=1.4. > > Presumably they can be merged into one function? compare_file() writes output and doesn't return anything meaningful (it's a procedure), while cmp_file is a boolean state function that doesn't write anything to stdout. The first could be based on the second. Of course you can find a common signature, but then you'll have to change all occurences and add a use case parameter, which isn't nice, too. Perhaps you can suggest better names? Please do not change the semantics (i.e. the use of @cmp, for example) though, as that might break the regression tests. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Jul 1 12:26:15 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 1 Jul 2010 10:26:15 +0000 Subject: [M3devel] m3tests/cmp_fie vs. compare_file In-Reply-To: <20100701113853.cn7e82bwso48oc0s@mail.elegosoft.com> References: , <20100701113853.cn7e82bwso48oc0s@mail.elegosoft.com> Message-ID: Understood. They do a lot of the same but merging requires both a decent top-down understanding of the semantics to plan ahead slightly and then a close bottom-up line by line read to merge and preserve meaning. (I seem to be speaking like an MBA this evening. Don't worry. :) ) I don't have the energy for it at the moment. I am extending this area though, the stuff for recording and later comparing assembly output. Background: Fixing more configure -enable-checking seems to regress code /slightly/, in bit insert/extract. So I haven't commited said fix. So I'm going to try the bitfield refs again (that Tony had done). That might both fix and improve the code. Once they are merged the result can probably keep the name compare_file. Thanks for the overview. I'll try to look into this eventually and I'll try not to look into it too soon, before other things that are probably more useful (and more interesting and fun). Btw, there's stuff called "jux" in the code here. Is it rude to request sticking to English? Thanks. ?- Jay ---------------------------------------- > Date: Thu, 1 Jul 2010 11:38:53 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] m3tests/cmp_fie vs. compare_file > > Quoting Jay K : > > > > > I find it confusing that m3-sys/m3tests/src/m3makefile contains both > > cmp_file and compare_file (unless one was a thin wrapper over the > > other, not the case) > > Olaf you added cmp_file in > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3tests/src/m3makefile.diff?r1=1.3;r2=1.4. > > > > Presumably they can be merged into one function? > > compare_file() writes output and doesn't return anything meaningful > (it's a procedure), while cmp_file is a boolean state function that > doesn't write anything to stdout. > > The first could be based on the second. > > Of course you can find a common signature, but then you'll have to > change all occurences and add a use case parameter, which isn't nice, > too. > > Perhaps you can suggest better names? > > Please do not change the semantics (i.e. the use of @cmp, for example) > though, as that might break the regression tests. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Thu Jul 1 16:45:18 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 1 Jul 2010 14:45:18 +0000 Subject: [M3devel] add/subtract in Quake Message-ID: Folks might find this amusing or useful. I actually think I'm going to use it, just for the numbers 0-64.It implements addition and subtraction for a fixed range, here 0-9999Global variables are only used for initialization.Thereafter, just global constants (no enforcement of that, but I think it could be done by having initialization return them). Approach is that adding 1 to a single digit can be done with a small map.Adding 1 to multiple digits can be done using multiple variables and checking for "wraparound" to 0 (the table maps 9 to 0).You count up to 9999, filling in an Add1 and Sub1 hash table as you go up. I don't think quake has an appropriate looping mechanism, so counting up to 9999 is done recursively.Then Add and Sub are implemented recursively like Add1{Add(a, Sub1(b)}. local Add1 = { }local Sub1 = { } local counter0 = 0local counter1 = 0local counter2 = 0local counter3 = 0 local proc Increment() is local inc = { 0:1,1:2,2:3,3:4,4:5, 5:6,6:7,7:8,8:9,9:0 } counter0 = inc{counter0} if equal(counter0, 0) counter1 = inc{counter1} if equal(counter1, 0) counter2 = inc{counter2} if equal(counter2, 0) counter3 = inc{counter3} end end end local c = "" foreach d in [counter3, counter2, counter1, counter0] if not equal(d, 0) or not equal(c, "") c = c & d end end return cend proc InitMath_F1(a, b) is if equal(a, "9999") return end Add1{a} = b Sub1{b} = a InitMath_F1(b, Increment())end proc InitMath() is counter0 = 0 counter1 = 0 counter2 = 0 counter3 = 0 InitMath_F1(0, Increment())end proc Add(a, b) is if equal(a, 0) return b end if equal(b, 0) return a end if equal(a, 1) return Add1{b} end if equal(b, 1) return Add1{a} end return Add1{Add(a, Sub1{b})}end proc Sub(a, b) is if equal(a, 0) return b end if equal(b, 0) return a end if equal(a, 1) return Sub1{b} end if equal(b, 1) return Sub1{a} end return Sub1{Sub(a, Sub1{b})}end InitMath()write("99 - 40 is " & Sub(99, 40), CR)write("6 - 4 is " & Sub(6, 4), CR)write("3 + 2 is " & Add(2, 3), CR) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Thu Jul 1 22:33:13 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 01 Jul 2010 15:33:13 -0500 Subject: [M3devel] Another CVS question: duplicate local copies Message-ID: <4C2CFB89.4000406@lcwb.coop> I understand a release tag is "sticky", meaning once I specify it in a CVS command, the value I gave becomes internal state and will continue to be used in subsequent commands, until I do something explicitly to change it. Where is this state recorded? I particular, is it somewhere in the repository, or on my local disk? The motivation is this: I am now connected through a satellite internet service that has high latency, slow speed, and worst, a restrictive quota on bit volumes. I can scarcely afford the data transfer of frequent switches between the head and release branches. I want to keep a local copy of each. Can I do this? I made a complete copy of my local distribution, currently of the head. In the copy, I did "cvs -z9 -q update -r release_branch_cm3_5_8". So if I do an update in the future from inside the original directory, will I get head versions, and if I do it in my copy that is now the release branch, will I get updates to the release branch? Or do I have to specify tags carefully every time, no matter where I am? Or is this feasible at all? From wagner at elegosoft.com Thu Jul 1 22:51:37 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 01 Jul 2010 22:51:37 +0200 Subject: [M3devel] Another CVS question: duplicate local copies In-Reply-To: <4C2CFB89.4000406@lcwb.coop> References: <4C2CFB89.4000406@lcwb.coop> Message-ID: <20100701225137.lrzkgtfmswgcokcs@mail.elegosoft.com> Quoting "Rodney M. Bates" : > I understand a release tag is "sticky", meaning once I specify it in a > CVS command, the value I gave becomes internal state and will continue > to be used in subsequent commands, until I do something explicitly to > change it. Where is this state recorded? I particular, is it somewhere > in the repository, or on my local disk? It's in the CVS/Entries files; there's a column for sticky tags. It looks like this: % cat m3-libs/binIO/src/CVS/Entries /BinIO.i3/1.1.1.1/Sat Jan 5 16:32:08 2002//Trelease_branch_cm3_5_8 /BinIO.m3/1.1.1.1/Sat Jan 5 16:32:09 2002//Trelease_branch_cm3_5_8 /FastBinIO.i3/1.1.1.1/Sat Jan 5 16:32:09 2002//Trelease_branch_cm3_5_8 /FastBinIO.m3/1.1.1.1/Sat Jan 5 16:32:10 2002//Trelease_branch_cm3_5_8 /m3makefile/1.1.1.1/Sat Mar 27 11:42:57 2004//Trelease_branch_cm3_5_8 /m3overrides/1.2/Sat Jul 25 09:33:14 2009//Trelease_branch_cm3_5_8 D The repository does not know about any workspaces. > The motivation is this: I am now connected through a satellite internet > service that has high latency, slow speed, and worst, a restrictive > quota on bit volumes. I can scarcely afford the data transfer of > frequent switches between the head and release branches. I want to > keep a local copy of each. Can I do this? You can have as many CVS workspaces with different branches and versions as you like. > I made a complete copy of my local distribution, currently of the > head. In the copy, I did "cvs -z9 -q update -r release_branch_cm3_5_8". > So if I do an update in the future from inside the original directory, > will I get head versions, and if I do it in my copy that is now the > release branch, will I get updates to the release branch? Or do I > have to specify tags carefully every time, no matter where I am? > Or is this feasible at all? That should be no problem with CVS. Just be careful not to mess up the CVS directories manually. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Fri Jul 2 09:34:19 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 02 Jul 2010 09:34:19 +0200 Subject: [M3devel] add/subtract in Quake In-Reply-To: References: Message-ID: <20100702093419.0hvbuzj2ysocsk4s@mail.elegosoft.com> Shouldn't we rather define some standard quake functions and implement them in M3, like add, substract, multiply, div, mod? Probably working on TEXT of course... or even introduce a new quake type for integers? I haven't really thought about that, but I've missed integer arithmetics several times in the past, too. Olaf Quoting Jay K : > Folks might find this amusing or useful. I actually think I'm > going to use it, just for the numbers 0-64.It implements addition > and subtraction for a fixed range, here 0-9999Global variables are > only used for initialization.Thereafter, just global constants (no > enforcement of that, but I think it could be done by having > initialization return them). > Approach is that adding 1 to a single digit can be done with a small > map.Adding 1 to multiple digits can be done using multiple > variables and checking for "wraparound" to 0 (the table maps 9 to > 0).You count up to 9999, filling in an Add1 and Sub1 hash table as > you go up. I don't think quake has an appropriate looping > mechanism, so counting up to 9999 is done recursively.Then Add and > Sub are implemented recursively like Add1{Add(a, Sub1(b)}. > > local Add1 = { }local Sub1 = { } > > local counter0 = 0local counter1 = 0local counter2 = 0local counter3 = 0 > > local proc Increment() is local inc = { 0:1,1:2,2:3,3:4,4:5, > 5:6,6:7,7:8,8:9,9:0 } counter0 = inc{counter0} if > equal(counter0, 0) counter1 = inc{counter1} if equal(counter1, > 0) counter2 = inc{counter2} if equal(counter2, 0) > counter3 = inc{counter3} end end end local c = "" foreach > d in [counter3, counter2, counter1, counter0] if not equal(d, 0) > or not equal(c, "") c = c & d end end return cend > > proc InitMath_F1(a, b) is if equal(a, "9999") return end > Add1{a} = b Sub1{b} = a InitMath_F1(b, Increment())end > proc InitMath() is counter0 = 0 counter1 = 0 counter2 = 0 > counter3 = 0 InitMath_F1(0, Increment())end > > proc Add(a, b) is if equal(a, 0) return b end if equal(b, 0) > return a end if equal(a, 1) return Add1{b} end if equal(b, 1) > return Add1{a} end return Add1{Add(a, Sub1{b})}end > > proc Sub(a, b) is if equal(a, 0) return b end if equal(b, 0) > return a end if equal(a, 1) return Sub1{b} end if equal(b, 1) > return Sub1{a} end return Sub1{Sub(a, Sub1{b})}end > > InitMath()write("99 - 40 is " & Sub(99, 40), CR)write("6 - 4 is " & > Sub(6, 4), CR)write("3 + 2 is " & Add(2, 3), CR) -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Jul 2 10:10:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 2 Jul 2010 08:10:10 +0000 Subject: [M3devel] ppc_linux hanging Message-ID: Alas, PPC_LINUX is very prone to hang on head. ?e.g. compiling m3front. ?It doesn't hang with @M3nogc. ?The stack at the time just shows junk, no symbols at all. ? and info threads shows nothing, maybe I mistyped it. I'll try to figure it out. The biggest recent change I think is removing volatile so I'll start by trying with that put back. Also I use Darwin more lately, which has its own thread suspension code. Could be something broke the others. Later, ?- Jay From jay.krell at cornell.edu Fri Jul 2 10:20:26 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 2 Jul 2010 08:20:26 +0000 Subject: [M3devel] add/subtract in Quake In-Reply-To: <20100702093419.0hvbuzj2ysocsk4s@mail.elegosoft.com> References: , <20100702093419.0hvbuzj2ysocsk4s@mail.elegosoft.com> Message-ID: If someone can specify and/or implement, yes. In the meantime I'll proceed without. It appears many newlines were lost from my email rendering it unreadable. Arg. Then we maybe need for loops. And comparison and bitwise operation and shifting -- consider the case of combinatorial test generation...you nested for loop various integers from 0 to 1 and then shift them each a different amount, oring them together to get a test number... Or you loop from 0 to 2^n and you check for a bit set to decide which variation of that variable to generate. Or maybe we need a different scripting language. Python is very good. A friend is telling me about Lua. ? Need to check about portability to OpenBSD/mips64..never quite got Python working there, but close.. :) Or maybe we should use makefile.m3 that gets compiled on-demand or something. ? Really. Maybe. makefile.m3 around m3-sys would have to limit itself to working with old compiler/m3core/libm3. You know.."compiled languages" ought to compete better with "scripting languages".. the distinction belies any technical classification, to me. What is a "scripting language" vs. others? They are often interprted. But not always. Quake is acually compiled in a way. Often dynamically typed. But not always. Often lack tools for turning them into "executables". But not always. Often are slow. But not always. Usually are "safe". Always? ? But so sometimes are others: Modula-3, C#, Java, etc. ?- Jay ---------------------------------------- > Date: Fri, 2 Jul 2010 09:34:19 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] add/subtract in Quake > > Shouldn't we rather define some standard quake functions and implement > them in M3, like add, substract, multiply, div, mod? > Probably working on TEXT of course... or even introduce a new > quake type for integers? > > I haven't really thought about that, but I've missed integer arithmetics > several times in the past, too. > > Olaf > > Quoting Jay K : > > > Folks might find this amusing or useful. I actually think I'm > > going to use it, just for the numbers 0-64.It implements addition > > and subtraction for a fixed range, here 0-9999Global variables are > > only used for initialization.Thereafter, just global constants (no > > enforcement of that, but I think it could be done by having > > initialization return them). > > Approach is that adding 1 to a single digit can be done with a small > > map.Adding 1 to multiple digits can be done using multiple > > variables and checking for "wraparound" to 0 (the table maps 9 to > > 0).You count up to 9999, filling in an Add1 and Sub1 hash table as > > you go up. I don't think quake has an appropriate looping > > mechanism, so counting up to 9999 is done recursively.Then Add and > > Sub are implemented recursively like Add1{Add(a, Sub1(b)}. > > > > local Add1 = { }local Sub1 = { } > > > > local counter0 = 0local counter1 = 0local counter2 = 0local counter3 = 0 > > > > local proc Increment() is local inc = { 0:1,1:2,2:3,3:4,4:5, > > 5:6,6:7,7:8,8:9,9:0 } counter0 = inc{counter0} if > > equal(counter0, 0) counter1 = inc{counter1} if equal(counter1, > > 0) counter2 = inc{counter2} if equal(counter2, 0) > > counter3 = inc{counter3} end end end local c = "" foreach > > d in [counter3, counter2, counter1, counter0] if not equal(d, 0) > > or not equal(c, "") c = c & d end end return cend > > > > proc InitMath_F1(a, b) is if equal(a, "9999") return end > > Add1{a} = b Sub1{b} = a InitMath_F1(b, Increment())end > > proc InitMath() is counter0 = 0 counter1 = 0 counter2 = 0 > > counter3 = 0 InitMath_F1(0, Increment())end > > > > proc Add(a, b) is if equal(a, 0) return b end if equal(b, 0) > > return a end if equal(a, 1) return Add1{b} end if equal(b, 1) > > return Add1{a} end return Add1{Add(a, Sub1{b})}end > > > > proc Sub(a, b) is if equal(a, 0) return b end if equal(b, 0) > > return a end if equal(a, 1) return Sub1{b} end if equal(b, 1) > > return Sub1{a} end return Sub1{Sub(a, Sub1{b})}end > > > > InitMath()write("99 - 40 is " & Sub(99, 40), CR)write("6 - 4 is " & > > Sub(6, 4), CR)write("3 + 2 is " & Add(2, 3), CR) > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Fri Jul 2 12:35:09 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 2 Jul 2010 10:35:09 +0000 Subject: [M3devel] object oriented programming in Quake Message-ID: next in the series of advanced programming in quake... Perl/Python-esque "objects" (aka hash tables) ?- Quake doesn't have lexical scoping. Or therefore closures. ? ??? So you have to pass the this pointer manually. ? - Quake does allow naming a procedure to act like taking its address; it can be stored and called later. ?????? This is really the only thing that helps the situation. ?- I wasn't able to write "void member functions" aka "methods that don't return anything", thus the "a = " ?- There is no private/protected. ?- Similar reduction in making typos static errors: ie: a{"foo"} = 1 vs. a{"food"} = 1, whichever you meant, no matter, ?? you get what you typed, no errors. ? - No "inheritance" demonstrated but er you could probably say there is JavaScript-esque prototyping -- just assign from another object (hash table) proc NewCounter() is ? local proc inc(this) is ??? this{"c"} = Add(this{"c"}, 1) ??? return this ? end ? local proc get(this) is ??? return this{"c"} ? end ? local this = { } ? this{"c"} = 0 ? this{"inc"} = inc ? this{"get"} = get ? return this end local c1 = NewCounter() local c2 = NewCounter() write("c1 is " & c1{"get"}(c1), CR) a = c1{"inc"}(c1) write("c1 is " & c1{"get"}(c1), CR) a = c1{"inc"}(c1) a = c1{"inc"}(c1) write("c1 is " & c1{"get"}(c1), CR) write("c2 is " & c2{"get"}(c2), CR) a = c2{"inc"}(c2) a = c2{"inc"}(c2) a = c2{"inc"}(c2) write("c2 is " & c2{"get"}(c2), CR) ?- Jay From jay.krell at cornell.edu Fri Jul 2 13:04:54 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 2 Jul 2010 11:04:54 +0000 Subject: [M3devel] looping over range of integers in quake Message-ID: Given the lack of lexical scoping and closures, the second form is preferred. ? Actually there is lexical scoping it seems, but not closures. Maybe more on that later. proc For(start, endd, body) is ? if equal(start, endd & "") ??? return ? end ? body(start) ? For(Add(start, 1), endd, body) end For(0, 10, write) write(CR) proc ToString(a) is ? return a & "" end proc Range(start, endd) is % I thought local a good idea here but no. ? proc Helper(result, start, endd) is ??? if equal(start, endd) ????? return result ??? end ??? result += start ??? return Helper(result, Add(start, 1), endd) ? end ? return Helper([ ], ToString(start), ToString(endd)) end foreach i in Range(0, 10) ? write(i, CR) end From jay.krell at cornell.edu Sat Jul 3 12:37:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 3 Jul 2010 10:37:36 +0000 Subject: [M3devel] ppc_linux hanging In-Reply-To: References: Message-ID: Alas, good news, bad news, restoring volatile on every load/store seems to fix this. I wasn't even optimizing. Tony any ideas? I386_LINUX is ok. AMD64_DARWIN is ok. SOLgnu is ok, but that doesn't count. I left volatile on there, was worried for some reason about interaction with stack walker, I forget. So far the debugger is being very uncooperative, can't set any breakpoints..it works for C. Aha.. gcc -gstabs+ -fPIC -pie 2.c (gdb) break main Breakpoint 1 at 0x658: file 2.c, line 3. (gdb) run Starting program: /home/jay/a.out Warning: Cannot insert breakpoint 1. Error accessing memory address 0x658: Input/output error. (gdb) q The program is running.? Exit anyway? (y or n) y jay at plin:~$ gcc -gstabs+ -fPIC 2.c jay at plin:~$ gdb ./a.out GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.? Type "show copying" and "show warranty" for details. This GDB was configured as "powerpc-linux-gnu"... (gdb) break main Breakpoint 1 at 0x10000448: file 2.c, line 3. (gdb) run Starting program: /home/jay/a.out Breakpoint 1, main () at 2.c:3 3??? } So lame.. ? - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: ppc_linux hanging > Date: Fri, 2 Jul 2010 08:10:10 +0000 > > > Alas, PPC_LINUX is very prone to hang on head. > e.g. compiling m3front. > It doesn't hang with @M3nogc. > The stack at the time just shows junk, no symbols at all. > and info threads shows nothing, maybe I mistyped it. > > > I'll try to figure it out. > The biggest recent change I think is removing volatile so I'll start > by trying with that put back. > > > Also I use Darwin more lately, which has its own thread suspension code. > Could be something broke the others. > > > Later, > - Jay > > From jay.krell at cornell.edu Sat Jul 3 13:21:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 3 Jul 2010 11:21:44 +0000 Subject: [M3devel] quake continue Message-ID: It'd be very nice if quake had "continue". I find myself having to indent loops further and further and further when continue is really want I want. You can fake it by moving code into a function and using return but... ?- Jay From jay.krell at cornell.edu Sat Jul 3 17:13:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 3 Jul 2010 15:13:20 +0000 Subject: [M3devel] Could not find a legal alignment for the packed type? Message-ID: "../I386_LINUX/bitfield.m3", line 16078: Could not find a legal alignment for the packed type. <*NOWARN*>TYPE BitField_offset63_count1 = RECORD ?offset:BITS 63 FOR? [0L .. Long.RightShift(Long.Not(0L), 1)]; ?value:BITS 1 FOR? [0L .. Long.RightShift(Long.Not(0L), 63)]; END; ? Does that make sense? Obviously? the record contains one LONGINT broken up into a 1 bit field and a 63 bit field. I'll try removing the "BITS FOR". ? - Jay From rodney_bates at lcwb.coop Sat Jul 3 18:09:27 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 03 Jul 2010 11:09:27 -0500 Subject: [M3devel] Another CVS question: duplicate local copies In-Reply-To: <20100701225137.lrzkgtfmswgcokcs@mail.elegosoft.com> References: <4C2CFB89.4000406@lcwb.coop> <20100701225137.lrzkgtfmswgcokcs@mail.elegosoft.com> Message-ID: <4C2F60B7.3070903@lcwb.coop> OK, thanks. I had since noticed the tags in .../CVS/Entries files. It seems to be working, after I remembered to add -dAP to my cvs update command. Olaf Wagner wrote: > Quoting "Rodney M. Bates" : > >> I understand a release tag is "sticky", meaning once I specify it in a >> CVS command, the value I gave becomes internal state and will continue >> to be used in subsequent commands, until I do something explicitly to >> change it. Where is this state recorded? I particular, is it somewhere >> in the repository, or on my local disk? > > It's in the CVS/Entries files; there's a column for sticky tags. > It looks like this: > > % cat m3-libs/binIO/src/CVS/Entries > /BinIO.i3/1.1.1.1/Sat Jan 5 16:32:08 2002//Trelease_branch_cm3_5_8 > /BinIO.m3/1.1.1.1/Sat Jan 5 16:32:09 2002//Trelease_branch_cm3_5_8 > /FastBinIO.i3/1.1.1.1/Sat Jan 5 16:32:09 2002//Trelease_branch_cm3_5_8 > /FastBinIO.m3/1.1.1.1/Sat Jan 5 16:32:10 2002//Trelease_branch_cm3_5_8 > /m3makefile/1.1.1.1/Sat Mar 27 11:42:57 2004//Trelease_branch_cm3_5_8 > /m3overrides/1.2/Sat Jul 25 09:33:14 2009//Trelease_branch_cm3_5_8 > D > > The repository does not know about any workspaces. > >> The motivation is this: I am now connected through a satellite internet >> service that has high latency, slow speed, and worst, a restrictive >> quota on bit volumes. I can scarcely afford the data transfer of >> frequent switches between the head and release branches. I want to >> keep a local copy of each. Can I do this? > > You can have as many CVS workspaces with different branches and > versions as you like. > >> I made a complete copy of my local distribution, currently of the >> head. In the copy, I did "cvs -z9 -q update -r release_branch_cm3_5_8". >> So if I do an update in the future from inside the original directory, >> will I get head versions, and if I do it in my copy that is now the >> release branch, will I get updates to the release branch? Or do I >> have to specify tags carefully every time, no matter where I am? >> Or is this feasible at all? > > That should be no problem with CVS. > Just be careful not to mess up the CVS directories manually. > > Olaf From jay.krell at cornell.edu Sun Jul 4 02:03:05 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 00:03:05 +0000 Subject: [M3devel] "exact codegen" testing Message-ID: m3-sys/m3tests now has infrastructure for "exact codegen" testing. An interesting thing I just realized, is that it is, well, it is trivial. And it is applicable to any test. If the "expected" directory exists, then it gets compared. ? Now, probably in such cases you want to "trim" the code some, such as by turning off or reducing symbols. This can be used for cross builds -- since assembly is what cross builds produce on the host, and assembly is what this looks at. Probably then what is needed is a script to loop through all architectures and update whichever tests have checked in assembly. Or a two step, produce them all, present diff to human, update them all. There is a temporary problem right now that I made the "c" tests run. They include one with an infinite loop. I'll undo that now. "p" tests are now subtely redefined. Previously: Programs whose output is interesting or for which running them is interesting. Now: "code" tests that are safe to run (ie. they need not do anything), i.e should always be built and run, even if running them doesn't do anything interesting, building them does. I'll move c135 to be a "p" test. c135 should probably be expanded further. Specifically with the goal of covering every single M3CG_Op and every boolean parameter combination thereof. ? i.e. extract with sign extend both true and false, though for example extract_n(sign_extend=true) is never ? used by the frontend. Iterating through integer values can't be done for all values, but booleans can be. There's still a fair amount missing. Though other tests and building the system itself should provide much/all of it. ?- Jay From hosking at cs.purdue.edu Sun Jul 4 02:29:00 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 3 Jul 2010 20:29:00 -0400 Subject: [M3devel] ppc_linux hanging In-Reply-To: References: Message-ID: <9B486681-F277-414E-8A67-F2A63E2BC4CD@cs.purdue.edu> Is there something about the memory model on PPC? It manifests as a hang, correct? On 3 Jul 2010, at 06:37, Jay K wrote: > > Alas, good news, bad news, restoring volatile on every load/store seems to fix this. > I wasn't even optimizing. > > Tony any ideas? > > I386_LINUX is ok. AMD64_DARWIN is ok. > SOLgnu is ok, but that doesn't count. I left volatile on there, was worried for some reason about interaction with stack walker, I forget. > > So far the debugger is being very uncooperative, can't set any breakpoints..it works for C. > > Aha.. > > gcc -gstabs+ -fPIC -pie 2.c > (gdb) break main > Breakpoint 1 at 0x658: file 2.c, line 3. > (gdb) run > Starting program: /home/jay/a.out > Warning: > Cannot insert breakpoint 1. > Error accessing memory address 0x658: Input/output error. > > > (gdb) q > The program is running. Exit anyway? (y or n) y > jay at plin:~$ gcc -gstabs+ -fPIC 2.c > jay at plin:~$ gdb ./a.out > GNU gdb 6.8-debian > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "powerpc-linux-gnu"... > (gdb) break main > Breakpoint 1 at 0x10000448: file 2.c, line 3. > (gdb) run > Starting program: /home/jay/a.out > > Breakpoint 1, main () at 2.c:3 > 3 } > > > So lame.. > > - Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Subject: ppc_linux hanging >> Date: Fri, 2 Jul 2010 08:10:10 +0000 >> >> >> Alas, PPC_LINUX is very prone to hang on head. >> e.g. compiling m3front. >> It doesn't hang with @M3nogc. >> The stack at the time just shows junk, no symbols at all. >> and info threads shows nothing, maybe I mistyped it. >> >> >> I'll try to figure it out. >> The biggest recent change I think is removing volatile so I'll start >> by trying with that put back. >> >> >> Also I use Darwin more lately, which has its own thread suspension code. >> Could be something broke the others. >> >> >> Later, >> - Jay >> >> > From jay.krell at cornell.edu Sun Jul 4 02:38:16 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 00:38:16 +0000 Subject: [M3devel] ppc_linux hanging In-Reply-To: <9B486681-F277-414E-8A67-F2A63E2BC4CD@cs.purdue.edu> References: , , <9B486681-F277-414E-8A67-F2A63E2BC4CD@cs.purdue.edu> Message-ID: I'm afraid I just don't know. Now I'm seeing: Fatal Error: bad version stamps: TextClass.i3 version stamp mismatch: M3_BUILTIN.TEXT ? <61b2d19ae7136110> => TextClass.i3 ? => M3_BUILTIN.i3? ?*** execution of [, From: hosking at cs.purdue.edu > Date: Sat, 3 Jul 2010 20:29:00 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] ppc_linux hanging > > Is there something about the memory model on PPC? It manifests as a hang, correct? > > On 3 Jul 2010, at 06:37, Jay K wrote: > > > > > Alas, good news, bad news, restoring volatile on every load/store seems to fix this. > > I wasn't even optimizing. > > > > Tony any ideas? > > > > I386_LINUX is ok. AMD64_DARWIN is ok. > > SOLgnu is ok, but that doesn't count. I left volatile on there, was worried for some reason about interaction with stack walker, I forget. > > > > So far the debugger is being very uncooperative, can't set any breakpoints..it works for C. > > > > Aha.. > > > > gcc -gstabs+ -fPIC -pie 2.c > > (gdb) break main > > Breakpoint 1 at 0x658: file 2.c, line 3. > > (gdb) run > > Starting program: /home/jay/a.out > > Warning: > > Cannot insert breakpoint 1. > > Error accessing memory address 0x658: Input/output error. > > > > > > (gdb) q > > The program is running. Exit anyway? (y or n) y > > jay at plin:~$ gcc -gstabs+ -fPIC 2.c > > jay at plin:~$ gdb ./a.out > > GNU gdb 6.8-debian > > Copyright (C) 2008 Free Software Foundation, Inc. > > License GPLv3+: GNU GPL version 3 or later > > This is free software: you are free to change and redistribute it. > > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > > and "show warranty" for details. > > This GDB was configured as "powerpc-linux-gnu"... > > (gdb) break main > > Breakpoint 1 at 0x10000448: file 2.c, line 3. > > (gdb) run > > Starting program: /home/jay/a.out > > > > Breakpoint 1, main () at 2.c:3 > > 3 } > > > > > > So lame.. > > > > - Jay > > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: m3devel at elegosoft.com > >> Subject: ppc_linux hanging > >> Date: Fri, 2 Jul 2010 08:10:10 +0000 > >> > >> > >> Alas, PPC_LINUX is very prone to hang on head. > >> e.g. compiling m3front. > >> It doesn't hang with @M3nogc. > >> The stack at the time just shows junk, no symbols at all. > >> and info threads shows nothing, maybe I mistyped it. > >> > >> > >> I'll try to figure it out. > >> The biggest recent change I think is removing volatile so I'll start > >> by trying with that put back. > >> > >> > >> Also I use Darwin more lately, which has its own thread suspension code. > >> Could be something broke the others. > >> > >> > >> Later, > >> - Jay > >> > >> > > > From jay.krell at cornell.edu Sun Jul 4 03:16:23 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 01:16:23 +0000 Subject: [M3devel] aliases/optimization In-Reply-To: <00538FB2-00DA-4C0E-82F3-D151B9A85A0E@cs.purdue.edu> References: <20100703105709.DBD2E2474003@birch.elegosoft.com>, , , , , , <00538FB2-00DA-4C0E-82F3-D151B9A85A0E@cs.purdue.edu> Message-ID: aha you just reminded me of something that we need to remember a bit and apply soon. Depending on compilers, optimization, etc. gcc doesn't like: float f; int i; i = *(int*)&f; though I think that's perfectly reasonable..anyway the equivalent form of code that gcc is explicitly ok with is: float f; int i; union { ? float f; ? int i; } u; u.f = f; i = u.i; So, point being, we should try changing LOOPHOLE to compile like that. You know, cons up the union type on-demand, make a local, etc. If we are lucky, that might solve some of our problems. Not the PPC ones. But that I left some systematic use of volatile in, like for all floating point, or something. And maybe it'll fix some of the optimizations I disabled. ? It'd still leave "unit at a time" broken. ? Possibly in tree-nested we can remove any notion of the functions being nested and ?? maybe that'll help.. Search the for "gcc type punning" ?=> wikipedia ?=> link at the bottom http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Optimize-Options.html#index-fstrict_002daliasing-542 There is a subtlty there though..we'd have use member_ref on the union. They also give some pointer to what to do "for real". I can follow up, later. Disabling unit at a time is also lame. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Sat, 3 Jul 2010 20:50:11 -0400 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > I added it a long time back only because I saw failures with optimisation turned on. Something to do with the alias analysis (and lack of proper type information) as far as I recall. > > > On 3 Jul 2010, at 20:44, Jay K wrote: > > > > > Tony, just to be clear..you/I are disturbed by volatile, but it has also, I believe, like always been there. > > It has been gone only very briefly, and its non-use is probably limited for other reasons (how many people are > > using it, on how many platforms?). > > > > > > - Jay > > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: hosking at cs.purdue.edu; jkrell at elego.de > >> CC: m3commit at elegosoft.com > >> Subject: RE: [M3commit] CVS Update: cm3 > >> Date: Sun, 4 Jul 2010 00:42:20 +0000 > >> > >> > >> Not a multiprocessor. > >> Still interested in selective volatile? > >> > >> > >> This all bothers me too. > >> I don't want volatile. It makes the optimized code terrible. > >> But I don't want to debug any problem from removing it, beyond compilation failure. > >> > >> > >> I can try a few things. > >> This is all wierd. I swear I saw it hang several times. > >> I swear I'm trying to to change "too many" variables at a time. Yes, I know, 2 is too many. > >> > >> > >> Once I started getting version stamp mismatch, I resorted to using a cross built cm3. > >> Out of necessity sort of, but that causes more flucuation of variables. > >> > >> Let me try again with volatile and see if it is solid. > >> Then I'll try with only volatile stores. > >> > >> I've been trying optimized and unoptimized, and not kept good track of which when. > >> > >> > >> - Jay > >> > >> > >> ---------------------------------------- > >>> From: hosking at cs.purdue.edu > >>> Date: Sat, 3 Jul 2010 20:36:20 -0400 > >>> To: jkrell at elego.de > >>> CC: m3commit at elegosoft.com > >>> Subject: Re: [M3commit] CVS Update: cm3 > >>> > >>> I am very disturbed that volatile is needed here. Can we selectively turn it on for thread-critical files like ThreadPThread and see if it fixes the problem. I wonder if the double-checked locking is broken for PPC memory model. Is this on a multi-processor? > >>> > >>> On 3 Jul 2010, at 12:57, Jay Krell wrote: > >>> > >>>> CVSROOT: /usr/cvs > >>>> Changes by: jkrell at birch. 10/07/03 12:57:09 > >>>> > >>>> Modified files: > >>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > >>>> > >>>> Log message: > >>>> restore volatile for powerpc and powerpc64 platforms > >>>> This seems to fix PPC_LINUX hanging. > >>>> This needs further debugging, but I'm not eager. > >>>> This will also affect PPC_DARWIN, PPC64_DARWIN, PPC32_OPENBSD, > >>>> PPC32_NETBSD, PPC32_FREEBSD, etc., but these platforms are little used or > >>>> nonexistant. > >>>> > >>>> Having volatile like has been the very long standing situation though. > >>>> The result is that the optimizer does basically nothing. > >>> > >> > > > From jay.krell at cornell.edu Sun Jul 4 10:14:47 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 08:14:47 +0000 Subject: [M3devel] aliases/optimization In-Reply-To: References: <20100703105709.DBD2E2474003@birch.elegosoft.com>, , , , , , <00538FB2-00DA-4C0E-82F3-D151B9A85A0E@cs.purdue.edu>, Message-ID: It appears this behavior is part of the C frontend, not the backend. It appears..that maybe..we should provide a langhook get_alias_set that always returns 0. The default is always -1. Not clear to me. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: aliases/optimization > Date: Sun, 4 Jul 2010 01:16:23 +0000 > > > aha you just reminded me of something that we need to remember a bit and apply soon. > > > Depending on compilers, optimization, etc. gcc doesn't like: > > > float f; > int i; > i = *(int*)&f; > > though I think that's perfectly reasonable..anyway the equivalent form of code that gcc is explicitly ok with is: > > float f; > > int i; > union { > float f; > int i; > } u; > u.f = f; > i = u.i; > > So, point being, we should try changing LOOPHOLE to compile like that. > You know, cons up the union type on-demand, make a local, etc. > > If we are lucky, that might solve some of our problems. > Not the PPC ones. > But that I left some systematic use of volatile in, like for all floating point, or something. > And maybe it'll fix some of the optimizations I disabled. > It'd still leave "unit at a time" broken. > Possibly in tree-nested we can remove any notion of the functions being nested and > maybe that'll help.. > > Search the for "gcc type punning" > => wikipedia > => link at the bottom > > http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Optimize-Options.html#index-fstrict_002daliasing-542 > > There is a subtlty there though..we'd have use member_ref on the union. > They also give some pointer to what to do "for real". I can follow up, later. > > > Disabling unit at a time is also lame. > > > - Jay > > ---------------------------------------- > > From: hosking at cs.purdue.edu > > Date: Sat, 3 Jul 2010 20:50:11 -0400 > > To: jay.krell at cornell.edu > > CC: m3commit at elegosoft.com > > Subject: Re: [M3commit] CVS Update: cm3 > > > > I added it a long time back only because I saw failures with optimisation turned on. Something to do with the alias analysis (and lack of proper type information) as far as I recall. > > > > > > On 3 Jul 2010, at 20:44, Jay K wrote: > > > > > > > > Tony, just to be clear..you/I are disturbed by volatile, but it has also, I believe, like always been there. > > > It has been gone only very briefly, and its non-use is probably limited for other reasons (how many people are > > > using it, on how many platforms?). > > > > > > > > > - Jay > > > > > > ---------------------------------------- > > >> From: jay.krell at cornell.edu > > >> To: hosking at cs.purdue.edu; jkrell at elego.de > > >> CC: m3commit at elegosoft.com > > >> Subject: RE: [M3commit] CVS Update: cm3 > > >> Date: Sun, 4 Jul 2010 00:42:20 +0000 > > >> > > >> > > >> Not a multiprocessor. > > >> Still interested in selective volatile? > > >> > > >> > > >> This all bothers me too. > > >> I don't want volatile. It makes the optimized code terrible. > > >> But I don't want to debug any problem from removing it, beyond compilation failure. > > >> > > >> > > >> I can try a few things. > > >> This is all wierd. I swear I saw it hang several times. > > >> I swear I'm trying to to change "too many" variables at a time. Yes, I know, 2 is too many. > > >> > > >> > > >> Once I started getting version stamp mismatch, I resorted to using a cross built cm3. > > >> Out of necessity sort of, but that causes more flucuation of variables. > > >> > > >> Let me try again with volatile and see if it is solid. > > >> Then I'll try with only volatile stores. > > >> > > >> I've been trying optimized and unoptimized, and not kept good track of which when. > > >> > > >> > > >> - Jay > > >> > > >> > > >> ---------------------------------------- > > >>> From: hosking at cs.purdue.edu > > >>> Date: Sat, 3 Jul 2010 20:36:20 -0400 > > >>> To: jkrell at elego.de > > >>> CC: m3commit at elegosoft.com > > >>> Subject: Re: [M3commit] CVS Update: cm3 > > >>> > > >>> I am very disturbed that volatile is needed here. Can we selectively turn it on for thread-critical files like ThreadPThread and see if it fixes the problem. I wonder if the double-checked locking is broken for PPC memory model. Is this on a multi-processor? > > >>> > > >>> On 3 Jul 2010, at 12:57, Jay Krell wrote: > > >>> > > >>>> CVSROOT: /usr/cvs > > >>>> Changes by: jkrell at birch. 10/07/03 12:57:09 > > >>>> > > >>>> Modified files: > > >>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > >>>> > > >>>> Log message: > > >>>> restore volatile for powerpc and powerpc64 platforms > > >>>> This seems to fix PPC_LINUX hanging. > > >>>> This needs further debugging, but I'm not eager. > > >>>> This will also affect PPC_DARWIN, PPC64_DARWIN, PPC32_OPENBSD, > > >>>> PPC32_NETBSD, PPC32_FREEBSD, etc., but these platforms are little used or > > >>>> nonexistant. > > >>>> > > >>>> Having volatile like has been the very long standing situation though. > > >>>> The result is that the optimizer does basically nothing. > > >>> > > >> > > > > > > From jay.krell at cornell.edu Sun Jul 4 10:18:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 08:18:31 +0000 Subject: [M3devel] aliases/optimization In-Reply-To: References: <20100703105709.DBD2E2474003@birch.elegosoft.com>, , , , , , <00538FB2-00DA-4C0E-82F3-D151B9A85A0E@cs.purdue.edu>, , Message-ID: er, well, clearly, if we just assign flag_strict_aliasing = false, this stuff all falls away. That I will try. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: aliases/optimization > Date: Sun, 4 Jul 2010 08:14:47 +0000 > > > It appears this behavior is part of the C frontend, not the backend. > It appears..that maybe..we should provide a langhook get_alias_set that always returns 0. > The default is always -1. > Not clear to me. > > - Jay > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: hosking at cs.purdue.edu > > CC: m3devel at elegosoft.com > > Subject: aliases/optimization > > Date: Sun, 4 Jul 2010 01:16:23 +0000 > > > > > > aha you just reminded me of something that we need to remember a bit and apply soon. > > > > > > Depending on compilers, optimization, etc. gcc doesn't like: > > > > > > float f; > > int i; > > i = *(int*)&f; > > > > though I think that's perfectly reasonable..anyway the equivalent form of code that gcc is explicitly ok with is: > > > > float f; > > > > int i; > > union { > > float f; > > int i; > > } u; > > u.f = f; > > i = u.i; > > > > So, point being, we should try changing LOOPHOLE to compile like that. > > You know, cons up the union type on-demand, make a local, etc. > > > > If we are lucky, that might solve some of our problems. > > Not the PPC ones. > > But that I left some systematic use of volatile in, like for all floating point, or something. > > And maybe it'll fix some of the optimizations I disabled. > > It'd still leave "unit at a time" broken. > > Possibly in tree-nested we can remove any notion of the functions being nested and > > maybe that'll help.. > > > > Search the for "gcc type punning" > > => wikipedia > > => link at the bottom > > > > http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Optimize-Options.html#index-fstrict_002daliasing-542 > > > > There is a subtlty there though..we'd have use member_ref on the union. > > They also give some pointer to what to do "for real". I can follow up, later. > > > > > > Disabling unit at a time is also lame. > > > > > > - Jay > > > > ---------------------------------------- > > > From: hosking at cs.purdue.edu > > > Date: Sat, 3 Jul 2010 20:50:11 -0400 > > > To: jay.krell at cornell.edu > > > CC: m3commit at elegosoft.com > > > Subject: Re: [M3commit] CVS Update: cm3 > > > > > > I added it a long time back only because I saw failures with optimisation turned on. Something to do with the alias analysis (and lack of proper type information) as far as I recall. > > > > > > > > > On 3 Jul 2010, at 20:44, Jay K wrote: > > > > > > > > > > > Tony, just to be clear..you/I are disturbed by volatile, but it has also, I believe, like always been there. > > > > It has been gone only very briefly, and its non-use is probably limited for other reasons (how many people are > > > > using it, on how many platforms?). > > > > > > > > > > > > - Jay > > > > > > > > ---------------------------------------- > > > >> From: jay.krell at cornell.edu > > > >> To: hosking at cs.purdue.edu; jkrell at elego.de > > > >> CC: m3commit at elegosoft.com > > > >> Subject: RE: [M3commit] CVS Update: cm3 > > > >> Date: Sun, 4 Jul 2010 00:42:20 +0000 > > > >> > > > >> > > > >> Not a multiprocessor. > > > >> Still interested in selective volatile? > > > >> > > > >> > > > >> This all bothers me too. > > > >> I don't want volatile. It makes the optimized code terrible. > > > >> But I don't want to debug any problem from removing it, beyond compilation failure. > > > >> > > > >> > > > >> I can try a few things. > > > >> This is all wierd. I swear I saw it hang several times. > > > >> I swear I'm trying to to change "too many" variables at a time. Yes, I know, 2 is too many. > > > >> > > > >> > > > >> Once I started getting version stamp mismatch, I resorted to using a cross built cm3. > > > >> Out of necessity sort of, but that causes more flucuation of variables. > > > >> > > > >> Let me try again with volatile and see if it is solid. > > > >> Then I'll try with only volatile stores. > > > >> > > > >> I've been trying optimized and unoptimized, and not kept good track of which when. > > > >> > > > >> > > > >> - Jay > > > >> > > > >> > > > >> ---------------------------------------- > > > >>> From: hosking at cs.purdue.edu > > > >>> Date: Sat, 3 Jul 2010 20:36:20 -0400 > > > >>> To: jkrell at elego.de > > > >>> CC: m3commit at elegosoft.com > > > >>> Subject: Re: [M3commit] CVS Update: cm3 > > > >>> > > > >>> I am very disturbed that volatile is needed here. Can we selectively turn it on for thread-critical files like ThreadPThread and see if it fixes the problem. I wonder if the double-checked locking is broken for PPC memory model. Is this on a multi-processor? > > > >>> > > > >>> On 3 Jul 2010, at 12:57, Jay Krell wrote: > > > >>> > > > >>>> CVSROOT: /usr/cvs > > > >>>> Changes by: jkrell at birch. 10/07/03 12:57:09 > > > >>>> > > > >>>> Modified files: > > > >>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > > >>>> > > > >>>> Log message: > > > >>>> restore volatile for powerpc and powerpc64 platforms > > > >>>> This seems to fix PPC_LINUX hanging. > > > >>>> This needs further debugging, but I'm not eager. > > > >>>> This will also affect PPC_DARWIN, PPC64_DARWIN, PPC32_OPENBSD, > > > >>>> PPC32_NETBSD, PPC32_FREEBSD, etc., but these platforms are little used or > > > >>>> nonexistant. > > > >>>> > > > >>>> Having volatile like has been the very long standing situation though. > > > >>>> The result is that the optimizer does basically nothing. > > > >>> > > > >> > > > > > > > > > > From jay.krell at cornell.edu Sun Jul 4 16:25:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 14:25:04 +0000 Subject: [M3devel] eliminating volatile on floats Message-ID: Through simple trial/error I've tracked a need (the only need?) for floats down: If I set flag_tree_ter = 0, I can compile m3core where I couldn't before, with -O3. I suspect due to: builtins.c: int get_pointer_alignment (tree exp, unsigned int max_align) { ? unsigned int align, inner; ? /* We rely on TER to compute accurate alignment information.? */ ? if (!(optimize && flag_tree_ter)) ??? return 0; Another thing to try is #if 0 out this block of code (it is not in parse,c but "gcc? itself"). That should yield more optimization, but more patch to gcc. I'm inclined to try that. There should be additional options, like getting the alignment correct or such. The code that fails to compile is: /dev2/cm3/m3-libs/m3core/src/float/IEEE/LongFloat.m3 PROCEDURE CopySign (x, y: T): T = ? VAR res := x; ? BEGIN ??? LOOPHOLE (res, Rep.T).sign := LOOPHOLE (y, Rep.T).sign; ??? RETURN res; ? END CopySign; I also tried some other options like adding volatile and/or temporaries on loophole's using t_struct. (To be clear, we only have volatile on float loads, not stores, though I think only stores would be preferable to only loads. "reads are more common than writes", "consider the registers to be a write-through cache") ?- Jay From jay.krell at cornell.edu Sun Jul 4 16:44:26 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 14:44:26 +0000 Subject: [M3devel] other optimizations to think about? Message-ID: Given that we know vaguely what these things are: ??? flag_strict_aliasing = 0; ??? flag_strict_overflow = 0; I'm inclined to turn them off in m3cg/parse.c like how a few others are. They sound kind of scary and not valuable. strict_aliasing I believe is something like where if you have pointers to integers and pointers to floats, writes through one are assumed to not affect reads through the other. ? So the reads can be cached in registers across the writes. Tony has mentioned a need for alias analysis a few times, so.. Or we could just turn it off in unsafe modules or once we see a loophole, perhaps. strict_overflow is something like where the compiler assumes there shall be no signed integer overflow, ?or that signed integer overflow doesn't trap?, and then make optimizations based on that assumption. I don't feel I'm yet willing to give up a possibly systematic that signed oveflow silently overflow. This optimization in fact I believe/thought defeats the obvious ways to check for overflow. int add(int a, int b) { int c = a + b; ?? if (c < a) ????? error_and_exit("overflow"); ? return c; } strict overflow means c can't be less than a, so the check can be optimized away. I wasn't able to reproduce this, granted, with: ?Apple gcc 4.2 ? Debian 5.0 gcc 4.3 ? self-built gcc 4.5 http://gcc.gnu.org/gcc-4.2/changes.html does sound like what I'm saying though. er, wait, what I showed is the unsigned algorithm, duh. void overflow(void); int add(int a, int b) { ? int c = (a + b); ? int asign = (a < 0); ? if (asign == (b < 0) && asign != (c < 0)) ??? overflow(); ? return c; } still, doesn't have a problem. (explanation: overflow occured if inputs have same sign and output differs from their sign overflow cannot occur if inputs have different sign sign(x) equivalent to (x < 0) (maps one to one: negative => 1, positive => 0) ) ?- Jay From jay.krell at cornell.edu Sun Jul 4 16:54:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 14:54:03 +0000 Subject: [M3devel] other optimizations to think about? In-Reply-To: References: Message-ID: proofreading... > strict_overflow is something like where the compiler assumes there shall be no signed integer overflow, ?or that signed integer overflow doesn't trap?, and then make optimizations based on that assumption. > I don't feel I'm yet willing to give up a possibly systematic that signed oveflow silently overflow. DOES trap systematic ASSUMPTION ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: other optimizations to think about? > Date: Sun, 4 Jul 2010 14:44:26 +0000 > > > Given that we know vaguely what these things are: > flag_strict_aliasing = 0; > flag_strict_overflow = 0; > > > I'm inclined to turn them off in m3cg/parse.c like how a few others are. > They sound kind of scary and not valuable. > > > strict_aliasing I believe is something like where if you have pointers to integers and pointers to floats, writes through one are assumed to not affect reads through the other. > So the reads can be cached in registers across the writes. > Tony has mentioned a need for alias analysis a few times, so.. > Or we could just turn it off in unsafe modules or once we see a loophole, perhaps. > > > strict_overflow is something like where the compiler assumes there shall be no signed integer overflow, ?or that signed integer overflow doesn't trap?, and then make optimizations based on that assumption. > I don't feel I'm yet willing to give up a possibly systematic that signed oveflow silently overflow. > This optimization in fact I believe/thought defeats the obvious ways to check for overflow. > int add(int a, int b) > { int c = a + b; > if (c < a) > error_and_exit("overflow"); > return c; > } > > strict overflow means c can't be less than a, so the check can be optimized away. > > I wasn't able to reproduce this, granted, with: > Apple gcc 4.2 > Debian 5.0 gcc 4.3 > self-built gcc 4.5 > > http://gcc.gnu.org/gcc-4.2/changes.html > > does sound like what I'm saying though. > > er, wait, what I showed is the unsigned algorithm, duh. > > void overflow(void); > > int add(int a, int b) > { > int c = (a + b); > int asign = (a < 0); > if (asign == (b < 0) && asign != (c < 0)) > overflow(); > return c; > } > > still, doesn't have a problem. > > (explanation: > overflow occured if inputs have same sign and output differs from their sign > overflow cannot occur if inputs have different sign > sign(x) equivalent to (x < 0) (maps one to one: negative => 1, positive => 0) > ) > > > - Jay > From hosking at cs.purdue.edu Sun Jul 4 16:49:55 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 4 Jul 2010 10:49:55 -0400 Subject: [M3devel] eliminating volatile on floats In-Reply-To: References: Message-ID: I don't understand what we would need to do to fix this without the hack of commenting out gcc functionality. Better to give gcc something it likes than to hack it. On 4 Jul 2010, at 10:25, Jay K wrote: > > Through simple trial/error I've tracked a need (the only need?) for floats down: > > If I set flag_tree_ter = 0, I can compile m3core where I couldn't before, with -O3. > > > I suspect due to: > > builtins.c: > > int > get_pointer_alignment (tree exp, unsigned int max_align) > { > unsigned int align, inner; > > /* We rely on TER to compute accurate alignment information. */ > if (!(optimize && flag_tree_ter)) > return 0; > > > Another thing to try is #if 0 out this block of code (it is not in parse,c but "gcc itself"). > That should yield more optimization, but more patch to gcc. > I'm inclined to try that. > > > There should be additional options, like getting the alignment correct or such. > > > The code that fails to compile is: > /dev2/cm3/m3-libs/m3core/src/float/IEEE/LongFloat.m3 > > > PROCEDURE CopySign (x, y: T): T = > VAR res := x; > BEGIN > LOOPHOLE (res, Rep.T).sign := LOOPHOLE (y, Rep.T).sign; > RETURN res; > END CopySign; > > > I also tried some other options like adding volatile and/or temporaries on loophole's using t_struct. > > > (To be clear, we only have volatile on float loads, not stores, though I think only stores would be preferable to only loads. > "reads are more common than writes", "consider the registers to be a write-through cache") > > > - Jay > From hosking at cs.purdue.edu Sun Jul 4 16:47:50 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 4 Jul 2010 10:47:50 -0400 Subject: [M3devel] aliases/optimization In-Reply-To: References: <20100703105709.DBD2E2474003@birch.elegosoft.com>, , , , , , <00538FB2-00DA-4C0E-82F3-D151B9A85A0E@cs.purdue.edu>, Message-ID: I thought I already implemented one of those. On 4 Jul 2010, at 04:14, Jay K wrote: > > It appears this behavior is part of the C frontend, not the backend. > It appears..that maybe..we should provide a langhook get_alias_set that always returns 0. > The default is always -1. > Not clear to me. > > - Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: aliases/optimization >> Date: Sun, 4 Jul 2010 01:16:23 +0000 >> >> >> aha you just reminded me of something that we need to remember a bit and apply soon. >> >> >> Depending on compilers, optimization, etc. gcc doesn't like: >> >> >> float f; >> int i; >> i = *(int*)&f; >> >> though I think that's perfectly reasonable..anyway the equivalent form of code that gcc is explicitly ok with is: >> >> float f; >> >> int i; >> union { >> float f; >> int i; >> } u; >> u.f = f; >> i = u.i; >> >> So, point being, we should try changing LOOPHOLE to compile like that. >> You know, cons up the union type on-demand, make a local, etc. >> >> If we are lucky, that might solve some of our problems. >> Not the PPC ones. >> But that I left some systematic use of volatile in, like for all floating point, or something. >> And maybe it'll fix some of the optimizations I disabled. >> It'd still leave "unit at a time" broken. >> Possibly in tree-nested we can remove any notion of the functions being nested and >> maybe that'll help.. >> >> Search the for "gcc type punning" >> => wikipedia >> => link at the bottom >> >> http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Optimize-Options.html#index-fstrict_002daliasing-542 >> >> There is a subtlty there though..we'd have use member_ref on the union. >> They also give some pointer to what to do "for real". I can follow up, later. >> >> >> Disabling unit at a time is also lame. >> >> >> - Jay >> >> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> Date: Sat, 3 Jul 2010 20:50:11 -0400 >>> To: jay.krell at cornell.edu >>> CC: m3commit at elegosoft.com >>> Subject: Re: [M3commit] CVS Update: cm3 >>> >>> I added it a long time back only because I saw failures with optimisation turned on. Something to do with the alias analysis (and lack of proper type information) as far as I recall. >>> >>> >>> On 3 Jul 2010, at 20:44, Jay K wrote: >>> >>>> >>>> Tony, just to be clear..you/I are disturbed by volatile, but it has also, I believe, like always been there. >>>> It has been gone only very briefly, and its non-use is probably limited for other reasons (how many people are >>>> using it, on how many platforms?). >>>> >>>> >>>> - Jay >>>> >>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: hosking at cs.purdue.edu; jkrell at elego.de >>>>> CC: m3commit at elegosoft.com >>>>> Subject: RE: [M3commit] CVS Update: cm3 >>>>> Date: Sun, 4 Jul 2010 00:42:20 +0000 >>>>> >>>>> >>>>> Not a multiprocessor. >>>>> Still interested in selective volatile? >>>>> >>>>> >>>>> This all bothers me too. >>>>> I don't want volatile. It makes the optimized code terrible. >>>>> But I don't want to debug any problem from removing it, beyond compilation failure. >>>>> >>>>> >>>>> I can try a few things. >>>>> This is all wierd. I swear I saw it hang several times. >>>>> I swear I'm trying to to change "too many" variables at a time. Yes, I know, 2 is too many. >>>>> >>>>> >>>>> Once I started getting version stamp mismatch, I resorted to using a cross built cm3. >>>>> Out of necessity sort of, but that causes more flucuation of variables. >>>>> >>>>> Let me try again with volatile and see if it is solid. >>>>> Then I'll try with only volatile stores. >>>>> >>>>> I've been trying optimized and unoptimized, and not kept good track of which when. >>>>> >>>>> >>>>> - Jay >>>>> >>>>> >>>>> ---------------------------------------- >>>>>> From: hosking at cs.purdue.edu >>>>>> Date: Sat, 3 Jul 2010 20:36:20 -0400 >>>>>> To: jkrell at elego.de >>>>>> CC: m3commit at elegosoft.com >>>>>> Subject: Re: [M3commit] CVS Update: cm3 >>>>>> >>>>>> I am very disturbed that volatile is needed here. Can we selectively turn it on for thread-critical files like ThreadPThread and see if it fixes the problem. I wonder if the double-checked locking is broken for PPC memory model. Is this on a multi-processor? >>>>>> >>>>>> On 3 Jul 2010, at 12:57, Jay Krell wrote: >>>>>> >>>>>>> CVSROOT: /usr/cvs >>>>>>> Changes by: jkrell at birch. 10/07/03 12:57:09 >>>>>>> >>>>>>> Modified files: >>>>>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >>>>>>> >>>>>>> Log message: >>>>>>> restore volatile for powerpc and powerpc64 platforms >>>>>>> This seems to fix PPC_LINUX hanging. >>>>>>> This needs further debugging, but I'm not eager. >>>>>>> This will also affect PPC_DARWIN, PPC64_DARWIN, PPC32_OPENBSD, >>>>>>> PPC32_NETBSD, PPC32_FREEBSD, etc., but these platforms are little used or >>>>>>> nonexistant. >>>>>>> >>>>>>> Having volatile like has been the very long standing situation though. >>>>>>> The result is that the optimizer does basically nothing. >>>>>> >>>>> >>>> >>> >> > From jay.krell at cornell.edu Sun Jul 4 16:57:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 14:57:24 +0000 Subject: [M3devel] aliases/optimization In-Reply-To: <393E6607-54BD-4776-AB1E-D68BDA6F6906@cs.purdue.edu> References: <20100703105709.DBD2E2474003@birch.elegosoft.com>, , , , , , <00538FB2-00DA-4C0E-82F3-D151B9A85A0E@cs.purdue.edu> , <393E6607-54BD-4776-AB1E-D68BDA6F6906@cs.purdue.edu> Message-ID: Further research suggests this is frontend behavior, not backend. Oops my mistake. I read the C compiler documentation and forget about that division. Though I haven't tried this, it appears maybe a "lang hook" get_alias_set that returns 0 might be an easy win pessimistic win. Perhaps, again, only in unsafe modules and/or modules that use loophole (yes, I realize loophole implies unsafe). It's not clear to me yet what the default alias analysis is. -1 seems to mean "the default" and 0 seems to mean "pessimisic" Oh I didn't realize, we have: alias_set_type m3_get_alias_set (tree ARG_UNUSED (t)) { ? return 0; } which I'm pretty sure means pessimistic. ?- Jay ---------------------------------------- > Subject: Re: aliases/optimization > From: hosking at cs.purdue.edu > Date: Sun, 4 Jul 2010 10:47:03 -0400 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > Yes, that's right! > > On 3 Jul 2010, at 21:16, Jay K wrote: > > > > > aha you just reminded me of something that we need to remember a bit and apply soon. > > > > > > Depending on compilers, optimization, etc. gcc doesn't like: > > > > > > float f; > > int i; > > i = *(int*)&f; > > > > though I think that's perfectly reasonable..anyway the equivalent form of code that gcc is explicitly ok with is: > > > > float f; > > > > int i; > > union { > > float f; > > int i; > > } u; > > u.f = f; > > i = u.i; > > > > So, point being, we should try changing LOOPHOLE to compile like that. > > You know, cons up the union type on-demand, make a local, etc. > > > > If we are lucky, that might solve some of our problems. > > Not the PPC ones. > > But that I left some systematic use of volatile in, like for all floating point, or something. > > And maybe it'll fix some of the optimizations I disabled. > > It'd still leave "unit at a time" broken. > > Possibly in tree-nested we can remove any notion of the functions being nested and > > maybe that'll help.. > > > > Search the for "gcc type punning" > > => wikipedia > > => link at the bottom > > > > http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Optimize-Options.html#index-fstrict_002daliasing-542 > > > > There is a subtlty there though..we'd have use member_ref on the union. > > They also give some pointer to what to do "for real". I can follow up, later. > > > > > > Disabling unit at a time is also lame. > > > > > > - Jay > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Sat, 3 Jul 2010 20:50:11 -0400 > >> To: jay.krell at cornell.edu > >> CC: m3commit at elegosoft.com > >> Subject: Re: [M3commit] CVS Update: cm3 > >> > >> I added it a long time back only because I saw failures with optimisation turned on. Something to do with the alias analysis (and lack of proper type information) as far as I recall. > >> > >> > >> On 3 Jul 2010, at 20:44, Jay K wrote: > >> > >>> > >>> Tony, just to be clear..you/I are disturbed by volatile, but it has also, I believe, like always been there. > >>> It has been gone only very briefly, and its non-use is probably limited for other reasons (how many people are > >>> using it, on how many platforms?). > >>> > >>> > >>> - Jay > >>> > >>> ---------------------------------------- > >>>> From: jay.krell at cornell.edu > >>>> To: hosking at cs.purdue.edu; jkrell at elego.de > >>>> CC: m3commit at elegosoft.com > >>>> Subject: RE: [M3commit] CVS Update: cm3 > >>>> Date: Sun, 4 Jul 2010 00:42:20 +0000 > >>>> > >>>> > >>>> Not a multiprocessor. > >>>> Still interested in selective volatile? > >>>> > >>>> > >>>> This all bothers me too. > >>>> I don't want volatile. It makes the optimized code terrible. > >>>> But I don't want to debug any problem from removing it, beyond compilation failure. > >>>> > >>>> > >>>> I can try a few things. > >>>> This is all wierd. I swear I saw it hang several times. > >>>> I swear I'm trying to to change "too many" variables at a time. Yes, I know, 2 is too many. > >>>> > >>>> > >>>> Once I started getting version stamp mismatch, I resorted to using a cross built cm3. > >>>> Out of necessity sort of, but that causes more flucuation of variables. > >>>> > >>>> Let me try again with volatile and see if it is solid. > >>>> Then I'll try with only volatile stores. > >>>> > >>>> I've been trying optimized and unoptimized, and not kept good track of which when. > >>>> > >>>> > >>>> - Jay > >>>> > >>>> > >>>> ---------------------------------------- > >>>>> From: hosking at cs.purdue.edu > >>>>> Date: Sat, 3 Jul 2010 20:36:20 -0400 > >>>>> To: jkrell at elego.de > >>>>> CC: m3commit at elegosoft.com > >>>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>>> > >>>>> I am very disturbed that volatile is needed here. Can we selectively turn it on for thread-critical files like ThreadPThread and see if it fixes the problem. I wonder if the double-checked locking is broken for PPC memory model. Is this on a multi-processor? > >>>>> > >>>>> On 3 Jul 2010, at 12:57, Jay Krell wrote: > >>>>> > >>>>>> CVSROOT: /usr/cvs > >>>>>> Changes by: jkrell at birch. 10/07/03 12:57:09 > >>>>>> > >>>>>> Modified files: > >>>>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > >>>>>> > >>>>>> Log message: > >>>>>> restore volatile for powerpc and powerpc64 platforms > >>>>>> This seems to fix PPC_LINUX hanging. > >>>>>> This needs further debugging, but I'm not eager. > >>>>>> This will also affect PPC_DARWIN, PPC64_DARWIN, PPC32_OPENBSD, > >>>>>> PPC32_NETBSD, PPC32_FREEBSD, etc., but these platforms are little used or > >>>>>> nonexistant. > >>>>>> > >>>>>> Having volatile like has been the very long standing situation though. > >>>>>> The result is that the optimizer does basically nothing. > >>>>> > >>>> > >>> > >> > > > From jay.krell at cornell.edu Sun Jul 4 16:57:49 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 14:57:49 +0000 Subject: [M3devel] aliases/optimization In-Reply-To: References: <20100703105709.DBD2E2474003@birch.elegosoft.com>, ,,, , , , , , , <00538FB2-00DA-4C0E-82F3-D151B9A85A0E@cs.purdue.edu>, , , , Message-ID: Yep I just noticed, finally. ?- Jay --------------------------------------- > From: hosking at cs.purdue.edu > Date: Sun, 4 Jul 2010 10:47:50 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] aliases/optimization > > I thought I already implemented one of those. > > On 4 Jul 2010, at 04:14, Jay K wrote: > > > > > It appears this behavior is part of the C frontend, not the backend. > > It appears..that maybe..we should provide a langhook get_alias_set that always returns 0. > > The default is always -1. > > Not clear to me. > > > > - Jay > > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: hosking at cs.purdue.edu > >> CC: m3devel at elegosoft.com > >> Subject: aliases/optimization > >> Date: Sun, 4 Jul 2010 01:16:23 +0000 > >> > >> > >> aha you just reminded me of something that we need to remember a bit and apply soon. > >> > >> > >> Depending on compilers, optimization, etc. gcc doesn't like: > >> > >> > >> float f; > >> int i; > >> i = *(int*)&f; > >> > >> though I think that's perfectly reasonable..anyway the equivalent form of code that gcc is explicitly ok with is: > >> > >> float f; > >> > >> int i; > >> union { > >> float f; > >> int i; > >> } u; > >> u.f = f; > >> i = u.i; > >> > >> So, point being, we should try changing LOOPHOLE to compile like that. > >> You know, cons up the union type on-demand, make a local, etc. > >> > >> If we are lucky, that might solve some of our problems. > >> Not the PPC ones. > >> But that I left some systematic use of volatile in, like for all floating point, or something. > >> And maybe it'll fix some of the optimizations I disabled. > >> It'd still leave "unit at a time" broken. > >> Possibly in tree-nested we can remove any notion of the functions being nested and > >> maybe that'll help.. > >> > >> Search the for "gcc type punning" > >> => wikipedia > >> => link at the bottom > >> > >> http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Optimize-Options.html#index-fstrict_002daliasing-542 > >> > >> There is a subtlty there though..we'd have use member_ref on the union. > >> They also give some pointer to what to do "for real". I can follow up, later. > >> > >> > >> Disabling unit at a time is also lame. > >> > >> > >> - Jay > >> > >> ---------------------------------------- > >>> From: hosking at cs.purdue.edu > >>> Date: Sat, 3 Jul 2010 20:50:11 -0400 > >>> To: jay.krell at cornell.edu > >>> CC: m3commit at elegosoft.com > >>> Subject: Re: [M3commit] CVS Update: cm3 > >>> > >>> I added it a long time back only because I saw failures with optimisation turned on. Something to do with the alias analysis (and lack of proper type information) as far as I recall. > >>> > >>> > >>> On 3 Jul 2010, at 20:44, Jay K wrote: > >>> > >>>> > >>>> Tony, just to be clear..you/I are disturbed by volatile, but it has also, I believe, like always been there. > >>>> It has been gone only very briefly, and its non-use is probably limited for other reasons (how many people are > >>>> using it, on how many platforms?). > >>>> > >>>> > >>>> - Jay > >>>> > >>>> ---------------------------------------- > >>>>> From: jay.krell at cornell.edu > >>>>> To: hosking at cs.purdue.edu; jkrell at elego.de > >>>>> CC: m3commit at elegosoft.com > >>>>> Subject: RE: [M3commit] CVS Update: cm3 > >>>>> Date: Sun, 4 Jul 2010 00:42:20 +0000 > >>>>> > >>>>> > >>>>> Not a multiprocessor. > >>>>> Still interested in selective volatile? > >>>>> > >>>>> > >>>>> This all bothers me too. > >>>>> I don't want volatile. It makes the optimized code terrible. > >>>>> But I don't want to debug any problem from removing it, beyond compilation failure. > >>>>> > >>>>> > >>>>> I can try a few things. > >>>>> This is all wierd. I swear I saw it hang several times. > >>>>> I swear I'm trying to to change "too many" variables at a time. Yes, I know, 2 is too many. > >>>>> > >>>>> > >>>>> Once I started getting version stamp mismatch, I resorted to using a cross built cm3. > >>>>> Out of necessity sort of, but that causes more flucuation of variables. > >>>>> > >>>>> Let me try again with volatile and see if it is solid. > >>>>> Then I'll try with only volatile stores. > >>>>> > >>>>> I've been trying optimized and unoptimized, and not kept good track of which when. > >>>>> > >>>>> > >>>>> - Jay > >>>>> > >>>>> > >>>>> ---------------------------------------- > >>>>>> From: hosking at cs.purdue.edu > >>>>>> Date: Sat, 3 Jul 2010 20:36:20 -0400 > >>>>>> To: jkrell at elego.de > >>>>>> CC: m3commit at elegosoft.com > >>>>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>>>> > >>>>>> I am very disturbed that volatile is needed here. Can we selectively turn it on for thread-critical files like ThreadPThread and see if it fixes the problem. I wonder if the double-checked locking is broken for PPC memory model. Is this on a multi-processor? > >>>>>> > >>>>>> On 3 Jul 2010, at 12:57, Jay Krell wrote: > >>>>>> > >>>>>>> CVSROOT: /usr/cvs > >>>>>>> Changes by: jkrell at birch. 10/07/03 12:57:09 > >>>>>>> > >>>>>>> Modified files: > >>>>>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > >>>>>>> > >>>>>>> Log message: > >>>>>>> restore volatile for powerpc and powerpc64 platforms > >>>>>>> This seems to fix PPC_LINUX hanging. > >>>>>>> This needs further debugging, but I'm not eager. > >>>>>>> This will also affect PPC_DARWIN, PPC64_DARWIN, PPC32_OPENBSD, > >>>>>>> PPC32_NETBSD, PPC32_FREEBSD, etc., but these platforms are little used or > >>>>>>> nonexistant. > >>>>>>> > >>>>>>> Having volatile like has been the very long standing situation though. > >>>>>>> The result is that the optimizer does basically nothing. > >>>>>> > >>>>> > >>>> > >>> > >> > > > From hosking at cs.purdue.edu Sun Jul 4 16:47:03 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 4 Jul 2010 10:47:03 -0400 Subject: [M3devel] aliases/optimization In-Reply-To: References: <20100703105709.DBD2E2474003@birch.elegosoft.com>, , , , , , <00538FB2-00DA-4C0E-82F3-D151B9A85A0E@cs.purdue.edu> Message-ID: <393E6607-54BD-4776-AB1E-D68BDA6F6906@cs.purdue.edu> Yes, that's right! On 3 Jul 2010, at 21:16, Jay K wrote: > > aha you just reminded me of something that we need to remember a bit and apply soon. > > > Depending on compilers, optimization, etc. gcc doesn't like: > > > float f; > int i; > i = *(int*)&f; > > though I think that's perfectly reasonable..anyway the equivalent form of code that gcc is explicitly ok with is: > > float f; > > int i; > union { > float f; > int i; > } u; > u.f = f; > i = u.i; > > So, point being, we should try changing LOOPHOLE to compile like that. > You know, cons up the union type on-demand, make a local, etc. > > If we are lucky, that might solve some of our problems. > Not the PPC ones. > But that I left some systematic use of volatile in, like for all floating point, or something. > And maybe it'll fix some of the optimizations I disabled. > It'd still leave "unit at a time" broken. > Possibly in tree-nested we can remove any notion of the functions being nested and > maybe that'll help.. > > Search the for "gcc type punning" > => wikipedia > => link at the bottom > > http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Optimize-Options.html#index-fstrict_002daliasing-542 > > There is a subtlty there though..we'd have use member_ref on the union. > They also give some pointer to what to do "for real". I can follow up, later. > > > Disabling unit at a time is also lame. > > > - Jay > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Sat, 3 Jul 2010 20:50:11 -0400 >> To: jay.krell at cornell.edu >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> I added it a long time back only because I saw failures with optimisation turned on. Something to do with the alias analysis (and lack of proper type information) as far as I recall. >> >> >> On 3 Jul 2010, at 20:44, Jay K wrote: >> >>> >>> Tony, just to be clear..you/I are disturbed by volatile, but it has also, I believe, like always been there. >>> It has been gone only very briefly, and its non-use is probably limited for other reasons (how many people are >>> using it, on how many platforms?). >>> >>> >>> - Jay >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: hosking at cs.purdue.edu; jkrell at elego.de >>>> CC: m3commit at elegosoft.com >>>> Subject: RE: [M3commit] CVS Update: cm3 >>>> Date: Sun, 4 Jul 2010 00:42:20 +0000 >>>> >>>> >>>> Not a multiprocessor. >>>> Still interested in selective volatile? >>>> >>>> >>>> This all bothers me too. >>>> I don't want volatile. It makes the optimized code terrible. >>>> But I don't want to debug any problem from removing it, beyond compilation failure. >>>> >>>> >>>> I can try a few things. >>>> This is all wierd. I swear I saw it hang several times. >>>> I swear I'm trying to to change "too many" variables at a time. Yes, I know, 2 is too many. >>>> >>>> >>>> Once I started getting version stamp mismatch, I resorted to using a cross built cm3. >>>> Out of necessity sort of, but that causes more flucuation of variables. >>>> >>>> Let me try again with volatile and see if it is solid. >>>> Then I'll try with only volatile stores. >>>> >>>> I've been trying optimized and unoptimized, and not kept good track of which when. >>>> >>>> >>>> - Jay >>>> >>>> >>>> ---------------------------------------- >>>>> From: hosking at cs.purdue.edu >>>>> Date: Sat, 3 Jul 2010 20:36:20 -0400 >>>>> To: jkrell at elego.de >>>>> CC: m3commit at elegosoft.com >>>>> Subject: Re: [M3commit] CVS Update: cm3 >>>>> >>>>> I am very disturbed that volatile is needed here. Can we selectively turn it on for thread-critical files like ThreadPThread and see if it fixes the problem. I wonder if the double-checked locking is broken for PPC memory model. Is this on a multi-processor? >>>>> >>>>> On 3 Jul 2010, at 12:57, Jay Krell wrote: >>>>> >>>>>> CVSROOT: /usr/cvs >>>>>> Changes by: jkrell at birch. 10/07/03 12:57:09 >>>>>> >>>>>> Modified files: >>>>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >>>>>> >>>>>> Log message: >>>>>> restore volatile for powerpc and powerpc64 platforms >>>>>> This seems to fix PPC_LINUX hanging. >>>>>> This needs further debugging, but I'm not eager. >>>>>> This will also affect PPC_DARWIN, PPC64_DARWIN, PPC32_OPENBSD, >>>>>> PPC32_NETBSD, PPC32_FREEBSD, etc., but these platforms are little used or >>>>>> nonexistant. >>>>>> >>>>>> Having volatile like has been the very long standing situation though. >>>>>> The result is that the optimizer does basically nothing. >>>>> >>>> >>> >> > From jay.krell at cornell.edu Sun Jul 4 17:01:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 15:01:53 +0000 Subject: [M3devel] eliminating volatile on floats In-Reply-To: References: , Message-ID: The #if 0 didn't seem to work. I'll go with ter = 0 for now. Then maybe look at what equivalent C does. I still think the problem is maybe something about alignment, more than type punning/aliases, though they are related. I checked some obvious things, like, if alignment of int/long/float/double/void* were other than I expected in C. I'll go with ter = 0 for now. I think I'll commit that as some steps forward and backward but not a bad tradeoff. Granted, I don't know really what ter is and how effective it is, but O1, O2, O3 are each a "bundle" of quite a number of optimizations. Throwing out some of them seems not too terrible. Throwing in volatile definitely defeats a lot, and probably not the ones I turn off. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Sun, 4 Jul 2010 10:49:55 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] eliminating volatile on floats > > I don't understand what we would need to do to fix this without the hack of commenting out gcc functionality. Better to give gcc something it likes than to hack it. > > On 4 Jul 2010, at 10:25, Jay K wrote: > > > > > Through simple trial/error I've tracked a need (the only need?) for floats down: > > > > If I set flag_tree_ter = 0, I can compile m3core where I couldn't before, with -O3. > > > > > > I suspect due to: > > > > builtins.c: > > > > int > > get_pointer_alignment (tree exp, unsigned int max_align) > > { > > unsigned int align, inner; > > > > /* We rely on TER to compute accurate alignment information. */ > > if (!(optimize && flag_tree_ter)) > > return 0; > > > > > > Another thing to try is #if 0 out this block of code (it is not in parse,c but "gcc itself"). > > That should yield more optimization, but more patch to gcc. > > I'm inclined to try that. > > > > > > There should be additional options, like getting the alignment correct or such. > > > > > > The code that fails to compile is: > > /dev2/cm3/m3-libs/m3core/src/float/IEEE/LongFloat.m3 > > > > > > PROCEDURE CopySign (x, y: T): T = > > VAR res := x; > > BEGIN > > LOOPHOLE (res, Rep.T).sign := LOOPHOLE (y, Rep.T).sign; > > RETURN res; > > END CopySign; > > > > > > I also tried some other options like adding volatile and/or temporaries on loophole's using t_struct. > > > > > > (To be clear, we only have volatile on float loads, not stores, though I think only stores would be preferable to only loads. > > "reads are more common than writes", "consider the registers to be a write-through cache") > > > > > > - Jay > > > From jay.krell at cornell.edu Sun Jul 4 17:50:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 15:50:03 +0000 Subject: [M3devel] volatile float/ter/copysign Message-ID: This is the code that often fails to compile. Aha, well look at that. PROCEDURE CopySign (x, y: T): T = ? VAR res := x; ? BEGIN ??? LOOPHOLE (res, Rep.T).sign := LOOPHOLE (y, Rep.T).sign; ??? RETURN res; ? END CopySign; There's no loophole! Store lreal, load int64->word8 => insert_mn => store int64->word8. There are several other ways to write this code, but I guess that's not the point. (552) begin_procedure ? procedure LongFloat__CopySign ?LongFloat__CopySign(553) set_source_line ? source line? 117 (554) load ? type:lreal ? type:lreal ? m3cg_load (M3_CtKayy_x): offset 0x0, convert lreal -> lreal (555) store ? type:lreal ? type:lreal ? store (M3_CtKayy_res) offset:0x0 src_t:lreal dst_t:lreal (556) set_source_line ? source line? 119 (557) load ? type:word8 ? type:int64 ? m3cg_load (M3_CtKayy_y): offset 0x38, convert word8 -> int64 (558) extract_mn ? type:int64 ?extract_mn offset:7 count:1 sign_extend:0 (559) load ? type:word8 ? type:int64 ? m3cg_load (M3_CtKayy_res): offset 0x38, convert word8 -> int64 (560) swap ? type:int64 ? type:int64 (561) insert_mn ? type:int64 ?insert_mn offset:7 count:1 (562) store ? type:int64 ? type:word8 ? store (M3_CtKayy_res) offset:0x38 src_t:int64 dst_t:word8 (563) set_source_line ? source line? 120 (564) load ? type:lreal ? type:lreal ? m3cg_load (M3_CtKayy_res): offset 0x0, convert lreal -> lreal (565) exit_proc ? type:lreal (566) end_procedure ?- Jay From jay.krell at cornell.edu Sun Jul 4 18:20:01 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 4 Jul 2010 16:20:01 +0000 Subject: [M3devel] licensing (gcc patches) Message-ID: licensing "for the record" I don't necessarily want to discuss it.. It has been speculated here that our gcc patches weren't acceptable because our license is more restrictive than GPL. I believe it is more like the opposite. Our patches not accepted because our license is /less/ restrictive. ?To most of the code. Not to the patch or files added to gcc. ?? They can't really be. In particular, by splitting cm3 from m3cg, the license "boundary" is stopped. parse.c is/must be GPL. All the various *.m3 files not. GPL advocates would prefer GPL code be linked to more code, thus forcing more code to be GPL. Doing something like splitting "something" into two processes is kind of a deliberate anti-GPL move. It may or may not make good engineering sense. (It does and it doesn't, in fact. It is good for development/testing, bad for performance.) Lately they allow "plugins", though they must be GPL. Gcc faces "competition", e.g. LLVM. Maybe things are more relaxed now. Besides all that, non-trivial gcc patches require signing FSF papers. Something I at least am very unlikely able to do. But the vast bulk of the work I had nothing to do with. And you can remove my changs with little effect. Alternatively of course, LLVM has a more liberal license. Generating C has no licening problem. Porting m3back to more targets ditto.. ?- Jay From hendrik at topoi.pooq.com Sun Jul 4 22:04:18 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 4 Jul 2010 16:04:18 -0400 Subject: [M3devel] licensing (gcc patches) In-Reply-To: References: Message-ID: <20100704200418.GC22573@topoi.pooq.com> On Sun, Jul 04, 2010 at 04:20:01PM +0000, Jay K wrote: > > licensing > > > "for the record" > I don't necessarily want to discuss it.. > > > It has been speculated here that > our gcc patches weren't acceptable > because our license is more restrictive than GPL. > > > I believe it is more like the opposite. > Our patches not accepted because our license is /less/ restrictive. The restriction I see in the modula 3 license is everyone dealing in Modula 3 code has to allow SRC to do anything they want to any of it. This 'requirement to allow' is a restriction that doesn't apply to GPL, so in that sense we're more restrictive. In pretty well all other ways, we're less restrictive. > ?To most of the code. Not to the patch or files added to gcc. > ?They can't really be. Of course any code we *add* at this point can be dual-licensed, letting people who get it use one license, or the other, or both, at their option. -- hendrik From wagner at elegosoft.com Mon Jul 5 09:32:30 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 05 Jul 2010 09:32:30 +0200 Subject: [M3devel] licensing (gcc patches) In-Reply-To: <20100704200418.GC22573@topoi.pooq.com> References: <20100704200418.GC22573@topoi.pooq.com> Message-ID: <20100705093230.k462uhajq8cc8kkw@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > On Sun, Jul 04, 2010 at 04:20:01PM +0000, Jay K wrote: >> >> licensing >> >> "for the record" >> I don't necessarily want to discuss it.. >> >> >> It has been speculated here that >> our gcc patches weren't acceptable >> because our license is more restrictive than GPL. >> >> I believe it is more like the opposite. >> Our patches not accepted because our license is /less/ restrictive. > > The restriction I see in the modula 3 license is everyone dealing in > Modula 3 code has to allow SRC to do anything they want to any of it. > This 'requirement to allow' is a restriction that doesn't apply to GPL, > so in that sense we're more restrictive. > > In pretty well all other ways, we're less restrictive. The M3 licence allows free use and distribution of the code in source and binary format. There is no restriction that source must be provided if it is changed or sold or just used as a service by anyone, i.e. it is no viral license. The only provision is that _if_ patches are returned to the copyright owner (which can be DEC, Critical Mass, or others), they may use them for any purpose they wish without any restriction, too. Actually, both DEC and Critical Mass won't (any more). At least as far as I can see... >> ?To most of the code. Not to the patch or files added to gcc. >> ?They can't really be. > > Of course any code we *add* at this point can be dual-licensed, letting > people who get it use one license, or the other, or both, at their > option. Code linked with gcc must be under GPL. That's why DEC went to all this fuss with two-phase compilation using two processes. Otherwise all the M3 compiler code would need to be distributed as source by anyone who uses it, too. GPL is still pretty much a no-go for commercial use. In fact that's the reason why the FSF never accepted the M3 extensions for gcc; they didn't approve of the license `workaround'. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Jul 5 09:39:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 07:39:44 +0000 Subject: [M3devel] licensing (gcc patches) In-Reply-To: <20100704200418.GC22573@topoi.pooq.com> References: , <20100704200418.GC22573@topoi.pooq.com> Message-ID: > Of course any code we *add* at this point can be dual-licensed, letting I find "dual license" confusing. I like the BSD way, esp. OpenBSD way.Besides being "liberal", they also significantly favor "simplicity". Simple, short, clear, and also widely used. I'm talking about the license, not the code.That is, if you come up with a new license, and claim it is liberal, but it takes too muchtime/effort/money/lawyer to read and interpret, then they reject it.They reject for example Apache 2.x. Thus they stick with Apache 1.x.I kind of wish they wouldn't stick with Apache 1.x, it seems "dangerous" to lingerback on "old" versions, but I understand the reason.I don't know if they stuck with gcc 3.x to avoid bloat or to avoid GPL 3. I don't think we have a choice in the licensing of what we add, parse.c in particular.I suspect parts of it are copied from the GPL gcc C front end.That is ok. - Jay > Date: Sun, 4 Jul 2010 16:04:18 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] licensing (gcc patches) > > On Sun, Jul 04, 2010 at 04:20:01PM +0000, Jay K wrote: > > > > licensing > > > > > > "for the record" > > I don't necessarily want to discuss it.. > > > > > > It has been speculated here that > > our gcc patches weren't acceptable > > because our license is more restrictive than GPL. > > > > > > I believe it is more like the opposite. > > Our patches not accepted because our license is /less/ restrictive. > > The restriction I see in the modula 3 license is everyone dealing in > Modula 3 code has to allow SRC to do anything they want to any of it. > This 'requirement to allow' is a restriction that doesn't apply to GPL, > so in that sense we're more restrictive. > > In pretty well all other ways, we're less restrictive. > > > To most of the code. Not to the patch or files added to gcc. > > They can't really be. > > Of course any code we *add* at this point can be dual-licensed, letting > people who get it use one license, or the other, or both, at their > option. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Jul 5 11:24:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 09:24:20 +0000 Subject: [M3devel] loophole/copysign Message-ID: Our codegen is remarkably low level. That is, lower level earlier than C. gcc/m3cg -ftree-dump-all As early as LongFloat.mc.003t.original, the first file dumped, we have: LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) { ? xreel M3_CtKayy__result; ? xreel M3_CtKayy_res; ??? xreel M3_CtKayy__result; ??? xreel M3_CtKayy_res; ? M3_CtKayy_res = M3_CtKayy_x; ? BIT_FIELD_REF = (word_8) ((int_64) ? BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); ? = M3_CtKayy_res; ? return ; } compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: copy_sign_f (from, to) { ? float res; ? float D.1918; ? D.1917; ? struct float_t * from.1; ? struct float_t * res.0; : ? res = to_1; ? res.0_4 = (struct float_t *) &res; ? from.1_5 = (struct float_t *) &from; ? D.1917_6 = from.1_5->sign; ? res.0_4->sign = D.1917_6; ? D.1918_7 = res; ? return D.1918_7; } See, you know, from gcc's point of view, we don't have any records/structs/unions. Just integers and offsets from them mostly. The right fix is to build up types. That way also debugging with gdb will have a chance. Perhaps not a small amount of work. But maybe not too bad. For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. At least if one type but not the other is floating point. I don't know if that will work, but maybe. Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or store volatile. ?- Jay From jay.krell at cornell.edu Mon Jul 5 12:42:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 10:42:57 +0000 Subject: [M3devel] loophole/copysign In-Reply-To: References: Message-ID: Tony, et. al.. in m3front/src/exprs/CastExpr.m3..what's the difference between a "designator" and a "value"? http://www-plan.cs.colorado.edu/diwan/modula3/designators.html An identifier is a writable designator if it is declared as a variable, is a VAR or VALUE parameter, is a local of a TYPECASE or TRY EXCEPT statement, or is a WITH local that is bound to a writable designator. An identifier is a readonly designator if it is a READONLY parameter, a local of a FOR statement, or a WITH local bound to a non-designator or readonly designator. I guess a designator is what I would think of a "variable" or "read only variable"? Something that either is "in memory" or can "reasonably" be put there? 1 + 2 is not a designator. Or, generally, a "variable", but that includes such similar things as parameters, "with variables", "for variables", "TYPECASE vairables", "TRY variables" Anything with a name??? (not functions/modules/generics -- "named data") Anyway, the next questions include: In CastExpr.m3 would it be terrible and/or wrong to treat "designators" the same as "values"? ?I realize, probably a deoptimization. ?I think this lets the backend work. ? And really, more to the point...shouldn't CastExpr.m3 use cg.loophole far more? I haven't had much luck with that. I always get the cg stack out of balance or with the wrong types, even though it seems like it should be easy. I have more testing to do, but classifying the loophole as V_to_S (value to structure) in place of D_to_S (designator to structure), at least if either side is one of the three float types, seems reasonable and correct, albeit slight deoptimization -- in unsafe code dealing with floating point..should be rare.. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 5 Jul 2010 09:24:20 +0000 > Subject: [M3devel] loophole/copysign > > > Our codegen is remarkably low level. That is, lower level earlier than C. > > > gcc/m3cg -ftree-dump-all > > > As early as LongFloat.mc.003t.original, the first file dumped, we have: > > LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) > { > xreel M3_CtKayy__result; > xreel M3_CtKayy_res; > > xreel M3_CtKayy__result; > xreel M3_CtKayy_res; > M3_CtKayy_res = M3_CtKayy_x; > BIT_FIELD_REF = (word_8) ((int_64) > BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); > = M3_CtKayy_res; > return ; > } > > compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: > > copy_sign_f (from, to) > { > float res; > float D.1918; > D.1917; > struct float_t * from.1; > struct float_t * res.0; > > : > res = to_1; > res.0_4 = (struct float_t *) &res; > from.1_5 = (struct float_t *) &from; > D.1917_6 = from.1_5->sign; > res.0_4->sign = D.1917_6; > D.1918_7 = res; > return D.1918_7; > > } > > > See, you know, from gcc's point of view, we don't have any records/structs/unions. > Just integers and offsets from them mostly. > > > The right fix is to build up types. > That way also debugging with gdb will have a chance. > Perhaps not a small amount of work. But maybe not too bad. > > > For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. > At least if one type but not the other is floating point. > I don't know if that will work, but maybe. > > Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or > store volatile. > > - Jay > From jay.krell at cornell.edu Mon Jul 5 13:25:19 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 11:25:19 +0000 Subject: [M3devel] loophole/copysign In-Reply-To: References: , Message-ID: Hm. it seems that it might be important to preserve the "designatorness", like in: libm3/...RandomReal.m3: ? VAR frac, exp: INTEGER; result: LONGREAL; ??? (* Repack as LONGREAL: *) ??? WITH lr = LOOPHOLE (result, LongRealRep.T) DO ????? lr.sign := 0; ????? lr.exponent := exp; ????? lr.significand0 := Word.Shift (Word.And (frac, 16_7fffffff), ????????????????????????????????????? -(WordSize - 1 - FractionBits)); ????? lr.significand1 := r.integer (min := -16_7fffffff-1, max :=16_7fffffff); ??? END; ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 5 Jul 2010 10:42:57 +0000 > Subject: Re: [M3devel] loophole/copysign > > > Tony, et. al.. in m3front/src/exprs/CastExpr.m3..what's the difference between a "designator" and a "value"? > > > http://www-plan.cs.colorado.edu/diwan/modula3/designators.html > > An identifier is a writable designator > if it is declared as a variable, > is a VAR or VALUE parameter, > is a local of a TYPECASE > or TRY EXCEPT statement, > or is a WITH local that is bound to a writable designator. > An identifier is a readonly designator if it is > a READONLY parameter, > a local of a FOR statement, > or a WITH local bound to a non-designator or > readonly designator. > > > > I guess a designator is what I would think of a "variable" or "read only variable"? > Something that either is "in memory" or can "reasonably" be put there? > > > 1 + 2 is not a designator. > > > Or, generally, a "variable", but that includes such similar things as parameters, "with variables", "for variables", "TYPECASE vairables", "TRY variables" > > > Anything with a name??? (not functions/modules/generics -- "named data") > > > Anyway, the next questions include: > > > In CastExpr.m3 would it be terrible and/or wrong to treat "designators" the same as "values"? > I realize, probably a deoptimization. > I think this lets the backend work. > > > And really, more to the point...shouldn't CastExpr.m3 use cg.loophole far more? > I haven't had much luck with that. I always get the cg stack out of balance or with the wrong types, even though it seems like it should be easy. > > > I have more testing to do, but classifying the loophole as V_to_S (value to structure) in place of D_to_S (designator to structure), at least if either side is one of the three float types, seems reasonable and correct, albeit slight deoptimization -- in unsafe code dealing with floating point..should be rare.. > > > - Jay > > > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Date: Mon, 5 Jul 2010 09:24:20 +0000 > > Subject: [M3devel] loophole/copysign > > > > > > Our codegen is remarkably low level. That is, lower level earlier than C. > > > > > > gcc/m3cg -ftree-dump-all > > > > > > As early as LongFloat.mc.003t.original, the first file dumped, we have: > > > > LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) > > { > > xreel M3_CtKayy__result; > > xreel M3_CtKayy_res; > > > > xreel M3_CtKayy__result; > > xreel M3_CtKayy_res; > > M3_CtKayy_res = M3_CtKayy_x; > > BIT_FIELD_REF = (word_8) ((int_64) > > BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); > > = M3_CtKayy_res; > > return ; > > } > > > > compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: > > > > copy_sign_f (from, to) > > { > > float res; > > float D.1918; > > D.1917; > > struct float_t * from.1; > > struct float_t * res.0; > > > > : > > res = to_1; > > res.0_4 = (struct float_t *) &res; > > from.1_5 = (struct float_t *) &from; > > D.1917_6 = from.1_5->sign; > > res.0_4->sign = D.1917_6; > > D.1918_7 = res; > > return D.1918_7; > > > > } > > > > > > See, you know, from gcc's point of view, we don't have any records/structs/unions. > > Just integers and offsets from them mostly. > > > > > > The right fix is to build up types. > > That way also debugging with gdb will have a chance. > > Perhaps not a small amount of work. But maybe not too bad. > > > > > > For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. > > At least if one type but not the other is floating point. > > I don't know if that will work, but maybe. > > > > Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or > > store volatile. > > > > - Jay > > > From jay.krell at cornell.edu Mon Jul 5 13:36:11 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 11:36:11 +0000 Subject: [M3devel] loophole/copysign In-Reply-To: References: , , , Message-ID: another idea: let's not use bitfield ref for float/double ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 5 Jul 2010 11:25:19 +0000 > Subject: Re: [M3devel] loophole/copysign > > > Hm. it seems that it might be important to preserve the "designatorness", like in: > > libm3/...RandomReal.m3: > > VAR frac, exp: INTEGER; result: LONGREAL; > > (* Repack as LONGREAL: *) > WITH lr = LOOPHOLE (result, LongRealRep.T) DO > lr.sign := 0; > lr.exponent := exp; > lr.significand0 := Word.Shift (Word.And (frac, 16_7fffffff), > -(WordSize - 1 - FractionBits)); > lr.significand1 := r.integer (min := -16_7fffffff-1, max :=16_7fffffff); > END; > > > - Jay > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Date: Mon, 5 Jul 2010 10:42:57 +0000 > > Subject: Re: [M3devel] loophole/copysign > > > > > > Tony, et. al.. in m3front/src/exprs/CastExpr.m3..what's the difference between a "designator" and a "value"? > > > > > > http://www-plan.cs.colorado.edu/diwan/modula3/designators.html > > > > An identifier is a writable designator > > if it is declared as a variable, > > is a VAR or VALUE parameter, > > is a local of a TYPECASE > > or TRY EXCEPT statement, > > or is a WITH local that is bound to a writable designator. > > An identifier is a readonly designator if it is > > a READONLY parameter, > > a local of a FOR statement, > > or a WITH local bound to a non-designator or > > readonly designator. > > > > > > > > I guess a designator is what I would think of a "variable" or "read only variable"? > > Something that either is "in memory" or can "reasonably" be put there? > > > > > > 1 + 2 is not a designator. > > > > > > Or, generally, a "variable", but that includes such similar things as parameters, "with variables", "for variables", "TYPECASE vairables", "TRY variables" > > > > > > Anything with a name??? (not functions/modules/generics -- "named data") > > > > > > Anyway, the next questions include: > > > > > > In CastExpr.m3 would it be terrible and/or wrong to treat "designators" the same as "values"? > > I realize, probably a deoptimization. > > I think this lets the backend work. > > > > > > And really, more to the point...shouldn't CastExpr.m3 use cg.loophole far more? > > I haven't had much luck with that. I always get the cg stack out of balance or with the wrong types, even though it seems like it should be easy. > > > > > > I have more testing to do, but classifying the loophole as V_to_S (value to structure) in place of D_to_S (designator to structure), at least if either side is one of the three float types, seems reasonable and correct, albeit slight deoptimization -- in unsafe code dealing with floating point..should be rare.. > > > > > > - Jay > > > > > > > > ---------------------------------------- > > > From: jay.krell at cornell.edu > > > To: m3devel at elegosoft.com > > > Date: Mon, 5 Jul 2010 09:24:20 +0000 > > > Subject: [M3devel] loophole/copysign > > > > > > > > > Our codegen is remarkably low level. That is, lower level earlier than C. > > > > > > > > > gcc/m3cg -ftree-dump-all > > > > > > > > > As early as LongFloat.mc.003t.original, the first file dumped, we have: > > > > > > LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) > > > { > > > xreel M3_CtKayy__result; > > > xreel M3_CtKayy_res; > > > > > > xreel M3_CtKayy__result; > > > xreel M3_CtKayy_res; > > > M3_CtKayy_res = M3_CtKayy_x; > > > BIT_FIELD_REF = (word_8) ((int_64) > > > BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); > > > = M3_CtKayy_res; > > > return ; > > > } > > > > > > compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: > > > > > > copy_sign_f (from, to) > > > { > > > float res; > > > float D.1918; > > > D.1917; > > > struct float_t * from.1; > > > struct float_t * res.0; > > > > > > : > > > res = to_1; > > > res.0_4 = (struct float_t *) &res; > > > from.1_5 = (struct float_t *) &from; > > > D.1917_6 = from.1_5->sign; > > > res.0_4->sign = D.1917_6; > > > D.1918_7 = res; > > > return D.1918_7; > > > > > > } > > > > > > > > > See, you know, from gcc's point of view, we don't have any records/structs/unions. > > > Just integers and offsets from them mostly. > > > > > > > > > The right fix is to build up types. > > > That way also debugging with gdb will have a chance. > > > Perhaps not a small amount of work. But maybe not too bad. > > > > > > > > > For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. > > > At least if one type but not the other is floating point. > > > I don't know if that will work, but maybe. > > > > > > Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or > > > store volatile. > > > > > > - Jay > > > > > > From hendrik at topoi.pooq.com Mon Jul 5 14:24:15 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 5 Jul 2010 08:24:15 -0400 Subject: [M3devel] licensing (gcc patches) In-Reply-To: <20100705093230.k462uhajq8cc8kkw@mail.elegosoft.com> References: <20100704200418.GC22573@topoi.pooq.com> <20100705093230.k462uhajq8cc8kkw@mail.elegosoft.com> Message-ID: <20100705122414.GB27490@topoi.pooq.com> On Mon, Jul 05, 2010 at 09:32:30AM +0200, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > >> On Sun, Jul 04, 2010 at 04:20:01PM +0000, Jay K wrote: >>> >>> licensing >>> >>> "for the record" >>> I don't necessarily want to discuss it.. >>> >>> >>> It has been speculated here that >>> our gcc patches weren't acceptable >>> because our license is more restrictive than GPL. >>> >>> I believe it is more like the opposite. >>> Our patches not accepted because our license is /less/ restrictive. >> >> The restriction I see in the modula 3 license is everyone dealing in >> Modula 3 code has to allow SRC to do anything they want to any of it. >> This 'requirement to allow' is a restriction that doesn't apply to GPL, >> so in that sense we're more restrictive. >> >> In pretty well all other ways, we're less restrictive. > > The M3 licence allows free use and distribution of the code in source > and binary format. There is no restriction that source must be provided > if it is changed or sold or just used as a service by anyone, i.e. it is > no viral license. > > The only provision is that _if_ patches are returned to the copyright owner > (which can be DEC, Critical Mass, or others), they may use them for any > purpose they wish without any restriction, too. > > Actually, both DEC and Critical Mass won't (any more). At least as far > as I can see... > >>> ?To most of the code. Not to the patch or files added to gcc. >>> ?They can't really be. >> >> Of course any code we *add* at this point can be dual-licensed, letting >> people who get it use one license, or the other, or both, at their >> option. > > Code linked with gcc must be under GPL. That's why DEC went to all > this fuss with two-phase compilation using two processes. Otherwise all > the M3 compiler code would need to be distributed as source by anyone > who uses it, too. But code can be released under more than one licence, the SRC license *and* the GPL, for example. Of course, that would require the copyright holders to do that. > GPL is still pretty much a no-go for commercial use. > > In fact that's the reason why the FSF never accepted the M3 extensions > for gcc; they didn't approve of the license `workaround'. So the issue here is not wiether the M3 extensions to gcc are GPL'd, butwhether the FSF is willing to accept them into their gcc distribution? -- hendrik. From hendrik at topoi.pooq.com Mon Jul 5 14:39:55 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 5 Jul 2010 08:39:55 -0400 Subject: [M3devel] licensing (gcc patches) In-Reply-To: References: <20100704200418.GC22573@topoi.pooq.com> Message-ID: <20100705123955.GC27490@topoi.pooq.com> On Mon, Jul 05, 2010 at 07:39:44AM +0000, Jay K wrote: > > > Of course any code we *add* at this point can be dual-licensed, letting > I find "dual license" confusing. Each licence gives potential clients certain rights. If they follow the restrictions in either licence, they have the privileges granted by that licence. If they follow the restrictions of both, they have the privileges granted by both. If all of out new code were to be dual-licensed, we'd be compatible with the SRC licence (pretty easy to be), and our new code could be taken by anyone and used and redistributed under the GPL on its own. Whether it would be useful on its own is another question. GPL becomes restrictive is when you don't have the permission of all the copyright holders to change licenses. As in our case, where we, as far as I can tell, can't get it from SRC, perhaps only because they just don't care at all about the matter any more. > > I like the BSD way, esp. OpenBSD way.Besides being "liberal", they > also significantly favor "simplicity". Simple, short, clear, and also > widely used. I'm talking about the license, not the code.That is, if > you come up with a new license, and claim it is liberal, but it takes > too muchtime/effort/money/lawyer to read and interpret, then they > reject it.They reject for example Apache 2.x. Thus they stick with > Apache 1.x.I kind of wish they wouldn't stick with Apache 1.x, it > seems "dangerous" to lingerback on "old" versions, but I understand > the reason.I don't know if they stuck with gcc 3.x to avoid bloat or > to avoid GPL 3. > > I don't think we have a choice in the licensing of what we add, > parse.c in particular. I suspect parts of it are copied from the GPL > gcc C front end. That is ok. And that restricts us from distributing parse.c other than under the GPL. We can't dual-licence that bit. Is parse.c part of our modified gcc back end? If so, yes, that is OK. -- hendrik From jay.krell at cornell.edu Mon Jul 5 14:49:18 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 12:49:18 +0000 Subject: [M3devel] licensing (gcc patches) In-Reply-To: <20100705123955.GC27490@topoi.pooq.com> References: <20100704200418.GC22573@topoi.pooq.com>, , <20100705123955.GC27490@topoi.pooq.com> Message-ID: Yes parse.c is a new file added to gcc and contains the bulk of our work on gcc. There are some other small files and small diffs, but parse.c is really it. parse.c: the name seems wrong, but if you consider that from gcc's point of view, we are a front end, then it makes sense. As a front end to gcc, our "source language" is very odd, it is binary files encoding the sequence of function calls the "actual" frontend would have me to an "actual" backend. ?- Jay ---------------------------------------- > Date: Mon, 5 Jul 2010 08:39:55 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] licensing (gcc patches) > > On Mon, Jul 05, 2010 at 07:39:44AM +0000, Jay K wrote: > > > > > Of course any code we *add* at this point can be dual-licensed, letting > > I find "dual license" confusing. > > Each licence gives potential clients certain rights. If they follow > the restrictions in either licence, they have the privileges granted by > that licence. If they follow the restrictions of both, they have the > privileges granted by both. > > If all of out new code were to be dual-licensed, we'd be compatible with > the SRC licence (pretty easy to be), and our new code could be taken by > anyone and used and redistributed under the GPL on its own. Whether it > would be useful on its own is another question. > > GPL becomes restrictive is when you don't have the permission of all the > copyright holders to change licenses. As in our case, where we, as far > as I can tell, can't get it from SRC, perhaps only because they just > don't care at all about the matter any more. > > > > > I like the BSD way, esp. OpenBSD way.Besides being "liberal", they > > also significantly favor "simplicity". Simple, short, clear, and also > > widely used. I'm talking about the license, not the code.That is, if > > you come up with a new license, and claim it is liberal, but it takes > > too muchtime/effort/money/lawyer to read and interpret, then they > > reject it.They reject for example Apache 2.x. Thus they stick with > > Apache 1.x.I kind of wish they wouldn't stick with Apache 1.x, it > > seems "dangerous" to lingerback on "old" versions, but I understand > > the reason.I don't know if they stuck with gcc 3.x to avoid bloat or > > to avoid GPL 3. > > > > I don't think we have a choice in the licensing of what we add, > > parse.c in particular. I suspect parts of it are copied from the GPL > > gcc C front end. That is ok. > > And that restricts us from distributing parse.c other than under the > GPL. We can't dual-licence that bit. Is parse.c part of our modified > gcc back end? If so, yes, that is OK. > > -- hendrik From jay.krell at cornell.edu Mon Jul 5 14:56:23 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 12:56:23 +0000 Subject: [M3devel] loophole/copysign In-Reply-To: References: , , , , Message-ID: nope. I know this is gross, but how about we addd CG.make_volatile that front end can call very sparingly, that acts just like generating a call to setjmp or vfork -- in that it makes locals, parameters, temporaries in current function as volatile? CastExpr.m3 would call it for D_to_S and FloatType[src] # FloatType[dest]. It would be available as a desparate measure if we find other problems. To selectively inhibit optimization a function at a time. ? Which, granted, is generally overkill. I'm trying this now.. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: RE: [M3devel] loophole/copysign > Date: Mon, 5 Jul 2010 11:36:11 +0000 > > > another idea: let's not use bitfield ref for float/double > > - Jay > > > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Date: Mon, 5 Jul 2010 11:25:19 +0000 > > Subject: Re: [M3devel] loophole/copysign > > > > > > Hm. it seems that it might be important to preserve the "designatorness", like in: > > > > libm3/...RandomReal.m3: > > > > VAR frac, exp: INTEGER; result: LONGREAL; > > > > (* Repack as LONGREAL: *) > > WITH lr = LOOPHOLE (result, LongRealRep.T) DO > > lr.sign := 0; > > lr.exponent := exp; > > lr.significand0 := Word.Shift (Word.And (frac, 16_7fffffff), > > -(WordSize - 1 - FractionBits)); > > lr.significand1 := r.integer (min := -16_7fffffff-1, max :=16_7fffffff); > > END; > > > > > > - Jay > > > > ---------------------------------------- > > > From: jay.krell at cornell.edu > > > To: m3devel at elegosoft.com > > > Date: Mon, 5 Jul 2010 10:42:57 +0000 > > > Subject: Re: [M3devel] loophole/copysign > > > > > > > > > Tony, et. al.. in m3front/src/exprs/CastExpr.m3..what's the difference between a "designator" and a "value"? > > > > > > > > > http://www-plan.cs.colorado.edu/diwan/modula3/designators.html > > > > > > An identifier is a writable designator > > > if it is declared as a variable, > > > is a VAR or VALUE parameter, > > > is a local of a TYPECASE > > > or TRY EXCEPT statement, > > > or is a WITH local that is bound to a writable designator. > > > An identifier is a readonly designator if it is > > > a READONLY parameter, > > > a local of a FOR statement, > > > or a WITH local bound to a non-designator or > > > readonly designator. > > > > > > > > > > > > I guess a designator is what I would think of a "variable" or "read only variable"? > > > Something that either is "in memory" or can "reasonably" be put there? > > > > > > > > > 1 + 2 is not a designator. > > > > > > > > > Or, generally, a "variable", but that includes such similar things as parameters, "with variables", "for variables", "TYPECASE vairables", "TRY variables" > > > > > > > > > Anything with a name??? (not functions/modules/generics -- "named data") > > > > > > > > > Anyway, the next questions include: > > > > > > > > > In CastExpr.m3 would it be terrible and/or wrong to treat "designators" the same as "values"? > > > I realize, probably a deoptimization. > > > I think this lets the backend work. > > > > > > > > > And really, more to the point...shouldn't CastExpr.m3 use cg.loophole far more? > > > I haven't had much luck with that. I always get the cg stack out of balance or with the wrong types, even though it seems like it should be easy. > > > > > > > > > I have more testing to do, but classifying the loophole as V_to_S (value to structure) in place of D_to_S (designator to structure), at least if either side is one of the three float types, seems reasonable and correct, albeit slight deoptimization -- in unsafe code dealing with floating point..should be rare.. > > > > > > > > > - Jay > > > > > > > > > > > > ---------------------------------------- > > > > From: jay.krell at cornell.edu > > > > To: m3devel at elegosoft.com > > > > Date: Mon, 5 Jul 2010 09:24:20 +0000 > > > > Subject: [M3devel] loophole/copysign > > > > > > > > > > > > Our codegen is remarkably low level. That is, lower level earlier than C. > > > > > > > > > > > > gcc/m3cg -ftree-dump-all > > > > > > > > > > > > As early as LongFloat.mc.003t.original, the first file dumped, we have: > > > > > > > > LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) > > > > { > > > > xreel M3_CtKayy__result; > > > > xreel M3_CtKayy_res; > > > > > > > > xreel M3_CtKayy__result; > > > > xreel M3_CtKayy_res; > > > > M3_CtKayy_res = M3_CtKayy_x; > > > > BIT_FIELD_REF = (word_8) ((int_64) > > > > BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); > > > > = M3_CtKayy_res; > > > > return ; > > > > } > > > > > > > > compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: > > > > > > > > copy_sign_f (from, to) > > > > { > > > > float res; > > > > float D.1918; > > > > D.1917; > > > > struct float_t * from.1; > > > > struct float_t * res.0; > > > > > > > > : > > > > res = to_1; > > > > res.0_4 = (struct float_t *) &res; > > > > from.1_5 = (struct float_t *) &from; > > > > D.1917_6 = from.1_5->sign; > > > > res.0_4->sign = D.1917_6; > > > > D.1918_7 = res; > > > > return D.1918_7; > > > > > > > > } > > > > > > > > > > > > See, you know, from gcc's point of view, we don't have any records/structs/unions. > > > > Just integers and offsets from them mostly. > > > > > > > > > > > > The right fix is to build up types. > > > > That way also debugging with gdb will have a chance. > > > > Perhaps not a small amount of work. But maybe not too bad. > > > > > > > > > > > > For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. > > > > At least if one type but not the other is floating point. > > > > I don't know if that will work, but maybe. > > > > > > > > Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or > > > > store volatile. > > > > > > > > - Jay > > > > > > > > > > From hendrik at topoi.pooq.com Mon Jul 5 17:25:07 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 5 Jul 2010 11:25:07 -0400 Subject: [M3devel] licensing (gcc patches) In-Reply-To: References: <20100705123955.GC27490@topoi.pooq.com> Message-ID: <20100705152506.GE27490@topoi.pooq.com> On Mon, Jul 05, 2010 at 12:49:18PM +0000, Jay K wrote: > > Yes parse.c is a new file added to gcc and contains the bulk of our work on gcc. > There are some other small files and small diffs, but parse.c is really it. > > parse.c: the name seems wrong, but if you consider that from gcc's point of view, > we are a front end, then it makes sense. As a front end to gcc, our "source language" > is very odd, it is binary files encoding the sequence of function calls the "actual" > frontend would have me to an "actual" backend. I like that technique. It's similar to the intermediate code the coq proof checker produces after it's proved a theorem -- a file coding the sequence of calls to the elementary proof rules that turned out to be actually needed to get to the conclusion. It stores these files in a library, so it can read them in later and reprove the theorem quickly in case you need it again. It beats cryptographic signatures for security. I wonder if the FSF gang would look at parse.c differently if there were other compilers, GPLed ones, that use your back end. -- hendrik From dabenavidesd at yahoo.es Mon Jul 5 19:17:26 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 5 Jul 2010 17:17:26 +0000 (GMT) Subject: [M3devel] licensing (gcc patches) In-Reply-To: <20100705152506.GE27490@topoi.pooq.com> Message-ID: <495012.96539.qm@web23608.mail.ird.yahoo.com> Hi all: I think as is pointed out original developers copyright holders must be at the public domain as they are not present anymore and nobody seems to reclaim if there is any wanting to hold them as they don't have nobody who uses it as far as we know. So it probably needs to be a process of release of this holders to the public domain and especially the owners of the linked code would not regret having the hold as far as they return what they did to the originals which I believe don't or wouldn't hesitate to receive. If they do hesitate to receive they would be admitting they are not anymore owners of it and the changes would and shall be returned to somebody who will receive for them as to allow any wanting to do changes. I don't think FSF would accept to do that procedure. What shall we do then? --- El lun, 5/7/10, hendrik at topoi.pooq.com escribi?: > De: hendrik at topoi.pooq.com > Asunto: Re: [M3devel] licensing (gcc patches) > Para: m3devel at elegosoft.com > Fecha: lunes, 5 de julio, 2010 10:25 > On Mon, Jul 05, 2010 at 12:49:18PM > +0000, Jay K wrote: > > > > Yes parse.c is a new file added to gcc and contains > the bulk of our work on gcc. > > There are some other small files and small diffs, but > parse.c is really it. > > > > parse.c: the name seems wrong, but if you consider > that from gcc's point of view, > > we are a front end, then it makes sense. As a front > end to gcc, our "source language" > > is very odd, it is binary files encoding the sequence > of function calls the "actual" > > frontend would have me to an "actual" backend. > > I like that technique. It's similar to the > intermediate code the coq > proof checker produces after it's proved a theorem -- a > file > coding the sequence of calls to the elementary proof rules > that turned > out to be actually needed to get to the conclusion. > It stores these > files in a library, so it can read them in later and > reprove the theorem > quickly in case you need it again. It beats > cryptographic signatures > for security. > > I wonder if the FSF gang would look at parse.c differently > if there were > other compilers, GPLed ones, that use your back end. > > -- hendrik > From hosking at cs.purdue.edu Mon Jul 5 20:24:01 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 14:24:01 -0400 Subject: [M3devel] loophole/copysign In-Reply-To: References: Message-ID: <3267416E-1152-4A3D-A4C0-491F2C5FF74D@cs.purdue.edu> We shouldn't need a barrier here. That is for memory operations, whereas these need not be. I would hate to make this change. Why can't we produce gcc trees that accomplish what we need? On 5 Jul 2010, at 05:24, Jay K wrote: > > Our codegen is remarkably low level. That is, lower level earlier than C. > > > gcc/m3cg -ftree-dump-all > > > As early as LongFloat.mc.003t.original, the first file dumped, we have: > > LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) > { > xreel M3_CtKayy__result; > xreel M3_CtKayy_res; > > xreel M3_CtKayy__result; > xreel M3_CtKayy_res; > M3_CtKayy_res = M3_CtKayy_x; > BIT_FIELD_REF = (word_8) ((int_64) > BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); > = M3_CtKayy_res; > return ; > } > > compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: > > copy_sign_f (from, to) > { > float res; > float D.1918; > D.1917; > struct float_t * from.1; > struct float_t * res.0; > > : > res = to_1; > res.0_4 = (struct float_t *) &res; > from.1_5 = (struct float_t *) &from; > D.1917_6 = from.1_5->sign; > res.0_4->sign = D.1917_6; > D.1918_7 = res; > return D.1918_7; > > } > > > See, you know, from gcc's point of view, we don't have any records/structs/unions. > Just integers and offsets from them mostly. > > > The right fix is to build up types. > That way also debugging with gdb will have a chance. > Perhaps not a small amount of work. But maybe not too bad. > > > For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. > At least if one type but not the other is floating point. > I don't know if that will work, but maybe. > > Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or > store volatile. > > - Jay > From hosking at cs.purdue.edu Mon Jul 5 20:24:56 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 14:24:56 -0400 Subject: [M3devel] loophole/copysign In-Reply-To: References: Message-ID: <2F356C4B-5541-489B-B957-E3D295F549F5@cs.purdue.edu> A designator is something that can be assigned to as well as read from. It says nothing about it being in memory. A value cannot be assigned to. On 5 Jul 2010, at 06:42, Jay K wrote: > > Tony, et. al.. in m3front/src/exprs/CastExpr.m3..what's the difference between a "designator" and a "value"? > > > http://www-plan.cs.colorado.edu/diwan/modula3/designators.html > > An identifier is a writable designator > if it is declared as a variable, > is a VAR or VALUE parameter, > is a local of a TYPECASE > or TRY EXCEPT statement, > or is a WITH local that is bound to a writable designator. > An identifier is a readonly designator if it is > a READONLY parameter, > a local of a FOR statement, > or a WITH local bound to a non-designator or > readonly designator. > > > > I guess a designator is what I would think of a "variable" or "read only variable"? > Something that either is "in memory" or can "reasonably" be put there? > > > 1 + 2 is not a designator. > > > Or, generally, a "variable", but that includes such similar things as parameters, "with variables", "for variables", "TYPECASE vairables", "TRY variables" > > > Anything with a name??? (not functions/modules/generics -- "named data") > > > Anyway, the next questions include: > > > In CastExpr.m3 would it be terrible and/or wrong to treat "designators" the same as "values"? > I realize, probably a deoptimization. > I think this lets the backend work. > > > And really, more to the point...shouldn't CastExpr.m3 use cg.loophole far more? > I haven't had much luck with that. I always get the cg stack out of balance or with the wrong types, even though it seems like it should be easy. > > > I have more testing to do, but classifying the loophole as V_to_S (value to structure) in place of D_to_S (designator to structure), at least if either side is one of the three float types, seems reasonable and correct, albeit slight deoptimization -- in unsafe code dealing with floating point..should be rare.. > > > - Jay > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Date: Mon, 5 Jul 2010 09:24:20 +0000 >> Subject: [M3devel] loophole/copysign >> >> >> Our codegen is remarkably low level. That is, lower level earlier than C. >> >> >> gcc/m3cg -ftree-dump-all >> >> >> As early as LongFloat.mc.003t.original, the first file dumped, we have: >> >> LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) >> { >> xreel M3_CtKayy__result; >> xreel M3_CtKayy_res; >> >> xreel M3_CtKayy__result; >> xreel M3_CtKayy_res; >> M3_CtKayy_res = M3_CtKayy_x; >> BIT_FIELD_REF = (word_8) ((int_64) >> BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); >> = M3_CtKayy_res; >> return ; >> } >> >> compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: >> >> copy_sign_f (from, to) >> { >> float res; >> float D.1918; >> D.1917; >> struct float_t * from.1; >> struct float_t * res.0; >> >> : >> res = to_1; >> res.0_4 = (struct float_t *) &res; >> from.1_5 = (struct float_t *) &from; >> D.1917_6 = from.1_5->sign; >> res.0_4->sign = D.1917_6; >> D.1918_7 = res; >> return D.1918_7; >> >> } >> >> >> See, you know, from gcc's point of view, we don't have any records/structs/unions. >> Just integers and offsets from them mostly. >> >> >> The right fix is to build up types. >> That way also debugging with gdb will have a chance. >> Perhaps not a small amount of work. But maybe not too bad. >> >> >> For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. >> At least if one type but not the other is floating point. >> I don't know if that will work, but maybe. >> >> Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or >> store volatile. >> >> - Jay >> > From hosking at cs.purdue.edu Mon Jul 5 20:25:17 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 14:25:17 -0400 Subject: [M3devel] loophole/copysign In-Reply-To: References: , , , Message-ID: <01D93A8D-8D43-4D9A-A753-6B2D41C03F52@cs.purdue.edu> Yes, maybe that is the best way forward. On 5 Jul 2010, at 07:36, Jay K wrote: > > another idea: let's not use bitfield ref for float/double > > - Jay > > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Date: Mon, 5 Jul 2010 11:25:19 +0000 >> Subject: Re: [M3devel] loophole/copysign >> >> >> Hm. it seems that it might be important to preserve the "designatorness", like in: >> >> libm3/...RandomReal.m3: >> >> VAR frac, exp: INTEGER; result: LONGREAL; >> >> (* Repack as LONGREAL: *) >> WITH lr = LOOPHOLE (result, LongRealRep.T) DO >> lr.sign := 0; >> lr.exponent := exp; >> lr.significand0 := Word.Shift (Word.And (frac, 16_7fffffff), >> -(WordSize - 1 - FractionBits)); >> lr.significand1 := r.integer (min := -16_7fffffff-1, max :=16_7fffffff); >> END; >> >> >> - Jay >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: m3devel at elegosoft.com >>> Date: Mon, 5 Jul 2010 10:42:57 +0000 >>> Subject: Re: [M3devel] loophole/copysign >>> >>> >>> Tony, et. al.. in m3front/src/exprs/CastExpr.m3..what's the difference between a "designator" and a "value"? >>> >>> >>> http://www-plan.cs.colorado.edu/diwan/modula3/designators.html >>> >>> An identifier is a writable designator >>> if it is declared as a variable, >>> is a VAR or VALUE parameter, >>> is a local of a TYPECASE >>> or TRY EXCEPT statement, >>> or is a WITH local that is bound to a writable designator. >>> An identifier is a readonly designator if it is >>> a READONLY parameter, >>> a local of a FOR statement, >>> or a WITH local bound to a non-designator or >>> readonly designator. >>> >>> >>> >>> I guess a designator is what I would think of a "variable" or "read only variable"? >>> Something that either is "in memory" or can "reasonably" be put there? >>> >>> >>> 1 + 2 is not a designator. >>> >>> >>> Or, generally, a "variable", but that includes such similar things as parameters, "with variables", "for variables", "TYPECASE vairables", "TRY variables" >>> >>> >>> Anything with a name??? (not functions/modules/generics -- "named data") >>> >>> >>> Anyway, the next questions include: >>> >>> >>> In CastExpr.m3 would it be terrible and/or wrong to treat "designators" the same as "values"? >>> I realize, probably a deoptimization. >>> I think this lets the backend work. >>> >>> >>> And really, more to the point...shouldn't CastExpr.m3 use cg.loophole far more? >>> I haven't had much luck with that. I always get the cg stack out of balance or with the wrong types, even though it seems like it should be easy. >>> >>> >>> I have more testing to do, but classifying the loophole as V_to_S (value to structure) in place of D_to_S (designator to structure), at least if either side is one of the three float types, seems reasonable and correct, albeit slight deoptimization -- in unsafe code dealing with floating point..should be rare.. >>> >>> >>> - Jay >>> >>> >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: m3devel at elegosoft.com >>>> Date: Mon, 5 Jul 2010 09:24:20 +0000 >>>> Subject: [M3devel] loophole/copysign >>>> >>>> >>>> Our codegen is remarkably low level. That is, lower level earlier than C. >>>> >>>> >>>> gcc/m3cg -ftree-dump-all >>>> >>>> >>>> As early as LongFloat.mc.003t.original, the first file dumped, we have: >>>> >>>> LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) >>>> { >>>> xreel M3_CtKayy__result; >>>> xreel M3_CtKayy_res; >>>> >>>> xreel M3_CtKayy__result; >>>> xreel M3_CtKayy_res; >>>> M3_CtKayy_res = M3_CtKayy_x; >>>> BIT_FIELD_REF = (word_8) ((int_64) >>>> BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); >>>> = M3_CtKayy_res; >>>> return ; >>>> } >>>> >>>> compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: >>>> >>>> copy_sign_f (from, to) >>>> { >>>> float res; >>>> float D.1918; >>>> D.1917; >>>> struct float_t * from.1; >>>> struct float_t * res.0; >>>> >>>> : >>>> res = to_1; >>>> res.0_4 = (struct float_t *) &res; >>>> from.1_5 = (struct float_t *) &from; >>>> D.1917_6 = from.1_5->sign; >>>> res.0_4->sign = D.1917_6; >>>> D.1918_7 = res; >>>> return D.1918_7; >>>> >>>> } >>>> >>>> >>>> See, you know, from gcc's point of view, we don't have any records/structs/unions. >>>> Just integers and offsets from them mostly. >>>> >>>> >>>> The right fix is to build up types. >>>> That way also debugging with gdb will have a chance. >>>> Perhaps not a small amount of work. But maybe not too bad. >>>> >>>> >>>> For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. >>>> At least if one type but not the other is floating point. >>>> I don't know if that will work, but maybe. >>>> >>>> Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or >>>> store volatile. >>>> >>>> - Jay >>>> >>> >> > From hosking at cs.purdue.edu Mon Jul 5 20:25:33 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 14:25:33 -0400 Subject: [M3devel] loophole/copysign In-Reply-To: References: , Message-ID: <195E2A33-B6BD-4554-9FAD-47E0445FBB46@cs.purdue.edu> Indeed. On 5 Jul 2010, at 07:25, Jay K wrote: > > Hm. it seems that it might be important to preserve the "designatorness", like in: > > libm3/...RandomReal.m3: > > VAR frac, exp: INTEGER; result: LONGREAL; > > (* Repack as LONGREAL: *) > WITH lr = LOOPHOLE (result, LongRealRep.T) DO > lr.sign := 0; > lr.exponent := exp; > lr.significand0 := Word.Shift (Word.And (frac, 16_7fffffff), > -(WordSize - 1 - FractionBits)); > lr.significand1 := r.integer (min := -16_7fffffff-1, max :=16_7fffffff); > END; > > > - Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Date: Mon, 5 Jul 2010 10:42:57 +0000 >> Subject: Re: [M3devel] loophole/copysign >> >> >> Tony, et. al.. in m3front/src/exprs/CastExpr.m3..what's the difference between a "designator" and a "value"? >> >> >> http://www-plan.cs.colorado.edu/diwan/modula3/designators.html >> >> An identifier is a writable designator >> if it is declared as a variable, >> is a VAR or VALUE parameter, >> is a local of a TYPECASE >> or TRY EXCEPT statement, >> or is a WITH local that is bound to a writable designator. >> An identifier is a readonly designator if it is >> a READONLY parameter, >> a local of a FOR statement, >> or a WITH local bound to a non-designator or >> readonly designator. >> >> >> >> I guess a designator is what I would think of a "variable" or "read only variable"? >> Something that either is "in memory" or can "reasonably" be put there? >> >> >> 1 + 2 is not a designator. >> >> >> Or, generally, a "variable", but that includes such similar things as parameters, "with variables", "for variables", "TYPECASE vairables", "TRY variables" >> >> >> Anything with a name??? (not functions/modules/generics -- "named data") >> >> >> Anyway, the next questions include: >> >> >> In CastExpr.m3 would it be terrible and/or wrong to treat "designators" the same as "values"? >> I realize, probably a deoptimization. >> I think this lets the backend work. >> >> >> And really, more to the point...shouldn't CastExpr.m3 use cg.loophole far more? >> I haven't had much luck with that. I always get the cg stack out of balance or with the wrong types, even though it seems like it should be easy. >> >> >> I have more testing to do, but classifying the loophole as V_to_S (value to structure) in place of D_to_S (designator to structure), at least if either side is one of the three float types, seems reasonable and correct, albeit slight deoptimization -- in unsafe code dealing with floating point..should be rare.. >> >> >> - Jay >> >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: m3devel at elegosoft.com >>> Date: Mon, 5 Jul 2010 09:24:20 +0000 >>> Subject: [M3devel] loophole/copysign >>> >>> >>> Our codegen is remarkably low level. That is, lower level earlier than C. >>> >>> >>> gcc/m3cg -ftree-dump-all >>> >>> >>> As early as LongFloat.mc.003t.original, the first file dumped, we have: >>> >>> LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) >>> { >>> xreel M3_CtKayy__result; >>> xreel M3_CtKayy_res; >>> >>> xreel M3_CtKayy__result; >>> xreel M3_CtKayy_res; >>> M3_CtKayy_res = M3_CtKayy_x; >>> BIT_FIELD_REF = (word_8) ((int_64) >>> BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); >>> = M3_CtKayy_res; >>> return ; >>> } >>> >>> compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: >>> >>> copy_sign_f (from, to) >>> { >>> float res; >>> float D.1918; >>> D.1917; >>> struct float_t * from.1; >>> struct float_t * res.0; >>> >>> : >>> res = to_1; >>> res.0_4 = (struct float_t *) &res; >>> from.1_5 = (struct float_t *) &from; >>> D.1917_6 = from.1_5->sign; >>> res.0_4->sign = D.1917_6; >>> D.1918_7 = res; >>> return D.1918_7; >>> >>> } >>> >>> >>> See, you know, from gcc's point of view, we don't have any records/structs/unions. >>> Just integers and offsets from them mostly. >>> >>> >>> The right fix is to build up types. >>> That way also debugging with gdb will have a chance. >>> Perhaps not a small amount of work. But maybe not too bad. >>> >>> >>> For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. >>> At least if one type but not the other is floating point. >>> I don't know if that will work, but maybe. >>> >>> Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or >>> store volatile. >>> >>> - Jay >>> >> > From hosking at cs.purdue.edu Mon Jul 5 20:26:29 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 14:26:29 -0400 Subject: [M3devel] loophole/copysign In-Reply-To: References: , , , , Message-ID: We really don't want to do this. We need to figure out what needs to be generated as gcc trees. Perhaps an anonymous struct will suffice. On 5 Jul 2010, at 08:56, Jay K wrote: > > nope. > I know this is gross, but how about we addd CG.make_volatile that front end can call very sparingly, > that acts just like generating a call to setjmp or vfork -- in that it makes locals, parameters, temporaries > in current function as volatile? > > CastExpr.m3 would call it for D_to_S and FloatType[src] # FloatType[dest]. > > It would be available as a desparate measure if we find other problems. > To selectively inhibit optimization a function at a time. > Which, granted, is generally overkill. > > I'm trying this now.. > - Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Subject: RE: [M3devel] loophole/copysign >> Date: Mon, 5 Jul 2010 11:36:11 +0000 >> >> >> another idea: let's not use bitfield ref for float/double >> >> - Jay >> >> >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: m3devel at elegosoft.com >>> Date: Mon, 5 Jul 2010 11:25:19 +0000 >>> Subject: Re: [M3devel] loophole/copysign >>> >>> >>> Hm. it seems that it might be important to preserve the "designatorness", like in: >>> >>> libm3/...RandomReal.m3: >>> >>> VAR frac, exp: INTEGER; result: LONGREAL; >>> >>> (* Repack as LONGREAL: *) >>> WITH lr = LOOPHOLE (result, LongRealRep.T) DO >>> lr.sign := 0; >>> lr.exponent := exp; >>> lr.significand0 := Word.Shift (Word.And (frac, 16_7fffffff), >>> -(WordSize - 1 - FractionBits)); >>> lr.significand1 := r.integer (min := -16_7fffffff-1, max :=16_7fffffff); >>> END; >>> >>> >>> - Jay >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: m3devel at elegosoft.com >>>> Date: Mon, 5 Jul 2010 10:42:57 +0000 >>>> Subject: Re: [M3devel] loophole/copysign >>>> >>>> >>>> Tony, et. al.. in m3front/src/exprs/CastExpr.m3..what's the difference between a "designator" and a "value"? >>>> >>>> >>>> http://www-plan.cs.colorado.edu/diwan/modula3/designators.html >>>> >>>> An identifier is a writable designator >>>> if it is declared as a variable, >>>> is a VAR or VALUE parameter, >>>> is a local of a TYPECASE >>>> or TRY EXCEPT statement, >>>> or is a WITH local that is bound to a writable designator. >>>> An identifier is a readonly designator if it is >>>> a READONLY parameter, >>>> a local of a FOR statement, >>>> or a WITH local bound to a non-designator or >>>> readonly designator. >>>> >>>> >>>> >>>> I guess a designator is what I would think of a "variable" or "read only variable"? >>>> Something that either is "in memory" or can "reasonably" be put there? >>>> >>>> >>>> 1 + 2 is not a designator. >>>> >>>> >>>> Or, generally, a "variable", but that includes such similar things as parameters, "with variables", "for variables", "TYPECASE vairables", "TRY variables" >>>> >>>> >>>> Anything with a name??? (not functions/modules/generics -- "named data") >>>> >>>> >>>> Anyway, the next questions include: >>>> >>>> >>>> In CastExpr.m3 would it be terrible and/or wrong to treat "designators" the same as "values"? >>>> I realize, probably a deoptimization. >>>> I think this lets the backend work. >>>> >>>> >>>> And really, more to the point...shouldn't CastExpr.m3 use cg.loophole far more? >>>> I haven't had much luck with that. I always get the cg stack out of balance or with the wrong types, even though it seems like it should be easy. >>>> >>>> >>>> I have more testing to do, but classifying the loophole as V_to_S (value to structure) in place of D_to_S (designator to structure), at least if either side is one of the three float types, seems reasonable and correct, albeit slight deoptimization -- in unsafe code dealing with floating point..should be rare.. >>>> >>>> >>>> - Jay >>>> >>>> >>>> >>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: m3devel at elegosoft.com >>>>> Date: Mon, 5 Jul 2010 09:24:20 +0000 >>>>> Subject: [M3devel] loophole/copysign >>>>> >>>>> >>>>> Our codegen is remarkably low level. That is, lower level earlier than C. >>>>> >>>>> >>>>> gcc/m3cg -ftree-dump-all >>>>> >>>>> >>>>> As early as LongFloat.mc.003t.original, the first file dumped, we have: >>>>> >>>>> LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) >>>>> { >>>>> xreel M3_CtKayy__result; >>>>> xreel M3_CtKayy_res; >>>>> >>>>> xreel M3_CtKayy__result; >>>>> xreel M3_CtKayy_res; >>>>> M3_CtKayy_res = M3_CtKayy_x; >>>>> BIT_FIELD_REF = (word_8) ((int_64) >>>>> BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); >>>>> = M3_CtKayy_res; >>>>> return ; >>>>> } >>>>> >>>>> compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: >>>>> >>>>> copy_sign_f (from, to) >>>>> { >>>>> float res; >>>>> float D.1918; >>>>> D.1917; >>>>> struct float_t * from.1; >>>>> struct float_t * res.0; >>>>> >>>>> : >>>>> res = to_1; >>>>> res.0_4 = (struct float_t *) &res; >>>>> from.1_5 = (struct float_t *) &from; >>>>> D.1917_6 = from.1_5->sign; >>>>> res.0_4->sign = D.1917_6; >>>>> D.1918_7 = res; >>>>> return D.1918_7; >>>>> >>>>> } >>>>> >>>>> >>>>> See, you know, from gcc's point of view, we don't have any records/structs/unions. >>>>> Just integers and offsets from them mostly. >>>>> >>>>> >>>>> The right fix is to build up types. >>>>> That way also debugging with gdb will have a chance. >>>>> Perhaps not a small amount of work. But maybe not too bad. >>>>> >>>>> >>>>> For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. >>>>> At least if one type but not the other is floating point. >>>>> I don't know if that will work, but maybe. >>>>> >>>>> Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or >>>>> store volatile. >>>>> >>>>> - Jay >>>>> >>>> >>> >> > From jay.krell at cornell.edu Mon Jul 5 22:44:45 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 20:44:45 +0000 Subject: [M3devel] loophole/copysign In-Reply-To: <3267416E-1152-4A3D-A4C0-491F2C5FF74D@cs.purdue.edu> References: , <3267416E-1152-4A3D-A4C0-491F2C5FF74D@cs.purdue.edu> Message-ID: I don't think a barrier worked. The thing is, I don't think a change in parse.c alone can work. It isn't being given enough information. Or, well, it does have enough information, but, like, it is information it never uses. It has some type information. It would have to notice that the most recent store to a variable was of a different type than a load. ?- Jay ---------------------------------------- > Subject: Re: [M3devel] loophole/copysign > From: hosking at cs.purdue.edu > Date: Mon, 5 Jul 2010 14:24:01 -0400 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > We shouldn't need a barrier here. That is for memory operations, whereas these need not be. I would hate to make this change. Why can't we produce gcc trees that accomplish what we need? > > On 5 Jul 2010, at 05:24, Jay K wrote: > > > > > Our codegen is remarkably low level. That is, lower level earlier than C. > > > > > > gcc/m3cg -ftree-dump-all > > > > > > As early as LongFloat.mc.003t.original, the first file dumped, we have: > > > > LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) > > { > > xreel M3_CtKayy__result; > > xreel M3_CtKayy_res; > > > > xreel M3_CtKayy__result; > > xreel M3_CtKayy_res; > > M3_CtKayy_res = M3_CtKayy_x; > > BIT_FIELD_REF = (word_8) ((int_64) > > BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); > > = M3_CtKayy_res; > > return ; > > } > > > > compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: > > > > copy_sign_f (from, to) > > { > > float res; > > float D.1918; > > D.1917; > > struct float_t * from.1; > > struct float_t * res.0; > > > > : > > res = to_1; > > res.0_4 = (struct float_t *) &res; > > from.1_5 = (struct float_t *) &from; > > D.1917_6 = from.1_5->sign; > > res.0_4->sign = D.1917_6; > > D.1918_7 = res; > > return D.1918_7; > > > > } > > > > > > See, you know, from gcc's point of view, we don't have any records/structs/unions. > > Just integers and offsets from them mostly. > > > > > > The right fix is to build up types. > > That way also debugging with gdb will have a chance. > > Perhaps not a small amount of work. But maybe not too bad. > > > > > > For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. > > At least if one type but not the other is floating point. > > I don't know if that will work, but maybe. > > > > Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or > > store volatile. > > > > - Jay > > > From jay.krell at cornell.edu Mon Jul 5 22:49:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 20:49:14 +0000 Subject: [M3devel] loophole/copysign In-Reply-To: References: , , , , , , , , , Message-ID: The make_volatile idea seems to work. I agree it isn't great. I only inserted one call to it, for loophole + d_to_s + floattype src # dest. Let me know if attached is ok to commit. The front end all but needs to change here somehow, as the backend isn't being given much information -- no loophole call at all. Thanks, ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Mon, 5 Jul 2010 14:26:29 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] loophole/copysign > > We really don't want to do this. We need to figure out what needs to be generated as gcc trees. Perhaps an anonymous struct will suffice. > > > On 5 Jul 2010, at 08:56, Jay K wrote: > > > > > nope. > > I know this is gross, but how about we addd CG.make_volatile that front end can call very sparingly, > > that acts just like generating a call to setjmp or vfork -- in that it makes locals, parameters, temporaries > > in current function as volatile? > > > > CastExpr.m3 would call it for D_to_S and FloatType[src] # FloatType[dest]. > > > > It would be available as a desparate measure if we find other problems. > > To selectively inhibit optimization a function at a time. > > Which, granted, is generally overkill. > > > > I'm trying this now.. > > - Jay > > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: m3devel at elegosoft.com > >> Subject: RE: [M3devel] loophole/copysign > >> Date: Mon, 5 Jul 2010 11:36:11 +0000 > >> > >> > >> another idea: let's not use bitfield ref for float/double > >> > >> - Jay > >> > >> > >> > >> ---------------------------------------- > >>> From: jay.krell at cornell.edu > >>> To: m3devel at elegosoft.com > >>> Date: Mon, 5 Jul 2010 11:25:19 +0000 > >>> Subject: Re: [M3devel] loophole/copysign > >>> > >>> > >>> Hm. it seems that it might be important to preserve the "designatorness", like in: > >>> > >>> libm3/...RandomReal.m3: > >>> > >>> VAR frac, exp: INTEGER; result: LONGREAL; > >>> > >>> (* Repack as LONGREAL: *) > >>> WITH lr = LOOPHOLE (result, LongRealRep.T) DO > >>> lr.sign := 0; > >>> lr.exponent := exp; > >>> lr.significand0 := Word.Shift (Word.And (frac, 16_7fffffff), > >>> -(WordSize - 1 - FractionBits)); > >>> lr.significand1 := r.integer (min := -16_7fffffff-1, max :=16_7fffffff); > >>> END; > >>> > >>> > >>> - Jay > >>> > >>> ---------------------------------------- > >>>> From: jay.krell at cornell.edu > >>>> To: m3devel at elegosoft.com > >>>> Date: Mon, 5 Jul 2010 10:42:57 +0000 > >>>> Subject: Re: [M3devel] loophole/copysign > >>>> > >>>> > >>>> Tony, et. al.. in m3front/src/exprs/CastExpr.m3..what's the difference between a "designator" and a "value"? > >>>> > >>>> > >>>> http://www-plan.cs.colorado.edu/diwan/modula3/designators.html > >>>> > >>>> An identifier is a writable designator > >>>> if it is declared as a variable, > >>>> is a VAR or VALUE parameter, > >>>> is a local of a TYPECASE > >>>> or TRY EXCEPT statement, > >>>> or is a WITH local that is bound to a writable designator. > >>>> An identifier is a readonly designator if it is > >>>> a READONLY parameter, > >>>> a local of a FOR statement, > >>>> or a WITH local bound to a non-designator or > >>>> readonly designator. > >>>> > >>>> > >>>> > >>>> I guess a designator is what I would think of a "variable" or "read only variable"? > >>>> Something that either is "in memory" or can "reasonably" be put there? > >>>> > >>>> > >>>> 1 + 2 is not a designator. > >>>> > >>>> > >>>> Or, generally, a "variable", but that includes such similar things as parameters, "with variables", "for variables", "TYPECASE vairables", "TRY variables" > >>>> > >>>> > >>>> Anything with a name??? (not functions/modules/generics -- "named data") > >>>> > >>>> > >>>> Anyway, the next questions include: > >>>> > >>>> > >>>> In CastExpr.m3 would it be terrible and/or wrong to treat "designators" the same as "values"? > >>>> I realize, probably a deoptimization. > >>>> I think this lets the backend work. > >>>> > >>>> > >>>> And really, more to the point...shouldn't CastExpr.m3 use cg.loophole far more? > >>>> I haven't had much luck with that. I always get the cg stack out of balance or with the wrong types, even though it seems like it should be easy. > >>>> > >>>> > >>>> I have more testing to do, but classifying the loophole as V_to_S (value to structure) in place of D_to_S (designator to structure), at least if either side is one of the three float types, seems reasonable and correct, albeit slight deoptimization -- in unsafe code dealing with floating point..should be rare.. > >>>> > >>>> > >>>> - Jay > >>>> > >>>> > >>>> > >>>> ---------------------------------------- > >>>>> From: jay.krell at cornell.edu > >>>>> To: m3devel at elegosoft.com > >>>>> Date: Mon, 5 Jul 2010 09:24:20 +0000 > >>>>> Subject: [M3devel] loophole/copysign > >>>>> > >>>>> > >>>>> Our codegen is remarkably low level. That is, lower level earlier than C. > >>>>> > >>>>> > >>>>> gcc/m3cg -ftree-dump-all > >>>>> > >>>>> > >>>>> As early as LongFloat.mc.003t.original, the first file dumped, we have: > >>>>> > >>>>> LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) > >>>>> { > >>>>> xreel M3_CtKayy__result; > >>>>> xreel M3_CtKayy_res; > >>>>> > >>>>> xreel M3_CtKayy__result; > >>>>> xreel M3_CtKayy_res; > >>>>> M3_CtKayy_res = M3_CtKayy_x; > >>>>> BIT_FIELD_REF = (word_8) ((int_64) > >>>>> BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); > >>>>> = M3_CtKayy_res; > >>>>> return ; > >>>>> } > >>>>> > >>>>> compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: > >>>>> > >>>>> copy_sign_f (from, to) > >>>>> { > >>>>> float res; > >>>>> float D.1918; > >>>>> D.1917; > >>>>> struct float_t * from.1; > >>>>> struct float_t * res.0; > >>>>> > >>>>> : > >>>>> res = to_1; > >>>>> res.0_4 = (struct float_t *) &res; > >>>>> from.1_5 = (struct float_t *) &from; > >>>>> D.1917_6 = from.1_5->sign; > >>>>> res.0_4->sign = D.1917_6; > >>>>> D.1918_7 = res; > >>>>> return D.1918_7; > >>>>> > >>>>> } > >>>>> > >>>>> > >>>>> See, you know, from gcc's point of view, we don't have any records/structs/unions. > >>>>> Just integers and offsets from them mostly. > >>>>> > >>>>> > >>>>> The right fix is to build up types. > >>>>> That way also debugging with gdb will have a chance. > >>>>> Perhaps not a small amount of work. But maybe not too bad. > >>>>> > >>>>> > >>>>> For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. > >>>>> At least if one type but not the other is floating point. > >>>>> I don't know if that will work, but maybe. > >>>>> > >>>>> Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or > >>>>> store volatile. > >>>>> > >>>>> - Jay > >>>>> > >>>> > >>> > >> > > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: volatile.txt URL: From jay.krell at cornell.edu Mon Jul 5 22:51:25 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 20:51:25 +0000 Subject: [M3devel] loophole/copysign In-Reply-To: <01D93A8D-8D43-4D9A-A753-6B2D41C03F52@cs.purdue.edu> References: , , , , , , , <01D93A8D-8D43-4D9A-A753-6B2D41C03F52@cs.purdue.edu> Message-ID: I think this is still a good idea but I don't think relevant here. There's no offset or type mismatch to trigger that path, in this code, I'm pretty sure. I think a temporary would still work, in the "LV" D_to_S variant. But a temporary is wrong for the non-LV case, due the need to preserve writes to the original. But I didn't read through how the compiler choses LV or not-LV so not yet keen on making that sort of change. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Mon, 5 Jul 2010 14:25:17 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] loophole/copysign > > Yes, maybe that is the best way forward. > > On 5 Jul 2010, at 07:36, Jay K wrote: > > > > > another idea: let's not use bitfield ref for float/double > > > > - Jay > > > > > > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: m3devel at elegosoft.com > >> Date: Mon, 5 Jul 2010 11:25:19 +0000 > >> Subject: Re: [M3devel] loophole/copysign > >> > >> > >> Hm. it seems that it might be important to preserve the "designatorness", like in: > >> > >> libm3/...RandomReal.m3: > >> > >> VAR frac, exp: INTEGER; result: LONGREAL; > >> > >> (* Repack as LONGREAL: *) > >> WITH lr = LOOPHOLE (result, LongRealRep.T) DO > >> lr.sign := 0; > >> lr.exponent := exp; > >> lr.significand0 := Word.Shift (Word.And (frac, 16_7fffffff), > >> -(WordSize - 1 - FractionBits)); > >> lr.significand1 := r.integer (min := -16_7fffffff-1, max :=16_7fffffff); > >> END; > >> > >> > >> - Jay > >> > >> ---------------------------------------- > >>> From: jay.krell at cornell.edu > >>> To: m3devel at elegosoft.com > >>> Date: Mon, 5 Jul 2010 10:42:57 +0000 > >>> Subject: Re: [M3devel] loophole/copysign > >>> > >>> > >>> Tony, et. al.. in m3front/src/exprs/CastExpr.m3..what's the difference between a "designator" and a "value"? > >>> > >>> > >>> http://www-plan.cs.colorado.edu/diwan/modula3/designators.html > >>> > >>> An identifier is a writable designator > >>> if it is declared as a variable, > >>> is a VAR or VALUE parameter, > >>> is a local of a TYPECASE > >>> or TRY EXCEPT statement, > >>> or is a WITH local that is bound to a writable designator. > >>> An identifier is a readonly designator if it is > >>> a READONLY parameter, > >>> a local of a FOR statement, > >>> or a WITH local bound to a non-designator or > >>> readonly designator. > >>> > >>> > >>> > >>> I guess a designator is what I would think of a "variable" or "read only variable"? > >>> Something that either is "in memory" or can "reasonably" be put there? > >>> > >>> > >>> 1 + 2 is not a designator. > >>> > >>> > >>> Or, generally, a "variable", but that includes such similar things as parameters, "with variables", "for variables", "TYPECASE vairables", "TRY variables" > >>> > >>> > >>> Anything with a name??? (not functions/modules/generics -- "named data") > >>> > >>> > >>> Anyway, the next questions include: > >>> > >>> > >>> In CastExpr.m3 would it be terrible and/or wrong to treat "designators" the same as "values"? > >>> I realize, probably a deoptimization. > >>> I think this lets the backend work. > >>> > >>> > >>> And really, more to the point...shouldn't CastExpr.m3 use cg.loophole far more? > >>> I haven't had much luck with that. I always get the cg stack out of balance or with the wrong types, even though it seems like it should be easy. > >>> > >>> > >>> I have more testing to do, but classifying the loophole as V_to_S (value to structure) in place of D_to_S (designator to structure), at least if either side is one of the three float types, seems reasonable and correct, albeit slight deoptimization -- in unsafe code dealing with floating point..should be rare.. > >>> > >>> > >>> - Jay > >>> > >>> > >>> > >>> ---------------------------------------- > >>>> From: jay.krell at cornell.edu > >>>> To: m3devel at elegosoft.com > >>>> Date: Mon, 5 Jul 2010 09:24:20 +0000 > >>>> Subject: [M3devel] loophole/copysign > >>>> > >>>> > >>>> Our codegen is remarkably low level. That is, lower level earlier than C. > >>>> > >>>> > >>>> gcc/m3cg -ftree-dump-all > >>>> > >>>> > >>>> As early as LongFloat.mc.003t.original, the first file dumped, we have: > >>>> > >>>> LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) > >>>> { > >>>> xreel M3_CtKayy__result; > >>>> xreel M3_CtKayy_res; > >>>> > >>>> xreel M3_CtKayy__result; > >>>> xreel M3_CtKayy_res; > >>>> M3_CtKayy_res = M3_CtKayy_x; > >>>> BIT_FIELD_REF = (word_8) ((int_64) > >>>> BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); > >>>> = M3_CtKayy_res; > >>>> return ; > >>>> } > >>>> > >>>> compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: > >>>> > >>>> copy_sign_f (from, to) > >>>> { > >>>> float res; > >>>> float D.1918; > >>>> D.1917; > >>>> struct float_t * from.1; > >>>> struct float_t * res.0; > >>>> > >>>> : > >>>> res = to_1; > >>>> res.0_4 = (struct float_t *) &res; > >>>> from.1_5 = (struct float_t *) &from; > >>>> D.1917_6 = from.1_5->sign; > >>>> res.0_4->sign = D.1917_6; > >>>> D.1918_7 = res; > >>>> return D.1918_7; > >>>> > >>>> } > >>>> > >>>> > >>>> See, you know, from gcc's point of view, we don't have any records/structs/unions. > >>>> Just integers and offsets from them mostly. > >>>> > >>>> > >>>> The right fix is to build up types. > >>>> That way also debugging with gdb will have a chance. > >>>> Perhaps not a small amount of work. But maybe not too bad. > >>>> > >>>> > >>>> For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. > >>>> At least if one type but not the other is floating point. > >>>> I don't know if that will work, but maybe. > >>>> > >>>> Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or > >>>> store volatile. > >>>> > >>>> - Jay > >>>> > >>> > >> > > > From hosking at cs.purdue.edu Mon Jul 5 23:32:44 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 17:32:44 -0400 Subject: [M3devel] loophole/copysign In-Reply-To: References: , , , , , , , , , Message-ID: <19A59BEE-60F0-4A37-8FF8-69FBC74AB153@cs.purdue.edu> Are you saying that conversion of floats is not generating a loophole? The volatilise idea is overkill, and I don't want to see it contaminate the M3CG interfaces. Can you point me at the problematic code in CastExpr? On 5 Jul 2010, at 16:49, Jay K wrote: > > The make_volatile idea seems to work. I agree it isn't great. I only inserted one call to it, for loophole + d_to_s + floattype src # dest. > Let me know if attached is ok to commit. > The front end all but needs to change here somehow, as the backend isn't being given much information -- no loophole call at all. > > Thanks, > - Jay > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Mon, 5 Jul 2010 14:26:29 -0400 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] loophole/copysign >> >> We really don't want to do this. We need to figure out what needs to be generated as gcc trees. Perhaps an anonymous struct will suffice. >> >> >> On 5 Jul 2010, at 08:56, Jay K wrote: >> >>> >>> nope. >>> I know this is gross, but how about we addd CG.make_volatile that front end can call very sparingly, >>> that acts just like generating a call to setjmp or vfork -- in that it makes locals, parameters, temporaries >>> in current function as volatile? >>> >>> CastExpr.m3 would call it for D_to_S and FloatType[src] # FloatType[dest]. >>> >>> It would be available as a desparate measure if we find other problems. >>> To selectively inhibit optimization a function at a time. >>> Which, granted, is generally overkill. >>> >>> I'm trying this now.. >>> - Jay >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: m3devel at elegosoft.com >>>> Subject: RE: [M3devel] loophole/copysign >>>> Date: Mon, 5 Jul 2010 11:36:11 +0000 >>>> >>>> >>>> another idea: let's not use bitfield ref for float/double >>>> >>>> - Jay >>>> >>>> >>>> >>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: m3devel at elegosoft.com >>>>> Date: Mon, 5 Jul 2010 11:25:19 +0000 >>>>> Subject: Re: [M3devel] loophole/copysign >>>>> >>>>> >>>>> Hm. it seems that it might be important to preserve the "designatorness", like in: >>>>> >>>>> libm3/...RandomReal.m3: >>>>> >>>>> VAR frac, exp: INTEGER; result: LONGREAL; >>>>> >>>>> (* Repack as LONGREAL: *) >>>>> WITH lr = LOOPHOLE (result, LongRealRep.T) DO >>>>> lr.sign := 0; >>>>> lr.exponent := exp; >>>>> lr.significand0 := Word.Shift (Word.And (frac, 16_7fffffff), >>>>> -(WordSize - 1 - FractionBits)); >>>>> lr.significand1 := r.integer (min := -16_7fffffff-1, max :=16_7fffffff); >>>>> END; >>>>> >>>>> >>>>> - Jay >>>>> >>>>> ---------------------------------------- >>>>>> From: jay.krell at cornell.edu >>>>>> To: m3devel at elegosoft.com >>>>>> Date: Mon, 5 Jul 2010 10:42:57 +0000 >>>>>> Subject: Re: [M3devel] loophole/copysign >>>>>> >>>>>> >>>>>> Tony, et. al.. in m3front/src/exprs/CastExpr.m3..what's the difference between a "designator" and a "value"? >>>>>> >>>>>> >>>>>> http://www-plan.cs.colorado.edu/diwan/modula3/designators.html >>>>>> >>>>>> An identifier is a writable designator >>>>>> if it is declared as a variable, >>>>>> is a VAR or VALUE parameter, >>>>>> is a local of a TYPECASE >>>>>> or TRY EXCEPT statement, >>>>>> or is a WITH local that is bound to a writable designator. >>>>>> An identifier is a readonly designator if it is >>>>>> a READONLY parameter, >>>>>> a local of a FOR statement, >>>>>> or a WITH local bound to a non-designator or >>>>>> readonly designator. >>>>>> >>>>>> >>>>>> >>>>>> I guess a designator is what I would think of a "variable" or "read only variable"? >>>>>> Something that either is "in memory" or can "reasonably" be put there? >>>>>> >>>>>> >>>>>> 1 + 2 is not a designator. >>>>>> >>>>>> >>>>>> Or, generally, a "variable", but that includes such similar things as parameters, "with variables", "for variables", "TYPECASE vairables", "TRY variables" >>>>>> >>>>>> >>>>>> Anything with a name??? (not functions/modules/generics -- "named data") >>>>>> >>>>>> >>>>>> Anyway, the next questions include: >>>>>> >>>>>> >>>>>> In CastExpr.m3 would it be terrible and/or wrong to treat "designators" the same as "values"? >>>>>> I realize, probably a deoptimization. >>>>>> I think this lets the backend work. >>>>>> >>>>>> >>>>>> And really, more to the point...shouldn't CastExpr.m3 use cg.loophole far more? >>>>>> I haven't had much luck with that. I always get the cg stack out of balance or with the wrong types, even though it seems like it should be easy. >>>>>> >>>>>> >>>>>> I have more testing to do, but classifying the loophole as V_to_S (value to structure) in place of D_to_S (designator to structure), at least if either side is one of the three float types, seems reasonable and correct, albeit slight deoptimization -- in unsafe code dealing with floating point..should be rare.. >>>>>> >>>>>> >>>>>> - Jay >>>>>> >>>>>> >>>>>> >>>>>> ---------------------------------------- >>>>>>> From: jay.krell at cornell.edu >>>>>>> To: m3devel at elegosoft.com >>>>>>> Date: Mon, 5 Jul 2010 09:24:20 +0000 >>>>>>> Subject: [M3devel] loophole/copysign >>>>>>> >>>>>>> >>>>>>> Our codegen is remarkably low level. That is, lower level earlier than C. >>>>>>> >>>>>>> >>>>>>> gcc/m3cg -ftree-dump-all >>>>>>> >>>>>>> >>>>>>> As early as LongFloat.mc.003t.original, the first file dumped, we have: >>>>>>> >>>>>>> LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) >>>>>>> { >>>>>>> xreel M3_CtKayy__result; >>>>>>> xreel M3_CtKayy_res; >>>>>>> >>>>>>> xreel M3_CtKayy__result; >>>>>>> xreel M3_CtKayy_res; >>>>>>> M3_CtKayy_res = M3_CtKayy_x; >>>>>>> BIT_FIELD_REF = (word_8) ((int_64) >>>>>>> BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); >>>>>>> = M3_CtKayy_res; >>>>>>> return ; >>>>>>> } >>>>>>> >>>>>>> compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: >>>>>>> >>>>>>> copy_sign_f (from, to) >>>>>>> { >>>>>>> float res; >>>>>>> float D.1918; >>>>>>> D.1917; >>>>>>> struct float_t * from.1; >>>>>>> struct float_t * res.0; >>>>>>> >>>>>>> : >>>>>>> res = to_1; >>>>>>> res.0_4 = (struct float_t *) &res; >>>>>>> from.1_5 = (struct float_t *) &from; >>>>>>> D.1917_6 = from.1_5->sign; >>>>>>> res.0_4->sign = D.1917_6; >>>>>>> D.1918_7 = res; >>>>>>> return D.1918_7; >>>>>>> >>>>>>> } >>>>>>> >>>>>>> >>>>>>> See, you know, from gcc's point of view, we don't have any records/structs/unions. >>>>>>> Just integers and offsets from them mostly. >>>>>>> >>>>>>> >>>>>>> The right fix is to build up types. >>>>>>> That way also debugging with gdb will have a chance. >>>>>>> Perhaps not a small amount of work. But maybe not too bad. >>>>>>> >>>>>>> >>>>>>> For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. >>>>>>> At least if one type but not the other is floating point. >>>>>>> I don't know if that will work, but maybe. >>>>>>> >>>>>>> Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or >>>>>>> store volatile. >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>> >>>>> >>>> >>> >> > From hosking at cs.purdue.edu Mon Jul 5 23:34:20 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 17:34:20 -0400 Subject: [M3devel] loophole/copysign In-Reply-To: References: , , , , , , , <01D93A8D-8D43-4D9A-A753-6B2D41C03F52@cs.purdue.edu> Message-ID: None of this is making much sense to me... On 5 Jul 2010, at 16:51, Jay K wrote: > > I think this is still a good idea but I don't think relevant here. > There's no offset or type mismatch to trigger that path, in this code, I'm pretty sure. > > I think a temporary would still work, in the "LV" D_to_S variant. > But a temporary is wrong for the non-LV case, due the need to preserve writes to the original. > But I didn't read through how the compiler choses LV or not-LV so not yet keen on making that sort of change. > > - Jay > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Mon, 5 Jul 2010 14:25:17 -0400 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] loophole/copysign >> >> Yes, maybe that is the best way forward. >> >> On 5 Jul 2010, at 07:36, Jay K wrote: >> >>> >>> another idea: let's not use bitfield ref for float/double >>> >>> - Jay >>> >>> >>> >>> ---------------------------------------- >>>> From: jay.krell at cornell.edu >>>> To: m3devel at elegosoft.com >>>> Date: Mon, 5 Jul 2010 11:25:19 +0000 >>>> Subject: Re: [M3devel] loophole/copysign >>>> >>>> >>>> Hm. it seems that it might be important to preserve the "designatorness", like in: >>>> >>>> libm3/...RandomReal.m3: >>>> >>>> VAR frac, exp: INTEGER; result: LONGREAL; >>>> >>>> (* Repack as LONGREAL: *) >>>> WITH lr = LOOPHOLE (result, LongRealRep.T) DO >>>> lr.sign := 0; >>>> lr.exponent := exp; >>>> lr.significand0 := Word.Shift (Word.And (frac, 16_7fffffff), >>>> -(WordSize - 1 - FractionBits)); >>>> lr.significand1 := r.integer (min := -16_7fffffff-1, max :=16_7fffffff); >>>> END; >>>> >>>> >>>> - Jay >>>> >>>> ---------------------------------------- >>>>> From: jay.krell at cornell.edu >>>>> To: m3devel at elegosoft.com >>>>> Date: Mon, 5 Jul 2010 10:42:57 +0000 >>>>> Subject: Re: [M3devel] loophole/copysign >>>>> >>>>> >>>>> Tony, et. al.. in m3front/src/exprs/CastExpr.m3..what's the difference between a "designator" and a "value"? >>>>> >>>>> >>>>> http://www-plan.cs.colorado.edu/diwan/modula3/designators.html >>>>> >>>>> An identifier is a writable designator >>>>> if it is declared as a variable, >>>>> is a VAR or VALUE parameter, >>>>> is a local of a TYPECASE >>>>> or TRY EXCEPT statement, >>>>> or is a WITH local that is bound to a writable designator. >>>>> An identifier is a readonly designator if it is >>>>> a READONLY parameter, >>>>> a local of a FOR statement, >>>>> or a WITH local bound to a non-designator or >>>>> readonly designator. >>>>> >>>>> >>>>> >>>>> I guess a designator is what I would think of a "variable" or "read only variable"? >>>>> Something that either is "in memory" or can "reasonably" be put there? >>>>> >>>>> >>>>> 1 + 2 is not a designator. >>>>> >>>>> >>>>> Or, generally, a "variable", but that includes such similar things as parameters, "with variables", "for variables", "TYPECASE vairables", "TRY variables" >>>>> >>>>> >>>>> Anything with a name??? (not functions/modules/generics -- "named data") >>>>> >>>>> >>>>> Anyway, the next questions include: >>>>> >>>>> >>>>> In CastExpr.m3 would it be terrible and/or wrong to treat "designators" the same as "values"? >>>>> I realize, probably a deoptimization. >>>>> I think this lets the backend work. >>>>> >>>>> >>>>> And really, more to the point...shouldn't CastExpr.m3 use cg.loophole far more? >>>>> I haven't had much luck with that. I always get the cg stack out of balance or with the wrong types, even though it seems like it should be easy. >>>>> >>>>> >>>>> I have more testing to do, but classifying the loophole as V_to_S (value to structure) in place of D_to_S (designator to structure), at least if either side is one of the three float types, seems reasonable and correct, albeit slight deoptimization -- in unsafe code dealing with floating point..should be rare.. >>>>> >>>>> >>>>> - Jay >>>>> >>>>> >>>>> >>>>> ---------------------------------------- >>>>>> From: jay.krell at cornell.edu >>>>>> To: m3devel at elegosoft.com >>>>>> Date: Mon, 5 Jul 2010 09:24:20 +0000 >>>>>> Subject: [M3devel] loophole/copysign >>>>>> >>>>>> >>>>>> Our codegen is remarkably low level. That is, lower level earlier than C. >>>>>> >>>>>> >>>>>> gcc/m3cg -ftree-dump-all >>>>>> >>>>>> >>>>>> As early as LongFloat.mc.003t.original, the first file dumped, we have: >>>>>> >>>>>> LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) >>>>>> { >>>>>> xreel M3_CtKayy__result; >>>>>> xreel M3_CtKayy_res; >>>>>> >>>>>> xreel M3_CtKayy__result; >>>>>> xreel M3_CtKayy_res; >>>>>> M3_CtKayy_res = M3_CtKayy_x; >>>>>> BIT_FIELD_REF = (word_8) ((int_64) >>>>>> BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); >>>>>> = M3_CtKayy_res; >>>>>> return ; >>>>>> } >>>>>> >>>>>> compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: >>>>>> >>>>>> copy_sign_f (from, to) >>>>>> { >>>>>> float res; >>>>>> float D.1918; >>>>>> D.1917; >>>>>> struct float_t * from.1; >>>>>> struct float_t * res.0; >>>>>> >>>>>> : >>>>>> res = to_1; >>>>>> res.0_4 = (struct float_t *) &res; >>>>>> from.1_5 = (struct float_t *) &from; >>>>>> D.1917_6 = from.1_5->sign; >>>>>> res.0_4->sign = D.1917_6; >>>>>> D.1918_7 = res; >>>>>> return D.1918_7; >>>>>> >>>>>> } >>>>>> >>>>>> >>>>>> See, you know, from gcc's point of view, we don't have any records/structs/unions. >>>>>> Just integers and offsets from them mostly. >>>>>> >>>>>> >>>>>> The right fix is to build up types. >>>>>> That way also debugging with gdb will have a chance. >>>>>> Perhaps not a small amount of work. But maybe not too bad. >>>>>> >>>>>> >>>>>> For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. >>>>>> At least if one type but not the other is floating point. >>>>>> I don't know if that will work, but maybe. >>>>>> >>>>>> Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or >>>>>> store volatile. >>>>>> >>>>>> - Jay >>>>>> >>>>> >>>> >>> >> > From hosking at cs.purdue.edu Mon Jul 5 23:33:43 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 17:33:43 -0400 Subject: [M3devel] loophole/copysign In-Reply-To: References: , <3267416E-1152-4A3D-A4C0-491F2C5FF74D@cs.purdue.edu> Message-ID: <6BF4E7E7-1068-4623-AE86-6687E2B7B385@cs.purdue.edu> Surely we should instead give it the type conversion from what was stored to what is loaded. Can you point me at the problem code in CastExpr? On 5 Jul 2010, at 16:44, Jay K wrote: > > I don't think a barrier worked. > The thing is, I don't think a change in parse.c alone can work. It isn't being given enough information. > Or, well, it does have enough information, but, like, it is information it never uses. > It has some type information. It would have to notice that the most recent store to a variable was > of a different type than a load. > > - Jay > > > > ---------------------------------------- >> Subject: Re: [M3devel] loophole/copysign >> From: hosking at cs.purdue.edu >> Date: Mon, 5 Jul 2010 14:24:01 -0400 >> CC: m3devel at elegosoft.com >> To: jay.krell at cornell.edu >> >> We shouldn't need a barrier here. That is for memory operations, whereas these need not be. I would hate to make this change. Why can't we produce gcc trees that accomplish what we need? >> >> On 5 Jul 2010, at 05:24, Jay K wrote: >> >>> >>> Our codegen is remarkably low level. That is, lower level earlier than C. >>> >>> >>> gcc/m3cg -ftree-dump-all >>> >>> >>> As early as LongFloat.mc.003t.original, the first file dumped, we have: >>> >>> LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) >>> { >>> xreel M3_CtKayy__result; >>> xreel M3_CtKayy_res; >>> >>> xreel M3_CtKayy__result; >>> xreel M3_CtKayy_res; >>> M3_CtKayy_res = M3_CtKayy_x; >>> BIT_FIELD_REF = (word_8) ((int_64) >>> BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); >>> = M3_CtKayy_res; >>> return ; >>> } >>> >>> compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: >>> >>> copy_sign_f (from, to) >>> { >>> float res; >>> float D.1918; >>> D.1917; >>> struct float_t * from.1; >>> struct float_t * res.0; >>> >>> : >>> res = to_1; >>> res.0_4 = (struct float_t *) &res; >>> from.1_5 = (struct float_t *) &from; >>> D.1917_6 = from.1_5->sign; >>> res.0_4->sign = D.1917_6; >>> D.1918_7 = res; >>> return D.1918_7; >>> >>> } >>> >>> >>> See, you know, from gcc's point of view, we don't have any records/structs/unions. >>> Just integers and offsets from them mostly. >>> >>> >>> The right fix is to build up types. >>> That way also debugging with gdb will have a chance. >>> Perhaps not a small amount of work. But maybe not too bad. >>> >>> >>> For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. >>> At least if one type but not the other is floating point. >>> I don't know if that will work, but maybe. >>> >>> Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or >>> store volatile. >>> >>> - Jay >>> >> > From jay.krell at cornell.edu Mon Jul 5 23:42:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 21:42:43 +0000 Subject: [M3devel] loophole/copysign In-Reply-To: <6BF4E7E7-1068-4623-AE86-6687E2B7B385@cs.purdue.edu> References: , , <3267416E-1152-4A3D-A4C0-491F2C5FF74D@cs.purdue.edu>, , <6BF4E7E7-1068-4623-AE86-6687E2B7B385@cs.purdue.edu> Message-ID: CastExpr.m3 has precious few calls to CG.Loophole, including none for this case. cm3cg -y output for m3core/LongReal.mc CopySign has no calls to loophole. We store into a local as one type and read it back as another type. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Mon, 5 Jul 2010 17:33:43 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] loophole/copysign > > Surely we should instead give it the type conversion from what was stored to what is loaded. Can you point me at the problem code in CastExpr? > > On 5 Jul 2010, at 16:44, Jay K wrote: > > > > > I don't think a barrier worked. > > The thing is, I don't think a change in parse.c alone can work. It isn't being given enough information. > > Or, well, it does have enough information, but, like, it is information it never uses. > > It has some type information. It would have to notice that the most recent store to a variable was > > of a different type than a load. > > > > - Jay > > > > > > > > ---------------------------------------- > >> Subject: Re: [M3devel] loophole/copysign > >> From: hosking at cs.purdue.edu > >> Date: Mon, 5 Jul 2010 14:24:01 -0400 > >> CC: m3devel at elegosoft.com > >> To: jay.krell at cornell.edu > >> > >> We shouldn't need a barrier here. That is for memory operations, whereas these need not be. I would hate to make this change. Why can't we produce gcc trees that accomplish what we need? > >> > >> On 5 Jul 2010, at 05:24, Jay K wrote: > >> > >>> > >>> Our codegen is remarkably low level. That is, lower level earlier than C. > >>> > >>> > >>> gcc/m3cg -ftree-dump-all > >>> > >>> > >>> As early as LongFloat.mc.003t.original, the first file dumped, we have: > >>> > >>> LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) > >>> { > >>> xreel M3_CtKayy__result; > >>> xreel M3_CtKayy_res; > >>> > >>> xreel M3_CtKayy__result; > >>> xreel M3_CtKayy_res; > >>> M3_CtKayy_res = M3_CtKayy_x; > >>> BIT_FIELD_REF = (word_8) ((int_64) > >>> BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); > >>> = M3_CtKayy_res; > >>> return ; > >>> } > >>> > >>> compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: > >>> > >>> copy_sign_f (from, to) > >>> { > >>> float res; > >>> float D.1918; > >>> D.1917; > >>> struct float_t * from.1; > >>> struct float_t * res.0; > >>> > >>> : > >>> res = to_1; > >>> res.0_4 = (struct float_t *) &res; > >>> from.1_5 = (struct float_t *) &from; > >>> D.1917_6 = from.1_5->sign; > >>> res.0_4->sign = D.1917_6; > >>> D.1918_7 = res; > >>> return D.1918_7; > >>> > >>> } > >>> > >>> > >>> See, you know, from gcc's point of view, we don't have any records/structs/unions. > >>> Just integers and offsets from them mostly. > >>> > >>> > >>> The right fix is to build up types. > >>> That way also debugging with gdb will have a chance. > >>> Perhaps not a small amount of work. But maybe not too bad. > >>> > >>> > >>> For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. > >>> At least if one type but not the other is floating point. > >>> I don't know if that will work, but maybe. > >>> > >>> Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or > >>> store volatile. > >>> > >>> - Jay > >>> > >> > > > From jay.krell at cornell.edu Tue Jul 6 00:20:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 22:20:20 +0000 Subject: [M3devel] loophole/copysign In-Reply-To: References: , , <3267416E-1152-4A3D-A4C0-491F2C5FF74D@cs.purdue.edu>, , <6BF4E7E7-1068-4623-AE86-6687E2B7B385@cs.purdue.edu>, Message-ID: Specifically it goes down the "D_to_S" and "LV" paths (PrepLV, CompileLV, and not Prep and Compile, no temporary, no loophole) ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] loophole/copysign > Date: Mon, 5 Jul 2010 21:42:43 +0000 > > > CastExpr.m3 has precious few calls to CG.Loophole, including none for this case. > cm3cg -y output for m3core/LongReal.mc CopySign has no calls to loophole. > We store into a local as one type and read it back as another type. > > - Jay > > ---------------------------------------- > > From: hosking at cs.purdue.edu > > Date: Mon, 5 Jul 2010 17:33:43 -0400 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] loophole/copysign > > > > Surely we should instead give it the type conversion from what was stored to what is loaded. Can you point me at the problem code in CastExpr? > > > > On 5 Jul 2010, at 16:44, Jay K wrote: > > > > > > > > I don't think a barrier worked. > > > The thing is, I don't think a change in parse.c alone can work. It isn't being given enough information. > > > Or, well, it does have enough information, but, like, it is information it never uses. > > > It has some type information. It would have to notice that the most recent store to a variable was > > > of a different type than a load. > > > > > > - Jay > > > > > > > > > > > > ---------------------------------------- > > >> Subject: Re: [M3devel] loophole/copysign > > >> From: hosking at cs.purdue.edu > > >> Date: Mon, 5 Jul 2010 14:24:01 -0400 > > >> CC: m3devel at elegosoft.com > > >> To: jay.krell at cornell.edu > > >> > > >> We shouldn't need a barrier here. That is for memory operations, whereas these need not be. I would hate to make this change. Why can't we produce gcc trees that accomplish what we need? > > >> > > >> On 5 Jul 2010, at 05:24, Jay K wrote: > > >> > > >>> > > >>> Our codegen is remarkably low level. That is, lower level earlier than C. > > >>> > > >>> > > >>> gcc/m3cg -ftree-dump-all > > >>> > > >>> > > >>> As early as LongFloat.mc.003t.original, the first file dumped, we have: > > >>> > > >>> LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) > > >>> { > > >>> xreel M3_CtKayy__result; > > >>> xreel M3_CtKayy_res; > > >>> > > >>> xreel M3_CtKayy__result; > > >>> xreel M3_CtKayy_res; > > >>> M3_CtKayy_res = M3_CtKayy_x; > > >>> BIT_FIELD_REF = (word_8) ((int_64) > > >>> BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); > > >>> = M3_CtKayy_res; > > >>> return ; > > >>> } > > >>> > > >>> compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: > > >>> > > >>> copy_sign_f (from, to) > > >>> { > > >>> float res; > > >>> float D.1918; > > >>> D.1917; > > >>> struct float_t * from.1; > > >>> struct float_t * res.0; > > >>> > > >>> : > > >>> res = to_1; > > >>> res.0_4 = (struct float_t *) &res; > > >>> from.1_5 = (struct float_t *) &from; > > >>> D.1917_6 = from.1_5->sign; > > >>> res.0_4->sign = D.1917_6; > > >>> D.1918_7 = res; > > >>> return D.1918_7; > > >>> > > >>> } > > >>> > > >>> > > >>> See, you know, from gcc's point of view, we don't have any records/structs/unions. > > >>> Just integers and offsets from them mostly. > > >>> > > >>> > > >>> The right fix is to build up types. > > >>> That way also debugging with gdb will have a chance. > > >>> Perhaps not a small amount of work. But maybe not too bad. > > >>> > > >>> > > >>> For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. > > >>> At least if one type but not the other is floating point. > > >>> I don't know if that will work, but maybe. > > >>> > > >>> Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or > > >>> store volatile. > > >>> > > >>> - Jay > > >>> > > >> > > > > > > From hosking at cs.purdue.edu Tue Jul 6 00:27:10 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 5 Jul 2010 18:27:10 -0400 Subject: [M3devel] loophole/copysign In-Reply-To: References: , , <3267416E-1152-4A3D-A4C0-491F2C5FF74D@cs.purdue.edu>, , <6BF4E7E7-1068-4623-AE86-6687E2B7B385@cs.purdue.edu> Message-ID: OK, so now I begin to understand. What you are saying is that gcc needs to have a union type capturing the fact that the variable is accessed using 2 different types. What happens in C code where you cast a memory location from one type to another? How does gcc cope with that? Presumably it gets some sort of type aliasing information? On 5 Jul 2010, at 17:42, Jay K wrote: > > CastExpr.m3 has precious few calls to CG.Loophole, including none for this case. > cm3cg -y output for m3core/LongReal.mc CopySign has no calls to loophole. > We store into a local as one type and read it back as another type. > > - Jay > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Mon, 5 Jul 2010 17:33:43 -0400 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] loophole/copysign >> >> Surely we should instead give it the type conversion from what was stored to what is loaded. Can you point me at the problem code in CastExpr? >> >> On 5 Jul 2010, at 16:44, Jay K wrote: >> >>> >>> I don't think a barrier worked. >>> The thing is, I don't think a change in parse.c alone can work. It isn't being given enough information. >>> Or, well, it does have enough information, but, like, it is information it never uses. >>> It has some type information. It would have to notice that the most recent store to a variable was >>> of a different type than a load. >>> >>> - Jay >>> >>> >>> >>> ---------------------------------------- >>>> Subject: Re: [M3devel] loophole/copysign >>>> From: hosking at cs.purdue.edu >>>> Date: Mon, 5 Jul 2010 14:24:01 -0400 >>>> CC: m3devel at elegosoft.com >>>> To: jay.krell at cornell.edu >>>> >>>> We shouldn't need a barrier here. That is for memory operations, whereas these need not be. I would hate to make this change. Why can't we produce gcc trees that accomplish what we need? >>>> >>>> On 5 Jul 2010, at 05:24, Jay K wrote: >>>> >>>>> >>>>> Our codegen is remarkably low level. That is, lower level earlier than C. >>>>> >>>>> >>>>> gcc/m3cg -ftree-dump-all >>>>> >>>>> >>>>> As early as LongFloat.mc.003t.original, the first file dumped, we have: >>>>> >>>>> LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) >>>>> { >>>>> xreel M3_CtKayy__result; >>>>> xreel M3_CtKayy_res; >>>>> >>>>> xreel M3_CtKayy__result; >>>>> xreel M3_CtKayy_res; >>>>> M3_CtKayy_res = M3_CtKayy_x; >>>>> BIT_FIELD_REF = (word_8) ((int_64) >>>>> BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); >>>>> = M3_CtKayy_res; >>>>> return ; >>>>> } >>>>> >>>>> compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: >>>>> >>>>> copy_sign_f (from, to) >>>>> { >>>>> float res; >>>>> float D.1918; >>>>> D.1917; >>>>> struct float_t * from.1; >>>>> struct float_t * res.0; >>>>> >>>>> : >>>>> res = to_1; >>>>> res.0_4 = (struct float_t *) &res; >>>>> from.1_5 = (struct float_t *) &from; >>>>> D.1917_6 = from.1_5->sign; >>>>> res.0_4->sign = D.1917_6; >>>>> D.1918_7 = res; >>>>> return D.1918_7; >>>>> >>>>> } >>>>> >>>>> >>>>> See, you know, from gcc's point of view, we don't have any records/structs/unions. >>>>> Just integers and offsets from them mostly. >>>>> >>>>> >>>>> The right fix is to build up types. >>>>> That way also debugging with gdb will have a chance. >>>>> Perhaps not a small amount of work. But maybe not too bad. >>>>> >>>>> >>>>> For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. >>>>> At least if one type but not the other is floating point. >>>>> I don't know if that will work, but maybe. >>>>> >>>>> Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or >>>>> store volatile. >>>>> >>>>> - Jay >>>>> >>>> >>> >> > From jay.krell at cornell.edu Tue Jul 6 00:50:38 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 22:50:38 +0000 Subject: [M3devel] loophole/copysign In-Reply-To: References: , , <3267416E-1152-4A3D-A4C0-491F2C5FF74D@cs.purdue.edu>, , <6BF4E7E7-1068-4623-AE86-6687E2B7B385@cs.purdue.edu> , Message-ID: The C trees are much higher level. First, cm3/m3-libs/m3core/src/float/test_copysign.c which is analogous to CopySign, the C code: typedef struct { ??????? unsigned rest : 31; ??????? unsigned sign : 1; } float_t; float copy_sign_f(float from, float to) { ??????? float res = to; ??????? ((float_t*)&res)->sign = ((float_t*)&from)->sign; ??????? return res; } is what we should somehow strive for. It yields a tree with almost everything preserved (typedefs fall out). gcc-4.2 -fdump-tree-all -c test_copysign.c test_copysign.c.003t.original: ;; Function copy_sign_f (copy_sign_f) ;; enabled by -tree-original { ? float res = to; ??? float res = to; ? ((struct float_t *) &res)->sign = ((struct float_t *) &from)->sign; ? return res; } which is nothing like what we produce. We don't have structs/member_refs ever, I believe. To maybe answer your question..well..: int reinterpret(float f) { ? return *(int*)&f; } gcc-4.2 -ftree-dump-all -c 5.c well, the tree is high super high fidelity, nearly indistinguishable from the input C: ;; Function reinterpret (reinterpret) ;; enabled by -tree-original { ? return *(int *) &f; } I think we would produce about the same thing if we went down the non-bitfield path in load or store. You know ... we don't even need to do loophole, but we need to do just one load or one store, with a conversion, instead of storing one way and loading the other. You could imagine parse.c might buffer up one load or store and then if the next instruction is not store or load, just flush it, but if it is store or load, merge them. Well, it depends on what load or store is to of course. ?- Jay ---------------------------------------- > Subject: Re: [M3devel] loophole/copysign > From: hosking at cs.purdue.edu > Date: Mon, 5 Jul 2010 18:27:10 -0400 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > OK, so now I begin to understand. What you are saying is that gcc needs to have a union type capturing the fact that the variable is accessed using 2 different types. What happens in C code where you cast a memory location from one type to another? How does gcc cope with that? Presumably it gets some sort of type aliasing information? > > On 5 Jul 2010, at 17:42, Jay K wrote: > > > > > CastExpr.m3 has precious few calls to CG.Loophole, including none for this case. > > cm3cg -y output for m3core/LongReal.mc CopySign has no calls to loophole. > > We store into a local as one type and read it back as another type. > > > > - Jay > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Mon, 5 Jul 2010 17:33:43 -0400 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] loophole/copysign > >> > >> Surely we should instead give it the type conversion from what was stored to what is loaded. Can you point me at the problem code in CastExpr? > >> > >> On 5 Jul 2010, at 16:44, Jay K wrote: > >> > >>> > >>> I don't think a barrier worked. > >>> The thing is, I don't think a change in parse.c alone can work. It isn't being given enough information. > >>> Or, well, it does have enough information, but, like, it is information it never uses. > >>> It has some type information. It would have to notice that the most recent store to a variable was > >>> of a different type than a load. > >>> > >>> - Jay > >>> > >>> > >>> > >>> ---------------------------------------- > >>>> Subject: Re: [M3devel] loophole/copysign > >>>> From: hosking at cs.purdue.edu > >>>> Date: Mon, 5 Jul 2010 14:24:01 -0400 > >>>> CC: m3devel at elegosoft.com > >>>> To: jay.krell at cornell.edu > >>>> > >>>> We shouldn't need a barrier here. That is for memory operations, whereas these need not be. I would hate to make this change. Why can't we produce gcc trees that accomplish what we need? > >>>> > >>>> On 5 Jul 2010, at 05:24, Jay K wrote: > >>>> > >>>>> > >>>>> Our codegen is remarkably low level. That is, lower level earlier than C. > >>>>> > >>>>> > >>>>> gcc/m3cg -ftree-dump-all > >>>>> > >>>>> > >>>>> As early as LongFloat.mc.003t.original, the first file dumped, we have: > >>>>> > >>>>> LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) > >>>>> { > >>>>> xreel M3_CtKayy__result; > >>>>> xreel M3_CtKayy_res; > >>>>> > >>>>> xreel M3_CtKayy__result; > >>>>> xreel M3_CtKayy_res; > >>>>> M3_CtKayy_res = M3_CtKayy_x; > >>>>> BIT_FIELD_REF = (word_8) ((int_64) > >>>>> BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); > >>>>> = M3_CtKayy_res; > >>>>> return ; > >>>>> } > >>>>> > >>>>> compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: > >>>>> > >>>>> copy_sign_f (from, to) > >>>>> { > >>>>> float res; > >>>>> float D.1918; > >>>>> D.1917; > >>>>> struct float_t * from.1; > >>>>> struct float_t * res.0; > >>>>> > >>>>> : > >>>>> res = to_1; > >>>>> res.0_4 = (struct float_t *) &res; > >>>>> from.1_5 = (struct float_t *) &from; > >>>>> D.1917_6 = from.1_5->sign; > >>>>> res.0_4->sign = D.1917_6; > >>>>> D.1918_7 = res; > >>>>> return D.1918_7; > >>>>> > >>>>> } > >>>>> > >>>>> > >>>>> See, you know, from gcc's point of view, we don't have any records/structs/unions. > >>>>> Just integers and offsets from them mostly. > >>>>> > >>>>> > >>>>> The right fix is to build up types. > >>>>> That way also debugging with gdb will have a chance. > >>>>> Perhaps not a small amount of work. But maybe not too bad. > >>>>> > >>>>> > >>>>> For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. > >>>>> At least if one type but not the other is floating point. > >>>>> I don't know if that will work, but maybe. > >>>>> > >>>>> Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or > >>>>> store volatile. > >>>>> > >>>>> - Jay > >>>>> > >>>> > >>> > >> > > > From jay.krell at cornell.edu Tue Jul 6 01:06:29 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 5 Jul 2010 23:06:29 +0000 Subject: [M3devel] loophole/copysign In-Reply-To: References: , , <3267416E-1152-4A3D-A4C0-491F2C5FF74D@cs.purdue.edu>, , <6BF4E7E7-1068-4623-AE86-6687E2B7B385@cs.purdue.edu>, , , Message-ID: I'm not sure we need to be too fancy: not sure we need a union. I think merely taking the address and casting and derefing it might suffice. For aliasing we just always return 0, so presumably..any pointers are pessimistic. The alias information seems to be that any "decl" could be a variable, or a type..is in a "set". Sets are integer indices into an array of sets. Same integer => same set. But I think that we just return 0 all the time makes these easy and adequate. Could be better. But probably ok. Perhaps the better way would be: ? if file uses loophole anywhere, same as today ?? loophole in the front end or backend ?if file doesn't use loophole, we can probably at least put every? type in its own set? ? Er, not exactly: not subranges enums integers. ? But still probably some easy stuff? ?Anyway, just having everything in the same alias set should be ok for now. ?We're still digging out of a big hole: volatile everywhere.. no unit at a time.. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] loophole/copysign > Date: Mon, 5 Jul 2010 22:50:38 +0000 > > > The C trees are much higher level. > > First, cm3/m3-libs/m3core/src/float/test_copysign.c which is analogous to CopySign, the C code: > > typedef struct { > unsigned rest : 31; > unsigned sign : 1; > } float_t; > > float copy_sign_f(float from, float to) > { > float res = to; > ((float_t*)&res)->sign = ((float_t*)&from)->sign; > return res; > } > > is what we should somehow strive for. > > It yields a tree with almost everything preserved (typedefs fall out). > gcc-4.2 -fdump-tree-all -c test_copysign.c > > test_copysign.c.003t.original: > > ;; Function copy_sign_f (copy_sign_f) > ;; enabled by -tree-original > > { > float res = to; > > float res = to; > ((struct float_t *) &res)->sign = ((struct float_t *) &from)->sign; > return res; > } > > which is nothing like what we produce. > We don't have structs/member_refs ever, I believe. > > > To maybe answer your question..well..: > > int reinterpret(float f) > { > return *(int*)&f; > } > > gcc-4.2 -ftree-dump-all -c 5.c well, the tree is high super high fidelity, nearly > indistinguishable from the input C: > > > ;; Function reinterpret (reinterpret) > ;; enabled by -tree-original > { > return *(int *) &f; > } > > > I think we would produce about the same thing if we went down the non-bitfield path in load or store. > You know ... we don't even need to do loophole, but we need to do just one load or one store, with a conversion, > instead of storing one way and loading the other. > > > You could imagine parse.c might buffer up one load or store and then if the next instruction is not store or load, just flush it, > but if it is store or load, merge them. Well, it depends on what load or store is to of course. > > > - Jay > > ---------------------------------------- > > Subject: Re: [M3devel] loophole/copysign > > From: hosking at cs.purdue.edu > > Date: Mon, 5 Jul 2010 18:27:10 -0400 > > CC: m3devel at elegosoft.com > > To: jay.krell at cornell.edu > > > > OK, so now I begin to understand. What you are saying is that gcc needs to have a union type capturing the fact that the variable is accessed using 2 different types. What happens in C code where you cast a memory location from one type to another? How does gcc cope with that? Presumably it gets some sort of type aliasing information? > > > > On 5 Jul 2010, at 17:42, Jay K wrote: > > > > > > > > CastExpr.m3 has precious few calls to CG.Loophole, including none for this case. > > > cm3cg -y output for m3core/LongReal.mc CopySign has no calls to loophole. > > > We store into a local as one type and read it back as another type. > > > > > > - Jay > > > > > > ---------------------------------------- > > >> From: hosking at cs.purdue.edu > > >> Date: Mon, 5 Jul 2010 17:33:43 -0400 > > >> To: jay.krell at cornell.edu > > >> CC: m3devel at elegosoft.com > > >> Subject: Re: [M3devel] loophole/copysign > > >> > > >> Surely we should instead give it the type conversion from what was stored to what is loaded. Can you point me at the problem code in CastExpr? > > >> > > >> On 5 Jul 2010, at 16:44, Jay K wrote: > > >> > > >>> > > >>> I don't think a barrier worked. > > >>> The thing is, I don't think a change in parse.c alone can work. It isn't being given enough information. > > >>> Or, well, it does have enough information, but, like, it is information it never uses. > > >>> It has some type information. It would have to notice that the most recent store to a variable was > > >>> of a different type than a load. > > >>> > > >>> - Jay > > >>> > > >>> > > >>> > > >>> ---------------------------------------- > > >>>> Subject: Re: [M3devel] loophole/copysign > > >>>> From: hosking at cs.purdue.edu > > >>>> Date: Mon, 5 Jul 2010 14:24:01 -0400 > > >>>> CC: m3devel at elegosoft.com > > >>>> To: jay.krell at cornell.edu > > >>>> > > >>>> We shouldn't need a barrier here. That is for memory operations, whereas these need not be. I would hate to make this change. Why can't we produce gcc trees that accomplish what we need? > > >>>> > > >>>> On 5 Jul 2010, at 05:24, Jay K wrote: > > >>>> > > >>>>> > > >>>>> Our codegen is remarkably low level. That is, lower level earlier than C. > > >>>>> > > >>>>> > > >>>>> gcc/m3cg -ftree-dump-all > > >>>>> > > >>>>> > > >>>>> As early as LongFloat.mc.003t.original, the first file dumped, we have: > > >>>>> > > >>>>> LongFloat__CopySign (M3_CtKayy_x, M3_CtKayy_y) > > >>>>> { > > >>>>> xreel M3_CtKayy__result; > > >>>>> xreel M3_CtKayy_res; > > >>>>> > > >>>>> xreel M3_CtKayy__result; > > >>>>> xreel M3_CtKayy_res; > > >>>>> M3_CtKayy_res = M3_CtKayy_x; > > >>>>> BIT_FIELD_REF = (word_8) ((int_64) > > >>>>> BIT_FIELD_REF & -129 | (word_64) BIT_FIELD_REF <(int_64) BIT_FIELD_REF , 1, 7> << 7 & 255); > > >>>>> = M3_CtKayy_res; > > >>>>> return ; > > >>>>> } > > >>>>> > > >>>>> compared to C where as test_copysign.c.t69.copyrename3, the last file dumped, we have: > > >>>>> > > >>>>> copy_sign_f (from, to) > > >>>>> { > > >>>>> float res; > > >>>>> float D.1918; > > >>>>> D.1917; > > >>>>> struct float_t * from.1; > > >>>>> struct float_t * res.0; > > >>>>> > > >>>>> : > > >>>>> res = to_1; > > >>>>> res.0_4 = (struct float_t *) &res; > > >>>>> from.1_5 = (struct float_t *) &from; > > >>>>> D.1917_6 = from.1_5->sign; > > >>>>> res.0_4->sign = D.1917_6; > > >>>>> D.1918_7 = res; > > >>>>> return D.1918_7; > > >>>>> > > >>>>> } > > >>>>> > > >>>>> > > >>>>> See, you know, from gcc's point of view, we don't have any records/structs/unions. > > >>>>> Just integers and offsets from them mostly. > > >>>>> > > >>>>> > > >>>>> The right fix is to build up types. > > >>>>> That way also debugging with gdb will have a chance. > > >>>>> Perhaps not a small amount of work. But maybe not too bad. > > >>>>> > > >>>>> > > >>>>> For now my inclination is in m3front to insert a barrier between the store and the load associated with loopholes. > > >>>>> At least if one type but not the other is floating point. > > >>>>> I don't know if that will work, but maybe. > > >>>>> > > >>>>> Or maybe have m3front actually call loophole for this case and again, either a barrier or make the load and/or > > >>>>> store volatile. > > >>>>> > > >>>>> - Jay > > >>>>> > > >>>> > > >>> > > >> > > > > > > From mika at async.async.caltech.edu Tue Jul 6 07:58:33 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Mon, 05 Jul 2010 22:58:33 -0700 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20100705132228.0E6D52474003@birch.elegosoft.com>, <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu>, , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu>, , <6331F39C-AA28-4AC1-8C87-3D47D52D0C55@cs.purdue.edu>, , <02F12035-7271-4004-BE67-3DAB17C37B3B@cs.purdue.edu> Message-ID: <20100706055833.118D21A2080@async.async.caltech.edu> As I've said before, When I write: VAR a : INTEGER; BEGIN ... .... a := .. ... ... END that means I am putting you, the reader, on notice that I have no particularly meaningful idea of what a's initial value is. If I were to write VAR a := 0; BEGIN ... END I would mislead you into thinking that 0 is a somehow important initial value. Which it's not. It's just garbage, and it better not show up in the computation! Programs are mainly meant to be read by humans, not computers. Mika Jay K writes: >--_d2468f3b-9666-4291-98b5-5414421f54d9_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >We are going in circles. From jay.krell at cornell.edu Tue Jul 6 08:22:50 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Jul 2010 06:22:50 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20100706055833.118D21A2080@async.async.caltech.edu> References: <20100705132228.0E6D52474003@birch.elegosoft.com>, , <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , , , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu>, , , , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu>, , , , <6331F39C-AA28-4AC1-8C87-3D47D52D0C55@cs.purdue.edu>, , , , <02F12035-7271-4004-BE67-3DAB17C37B3B@cs.purdue.edu>, , <20100706055833.118D21A2080@async.async.caltech.edu> Message-ID: Programmers are notorious for making mistakes. When you write VAR a:INTEGER; you make the human proofreading your code have to work much harder to do the data/control flow analysis to make sure you didn't use the uninitialized value. Using the a := 0 value might still be "wrong", but is it at least consistent and the penalty for getting it wrong is generally less severe. Now, I don't want there to be a bug either way, but I feel that a consistent 0 is much "safer" than uninitialized. Either is typesafe, sure, but type safe is just the bare minimum expectation for my code. It must not only be type safe, but act correctly. Again, compiler isn't generally a program proofer, but the little it can do, let it do. Here is how I write C code: void function_with_two_temporary_buffers() { ? void* p = { 0 }; ? void* q = { 0 }; ? if (!(p = malloc(...))) ??? goto exit; ? if (!(q = malloc(...))) ??? goto exit; ... exit: ?? free(p); ?? free(q); } or void function_that_returns_two_buffers(void** a, void** b) { ? void* p = { 0 }; ? void* q = { 0 }; ? ? *a = p; ? *b = q; ? if (!(p = malloc(...)) ?? goto Exit; ? if (!(q = malloc(...)) ?? goto Exit; ??? .... ? *a = p; ?? p = 0; ?? *b = q; ?? q = 0; Exit: ? free(p); ? free(q); } In reality malloc is generally a function that returns an integer, negative for success. So it is more like: #define CHECK(expr) do { if ((status = (expr)) < 0) goto Exit; } while(0) ? CHECK(MemoryAlloc(..., &q)); See, the style is written to be easy for a human to verify the correctness of. Locals are always initialized. Ownership of resources is always clear. This is contrast with other styles: ?if (p = malloc(...)) ? { ????? ... ???? if (q = malloc(...)) ??? { ???????? ... ??????? free(q); ??? } ?? free(p); } where one has to follow the ever further indented blob of ifs. It doesn't scale. Every resource allocation makes the code incrementally harder for a human to read. Whereas the style that includes initializing all locals has no such incremental cost. (And this hard to read style is in fact somewhat encouraged by the "with" feature of Modula-3. C++'s equivalent -- declaring variables anywhere -- doesn't suggest ever increasing indentation. ) ?- Jay ---------------------------------------- > To: jay.krell at cornell.edu > Date: Mon, 5 Jul 2010 22:58:33 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > > As I've said before, > > When I write: > > VAR > a : INTEGER; > BEGIN > > ... > > .... a := .. ... > > ... > > END > > that means I am putting you, the reader, on notice that I have no > particularly meaningful idea of what a's initial value is. > > If I were to write > > VAR > a := 0; > BEGIN > ... > END > > I would mislead you into thinking that 0 is a somehow important > initial value. Which it's not. It's just garbage, and it better > not show up in the computation! > > Programs are mainly meant to be read by humans, not computers. > > Mika > > > Jay K writes: > >--_d2468f3b-9666-4291-98b5-5414421f54d9_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >We are going in circles. From mika at async.async.caltech.edu Tue Jul 6 08:34:58 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Mon, 05 Jul 2010 23:34:58 -0700 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20100705132228.0E6D52474003@birch.elegosoft.com>, , <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , , , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu>, , , , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu>, , , , <6331F39C-AA28-4AC1-8C87-3D47D52D0C55@cs.purdue.edu>, , , , <02F12035-7271-4004-BE67-3DAB17C37B3B@cs.purdue.edu>, , <20100706055833.118D21A2080@async.async.caltech.edu> Message-ID: <20100706063458.DCFF41A2080@async.async.caltech.edu> Jay, I agree with the general premise that splitting declaration and initialization is bad coding style. I use WITH or the initialization of a procedure entry as much as possible to declare my variables. And if they have to change during the course of their lifetime, I do try to initialize them in the VAR. But... you're wrong :-) Imagine you have a variable whose initial value (i.e., the value it has before the first time it is used) is critical for the correctness of your algorithm. The initial value depends on something else, something that has to be computed. In this case, which does happen, at least in my code, there is no static value that is better than any other. VAR x : INTEGER; BEGIN is the right way to code that. VAR x := 0; BEGIN accomplishes exactly one thing: it obfuscates the code---it misleads the reader into thinking that x=0 is somehow relevant to the code, without adding anything at all to its correctness. As I said, the declaration that isn't initialized is to be used *sparingly* and whenever it is used it should be a giant red flag to the reader that the variable x is going to be initialized with a value that the programmer doesn't know at the time of declaration. What on earth do you gain from x := 0? A "little correctness"? Mika Jay K writes: > >Programmers are notorious for making mistakes. > > >When you write VAR a:INTEGER=3B >you make the human proofreading your code have to work much harder >to do the data/control flow analysis to make sure you didn't >use the uninitialized value. > > >Using the a :=3D 0 value might still be "wrong"=2C but is it at least consi= >stent >and the penalty for getting it wrong is generally less severe. > >Now=2C I don't want there to be a bug either way=2C but I feel that a consi= >stent 0 is much "safer" >than uninitialized. Either is typesafe=2C sure=2C but type safe is just the= > bare minimum expectation >for my code. It must not only be type safe=2C but act correctly. > >Again=2C compiler isn't generally a program proofer=2C but the little it ca= >n do=2C let it do. > > > >Here is how I write C code: > >void function_with_two_temporary_buffers() >{ >=A0 void* p =3D { 0 }=3B >=A0 void* q =3D { 0 }=3B > >=A0 if (!(p =3D malloc(...))) >=A0=A0=A0 goto exit=3B > >=A0 if (!(q =3D malloc(...))) > >=A0=A0=A0 goto exit=3B > > > >... > >exit: >=A0=A0 free(p)=3B >=A0=A0 free(q)=3B >} > >or >void function_that_returns_two_buffers(void** a=2C void** b) >{ >=A0 void* p =3D { 0 }=3B >=A0 void* q =3D { 0 }=3B >=A0=20 >=A0 *a =3D p=3B >=A0 *b =3D q=3B > >=A0 if (!(p =3D malloc(...)) >=A0=A0 goto Exit=3B > >=A0 if (!(q =3D malloc(...)) > >=A0=A0 goto Exit=3B > > > >=A0=A0=A0 .... >=A0 *a =3D p=3B >=A0=A0 p =3D 0=3B >=A0=A0 *b =3D q=3B >=A0=A0 q =3D 0=3B > >Exit:=20 >=A0 free(p)=3B >=A0 free(q)=3B > >} > >In reality malloc is generally a function that returns an integer=2C negati= >ve for success. >So it is more like: >#define CHECK(expr) do { if ((status =3D (expr)) < 0) goto Exit=3B } while(= >0) > > >=A0 CHECK(MemoryAlloc(...=2C &q))=3B > >See=2C the style is written to be easy for a human to verify the correctnes= >s of. >Locals are always initialized. Ownership of resources is always clear. > >This is contrast with other styles: > >=A0if (p =3D malloc(...)) >=A0 { >=A0=A0=A0=A0=A0 ... >=A0=A0=A0=A0 if (q =3D malloc(...)) >=A0=A0=A0 { >=A0=A0=A0=A0=A0=A0=A0=A0 ... >=A0=A0=A0=A0=A0=A0=A0 free(q)=3B >=A0=A0=A0 } >=A0=A0 free(p)=3B >} > >where one has to follow the ever further indented blob of ifs. >It doesn't scale. Every resource allocation makes the code incrementally ha= >rder for a human to read. >Whereas the style that includes initializing all locals has no such increme= >ntal cost. > >(And this hard to read style is in fact somewhat encouraged by the "with" f= >eature of Modula-3. >C++'s equivalent -- declaring variables anywhere -- doesn't suggest ever in= >creasing indentation. >) > > >=A0- Jay > > > >---------------------------------------- >> To: jay.krell at cornell.edu >> Date: Mon=2C 5 Jul 2010 22:58:33 -0700 >> From: mika at async.async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] [M3commit] CVS Update: cm3 >> >> >> As I've said before=2C >> >> When I write: >> >> VAR >> a : INTEGER=3B >> BEGIN >> >> ... >> >> .... a :=3D .. ... >> >> ... >> >> END >> >> that means I am putting you=2C the reader=2C on notice that I have no >> particularly meaningful idea of what a's initial value is. >> >> If I were to write >> >> VAR >> a :=3D 0=3B >> BEGIN >> ... >> END >> >> I would mislead you into thinking that 0 is a somehow important >> initial value. Which it's not. It's just garbage=2C and it better >> not show up in the computation! >> >> Programs are mainly meant to be read by humans=2C not computers. >> >> Mika >> >> >> Jay K writes: >> >--_d2468f3b-9666-4291-98b5-5414421f54d9_ >> >Content-Type: text/plain=3B charset=3D"iso-8859-1" >> >Content-Transfer-Encoding: quoted-printable >> > >> > >> >We are going in circles. > = From mika at async.async.caltech.edu Tue Jul 6 08:35:47 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Mon, 05 Jul 2010 23:35:47 -0700 Subject: [M3devel] [M3commit] CVS Update: cm3 Message-ID: <20100706063547.81FC21A2080@async.async.caltech.edu> >When you write VAR a:INTEGER=3B >you make the human proofreading your code have to work much harder >to do the data/control flow analysis to make sure you didn't >use the uninitialized value. And yes, that's precisely the point! From jay.krell at cornell.edu Tue Jul 6 12:05:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Jul 2010 10:05:43 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20100706063458.DCFF41A2080@async.async.caltech.edu> References: <20100705132228.0E6D52474003@birch.elegosoft.com>, , <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , , , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu>, , , , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu>, , , , <6331F39C-AA28-4AC1-8C87-3D47D52D0C55@cs.purdue.edu>, , , , <02F12035-7271-4004-BE67-3DAB17C37B3B@cs.purdue.edu>, , <20100706055833.118D21A2080@async.async.caltech.edu> , <20100706063458.DCFF41A2080@async.async.caltech.edu> Message-ID: > used it should be a giant red flag to the reader that the variable x is > going to be initialized with a value that the programmer doesn't know > at the time of declaration. What on earth do you gain from x := 0? > A "little correctness"? You are making the code more expensive to maintain, by making it harder for a human to analyze. For the benefit of microoptimization. ?- Jay ---------------------------------------- > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > Date: Mon, 5 Jul 2010 23:34:58 -0700 > From: mika at async.async.caltech.edu > > > Jay, I agree with the general premise that splitting declaration and > initialization is bad coding style. I use WITH or the initialization > of a procedure entry as much as possible to declare my variables. > And if they have to change during the course of their lifetime, > I do try to initialize them in the VAR. > > But... you're wrong :-) > > Imagine you have a variable whose initial value (i.e., the value it has > before the first time it is used) is critical for the correctness of > your algorithm. The initial value depends on something else, something > that has to be computed. In this case, which does happen, at least > in my code, there is no static value that is better than any other. > VAR x : INTEGER; BEGIN is the right way to code that. VAR x := 0; BEGIN > accomplishes exactly one thing: it obfuscates the code---it misleads the > reader into thinking that x=0 is somehow relevant to the code, without > adding anything at all to its correctness. As I said, the declaration > that isn't initialized is to be used *sparingly* and whenever it is > used it should be a giant red flag to the reader that the variable x is > going to be initialized with a value that the programmer doesn't know > at the time of declaration. What on earth do you gain from x := 0? > A "little correctness"? > > Mika > > Jay K writes: > > > >Programmers are notorious for making mistakes. > > > > > >When you write VAR a:INTEGER=3B > >you make the human proofreading your code have to work much harder > >to do the data/control flow analysis to make sure you didn't > >use the uninitialized value. > > > > > >Using the a :=3D 0 value might still be "wrong"=2C but is it at least consi= > >stent > >and the penalty for getting it wrong is generally less severe. > > > >Now=2C I don't want there to be a bug either way=2C but I feel that a consi= > >stent 0 is much "safer" > >than uninitialized. Either is typesafe=2C sure=2C but type safe is just the= > > bare minimum expectation > >for my code. It must not only be type safe=2C but act correctly. > > > >Again=2C compiler isn't generally a program proofer=2C but the little it ca= > >n do=2C let it do. > > > > > > > >Here is how I write C code: > > > >void function_with_two_temporary_buffers() > >{ > >=A0 void* p =3D { 0 }=3B > >=A0 void* q =3D { 0 }=3B > > > >=A0 if (!(p =3D malloc(...))) > >=A0=A0=A0 goto exit=3B > > > >=A0 if (!(q =3D malloc(...))) > > > >=A0=A0=A0 goto exit=3B > > > > > > > >... > > > >exit: > >=A0=A0 free(p)=3B > >=A0=A0 free(q)=3B > >} > > > >or > >void function_that_returns_two_buffers(void** a=2C void** b) > >{ > >=A0 void* p =3D { 0 }=3B > >=A0 void* q =3D { 0 }=3B > >=A0=20 > >=A0 *a =3D p=3B > >=A0 *b =3D q=3B > > > >=A0 if (!(p =3D malloc(...)) > >=A0=A0 goto Exit=3B > > > >=A0 if (!(q =3D malloc(...)) > > > >=A0=A0 goto Exit=3B > > > > > > > >=A0=A0=A0 .... > >=A0 *a =3D p=3B > >=A0=A0 p =3D 0=3B > >=A0=A0 *b =3D q=3B > >=A0=A0 q =3D 0=3B > > > >Exit:=20 > >=A0 free(p)=3B > >=A0 free(q)=3B > > > >} > > > >In reality malloc is generally a function that returns an integer=2C negati= > >ve for success. > >So it is more like: > >#define CHECK(expr) do { if ((status =3D (expr)) < 0) goto Exit=3B } while(= > >0) > > > > > >=A0 CHECK(MemoryAlloc(...=2C &q))=3B > > > >See=2C the style is written to be easy for a human to verify the correctnes= > >s of. > >Locals are always initialized. Ownership of resources is always clear. > > > >This is contrast with other styles: > > > >=A0if (p =3D malloc(...)) > >=A0 { > >=A0=A0=A0=A0=A0 ... > >=A0=A0=A0=A0 if (q =3D malloc(...)) > >=A0=A0=A0 { > >=A0=A0=A0=A0=A0=A0=A0=A0 ... > >=A0=A0=A0=A0=A0=A0=A0 free(q)=3B > >=A0=A0=A0 } > >=A0=A0 free(p)=3B > >} > > > >where one has to follow the ever further indented blob of ifs. > >It doesn't scale. Every resource allocation makes the code incrementally ha= > >rder for a human to read. > >Whereas the style that includes initializing all locals has no such increme= > >ntal cost. > > > >(And this hard to read style is in fact somewhat encouraged by the "with" f= > >eature of Modula-3. > >C++'s equivalent -- declaring variables anywhere -- doesn't suggest ever in= > >creasing indentation. > >) > > > > > >=A0- Jay > > > > > > > >---------------------------------------- > >> To: jay.krell at cornell.edu > >> Date: Mon=2C 5 Jul 2010 22:58:33 -0700 > >> From: mika at async.async.caltech.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > >> > >> > >> As I've said before=2C > >> > >> When I write: > >> > >> VAR > >> a : INTEGER=3B > >> BEGIN > >> > >> ... > >> > >> .... a :=3D .. ... > >> > >> ... > >> > >> END > >> > >> that means I am putting you=2C the reader=2C on notice that I have no > >> particularly meaningful idea of what a's initial value is. > >> > >> If I were to write > >> > >> VAR > >> a :=3D 0=3B > >> BEGIN > >> ... > >> END > >> > >> I would mislead you into thinking that 0 is a somehow important > >> initial value. Which it's not. It's just garbage=2C and it better > >> not show up in the computation! > >> > >> Programs are mainly meant to be read by humans=2C not computers. > >> > >> Mika > >> > >> > >> Jay K writes: > >> >--_d2468f3b-9666-4291-98b5-5414421f54d9_ > >> >Content-Type: text/plain=3B charset=3D"iso-8859-1" > >> >Content-Transfer-Encoding: quoted-printable > >> > > >> > > >> >We are going in circles. > > = From jay.krell at cornell.edu Tue Jul 6 12:08:30 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Jul 2010 10:08:30 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20100706063547.81FC21A2080@async.async.caltech.edu> References: <20100706063547.81FC21A2080@async.async.caltech.edu> Message-ID: ---------------------------------------- > To: jay > CC: m3devel > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > Date: Mon, 5 Jul 2010 23:35:47 -0700 > From: mikau > > >When you write VAR a:INTEGER=3B > >you make the human proofreading your code have to work much harder > >to do the data/control flow analysis to make sure you didn't > >use the uninitialized value. > > And yes, that's precisely the point! You are just adding to the maintenance cost of the code. If something makes it much more difficult to analyze by a human, and doesn't provide much benefit, don't do it. Esp. when a large fraction of the time, the compiler with far more cycles to burn, will be able to make the micro optimization. And another fraction of the time, the computer running the program will have plenty of cycles. ?(granted, the code is larger, and disk cycles are scarce). ?- Jay From jay.krell at cornell.edu Tue Jul 6 14:28:34 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Jul 2010 12:28:34 +0000 Subject: [M3devel] yet another proposed fix.. careful insertion of one instance of CG.Force() in CastExpr.m3 Message-ID: Ok, this is interesting. I think. Finally. I need to test more, but it is looking very promising. I think you'll like it (Tony). I still don't understand all the flow around the front end. I had to try out some guesses. It certainly appears that m3front/src/misc/CG.m3 is in the business of optimizations. This change might actually be too conservative. It defeats optimization in CG.m3. It limits it to D_to_S when one type is float and the other isn't. ?I guess S (struct) can't really be float. The assertion failure in gcc btw, was gcc_assert( something_is_float == other_is_float). So the conservativeness is somewhat sensible. Limiting it to D_to_S, though, unclear. The change is just inserting CG.Force(). OK? (Let me test a bit more -- build the entire tree.) This appears to let me leave "ter" on. I can try leaving other optimizations on. Index: exprs/CastExpr.m3 =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/CastExpr.m3,v retrieving revision 1.9 diff -u -r1.9 CastExpr.m3 --- exprs/CastExpr.m3??? 5 Jul 2010 11:28:32 -0000??? 1.9 +++ exprs/CastExpr.m3??? 6 Jul 2010 12:23:14 -0000 @@ -10,6 +10,7 @@ ? ?IMPORT M3Buf, CG, Expr, ExprRep, Type, Error, OpenArrayType; ?IMPORT M3, M3ID, M3RT, Target, TInt; +FROM Target IMPORT FloatType; ? ?TYPE ?? Kind = { @@ -394,7 +395,7 @@ ???? u? := Expr.TypeOf (e); ???? t? := p.tipe; ???? sz, t_align, u_align, z_align: INTEGER; -??? u_cg: CG.Type; +??? u_cg, t_cg: CG.Type; ???? u_info, t_info: Type.Info; ?? BEGIN ???? u := Type.CheckInfo (u, u_info); @@ -403,6 +404,7 @@ ???? u_align := u_info.alignment; ???? z_align := MAX (t_align, u_align); ???? u_cg := u_info.stk_type; +??? t_cg := t_info.stk_type; ???? sz := u_info.size; ???? Type.Compile (t); ???? Type.Compile (u); @@ -416,6 +418,15 @@ ?????? Kind.V_to_V => ???????? Expr.CompileLValue (p.expr, traced); ???????? CG.Boost_alignment (t_align); +(* Inhibit some optimization that causes compilation to fail. e.g. m3core: +../src/float/IEEE/RealFloat.m3: In function 'RealFloat__CopySign': +../src/float/IEEE/RealFloat.m3:96: internal compiler error: in convert_move, at expr.c:371 +../src/float/IEEE/LongFloat.m3: In function 'LongFloat__CopySign': +../src/float/IEEE/LongFloat.m3:116: internal compiler error: in convert_move, at expr.c:371 +*) +??????? IF p.kind = Kind.D_to_S AND FloatType[u_cg] # FloatType[t_cg] THEN +????????? CG.Force (); +??????? END; ? ???? | Kind.D_to_A, ?????? Kind.S_to_A, (577) begin_procedure ? procedure LongFloat__CopySign ?LongFloat__CopySign(578) set_source_line ? source line? 117 (579) load ? type:lreal ? type:lreal ? m3cg_load (M3_CtKayy_x): offset 0x0, convert lreal -> lreal (580) store ? type:lreal ? type:lreal ? store (M3_CtKayy_res) offset:0x0 src_t:lreal dst_t:lreal (581) set_source_line ? source line? 119 now notice we have use of load_address and load_indirect here, where before we had no address and load (direct) (582) load_address ? load address (M3_CtKayy_res) offset 0x0 (583) load_address ? load address (M3_CtKayy_y) offset 0x0 (584) load_indirect ? type:word8 ? type:int64 ? load address offset:0x38 src_t:word8 dst_t:int64 (585) extract_mn ? type:int64 ?extract_mn offset:7 count:1 sign_extend:0 (586) swap ? type:addr ? type:int64 (587) declare_temp ? type:addr ? temp var type:addr size:0x40 alignment:0x40 (588) store ? type:addr ? type:addr ? store (noname) offset:0x0 src_t:addr dst_t:addr (589) load ? type:addr ? type:addr ? m3cg_load (noname): offset 0x0, convert addr -> addr (590) load_indirect ? type:word8 ? type:int64 ? load address offset:0x38 src_t:word8 dst_t:int64 (591) swap ? type:int64 ? type:word8 (592) insert_mn ? type:int64 ?insert_mn offset:7 count:1 (593) load ? type:addr ? type:addr ? m3cg_load (noname): offset 0x0, convert addr -> addr (594) swap ? type:word8 ? type:addr (595) store_indirect ? type:int64 ? type:word8 ? store indirect offset:0x38 src_t:int64 dst_t:word8 (596) set_source_line ? source line? 120 (597) load ? type:lreal ? type:lreal ? m3cg_load (M3_CtKayy_res): offset 0x0, convert lreal -> lreal (598) exit_proc ? type:lreal (599) free_temp (600) end_procedure ? procedure LongFloat__CopySign ?- Jay From hosking at cs.purdue.edu Tue Jul 6 15:50:33 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 6 Jul 2010 09:50:33 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20100706055833.118D21A2080@async.async.caltech.edu> References: <20100705132228.0E6D52474003@birch.elegosoft.com>, <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu>, , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu>, , <6331F39C-AA28-4AC1-8C87-3D47D52D0C55@cs.purdue.edu>, , <02F12035-7271-4004-BE67-3DAB17C37B3B@cs.purdue.edu> <20100706055833.118D21A2080@async.async.caltech.edu> Message-ID: Thanks Mika, That's what I was hoping to express but I was too tired. I don't think we can convince Jay, but I do want him to understand at least that there is strong resistance to his desire to add all of these value initialisers, and that it really is not a priority. On 6 Jul 2010, at 01:58, Mika Nystrom wrote: > > As I've said before, > > When I write: > > VAR > a : INTEGER; > BEGIN > > ... > > .... a := .. ... > > ... > > END > > that means I am putting you, the reader, on notice that I have no > particularly meaningful idea of what a's initial value is. > > If I were to write > > VAR > a := 0; > BEGIN > ... > END > > I would mislead you into thinking that 0 is a somehow important > initial value. Which it's not. It's just garbage, and it better > not show up in the computation! > > Programs are mainly meant to be read by humans, not computers. > > Mika > > > Jay K writes: >> --_d2468f3b-9666-4291-98b5-5414421f54d9_ >> Content-Type: text/plain; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> >> We are going in circles. From hosking at cs.purdue.edu Tue Jul 6 15:58:19 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 6 Jul 2010 09:58:19 -0400 Subject: [M3devel] yet another proposed fix.. careful insertion of one instance of CG.Force() in CastExpr.m3 In-Reply-To: References: Message-ID: <0FABE0B5-71CE-49F8-BD07-688EA9DC1C17@cs.purdue.edu> I wonder if we should be forcing all D_to_S? Is it really only floats that cause this problem? Why would that be the case? On 6 Jul 2010, at 08:28, Jay K wrote: > > Ok, this is interesting. I think. Finally. > I need to test more, but it is looking very promising. I think you'll like it (Tony). > I still don't understand all the flow around the front end. I had to try out some guesses. > It certainly appears that m3front/src/misc/CG.m3 is in the business of optimizations. > This change might actually be too conservative. > It defeats optimization in CG.m3. It limits it to D_to_S when one type is float and the other isn't. > I guess S (struct) can't really be float. > > > The assertion failure in gcc btw, was gcc_assert( something_is_float == other_is_float). > So the conservativeness is somewhat sensible. > Limiting it to D_to_S, though, unclear. > > > The change is just inserting CG.Force(). > > > OK? (Let me test a bit more -- build the entire tree.) > > This appears to let me leave "ter" on. > I can try leaving other optimizations on. > > > Index: exprs/CastExpr.m3 > =================================================================== > RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/CastExpr.m3,v > retrieving revision 1.9 > diff -u -r1.9 CastExpr.m3 > --- exprs/CastExpr.m3 5 Jul 2010 11:28:32 -0000 1.9 > +++ exprs/CastExpr.m3 6 Jul 2010 12:23:14 -0000 > @@ -10,6 +10,7 @@ > > IMPORT M3Buf, CG, Expr, ExprRep, Type, Error, OpenArrayType; > IMPORT M3, M3ID, M3RT, Target, TInt; > +FROM Target IMPORT FloatType; > > TYPE > Kind = { > @@ -394,7 +395,7 @@ > u := Expr.TypeOf (e); > t := p.tipe; > sz, t_align, u_align, z_align: INTEGER; > - u_cg: CG.Type; > + u_cg, t_cg: CG.Type; > u_info, t_info: Type.Info; > BEGIN > u := Type.CheckInfo (u, u_info); > @@ -403,6 +404,7 @@ > u_align := u_info.alignment; > z_align := MAX (t_align, u_align); > u_cg := u_info.stk_type; > + t_cg := t_info.stk_type; > sz := u_info.size; > Type.Compile (t); > Type.Compile (u); > @@ -416,6 +418,15 @@ > Kind.V_to_V => > Expr.CompileLValue (p.expr, traced); > CG.Boost_alignment (t_align); > +(* Inhibit some optimization that causes compilation to fail. e.g. m3core: > +../src/float/IEEE/RealFloat.m3: In function 'RealFloat__CopySign': > +../src/float/IEEE/RealFloat.m3:96: internal compiler error: in convert_move, at expr.c:371 > +../src/float/IEEE/LongFloat.m3: In function 'LongFloat__CopySign': > +../src/float/IEEE/LongFloat.m3:116: internal compiler error: in convert_move, at expr.c:371 > +*) > + IF p.kind = Kind.D_to_S AND FloatType[u_cg] # FloatType[t_cg] THEN > + CG.Force (); > + END; > > | Kind.D_to_A, > Kind.S_to_A, > > > > (577) begin_procedure > procedure LongFloat__CopySign > LongFloat__CopySign(578) set_source_line > source line 117 > (579) load > type:lreal > type:lreal > m3cg_load (M3_CtKayy_x): offset 0x0, convert lreal -> lreal > (580) store > type:lreal > type:lreal > store (M3_CtKayy_res) offset:0x0 src_t:lreal dst_t:lreal > (581) set_source_line > source line 119 > > > now notice we have use of load_address and load_indirect here, where before we had no address and load (direct) > > > (582) load_address > load address (M3_CtKayy_res) offset 0x0 > (583) load_address > load address (M3_CtKayy_y) offset 0x0 > (584) load_indirect > type:word8 > type:int64 > load address offset:0x38 src_t:word8 dst_t:int64 > (585) extract_mn > type:int64 > extract_mn offset:7 count:1 sign_extend:0 > (586) swap > type:addr > type:int64 > (587) declare_temp > type:addr > temp var type:addr size:0x40 alignment:0x40 > (588) store > type:addr > type:addr > store (noname) offset:0x0 src_t:addr dst_t:addr > (589) load > type:addr > type:addr > m3cg_load (noname): offset 0x0, convert addr -> addr > (590) load_indirect > type:word8 > type:int64 > load address offset:0x38 src_t:word8 dst_t:int64 > (591) swap > type:int64 > type:word8 > (592) insert_mn > type:int64 > insert_mn offset:7 count:1 > (593) load > type:addr > type:addr > m3cg_load (noname): offset 0x0, convert addr -> addr > (594) swap > type:word8 > type:addr > (595) store_indirect > type:int64 > type:word8 > store indirect offset:0x38 src_t:int64 dst_t:word8 > (596) set_source_line > source line 120 > (597) load > type:lreal > type:lreal > m3cg_load (M3_CtKayy_res): offset 0x0, convert lreal -> lreal > (598) exit_proc > type:lreal > (599) free_temp > (600) end_procedure > procedure LongFloat__CopySign > > > > - Jay > > From rodney_bates at lcwb.coop Tue Jul 6 17:11:55 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 06 Jul 2010 10:11:55 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20100706055833.118D21A2080@async.async.caltech.edu> References: <20100705132228.0E6D52474003@birch.elegosoft.com>, <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu>, , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu>, , <6331F39C-AA28-4AC1-8C87-3D47D52D0C55@cs.purdue.edu>, , <02F12035-7271-4004-BE67-3DAB17C37B3B@cs.purdue.edu> <20100706055833.118D21A2080@async.async.caltech.edu> Message-ID: <4C3347BB.3050206@lcwb.coop> Mika Nystrom wrote: > As I've said before, > > When I write: > > VAR > a : INTEGER; > BEGIN > > ... > > .... a := .. ... > > ... > > END > > that means I am putting you, the reader, on notice that I have no > particularly meaningful idea of what a's initial value is. > > If I were to write > > VAR > a := 0; > BEGIN > ... > END > > I would mislead you into thinking that 0 is a somehow important > initial value. Which it's not. It's just garbage, and it better > not show up in the computation! I often write an initialization in a variable declaration that I fully expect will be overwritten before it is used, assuming I don't make a mistake elsewhere. I do this probably more often in field declarations of record and object types than in variables. I do it because it makes bugs more likely to be repeatable. This is at the cost that it may occasionally make a bug go unnoticed altogether because the initial value happens to suppress an obvious symptom. *But*, if it's code I wrote in the last ten years, or maybe fifteen, such initializations always have (* Paranoid. *) or (* Defensive. *) or a similar comment, for exactly Mika's reason. It tells a reader that this value is intended not be algorithmically significant. I suppose one could assume that an implementation of Modula-3 would initialize things consistently, but that relies on something that is not a rule of the language. Moreover, it is very likely not true for a type where all bit patterns represent members of the type. Sometimes I try to pick a really weird value, just so it will be more conspicuous and more likely to trigger a symptom, if it ever gets mistakenly used. This also helps in a debugger just to see if a real algorithmic initialization has ever been reached. For many types, I often reserve a distinct value to mean "unknown" or "meaningless", for some reason or other. Sometimes I even have more than one such special value. > > Programs are mainly meant to be read by humans, not computers. > > Mika > > > Jay K writes: >> --_d2468f3b-9666-4291-98b5-5414421f54d9_ >> Content-Type: text/plain; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> >> We are going in circles. > From hosking at cs.purdue.edu Tue Jul 6 17:45:21 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 6 Jul 2010 11:45:21 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <4C3347BB.3050206@lcwb.coop> References: <20100705132228.0E6D52474003@birch.elegosoft.com>, <759A98E1-3098-49B8-BC68-B9B3F54D4230@cs.purdue.edu>, , <3B74FBBA-DEE1-43E8-AB9D-631AA959D6B4@cs.purdue.edu>, , <08FF7A56-401D-49FD-A943-155B94BE41C4@cs.purdue.edu>, , <6331F39C-AA28-4AC1-8C87-3D47D52D0C55@cs.purdue.edu>, , <02F12035-7271-4004-BE67-3DAB17C37B3B@cs.purdue.edu> <20100706055833.118D21A2080@async.async.caltech.edu> <4C3347BB.3050206@lcwb.coop> Message-ID: <0B0BBBE5-3841-48BF-BB4F-E27EBDFBBEEF@cs.purdue.edu> I guess I just don't see the difference between writing: := 0 or := 1234567 or := -1 other than perhaps efficiency. In which case, excepting that you have a *known* initial value, writing: : INTEGER is no less expressive. On 6 Jul 2010, at 11:11, Rodney M. Bates wrote: > > > Mika Nystrom wrote: >> As I've said before, >> When I write: >> VAR a : INTEGER; >> BEGIN >> ... >> .... a := .. ... >> ... >> END >> that means I am putting you, the reader, on notice that I have no >> particularly meaningful idea of what a's initial value is. >> If I were to write VAR a := 0; >> BEGIN >> ... >> END >> I would mislead you into thinking that 0 is a somehow important >> initial value. Which it's not. It's just garbage, and it better >> not show up in the computation! > > I often write an initialization in a variable declaration that I > fully expect will be overwritten before it is used, assuming I > don't make a mistake elsewhere. I do this probably more often > in field declarations of record and object types than in variables. > > I do it because it makes bugs more likely to be repeatable. > This is at the cost that it may occasionally make a bug go > unnoticed altogether because the initial value happens to > suppress an obvious symptom. > > *But*, if it's code I wrote in the last ten years, or > maybe fifteen, such initializations always have (* Paranoid. *) > or (* Defensive. *) or a similar comment, for exactly Mika's > reason. It tells a reader that this value is intended not be > algorithmically significant. > > I suppose one could assume that an implementation of Modula-3 > would initialize things consistently, but that relies on > something that is not a rule of the language. Moreover, it > is very likely not true for a type where all bit patterns > represent members of the type. > > Sometimes I try to pick a really weird value, just so > it will be more conspicuous and more likely to trigger > a symptom, if it ever gets mistakenly used. This also helps > in a debugger just to see if a real algorithmic initialization > has ever been reached. > > For many types, I often reserve a distinct value to mean "unknown" > or "meaningless", for some reason or other. Sometimes I even > have more than one such special value. > > >> Programs are mainly meant to be read by humans, not computers. >> Mika >> Jay K writes: >>> --_d2468f3b-9666-4291-98b5-5414421f54d9_ >>> Content-Type: text/plain; charset="iso-8859-1" >>> Content-Transfer-Encoding: quoted-printable >>> >>> >>> We are going in circles. From hendrik at topoi.pooq.com Tue Jul 6 18:53:56 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 6 Jul 2010 12:53:56 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20100706055833.118D21A2080@async.async.caltech.edu> <20100706063458.DCFF41A2080@async.async.caltech.edu> Message-ID: <20100706165355.GA1520@topoi.pooq.com> On Tue, Jul 06, 2010 at 10:05:43AM +0000, Jay K wrote: > > > used it should be a giant red flag to the reader that the variable x is > > going to be initialized with a value that the programmer doesn't know > > at the time of declaration. What on earth do you gain from x := 0? > > A "little correctness"? > > You are making the code more expensive to maintain, by making > it harder for a human to analyze. For the benefit of microoptimization. Microoptimisation as a purpose? Didn't he just explain that VAR x : INTEGER; is intended to signal to the *reader* that the initial value is irrelevant? The fact that a naive compiler might compile it slightly more efficiently is a side effect, not a purpose. If he were interested in microoptimisation, he would better feed it into a flow-analysing compiler, which could even detect when an explicit initialization like VAR x := 0; is irrelevant and suppress it. It's not *about* optimisation. Indeed, they syntactic awkwardness of declaring variables with WITH (to make sure they're initialized where they're declared) is one of the problems of Modula 3, and one of the few places where C did it better. Granted C, didn't do this at all initially, and took it from Algol 68 in one of C's rounds of standardisation. -- hendrik From hendrik at topoi.pooq.com Tue Jul 6 19:02:28 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 6 Jul 2010 13:02:28 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20100706055833.118D21A2080@async.async.caltech.edu> Message-ID: <20100706170228.GB1520@topoi.pooq.com> On Tue, Jul 06, 2010 at 06:22:50AM +0000, Jay K wrote: > > Programmers are notorious for making mistakes. > > > When you write VAR a:INTEGER; > you make the human proofreading your code have to work much harder > to do the data/control flow analysis to make sure you didn't > use the uninitialized value. > > > Using the a := 0 value might still be "wrong", but is it at least consistent > and the penalty for getting it wrong is generally less severe. > > Now, I don't want there to be a bug either way, but I feel that a consistent 0 is much "safer" > than uninitialized. Either is typesafe, sure, but type safe is just the bare minimum expectation > for my code. It must not only be type safe, but act correctly. > > Again, compiler isn't generally a program proofer, but the little it can do, let it do. Agree with letting the compiler find flaws by flow analysis and report them, if it can. But explicitly initializing it so zero so that (a) the ocmpiler won't notice it's really uninitilized, and (b) it's going to have less of a penalty for getting it wrong? I disagree with this. If there's a bug in my program I want to find it so I can fix it. I don't want it masked by an arbitrary but innocuous initial value. Here's where letting the ocmpiler initialize undefined integer variables to something like 1683002888 might actually contribute to debugging, especially if it chooses this consistently so you can rerun the program reliable while you close in on the error. But for the programmer to write VAR x := 1683002888; would likely confuse the human reader, who would spend ages pondering why *that* value. - hendrik From hosking at cs.purdue.edu Tue Jul 6 19:00:21 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 6 Jul 2010 13:00:21 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20100706165355.GA1520@topoi.pooq.com> References: <20100706055833.118D21A2080@async.async.caltech.edu> <20100706063458.DCFF41A2080@async.async.caltech.edu> <20100706165355.GA1520@topoi.pooq.com> Message-ID: I agree. If Modula-3 was being designed today it would impose the same ban on uninitialized use of variables that Java does. We have a language that does not impose that ban, but instead assures that every ininitialized variable holds a valid value. I much prefer to see VAR x: INTEGER as an *explicit* marker that the variable holds an indeterminate but valid value. Seeing VAR x := 0 implies to me that there is something especially significant about the initial value 0. On 6 Jul 2010, at 12:53, hendrik at topoi.pooq.com wrote: > On Tue, Jul 06, 2010 at 10:05:43AM +0000, Jay K wrote: >> >>> used it should be a giant red flag to the reader that the variable x is >>> going to be initialized with a value that the programmer doesn't know >>> at the time of declaration. What on earth do you gain from x := 0? >>> A "little correctness"? >> >> You are making the code more expensive to maintain, by making >> it harder for a human to analyze. For the benefit of microoptimization. > > Microoptimisation as a purpose? Didn't he just explain that > VAR x : INTEGER; > is intended to signal to the *reader* that the initial value is > irrelevant? The fact that a naive compiler might compile it slightly > more efficiently is a side effect, not a purpose. If he were interested > in microoptimisation, he would better feed it into a flow-analysing > compiler, which could even detect when an explicit initialization like > VAR x := 0; > is irrelevant and suppress it. > > It's not *about* optimisation. > > Indeed, they syntactic awkwardness of declaring variables with WITH > (to make sure they're initialized where they're declared) is one of > the problems of Modula 3, and one of the few places where C did it > better. Granted C, didn't do this at all initially, and took it from > Algol 68 in one of C's rounds of standardisation. > > -- hendrik From hosking at cs.purdue.edu Tue Jul 6 19:04:36 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 6 Jul 2010 13:04:36 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20100706170228.GB1520@topoi.pooq.com> References: <20100706055833.118D21A2080@async.async.caltech.edu> <20100706170228.GB1520@topoi.pooq.com> Message-ID: So, here is a proposal. Why not have a flag to the M3 compiler that tells it to initialise every value with zero for numbers, NIL for references, or FIRST(T) for enumerations/subranges? I am sure we can come up with something reasonable for all the primitive types. This would be an aid to debugging, but avoid the need for explicit initialisation be expressed in the code. Then, if you find yourself wondering if an uninitialised variable is the culprit for some bug then you can simply turn on the flag. It would also have the side-effect of passing the flag Jay is using to the cm3cg backend. On 6 Jul 2010, at 13:02, hendrik at topoi.pooq.com wrote: > On Tue, Jul 06, 2010 at 06:22:50AM +0000, Jay K wrote: >> >> Programmers are notorious for making mistakes. >> >> >> When you write VAR a:INTEGER; >> you make the human proofreading your code have to work much harder >> to do the data/control flow analysis to make sure you didn't >> use the uninitialized value. >> >> >> Using the a := 0 value might still be "wrong", but is it at least consistent >> and the penalty for getting it wrong is generally less severe. >> >> Now, I don't want there to be a bug either way, but I feel that a consistent 0 is much "safer" >> than uninitialized. Either is typesafe, sure, but type safe is just the bare minimum expectation >> for my code. It must not only be type safe, but act correctly. >> >> Again, compiler isn't generally a program proofer, but the little it can do, let it do. > > Agree with letting the compiler find flaws by flow analysis and > report them, if it can. > > But explicitly initializing it so zero so that (a) the ocmpiler won't > notice it's really uninitilized, and (b) it's going to have less of a > penalty for getting it wrong? I disagree with this. If there's a bug > in my program I want to find it so I can fix it. I don't want it > masked by an arbitrary but innocuous initial value. > > Here's where letting the ocmpiler initialize undefined integer > variables to something like 1683002888 might actually contribute to > debugging, especially if it chooses this consistently so you can rerun > the program reliable while you close in on the error. > > But for the programmer to write > > VAR x := 1683002888; > > would likely confuse the human reader, who would spend ages pondering > why *that* value. > > - hendrik From hosking at cs.purdue.edu Tue Jul 6 19:10:34 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 6 Jul 2010 13:10:34 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20100706055833.118D21A2080@async.async.caltech.edu> <20100706170228.GB1520@topoi.pooq.com> Message-ID: Or, alternatively, we could turn it around and have a flag that turns off (for performance if desired) well-defined initialisations (much like nochecks does to turn off other runtime checks). This would be in the spirit of the language spec, which says simply that some legal value is present, and simply go one step further in making the initialised value deterministic. As far as I can tell, this changes only the behaviour of "automatic" variables (function-scope local variables) whose initial value can be any combination of bits in the variable. All other variables get deterministic initial values already. On 6 Jul 2010, at 13:04, Tony Hosking wrote: > So, here is a proposal. > Why not have a flag to the M3 compiler that tells it to initialise every value with zero for numbers, NIL for references, or FIRST(T) for enumerations/subranges? I am sure we can come up with something reasonable for all the primitive types. > This would be an aid to debugging, but avoid the need for explicit initialisation be expressed in the code. > > Then, if you find yourself wondering if an uninitialised variable is the culprit for some bug then you can simply turn on the flag. > It would also have the side-effect of passing the flag Jay is using to the cm3cg backend. > > On 6 Jul 2010, at 13:02, hendrik at topoi.pooq.com wrote: > >> On Tue, Jul 06, 2010 at 06:22:50AM +0000, Jay K wrote: >>> >>> Programmers are notorious for making mistakes. >>> >>> >>> When you write VAR a:INTEGER; >>> you make the human proofreading your code have to work much harder >>> to do the data/control flow analysis to make sure you didn't >>> use the uninitialized value. >>> >>> >>> Using the a := 0 value might still be "wrong", but is it at least consistent >>> and the penalty for getting it wrong is generally less severe. >>> >>> Now, I don't want there to be a bug either way, but I feel that a consistent 0 is much "safer" >>> than uninitialized. Either is typesafe, sure, but type safe is just the bare minimum expectation >>> for my code. It must not only be type safe, but act correctly. >>> >>> Again, compiler isn't generally a program proofer, but the little it can do, let it do. >> >> Agree with letting the compiler find flaws by flow analysis and >> report them, if it can. >> >> But explicitly initializing it so zero so that (a) the ocmpiler won't >> notice it's really uninitilized, and (b) it's going to have less of a >> penalty for getting it wrong? I disagree with this. If there's a bug >> in my program I want to find it so I can fix it. I don't want it >> masked by an arbitrary but innocuous initial value. >> >> Here's where letting the ocmpiler initialize undefined integer >> variables to something like 1683002888 might actually contribute to >> debugging, especially if it chooses this consistently so you can rerun >> the program reliable while you close in on the error. >> >> But for the programmer to write >> >> VAR x := 1683002888; >> >> would likely confuse the human reader, who would spend ages pondering >> why *that* value. >> >> - hendrik > From hendrik at topoi.pooq.com Tue Jul 6 19:23:05 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 6 Jul 2010 13:23:05 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20100706055833.118D21A2080@async.async.caltech.edu> <20100706170228.GB1520@topoi.pooq.com> Message-ID: <20100706172305.GC1520@topoi.pooq.com> On Tue, Jul 06, 2010 at 01:10:34PM -0400, Tony Hosking wrote: > Or, alternatively, we could turn it around and have a flag that turns off (for performance if desired) well-defined initialisations (much like nochecks does to turn off other runtime checks). This would be in the spirit of the language spec, which says simply that some legal value is present, and simply go one step further in making the initialised value deterministic. As far as I can tell, this changes only the behaviour of "automatic" variables (function-scope local variables) whose initial value can be any combination of bits in the variable. All other variables get deterministic initial values already. A flag like that that uses a consistent junk value would also be useful, since it's less likely to be accidentally masked. Zero is far too commonly valid for the application, and not just valid for the language. -- hendrik From hosking at cs.purdue.edu Tue Jul 6 21:18:26 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 6 Jul 2010 15:18:26 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20100706172305.GC1520@topoi.pooq.com> References: <20100706055833.118D21A2080@async.async.caltech.edu> <20100706170228.GB1520@topoi.pooq.com> <20100706172305.GC1520@topoi.pooq.com> Message-ID: <4147B852-EA8F-49A7-94DF-81EFE5F76EDA@cs.purdue.edu> I was proposing a 0 value in the common case (where 0 bits are valid for the type). On 6 Jul 2010, at 13:23, hendrik at topoi.pooq.com wrote: > On Tue, Jul 06, 2010 at 01:10:34PM -0400, Tony Hosking wrote: >> Or, alternatively, we could turn it around and have a flag that turns off (for performance if desired) well-defined initialisations (much like nochecks does to turn off other runtime checks). This would be in the spirit of the language spec, which says simply that some legal value is present, and simply go one step further in making the initialised value deterministic. As far as I can tell, this changes only the behaviour of "automatic" variables (function-scope local variables) whose initial value can be any combination of bits in the variable. All other variables get deterministic initial values already. > > A flag like that that uses a consistent junk value would also be > useful, since it's less likely to be accidentally masked. Zero is far > too commonly valid for the application, and not just valid for the > language. > > -- hendrik From jay.krell at cornell.edu Tue Jul 6 21:20:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Jul 2010 19:20:04 +0000 Subject: [M3devel] yet another proposed fix.. careful insertion of one instance of CG.Force() in CastExpr.m3 In-Reply-To: <0FABE0B5-71CE-49F8-BD07-688EA9DC1C17@cs.purdue.edu> References: , <0FABE0B5-71CE-49F8-BD07-688EA9DC1C17@cs.purdue.edu> Message-ID: Right, that's what I meant by "too conservative". The change is acceptable as a start asis, right? We can soon thereafter evaluate expanding it? ? Well, the danger in being too conservative, is I'll allow "ter" optimization, and then bad code could creep in when optimizing. ? I can build the system this way and Juno, mentor minimally work. I could have sworn mentor wasn't "running" (the ? algorithms weren't showing anything in the GUI), but I deleted ~/.zeusState and rebuilt again and it seems ok now) btw, I forgot to say, the nice thing about that make_volatile change is, it'd be available to us in a pinch to inhibit optimizations if/when they cause other problems. ?- Jay ---------------------------------------- > Subject: Re: yet another proposed fix.. careful insertion of one instance of CG.Force() in CastExpr.m3 > From: hosking at cs.purdue.edu > Date: Tue, 6 Jul 2010 09:58:19 -0400 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > I wonder if we should be forcing all D_to_S? Is it really only floats that cause this problem? Why would that be the case? > > On 6 Jul 2010, at 08:28, Jay K wrote: > > > > > Ok, this is interesting. I think. Finally. > > I need to test more, but it is looking very promising. I think you'll like it (Tony). > > I still don't understand all the flow around the front end. I had to try out some guesses. > > It certainly appears that m3front/src/misc/CG.m3 is in the business of optimizations. > > This change might actually be too conservative. > > It defeats optimization in CG.m3. It limits it to D_to_S when one type is float and the other isn't. > > I guess S (struct) can't really be float. > > > > > > The assertion failure in gcc btw, was gcc_assert( something_is_float == other_is_float). > > So the conservativeness is somewhat sensible. > > Limiting it to D_to_S, though, unclear. > > > > > > The change is just inserting CG.Force(). > > > > > > OK? (Let me test a bit more -- build the entire tree.) > > > > This appears to let me leave "ter" on. > > I can try leaving other optimizations on. > > > > > > Index: exprs/CastExpr.m3 > > =================================================================== > > RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/CastExpr.m3,v > > retrieving revision 1.9 > > diff -u -r1.9 CastExpr.m3 > > --- exprs/CastExpr.m3 5 Jul 2010 11:28:32 -0000 1.9 > > +++ exprs/CastExpr.m3 6 Jul 2010 12:23:14 -0000 > > @@ -10,6 +10,7 @@ > > > > IMPORT M3Buf, CG, Expr, ExprRep, Type, Error, OpenArrayType; > > IMPORT M3, M3ID, M3RT, Target, TInt; > > +FROM Target IMPORT FloatType; > > > > TYPE > > Kind = { > > @@ -394,7 +395,7 @@ > > u := Expr.TypeOf (e); > > t := p.tipe; > > sz, t_align, u_align, z_align: INTEGER; > > - u_cg: CG.Type; > > + u_cg, t_cg: CG.Type; > > u_info, t_info: Type.Info; > > BEGIN > > u := Type.CheckInfo (u, u_info); > > @@ -403,6 +404,7 @@ > > u_align := u_info.alignment; > > z_align := MAX (t_align, u_align); > > u_cg := u_info.stk_type; > > + t_cg := t_info.stk_type; > > sz := u_info.size; > > Type.Compile (t); > > Type.Compile (u); > > @@ -416,6 +418,15 @@ > > Kind.V_to_V => > > Expr.CompileLValue (p.expr, traced); > > CG.Boost_alignment (t_align); > > +(* Inhibit some optimization that causes compilation to fail. e.g. m3core: > > +../src/float/IEEE/RealFloat.m3: In function 'RealFloat__CopySign': > > +../src/float/IEEE/RealFloat.m3:96: internal compiler error: in convert_move, at expr.c:371 > > +../src/float/IEEE/LongFloat.m3: In function 'LongFloat__CopySign': > > +../src/float/IEEE/LongFloat.m3:116: internal compiler error: in convert_move, at expr.c:371 > > +*) > > + IF p.kind = Kind.D_to_S AND FloatType[u_cg] # FloatType[t_cg] THEN > > + CG.Force (); > > + END; > > > > | Kind.D_to_A, > > Kind.S_to_A, > > > > > > > > (577) begin_procedure > > procedure LongFloat__CopySign > > LongFloat__CopySign(578) set_source_line > > source line 117 > > (579) load > > type:lreal > > type:lreal > > m3cg_load (M3_CtKayy_x): offset 0x0, convert lreal -> lreal > > (580) store > > type:lreal > > type:lreal > > store (M3_CtKayy_res) offset:0x0 src_t:lreal dst_t:lreal > > (581) set_source_line > > source line 119 > > > > > > now notice we have use of load_address and load_indirect here, where before we had no address and load (direct) > > > > > > (582) load_address > > load address (M3_CtKayy_res) offset 0x0 > > (583) load_address > > load address (M3_CtKayy_y) offset 0x0 > > (584) load_indirect > > type:word8 > > type:int64 > > load address offset:0x38 src_t:word8 dst_t:int64 > > (585) extract_mn > > type:int64 > > extract_mn offset:7 count:1 sign_extend:0 > > (586) swap > > type:addr > > type:int64 > > (587) declare_temp > > type:addr > > temp var type:addr size:0x40 alignment:0x40 > > (588) store > > type:addr > > type:addr > > store (noname) offset:0x0 src_t:addr dst_t:addr > > (589) load > > type:addr > > type:addr > > m3cg_load (noname): offset 0x0, convert addr -> addr > > (590) load_indirect > > type:word8 > > type:int64 > > load address offset:0x38 src_t:word8 dst_t:int64 > > (591) swap > > type:int64 > > type:word8 > > (592) insert_mn > > type:int64 > > insert_mn offset:7 count:1 > > (593) load > > type:addr > > type:addr > > m3cg_load (noname): offset 0x0, convert addr -> addr > > (594) swap > > type:word8 > > type:addr > > (595) store_indirect > > type:int64 > > type:word8 > > store indirect offset:0x38 src_t:int64 dst_t:word8 > > (596) set_source_line > > source line 120 > > (597) load > > type:lreal > > type:lreal > > m3cg_load (M3_CtKayy_res): offset 0x0, convert lreal -> lreal > > (598) exit_proc > > type:lreal > > (599) free_temp > > (600) end_procedure > > procedure LongFloat__CopySign > > > > > > > > - Jay > > > > > From hosking at cs.purdue.edu Tue Jul 6 21:23:47 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 6 Jul 2010 15:23:47 -0400 Subject: [M3devel] yet another proposed fix.. careful insertion of one instance of CG.Force() in CastExpr.m3 In-Reply-To: References: , <0FABE0B5-71CE-49F8-BD07-688EA9DC1C17@cs.purdue.edu> Message-ID: <2A836943-BEB7-4D5C-928B-65FD2098DF6D@cs.purdue.edu> On 6 Jul 2010, at 15:20, Jay K wrote: > Right, that's what I meant by "too conservative". I am ok with forcing in all D_to_S cases. > The change is acceptable as a start asis, right? We can soon thereafter evaluate expanding it? > Well, the danger in being too conservative, is I'll allow "ter" optimization, and then bad code could creep in when optimising. I don't think that will happen with the force, since we will make it in memory for gcc which will probably then be much happier. > I can build the system this way and Juno, mentor minimally work. I could have sworn mentor wasn't "running" (the > algorithms weren't showing anything in the GUI), but I deleted ~/.zeusState and rebuilt again and it seems ok now) OK, great. > btw, I forgot to say, the nice thing about that make_volatile change is, it'd be available to us in a pinch to inhibit > optimizations if/when they cause other problems. I am extremely leery of introducing hacks into the IR that we will later regret. The rot will set in... > > - Jay > > ---------------------------------------- >> Subject: Re: yet another proposed fix.. careful insertion of one instance of CG.Force() in CastExpr.m3 >> From: hosking at cs.purdue.edu >> Date: Tue, 6 Jul 2010 09:58:19 -0400 >> CC: m3devel at elegosoft.com >> To: jay.krell at cornell.edu >> >> I wonder if we should be forcing all D_to_S? Is it really only floats that cause this problem? Why would that be the case? >> >> On 6 Jul 2010, at 08:28, Jay K wrote: >> >>> >>> Ok, this is interesting. I think. Finally. >>> I need to test more, but it is looking very promising. I think you'll like it (Tony). >>> I still don't understand all the flow around the front end. I had to try out some guesses. >>> It certainly appears that m3front/src/misc/CG.m3 is in the business of optimizations. >>> This change might actually be too conservative. >>> It defeats optimization in CG.m3. It limits it to D_to_S when one type is float and the other isn't. >>> I guess S (struct) can't really be float. >>> >>> >>> The assertion failure in gcc btw, was gcc_assert( something_is_float == other_is_float). >>> So the conservativeness is somewhat sensible. >>> Limiting it to D_to_S, though, unclear. >>> >>> >>> The change is just inserting CG.Force(). >>> >>> >>> OK? (Let me test a bit more -- build the entire tree.) >>> >>> This appears to let me leave "ter" on. >>> I can try leaving other optimizations on. >>> >>> >>> Index: exprs/CastExpr.m3 >>> =================================================================== >>> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/exprs/CastExpr.m3,v >>> retrieving revision 1.9 >>> diff -u -r1.9 CastExpr.m3 >>> --- exprs/CastExpr.m3 5 Jul 2010 11:28:32 -0000 1.9 >>> +++ exprs/CastExpr.m3 6 Jul 2010 12:23:14 -0000 >>> @@ -10,6 +10,7 @@ >>> >>> IMPORT M3Buf, CG, Expr, ExprRep, Type, Error, OpenArrayType; >>> IMPORT M3, M3ID, M3RT, Target, TInt; >>> +FROM Target IMPORT FloatType; >>> >>> TYPE >>> Kind = { >>> @@ -394,7 +395,7 @@ >>> u := Expr.TypeOf (e); >>> t := p.tipe; >>> sz, t_align, u_align, z_align: INTEGER; >>> - u_cg: CG.Type; >>> + u_cg, t_cg: CG.Type; >>> u_info, t_info: Type.Info; >>> BEGIN >>> u := Type.CheckInfo (u, u_info); >>> @@ -403,6 +404,7 @@ >>> u_align := u_info.alignment; >>> z_align := MAX (t_align, u_align); >>> u_cg := u_info.stk_type; >>> + t_cg := t_info.stk_type; >>> sz := u_info.size; >>> Type.Compile (t); >>> Type.Compile (u); >>> @@ -416,6 +418,15 @@ >>> Kind.V_to_V => >>> Expr.CompileLValue (p.expr, traced); >>> CG.Boost_alignment (t_align); >>> +(* Inhibit some optimization that causes compilation to fail. e.g. m3core: >>> +../src/float/IEEE/RealFloat.m3: In function 'RealFloat__CopySign': >>> +../src/float/IEEE/RealFloat.m3:96: internal compiler error: in convert_move, at expr.c:371 >>> +../src/float/IEEE/LongFloat.m3: In function 'LongFloat__CopySign': >>> +../src/float/IEEE/LongFloat.m3:116: internal compiler error: in convert_move, at expr.c:371 >>> +*) >>> + IF p.kind = Kind.D_to_S AND FloatType[u_cg] # FloatType[t_cg] THEN >>> + CG.Force (); >>> + END; >>> >>> | Kind.D_to_A, >>> Kind.S_to_A, >>> >>> >>> >>> (577) begin_procedure >>> procedure LongFloat__CopySign >>> LongFloat__CopySign(578) set_source_line >>> source line 117 >>> (579) load >>> type:lreal >>> type:lreal >>> m3cg_load (M3_CtKayy_x): offset 0x0, convert lreal -> lreal >>> (580) store >>> type:lreal >>> type:lreal >>> store (M3_CtKayy_res) offset:0x0 src_t:lreal dst_t:lreal >>> (581) set_source_line >>> source line 119 >>> >>> >>> now notice we have use of load_address and load_indirect here, where before we had no address and load (direct) >>> >>> >>> (582) load_address >>> load address (M3_CtKayy_res) offset 0x0 >>> (583) load_address >>> load address (M3_CtKayy_y) offset 0x0 >>> (584) load_indirect >>> type:word8 >>> type:int64 >>> load address offset:0x38 src_t:word8 dst_t:int64 >>> (585) extract_mn >>> type:int64 >>> extract_mn offset:7 count:1 sign_extend:0 >>> (586) swap >>> type:addr >>> type:int64 >>> (587) declare_temp >>> type:addr >>> temp var type:addr size:0x40 alignment:0x40 >>> (588) store >>> type:addr >>> type:addr >>> store (noname) offset:0x0 src_t:addr dst_t:addr >>> (589) load >>> type:addr >>> type:addr >>> m3cg_load (noname): offset 0x0, convert addr -> addr >>> (590) load_indirect >>> type:word8 >>> type:int64 >>> load address offset:0x38 src_t:word8 dst_t:int64 >>> (591) swap >>> type:int64 >>> type:word8 >>> (592) insert_mn >>> type:int64 >>> insert_mn offset:7 count:1 >>> (593) load >>> type:addr >>> type:addr >>> m3cg_load (noname): offset 0x0, convert addr -> addr >>> (594) swap >>> type:word8 >>> type:addr >>> (595) store_indirect >>> type:int64 >>> type:word8 >>> store indirect offset:0x38 src_t:int64 dst_t:word8 >>> (596) set_source_line >>> source line 120 >>> (597) load >>> type:lreal >>> type:lreal >>> m3cg_load (M3_CtKayy_res): offset 0x0, convert lreal -> lreal >>> (598) exit_proc >>> type:lreal >>> (599) free_temp >>> (600) end_procedure >>> procedure LongFloat__CopySign >>> >>> >>> >>> - Jay >>> >>> >> > From jay.krell at cornell.edu Tue Jul 6 22:21:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Jul 2010 20:21:08 +0000 Subject: [M3devel] fault reports beyond 100mill lines? Message-ID: It appears that if a file has over around 100 million lines, that fault reports (nil deref, subrange out of bounds, etc.) get the wrong line number. Leave it as ("qualit of implementation"?) or fail an assertion in the compiler earlier (leaving anyone with a huge file kind of stuck (generated?) or, unlikely, expand the range? The line number is in an integer along with a 5 bit fault code. ? We could also allow much larger numbers on 64bit targets. This is just because there's a "FIXME" comment in parse.c. The code is basically right and I'm adding comments and perhaps assertions. Certainly we can assert that the fault code is in range. I think I prefer silently losing bits in the line number, or conveting it to 0 if it is out of bounds or pinning it to maxint. ? Though it'd be maxint? / 32 which is less "special" looking if someone ever saw it.. though the runtime could ? report maxint / 32 as maxint. ?- Jay From jay.krell at cornell.edu Tue Jul 6 22:35:45 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 6 Jul 2010 20:35:45 +0000 Subject: [M3devel] fault reports beyond 100mill lines? In-Reply-To: References: Message-ID: I'm pretty settled on silently losing line numbers over 100 million. If the host and target are 64 bits it preserves far more. If someone produces such a file, and it compiles and runs, but gets a runtime error in their code on the wrong line, they can claim they found a compiler bug... ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Tue, 6 Jul 2010 20:21:08 +0000 > Subject: [M3devel] fault reports beyond 100mill lines? > > > It appears that if a file has over around 100 million lines, that fault reports (nil deref, subrange out of bounds, etc.) get the wrong line number. > Leave it as ("qualit of implementation"?) or fail an assertion in the compiler earlier (leaving anyone with a huge file kind of stuck (generated?) or, unlikely, expand the range? > The line number is in an integer along with a 5 bit fault code. > We could also allow much larger numbers on 64bit targets. > > > This is just because there's a "FIXME" comment in parse.c. > The code is basically right and I'm adding comments and perhaps assertions. > Certainly we can assert that the fault code is in range. > > > I think I prefer silently losing bits in the line number, or conveting it to 0 if it is out of bounds or pinning it to maxint. > Though it'd be maxint / 32 which is less "special" looking if someone ever saw it.. though the runtime could > report maxint / 32 as maxint. > > - Jay > > From rcolebur at SCIRES.COM Wed Jul 7 00:19:45 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Tue, 6 Jul 2010 18:19:45 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20100706055833.118D21A2080@async.async.caltech.edu> <20100706063458.DCFF41A2080@async.async.caltech.edu> <20100706165355.GA1520@topoi.pooq.com> Message-ID: I agree also. Let's not change the language here, and let's not change the compiler's behavior to no longer match the language. I don't have a problem with selectively turning on a warning level at compile time for compiler to warn me that I might be using a variable before it is initialized, but I don't want compiler choosing to initialize it for me. --Randy -----Original Message----- From: Tony Hosking [mailto:hosking at cs.purdue.edu] Sent: Tuesday, July 06, 2010 1:00 PM To: hendrik at topoi.pooq.com Cc: m3devel at elegosoft.com Subject: Re: [M3devel] [M3commit] CVS Update: cm3 I agree. If Modula-3 was being designed today it would impose the same ban on uninitialized use of variables that Java does. We have a language that does not impose that ban, but instead assures that every ininitialized variable holds a valid value. I much prefer to see VAR x: INTEGER as an *explicit* marker that the variable holds an indeterminate but valid value. Seeing VAR x := 0 implies to me that there is something especially significant about the initial value 0. On 6 Jul 2010, at 12:53, hendrik at topoi.pooq.com wrote: > On Tue, Jul 06, 2010 at 10:05:43AM +0000, Jay K wrote: >> >>> used it should be a giant red flag to the reader that the variable x is >>> going to be initialized with a value that the programmer doesn't know >>> at the time of declaration. What on earth do you gain from x := 0? >>> A "little correctness"? >> >> You are making the code more expensive to maintain, by making >> it harder for a human to analyze. For the benefit of microoptimization. > > Microoptimisation as a purpose? Didn't he just explain that > VAR x : INTEGER; > is intended to signal to the *reader* that the initial value is > irrelevant? The fact that a naive compiler might compile it slightly > more efficiently is a side effect, not a purpose. If he were interested > in microoptimisation, he would better feed it into a flow-analysing > compiler, which could even detect when an explicit initialization like > VAR x := 0; > is irrelevant and suppress it. > > It's not *about* optimisation. > > Indeed, they syntactic awkwardness of declaring variables with WITH > (to make sure they're initialized where they're declared) is one of > the problems of Modula 3, and one of the few places where C did it > better. Granted C, didn't do this at all initially, and took it from > Algol 68 in one of C's rounds of standardisation. > > -- hendrik From rodney_bates at lcwb.coop Wed Jul 7 00:41:55 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 06 Jul 2010 17:41:55 -0500 Subject: [M3devel] loophole/copysign In-Reply-To: <2F356C4B-5541-489B-B957-E3D295F549F5@cs.purdue.edu> References: <2F356C4B-5541-489B-B957-E3D295F549F5@cs.purdue.edu> Message-ID: <4C33B133.8020107@lcwb.coop> Tony Hosking wrote: > A designator is something that can be assigned to as well as read from. > It says nothing about it being in memory. A value cannot be assigned to. > Not necessarily. There are writable designators and readonly designators. The only things I find that can spontaneously produce a readonly designator are a READONLY formal and a FOR local. Several things produce writable designators, Lots of things propagate designator-ness around, and sometimes writability too. E.g., subscripting an array propagates each of these properties independently from the array to the selected element. ADR, BITSIZE, BYTESIZE, and ADRSIZE can be applied to a readonly designator (but not to a non-designator). Assignment, passing to a VAR formal, and DISPOSE require a writable designator. Although it is really an implementation- level distinction, these pretty well imply that a designator will have to be in memory. Not necessarily the converse, as, for example, a compiler could very well store the result of A+B in memory, but the language still forbids applying ADR to it, etc., leaving the compiler a choice. > On 5 Jul 2010, at 06:42, Jay K wrote: > >> Tony, et. al.. in m3front/src/exprs/CastExpr.m3..what's the difference between a "designator" and a "value"? > From hendrik at topoi.pooq.com Wed Jul 7 01:01:16 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 6 Jul 2010 19:01:16 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <4147B852-EA8F-49A7-94DF-81EFE5F76EDA@cs.purdue.edu> References: <20100706055833.118D21A2080@async.async.caltech.edu> <20100706170228.GB1520@topoi.pooq.com> <20100706172305.GC1520@topoi.pooq.com> <4147B852-EA8F-49A7-94DF-81EFE5F76EDA@cs.purdue.edu> Message-ID: <20100706230115.GA3124@topoi.pooq.com> On Tue, Jul 06, 2010 at 03:18:26PM -0400, Tony Hosking wrote: > I was proposing a 0 value in the common case (where 0 bits are valid for the type). Yes, I understood that. I'm pointing out that a nonzero value (also where valid) is likely to find more errors than a zero value, and that a consistent nonzero value will make it easier to actually find the errors, instead of just detect them. And it's less likely to lead to programs that run successfully only when you specify the option. -- hendrik From ttmrichter at gmail.com Wed Jul 7 05:56:43 2010 From: ttmrichter at gmail.com (Michael Richter) Date: Wed, 7 Jul 2010 11:56:43 +0800 Subject: [M3devel] fault reports beyond 100mill lines? In-Reply-To: References: Message-ID: Why the magic number of 100,000,000? Why not 4 billion, say? On 7 July 2010 04:35, Jay K wrote: > > I'm pretty settled on silently losing line numbers over 100 million. > If the host and target are 64 bits it preserves far more. > If someone produces such a file, and it compiles and runs, but gets a > runtime error in their code on the wrong line, they can claim they found a > compiler bug... > > - Jay > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: m3devel at elegosoft.com > > Date: Tue, 6 Jul 2010 20:21:08 +0000 > > Subject: [M3devel] fault reports beyond 100mill lines? > > > > > > It appears that if a file has over around 100 million lines, that fault > reports (nil deref, subrange out of bounds, etc.) get the wrong line number. > > Leave it as ("qualit of implementation"?) or fail an assertion in the > compiler earlier (leaving anyone with a huge file kind of stuck (generated?) > or, unlikely, expand the range? > > The line number is in an integer along with a 5 bit fault code. > > We could also allow much larger numbers on 64bit targets. > > > > > > This is just because there's a "FIXME" comment in parse.c. > > The code is basically right and I'm adding comments and perhaps > assertions. > > Certainly we can assert that the fault code is in range. > > > > > > I think I prefer silently losing bits in the line number, or conveting it > to 0 if it is out of bounds or pinning it to maxint. > > Though it'd be maxint / 32 which is less "special" looking if someone > ever saw it.. though the runtime could > > report maxint / 32 as maxint. > > > > - Jay > > > > > > -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Jul 7 06:03:42 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 7 Jul 2010 04:03:42 +0000 Subject: [M3devel] fault reports beyond 100mill lines? In-Reply-To: References: , , Message-ID: See below: >> The line number is in an integer along with a 5 bit fault code. Maybe that isn't clear -- they are in the same integer, 32bits or 64bits. 4 billion / 32 is roughly 100 million. - Jay Date: Wed, 7 Jul 2010 11:56:43 +0800 From: ttmrichter at gmail.com To: m3devel at elegosoft.com Subject: Re: [M3devel] fault reports beyond 100mill lines? Why the magic number of 100,000,000? Why not 4 billion, say? On 7 July 2010 04:35, Jay K wrote: I'm pretty settled on silently losing line numbers over 100 million. If the host and target are 64 bits it preserves far more. If someone produces such a file, and it compiles and runs, but gets a runtime error in their code on the wrong line, they can claim they found a compiler bug... - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Tue, 6 Jul 2010 20:21:08 +0000 > Subject: [M3devel] fault reports beyond 100mill lines? > > > It appears that if a file has over around 100 million lines, that fault reports (nil deref, subrange out of bounds, etc.) get the wrong line number. > Leave it as ("qualit of implementation"?) or fail an assertion in the compiler earlier (leaving anyone with a huge file kind of stuck (generated?) or, unlikely, expand the range? > The line number is in an integer along with a 5 bit fault code. > We could also allow much larger numbers on 64bit targets. > > > This is just because there's a "FIXME" comment in parse.c. > The code is basically right and I'm adding comments and perhaps assertions. > Certainly we can assert that the fault code is in range. > > > I think I prefer silently losing bits in the line number, or conveting it to 0 if it is out of bounds or pinning it to maxint. > Though it'd be maxint / 32 which is less "special" looking if someone ever saw it.. though the runtime could > report maxint / 32 as maxint. > > - Jay > > -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Wed Jul 7 06:30:06 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 7 Jul 2010 04:30:06 +0000 (GMT) Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: Message-ID: <4898.91283.qm@web23608.mail.ird.yahoo.com> Hi all: I could be wrong but if the mapped structures of original CM3 v4.1 were to detect compile time errors and runtime errors those ones no checked in M3 would be like to be checked at the CM3 JVM runtime (which abide CM3 itself at the time) then as the runtime JVM micro-ops were even possibly checked at java process runtime and possibly scanned at the lowest Modula-3 execution trace lower levels, we can I guess map those of the M3CG (even if are at the lowest level they did something like to match some structures at least they did that level of matching of two semantic structures and work as one like the CISC stack based JVM machine and the "RISC" stack class machine of M3CG) at the compile time back traces and so on interpretation (it would be not just not a M3CG VM like JVM but to get type info of the system and detect the probably undetectable otherwise Modula-3 runtime overflows i.e map some undetectable otherwise expressions meant to be not overflowed actually overflowed in the runtime). I guess in that way we can reserve more energies for both tasks compiler enhancement and m3cg tracing tree debugger ability if thats what you are looking for. In other short words I am proposing instead of the idea of initialize everything either manually or semi automatically get into the idea of a proper type system for M3CG and get rid of this kind of errors people are seeing meaningful if someone tells what else. I have a history of Modula-3, Java and JVM friendly leaving but to get into this properly I guess I would need more than energies I would like to get to check specially the implementation of the JVM lower level of CM3 and even better than that state or propose a type system for M3CG assembly language if we can call like that so no matters what we can have a better and systematic and reasonable (as JVM does) way of checking the M3CG code checking and generation if at all changes. Let me have a chance of asking of this more, probably first I need to check this paper wrote in DEC SRC about 1998 to see if the type system is pretty straight forward http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-158.pdf Thanks in advance --- El mar, 6/7/10, Tony Hosking escribi?: > De: Tony Hosking > Asunto: Re: [M3devel] [M3commit] CVS Update: cm3 > Para: hendrik at topoi.pooq.com > CC: m3devel at elegosoft.com > Fecha: martes, 6 de julio, 2010 12:00 > I agree. > > If Modula-3 was being designed today it would impose the > same ban on uninitialized use of variables that Java does. > We have a language that does not impose that ban, but > instead assures that every ininitialized variable holds a > valid value. > I much prefer to see > > VAR x: INTEGER > > as an *explicit* marker that the variable holds an > indeterminate but valid value. > > Seeing > > VAR x := 0 > > implies to me that there is something especially > significant about the initial value 0. > > > On 6 Jul 2010, at 12:53, hendrik at topoi.pooq.com > wrote: > > > On Tue, Jul 06, 2010 at 10:05:43AM +0000, Jay K > wrote: > >> > >>> used it should be a giant red flag to the > reader that the variable x is > >>> going to be initialized with a value that the > programmer doesn't know > >>> at the time of declaration. What on earth do > you gain from x := 0? > >>> A "little correctness"? > >> > >> You are making the code more expensive to > maintain, by making > >> it harder for a human to analyze. For the benefit > of microoptimization. > > > > Microoptimisation as a purpose? Didn't he just > explain that > > VAR x : INTEGER; > > is intended to signal to the *reader* that the initial > value is > > irrelevant? The fact that a naive compiler might > compile it slightly > > more efficiently is a side effect, not a > purpose. If he were interested > > in microoptimisation, he would better feed it into a > flow-analysing > > compiler, which could even detect when an explicit > initialization like > > VAR x := 0; > > is irrelevant and suppress it. > > > > It's not *about* optimisation. > > > > Indeed, they syntactic awkwardness of declaring > variables with WITH > > (to make sure they're initialized where they're > declared) is one of > > the problems of Modula 3, and one of the few places > where C did it > > better. Granted C, didn't do this at all > initially, and took it from > > Algol 68 in one of C's rounds of standardisation. > > > > -- hendrik > > From mika at async.async.caltech.edu Wed Jul 7 09:37:53 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Wed, 07 Jul 2010 00:37:53 -0700 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20100706063547.81FC21A2080@async.async.caltech.edu> Message-ID: <20100707073753.8A8F21A207C@async.async.caltech.edu> Jay K writes: > ... >> >When you write VAR a:INTEGER=3D3B >> >you make the human proofreading your code have to work much harder >> >to do the data/control flow analysis to make sure you didn't >> >use the uninitialized value. >> >> And yes=2C that's precisely the point! > > >You are just adding to the maintenance cost of the code. >If something makes it much more difficult to analyze by a human=2C and does= >n't >provide much benefit=2C don't do it. > Sorry to keep beating a dead horse but I meant precisely the opposite. If you ever see code that I have written that says: VAR x : INTEGER; BEGIN ... END that means *precisely* that there is no initial value of x for which the code is more correct than for any other initial value. I couldn't care less (99.9% of the time) about the insignficant time the compiler spends initializing the variable. It's all about readability. If it says VAR x := 0; BEGIN ... END it's really rather a mystery what that 0 means until the human has analyzed the code and realizes that on every path, x is written before it is read! And hey if you introduce a bug in the program where you forget to initialize x as you thought, the naive reader will assume the code is correct, because you did initialize it to zero (how clever, that zero value must be very special!) If you leave out the extra initialization, the bug will be fairly obvious even to someone who doesn't know exactly what the program is doing. I think you are just trading a set of moderately easy to analyze bugs for a set of very difficult bugs if you insist on initializing every variable including those without good initial values. Mika From jay.krell at cornell.edu Wed Jul 7 23:01:33 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 7 Jul 2010 21:01:33 +0000 Subject: [M3devel] try/finally and ter optimization? Message-ID: This is an example that crashes the backend if ter is enabled. TryFinStmt has three modes: Compile1, Compile2, Compile3. ?- stack walker ?- two other modes depending on the form of the function (I didn't read closely). ? One of them calls setjmp, one does not. ? In this case, no call to setjmp. ? Needs further investigation. ?Even if I put code in the finally block, same thing. ?TryStmt.m3 only has two modes, stack walker and not. ?So I think the problem is somewhere in TryFinStmt -- it doesn't generate a call to setjmp (Marker.CaptureState) (* Compiling this program has crashed some backends. ?* (gcc backend with -O3, no volatile, 'ter') ?* This is reduced from libm3/Formatter.m3 ?* The point therefore is merely to compile it without crashing. ?*) MODULE Main; ? VAR NoAlignOp: CARDINAL; PROCEDURE PeekOp(<*NOWARN*> i: CARDINAL): CARDINAL = ? BEGIN RETURN NoAlignOp; END PeekOp; VAR pos1: CARDINAL := 0; <*NOWARN*> PROCEDURE PrintAlign(VAR pos: CARDINAL) = ? VAR op, endRun: CARDINAL := 0; ? BEGIN ??? TRY ????? LOOP ??????? op := PeekOp(pos); ??????? LOOP ????????? IF op = NoAlignOp THEN ??????????? IF endRun = pos THEN ????????????? INC(endRun); ??????????? END; ??????????? EXIT; ????????? END; ????????? op := PeekOp(pos1); ??????? END; ????? END; ??? FINALLY ??? END; ? END PrintAlign; BEGIN END Main. From jay.krell at cornell.edu Thu Jul 8 12:22:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 8 Jul 2010 10:22:32 +0000 Subject: [M3devel] try/finally and ter optimization? In-Reply-To: References: Message-ID: To be clear, in several emails and commit comments, I mixed up "pre" and "ter". ?"ter" allowed now. ?"pre" is the problem. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: try/finally and ter optimization? > Date: Wed, 7 Jul 2010 21:01:33 +0000 > > > This is an example that crashes the backend if ter is enabled. > TryFinStmt has three modes: Compile1, Compile2, Compile3. > - stack walker > - two other modes depending on the form of the function (I didn't read closely). > One of them calls setjmp, one does not. > In this case, no call to setjmp. > Needs further investigation. > Even if I put code in the finally block, same thing. > TryStmt.m3 only has two modes, stack walker and not. > So I think the problem is somewhere in TryFinStmt -- it doesn't generate a call to setjmp (Marker.CaptureState) > > > > (* Compiling this program has crashed some backends. > * (gcc backend with -O3, no volatile, 'ter') > * This is reduced from libm3/Formatter.m3 > * The point therefore is merely to compile it without crashing. > *) > > MODULE Main; > > VAR NoAlignOp: CARDINAL; > > PROCEDURE PeekOp(<*NOWARN*> i: CARDINAL): CARDINAL = > BEGIN RETURN NoAlignOp; END PeekOp; > > VAR pos1: CARDINAL := 0; > > <*NOWARN*> PROCEDURE PrintAlign(VAR pos: CARDINAL) = > VAR op, endRun: CARDINAL := 0; > BEGIN > TRY > LOOP > op := PeekOp(pos); > LOOP > IF op = NoAlignOp THEN > IF endRun = pos THEN > INC(endRun); > END; > EXIT; > END; > op := PeekOp(pos1); > END; > END; > FINALLY > END; > END PrintAlign; > > BEGIN > END Main. > > From rcolebur at SCIRES.COM Thu Jul 8 18:42:58 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Thu, 8 Jul 2010 12:42:58 -0400 Subject: [M3devel] head branch can't compile on Windows Message-ID: I am no longer able to build the head branch on Windows. --Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 9 10:20:37 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 9 Jul 2010 08:20:37 +0000 Subject: [M3devel] head branch can't compile on Windows In-Reply-To: References: Message-ID: Randy is this what you see: "..\src\runtime\common\RTHeapStats.m3", line 203: unknown qualification '.' (And) "..\src\runtime\common\RTHeapStats.m3", line 207: unknown qualification '.' (T) "..\src\runtime\common\RTHeapStats.m3", line 208: unknown qualification '.' (T) "..\src\runtime\common\RTHeapStats.m3", line 209: unknown qualification '.' (LeftShift) "..\src\runtime\common\RTHeapStats.m3", line 210: unknown qualification '.' (And) "..\src\runtime\common\RTHeapStats.m3", line 212: unknown qualification '.' (Or) Yes, something is very wrong. - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com Date: Thu, 8 Jul 2010 12:42:58 -0400 Subject: [M3devel] head branch can't compile on Windows I am no longer able to build the head branch on Windows. --Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 9 14:01:16 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 9 Jul 2010 12:01:16 +0000 Subject: [M3devel] head branch can't compile on Windows In-Reply-To: References: , Message-ID: Randy, please try again, with the change to m3front/misc/Scanner.m3 (ie: version 1.13 or 1.11, not version 1.12). Tony, this was yours. Thanks, - Jay From: jay.krell at cornell.edu To: rcolebur at scires.com; m3devel at elegosoft.com Subject: RE: [M3devel] head branch can't compile on Windows Date: Fri, 9 Jul 2010 08:20:37 +0000 Randy is this what you see: "..\src\runtime\common\RTHeapStats.m3", line 203: unknown qualification '.' (And) "..\src\runtime\common\RTHeapStats.m3", line 207: unknown qualification '.' (T) "..\src\runtime\common\RTHeapStats.m3", line 208: unknown qualification '.' (T) "..\src\runtime\common\RTHeapStats.m3", line 209: unknown qualification '.' (LeftShift) "..\src\runtime\common\RTHeapStats.m3", line 210: unknown qualification '.' (And) "..\src\runtime\common\RTHeapStats.m3", line 212: unknown qualification '.' (Or) Yes, something is very wrong. - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com Date: Thu, 8 Jul 2010 12:42:58 -0400 Subject: [M3devel] head branch can't compile on Windows I am no longer able to build the head branch on Windows. --Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Jul 11 13:46:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 11 Jul 2010 11:46:43 +0000 Subject: [M3devel] barrier labels? Message-ID: Tony, six years ago you introduce what is now: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c.diff?r1=1.5;r2=1.6 static void m3cg_set_label (void) { ... ? if (barrier) ??? { ... ????? { ??????? rtx list = DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels; ??????? DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels ????????? = gen_rtx_EXPR_LIST (VOIDmode, r, list); ????? } ... I'm not sure what to do here for gcc 4.5. ? The data has moved around and isn't available this early. I suppose we could hang some information on and ??? deal with it later in compilation. DECL_NONLOCAL(l) = true; seems promising, but it caused very bad code to be produced (incorrect, not inefficient). I didn't look into why. The bad code was changing the stack pointer where it should leave it alone. gcc-4.5 is working for me now (cm3 built with it can built itself), at least with -O1, AMD64_DARWIN. And Juno/mentor/tetris work without optimization, I'll test optimized later. Next I'll test -O2, -O3, m3-sys/m3tests. Do we have good exception handling tests? I know that cm3 uses exceptions, like, looking for cm3.cfg. I'll poke around more.. ?- Jay From hosking at cs.purdue.edu Sun Jul 11 22:25:41 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 11 Jul 2010 16:25:41 -0400 Subject: [M3devel] barrier labels? In-Reply-To: References: Message-ID: I extracted that usage from what C++ was doing for exception labels. The point is to make sure that flow analysis knows that the exception handler label targets are important "non-local" label targets. I do remember that DECL_NONLOCAL was *not* the right thing to do (that is used for proper non-local outer-scope goto targets for nested functions) and I remember the SP hacks being used with that (they need to recover from targeting from an inner-scope function and clean up the stack accordingly). I suggest poking around in what the C++ exception handling now does with table-driven exception targets. On 11 Jul 2010, at 07:46, Jay K wrote: > > Tony, six years ago you introduce what is now: > > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c.diff?r1=1.5;r2=1.6 > > > static void > m3cg_set_label (void) > { > ... > if (barrier) > { > ... > { > rtx list = DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels; > DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels > = gen_rtx_EXPR_LIST (VOIDmode, r, list); > } > ... > > > I'm not sure what to do here for gcc 4.5. > The data has moved around and isn't available this early. I suppose we could hang some information on and > deal with it later in compilation. > > > DECL_NONLOCAL(l) = true; seems promising, but it caused very bad code to be produced (incorrect, not inefficient). > I didn't look into why. The bad code was changing the stack pointer where it should leave it alone. > > > gcc-4.5 is working for me now (cm3 built with it can built itself), at least with -O1, AMD64_DARWIN. > And Juno/mentor/tetris work without optimization, I'll test optimized later. > Next I'll test -O2, -O3, m3-sys/m3tests. > > > Do we have good exception handling tests? > I know that cm3 uses exceptions, like, looking for cm3.cfg. > > > I'll poke around more.. > > > - Jay > From jay.krell at cornell.edu Mon Jul 12 01:41:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 11 Jul 2010 23:41:20 +0000 Subject: [M3devel] barrier labels? In-Reply-To: References: , Message-ID: Tony, thanks for the pointer..though I haven't been able to find it yet. I also looked for related code in 3.3 and 3.4, as I think 3.3 was current at the time. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Sun, 11 Jul 2010 16:25:41 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] barrier labels? > > I extracted that usage from what C++ was doing for exception labels. The point is to make sure that flow analysis knows that the exception handler label targets are important "non-local" label targets. I do remember that DECL_NONLOCAL was *not* the right thing to do (that is used for proper non-local outer-scope goto targets for nested functions) and I remember the SP hacks being used with that (they need to recover from targeting from an inner-scope function and clean up the stack accordingly). I suggest poking around in what the C++ exception handling now does with table-driven exception targets. > > On 11 Jul 2010, at 07:46, Jay K wrote: > > > > > Tony, six years ago you introduce what is now: > > > > > > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c.diff?r1=1.5;r2=1.6 > > > > > > static void > > m3cg_set_label (void) > > { > > ... > > if (barrier) > > { > > ... > > { > > rtx list = DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels; > > DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels > > = gen_rtx_EXPR_LIST (VOIDmode, r, list); > > } > > ... > > > > > > I'm not sure what to do here for gcc 4.5. > > The data has moved around and isn't available this early. I suppose we could hang some information on and > > deal with it later in compilation. > > > > > > DECL_NONLOCAL(l) = true; seems promising, but it caused very bad code to be produced (incorrect, not inefficient). > > I didn't look into why. The bad code was changing the stack pointer where it should leave it alone. > > > > > > gcc-4.5 is working for me now (cm3 built with it can built itself), at least with -O1, AMD64_DARWIN. > > And Juno/mentor/tetris work without optimization, I'll test optimized later. > > Next I'll test -O2, -O3, m3-sys/m3tests. > > > > > > Do we have good exception handling tests? > > I know that cm3 uses exceptions, like, looking for cm3.cfg. > > > > > > I'll poke around more.. > > > > > > - Jay > > > From jay.krell at cornell.edu Mon Jul 12 01:51:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 11 Jul 2010 23:51:43 +0000 Subject: [M3devel] gcc 4.5 Message-ID: I'm inclined to make gcc 4.5 the default backend very soon. AMD64_DARWIN, I386_LINUX, SOLgnu are looking ok. ? I could also test PPC, like PPC_LINUX. SOLgnu leaves everything volatile (same as 4.3) so maybe isn't much validation. I doubt there is much value in testing other operating systems, mainly just other processors. ?? Though there is sometimes, e.g. I think I386_DARWIN uses sse for floating point and other I386 systems don't. ?? I should also test SPARC_LINUX to get sparc w/o volatile. There are many other targets. OpenBSD, NetBSD, FreeBSD, OSF/1, I386/AMD64_SOLARIS, ARMEL_LINUX, Cygwin, MinGW, etc. Others can test them? There is some downside, in particular I disable more optimization at -O3 than with gcc 4.3. One of the additional optimizations perhaps doesn't exist in 4.3 though. The label/barrier thing still isn't resolved. I haven't run through m3-sys/m3tests. But that the system can build itself is a good sign, though sometimes I overvalue it. And I tested some gui apps at least unoptimized. The "man vs. boy" test works. The 4.3 backend will remain available via cm3 -DGCC43 in the m3cc directory. ? You have to be careful about cm3cfg.common probing around and finding the intended one, ? such as by deleting all others. ?- Jay From hosking at cs.purdue.edu Mon Jul 12 02:52:25 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 11 Jul 2010 20:52:25 -0400 Subject: [M3devel] barrier labels? In-Reply-To: References: , Message-ID: <08509C7F-5EC5-4679-8094-6985A70CC7C6@cs.purdue.edu> No, that code came from 4.x... On 11 Jul 2010, at 19:41, Jay K wrote: > > Tony, thanks for the pointer..though I haven't been able to find it yet. > I also looked for related code in 3.3 and 3.4, as I think 3.3 was current at the time. > > - Jay > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Sun, 11 Jul 2010 16:25:41 -0400 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] barrier labels? >> >> I extracted that usage from what C++ was doing for exception labels. The point is to make sure that flow analysis knows that the exception handler label targets are important "non-local" label targets. I do remember that DECL_NONLOCAL was *not* the right thing to do (that is used for proper non-local outer-scope goto targets for nested functions) and I remember the SP hacks being used with that (they need to recover from targeting from an inner-scope function and clean up the stack accordingly). I suggest poking around in what the C++ exception handling now does with table-driven exception targets. >> >> On 11 Jul 2010, at 07:46, Jay K wrote: >> >>> >>> Tony, six years ago you introduce what is now: >>> >>> >>> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c.diff?r1=1.5;r2=1.6 >>> >>> >>> static void >>> m3cg_set_label (void) >>> { >>> ... >>> if (barrier) >>> { >>> ... >>> { >>> rtx list = DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels; >>> DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels >>> = gen_rtx_EXPR_LIST (VOIDmode, r, list); >>> } >>> ... >>> >>> >>> I'm not sure what to do here for gcc 4.5. >>> The data has moved around and isn't available this early. I suppose we could hang some information on and >>> deal with it later in compilation. >>> >>> >>> DECL_NONLOCAL(l) = true; seems promising, but it caused very bad code to be produced (incorrect, not inefficient). >>> I didn't look into why. The bad code was changing the stack pointer where it should leave it alone. >>> >>> >>> gcc-4.5 is working for me now (cm3 built with it can built itself), at least with -O1, AMD64_DARWIN. >>> And Juno/mentor/tetris work without optimization, I'll test optimized later. >>> Next I'll test -O2, -O3, m3-sys/m3tests. >>> >>> >>> Do we have good exception handling tests? >>> I know that cm3 uses exceptions, like, looking for cm3.cfg. >>> >>> >>> I'll poke around more.. >>> >>> >>> - Jay >>> >> > From jay.krell at cornell.edu Mon Jul 12 03:58:52 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 12 Jul 2010 01:58:52 +0000 Subject: [M3devel] import from same .so or not Message-ID: It seems to me, an important bit of information is not provided to the backend. The backend is told "import" or "export". But this is about "modules", .m3 files to .m3 files. It isn't about .so files to .so files, or .dlls to .dlls. It's really tristate, not boolean: ? private to just this source file? ? private to this source file and those it statically links to ? public for all Granted, you might statically link "everything". There isn't enforcement of the middle state, and symbols still need to be as unique as the third state. But it is definitely useful. In particular we don't use DECL_VISIBILITY (p) = VISIBILITY_HIDDEN enough. ? For a long time we never used it. e.g. in the release branch. Agreed? Anyone volunteer to fix? Or mind if I try? ?- Jay From jay.krell at cornell.edu Mon Jul 12 05:03:58 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 12 Jul 2010 03:03:58 +0000 Subject: [M3devel] barrier labels? In-Reply-To: <08509C7F-5EC5-4679-8094-6985A70CC7C6@cs.purdue.edu> References: , , , , <08509C7F-5EC5-4679-8094-6985A70CC7C6@cs.purdue.edu> Message-ID: I still don't see it, in the C++ frontend. There is: void expand_label (tree label) { ... ? if (DECL_NONLOCAL (label)) ??? { ... ???? nonlocal_goto_handler_labels ??? = gen_rtx_EXPR_LIST (VOIDmode, label_r, ??? ??? ??? ???? nonlocal_goto_handler_labels); ??? } but I don't think this works until later. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Sun, 11 Jul 2010 20:52:25 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] barrier labels? > > No, that code came from 4.x... > > > > > On 11 Jul 2010, at 19:41, Jay K wrote: > > > > > Tony, thanks for the pointer..though I haven't been able to find it yet. > > I also looked for related code in 3.3 and 3.4, as I think 3.3 was current at the time. > > > > - Jay > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Sun, 11 Jul 2010 16:25:41 -0400 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] barrier labels? > >> > >> I extracted that usage from what C++ was doing for exception labels. The point is to make sure that flow analysis knows that the exception handler label targets are important "non-local" label targets. I do remember that DECL_NONLOCAL was *not* the right thing to do (that is used for proper non-local outer-scope goto targets for nested functions) and I remember the SP hacks being used with that (they need to recover from targeting from an inner-scope function and clean up the stack accordingly). I suggest poking around in what the C++ exception handling now does with table-driven exception targets. > >> > >> On 11 Jul 2010, at 07:46, Jay K wrote: > >> > >>> > >>> Tony, six years ago you introduce what is now: > >>> > >>> > >>> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c.diff?r1=1.5;r2=1.6 > >>> > >>> > >>> static void > >>> m3cg_set_label (void) > >>> { > >>> ... > >>> if (barrier) > >>> { > >>> ... > >>> { > >>> rtx list = DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels; > >>> DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels > >>> = gen_rtx_EXPR_LIST (VOIDmode, r, list); > >>> } > >>> ... > >>> > >>> > >>> I'm not sure what to do here for gcc 4.5. > >>> The data has moved around and isn't available this early. I suppose we could hang some information on and > >>> deal with it later in compilation. > >>> > >>> > >>> DECL_NONLOCAL(l) = true; seems promising, but it caused very bad code to be produced (incorrect, not inefficient). > >>> I didn't look into why. The bad code was changing the stack pointer where it should leave it alone. > >>> > >>> > >>> gcc-4.5 is working for me now (cm3 built with it can built itself), at least with -O1, AMD64_DARWIN. > >>> And Juno/mentor/tetris work without optimization, I'll test optimized later. > >>> Next I'll test -O2, -O3, m3-sys/m3tests. > >>> > >>> > >>> Do we have good exception handling tests? > >>> I know that cm3 uses exceptions, like, looking for cm3.cfg. > >>> > >>> > >>> I'll poke around more.. > >>> > >>> > >>> - Jay > >>> > >> > > > From hosking at cs.purdue.edu Mon Jul 12 15:28:43 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jul 2010 09:28:43 -0400 Subject: [M3devel] import from same .so or not In-Reply-To: References: Message-ID: It seems to me this would require massive reworking of the build infrastructure! On 11 Jul 2010, at 21:58, Jay K wrote: > > It seems to me, an important bit of information is not provided to the backend. > > The backend is told "import" or "export". > But this is about "modules", .m3 files to .m3 files. > > It isn't about .so files to .so files, or .dlls to .dlls. > > It's really tristate, not boolean: > private to just this source file > private to this source file and those it statically links to > public for all > > Granted, you might statically link "everything". > There isn't enforcement of the middle state, and symbols still need to be as unique as the third state. > But it is definitely useful. > > In particular we don't use DECL_VISIBILITY (p) = VISIBILITY_HIDDEN enough. > For a long time we never used it. e.g. in the release branch. > > Agreed? > Anyone volunteer to fix? > Or mind if I try? > > > - Jay > > From hosking at cs.purdue.edu Mon Jul 12 15:43:01 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jul 2010 09:43:01 -0400 Subject: [M3devel] barrier labels? In-Reply-To: References: , , , , <08509C7F-5EC5-4679-8094-6985A70CC7C6@cs.purdue.edu> Message-ID: Perhaps we just need FORCED_LABEL for these: /* In a LABEL_DECL, nonzero means this label had its address taken and therefore can never be deleted and is a jump target for computed gotos. */ On 11 Jul 2010, at 23:03, Jay K wrote: > > I still don't see it, in the C++ frontend. > > There is: > > void > expand_label (tree label) > { > ... > if (DECL_NONLOCAL (label)) > { > ... nonlocal_goto_handler_labels > = gen_rtx_EXPR_LIST (VOIDmode, label_r, > nonlocal_goto_handler_labels); > } > > but I don't think this works until later. > > - Jay > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Sun, 11 Jul 2010 20:52:25 -0400 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] barrier labels? >> >> No, that code came from 4.x... >> >> >> >> >> On 11 Jul 2010, at 19:41, Jay K wrote: >> >>> >>> Tony, thanks for the pointer..though I haven't been able to find it yet. >>> I also looked for related code in 3.3 and 3.4, as I think 3.3 was current at the time. >>> >>> - Jay >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> Date: Sun, 11 Jul 2010 16:25:41 -0400 >>>> To: jay.krell at cornell.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] barrier labels? >>>> >>>> I extracted that usage from what C++ was doing for exception labels. The point is to make sure that flow analysis knows that the exception handler label targets are important "non-local" label targets. I do remember that DECL_NONLOCAL was *not* the right thing to do (that is used for proper non-local outer-scope goto targets for nested functions) and I remember the SP hacks being used with that (they need to recover from targeting from an inner-scope function and clean up the stack accordingly). I suggest poking around in what the C++ exception handling now does with table-driven exception targets. >>>> >>>> On 11 Jul 2010, at 07:46, Jay K wrote: >>>> >>>>> >>>>> Tony, six years ago you introduce what is now: >>>>> >>>>> >>>>> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c.diff?r1=1.5;r2=1.6 >>>>> >>>>> >>>>> static void >>>>> m3cg_set_label (void) >>>>> { >>>>> ... >>>>> if (barrier) >>>>> { >>>>> ... >>>>> { >>>>> rtx list = DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels; >>>>> DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels >>>>> = gen_rtx_EXPR_LIST (VOIDmode, r, list); >>>>> } >>>>> ... >>>>> >>>>> >>>>> I'm not sure what to do here for gcc 4.5. >>>>> The data has moved around and isn't available this early. I suppose we could hang some information on and >>>>> deal with it later in compilation. >>>>> >>>>> >>>>> DECL_NONLOCAL(l) = true; seems promising, but it caused very bad code to be produced (incorrect, not inefficient). >>>>> I didn't look into why. The bad code was changing the stack pointer where it should leave it alone. >>>>> >>>>> >>>>> gcc-4.5 is working for me now (cm3 built with it can built itself), at least with -O1, AMD64_DARWIN. >>>>> And Juno/mentor/tetris work without optimization, I'll test optimized later. >>>>> Next I'll test -O2, -O3, m3-sys/m3tests. >>>>> >>>>> >>>>> Do we have good exception handling tests? >>>>> I know that cm3 uses exceptions, like, looking for cm3.cfg. >>>>> >>>>> >>>>> I'll poke around more.. >>>>> >>>>> >>>>> - Jay >>>>> >>>> >>> >> > From jay.krell at cornell.edu Tue Jul 13 01:53:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 12 Jul 2010 23:53:57 +0000 Subject: [M3devel] import from same .so or not In-Reply-To: References: , Message-ID: I don't know. I hope not. The information is there: lowercase interface vs. uppercase Interface, lowercase module vs. uppercase Module, derived_interface(hidden or private). I haven't looked at where all it is sent around. - Jay > Subject: Re: [M3devel] import from same .so or not > From: hosking at cs.purdue.edu > Date: Mon, 12 Jul 2010 09:28:43 -0400 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > It seems to me this would require massive reworking of the build infrastructure! > > On 11 Jul 2010, at 21:58, Jay K wrote: > > > > > It seems to me, an important bit of information is not provided to the backend. > > > > The backend is told "import" or "export". > > But this is about "modules", .m3 files to .m3 files. > > > > It isn't about .so files to .so files, or .dlls to .dlls. > > > > It's really tristate, not boolean: > > private to just this source file > > private to this source file and those it statically links to > > public for all > > > > Granted, you might statically link "everything". > > There isn't enforcement of the middle state, and symbols still need to be as unique as the third state. > > But it is definitely useful. > > > > In particular we don't use DECL_VISIBILITY (p) = VISIBILITY_HIDDEN enough. > > For a long time we never used it. e.g. in the release branch. > > > > Agreed? > > Anyone volunteer to fix? > > Or mind if I try? > > > > > > - Jay > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Jul 13 02:14:39 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 12 Jul 2010 20:14:39 -0400 Subject: [M3devel] import from same .so or not In-Reply-To: References: , Message-ID: <9241B253-8004-4DDD-B1EF-A7D02A3FEAFD@cs.purdue.edu> There question is where and how to communicate it back to gcc. Does it mean putting all the module units on the same command line for compilation by a single instance of cm3cg? Or do you communicate it some other way? On 12 Jul 2010, at 19:53, Jay K wrote: > I don't know. I hope not. The information is there: lowercase interface vs. uppercase Interface, lowercase module vs. uppercase Module, derived_interface(hidden or private). > I haven't looked at where all it is sent around. > > - Jay > > > > Subject: Re: [M3devel] import from same .so or not > > From: hosking at cs.purdue.edu > > Date: Mon, 12 Jul 2010 09:28:43 -0400 > > CC: m3devel at elegosoft.com > > To: jay.krell at cornell.edu > > > > It seems to me this would require massive reworking of the build infrastructure! > > > > On 11 Jul 2010, at 21:58, Jay K wrote: > > > > > > > > It seems to me, an important bit of information is not provided to the backend. > > > > > > The backend is told "import" or "export". > > > But this is about "modules", .m3 files to .m3 files. > > > > > > It isn't about .so files to .so files, or .dlls to .dlls. > > > > > > It's really tristate, not boolean: > > > private to just this source file > > > private to this source file and those it statically links to > > > public for all > > > > > > Granted, you might statically link "everything". > > > There isn't enforcement of the middle state, and symbols still need to be as unique as the third state. > > > But it is definitely useful. > > > > > > In particular we don't use DECL_VISIBILITY (p) = VISIBILITY_HIDDEN enough. > > > For a long time we never used it. e.g. in the release branch. > > > > > > Agreed? > > > Anyone volunteer to fix? > > > Or mind if I try? > > > > > > > > > - Jay > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 13 02:50:47 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 13 Jul 2010 00:50:47 +0000 Subject: [M3devel] import from same .so or not In-Reply-To: <9241B253-8004-4DDD-B1EF-A7D02A3FEAFD@cs.purdue.edu> References: , , <9241B253-8004-4DDD-B1EF-A7D02A3FEAFD@cs.purdue.edu> Message-ID: I think it'd be another boolean or expansion of a boolean to an integer to declare/import/begin_procedure/constant/variable. Not passing all the files at once. Passing all the files at once is attractive for reasons of compilation perf and optimizing codegen but I believe it requires a lot of other work. Similarly, passing all the C files at once to the C compiler is also attractive, and more work. LTCG/LTO provide similar benefits, but we aren't setup to use LTO and honestly I'm trying to ignore it. I'll settle for -O1/2/3. - Jay Subject: Re: [M3devel] import from same .so or not From: hosking at cs.purdue.edu Date: Mon, 12 Jul 2010 20:14:39 -0400 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu There question is where and how to communicate it back to gcc. Does it mean putting all the module units on the same command line for compilation by a single instance of cm3cg? Or do you communicate it some other way? On 12 Jul 2010, at 19:53, Jay K wrote: I don't know. I hope not. The information is there: lowercase interface vs. uppercase Interface, lowercase module vs. uppercase Module, derived_interface(hidden or private). I haven't looked at where all it is sent around. - Jay > Subject: Re: [M3devel] import from same .so or not > From: hosking at cs.purdue.edu > Date: Mon, 12 Jul 2010 09:28:43 -0400 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > It seems to me this would require massive reworking of the build infrastructure! > > On 11 Jul 2010, at 21:58, Jay K wrote: > > > > > It seems to me, an important bit of information is not provided to the backend. > > > > The backend is told "import" or "export". > > But this is about "modules", .m3 files to .m3 files. > > > > It isn't about .so files to .so files, or .dlls to .dlls. > > > > It's really tristate, not boolean: > > private to just this source file > > private to this source file and those it statically links to > > public for all > > > > Granted, you might statically link "everything". > > There isn't enforcement of the middle state, and symbols still need to be as unique as the third state. > > But it is definitely useful. > > > > In particular we don't use DECL_VISIBILITY (p) = VISIBILITY_HIDDEN enough. > > For a long time we never used it. e.g. in the release branch. > > > > Agreed? > > Anyone volunteer to fix? > > Or mind if I try? > > > > > > - Jay > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Tue Jul 13 05:35:19 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Mon, 12 Jul 2010 23:35:19 -0400 Subject: [M3devel] still having compile problems with HEAD branch Message-ID: I'm still unable to build the HEAD branch on Windows. I'm getting some version mismatch errors early on in the build process. Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 13 06:36:01 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 13 Jul 2010 04:36:01 +0000 Subject: [M3devel] still having compile problems with HEAD branch In-Reply-To: References: Message-ID: Randy, you probably need to go back to a working state, such as by reinstalling a release, and restart upgrade.py. - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com Date: Mon, 12 Jul 2010 23:35:19 -0400 Subject: [M3devel] still having compile problems with HEAD branch I?m still unable to build the HEAD branch on Windows. I?m getting some version mismatch errors early on in the build process. Regards, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 13 08:38:05 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 13 Jul 2010 06:38:05 +0000 Subject: [M3devel] barrier labels? In-Reply-To: References: , , , , , , , <08509C7F-5EC5-4679-8094-6985A70CC7C6@cs.purdue.edu>, , Message-ID: I don't know. There is so much unknown here. It is frustrating and difficult. We could use an extensive set of test cases. ? Or know more about the test cases we do have. And it'd be nice to see if anything varies in the 4.3 path if we put the labels on that list or not. tangent: I'd like automation that compiles the whole system, multiple architectures, and puts all the *s files in one flat directory per architecture. I guess it's just a matter of a little code. ??? It should just skip the few errors that are cross problems, which I should fix anyway. ??? That particular problem makes me a little nervous, but I suppose I can code it to use both INTEGER and Target.Int ?? ??? if doing a native build, and assert that the results match. I hit a snag yesterday, can't build any tests (just to assembly) without first shipping m3core/libm3. Can't ship m3core/libm3 for cross building. I guess, and I forgot this, I should have used -x for override. Duh. That's why I tried I386_DARWIN for some current 4.5 problems vs. SOLgnu, to escape cross building. Oops. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Mon, 12 Jul 2010 09:43:01 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] barrier labels? > > Perhaps we just need FORCED_LABEL for these: > > /* In a LABEL_DECL, nonzero means this label had its address taken > and therefore can never be deleted and is a jump target for > computed gotos. */ > > > On 11 Jul 2010, at 23:03, Jay K wrote: > > > > > I still don't see it, in the C++ frontend. > > > > There is: > > > > void > > expand_label (tree label) > > { > > ... > > if (DECL_NONLOCAL (label)) > > { > > ... nonlocal_goto_handler_labels > > = gen_rtx_EXPR_LIST (VOIDmode, label_r, > > nonlocal_goto_handler_labels); > > } > > > > but I don't think this works until later. > > > > - Jay > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Sun, 11 Jul 2010 20:52:25 -0400 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] barrier labels? > >> > >> No, that code came from 4.x... > >> > >> > >> > >> > >> On 11 Jul 2010, at 19:41, Jay K wrote: > >> > >>> > >>> Tony, thanks for the pointer..though I haven't been able to find it yet. > >>> I also looked for related code in 3.3 and 3.4, as I think 3.3 was current at the time. > >>> > >>> - Jay > >>> > >>> ---------------------------------------- > >>>> From: hosking at cs.purdue.edu > >>>> Date: Sun, 11 Jul 2010 16:25:41 -0400 > >>>> To: jay.krell at cornell.edu > >>>> CC: m3devel at elegosoft.com > >>>> Subject: Re: [M3devel] barrier labels? > >>>> > >>>> I extracted that usage from what C++ was doing for exception labels. The point is to make sure that flow analysis knows that the exception handler label targets are important "non-local" label targets. I do remember that DECL_NONLOCAL was *not* the right thing to do (that is used for proper non-local outer-scope goto targets for nested functions) and I remember the SP hacks being used with that (they need to recover from targeting from an inner-scope function and clean up the stack accordingly). I suggest poking around in what the C++ exception handling now does with table-driven exception targets. > >>>> > >>>> On 11 Jul 2010, at 07:46, Jay K wrote: > >>>> > >>>>> > >>>>> Tony, six years ago you introduce what is now: > >>>>> > >>>>> > >>>>> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c.diff?r1=1.5;r2=1.6 > >>>>> > >>>>> > >>>>> static void > >>>>> m3cg_set_label (void) > >>>>> { > >>>>> ... > >>>>> if (barrier) > >>>>> { > >>>>> ... > >>>>> { > >>>>> rtx list = DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels; > >>>>> DECL_STRUCT_FUNCTION (current_function_decl)->x_nonlocal_goto_handler_labels > >>>>> = gen_rtx_EXPR_LIST (VOIDmode, r, list); > >>>>> } > >>>>> ... > >>>>> > >>>>> > >>>>> I'm not sure what to do here for gcc 4.5. > >>>>> The data has moved around and isn't available this early. I suppose we could hang some information on and > >>>>> deal with it later in compilation. > >>>>> > >>>>> > >>>>> DECL_NONLOCAL(l) = true; seems promising, but it caused very bad code to be produced (incorrect, not inefficient). > >>>>> I didn't look into why. The bad code was changing the stack pointer where it should leave it alone. > >>>>> > >>>>> > >>>>> gcc-4.5 is working for me now (cm3 built with it can built itself), at least with -O1, AMD64_DARWIN. > >>>>> And Juno/mentor/tetris work without optimization, I'll test optimized later. > >>>>> Next I'll test -O2, -O3, m3-sys/m3tests. > >>>>> > >>>>> > >>>>> Do we have good exception handling tests? > >>>>> I know that cm3 uses exceptions, like, looking for cm3.cfg. > >>>>> > >>>>> > >>>>> I'll poke around more.. > >>>>> > >>>>> > >>>>> - Jay > >>>>> > >>>> > >>> > >> > > > From mika at async.async.caltech.edu Tue Jul 13 10:11:58 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Tue, 13 Jul 2010 01:11:58 -0700 Subject: [M3devel] "FreeBSD4" false advertising Message-ID: <20100713081158.D3E221A20A4@async.async.caltech.edu> Hi Modula-3ers, I am again (for the "umpteenth" time) attempting to move a medium-sized under-development software repository from PM3 to CM3. Things are looking better! But of course there is one snake in paradise. Can I upgrade the software without installing new OSes as well (at the same time)? The installation archive marked "FreeBSD4" does *not* work on FreeBSD 4/i386 nor on FreeBSD 5. Is it from 6 or 7? As I have mentioned before, FreeBSD is pretty good about being backward-compatible (FreeBSD 4 binaries and even compilers will work fine on 5 or 6), but it's not at all forwards-compatible. You simply cannot compile something on FreeBSD 6 and expect it to work on an earlier release of the OS. I have the following on a bona fide FreeBSD 4.11-RELEASE system: (62)trs80:~>cm3 -version Critical Mass Modula-3 version d0.0.0 last updated: unknown compiled: 2009-04-25 02:28:01 configuration: /usr/local/cm3/bin/cm3.cfg (63)trs80:~> My bootstrapping instructions I received from Tony do not work. Quake has changed so I get an error even cm3 trying to read the m3makefiles.... so how would I go about bootstrapping the latest CM3 on this? I wouldn't trust Python on it either. (I have Python but an old old version.) Yes I do want to get rid of FreeBSD-4.11 but one thing at a time would be my preference. Right now I seem to have all the software happy with CM3 (for once!) Mika From wagner at elegosoft.com Tue Jul 13 11:11:31 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 13 Jul 2010 11:11:31 +0200 Subject: [M3devel] "FreeBSD4" false advertising Message-ID: <20100713111131.lf9wqsz9eo0ckko0@mail.elegosoft.com> Quoting Mika Nystrom : > Hi Modula-3ers, > > I am again (for the "umpteenth" time) attempting to move a medium-sized > under-development software repository from PM3 to CM3. Things are looking > better! > > But of course there is one snake in paradise. Can I upgrade the software > without installing new OSes as well (at the same time)? > > The installation archive marked "FreeBSD4" does *not* work on FreeBSD 4/i386 > nor on FreeBSD 5. Is it from 6 or 7? > > As I have mentioned before, FreeBSD is pretty good about being > backward-compatible (FreeBSD 4 binaries and even compilers will work fine > on 5 or 6), but it's not at all forwards-compatible. You simply cannot > compile something on FreeBSD 6 and expect it to work on an earlier release > of the OS. Hi Mika, you're completely right about that. The name FreeBSD4 is currently wrong; nobody has added a new platform for every new release of FreeBSD since the time 4.x came out. It should long have been renamed to I386_FREEBSD. We also need to document the actual OS version an installation archive has been built on. I'll try to do that for the next release, but for 5.8 I think we simply need to rename and/or document the build systems (probably not before tomorrow evening though). The FreeBSD4 archives are actually built on a FreeBSD 6 system: FreeBSD new.elego.de 6.4-RELEASE-p5 FreeBSD 6.4-RELEASE-p5 #1: Sun Jun 14 14:03:37 CEST 2009 I'll try to rename them on birch, at least for the release and RC5, but I'm afraid I haven't got an actual FreeBSD 4.x system for build purposes anymore. The last version that may be directly useful I find on the web pages is FreeBSD 4.x and later: cm3-min-POSIX-FreeBSD4-d5.5.0.tgz (built on FreeBSD 4.11 i686) at http://www.modula3.com/cm3/cm3-min-POSIX-FreeBSD4-d5.5.0.tgz This could be used together with the upgrade.sh script to built the 5.8 release sources. > I have the following on a bona fide FreeBSD 4.11-RELEASE system: > > (62)trs80:~>cm3 -version > Critical Mass Modula-3 version d0.0.0 > last updated: unknown > compiled: 2009-04-25 02:28:01 > configuration: /usr/local/cm3/bin/cm3.cfg As the version string is actually undefined, this doesn't tell us very much :-( > (63)trs80:~> > > My bootstrapping instructions I received from Tony do not work. Quake has > changed so I get an error even cm3 trying to read the m3makefiles.... so > how would I go about bootstrapping the latest CM3 on this? I wouldn't > trust Python on it either. (I have Python but an old old version.) What exactly is the error you get? Can you try with the installation archives mentioned above? > Yes I do want to get rid of FreeBSD-4.11 but one thing at a time would be > my preference. Right now I seem to have all the software happy with CM3 > (for once!) I'd like to provide real FreeBSD4 archives, so if you get it to work, I'd ask you to run scripts/make-dist.sh to build and ship them (after the current FreeBSD4 archives have been renamed). If you get stuck, I'll try to help as I can; if you can provide remote access, I'd even try to build a working system myself. Sorry for the inconveniences, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 mika at async.async.caltech.edu Tue Jul 13 11:20:43 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Tue, 13 Jul 2010 02:20:43 -0700 Subject: [M3devel] "FreeBSD4" false advertising In-Reply-To: <20100713111131.lf9wqsz9eo0ckko0@mail.elegosoft.com> References: <20100713111131.lf9wqsz9eo0ckko0@mail.elegosoft.com> Message-ID: <20100713092043.808181A20A2@async.async.caltech.edu> Olaf Wagner writes: ... >FreeBSD 4.x and later: cm3-min-POSIX-FreeBSD4-d5.5.0.tgz >(built on FreeBSD 4.11 i686) at > > http://www.modula3.com/cm3/cm3-min-POSIX-FreeBSD4-d5.5.0.tgz > >This could be used together with the upgrade.sh script to built the >5.8 release sources. > >> I have the following on a bona fide FreeBSD 4.11-RELEASE system: >> >> (62)trs80:~>cm3 -version >> Critical Mass Modula-3 version d0.0.0 >> last updated: unknown >> compiled: 2009-04-25 02:28:01 >> configuration: /usr/local/cm3/bin/cm3.cfg > >As the version string is actually undefined, this doesn't tell us very =20 >much :-( Olaf, I'm pretty sure that release archive is a tarred up version of my system. (I built it on this machine!) How do I use upgrade.sh? I've been doing things manually following Tony's recommendations from a few years ago and that doesn't work. Well I'll try the obvious thing :-) Mika From jay.krell at cornell.edu Tue Jul 13 12:33:46 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 13 Jul 2010 10:33:46 +0000 Subject: [M3devel] "FreeBSD4" false advertising In-Reply-To: <20100713092043.808181A20A2@async.async.caltech.edu> References: <20100713111131.lf9wqsz9eo0ckko0@mail.elegosoft.com>, <20100713092043.808181A20A2@async.async.caltech.edu> Message-ID: The compatibility story on FreeBSD and some uncertain others is incredibly disappointing. When I build something on Windows 7, by default it works on older Windows systems. The ABI doesn't change. New functions are added. "Behavioral compability", *that* is the tricky part. Apple does similar, but also a hybrid of the "Unix model". Anyway, just do a cross build. It is fairly easy. ? If it is too hard, complain and suggest changes. Get the current source on the FreeBSD 4 machine and on nearly any other machine. ?? They don't actually have to be identical, I believe, because this won't be an "upgrade" but ??? eventually on the target will build up the entire system from "scratch", from just cm3, no libraries, ??? and cm3 no longer is tied to the libraries it is building at all (it used to be, it was bad). The second machine should have a working cm3. You can download a release. cd scripts/python ./boot1.py FreeBSD4 ?or ./boot1.py I386_FREEBSD wait a bit you'll have cme-boot-I386_FREEBSD-timestamp.tgz or such. Copy (scp) that to the FreeBSD 4 machine. Extract it. cd into it. Maybe look at the top of Makefile. ?Sometimes it isn't quite right. Using autoconf/libtool just a bit here is a good idea for future. make, maybe gnumake or gmake, though it is a very simple Makefile. result is cm3 in current directory ? ./cm3 ? It should say "unable to find cm3.cfg". ? If so, good, continue. ? If not, something didn't work and you'll have to investigate. mkdir -p $HOME/cm3/bin?? # or whatever cp cm3 $HOME/cm3/bin export PATH=$HOME/cm3/bin:$PATH cd scripts/python ./boot2.sh wait a while, a while result should be a working system, that built itself as well (look at boot2.sh) http://modula3.elegosoft.com/cm3/uploaded-archives/index.html You should be able to start from here: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-FreeBSD4-1.tar.gz or, er...here http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-FreeBSD4-1-userthreads.tar.gz Does FreeBSD4 have any sort of pthreads? If not, in the above instructions, you will need to make an edit in m3-libs/m3core/src/thread.quake. In the current tree, it looks pretty obvious what to do, since it is here that OpenBSD is pointed at user threads. In head,? I have added support and significantly tested a bunch of "fixed names": ? I386_LINUX, I386_FREEBSD, I386_NETBSD, I386_NT, I386_CYGWIN, I386_MINGW. Did I miss any? These are good names, right? esp. the last three? The one lagging point though is what to do about "SPARC32_SOLARIS". I think probably use cc by default but make swtiching to gcc just be a one line change in the config file. Maybe provide config files SPARC32_SOLARIS and SPARC32_SOLARIS_gcc. ?But they'd have the same TARGET and BUILD_DIR: SPARC32_SOLARIS. And maybe it should be SPARC_SOLARIS. ?- Jay ---------------------------------------- > To: wagner at elegosoft.com > Date: Tue, 13 Jul 2010 02:20:43 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] "FreeBSD4" false advertising > > Olaf Wagner writes: > ... > >FreeBSD 4.x and later: cm3-min-POSIX-FreeBSD4-d5.5.0.tgz > >(built on FreeBSD 4.11 i686) at > > > > http://www.modula3.com/cm3/cm3-min-POSIX-FreeBSD4-d5.5.0.tgz > > > >This could be used together with the upgrade.sh script to built the > >5.8 release sources. > > > >> I have the following on a bona fide FreeBSD 4.11-RELEASE system: > >> > >> (62)trs80:~>cm3 -version > >> Critical Mass Modula-3 version d0.0.0 > >> last updated: unknown > >> compiled: 2009-04-25 02:28:01 > >> configuration: /usr/local/cm3/bin/cm3.cfg > > > >As the version string is actually undefined, this doesn't tell us very =20 > >much :-( > > Olaf, I'm pretty sure that release archive is a tarred up version of my > system. (I built it on this machine!) > > How do I use upgrade.sh? I've been doing things manually following Tony's > recommendations from a few years ago and that doesn't work. > > Well I'll try the obvious thing :-) > > Mika From hosking at cs.purdue.edu Tue Jul 13 16:36:11 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 13 Jul 2010 10:36:11 -0400 Subject: [M3devel] import from same .so or not In-Reply-To: References: , , <9241B253-8004-4DDD-B1EF-A7D02A3FEAFD@cs.purdue.edu> Message-ID: <76827F66-451E-410E-9AF0-200D9538AFA1@cs.purdue.edu> OK, so what you want is for the build system (cm3/src/M3Build.m3) to pass a flag saying that a given module is package visible. Shouldn't be too hard to do. On 12 Jul 2010, at 20:50, Jay K wrote: > I think it'd be another boolean or expansion of a boolean to an integer to declare/import/begin_procedure/constant/variable. > Not passing all the files at once. > > > Passing all the files at once is attractive for reasons of compilation perf and optimizing codegen but I believe it requires a lot of other work. > > > Similarly, passing all the C files at once to the C compiler is also attractive, and more work. > > > LTCG/LTO provide similar benefits, but we aren't setup to use LTO and honestly I'm trying to ignore it. > I'll settle for -O1/2/3. > > > - Jay > > Subject: Re: [M3devel] import from same .so or not > From: hosking at cs.purdue.edu > Date: Mon, 12 Jul 2010 20:14:39 -0400 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > There question is where and how to communicate it back to gcc. Does it mean putting all the module units on the same command line for compilation by a single instance of cm3cg? Or do you communicate it some other way? > > On 12 Jul 2010, at 19:53, Jay K wrote: > > I don't know. I hope not. The information is there: lowercase interface vs. uppercase Interface, lowercase module vs. uppercase Module, derived_interface(hidden or private). > I haven't looked at where all it is sent around. > > - Jay > > > > Subject: Re: [M3devel] import from same .so or not > > From: hosking at cs.purdue.edu > > Date: Mon, 12 Jul 2010 09:28:43 -0400 > > CC: m3devel at elegosoft.com > > To: jay.krell at cornell.edu > > > > It seems to me this would require massive reworking of the build infrastructure! > > > > On 11 Jul 2010, at 21:58, Jay K wrote: > > > > > > > > It seems to me, an important bit of information is not provided to the backend. > > > > > > The backend is told "import" or "export". > > > But this is about "modules", .m3 files to .m3 files. > > > > > > It isn't about .so files to .so files, or .dlls to .dlls. > > > > > > It's really tristate, not boolean: > > > private to just this source file > > > private to this source file and those it statically links to > > > public for all > > > > > > Granted, you might statically link "everything". > > > There isn't enforcement of the middle state, and symbols still need to be as unique as the third state. > > > But it is definitely useful. > > > > > > In particular we don't use DECL_VISIBILITY (p) = VISIBILITY_HIDDEN enough. > > > For a long time we never used it. e.g. in the release branch. > > > > > > Agreed? > > > Anyone volunteer to fix? > > > Or mind if I try? > > > > > > > > > - Jay > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at wickensonline.co.uk Tue Jul 13 21:19:15 2010 From: mark at wickensonline.co.uk (Mark Wickens) Date: Tue, 13 Jul 2010 20:19:15 +0100 Subject: [M3devel] CM3 on Alpha tru64 4.0G In-Reply-To: <76827F66-451E-410E-9AF0-200D9538AFA1@cs.purdue.edu> References: , , <9241B253-8004-4DDD-B1EF-A7D02A3FEAFD@cs.purdue.edu> <76827F66-451E-410E-9AF0-200D9538AFA1@cs.purdue.edu> Message-ID: <1279048755.1793.13.camel@x60.appsoftint.co.uk> Hi Guys, I've been trying unsuccessfully to build various version of Modula-3 (DEC-SRC, PM3, CM3) on a DEC Alpha 300 running tru64 4.0G and was wondering whether anyone could give some guidance of what is possible, indeed sensible. I've received a couple of helpful emails for Daniel, but what I'd really like clarified are the following: 1. Is this sensible, or is tru64 5+ the only realistic tru64 platform to attempt? 2. The executables for tru64 uploaded to the opencm3 website in cm3-min-ALPHA_OSF-d5.8.2-20100612.tar.gz don't work for me - I get a decthreads exception. Does anyone know what version of tru64 these were built with? 3. Is it possible to build CM3 from scratch, or do I need some version of the M3 build tools? Many thanks for the help. I used DEC-SRC Modula-3 around 1995 and am trying to get it compiled up for a recent project, but on an original platform. Some may call me crazy, and they'd be totally justified. I'm not sure whether back-in-the-day I had it running on tru64 (well back then it would have been Digital Unix 3.2C) or whether it was on a linux box. Thanks for the help, Mark. From hosking at cs.purdue.edu Tue Jul 13 22:31:39 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 13 Jul 2010 16:31:39 -0400 Subject: [M3devel] CM3 on Alpha tru64 4.0G In-Reply-To: <1279048755.1793.13.camel@x60.appsoftint.co.uk> References: , , <9241B253-8004-4DDD-B1EF-A7D02A3FEAFD@cs.purdue.edu> <76827F66-451E-410E-9AF0-200D9538AFA1@cs.purdue.edu> <1279048755.1793.13.camel@x60.appsoftint.co.uk> Message-ID: <8E02058D-1A62-48FF-8DA7-B2C40C53B048@cs.purdue.edu> This should be entirely doable, so long as reasonable pthread APIs exist on 4.x Tru64. What was the decthreads exception? On 13 Jul 2010, at 15:19, Mark Wickens wrote: > Hi Guys, > > I've been trying unsuccessfully to build various version of Modula-3 > (DEC-SRC, PM3, CM3) on a DEC Alpha 300 running tru64 4.0G and was > wondering whether anyone could give some guidance of what is possible, > indeed sensible. > > I've received a couple of helpful emails for Daniel, but what I'd really > like clarified are the following: > > 1. Is this sensible, or is tru64 5+ the only realistic tru64 platform to > attempt? > > 2. The executables for tru64 uploaded to the opencm3 website in > cm3-min-ALPHA_OSF-d5.8.2-20100612.tar.gz don't work for me - I get a > decthreads exception. Does anyone know what version of tru64 these were > built with? > > 3. Is it possible to build CM3 from scratch, or do I need some version > of the M3 build tools? > > Many thanks for the help. I used DEC-SRC Modula-3 around 1995 and am > trying to get it compiled up for a recent project, but on an original > platform. Some may call me crazy, and they'd be totally justified. I'm > not sure whether back-in-the-day I had it running on tru64 (well back > then it would have been Digital Unix 3.2C) or whether it was on a linux > box. > > Thanks for the help, > > Mark. From mark at wickensonline.co.uk Tue Jul 13 22:40:28 2010 From: mark at wickensonline.co.uk (Mark Wickens) Date: Tue, 13 Jul 2010 21:40:28 +0100 Subject: [M3devel] CM3 on Alpha tru64 4.0G In-Reply-To: <8E02058D-1A62-48FF-8DA7-B2C40C53B048@cs.purdue.edu> References: , , <9241B253-8004-4DDD-B1EF-A7D02A3FEAFD@cs.purdue.edu> <76827F66-451E-410E-9AF0-200D9538AFA1@cs.purdue.edu> <1279048755.1793.13.camel@x60.appsoftint.co.uk> <8E02058D-1A62-48FF-8DA7-B2C40C53B048@cs.purdue.edu> Message-ID: <1279053628.1793.15.camel@x60.appsoftint.co.uk> Hi Tony, the exception I get is as follows: >From cm3-min-ALPHA_OSF-d5.8.2-20100612/bin bash-3.2$ ./cm3 %DECthreads bugcheck (version V3.18-037), terminating execution. % Reason: stkGet: (4) nxm_stack_create (0,5251072,16384,8192) % Running on OSF1 V4.0(1530) on AlphaServer 300 4/266, 256Mb; 1 CPUs, pid 21360 From jay.krell at cornell.edu Wed Jul 14 01:04:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 13 Jul 2010 23:04:20 +0000 Subject: [M3devel] CM3 on Alpha tru64 4.0G In-Reply-To: <1279053628.1793.15.camel@x60.appsoftint.co.uk> References: ,, , , , <9241B253-8004-4DDD-B1EF-A7D02A3FEAFD@cs.purdue.edu>, , <76827F66-451E-410E-9AF0-200D9538AFA1@cs.purdue.edu>, <1279048755.1793.13.camel@x60.appsoftint.co.uk>, <8E02058D-1A62-48FF-8DA7-B2C40C53B048@cs.purdue.edu>, <1279053628.1793.15.camel@x60.appsoftint.co.uk> Message-ID: Things to try: cross build, user threads. Do you have a "modern" system with a working cm3? Do you have cvs and a working C compiler/linker on this older system? ?- Jay ---------------------------------------- > From: mark at wickensonline.co.uk > To: hosking at cs.purdue.edu > Date: Tue, 13 Jul 2010 21:40:28 +0100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] CM3 on Alpha tru64 4.0G > > Hi Tony, the exception I get is as follows: > > >From cm3-min-ALPHA_OSF-d5.8.2-20100612/bin > > bash-3.2$ ./cm3 > %DECthreads bugcheck (version V3.18-037), terminating execution. > % Reason: stkGet: (4) nxm_stack_create (0,5251072,16384,8192) > % Running on OSF1 V4.0(1530) on AlphaServer 300 4/266, 256Mb; 1 CPUs, > pid 21360 > > From jay.krell at cornell.edu Wed Jul 14 01:27:51 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 13 Jul 2010 23:27:51 +0000 Subject: [M3devel] CM3 on Alpha tru64 4.0G In-Reply-To: References: , , , , , , , , <9241B253-8004-4DDD-B1EF-A7D02A3FEAFD@cs.purdue.edu>, , , , <76827F66-451E-410E-9AF0-200D9538AFA1@cs.purdue.edu>, , <1279048755.1793.13.camel@x60.appsoftint.co.uk>, , <8E02058D-1A62-48FF-8DA7-B2C40C53B048@cs.purdue.edu>, , <1279053628.1793.15.camel@x60.appsoftint.co.uk>, Message-ID: > Things to try: cross build, user threads. http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-ALPHA_OSF-pthreads-d5.8.2-20100713.tgz or http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-ALPHA_OSF-userthreads-d5.8.2-20100713.tgz ? And in userthreads, if there is no get/set/make/swapcontext, you can change the #if at the top of ThreadPosixC.c to try sigaltstack. Also the userthreads Makefile has -lpthread in it, which you'll maybe want to remove...depending on if there is pthread_atfork, i.e. you? might want to tweak this: jbook2:cm3-boot-ALPHA_OSF-d5.8.2-20100713 jay$ grep pthread_atfork *c RTProcessC.c:????? int i = pthread_atfork(prepare, parent, child); but try the pthread version first? These will give you a cm3 and if it prints "unable to find cm3.cfg", good. Tru64 4.x isn't officially supported by gcc any longer, but I noticed recent test results posted anyway. You just have to configure -enable-obsolete or somesuch. Can you give me ssh access? That's a good and bad thing. Should be doable without such direct help by me.. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: mark at wickensonline.co.uk; hosking at cs.purdue.edu > Date: Tue, 13 Jul 2010 23:04:20 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] CM3 on Alpha tru64 4.0G > > > Things to try: cross build, user threads. > Do you have a "modern" system with a working cm3? > Do you have cvs and a working C compiler/linker on this older system? > > - Jay > > ---------------------------------------- > > From: mark at wickensonline.co.uk > > To: hosking at cs.purdue.edu > > Date: Tue, 13 Jul 2010 21:40:28 +0100 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] CM3 on Alpha tru64 4.0G > > > > Hi Tony, the exception I get is as follows: > > > > >From cm3-min-ALPHA_OSF-d5.8.2-20100612/bin > > > > bash-3.2$ ./cm3 > > %DECthreads bugcheck (version V3.18-037), terminating execution. > > % Reason: stkGet: (4) nxm_stack_create (0,5251072,16384,8192) > > % Running on OSF1 V4.0(1530) on AlphaServer 300 4/266, 256Mb; 1 CPUs, > > pid 21360 > > > > > From jay.krell at cornell.edu Wed Jul 14 11:17:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Jul 2010 09:17:57 +0000 Subject: [M3devel] -pthread vs. -pthreads arg Message-ID: Just a note: Some versions of gcc accept -pthread, some -pthreads, some both. Lame. In particular, from the few systems I've tested: Darwin either Solaris pthreads FreeBSD OpenBSD Linux pthread ??? probably NetBSD, Interix, Cygwin same but I didn't check Solaris cc use -mt instead ?- Jay From mark at wickensonline.co.uk Wed Jul 14 11:40:23 2010 From: mark at wickensonline.co.uk (Mark Wickens) Date: Wed, 14 Jul 2010 10:40:23 +0100 Subject: [M3devel] -pthread vs. -pthreads arg In-Reply-To: References: Message-ID: <1279100423.1793.22.camel@x60.appsoftint.co.uk> On Wed, 2010-07-14 at 09:17 +0000, Jay K wrote: > Just a note: > Some versions of gcc accept -pthread, some -pthreads, some both. Lame. > In particular, from the few systems I've tested: > > Darwin either > Solaris pthreads > FreeBSD OpenBSD Linux pthread > probably NetBSD, Interix, Cygwin same but I didn't check > Solaris cc use -mt instead > > > - Jay > > Hi Jay, So what would you recommend as the best thing to try first? Cross-compile? I installed the debian based package on a 32 bit ubuntu 10.4 install and that works fine. I am also happy to give you remote access to the box - that is no problem at all. Regards, Mark. From wagner at elegosoft.com Wed Jul 14 12:55:16 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 14 Jul 2010 12:55:16 +0200 Subject: [M3devel] LongrealType missed, was: Re: "FreeBSD4" false advertising In-Reply-To: <20100714104312.155351A2098@async.async.caltech.edu> References: <20100714094120.93B001A2098@async.async.caltech.edu> <20100714114648.nhnwruh008840wso@mail.elegosoft.com> <20100714100138.631581A2098@async.async.caltech.edu>, <20100714100525.BEE931A2096@async.async.caltech.edu> <20100714104312.155351A2098@async.async.caltech.edu> Message-ID: <20100714125516.1mzfehgnkgcs800w@mail.elegosoft.com> Quoting Mika Nystrom : > Argh is it really necessary to break source compatibility here? > > I also don't like that I as a client have to import IEEE things when all > I want is "LONGREAL" (and let Modula-3 do whatever it wants with that). > > I would propose at least having an interface LongrealType with > > CONST Hash = Longreal.Hash > > etc. so as not to force clients to import all the nitty-gritty about > various floating point representations. And so as not to break source > compatibility! If I change this by removing Type, my code will no longer > compile with the old compilers.... Hm, I'm a little bit out of context here... What was the reason for this change? It seems nobody else has bothered so far. This was the commit in question: 2009-12-23 21:43 hosking * m3-libs/: m3core/src/m3makefile, libm3/src/types/ASCII.i3, libm3/src/types/ASCII.m3, libm3/src/types/Boolean.i3, libm3/src/types/Boolean.m3, libm3/src/types/COPYRIGHT-CMASS, libm3/src/types/Char.i3, libm3/src/types/Char.m3, libm3/src/types/Int32.i3, libm3/src/types/Int32.m3, libm3/src/types/Int64.i3, libm3/src/types/Int64.m3, libm3/src/types/Integer.i3, libm3/src/types/Integer.m3, libm3/src/types/Longint.i3, libm3/src/types/Longint.m3, libm3/src/types/LongrealType.i3, libm3/src/types/LongrealType.m3, libm3/src/types/RealType.i3, libm3/src/types/RealType.m3, libm3/src/types/Refany.i3, libm3/src/types/Refany.m3, libm3/src/types/Unicode.i3, libm3/src/types/Unicode.m3, libm3/src/types/WideChar.i3, libm3/src/types/WideChar.m3, libm3/src/types/m3makefile, m3core/src/float/Common/Extended.m3, m3core/src/float/Common/LongReal.m3, m3core/src/float/Common/Real.m3, m3core/src/float/IEEE/Extended.i3, m3core/src/float/IEEE/LongReal.i3, m3core/src/float/IEEE/Real.i3, m3core/src/float/VAX/Extended.i3, m3core/src/float/VAX/LongReal.i3, m3core/src/float/VAX/Real.i3: Move libm3/src/types into m3core. Note that LongrealType and RealType have been folded into m3core/src/float. Clients will need adjustment. Any comments? Olaf > Mika > > Jay K writes: >> >> Remove "Type" it appears. >> >> >> http://modula3.elegosoft.com/cm3/ChangeLog-2009 >> >> search for "clients will need". >> >> e.g. >> >> +++ cm3/m3-demo/mentor/src/binpack/m3makefile 2009/12/23 22:05:06 1.2 >> @@ -10=2C7 +10=2C7 @@ >> =20 >> import ("zeus") >> =20 >> -list ("Real"=2C "RealType") >> +list ("Real"=2C "Real") >> =20 >> zume ("Binpack") >> oblume ("Binpack"=2C "myview") >> >> --- cm3/m3-demo/mentor/src/binpack/RealList.i3 2001/01/13 14:18:20 1.1 >> +++ cm3/m3-demo/mentor/src/binpack/RealList.i3 2009/12/23 22:05:05 1.2 >> @@ -2=2C4 +2=2C4 @@ >> (* Distributed only by permission. *) >> (* Last modified on Fri Jul 9 16:36:47 PDT 1993 by mhb *) >> =20 >> -INTERFACE RealList =3D List(RealType) END RealList. >> +INTERFACE RealList =3D List(Real) END RealList. >> >> --- cm3/m3-demo/mentor/src/binpack/RealList.m3 2001/01/13 14:18:20 1.1 >> +++ cm3/m3-demo/mentor/src/binpack/RealList.m3 2009/12/23 22:05:06 1.2 >> @@ -2=2C4 +2=2C4 @@ >> (* All rights reserved. *) >> (* See the file COPYRIGHT for a full description. *) >> =20 >> -MODULE RealList =3D List(RealType) END RealList. >> +MODULE RealList =3D List(Real) END RealList. >> >> =A0- Jay >> >> ---------------------------------------- >>> To: wagner at elegosoft.com >>> CC: jay.krell at cornell.edu=3B mika at async.caltech.edu >>> Subject: Re: [M3devel] "FreeBSD4" false advertising >>> Date: Wed=2C 14 Jul 2010 03:05:25 -0700 >>> From: mika at async.async.caltech.edu >>> >>> I'm not actually sure I understand the intent of the changes in this area= >> . >>> >>> My old m3makefile has: >>> >>> Table("TextLongReal"=2C "Text"=2C "LongrealType") >>> >>> What am I supposed to use now? >>> >>> Mika >>> >>> Mika Nystrom writes: >>> >Olaf Wagner writes: >>> >>Quoting Mika Nystrom : >>> >> >>> >>> Hi Jay=2C Olaf=2C >>> >>> >>> >>> I actually built everything! After backing out some of my changes >>> >>> that I had tried to get 5.8.6-REL to build with=2C it worked=2C and m= >> entor >>> >>> ran=2C even. >>> >> >>> >>Great! So it's still possible to build cm3 on FreeBSD 4=2C though >>> >>not our release code. >>> > >>> >The differences relative to the current CVS head are very minor. >>> > >>> >1. Added FreeBSD4 to thread.quake as a non-pthread platform >>> > >>> >2. got rid of the -m32 flags in FreeBSD4.conf >>> > >>> >Everything else that needed to change I think Jay has managed to put in >>> >the CVS head. >>> > >>> >> >>> >>> But... what happened to libm3/src/types? Building my own code I get >>> >>> the following errors: >>> >>> >>> >>> new source -> compiling LRInterval.i3 >>> >>> "../FreeBSD4/LRInterval.i3 =3D3D> ../src/Interval.ig"=2C line 5: unab= >> le to =3D20 >>> >>> find interface (LongrealType) >>> >>> 1 error encountered >>> >>> >>> >>> I can't find LongrealType anywhere=2C do I have a broken checkout? We= >> ll=2C it >>> >>> is in one place=2C in "doc". (Same for RealType=2C maybe others?) >>> >> >>> >>See =3D20 >>> >>http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/t= >> ypes/=3D >>> >>Attic/LongrealType.i3 >>> > >>> >Surely this is wrong?? I am looking for an interface that has T =3D >>> >LONGREAL=2C not something that lets me muck around with the representati= >> on >>> >of IEEE=2C VAX=2C etc.=2C floating-point formats. >>> > >>> >Why is it even in m3core? This seems clearly like libm3 stuff.. I notice= >> d >>> >Boolean.i3 also moved. >>> > >>> >Also if there is no importable interface called LongrealType that is goi= >> ng >>> >to cause endless problems with source that is supposed to compile under >>> >different versions of Modula-3. Even relatively recent CM3s required >>> >you to use LongrealType to instantiate generics. >>> > >>> > Mika >> = > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 14 13:23:49 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Jul 2010 11:23:49 +0000 Subject: [M3devel] LongrealType missed, was: Re: "FreeBSD4" false advertising In-Reply-To: <20100714125516.1mzfehgnkgcs800w@mail.elegosoft.com> References: <20100714094120.93B001A2098@async.async.caltech.edu>, <20100714114648.nhnwruh008840wso@mail.elegosoft.com>, <20100714100138.631581A2098@async.async.caltech.edu>, <20100714100525.BEE931A2096@async.async.caltech.edu>, , <20100714104312.155351A2098@async.async.caltech.edu>, <20100714125516.1mzfehgnkgcs800w@mail.elegosoft.com> Message-ID: Mika, Please try updating libm3 and see if that works for you. Thanks. ?- Jay ---------------------------------------- > Date: Wed, 14 Jul 2010 12:55:16 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > CC: jay.krell at cornell.edu; mika at async.caltech.edu > Subject: LongrealType missed, was: Re: [M3devel] "FreeBSD4" false advertising > > Quoting Mika Nystrom : > > > Argh is it really necessary to break source compatibility here? > > > > I also don't like that I as a client have to import IEEE things when all > > I want is "LONGREAL" (and let Modula-3 do whatever it wants with that). > > > > I would propose at least having an interface LongrealType with > > > > CONST Hash = Longreal.Hash > > > > etc. so as not to force clients to import all the nitty-gritty about > > various floating point representations. And so as not to break source > > compatibility! If I change this by removing Type, my code will no longer > > compile with the old compilers.... > > Hm, I'm a little bit out of context here... > What was the reason for this change? It seems nobody else has bothered > so far. > > This was the commit in question: > > 2009-12-23 21:43 hosking > > * m3-libs/: m3core/src/m3makefile, libm3/src/types/ASCII.i3, > libm3/src/types/ASCII.m3, libm3/src/types/Boolean.i3, > libm3/src/types/Boolean.m3, libm3/src/types/COPYRIGHT-CMASS, > libm3/src/types/Char.i3, libm3/src/types/Char.m3, > libm3/src/types/Int32.i3, libm3/src/types/Int32.m3, > libm3/src/types/Int64.i3, libm3/src/types/Int64.m3, > libm3/src/types/Integer.i3, libm3/src/types/Integer.m3, > libm3/src/types/Longint.i3, libm3/src/types/Longint.m3, > libm3/src/types/LongrealType.i3, libm3/src/types/LongrealType.m3, > libm3/src/types/RealType.i3, libm3/src/types/RealType.m3, > libm3/src/types/Refany.i3, libm3/src/types/Refany.m3, > libm3/src/types/Unicode.i3, libm3/src/types/Unicode.m3, > libm3/src/types/WideChar.i3, libm3/src/types/WideChar.m3, > libm3/src/types/m3makefile, m3core/src/float/Common/Extended.m3, > m3core/src/float/Common/LongReal.m3, m3core/src/float/Common/Real.m3, > m3core/src/float/IEEE/Extended.i3, m3core/src/float/IEEE/LongReal.i3, > m3core/src/float/IEEE/Real.i3, m3core/src/float/VAX/Extended.i3, > m3core/src/float/VAX/LongReal.i3, m3core/src/float/VAX/Real.i3: > > Move libm3/src/types into m3core. > Note that LongrealType and RealType have been folded into m3core/src/float. > Clients will need adjustment. > > Any comments? > > Olaf > > > Mika > > > > Jay K writes: > >> > >> Remove "Type" it appears. > >> > >> > >> http://modula3.elegosoft.com/cm3/ChangeLog-2009 > >> > >> search for "clients will need". > >> > >> e.g. > >> > >> +++ cm3/m3-demo/mentor/src/binpack/m3makefile 2009/12/23 22:05:06 1.2 > >> @@ -10=2C7 +10=2C7 @@ > >> =20 > >> import ("zeus") > >> =20 > >> -list ("Real"=2C "RealType") > >> +list ("Real"=2C "Real") > >> =20 > >> zume ("Binpack") > >> oblume ("Binpack"=2C "myview") > >> > >> --- cm3/m3-demo/mentor/src/binpack/RealList.i3 2001/01/13 14:18:20 1.1 > >> +++ cm3/m3-demo/mentor/src/binpack/RealList.i3 2009/12/23 22:05:05 1.2 > >> @@ -2=2C4 +2=2C4 @@ > >> (* Distributed only by permission. *) > >> (* Last modified on Fri Jul 9 16:36:47 PDT 1993 by mhb *) > >> =20 > >> -INTERFACE RealList =3D List(RealType) END RealList. > >> +INTERFACE RealList =3D List(Real) END RealList. > >> > >> --- cm3/m3-demo/mentor/src/binpack/RealList.m3 2001/01/13 14:18:20 1.1 > >> +++ cm3/m3-demo/mentor/src/binpack/RealList.m3 2009/12/23 22:05:06 1.2 > >> @@ -2=2C4 +2=2C4 @@ > >> (* All rights reserved. *) > >> (* See the file COPYRIGHT for a full description. *) > >> =20 > >> -MODULE RealList =3D List(RealType) END RealList. > >> +MODULE RealList =3D List(Real) END RealList. > >> > >> =A0- Jay > >> > >> ---------------------------------------- > >>> To: wagner at elegosoft.com > >>> CC: jay.krell at cornell.edu=3B mika at async.caltech.edu > >>> Subject: Re: [M3devel] "FreeBSD4" false advertising > >>> Date: Wed=2C 14 Jul 2010 03:05:25 -0700 > >>> From: mika at async.async.caltech.edu > >>> > >>> I'm not actually sure I understand the intent of the changes in this area= > >> . > >>> > >>> My old m3makefile has: > >>> > >>> Table("TextLongReal"=2C "Text"=2C "LongrealType") > >>> > >>> What am I supposed to use now? > >>> > >>> Mika > >>> > >>> Mika Nystrom writes: > >>> >Olaf Wagner writes: > >>> >>Quoting Mika Nystrom : > >>> >> > >>> >>> Hi Jay=2C Olaf=2C > >>> >>> > >>> >>> I actually built everything! After backing out some of my changes > >>> >>> that I had tried to get 5.8.6-REL to build with=2C it worked=2C and m= > >> entor > >>> >>> ran=2C even. > >>> >> > >>> >>Great! So it's still possible to build cm3 on FreeBSD 4=2C though > >>> >>not our release code. > >>> > > >>> >The differences relative to the current CVS head are very minor. > >>> > > >>> >1. Added FreeBSD4 to thread.quake as a non-pthread platform > >>> > > >>> >2. got rid of the -m32 flags in FreeBSD4.conf > >>> > > >>> >Everything else that needed to change I think Jay has managed to put in > >>> >the CVS head. > >>> > > >>> >> > >>> >>> But... what happened to libm3/src/types? Building my own code I get > >>> >>> the following errors: > >>> >>> > >>> >>> new source -> compiling LRInterval.i3 > >>> >>> "../FreeBSD4/LRInterval.i3 =3D3D> ../src/Interval.ig"=2C line 5: unab= > >> le to =3D20 > >>> >>> find interface (LongrealType) > >>> >>> 1 error encountered > >>> >>> > >>> >>> I can't find LongrealType anywhere=2C do I have a broken checkout? We= > >> ll=2C it > >>> >>> is in one place=2C in "doc". (Same for RealType=2C maybe others?) > >>> >> > >>> >>See =3D20 > >>> >>http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/t= > >> ypes/=3D > >>> >>Attic/LongrealType.i3 > >>> > > >>> >Surely this is wrong?? I am looking for an interface that has T =3D > >>> >LONGREAL=2C not something that lets me muck around with the representati= > >> on > >>> >of IEEE=2C VAX=2C etc.=2C floating-point formats. > >>> > > >>> >Why is it even in m3core? This seems clearly like libm3 stuff.. I notice= > >> d > >>> >Boolean.i3 also moved. > >>> > > >>> >Also if there is no importable interface called LongrealType that is goi= > >> ng > >>> >to cause endless problems with source that is supposed to compile under > >>> >different versions of Modula-3. Even relatively recent CM3s required > >>> >you to use LongrealType to instantiate generics. > >>> > > >>> > Mika > >> = > > > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Wed Jul 14 15:19:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Jul 2010 13:19:31 +0000 Subject: [M3devel] SOLgnu not working Message-ID: Just a note, that I'm aware, SOLgnu appears to be broken in head. = package /home/jay/dev2/cm3/m3-win/import-libs == ?+++ /cm3/bin/cm3??? -build -DROOT=/home/jay/dev2/cm3 +++ *** *** runtime error: ***??? Unhandled exception: OSError.E ***??? file "../src/os/POSIX/OSErrorPosix.m3", line 50 *** Abort - core dumped No ETA on a fix. But it is? important. ?- Jay From jay.krell at cornell.edu Wed Jul 14 17:03:55 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 14 Jul 2010 15:03:55 +0000 Subject: [M3devel] SOLgnu not working In-Reply-To: References: Message-ID: Oh, sorry, it's probably ok. ? Debugging it... I was in user threads..because I had bootstrapped from 5.4.0. Maybe 5.4.0 is broken, don't care. ? Tried SOLsun..working better. ? Compared them..discovered this SOLgnu used the 4.5.0 backend, which isn't yet enabled. ! ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: SOLgnu not working > Date: Wed, 14 Jul 2010 13:19:31 +0000 > > > Just a note, that I'm aware, SOLgnu appears to be broken in head. > > = package /home/jay/dev2/cm3/m3-win/import-libs == > > +++ /cm3/bin/cm3 -build -DROOT=/home/jay/dev2/cm3 +++ > > > *** > *** runtime error: > *** Unhandled exception: OSError.E > *** file "../src/os/POSIX/OSErrorPosix.m3", line 50 > *** > > Abort - core dumped > > No ETA on a fix. But it is important. > > - Jay > > > > > From wagner at elegosoft.com Thu Jul 15 14:43:43 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 15 Jul 2010 14:43:43 +0200 Subject: [M3devel] minor problems on the release branch Message-ID: <20100715144343.qby2zwskgg4kok48@mail.elegosoft.com> While checking the status of the final 5.8.6 release of CM3, I found several minor problems, which would benefit from attention nonetheless. Investigating these should also be a good starting point for newbies and others lurking on the list and waiting for something to do: Why did this change? http://hudson.modula3.com:8080/view/cm3/job/cm3-test-m3tests-AMD64_LINUX/lastBuild/testReport/(root)/m3tests/p040__binary_____ASCII_conversion_routines (failing since Build #556 (Apr 29, 2010 9:35:06 PM)) same issue: http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-m3tests-I386_OPENBSD/lastBuild/testReport/(root)/m3tests/p040__binary_____ASCII_conversion_routines (failing since Build #28 (Nov 22, 2009 7:43:34 AM)) http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-m3tests-LINUXLIBC6/lastBuild/testReport/(root)/m3tests/p040__binary_____ASCII_conversion_routines (failing since Build #276 (Jul 9, 2010 11:40:25 AM)) The shipping tests on Nt386 seem to have never worked: http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-m3tests-NT386/374/testReport/ Test reporting ist still more or less completely broken on SOLsun :-( http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-m3tests-SOLsun/lastBuild Failed packages on I386_OPENBSD: http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-all-pkgs-I386_OPENBSD/44/testReport/ Failed packages on NT386: http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-all-pkgs-NT386/182/testReport/ m3gdb build fails on PPC_LINUX and SPARC32_LINUX: http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-all-pkgs-PPC_LINUX/18/testReport/ http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-all-pkgs-SPARC32_LINUX/lastBuild/testReport/ Failed package tests on SOLgnu and SOLsun: http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-all-pkgs-SOLgnu/lastBuild/testReport/ http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-all-pkgs-SOLsun/lastBuild/testReport/ Regards, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 bugs at elego.de Thu Jul 15 15:21:30 2010 From: bugs at elego.de (CM3) Date: Thu, 15 Jul 2010 13:21:30 -0000 Subject: [M3devel] [CM3] #1068: Segmentation violation in String8.m3 In-Reply-To: <062.b174f7e6cb17a55b692f50f311e18b17@elego.de> References: <062.b174f7e6cb17a55b692f50f311e18b17@elego.de> Message-ID: <071.f664d53a4c2a0572384dcc425bb5f2da@elego.de> #1068: Segmentation violation in String8.m3 ------------------------------------------+--------------------------------- Reporter: peter.mckinna@? | Owner: wagner Type: sw-bug | Status: assigned Priority: medium | Milestone: CM3 Release 5.9 Component: comm | Version: 5.8-RC3 Severity: serious | Keywords: pickles, 64 to 32 bit Relnote: | Org: Estimatedhours: 0.0 | Hours: 0 Billable: 1 | Totalhours: 0 Internal: 0 | ------------------------------------------+--------------------------------- Htr: Fix: Env: ------------------------------------------+--------------------------------- Changes (by wagner): * owner: rbates => wagner * milestone: CM3 release 5.8 => CM3 Release 5.9 -- Ticket URL: CM3 Critical Mass Modula3 Compiler From bugs at elego.de Thu Jul 15 15:22:23 2010 From: bugs at elego.de (CM3) Date: Thu, 15 Jul 2010 13:22:23 -0000 Subject: [M3devel] [CM3] #1068: Segmentation violation in String8.m3 In-Reply-To: <062.b174f7e6cb17a55b692f50f311e18b17@elego.de> References: <062.b174f7e6cb17a55b692f50f311e18b17@elego.de> Message-ID: <071.7f4f89c8c47fb8f7fdd347237342be4a@elego.de> #1068: Segmentation violation in String8.m3 ------------------------------------------+--------------------------------- Reporter: peter.mckinna@? | Owner: rbates Type: sw-bug | Status: assigned Priority: medium | Milestone: CM3 Release 5.9 Component: comm | Version: 5.8-RC3 Severity: serious | Keywords: pickles, 64 to 32 bit Relnote: | Org: Estimatedhours: 0.0 | Hours: 0 Billable: 1 | Totalhours: 0 Internal: 0 | ------------------------------------------+--------------------------------- Htr: Fix: Env: ------------------------------------------+--------------------------------- Changes (by wagner): * owner: wagner => rbates -- Ticket URL: CM3 Critical Mass Modula3 Compiler From jay.krell at cornell.edu Thu Jul 15 15:39:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 15 Jul 2010 13:39:04 +0000 Subject: [M3devel] branches in changelog? Message-ID: http://www.opencm3.net/ChangeLog-2009 indicates when a file is added to release branch, but not modified. That might help track down..e.g. what happened circa November 21 2009. Thanks, ?- Jay From jay.krell at cornell.edu Thu Jul 15 15:56:55 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 15 Jul 2010 13:56:55 +0000 Subject: [M3devel] minor problems on the release branch In-Reply-To: <20100715144343.qby2zwskgg4kok48@mail.elegosoft.com> References: <20100715144343.qby2zwskgg4kok48@mail.elegosoft.com> Message-ID: I believe the .M3SHIP tests have always failed because they look for Posix paths in the output. You can likely now create correct stdout.pgm-NT386 and they will work. It's not just the slashes, but also libfoo.a vs. foo.lib, foo.exe vs. foo. I think. I vaguely recall noticing that and that the tests not the functionality was broken. To the extent that the tests are looking for "back substitution" to work and don't care about the others, change the slashes, remove the last path element, and declare that correct output? The float<>string conversion worries me some. I wish we had noticed it earlier. At a certain level, it's not a big deal: the resulting strings are certainly "reasonable". But programs could legitimately take a pretty close dependency on the behavior here. Right? ? Until/unless VAX support comes back, in which case we'll probably get varying results. To debug this, a bit tedious, but someone might consider getting the release branch to just before the failure and verifying it works, then just after the failure, verify it doens't work. Then compare the two branches. SOLsun fails for a minor reason: +cc: Warning: -xarch=v8plus is deprecated, use -m32 -xarch=sparc instead I probably just have to redirect it to >/dev/null. I don't just change the config file. The config file works with a range of cc versions and probes their behavior. ? (something we might consider in a more autoconf-sh way, i.e. less often, though it isn't all that often, and ? someone can upgrade their cc at almost any time, so...) Lots to work through.. ?? - Jay ---------------------------------------- > Date: Thu, 15 Jul 2010 14:43:43 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] minor problems on the release branch > > While checking the status of the final 5.8.6 release of CM3, I found > several minor problems, which would benefit from attention nonetheless. > > Investigating these should also be a good starting point for newbies and > others lurking on the list and waiting for something to do: > > Why did this change? > > > http://hudson.modula3.com:8080/view/cm3/job/cm3-test-m3tests-AMD64_LINUX/lastBuild/testReport/(root)/m3tests/p040__binary_____ASCII_conversion_routines > (failing since Build #556 (Apr 29, 2010 9:35:06 PM)) > > same issue: > > > http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-m3tests-I386_OPENBSD/lastBuild/testReport/(root)/m3tests/p040__binary_____ASCII_conversion_routines > (failing since Build #28 (Nov 22, 2009 7:43:34 AM)) > > > http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-m3tests-LINUXLIBC6/lastBuild/testReport/(root)/m3tests/p040__binary_____ASCII_conversion_routines > (failing since Build #276 (Jul 9, 2010 11:40:25 AM)) > > The shipping tests on Nt386 seem to have never worked: > > http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-m3tests-NT386/374/testReport/ > > Test reporting ist still more or less completely broken on SOLsun :-( > > > http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-m3tests-SOLsun/lastBuild > > Failed packages on I386_OPENBSD: > > > http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-all-pkgs-I386_OPENBSD/44/testReport/ > > Failed packages on NT386: > > > http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-all-pkgs-NT386/182/testReport/ > > m3gdb build fails on PPC_LINUX and SPARC32_LINUX: > > > http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-all-pkgs-PPC_LINUX/18/testReport/ > > http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-all-pkgs-SPARC32_LINUX/lastBuild/testReport/ > > Failed package tests on SOLgnu and SOLsun: > > > http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-all-pkgs-SOLgnu/lastBuild/testReport/ > > http://hudson.modula3.com:8080/view/cm3-test/job/cm3-test-all-pkgs-SOLsun/lastBuild/testReport/ > > Regards, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Thu Jul 15 17:18:08 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 15 Jul 2010 17:18:08 +0200 Subject: [M3devel] CM3 5.8 RELEASE (5.8.6) Message-ID: <20100715171808.ftd7ycx6tcoog8gk@mail.elegosoft.com> Finally I've declared the last state of the release branch as the final CM3 5.8 release! There have been almost no changes in the recent weeks, and it's unlikely that much improvements will be added if we wait any longer. So I've closed the milestone in trac, and retargeted the remaining 3 or 4 issues to the 5.9 release. https://projects.elego.de/cm3/milestone/CM3%20release%205.8 I've also moved the target date for 5.9 to end of June 2011 ;-) https://projects.elego.de/cm3/milestone/CM3%20Release%205.9 The 5.8 release archives can be downloaded here: http://www.modula3.com/cm3/releng/download.html All related information should be available via that link, too. Some more general information can be found at http://www.modula3.com/cm3/download.html I know this has taken longer than ever before, but we've managed it after all. Thanks to everybody who helped with this release. If you still find bugs, please report them here: https://projects.elego.de/cm3/newticket In the next week, I'll change the Hudson jobs to follow the CVS main trunk again. Best regards, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Jul 16 14:58:42 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 16 Jul 2010 12:58:42 +0000 Subject: [M3devel] $ORIGIN? Message-ID: So I can build a distribution FreeBSD 4.11... But it looks like FreeBSD didn't support $ORIGIN until very recently: 8.0. This is evidenced from two places: http://www.freebsd.org/releases/8.0R/relnotes-detailed.html ? indicates it is new and http://www.freebsd.org/cgi/man.cgi lets you specify version. The ld-elf.so manpage doesn't mention it until 8.0. This means, something like: ? FreeBSD users using < 8.0 will need/want to set LD_LIBRARY_PATH. ? I don't think the distributed binaries have any hardcoded paths in them, except for the $ORIGIN stuff, ?? which I think will just be ignored. "Normally" they do, but the distribution build specifically ?? tries to omit them. This "puts pressure" on considering "this problem" more/again? ? NetBSD < 5.0, FreeBSD < 8.0 ... enough to do something about? ? I've been looking into autoconf and libtool some, but i haven't yet, like.. ? what I'd like to see very clearly is them do the "relink before install" behavior. ? Once confirmed to be there.. maybe our "binary" packages are a bunch of .o files? ? Interesting compromise? ? Or, really, maybe we somewhat give up on "relocatability" and hardcode /usr/local/cm3? ? ?? I realize, official Debian packages need to be at /usr. ? Anyone building from source, can put the files anywhere. ? We can also only "give up" on FreeBSD and/or NetBSD -- where $ORIGIN is more recent introduction. I also seem to recall OSF/1 supports arbitrary environment variables, but doesn't define anything for you like $ORIGIN. Some system is that way. For that can invent custom names and wrapper scripts perhaps. I know, a likely question, it has been asked for, "what is common?" i.e. portable, works the same "everywhere"? ? That would be hardcoded paths, no relocatability. $ORIGIN is very common, but less so. I'm the one who opened this can of worms here. ?The previous -rpath was a mess with lots of directories. That could at least be changed to something short. ? $ORIGIN is indeed very promising and fairly portable, but not perfectly portable nor perfectly "behaved". ? I don't think any solution is perfectly "behaved", there are contradictory goals. ?- Jay From wagner at elegosoft.com Fri Jul 16 15:10:02 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 16 Jul 2010 15:10:02 +0200 Subject: [M3devel] $ORIGIN? In-Reply-To: References: Message-ID: <20100716151002.ygdg5pakxwc0kwwc@mail.elegosoft.com> Quoting Jay K : > So I can build a distribution FreeBSD 4.11... > > But it looks like FreeBSD didn't support $ORIGIN until very recently: 8.0. > > This is evidenced from two places: > > http://www.freebsd.org/releases/8.0R/relnotes-detailed.html > ? indicates it is new > > and http://www.freebsd.org/cgi/man.cgi lets you specify version. > The ld-elf.so manpage doesn't mention it until 8.0. That's correct. Alas, there's no common standard shared by all the systems we support. > This means, something like: > ? FreeBSD users using < 8.0 will need/want to set LD_LIBRARY_PATH. We should document that as a workaround. > ? I don't think the distributed binaries have any hardcoded paths in > them, except for the $ORIGIN stuff, > ?? which I think will just be ignored. "Normally" they do, but the > distribution build specifically > ?? tries to omit them. > This "puts pressure" on considering "this problem" more/again? > ? NetBSD < 5.0, FreeBSD < 8.0 ... enough to do something about? > ? I've been looking into autoconf and libtool some, but i haven't yet, like.. > ? what I'd like to see very clearly is them do the "relink before > install" behavior. > ? Once confirmed to be there.. maybe our "binary" packages are a > bunch of .o files? > ? Interesting compromise? > ? Or, really, maybe we somewhat give up on "relocatability" and > hardcode /usr/local/cm3? > ? ?? I realize, official Debian packages need to be at /usr. > ? Anyone building from source, can put the files anywhere. > ? We can also only "give up" on FreeBSD and/or NetBSD -- where > $ORIGIN is more recent introduction. We should keep that for the time being. > I also seem to recall OSF/1 supports arbitrary environment > variables, but doesn't define anything for you like $ORIGIN. > Some system is that way. > For that can invent custom names and wrapper scripts perhaps. > > I know, a likely question, it has been asked for, "what is common?" > i.e. portable, works the same "everywhere"? > ? That would be hardcoded paths, no relocatability. > $ORIGIN is very common, but less so. > > I'm the one who opened this can of worms here. > ?The previous -rpath was a mess with lots of directories. That could > at least be changed to something short. > ? $ORIGIN is indeed very promising and fairly portable, but not > perfectly portable nor perfectly "behaved". > ? I don't think any solution is perfectly "behaved", there are > contradictory goals. /usr/local/cm3 was the original one standard location when we first published the sources from Critical Mass. But lots of people complained and wanted more flexibility, or rather their platform-specific different standard setups. We haven't got the ressources to fulfill all wishes currently. I'd vote to keep the status quo until someone either has a great idea or implements something better, or we'll keep changing solutions back and forth. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Jul 16 15:47:46 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 16 Jul 2010 13:47:46 +0000 Subject: [M3devel] $ORIGIN? In-Reply-To: <20100716151002.ygdg5pakxwc0kwwc@mail.elegosoft.com> References: , <20100716151002.ygdg5pakxwc0kwwc@mail.elegosoft.com> Message-ID: > We should document that as a workaround. It sort of is, but it is a bit vague. We can fill in specifics: FreeBSD < 8.0 NetBSD < 5.0 (but we don't have NetBSD distributions so..) no problem on Linux, Solaris, MacOSX, NT. Basically, I have to say..I think we might have zero NetBSD users so I thought we were well covered. I didn't realize FreeBSD was late here. That was surprising. > But lots of people complained > and wanted more flexibility, or rather their platform-specific different > standard setups. This is a critical distinction of course. Using /opt/cm3 on Solaris. ? /usr/pkg on NetBSD. ? etc. is trivial. I'm guessing $HOME and $HOME/cm3 are common though too. ?? I keep getting non-root access to machines and using that. :) As well, for a long time, the answer was LD_LIBRARY_PATH, which despite going by a few different names, does seem common. But I'm not sure I prefer it. Obviously you can read all the distaste for it on the web. I'm *guessing* that non-NT users are mostly Linux users, and I'm *guessing* that $ORIGIN has been there a while. Solaris has also had it a while. FreeBSD as I said, not. NetBSD since 5.0 (current). OpenBSD I don't know. Building "static" -- "partly static" also evades this. Except for OpenBSD, "static" is only relative to Modula-3 libraries. But it is overkill, wasteful, bigger, slower. And lots of people don't build the system themselves, right? > We haven't got the resources to fulfill all wishes currently. Hehe. I want world peace and a few million dollars. :) > I'd vote to keep the status quo until someone either has a great idea > or implements something better, or we'll keep changing solutions back > and forth. Ok. I think all the ideas are known here. :) Ultimately I like the idea of generating C, and then using autoconf and libtool to fill in some cracks. But the C backend is a big missing in action piece. I'm largely talk, less action. Time passing helps, people will converge more on systems having $ORIGIN support. ? - Jay ---------------------------------------- > Date: Fri, 16 Jul 2010 15:10:02 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] $ORIGIN? > > Quoting Jay K : > > > So I can build a distribution FreeBSD 4.11... > > > > But it looks like FreeBSD didn't support $ORIGIN until very recently: 8.0. > > > > This is evidenced from two places: > > > > http://www.freebsd.org/releases/8.0R/relnotes-detailed.html > > indicates it is new > > > > and http://www.freebsd.org/cgi/man.cgi lets you specify version. > > The ld-elf.so manpage doesn't mention it until 8.0. > > That's correct. > > Alas, there's no common standard shared by all the systems we support. > > > This means, something like: > > FreeBSD users using < 8.0 will need/want to set LD_LIBRARY_PATH. > > We should document that as a workaround. > > > I don't think the distributed binaries have any hardcoded paths in > > them, except for the $ORIGIN stuff, > > which I think will just be ignored. "Normally" they do, but the > > distribution build specifically > > tries to omit them. > > > This "puts pressure" on considering "this problem" more/again? > > NetBSD < 5.0, FreeBSD < 8.0 ... enough to do something about? > > I've been looking into autoconf and libtool some, but i haven't yet, like.. > > what I'd like to see very clearly is them do the "relink before > > install" behavior. > > Once confirmed to be there.. maybe our "binary" packages are a > > bunch of .o files? > > Interesting compromise? > > Or, really, maybe we somewhat give up on "relocatability" and > > hardcode /usr/local/cm3? > > I realize, official Debian packages need to be at /usr. > > Anyone building from source, can put the files anywhere. > > We can also only "give up" on FreeBSD and/or NetBSD -- where > > $ORIGIN is more recent introduction. > > We should keep that for the time being. > > > I also seem to recall OSF/1 supports arbitrary environment > > variables, but doesn't define anything for you like $ORIGIN. > > Some system is that way. > > For that can invent custom names and wrapper scripts perhaps. > > > > I know, a likely question, it has been asked for, "what is common?" > > i.e. portable, works the same "everywhere"? > > That would be hardcoded paths, no relocatability. > > $ORIGIN is very common, but less so. > > > > I'm the one who opened this can of worms here. > > The previous -rpath was a mess with lots of directories. That could > > at least be changed to something short. > > $ORIGIN is indeed very promising and fairly portable, but not > > perfectly portable nor perfectly "behaved". > > I don't think any solution is perfectly "behaved", there are > > contradictory goals. > > /usr/local/cm3 was the original one standard location when we first > published the sources from Critical Mass. But lots of people complained > and wanted more flexibility, or rather their platform-specific different > standard setups. > > We haven't got the ressources to fulfill all wishes currently. > > I'd vote to keep the status quo until someone either has a great idea > or implements something better, or we'll keep changing solutions back > and forth. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Fri Jul 16 16:16:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 16 Jul 2010 14:16:36 +0000 Subject: [M3devel] FreeBSD 4 Message-ID: Mika already got this working himself, but anyway: http://modula3.elegosoft.com/cm3/uploaded-archives/ => http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-I386_FREEBSD-d5.8.2-FreeBSD4.11-20100715.tar.gz http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-all-I386_FREEBSD-d5.8.2-FreeBSD4.11-20100715.tar.gz They have "no runpath". You must set LD_LIBRARY_PATH. They use userthreads. But FreeBSD4 does have pthreads. Maybe they are adequate. I wasn't able to test gui apps. (Mika did.) System builds itself, so it largely works. ?- Jay From mika at async.async.caltech.edu Fri Jul 16 16:42:43 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Fri, 16 Jul 2010 07:42:43 -0700 Subject: [M3devel] $ORIGIN? In-Reply-To: References: Message-ID: <20100716144243.E10F81A20A7@async.async.caltech.edu> Jay K writes: > >So I can build a distribution FreeBSD 4.11... > > >But it looks like FreeBSD didn't support $ORIGIN until very recently: 8.0. > > >This is evidenced from two places: > > >http://www.freebsd.org/releases/8.0R/relnotes-detailed.html >=A0 indicates it is new > > >and http://www.freebsd.org/cgi/man.cgi lets you specify version. >The ld-elf.so manpage doesn't mention it until 8.0. > > >This means=2C something like: >=A0 FreeBSD users using < 8.0 will need/want to set LD_LIBRARY_PATH. >=A0 I don't think the distributed binaries have any hardcoded paths in them= >=2C except for the $ORIGIN stuff=2C >=A0=A0 which I think will just be ignored. "Normally" they do=2C but the di= >stribution build specifically >=A0=A0 tries to omit them. I have been using Modula-3 on FreeBSD since 2.x and have never needed to set LD_LIBRARY_PATH. And I (almost) always compile outside the /usr/local/... (m3build -O or cm3 -x) Mika From jay.krell at cornell.edu Fri Jul 16 21:19:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 16 Jul 2010 19:19:32 +0000 Subject: [M3devel] $ORIGIN? In-Reply-To: <20100716144243.E10F81A20A7@async.async.caltech.edu> References: , <20100716144243.E10F81A20A7@async.async.caltech.edu> Message-ID: > I have been using Modula-3 on FreeBSD since 2.x and have never needed > to set LD_LIBRARY_PATH. > > And I (almost) always compile outside the /usr/local/... (m3build -O or cm3 -x) If you build it yourself, sure. If I build it for someone else to use and I don't know where they are going to install it, that's when it is needed. ?- Jay ---------------------------------------- > To: jay.krell > CC: m3devel > Subject: Re: [M3devel] $ORIGIN? > Date: Fri, 16 Jul 2010 07:42:43 -0700 > From: mika > ... From jay.krell at cornell.edu Sun Jul 18 03:30:09 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 18 Jul 2010 01:30:09 +0000 Subject: [M3devel] compiler behavior under "low memory"? Message-ID: Mark had a machine with low memory. It has more swap now. Our behavior was: Compiling m3tk would make good progress, complete many files, then fail for ?lack of memory. Manual retry would start over due to ?"missing version information" or such. Thus progress was "impossible". By editing down m3makefile I was able to make progress. ?Some stuff would fail due to missing interfaces, but ?whatever I left in would get the version information saved. ? ? Perhaps we should write out the version information every "few" files? ?For some definition of "few"? 10? 10% of the total? ? ? That would at least let such situations progress via manual retry. ? (unless not even a "few" fit in memory) I also wonder about reducing memory used, or why indeed we run out, ?but that is a thornier problem. You know, all we should need to ?continue forward progress is to hold all interfaces in memory and ?one implementation at a time. Now, there are a few unknowns here. ?It is possible Mark's machine didn't have enough memory for ?all the relevant interfaces, and that we only "load" them on-demand. ? ?It is also likely, I should add, that virtual address space is the ? problem, not working set. Some systems want to commit room ? in swap for all allocated virtual memory, like, to be sure ? ahead of time that everything can be paged out so other ? code can progress. Something like that. I'm not sure here. ? That is, I suspect we don't care. Virtual address space is probably ? reasonable to deem cheap. No problem using almost 2GB of address space ? as long as working set isn't that large (ie: to fit in 31bit address space). ? If some OSes don't see it that way, oh well. This might just ? be a design/policy thing in Tru64. ? ? (I'm well aware of virtual memory vs. physical memory vs. working set. But for whatever reason, we were failing due to memory use. All that *should* matter is that address space usage stays within around 2GB and that working set isn't huge. Working set I've recently come to understand can be managed like so: ? - random access over set of memory that fits in physical memory ? - sequential access over arbitrary memory (up to 2GB) ? - hybrid of previous ????? ie. sequential accesses over multiple separate areas As long as access is sequential, you shouldn't "thrash". It is only random access over data that doesn't fit in physical memory ?that causes thrashing.) ?- Jay From jay.krell at cornell.edu Sun Jul 18 03:34:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 18 Jul 2010 01:34:14 +0000 Subject: [M3devel] multithreaded compiler? Message-ID: It should be reasonably easy to have the gcc backend run on multiple separate threads. ?- Jay From dabenavidesd at yahoo.es Sun Jul 18 05:28:54 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 18 Jul 2010 03:28:54 +0000 (GMT) Subject: [M3devel] compiler behavior under "low memory"? In-Reply-To: Message-ID: <583206.38293.qm@web23608.mail.ird.yahoo.com> Hi: If it only had such small memory requirements I suppose less than 64 MB RAM I didn't get the number of interfaces is about the same (probably a 10 % larger by now with new added packages), probably the best way forward is not just to change the swap memory as its a common sense to double the RAM but in that case you would need such a thing for one process less the rest of operating system, i.e solution is not general, If I understand well Mark 's Alpha DEC machine had the same machine and probably with M3 running in top of it in 1995. I wonder how these years have expanded the compilers proficiency (as time is against space and vice-versa, that is, less time is more memory like to make a recursive program to unfold in a sequential one) in such a memory constrained environments could be solved I can remember now that there was a change in Amer Diwan Whole program optimizer to grab in a pickled AST to later unpickle it and compile to M3CG-machine assembly optimized see: http://www.modula3.org/threads/1/#advanced and also a proposed or to-do of DEC-SRC M3 days about Cache policy it mentioned see: http://www.cs.arizona.edu/~collberg/Research/Modula-3/modula-3/html/todo.html AST cache policy. The current driver keeps an in-memory cache of compiled interfaces, but never flushes entries, this refers to the simple problem of big heap which another application generated out of memory back in those days the ESC/Modula-3 checker available for Alphas see: http://web.archive.org/web/20030704143617/http://research.compaq.com/SRC/esc/escm3/bin/Esc.alpha.bin.Z (which was user of Simplify theorem prover http://portal.acm.org/citation.cfm?id=1066100.1066102 or doi:0.1145/1066100.1066102 as it should be cited and also used m3tk toolkit ) and they managed to solve by means of calling the collector to scan and throw away the uncollected things at least in Simplify, years later I retired the line with no problem in Simplify and all run in good benchmarks tests of Simplify with no problems see too http://qpq.csl.sri.com/downloads/simplify_benchmarks-tar.gz/view The result was that they created a tool to understand where the memory heap was being actually ran out of memory and they manage to solve I believe by managing the same way besides clearing stuff not needed something is useful in any garbage collected type language http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.49.3474&rep=rep1&type=pdf see slides onhttp://labs.oracle.com/people/detlefs/papers/detlefs-coots95-slides.ps and extra figures http://labs.oracle.com/people/detlefs/papers/detlefs-coots95-slides2.ps In our case in that case as it can't throw away AST representations before M3CG-machine tough there is separate compilation we don't manage to type check all m3tk in runtime eliminating when is compiled and not used code generation currently the problem might be solved in the compilation server written for pm3 (see: http://arxiv.org/pdf/cs/0506035 ) or as Amer Diwan solved to manage for his particular purposes (see ftp://ftp.cs.umass.edu/pub/osl/papers/diwan-dissertation.ps.gz) because in any case of low resources limits it would be stored pickled or in swaped memory in the disc but in non-low memory limits it would be in both memory and disk as it is now (at some point you need to bring from copy from disk the needed bytes back to memory). Besides that the implemented behavior on VM exhaustion should be not taken in false as guys didn't in those days http://modula3.elegosoft.com/pm3/intro/questions/new.html An implemented solution but actually not used not seen here: http://web.archive.org/web/19980613063641/www.vlsi.polymtl.ca/m3/pkg/contrib/whenNEWfails/.ghindex.html Thanks for any corrections in advance if so --- El s?b, 17/7/10, Jay K escribi?: > De: Jay K > Asunto: [M3devel] compiler behavior under "low memory"? > Para: "m3devel" > Fecha: s?bado, 17 de julio, 2010 20:30 > > Mark had a machine with low memory. > It has more swap now. > > > Our behavior was: > > > Compiling m3tk would make good progress, complete many > files, then fail for > lack of memory. > > > Manual retry would start over due to > "missing version information" or such. > > > Thus progress was "impossible". > By editing down m3makefile I was able to make progress. > Some stuff would fail due to missing interfaces, but > whatever I left in would get the version information > saved. > > > Perhaps we should write out the version information every > "few" files? > For some definition of "few"? 10? 10% of the total? > > > That would at least let such situations progress via manual > retry. > (unless not even a "few" fit in memory) > > > I also wonder about reducing memory used, or why indeed we > run out, > but that is a thornier problem. You know, all we should > need to > continue forward progress is to hold all interfaces in > memory and > one implementation at a time. Now, there are a few > unknowns here. > It is possible Mark's machine didn't have enough memory > for > all the relevant interfaces, and that we only "load" them > on-demand. > > > It is also likely, I should add, that virtual address > space is the > problem, not working set. Some systems want to commit > room > in swap for all allocated virtual memory, like, to be > sure > ahead of time that everything can be paged out so other > code can progress. Something like that. I'm not sure > here. > That is, I suspect we don't care. Virtual address space > is probably > reasonable to deem cheap. No problem using almost 2GB of > address space > as long as working set isn't that large (ie: to fit in > 31bit address space). > If some OSes don't see it that way, oh well. This might > just > be a design/policy thing in Tru64. > > > (I'm well aware of virtual memory vs. physical memory vs. > working set. > But for whatever reason, we were failing due to memory > use. > All that *should* matter is that address space usage stays > within > around 2GB and that working set isn't huge. Working set > I've recently > come to understand can be managed like so: > - random access over set of memory that fits in physical > memory > - sequential access over arbitrary memory (up to 2GB) > - hybrid of previous > ie. sequential accesses over multiple separate > areas > > As long as access is sequential, you shouldn't "thrash". > It is only random access over data that doesn't fit in > physical memory > that causes thrashing.) > > > - Jay > > > > From jay.krell at cornell.edu Sun Jul 18 06:02:46 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 18 Jul 2010 04:02:46 +0000 Subject: [M3devel] compiler behavior under "low memory"? In-Reply-To: <583206.38293.qm@web23608.mail.ird.yahoo.com> References: , <583206.38293.qm@web23608.mail.ird.yahoo.com> Message-ID: Daniel I have a hard time understanding you. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.49.3474&rep=rep1&type=pdf Is interesting though. We should make sure that stuff still works, and fix it if not. i.e. the heap debugging tools embedded in the runtime (shownew, etc.) ?- Jay ---------------------------------------- > Date: Sun, 18 Jul 2010 03:28:54 +0000 > From: dabenavidesd at yahoo.es > To: m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] compiler behavior under "low memory"? > > Hi: > If it only had such small memory requirements I suppose less than 64 MB RAM I didn't get the number of interfaces is about the same (probably a 10 % larger by now with new added packages), probably the best way forward is not just to change the swap memory as its a common sense to double the RAM but in that case you would need such a thing for one process less the rest of operating system, i.e solution is not general, If I understand well Mark 's Alpha DEC machine had the same machine and probably with M3 running in top of it in 1995. I wonder how these years have expanded the compilers proficiency (as time is against space and vice-versa, that is, less time is more memory like to make a recursive program to unfold in a sequential one) in such a memory constrained environments could be solved I can remember now that there was a change in Amer Diwan Whole program optimizer to grab in a pickled AST to later unpickle it and compile to M3CG-machine assembly > optimized see: > http://www.modula3.org/threads/1/#advanced > and also a proposed or to-do of DEC-SRC M3 days about Cache policy it mentioned see: > http://www.cs.arizona.edu/~collberg/Research/Modula-3/modula-3/html/todo.html > AST cache policy. The current driver keeps an in-memory cache of compiled interfaces, but never flushes entries, this refers to the simple problem of big heap which another application generated out of memory back in those days the ESC/Modula-3 checker available for Alphas see: > http://web.archive.org/web/20030704143617/http://research.compaq.com/SRC/esc/escm3/bin/Esc.alpha.bin.Z (which was user of Simplify theorem prover http://portal.acm.org/citation.cfm?id=1066100.1066102 > or doi:0.1145/1066100.1066102 as it should be cited and also used m3tk toolkit ) and they managed to solve by means of calling the collector to scan and throw away the uncollected things at least in Simplify, years later I retired the line with no problem in Simplify and all run in good benchmarks tests of Simplify with no problems see too http://qpq.csl.sri.com/downloads/simplify_benchmarks-tar.gz/view > The result was that they created a tool to understand where the memory heap was being actually ran out of memory and they manage to solve I believe by managing the same way besides clearing stuff not needed something is useful in any garbage collected type language http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.49.3474&rep=rep1&type=pdf > see slides onhttp://labs.oracle.com/people/detlefs/papers/detlefs-coots95-slides.ps and extra figures http://labs.oracle.com/people/detlefs/papers/detlefs-coots95-slides2.ps > In our case in that case as it can't throw away AST representations before M3CG-machine tough there is separate compilation we don't manage to type check all m3tk in runtime eliminating when is compiled and not used code generation currently the problem might be solved in the compilation server written for pm3 (see: > http://arxiv.org/pdf/cs/0506035 ) > or as Amer Diwan solved to manage for his particular purposes (see ftp://ftp.cs.umass.edu/pub/osl/papers/diwan-dissertation.ps.gz) because in any case of low resources limits it would be stored pickled or in swaped memory in the disc but in non-low memory limits it would be in both memory and disk as it is now (at some point you need to bring from copy from disk the needed bytes back to memory). > Besides that the implemented behavior on VM exhaustion should be not taken in false as guys didn't in those days > http://modula3.elegosoft.com/pm3/intro/questions/new.html > An implemented solution but actually not used not seen here: > > http://web.archive.org/web/19980613063641/www.vlsi.polymtl.ca/m3/pkg/contrib/whenNEWfails/.ghindex.html > > Thanks for any corrections in advance if so > > > > > > --- El s?b, 17/7/10, Jay K escribi?: > > > De: Jay K > > Asunto: [M3devel] compiler behavior under "low memory"? > > Para: "m3devel" > > Fecha: s?bado, 17 de julio, 2010 20:30 > > > > Mark had a machine with low memory. > > It has more swap now. > > > > > > Our behavior was: > > > > > > Compiling m3tk would make good progress, complete many > > files, then fail for > > lack of memory. > > > > > > Manual retry would start over due to > > "missing version information" or such. > > > > > > Thus progress was "impossible". > > By editing down m3makefile I was able to make progress. > > Some stuff would fail due to missing interfaces, but > > whatever I left in would get the version information > > saved. > > > > > > Perhaps we should write out the version information every > > "few" files? > > For some definition of "few"? 10? 10% of the total? > > > > > > That would at least let such situations progress via manual > > retry. > > (unless not even a "few" fit in memory) > > > > > > I also wonder about reducing memory used, or why indeed we > > run out, > > but that is a thornier problem. You know, all we should > > need to > > continue forward progress is to hold all interfaces in > > memory and > > one implementation at a time. Now, there are a few > > unknowns here. > > It is possible Mark's machine didn't have enough memory > > for > > all the relevant interfaces, and that we only "load" them > > on-demand. > > > > > > It is also likely, I should add, that virtual address > > space is the > > problem, not working set. Some systems want to commit > > room > > in swap for all allocated virtual memory, like, to be > > sure > > ahead of time that everything can be paged out so other > > code can progress. Something like that. I'm not sure > > here. > > That is, I suspect we don't care. Virtual address space > > is probably > > reasonable to deem cheap. No problem using almost 2GB of > > address space > > as long as working set isn't that large (ie: to fit in > > 31bit address space). > > If some OSes don't see it that way, oh well. This might > > just > > be a design/policy thing in Tru64. > > > > > > (I'm well aware of virtual memory vs. physical memory vs. > > working set. > > But for whatever reason, we were failing due to memory > > use. > > All that *should* matter is that address space usage stays > > within > > around 2GB and that working set isn't huge. Working set > > I've recently > > come to understand can be managed like so: > > - random access over set of memory that fits in physical > > memory > > - sequential access over arbitrary memory (up to 2GB) > > - hybrid of previous > > ie. sequential accesses over multiple separate > > areas > > > > As long as access is sequential, you shouldn't "thrash". > > It is only random access over data that doesn't fit in > > physical memory > > that causes thrashing.) > > > > > > - Jay > > > > > > > > > > > > From jay.krell at cornell.edu Sun Jul 18 08:36:45 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 18 Jul 2010 06:36:45 +0000 Subject: [M3devel] Modula-3 condition variables vs. pthread/Win32 condition variables? Message-ID: I was thinking of writing "ThreadWin6.m3". We'd check GetVersion and if it is >= 6.0, use it instead. This would give us: ? smaller locks ? condition variables ? likely isomorphic code with ThreadPThread.m3 Question, probably a repeat: (I'll check the archives) ? Why aren't Modula-3 condition variables a thinner wrapper over pthread condition variables? One difference I see is alert. Can't alert just signal the condition being waited on? Might need interlocked operations against alertable and alerted, and maybe also thread.cond? ? (Should be viable, even within one word, use the lower two bits of thread.cond?) ? ?- Jay From jay.krell at cornell.edu Sun Jul 18 14:00:05 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 18 Jul 2010 12:00:05 +0000 Subject: [M3devel] moving to new target names, in Hudson? Message-ID: Olaf, can I request that if/when you move Hudson to head, that you also switch to I386_LINUX, I386_FREEBSD, I386_NT, and whatever we decide for SPARC32_SOLARIS? I've mostly switched to them myself. It wasn't difficult. (I always say that). I think for SPARC32_SOLARIS we should either have SPARC32_SOLARIS that is the equivalent of today's SOLsun. Effectively dropping SOLgnu. Or we also add SPARC32_SOLARIS_gcc, which is just a configuration file and not a target. This is like the "experiment" I did with NT386/NT386GNU, which I think I regret, except SPARC32_SOLARIS / SPARC32_SOLAROS_gcc are far far more similar than those. All their platform-specific code is identical. Their backend is identical. etc. A related option is SPARC32_SOLARIS_cc or SPARC32_SOLARIS_suncc, and SPARC32_SOLARIS_gcc. Config files. But the compiler only know about SPARC32_SOLARIS. Just putting the two config files more as peers, so to speak. The way I switched targets was probably doing a cross build. That is overkill. You can probably just export CM3_TARGET to the name you want. And maybe fiddle with shipping of cm3cg or settings its build_dir -- i.e. leave it as just host and host-target. Thanks, ?- Jay From jay.krell at cornell.edu Sun Jul 18 14:44:25 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 18 Jul 2010 12:44:25 +0000 Subject: [M3devel] div/mod Message-ID: ok, this is a really minor thing. Very esoteric, waste of time probably. Div and mod are defined in terms of each other. In the "real world", any integer mod negative 1 is 0. ? All integers are "evenly divisible" by 1 and negative 1. So INT_MIN mod -1 is 0. One can code that to be the case. Some versions of the code do. ? I'm not sure about the current code, as we don't call the C functions any longer, except for int64 on NT386. ? The older div/mod helpers, depending on optimization, would either return 0 ?? or generate an overflow exception. In our computer world, INT_MIN div -1 is not computable, and generates ? the same exception. Even with current code. If div and mod are defined in terms of each other, and one of them is not computable, ? is it wrong to be able to compute the other? ?- Jay From jay.krell at cornell.edu Sun Jul 18 15:35:51 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 18 Jul 2010 13:35:51 +0000 Subject: [M3devel] Alpha/OSF exception handling Message-ID: Modula-3 for ALPHA_OSF historically had the best exception handling implementation. With Solaris/sparc32 second best. And then everything else equally bad. The current Alpha/osf is now in the "equally bad" category. Because I'm lazy. It might be worth restoring its former glory. Maybe a small project for someone? The code is still in there. I just tweaked the m3makefiles to avoid trying it. jbook2:runtime jay$ pwd /dev2/cm3/m3-libs/m3core/src/runtime jbook2:runtime jay$ find ALPHA_OSF ALPHA_OSF/m3makefile-old Renaming that m3makefile. Fiddling with this: book2:runtime jay$ grep STACK * m3makefile:readonly HAS_STACK_WALKER = { m3makefile:if defined("M3_USE_STACK_WALKER") m3makefile:? if M3_USE_STACK_WALKER and HAS_STACK_WALKER contains TARGET m3makefile:??? if HAS_STACK_WALKER{TARGET} and this: jbook2:src jay$ pwd /dev2/cm3/m3-sys/m3middle/src book2:src jay$ grep -i _stack *m3 Target.m3:??? Has_stack_walker????????? := FALSE; Target.m3:???????????????? Has_stack_walker := TRUE; ?- Jay From wagner at elegosoft.com Sun Jul 18 16:55:13 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 18 Jul 2010 16:55:13 +0200 Subject: [M3devel] Hudson regression for current cm3 / incompatibilities Message-ID: <20100718165513.gug2fuk04k8cww0o@mail.elegosoft.com> I've disabled the existing cm3 build and test jobs on Hudson and copied them to new ones all named cm3-current-*; I've also added a new view cm3-current that is now displayed by default. The now disabled jobs may be used again for the next release. However, already some incompatibilities seen to habe crept in. Neither the m3cc nor the build jobs succeed; i.e. the current sources cannot be built with the latest release version, even with the upgrade script. This should be fixed. Please have a look at http://hudson.modula3.com:8080/ When everything looks good again, I'll start to rename some of the jobs to new platform names as Jay requested (if we can all agree on them). However, this will take some more time and a better connection than that I currently have here from my mobile notebook. And now for something completely different again (it's weekend after all), Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Jul 18 17:04:26 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 18 Jul 2010 17:04:26 +0200 Subject: [M3devel] moving to new target names, in Hudson? In-Reply-To: References: Message-ID: <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com> Quoting Jay K : > Olaf, can I request that if/when you move Hudson to head, that you > also switch to I386_LINUX, I386_FREEBSD, I386_NT, > and whatever we decide for SPARC32_SOLARIS? > I've mostly switched to them myself. It wasn't difficult. (I always > say that). It will require a lot of manual work, compared to the more or less automated transition I just made from release to current for all the jobs. The target platform names are part of the jobs, and are also used in various places in the build scripts, so that many things are likely to break. My guess is that it will take some days for every target move given my current attention pattern for cm3, i.e. have a look at how things work out now and then between other work. Let's wait until all the jobs work again with their old target names, Olaf > I think for SPARC32_SOLARIS we should either have SPARC32_SOLARIS > that is the equivalent of today's SOLsun. > Effectively dropping SOLgnu. > > > Or we also add SPARC32_SOLARIS_gcc, which is just a configuration > file and not a target. > This is like the "experiment" I did with NT386/NT386GNU, which I > think I regret, except > SPARC32_SOLARIS / SPARC32_SOLAROS_gcc are far far more similar than those. > All their platform-specific code is identical. Their backend is > identical. etc. > > > A related option is SPARC32_SOLARIS_cc or SPARC32_SOLARIS_suncc, and > SPARC32_SOLARIS_gcc. > Config files. > But the compiler only know about SPARC32_SOLARIS. > Just putting the two config files more as peers, so to speak. > > > The way I switched targets was probably doing a cross build. > That is overkill. You can probably just export CM3_TARGET to the > name you want. > And maybe fiddle with shipping of cm3cg or settings its build_dir -- > i.e. leave it as just host and host-target. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sun Jul 18 18:16:15 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 18 Jul 2010 16:16:15 +0000 Subject: [M3devel] Hudson regression for current cm3 / incompatibilities In-Reply-To: <20100718165513.gug2fuk04k8cww0o@mail.elegosoft.com> References: <20100718165513.gug2fuk04k8cww0o@mail.elegosoft.com> Message-ID: This is great Olaf, having this already going, no matter the target names. I'll watch it. Thanks, ?- Jay ---------------------------------------- > Date: Sun, 18 Jul 2010 16:55:13 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] Hudson regression for current cm3 / incompatibilities > > I've disabled the existing cm3 build and test jobs on Hudson and copied > them to new ones all named cm3-current-*; I've also added a new view > cm3-current that is now displayed by default. > The now disabled jobs may be used again for the next release. > > However, already some incompatibilities seen to habe crept in. > Neither the m3cc nor the build jobs succeed; i.e. the current sources > cannot be built with the latest release version, even with the > upgrade script. > > This should be fixed. > > Please have a look at > > http://hudson.modula3.com:8080/ > > When everything looks good again, I'll start to rename some of the > jobs to new platform names as Jay requested (if we can all agree on them). > However, this will take some more time and a better connection than that > I currently have here from my mobile notebook. > > And now for something completely different again (it's weekend after all), > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Sun Jul 18 18:25:35 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 18 Jul 2010 16:25:35 +0000 Subject: [M3devel] CM3 on Alpha tru64 4.0G In-Reply-To: References: , , ,,, ,,,,, , <9241B253-8004-4DDD-B1EF-A7D02A3FEAFD@cs.purdue.edu>, ,,, ,,<76827F66-451E-410E-9AF0-200D9538AFA1@cs.purdue.edu>, ,,<1279048755.1793.13.camel@x60.appsoftint.co.uk>, ,,<8E02058D-1A62-48FF-8DA7-B2C40C53B048@cs.purdue.edu>, , , <1279053628.1793.15.camel@x60.appsoftint.co.uk>, , , Message-ID: http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-all-ALPHA_OSF-d5.8.2-OSF1V4.0-20100718.tar.gz http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-ALPHA_OSF-d5.8.2-OSF1V4.0-20100718.tar.gz System built itself natively on Mark's machine. Using pthreads. But no stack walker (I'm lazy and didn't even try it). Mark reports some GUI apps working. Would be cool to get this in Hudson but I think the current machines have too old Java. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: mark at wickensonline.co.uk; hosking at cs.purdue.edu > Date: Tue, 13 Jul 2010 23:27:51 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] CM3 on Alpha tru64 4.0G > > > > Things to try: cross build, user threads. > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-ALPHA_OSF-pthreads-d5.8.2-20100713.tgz > or > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-ALPHA_OSF-userthreads-d5.8.2-20100713.tgz > > ? > > And in userthreads, if there is no get/set/make/swapcontext, you can change the #if at the top of ThreadPosixC.c to try sigaltstack. > Also the userthreads Makefile has -lpthread in it, which you'll maybe want to remove...depending on if there is pthread_atfork, i.e. you might want to tweak this: > jbook2:cm3-boot-ALPHA_OSF-d5.8.2-20100713 jay$ grep pthread_atfork *c > RTProcessC.c: int i = pthread_atfork(prepare, parent, child); > > > but try the pthread version first? > > These will give you a cm3 and if it prints "unable to find cm3.cfg", good. > > Tru64 4.x isn't officially supported by gcc any longer, but I noticed recent test results posted anyway. > You just have to configure -enable-obsolete or somesuch. > > Can you give me ssh access? That's a good and bad thing. Should be doable without such direct help by me.. > > - Jay > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: mark at wickensonline.co.uk; hosking at cs.purdue.edu > > Date: Tue, 13 Jul 2010 23:04:20 +0000 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] CM3 on Alpha tru64 4.0G > > > > > > Things to try: cross build, user threads. > > Do you have a "modern" system with a working cm3? > > Do you have cvs and a working C compiler/linker on this older system? > > > > - Jay > > > > ---------------------------------------- > > > From: mark at wickensonline.co.uk > > > To: hosking at cs.purdue.edu > > > Date: Tue, 13 Jul 2010 21:40:28 +0100 > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] CM3 on Alpha tru64 4.0G > > > > > > Hi Tony, the exception I get is as follows: > > > > > > >From cm3-min-ALPHA_OSF-d5.8.2-20100612/bin > > > > > > bash-3.2$ ./cm3 > > > %DECthreads bugcheck (version V3.18-037), terminating execution. > > > % Reason: stkGet: (4) nxm_stack_create (0,5251072,16384,8192) > > > % Running on OSF1 V4.0(1530) on AlphaServer 300 4/266, 256Mb; 1 CPUs, > > > pid 21360 > > > > > > > > > From hosking at cs.purdue.edu Sun Jul 18 20:21:32 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 18 Jul 2010 14:21:32 -0400 Subject: [M3devel] Modula-3 condition variables vs. pthread/Win32 condition variables? In-Reply-To: References: Message-ID: <1908F6C1-08D0-46FE-89DE-D0B5BDEBDC59@cs.purdue.edu> On 18 Jul 2010, at 02:36, Jay K wrote: > > I was thinking of writing "ThreadWin6.m3". > We'd check GetVersion and if it is >= 6.0, use it instead. > This would give us: > smaller locks > condition variables > likely isomorphic code with ThreadPThread.m3 > > > Question, probably a repeat: (I'll check the archives) > Why aren't Modula-3 condition variables a thinner wrapper over pthread condition variables? Because there is no reliable way to alert a thread waiting on a condition variable. And we need a uniform way to handshake with a thread for GC, etc. Better just to build on the per-thread CV. > One difference I see is alert. Can't alert just signal the condition being waited on? > > > Might need interlocked operations against alertable and alerted, and maybe also thread.cond? > (Should be viable, even within one word, use the lower two bits of thread.cond?) Again, probably not a good idea going forward -- we will ultimately build M3 mutex/CV with non-blocking primitives where possible and inflate to pthread mutex only rarely. > > ? > > > - Jay > > > > > From hosking at cs.purdue.edu Sun Jul 18 20:22:41 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 18 Jul 2010 14:22:41 -0400 Subject: [M3devel] Alpha/OSF exception handling In-Reply-To: References: Message-ID: That is a huge shame. Why did you remove it? It used to be there and functional. On 18 Jul 2010, at 09:35, Jay K wrote: > > Modula-3 for ALPHA_OSF historically had the best exception handling implementation. > > With Solaris/sparc32 second best. > > And then everything else equally bad. > > > > > > The current Alpha/osf is now in the "equally bad" category. > Because I'm lazy. > > It might be worth restoring its former glory. > > > > Maybe a small project for someone? > > > The code is still in there. I just tweaked the m3makefiles to avoid trying it. > > > jbook2:runtime jay$ pwd > /dev2/cm3/m3-libs/m3core/src/runtime > jbook2:runtime jay$ find ALPHA_OSF > ALPHA_OSF/m3makefile-old > > Renaming that m3makefile. > > Fiddling with this: > > book2:runtime jay$ grep STACK * > m3makefile:readonly HAS_STACK_WALKER = { > m3makefile:if defined("M3_USE_STACK_WALKER") > m3makefile: if M3_USE_STACK_WALKER and HAS_STACK_WALKER contains TARGET > m3makefile: if HAS_STACK_WALKER{TARGET} > > > and this: > > > jbook2:src jay$ pwd > /dev2/cm3/m3-sys/m3middle/src > > > book2:src jay$ grep -i _stack *m3 > Target.m3: Has_stack_walker := FALSE; > Target.m3: Has_stack_walker := TRUE; > > > - Jay > From rodney_bates at lcwb.coop Mon Jul 19 00:41:43 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 18 Jul 2010 17:41:43 -0500 Subject: [M3devel] div/mod In-Reply-To: References: Message-ID: <4C438327.1070907@lcwb.coop> Jay K wrote: > ok, this is a really minor thing. Very esoteric, waste of time probably. > > > Div and mod are defined in terms of each other. > > > In the "real world", any integer mod negative 1 is 0. > All integers are "evenly divisible" by 1 and negative 1. > > So INT_MIN mod -1 is 0. > > > One can code that to be the case. Some versions of the code do. > I'm not sure about the current code, as we don't call the C functions any longer, except for int64 on NT386. > The older div/mod helpers, depending on optimization, would either return 0 > or generate an overflow exception. > > > In our computer world, INT_MIN div -1 is not computable, and generates > the same exception. Even with current code. My view of this is that the only reason INT_MIN DIV -1 raises an exception is that the mathematical result is not in INTEGER. The definitions of all the arithmetic operators in the language should be viewed as using the (unlimited range) operations of mathematics, with overflow happening if this lies outside the range of the result type. In fact, I doubt you can sensibly interpret the definitions in the language any other way. So it makes perfect sense for the DIV to raise the exception and the MOD not, since 0 is indeed in INTEGER. > > > If div and mod are defined in terms of each other, and one of them is not computable, > is it wrong to be able to compute the other? > > > - Jay > > From jay.krell at cornell.edu Mon Jul 19 02:16:46 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Jul 2010 00:16:46 +0000 Subject: [M3devel] Hudson regression for current cm3 / incompatibilities In-Reply-To: References: <20100718165513.gug2fuk04k8cww0o@mail.elegosoft.com>, Message-ID: Things are better now. Several jobs have succeeded. e.g. lots of I386_DARWIN, AMD64_LINUX, LINUXLIBC. Not all platforms have tried anything though. I just kicked some. e.g. SOLgnu. Not all platforms have new jobs. e.g. AMD64_DARWIN, NT386, SOLsun, PPC_DARWIN, PPC_LINUX, I386_OPENBSD. SPARC32_LINUX is still broken for reasons specific to it or at least sparc-specific. I'll look at it. cm3-current-build-FreeBSD4 seems hung. Thanks, ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Subject: RE: [M3devel] Hudson regression for current cm3 / incompatibilities > Date: Sun, 18 Jul 2010 16:16:15 +0000 > > > This is great Olaf, having this already going, no matter the target names. > I'll watch it. > > Thanks, > - Jay > > ---------------------------------------- > > Date: Sun, 18 Jul 2010 16:55:13 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: [M3devel] Hudson regression for current cm3 / incompatibilities > > > > I've disabled the existing cm3 build and test jobs on Hudson and copied > > them to new ones all named cm3-current-*; I've also added a new view > > cm3-current that is now displayed by default. > > The now disabled jobs may be used again for the next release. > > > > However, already some incompatibilities seen to habe crept in. > > Neither the m3cc nor the build jobs succeed; i.e. the current sources > > cannot be built with the latest release version, even with the > > upgrade script. > > > > This should be fixed. > > > > Please have a look at > > > > http://hudson.modula3.com:8080/ > > > > When everything looks good again, I'll start to rename some of the > > jobs to new platform names as Jay requested (if we can all agree on them). > > However, this will take some more time and a better connection than that > > I currently have here from my mobile notebook. > > > > And now for something completely different again (it's weekend after all), > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > > From jay.krell at cornell.edu Mon Jul 19 02:20:05 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Jul 2010 00:20:05 +0000 Subject: [M3devel] Hudson regression for current cm3 / incompatibilities In-Reply-To: References: <20100718165513.gug2fuk04k8cww0o@mail.elegosoft.com>, , , Message-ID: Oops. I was looking at the platform views instead of the cm3-current view. Things are better and worse than I said. More jobs exist, more jobs have succeeded, more jobs have also failed (that exist!) and I need to look at, e.g. PPC_DARWIN. I understand the PPC_DARWIN problem already -- related to building on older platform and my forcing autoconf to believe features are there. I know what to do. Thanks, ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Date: Mon, 19 Jul 2010 00:16:46 +0000 > Subject: Re: [M3devel] Hudson regression for current cm3 / incompatibilities > > > Things are better now. Several jobs have succeeded. e.g. lots of I386_DARWIN, AMD64_LINUX, LINUXLIBC. > Not all platforms have tried anything though. I just kicked some. e.g. SOLgnu. > Not all platforms have new jobs. e.g. AMD64_DARWIN, NT386, SOLsun, PPC_DARWIN, PPC_LINUX, I386_OPENBSD. > SPARC32_LINUX is still broken for reasons specific to it or at least sparc-specific. I'll look at it. > cm3-current-build-FreeBSD4 seems hung. > > Thanks, > - Jay > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: wagner at elegosoft.com; m3devel at elegosoft.com > > Subject: RE: [M3devel] Hudson regression for current cm3 / incompatibilities > > Date: Sun, 18 Jul 2010 16:16:15 +0000 > > > > > > This is great Olaf, having this already going, no matter the target names. > > I'll watch it. > > > > Thanks, > > - Jay > > > > ---------------------------------------- > > > Date: Sun, 18 Jul 2010 16:55:13 +0200 > > > From: wagner at elegosoft.com > > > To: m3devel at elegosoft.com > > > Subject: [M3devel] Hudson regression for current cm3 / incompatibilities > > > > > > I've disabled the existing cm3 build and test jobs on Hudson and copied > > > them to new ones all named cm3-current-*; I've also added a new view > > > cm3-current that is now displayed by default. > > > The now disabled jobs may be used again for the next release. > > > > > > However, already some incompatibilities seen to habe crept in. > > > Neither the m3cc nor the build jobs succeed; i.e. the current sources > > > cannot be built with the latest release version, even with the > > > upgrade script. > > > > > > This should be fixed. > > > > > > Please have a look at > > > > > > http://hudson.modula3.com:8080/ > > > > > > When everything looks good again, I'll start to rename some of the > > > jobs to new platform names as Jay requested (if we can all agree on them). > > > However, this will take some more time and a better connection than that > > > I currently have here from my mobile notebook. > > > > > > And now for something completely different again (it's weekend after all), > > > > > > Olaf > > > -- > > > Olaf Wagner -- elego Software Solutions GmbH > > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > > > > > From jay.krell at cornell.edu Mon Jul 19 03:33:05 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Jul 2010 01:33:05 +0000 Subject: [M3devel] Hudson m3cc clean? In-Reply-To: <20100719012318.ABC2E2474003@birch.elegosoft.com> References: <20100719012318.ABC2E2474003@birch.elegosoft.com> Message-ID: Olaf, the m3cc tasks should run "clean" with this -- configure needs to rerun. It seems some have such a check mark option, some do not. Platforms that are succeeding I guess can be left alone, but the ppc/sparc ones.. The ones on my machines I can fiddle with, but PPC_DARWIN.. Thanks, ?- Jay ---------------------------------------- > Date: Mon, 19 Jul 2010 03:23:16 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/07/19 03:23:16 > > Modified files: > cm3/m3-sys/m3cc/src/: m3makefile > cm3/m3-sys/m3cc/gcc/gcc/config/: darwin.h > > Log message: > m3makefile, basically undo: > Revision 1.162 > always specify -build, -host, -target, for cross and native > consistent but experimenta/unorthodox > Usually people let config.guess do all the work for native > and always for build. > Default build to host, not target. > > Revision 1.161 > Always specify -target. > in native builds, always specify -build and -host. > This should provide for more consistency, > though is also a bit experimental and unorthodox. > > darwin.h, undo > Revision 1.2 > always support hidden aka private extern aka don't export every function > > This should fix PPC_DARWIN and maybe maybe others (SPARC32_LINUX). > > Possibly relatd, I've noticed SOLsun using sparc-sun-solaris2.10-gcc > to build cm3cg, when I was hoping it'd use Sun cc. This will > at least change it to plain gcc, but same thing. > From jay.krell at cornell.edu Mon Jul 19 05:53:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Jul 2010 03:53:08 +0000 Subject: [M3devel] Hudson m3cc clean? In-Reply-To: References: <20100719012318.ABC2E2474003@birch.elegosoft.com>, Message-ID: They should probably all be clean. Given also the merge to 4.3.5. And that I put back dependency tracking. I think I'll put something in m3cc/src/m3makefile with a timestamp or guid, checked in by developer, copied to an output file in build_dir, and if they vary, delete everything. So checking in a deliberate edit to m3cc/src/m3makefile will trigger clean. In the mean time did *some* ssh root@ ; cd ~hudson; rm -rf */*/m3cc/{PPC_LINUX,SPARC32_LINUX} on my machines. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Subject: Hudson m3cc clean? > Date: Mon, 19 Jul 2010 01:33:05 +0000 > > > Olaf, the m3cc tasks should run "clean" with this -- configure needs to rerun. > It seems some have such a check mark option, some do not. > Platforms that are succeeding I guess can be left alone, but the ppc/sparc ones.. > The ones on my machines I can fiddle with, but PPC_DARWIN.. > > Thanks, > - Jay > > ---------------------------------------- > > Date: Mon, 19 Jul 2010 03:23:16 +0000 > > To: m3commit at elegosoft.com > > From: jkrell at elego.de > > Subject: [M3commit] CVS Update: cm3 > > > > CVSROOT: /usr/cvs > > Changes by: jkrell at birch. 10/07/19 03:23:16 > > > > Modified files: > > cm3/m3-sys/m3cc/src/: m3makefile > > cm3/m3-sys/m3cc/gcc/gcc/config/: darwin.h > > > > Log message: > > m3makefile, basically undo: > > Revision 1.162 > > always specify -build, -host, -target, for cross and native > > consistent but experimenta/unorthodox > > Usually people let config.guess do all the work for native > > and always for build. > > Default build to host, not target. > > > > Revision 1.161 > > Always specify -target. > > in native builds, always specify -build and -host. > > This should provide for more consistency, > > though is also a bit experimental and unorthodox. > > > > darwin.h, undo > > Revision 1.2 > > always support hidden aka private extern aka don't export every function > > > > This should fix PPC_DARWIN and maybe maybe others (SPARC32_LINUX). > > > > Possibly relatd, I've noticed SOLsun using sparc-sun-solaris2.10-gcc > > to build cm3cg, when I was hoping it'd use Sun cc. This will > > at least change it to plain gcc, but same thing. > > > From jay.krell at cornell.edu Mon Jul 19 08:10:58 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Jul 2010 06:10:58 +0000 Subject: [M3devel] clean in m3cc Message-ID: Too dangerous: m3cc/src/m3makefile if stale(build_dir & "/clean_marker.txt", "../src/clean_marker.txt") or defined ("FORCE") ? m3cc_Run(["rm -rf " & build_dir & "/*"]) ? cp_if("../src/clean_marker.txt", build_dir & "/clean_marker.txt") end ? If build_dir has a space..? ?- Jay From jay.krell at cornell.edu Mon Jul 19 08:17:29 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Jul 2010 06:17:29 +0000 Subject: [M3devel] clean in m3cc In-Reply-To: References: Message-ID: nevermind ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 19 Jul 2010 06:10:58 +0000 > Subject: [M3devel] clean in m3cc > > > Too dangerous: > > m3cc/src/m3makefile > > if stale(build_dir & "/clean_marker.txt", "../src/clean_marker.txt") or defined ("FORCE") > m3cc_Run(["rm -rf " & build_dir & "/*"]) > cp_if("../src/clean_marker.txt", build_dir & "/clean_marker.txt") > end > > ? > > If build_dir has a space..? > > > - Jay > > From wagner at elegosoft.com Mon Jul 19 08:27:13 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 19 Jul 2010 08:27:13 +0200 Subject: [M3devel] compiler behavior under "low memory"? In-Reply-To: References: Message-ID: <20100719082713.yjrrwn53b40sw0gc@mail.elegosoft.com> Perhaps a small limit was set on the system? (bash: ulimit, csh: limit) As for a fix, perhaps we could catch the exception in the builder and write out all known version information acquired so far (FINALLY block)? Olaf Quoting Jay K : > Mark had a machine with low memory. > It has more swap now. > > Our behavior was: > > Compiling m3tk would make good progress, complete many files, then fail for > ?lack of memory. > > Manual retry would start over due to > ?"missing version information" or such. > > Thus progress was "impossible". > By editing down m3makefile I was able to make progress. > ?Some stuff would fail due to missing interfaces, but > ?whatever I left in would get the version information saved. > ? > Perhaps we should write out the version information every "few" files? > ?For some definition of "few"? 10? 10% of the total? > ? > ? > That would at least let such situations progress via manual retry. > ? (unless not even a "few" fit in memory) > > > I also wonder about reducing memory used, or why indeed we run out, > ?but that is a thornier problem. You know, all we should need to > ?continue forward progress is to hold all interfaces in memory and > ?one implementation at a time. Now, there are a few unknowns here. > ?It is possible Mark's machine didn't have enough memory for > ?all the relevant interfaces, and that we only "load" them on-demand. > > ? > ?It is also likely, I should add, that virtual address space is the > ? problem, not working set. Some systems want to commit room > ? in swap for all allocated virtual memory, like, to be sure > ? ahead of time that everything can be paged out so other > ? code can progress. Something like that. I'm not sure here. > ? That is, I suspect we don't care. Virtual address space is probably > ? reasonable to deem cheap. No problem using almost 2GB of address space > ? as long as working set isn't that large (ie: to fit in 31bit > address space). > ? If some OSes don't see it that way, oh well. This might just > ? be a design/policy thing in Tru64. > ? > ? > (I'm well aware of virtual memory vs. physical memory vs. working set. > But for whatever reason, we were failing due to memory use. > All that *should* matter is that address space usage stays within > around 2GB and that working set isn't huge. Working set I've recently > come to understand can be managed like so: > ? - random access over set of memory that fits in physical memory > ? - sequential access over arbitrary memory (up to 2GB) > ? - hybrid of previous > ????? ie. sequential accesses over multiple separate areas > > As long as access is sequential, you shouldn't "thrash". > It is only random access over data that doesn't fit in physical memory > ?that causes thrashing.) > > > ?- 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 wagner at elegosoft.com Mon Jul 19 08:30:13 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 19 Jul 2010 08:30:13 +0200 Subject: [M3devel] multithreaded compiler? In-Reply-To: References: Message-ID: <20100719083013.uediq2tuogowg04g@mail.elegosoft.com> Quoting Jay K : > It should be reasonably easy to have the gcc backend run on multiple > separate threads. This won't necessarily speed things up, but could be an interesting option (-j ) depending on the machine in use. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Jul 19 09:31:22 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Jul 2010 07:31:22 +0000 Subject: [M3devel] Alpha/OSF exception handling In-Reply-To: References: , Message-ID: I didn't "remove" it, but I did "disable" it. Similar. I didn't want to have to spend any time debugging it if it didn't work any longer. I'm sure we have precious few users of this system (2 this month though, quite a surge) and they can probably live with an equally bad implementation as all the other platforms (except for Solaris/sparc). ? Granted, they have slower than average systems, would benefit more perhaps from the optimization. We can try it out I guess. I do hope we can improve this across the aboard. ? Even if we don't use the tree exception handling nodes, we can probably at least use the same runtime support (libunwind in libgcc). ? Even then, Alpha/OSF won't be important. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Sun, 18 Jul 2010 14:22:41 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Alpha/OSF exception handling > > That is a huge shame. Why did you remove it? It used to be there and functional. > > On 18 Jul 2010, at 09:35, Jay K wrote: > > > > > Modula-3 for ALPHA_OSF historically had the best exception handling implementation. > > > > With Solaris/sparc32 second best. > > > > And then everything else equally bad. > > > > > > > > > > > > The current Alpha/osf is now in the "equally bad" category. > > Because I'm lazy. > > > > It might be worth restoring its former glory. > > > > > > > > Maybe a small project for someone? > > > > > > The code is still in there. I just tweaked the m3makefiles to avoid trying it. > > > > > > jbook2:runtime jay$ pwd > > /dev2/cm3/m3-libs/m3core/src/runtime > > jbook2:runtime jay$ find ALPHA_OSF > > ALPHA_OSF/m3makefile-old > > > > Renaming that m3makefile. > > > > Fiddling with this: > > > > book2:runtime jay$ grep STACK * > > m3makefile:readonly HAS_STACK_WALKER = { > > m3makefile:if defined("M3_USE_STACK_WALKER") > > m3makefile: if M3_USE_STACK_WALKER and HAS_STACK_WALKER contains TARGET > > m3makefile: if HAS_STACK_WALKER{TARGET} > > > > > > and this: > > > > > > jbook2:src jay$ pwd > > /dev2/cm3/m3-sys/m3middle/src > > > > > > book2:src jay$ grep -i _stack *m3 > > Target.m3: Has_stack_walker := FALSE; > > Target.m3: Has_stack_walker := TRUE; > > > > > > - Jay > > > From wagner at elegosoft.com Mon Jul 19 09:49:59 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 19 Jul 2010 09:49:59 +0200 Subject: [M3devel] Hudson regression for current cm3 / incompatibilities In-Reply-To: References: <20100718165513.gug2fuk04k8cww0o@mail.elegosoft.com>, , , Message-ID: <20100719094959.plxt7b5u8c0og8o8@mail.elegosoft.com> Quoting Jay K : > Oops. I was looking at the platform views instead of the cm3-current view. > Things are better and worse than I said. More jobs exist, more jobs > have succeeded, more jobs have also failed (that exist!) and I need > to look at, e.g. PPC_DARWIN. > I understand the PPC_DARWIN problem already -- related to building > on older platform and my forcing autoconf to believe features are > there. > I know what to do. O know that my script missed NT386 jobs, but the others should all be there. I'll add that manually today. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Jul 19 10:17:15 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 19 Jul 2010 10:17:15 +0200 Subject: [M3devel] clean in m3cc In-Reply-To: References: Message-ID: <20100719101715.r4k0ubcc0oo80oso@mail.elegosoft.com> I've added a Hudson build variable CLEAN to all cm3-current-m3cc-* jobs. Olaf Quoting Jay K : > nevermind > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: m3devel at elegosoft.com >> Date: Mon, 19 Jul 2010 06:10:58 +0000 >> Subject: [M3devel] clean in m3cc >> >> >> Too dangerous: >> >> m3cc/src/m3makefile >> >> if stale(build_dir & "/clean_marker.txt", >> "../src/clean_marker.txt") or defined ("FORCE") >> m3cc_Run(["rm -rf " & build_dir & "/*"]) >> cp_if("../src/clean_marker.txt", build_dir & "/clean_marker.txt") >> end >> >> ? >> >> If build_dir has a space..? >> >> >> - 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 mika at async.async.caltech.edu Mon Jul 19 11:01:10 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Mon, 19 Jul 2010 02:01:10 -0700 Subject: [M3devel] div/mod In-Reply-To: References: Message-ID: <20100719090110.8ED961A2084@async.async.caltech.edu> No, aborting is always something the implementation is permitted to do if it can't do the sensible thing. If it can do something sensible, it may still be permitted to abort, but is not under the obligation to do so. I think this is a general principle. Mika Jay K writes: > >ok=2C this is a really minor thing. Very esoteric=2C waste of time probably= >. > > >Div and mod are defined in terms of each other. > > >In the "real world"=2C any integer mod negative 1 is 0.=20 >=A0 All integers are "evenly divisible" by 1 and negative 1. > >So INT_MIN mod -1 is 0. > > >One can code that to be the case. Some versions of the code do. >=A0 I'm not sure about the current code=2C as we don't call the C functions= > any longer=2C except for int64 on NT386. >=A0 The older div/mod helpers=2C depending on optimization=2C would either = >return 0 >=A0=A0 or generate an overflow exception. > > >In our computer world=2C INT_MIN div -1 is not computable=2C and generates >=A0 the same exception. Even with current code. > > >If div and mod are defined in terms of each other=2C and one of them is not= > computable=2C >=A0 is it wrong to be able to compute the other? > > >=A0- Jay > > = From mika at async.async.caltech.edu Mon Jul 19 11:04:59 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Mon, 19 Jul 2010 02:04:59 -0700 Subject: [M3devel] moving to new target names, in Hudson? In-Reply-To: <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com> References: <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com> Message-ID: <20100719090459.4CE191A2084@async.async.caltech.edu> Can I also add that changing the target names is going to require work---perhaps quite a bit of work---among users of CM3... now they will no longer match PM3, or a version of CM3 older than a particular, arbitrary date. All sorts of configuration and setup scripts will have to be fixed. I would hope this sort of thing would be done for a new version number or something else that is easily testable... I suppose you can grep through the output of cm3 -version. But m3build doesn't print the target, so the scripts really do become quite a bit more complicated.... Mika Olaf Wagner writes: >Quoting Jay K : > >> Olaf, can I request that if/when you move Hudson to head, that you =20 >> also switch to I386_LINUX, I386_FREEBSD, I386_NT, >> and whatever we decide for SPARC32_SOLARIS? >> I've mostly switched to them myself. It wasn't difficult. (I always =20 >> say that). > >It will require a lot of manual work, compared to the more or less >automated transition I just made from release to current for all the >jobs. The target platform names are part of the jobs, and are also used >in various places in the build scripts, so that many things are likely >to break. > >My guess is that it will take some days for every target move given my >current attention pattern for cm3, i.e. have a look at how things work >out now and then between other work. > >Let's wait until all the jobs work again with their old target names, > >Olaf > >> I think for SPARC32_SOLARIS we should either have SPARC32_SOLARIS =20 >> that is the equivalent of today's SOLsun. >> Effectively dropping SOLgnu. >> >> >> Or we also add SPARC32_SOLARIS_gcc, which is just a configuration =20 >> file and not a target. >> This is like the "experiment" I did with NT386/NT386GNU, which I =20 >> think I regret, except >> SPARC32_SOLARIS / SPARC32_SOLAROS_gcc are far far more similar than those. >> All their platform-specific code is identical. Their backend is =20 >> identical. etc. >> >> >> A related option is SPARC32_SOLARIS_cc or SPARC32_SOLARIS_suncc, and =20 >> SPARC32_SOLARIS_gcc. >> Config files. >> But the compiler only know about SPARC32_SOLARIS. >> Just putting the two config files more as peers, so to speak. >> >> >> The way I switched targets was probably doing a cross build. >> That is overkill. You can probably just export CM3_TARGET to the =20 >> name you want. >> And maybe fiddle with shipping of cm3cg or settings its build_dir -- =20 >> i.e. leave it as just host and host-target. >--=20 >Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb=C3=A4ude 12, 13355 Berlin, Germa= >ny >phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch=C3=A4ftsf=C3=BChrer: Olaf Wagner | Sitz= >: Berlin >Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Jul 19 12:48:38 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Jul 2010 10:48:38 +0000 Subject: [M3devel] moving to new target names, in Hudson? In-Reply-To: <20100719090459.4CE191A2084@async.async.caltech.edu> References: , <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com>, <20100719090459.4CE191A2084@async.async.caltech.edu> Message-ID: The old target names are still available. I agree something like cm3 -version should be more useful. Notice: ? gcc -dumpmachine ? gcc -dumpspecs ? gcc -dumpversion ? gcc -print-search-dirs *However* notice that cm3 is *not* preconfigured/predisposed for any particular target. It has a list of targets and it can handle any of them. The config file decides the target. ?In fact, neither cm3 nor the config files are particularly knowledable about targets. ? The config files vary a little in how they run the compiler or linker. ? cm3 varies mainly in word size, endianness, and jmpbuf size. ? All the real work of knowing about targets is buried in gcc. ? And a smattering of #ifdefs in C code. Some of which could be pushed to autoconf. The old names confuse people -- you, for example. They are inconsistent. They don't specify processor architecture. What pain did you all go through when FreeBSD changed to FreeBSD2 changed to FreeBSD3 changed to FreeBSD4? Or LINUX to LINUXELF to LINUXLIBC6? So long ago nobody remembers? I used LINUXELF a little, built it, went away, came back and there was LINUXLIBC6. I had no code. It didn't matter to me. ?- Jay ---------------------------------------- > To: wagner at elegosoft.com > Date: Mon, 19 Jul 2010 02:04:59 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] moving to new target names, in Hudson? > > > Can I also add that changing the target names is going to require > work---perhaps quite a bit of work---among users of CM3... now they will > no longer match PM3, or a version of CM3 older than a particular, arbitrary > date. All sorts of configuration and setup scripts will have to be fixed. > I would hope this sort of thing would be done for a new version number > or something else that is easily testable... I suppose you can grep through > the output of cm3 -version. But m3build doesn't print the target, so the > scripts really do become quite a bit more complicated.... > > Mika > > Olaf Wagner writes: > >Quoting Jay K : > > > >> Olaf, can I request that if/when you move Hudson to head, that you =20 > >> also switch to I386_LINUX, I386_FREEBSD, I386_NT, > >> and whatever we decide for SPARC32_SOLARIS? > >> I've mostly switched to them myself. It wasn't difficult. (I always =20 > >> say that). > > > >It will require a lot of manual work, compared to the more or less > >automated transition I just made from release to current for all the > >jobs. The target platform names are part of the jobs, and are also used > >in various places in the build scripts, so that many things are likely > >to break. > > > >My guess is that it will take some days for every target move given my > >current attention pattern for cm3, i.e. have a look at how things work > >out now and then between other work. > > > >Let's wait until all the jobs work again with their old target names, > > > >Olaf > > > >> I think for SPARC32_SOLARIS we should either have SPARC32_SOLARIS =20 > >> that is the equivalent of today's SOLsun. > >> Effectively dropping SOLgnu. > >> > >> > >> Or we also add SPARC32_SOLARIS_gcc, which is just a configuration =20 > >> file and not a target. > >> This is like the "experiment" I did with NT386/NT386GNU, which I =20 > >> think I regret, except > >> SPARC32_SOLARIS / SPARC32_SOLAROS_gcc are far far more similar than those. > >> All their platform-specific code is identical. Their backend is =20 > >> identical. etc. > >> > >> > >> A related option is SPARC32_SOLARIS_cc or SPARC32_SOLARIS_suncc, and =20 > >> SPARC32_SOLARIS_gcc. > >> Config files. > >> But the compiler only know about SPARC32_SOLARIS. > >> Just putting the two config files more as peers, so to speak. > >> > >> > >> The way I switched targets was probably doing a cross build. > >> That is overkill. You can probably just export CM3_TARGET to the =20 > >> name you want. > >> And maybe fiddle with shipping of cm3cg or settings its build_dir -- =20 > >> i.e. leave it as just host and host-target. > >--=20 > >Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb=C3=A4ude 12, 13355 Berlin, Germa= > >ny > >phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > http://www.elegosoft.com | Gesch=C3=A4ftsf=C3=BChrer: Olaf Wagner | Sitz= > >: Berlin > >Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Jul 19 12:50:37 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Jul 2010 10:50:37 +0000 Subject: [M3devel] clean in m3cc In-Reply-To: <20100719101715.r4k0ubcc0oo80oso@mail.elegosoft.com> References: , , <20100719101715.r4k0ubcc0oo80oso@mail.elegosoft.com> Message-ID: I put in another mechanism. If someone makes a change such that they want m3cc to build clean, edit m3-sys/m3cc/src/clean-marker.txt arbitrarily. I'm not sure though, the stuff at the top of m3cc/src/m3makefile might need to be adjusted to honor it. I probably should do even better -- the configure command line should be saved and if it changes, go clean. I didn't do that yet. ?- Jay ---------------------------------------- > Date: Mon, 19 Jul 2010 10:17:15 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] clean in m3cc > > I've added a Hudson build variable CLEAN to all cm3-current-m3cc-* jobs. > > Olaf > > Quoting Jay K : > > > nevermind > > > > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: m3devel at elegosoft.com > >> Date: Mon, 19 Jul 2010 06:10:58 +0000 > >> Subject: [M3devel] clean in m3cc > >> > >> > >> Too dangerous: > >> > >> m3cc/src/m3makefile > >> > >> if stale(build_dir & "/clean_marker.txt", > >> "../src/clean_marker.txt") or defined ("FORCE") > >> m3cc_Run(["rm -rf " & build_dir & "/*"]) > >> cp_if("../src/clean_marker.txt", build_dir & "/clean_marker.txt") > >> end > >> > >> ? > >> > >> If build_dir has a space..? > >> > >> > >> - 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 mika at async.async.caltech.edu Mon Jul 19 13:02:07 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Mon, 19 Jul 2010 04:02:07 -0700 Subject: [M3devel] moving to new target names, in Hudson? In-Reply-To: References: , <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com>, <20100719090459.4CE191A2084@async.async.caltech.edu> Message-ID: <20100719110208.011521A2091@async.async.caltech.edu> Jay K writes: > >The old target names are still available. > > ... > >*However* notice that cm3 is *not* preconfigured/predisposed for any partic= >ular target. cm3 -version prints a target... > > >It has a list of targets and it can handle any of them. The config file dec= >ides the target. >=A0In fact=2C neither cm3 nor the config files are particularly knowledable= > about targets. >=A0 The config files vary a little in how they run the compiler or linker. >=A0 cm3 varies mainly in word size=2C endianness=2C and jmpbuf size. >=A0 All the real work of knowing about targets is buried in gcc. >=A0 And a smattering of #ifdefs in C code. Some of which could be pushed to= > autoconf. > > >The old names confuse people -- you=2C for example. >They are inconsistent. >They don't specify processor architecture. > Well I agree with that much.. > >What pain did you all go through when FreeBSD changed to FreeBSD2 changed t= >o FreeBSD3 changed to FreeBSD4? >Or LINUX to LINUXELF to LINUXLIBC6? >So long ago nobody remembers? >I used LINUXELF a little=2C built it=2C went away=2C came back and there wa= >s LINUXLIBC6. I had no code. It didn't matter to me. > The point of these names, I thought, was that they were supposed to map to binary-incompatible systems. I remember having FreeBSD2 and FreeBSD3 at the same time. We had a cluster with machines with both OSes, which were not binary compatible. The point is so that you can run cm3/m3build for both in the same repository (even concurrently), and not have them interfere with each other. It's not a pain to have different names if they actually mean different things. If you just call everything I386_FREEBSD all hell will break loose in that situation... (just as when I by mistake run "FreeBSD4" (really FreeBSD6) CM3 in a directory where I have already compiled things with "FreeBSD4" (really FreeBSD4) PM3...) Or am I misunderstanding something here? I would have thought you really wanted to have a different name for each binary-incompatible system so you can build them all in the same place. Consistency in naming would be nice but I think it is secondary. Mika From jay.krell at cornell.edu Mon Jul 19 13:51:28 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Jul 2010 11:51:28 +0000 Subject: [M3devel] moving to new target names, in Hudson? In-Reply-To: <20100719110208.011521A2091@async.async.caltech.edu> References: , , <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com>, , <20100719090459.4CE191A2084@async.async.caltech.edu>, , <20100719110208.011521A2091@async.async.caltech.edu> Message-ID: Well, from the compiler (cm3, cm3cg) and libraries (m3core/*.m3, etc.) point of view, now, all I386_FREEBSD are the same. ?They are all little endian, 32bit word, have the same jmpbuf, and no stack walker. ?(Ok, there's a small difference in that older FreeBSD might not have decent enough pthreads. ? So we should really maybe have I386_FREEBSD_pthreads and I386_FREEBSD_userthreads. ??? But this still is overkill. They are still identical in cm3 and cm3cg. They vary only in m3core/*/m3makefile. ?? I think this is best done by making the "thread library" a variable that the user can edit in config file. ?? And maybe gets appended to BUILD_DIR. But TARGET is unchanged.) Any differences or binary compatibilities aren't present until m3core/*.c #includes varying headers. I think it makes more sense probably for people to start editing BUILD_DIR in their config files. ? I386_FREEBSD1 ? I386_FREEBSD2 ? I386_FREEBSD3 ? I386_FREEBSD4 ? I386_FREEBSD5 ? I386_FREEBSD6 ? I386_FREEBSD7 ? I386_FREEBSD8 ? I386_SOLARIS2.8 ? ? I386_SOLARIS2.9? ? I386_SOLARIS2.10 ? I386_SOLARIS2.11? Exposing this explosion in more than maybe one directory, I quite dislike. They could be config files that set BUILD_DIR, maybe THREAD_LIBRARY (which I just made up) and then include(I386_FREEBSD). I like to think they are "configurations", lightweight toplevel things, many of them, that quickly devolve into a small number of "targets". Maybe what we should really, like, is run config.guess and use its entire output: i386-unknown-freebsd4.11 Unknown is unsightly.. Specifically for BUILD_DIR. TARGET would be somehow computed from that? BUILD_DIR is arbitrary. See how profiling appends "p" to it? Not that I ever use that. Perhaps not that anyone ever has TARGET != BUILD_DIR. ? Though that is how Modula-3 works for Cygwin. I am slowly believing in the way of autoconf and the GNU build system. It must be observed. On one hand that exposes a combinatorial explosion of configurations. On the other, it avoids canonizing any particular combination as special. If cm3 were to discover jmpbuf size in some sort of autoconf-ish thing, and record that merely in the config file, we'd be left with basically only four architectures in cm3: little endian32, little endian64, big endian32, big endian64. Heck, it doesn't even need to be autoconfish. It just needs to be in the config files. And a very small number of other things: the name of setjmp (_setjmp or setjmp), if there is a stack walker (usually false but sometimes true). ?- Jay ---------------------------------------- > To: jay.krell at cornell.edu > Date: Mon, 19 Jul 2010 04:02:07 -0700 > From: mika at async.async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] moving to new target names, in Hudson? > > Jay K writes: > > > >The old target names are still available. > > > > > ... > > > >*However* notice that cm3 is *not* preconfigured/predisposed for any partic= > >ular target. > > cm3 -version prints a target... > > > > > > >It has a list of targets and it can handle any of them. The config file dec= > >ides the target. > >=A0In fact=2C neither cm3 nor the config files are particularly knowledable= > > about targets. > >=A0 The config files vary a little in how they run the compiler or linker. > >=A0 cm3 varies mainly in word size=2C endianness=2C and jmpbuf size. > >=A0 All the real work of knowing about targets is buried in gcc. > >=A0 And a smattering of #ifdefs in C code. Some of which could be pushed to= > > autoconf. > > > > > >The old names confuse people -- you=2C for example. > >They are inconsistent. > >They don't specify processor architecture. > > > > Well I agree with that much.. > > > > >What pain did you all go through when FreeBSD changed to FreeBSD2 changed t= > >o FreeBSD3 changed to FreeBSD4? > >Or LINUX to LINUXELF to LINUXLIBC6? > >So long ago nobody remembers? > >I used LINUXELF a little=2C built it=2C went away=2C came back and there wa= > >s LINUXLIBC6. I had no code. It didn't matter to me. > > > > The point of these names, I thought, was that they were supposed to map > to binary-incompatible systems. I remember having FreeBSD2 and FreeBSD3 > at the same time. We had a cluster with machines with both OSes, which > were not binary compatible. The point is so that you can run cm3/m3build > for both in the same repository (even concurrently), and not have them > interfere with each other. It's not a pain to have different names > if they actually mean different things. If you just call everything > I386_FREEBSD all hell will break loose in that situation... (just as when > I by mistake run "FreeBSD4" (really FreeBSD6) CM3 in a directory where > I have already compiled things with "FreeBSD4" (really FreeBSD4) PM3...) > > Or am I misunderstanding something here? I would have thought you really > wanted to have a different name for each binary-incompatible system so > you can build them all in the same place. Consistency in naming would be > nice but I think it is secondary. > > Mika From wagner at elegosoft.com Mon Jul 19 14:38:44 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 19 Jul 2010 14:38:44 +0200 Subject: [M3devel] moving to new target names, in Hudson? In-Reply-To: <20100719110208.011521A2091@async.async.caltech.edu> References: , <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com>, <20100719090459.4CE191A2084@async.async.caltech.edu> <20100719110208.011521A2091@async.async.caltech.edu> Message-ID: <20100719143844.03al7scsg0g400so@mail.elegosoft.com> Quoting Mika Nystrom : [...] > The point of these names, I thought, was that they were supposed to map > to binary-incompatible systems. I remember having FreeBSD2 and FreeBSD3 > at the same time. We had a cluster with machines with both OSes, which > were not binary compatible. The point is so that you can run cm3/m3build > for both in the same repository (even concurrently), and not have them > interfere with each other. It's not a pain to have different names > if they actually mean different things. If you just call everything > I386_FREEBSD all hell will break loose in that situation... (just as when > I by mistake run "FreeBSD4" (really FreeBSD6) CM3 in a directory where > I have already compiled things with "FreeBSD4" (really FreeBSD4) PM3...) > > Or am I misunderstanding something here? I would have thought you really > wanted to have a different name for each binary-incompatible system so > you can build them all in the same place. Consistency in naming would be > nice but I think it is secondary. In theory, yes, but it hasn't always worked out in practice. Binary compatibility works at least in two directions: (a) Allow applications compiled on an older system with older tools and libraries to be run on a newer system. (b) Allow applications compiled on a newer system to run on all or certain selected older system versions. Usually (a) is provided by Open Source systems like Linux, FreeBSD etc., at least within a major release line, sometimes also crossing boundaries (remember the switch from aout to elf format in FreeBSD). (b) is often partially provided by commercial systems like Windows, though in practice this doesn't always work as expected, too. It would be nice if we really could follow all binary compatibility changes in all supported operating system targets with a new unique name, but I'm afraid we haven't been able to do that in the past nor will we succeed to do that in the future. You have experienced one failure as you tried the FreeBSD4 packages built on FreeBSD 6.4 on an actual FreeBSD 4.11 system. We may get better if we distinguish between different uses of the target platform name though: (1) TARGET as a choice for compilation variants that cm3 distinguishes internally (2) TARGET as a name for the directories containing derived files (which is already configurable in quake config files). For example, the profiling setups I made some years ago added a `p' to the TARGET name. (3) TARGET as an indicator for installation or other binary packages on which system these binaries may run (3) should include as many information as possible, though it is not clear to me where to stop here. Do we actually want the X version or the GUI support libraries to be included there? What if different loadable formats are supported, as under Darwin (PPC, I386, combined) or Windows (com, exe (coff))? I would tend to start with something like the output of uname -rsm here: o FreeBSD 8.0-STABLE amd64 o Linux 2.6.26-2-amd64 x86_64 o FreeBSD 6.4-RELEASE-p5 i386 o Darwin 9.8.0 i386 o Darwin 8.11.0 Power Macintosh We could also add a more or less unspecified variant part there, for example, if we need to distinguish between aout/coff/elf format. (1) should be the list of distinctions we need to make to support different target platforms. The current compromise seems to be that this is a combination of processor/machine architecture (like I386, AMD64) and operating system name (not version). Then (2) could be an installation-specific choice: either just use the more generic name from (1), or a combination of (1) and (3), or some arbitrary name. It's not completely thought through yet, so suggestions on what exactly would be required or great are welcome. I've already added the information of (3) to the CM3 5.8.6 download pages; the next release should include it in the actual package names. (1) should be consistently standardized if possible (i.e. FreeBSD1/2/3/4 --> I386_FREEBSD etc.). Many actual configuration options may be determined by auto-configuration then. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Jul 19 15:32:22 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Jul 2010 13:32:22 +0000 Subject: [M3devel] moving to new target names, in Hudson? In-Reply-To: <20100719143844.03al7scsg0g400so@mail.elegosoft.com> References: , , <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com>, , <20100719090459.4CE191A2084@async.async.caltech.edu>, , <20100719110208.011521A2091@async.async.caltech.edu>, <20100719143844.03al7scsg0g400so@mail.elegosoft.com> Message-ID: Clearly this stuff is hard to describe. I think both Olaf and I sound like we're rambling. Esp. me. :) Olaf clearly gets my point of view though. :) > (b) is often partially provided by commercial systems like Windows, though > in practice this doesn't always work as expected, too. Yes it does! That's tangential though. ?> What if different loadable > formats are supported, as under Darwin (PPC, I386, combined) Let's table the "universal binaries" subject for now. I think it is slightly interesting, but nobody has asked for it, and it is fairly unique to Darwin. ?It can be done either by building everything twice, or by combing files after the fact. ? Nice thing about combining after the fact is basically nothing changes. > or Windows (com, exe (coff))? No, really, no. But I'll explain since you brought it up. There are two or so formats of MS-DOS file. A .com file is just under 64K of bytes loaded anywhere, all addresses are relative and <= 64K. That is, there is no file format. It just must be small. This is for 16bit code only. We don't support 16bit MS-DOS. There is MS-DOS .exe files which can be large and are relocatable. Again, this is a 16bit thing. In more general reality, people write their own loaders for MS-DOS. There's a DOS extender that loads Win32 files for example. Now, in Windows there is just one file format, PE, COFF, PE/COFF, whatever. All the same thing. The file *name* of such a file is arbitrary and varies. "more.com" is of the same file format as "findstr.exe". It just has that wierdo extension for compatibility. It is not a .com file like in MS-DOS. P in PE is "portable", as in all versions of NT: MIPS, PowerPC, 32bit Alpha, x86, use the same format. Later there was some revision, PE was renamed PE32, PE32+ was introduced. It is almost the same thing, but a few fields were widened to 64bits. Still, 64bit Alpha, IA64, AMD64 all use the same format. So there are only two formats: 32bit and 64bit. That's still nicely pretty "portable". So, short story, drop executable file format as a variable, at least on Windows. I understand some Unixes switched from a.out to ELF. That is/was relevant. LINUX => LINUXELF. But 32bit Windows never switched formats for files containing 32bit code. True, Win3.1 and OS/2 had various NE (new executable?), LE (linear executable?) but I don't think we care. Maybe at some point we'll have I386_OS2_NE, I386_OS2_LE but I don't know enough to say. More likely we'd have I386_WIN31, with one file format, I386_OS2 with one file format. > I would tend to start with something like the > output of uname -rsm here: > > o FreeBSD 8.0-STABLE amd64 > o Linux 2.6.26-2-amd64 x86_64 > o FreeBSD 6.4-RELEASE-p5 i386 > o Darwin 9.8.0 i386 > o Darwin 8.11.0 Power Macintosh I mostly agree, but I think it is maybe a little two much information in some cases. Should just be e.g. FreeBSD 8.0 amd64. FreeBSD 6.4 i386 -- does RELEASE p5 really help? I think you should look at the output (not the code) of the GNU config.guess file. I think it is mostly the way to go. It has those dumb "unknown" and "pc" things, and the "vendor" (apple, sun, dec) is generally meaningless. But the first and third/fourth parts are good. It is similar to your uname -srm. There are things beyond uname, like "sizer" on Alpha/OSF. config.guess finds the "g" in 4.0g, but uname doesn't. I'll admit another evidence of the problem. PPC64_DARWIN ?I think the last release added a bunch. ?So PPC64_DARWIN < 10.5 wouldn't have any Trestle/X stuff. ?But PPC64_DARWIN10.5 would. >From an implementation/compiler/library point of view, this can be implemented by having the config/m3makefiles probe at config/install/runtime. I've been putting probes in at runtime. Stuff that possibly belongs in config or install. Now, there is this this thorny issue you mention. We build binaries for redistribution. This does in a sense resemble a cross build. Building on machine X to run on machine Y, which may be more or less the same. If you consider something like Debian where they produce tons of binary packages, or even FreeBSD/NetBSD/OpenBSD, they have a luxury. They aren't really doing cross builds. They know the packages will be installed on the same OS release. They rebuild all the packages for each release. And Ubuntu vs. Debian are different builds. What do we do? Perhaps we sort of go back to the old model where customers do their own build? Or partly their own build? I think this is a definite possibility. And we use autoconf a bit in there? I think definitely maybe. The "boot" packages I build are a possible start. Though they need to come with matching Modula-3 source tree, including m3cc. ? => Just like the 3.6 DEC SRC release. Should we work towards that? Does it stink too much to make people build it? It has upside and downside. Upside is we get largely out of this configuration problem. Downside is they have to be much more patient before using the system. Perhaps we provide similar to what we already have, but with "overspecified configuration" names. If we have an exact match for you, great. If not, you build it yourself? I don't know about these Linux kernel version numbers. I hope/think Linux might have good compatibility? Our usage is fairly light. This is partly why i was interested in Modula-3 threads over Linux, instead of over glibc. So we could avoid the ARMEL_LINUX_glibc vs ARMEL_LINUX_uclibc vs. ARMEL_LINUX_bionic (Android) question. I'm rambling terribly, I realize. Sorry. In conclusion...I think we probably do something like uname -srm or config.guess, distribute "boot" + m3src.tar.gz + m3cc.tar.gz like DEC SRC did, we provide some binaries. User can rename build_dir to whatever he/she wants, but we'd start with something like config.guess? ?? Things like word size, endian, jmpbuf size, setjmp name, move to config file? ? Try to configure these things with autoconf? Make my "boot" packages use autoconf? e.g. to compile the C? ? To find libraries and build the config file and fill out SYSTEM_LIBS? i.e. to replace cminstall? Remove all target knowledge from Target.m3? ???? It's a bunch of work, makes these confusing (as autoconf does), but it does solve some problems I don't know. ?- Jay ---------------------------------------- > Date: Mon, 19 Jul 2010 14:38:44 +0200 > From: wagner at elegosoft.com > To: mika at async.async.caltech.edu > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > Subject: Re: [M3devel] moving to new target names, in Hudson? > > Quoting Mika Nystrom : > [...] > > The point of these names, I thought, was that they were supposed to map > > to binary-incompatible systems. I remember having FreeBSD2 and FreeBSD3 > > at the same time. We had a cluster with machines with both OSes, which > > were not binary compatible. The point is so that you can run cm3/m3build > > for both in the same repository (even concurrently), and not have them > > interfere with each other. It's not a pain to have different names > > if they actually mean different things. If you just call everything > > I386_FREEBSD all hell will break loose in that situation... (just as when > > I by mistake run "FreeBSD4" (really FreeBSD6) CM3 in a directory where > > I have already compiled things with "FreeBSD4" (really FreeBSD4) PM3...) > > > > Or am I misunderstanding something here? I would have thought you really > > wanted to have a different name for each binary-incompatible system so > > you can build them all in the same place. Consistency in naming would be > > nice but I think it is secondary. > > In theory, yes, but it hasn't always worked out in practice. > Binary compatibility works at least in two directions: > > (a) Allow applications compiled on an older system with older tools > and libraries to be run on a newer system. > > (b) Allow applications compiled on a newer system to run on all or > certain selected older system versions. > > Usually (a) is provided by Open Source systems like Linux, FreeBSD etc., > at least within a major release line, sometimes also crossing boundaries > (remember the switch from aout to elf format in FreeBSD). > > (b) is often partially provided by commercial systems like Windows, though > in practice this doesn't always work as expected, too. > > It would be nice if we really could follow all binary compatibility > changes in all supported operating system targets with a new unique > name, but I'm afraid we haven't been able to do that in the past nor > will we succeed to do that in the future. > > You have experienced one failure as you tried the FreeBSD4 packages > built on FreeBSD 6.4 on an actual FreeBSD 4.11 system. > > We may get better if we distinguish between different uses of the target > platform name though: > > (1) TARGET as a choice for compilation variants that cm3 distinguishes > internally > > (2) TARGET as a name for the directories containing derived files (which is > already configurable in quake config files). For example, the profiling > setups I made some years ago added a `p' to the TARGET name. > > (3) TARGET as an indicator for installation or other binary packages > on which system these binaries may run > > (3) should include as many information as possible, though it is not > clear to me where to stop here. Do we actually want the X version or > the GUI support libraries to be included there? What if different loadable > formats are supported, as under Darwin (PPC, I386, combined) or Windows > (com, exe (coff))? I would tend to start with something like the > output of uname -rsm here: > > o FreeBSD 8.0-STABLE amd64 > o Linux 2.6.26-2-amd64 x86_64 > o FreeBSD 6.4-RELEASE-p5 i386 > o Darwin 9.8.0 i386 > o Darwin 8.11.0 Power Macintosh > > We could also add a more or less unspecified variant part there, for > example, if we need to distinguish between aout/coff/elf format. > > (1) should be the list of distinctions we need to make to support > different target platforms. The current compromise seems to be that > this is a combination of processor/machine architecture (like I386, AMD64) > and operating system name (not version). > > Then (2) could be an installation-specific choice: either just use > the more generic name from (1), or a combination of (1) and (3), or > some arbitrary name. It's not completely thought through yet, so suggestions > on what exactly would be required or great are welcome. > > I've already added the information of (3) to the CM3 5.8.6 download > pages; the next release should include it in the actual package names. > > (1) should be consistently standardized if possible (i.e. FreeBSD1/2/3/4 > --> I386_FREEBSD etc.). Many actual configuration options may be > determined by auto-configuration then. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From wagner at elegosoft.com Mon Jul 19 16:28:35 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 19 Jul 2010 16:28:35 +0200 Subject: [M3devel] moving to new target names, in Hudson? In-Reply-To: References: , , <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com>, , <20100719090459.4CE191A2084@async.async.caltech.edu>, , <20100719110208.011521A2091@async.async.caltech.edu>, <20100719143844.03al7scsg0g400so@mail.elegosoft.com> Message-ID: <20100719162835.j0mnd9q3fo4s0g4g@mail.elegosoft.com> Hi Jay, I've learned several new things about Windows again; but in general, I don't think we disagree very much about the options and things to do. I agree that config.guess might be a good short-time option for the installation package names. I also agree that we could provide assembled packages for everything like PM3 did and rely on auto-configuration for everything else. This might be some more work for Windows though, as it uses a different backend than all other platforms. We'd need to create completely different Makefiles and scripts for Windows than for Unix and Unix-like systems. Or rely on some other tooling as prerequisite (either perl, python, Cygwin, ... you name it). I wouldn't like that very much though. I'm not sure yet if that would be welcome by all users and be seen as a step forward. I wouldn't mind it though. If it is generally accepted as a good idea, we should build up the infrastructure for that kind of packages and installations in parallel to what we have now. It would definitely not be the native Windows-installer user experience then ;-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Jul 19 16:34:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Jul 2010 14:34:02 +0000 Subject: [M3devel] I386_OPENBSD hangs in stubgen Message-ID: I386_OPENBSD hangs in stubgen Problem seems to be in the "rewritten" user threads (ie: using the sigaltstack approach instead of poking at the jmpbuf) here: ??? sigemptyset(&sigs); ??? sigaddset(&sigs, SIGUSR1); ??? sigprocmask(SIG_BLOCK, &sigs, &osigs); ... ??? kill(getpid(), SIGUSR1); ??? sigfillset(&sigs); ??? sigdelset(&sigs, SIGUSR1); ??? while (!mctx_called) ??????? sigsuspend(&sigs); The kill seems to come in immdiately, even though sigusr1 is blocked. And then sigsuspend hangs waiting forever. I forgot to eheck if mctx_called has changed, or if the check is optimized out. It seems ok if the kill comes in right away actually. I thought I had tested all this already on OpenBSD/x86 but I guess maybe not. I thought maybe the -pthread vs. -lpthread did it, but it seems not. I'll poke around more. I might resort to putting back the jmpbuf hacking, which would be unfortunate. (OpenBSD doesn't implement get/set/make/swapcontext, at least as of previous release 4.6.) ?- Jay From mika at async.async.caltech.edu Mon Jul 19 16:47:22 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Mon, 19 Jul 2010 07:47:22 -0700 Subject: [M3devel] moving to new target names, in Hudson? In-Reply-To: References: , , <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com>, , <20100719090459.4CE191A2084@async.async.caltech.edu>, , <20100719110208.011521A2091@async.async.caltech.edu> Message-ID: <20100719144722.81DB41A208C@async.async.caltech.edu> Well Jay, from the user's point of view it really doesn't matter whether cm3 is one binary or many... BUILD_DIR has more to do with whether the binaries that it produces can run on one platform or many. But from what I gather from your email, the idea seems to be that you can have many targets in one compiler and the user of the compiler can set BUILD_DIR himself, as he pleases? That would be wonderful... Does it work to do that? Can I just change BUILD_DIR to, say, MIKAS_ENVIRONMENT_USING_CM3_5_8_6_WITH_THREADS_HACKS_ON_FREEBSD_4_11_I386 and have everything work for me? Mika Jay K writes: > >Well=2C from the compiler (cm3=2C cm3cg) and libraries (m3core/*.m3=2C etc.= >) point of view=2C now=2C all I386_FREEBSD are the same. >=A0They are all little endian=2C 32bit word=2C have the same jmpbuf=2C and = >no stack walker. >=A0(Ok=2C there's a small difference in that older FreeBSD might not have d= >ecent enough pthreads. >=A0 So we should really maybe have I386_FREEBSD_pthreads and I386_FREEBSD_u= >serthreads. >=A0=A0=A0 But this still is overkill. They are still identical in cm3 and c= >m3cg. They vary only in m3core/*/m3makefile. >=A0=A0 I think this is best done by making the "thread library" a variable = >that the user can edit in config file. >=A0=A0 And maybe gets appended to BUILD_DIR. But TARGET is unchanged.) > > >Any differences or binary compatibilities aren't present until m3core/*.c #= >includes varying headers. >I think it makes more sense probably for people to start editing BUILD_DIR = >in their config files. >=A0 I386_FREEBSD1=20 >=A0 I386_FREEBSD2=20 >=A0 >I386_FREEBSD3=20 >=A0 >I386_FREEBSD4=20 >=A0 >I386_FREEBSD5=20 >=A0 >I386_FREEBSD6=20 >=A0 >I386_FREEBSD7=20 >=A0 I386_FREEBSD8 >=A0 I386_SOLARIS2.8 =A0=20 > > > >=A0 I386_SOLARIS2.9=A0=20 > > >=A0 I386_SOLARIS2.10=20 > > > >=A0 I386_SOLARIS2.11=A0=20 > > > > >Exposing this explosion in more than maybe one directory=2C I quite dislike= >. >They could be config files that set BUILD_DIR=2C maybe THREAD_LIBRARY (whic= >h I just made up) and then include(I386_FREEBSD). >I like to think they are "configurations"=2C lightweight toplevel things=2C= > many of them=2C that quickly devolve into a small number of "targets". > > > >Maybe what we should really=2C like=2C is run config.guess and use its enti= >re output: i386-unknown-freebsd4.11 >Unknown is unsightly.. Specifically for BUILD_DIR. TARGET would be somehow = >computed from that? > > > > >BUILD_DIR is arbitrary. See how profiling appends "p" to it? Not that I eve= >r use that. >Perhaps not that anyone ever has TARGET !=3D BUILD_DIR. >=A0 Though that is how Modula-3 works for Cygwin. > > >I am slowly believing in the way of autoconf and the GNU build system. It m= >ust be observed. >On one hand that exposes a combinatorial explosion of configurations. >On the other=2C it avoids canonizing any particular combination as special.= >=20 > > >If cm3 were to discover jmpbuf size in some sort of autoconf-ish thing=2C a= >nd record that merely in the config file=2C >we'd be left with basically only four architectures in cm3: little endian32= >=2C little endian64=2C big endian32=2C big endian64. > > >Heck=2C it doesn't even need to be autoconfish. It just needs to be in the = >config files. >And a very small number of other things: the name of setjmp (_setjmp or set= >jmp)=2C if there is a stack walker (usually false but sometimes true). > > > >=A0- Jay > >---------------------------------------- >> To: jay.krell at cornell.edu >> Date: Mon=2C 19 Jul 2010 04:02:07 -0700 >> From: mika at async.async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] moving to new target names=2C in Hudson? >> >> Jay K writes: >> > >> >The old target names are still available. >> > >> > >> ... >> > >> >*However* notice that cm3 is *not* preconfigured/predisposed for any par= >tic=3D >> >ular target. >> >> cm3 -version prints a target... >> >> > >> > >> >It has a list of targets and it can handle any of them. The config file = >dec=3D >> >ides the target. >> >=3DA0In fact=3D2C neither cm3 nor the config files are particularly know= >ledable=3D >> > about targets. >> >=3DA0 The config files vary a little in how they run the compiler or lin= >ker. >> >=3DA0 cm3 varies mainly in word size=3D2C endianness=3D2C and jmpbuf siz= >e. >> >=3DA0 All the real work of knowing about targets is buried in gcc. >> >=3DA0 And a smattering of #ifdefs in C code. Some of which could be push= >ed to=3D >> > autoconf. >> > >> > >> >The old names confuse people -- you=3D2C for example. >> >They are inconsistent. >> >They don't specify processor architecture. >> > >> >> Well I agree with that much.. >> >> > >> >What pain did you all go through when FreeBSD changed to FreeBSD2 change= >d t=3D >> >o FreeBSD3 changed to FreeBSD4? >> >Or LINUX to LINUXELF to LINUXLIBC6? >> >So long ago nobody remembers? >> >I used LINUXELF a little=3D2C built it=3D2C went away=3D2C came back and= > there wa=3D >> >s LINUXLIBC6. I had no code. It didn't matter to me. >> > >> >> The point of these names=2C I thought=2C was that they were supposed to m= >ap >> to binary-incompatible systems. I remember having FreeBSD2 and FreeBSD3 >> at the same time. We had a cluster with machines with both OSes=2C which >> were not binary compatible. The point is so that you can run cm3/m3build >> for both in the same repository (even concurrently)=2C and not have them >> interfere with each other. It's not a pain to have different names >> if they actually mean different things. If you just call everything >> I386_FREEBSD all hell will break loose in that situation... (just as when >> I by mistake run "FreeBSD4" (really FreeBSD6) CM3 in a directory where >> I have already compiled things with "FreeBSD4" (really FreeBSD4) PM3...) >> >> Or am I misunderstanding something here? I would have thought you really >> wanted to have a different name for each binary-incompatible system so >> you can build them all in the same place. Consistency in naming would be >> nice but I think it is secondary. >> >> Mika > = From jay.krell at cornell.edu Mon Jul 19 16:56:15 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Jul 2010 14:56:15 +0000 Subject: [M3devel] moving to new target names, in Hudson? In-Reply-To: <20100719162835.j0mnd9q3fo4s0g4g@mail.elegosoft.com> References: , ,,<20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com>, , , <20100719090459.4CE191A2084@async.async.caltech.edu>, , , , <20100719110208.011521A2091@async.async.caltech.edu>, , <20100719143844.03al7scsg0g400so@mail.elegosoft.com>, , <20100719162835.j0mnd9q3fo4s0g4g@mail.elegosoft.com> Message-ID: I agree we agree, on the issues. ? I know I've been rambly though, so I'm not sure others understand. ? I had made these points earlier for Cygwin vs. native NT, but they were less valid there. ? The systems resembled each other less. I'm nervous about my own suggestion though. Don't worry about Windows here. It has excellent binary compatibility and the existing static configuration will work fine. There is a similar matter with the C runtime version, which is also tied to the compiler version. You see I already handled that in terms of archive names. I also got "boot" archives working for I386_NT. The Makefile works with Microsoft nmake and is very simple. The "boot" process produces .objs instead assembly source, which is fine and good -- because of the integrated backend. To be clear, on NT, I think having the user build the system is fine and good. But instead of config.guess, probably just use "I386_NT_VC70", "I386_NT_VC80", "I386_NT_VC90", "I386_NT_VC100" You can see in pylib.py I probe the compiler version trivially. I guess I'll rewrite that in .cmd or JScript embedded in .cmd. ?That will do fine. And like my proposal where we build a few Posix packages (maybe very few), we can build a few/very few .msis. And just to remind everyone, m3src.tar.gz is split from m3cc.tar.gz, so that I386_NT users don't have to download m3cc.tar.gz which they don't use. Also to point out the obvious once you think about it: ?We can use DEC SRC for "guidance" but we cannot actually just go back to how it worked. ? In particular, because quake was written in C back then. They distributed C source to it. ? Small different really, as I believe they still distributed assembly of m3build. Let's sit and think/talk about this longer before implementing something we decide we don't like. I did start playing with autconf finally..been a long time coming. Thing is..I don't think we need the full machinery of automake and even GNU make. Depending on..another matter.. If you look at the existing boot archives, they just build cm3, Makefile is pretty simple. autoconf will help, to find the C compiler, flags for -pthreads. I put some annotations in m3core.h of stuff autoconf can figure out. Question then: do we extend this and ship the entire system as assembly + C + makefiles? That is, make user build m3cc, but then just assemble? Or, only ship assembly for cm3? I don't see a big difference either way. Except that full system assembly + C dovetails nicely into things like iphone where you want to "finish" the build not on the target, but using the "native cross" toolset. ie: it is probably useful automation to have. Independent of if we distribute it. But this does remind me...another thing autoconf can do...not autoconf actually, but libtool can be of use. A bit of the config files is how to run the linker, shared vs. static. libtool is kind of gross and slow. But this is what it does. (Again, I just wouldn't do it for NT.) "and another thing" We can perhaps distribute patches to gcc instead of the full gcc tree. State what version they are against, give a URL. ? We'd keep our tree for development convenience though. "and another thing" Back in the existing scheme of things..I was considering a go at upgrading m3gdb.. I'm still nervous. Maybe we wait and see how much success/failure there is with the current release's binary distribution. Mika's FreeBSD 4 problems and Mark's problem with 5.1 binaries on 4.0g aren't really enough to warrant doing much. Except that we do understand the problem. "and another thing" To whatever extent systems are x86/amd64 and runnable in VMs, and to whatever extent they have good backward compatibility, and to whatever extent Java is available on older systems. just building on "oldest common denominator" might be good. (I just up the term. :) ) Probably this new stuff can be worked on and pondered..completely without upsetting the status quo. I think so. Good. I've had a big mental hurdle around autoconf/libtool for a long time but I'm finally starting to clear it.. I think they are part of the solution. This will address the $ORIGIN stuff also of course, largely. ?(We still might provide a few binaries; maybe only for systems with $ORIGIN.) ?- Jay ---------------------------------------- > Date: Mon, 19 Jul 2010 16:28:35 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] moving to new target names, in Hudson? > > Hi Jay, > > I've learned several new things about Windows again; but in general, > I don't think we disagree very much about the options and things to do. > > I agree that config.guess might be a good short-time option for the > installation package names. > > I also agree that we could provide assembled packages for everything > like PM3 did and rely on auto-configuration for everything else. > This might be some more work for Windows though, as it uses a different > backend than all other platforms. We'd need to create completely different > Makefiles and scripts for Windows than for Unix and Unix-like systems. > Or rely on some other tooling as prerequisite (either perl, python, > Cygwin, ... you name it). I wouldn't like that very much though. > > I'm not sure yet if that would be welcome by all users and be seen > as a step forward. I wouldn't mind it though. > If it is generally accepted as a good idea, we should build up the > infrastructure for that kind of packages and installations in parallel > to what we have now. > > It would definitely not be the native Windows-installer user experience > then ;-) > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Mon Jul 19 17:04:22 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 19 Jul 2010 15:04:22 +0000 Subject: [M3devel] moving to new target names, in Hudson? In-Reply-To: <20100719144722.81DB41A208C@async.async.caltech.edu> References: , , <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com>, , <20100719090459.4CE191A2084@async.async.caltech.edu>, , <20100719110208.011521A2091@async.async.caltech.edu> , <20100719144722.81DB41A208C@async.async.caltech.edu> Message-ID: BUILD_DIR = "MIKAS_ENVIRONMENT_USING_CM3_5_8_6_WITH_THREADS_HACKS_ON_FREEBSD_4_11_I386" TARGET = "FreeBSD4" yes. I can't say I've ever done it, but it is supposed to work, and there is the profile precedent Olaf mentioned. Now, let's ask ourselves something important. Where does it ship to? Either it ships to BUILD_DIR, good, you get to rebuild everything (m3core, libm3, etc.) whenever you change BUILD_DIR. Or it ships to TARGET and my story is completely wrong. Unless we change it to BUILD_DOR. Let me see. We ship to build_dor. And I'm proposing...devil will in the details, actually doing it, seeing if it works out..if the config file sets word size (it already does, long ago), endian (I added recently), jmpbuf size... then TARGET might become even less meaningful. I think the alignments are all the same. The types are all the same, given word size. The floating point types are all the same, for now (I'm threatening to add VAX and 80bit x86 long double), but still that could be config file... then the compiler (cm3) is left knowing nothing of any predefined targets.. Currently TARGET must be from within a list the compiler knows about. BUILD_DIR is supposed to be arbitrary. The "ship no resolution" stuff has some dependency that build_dir == target, but that's ok. ?- Jay ---------------------------------------- > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] moving to new target names, in Hudson? > Date: Mon, 19 Jul 2010 07:47:22 -0700 > From: mika at async.async.caltech.edu > > > Well Jay, from the user's point of view it really doesn't matter whether > cm3 is one binary or many... BUILD_DIR has more to do with whether > the binaries that it produces can run on one platform or many. > > But from what I gather from your email, the idea seems to be that you > can have many targets in one compiler and the user of the compiler > can set BUILD_DIR himself, as he pleases? That would be wonderful... > Does it work to do that? Can I just change BUILD_DIR to, say, > > MIKAS_ENVIRONMENT_USING_CM3_5_8_6_WITH_THREADS_HACKS_ON_FREEBSD_4_11_I386 > > and have everything work for me? > > Mika > > Jay K writes: > > > >Well=2C from the compiler (cm3=2C cm3cg) and libraries (m3core/*.m3=2C etc.= > >) point of view=2C now=2C all I386_FREEBSD are the same. > >=A0They are all little endian=2C 32bit word=2C have the same jmpbuf=2C and = > >no stack walker. > >=A0(Ok=2C there's a small difference in that older FreeBSD might not have d= > >ecent enough pthreads. > >=A0 So we should really maybe have I386_FREEBSD_pthreads and I386_FREEBSD_u= > >serthreads. > >=A0=A0=A0 But this still is overkill. They are still identical in cm3 and c= > >m3cg. They vary only in m3core/*/m3makefile. > >=A0=A0 I think this is best done by making the "thread library" a variable = > >that the user can edit in config file. > >=A0=A0 And maybe gets appended to BUILD_DIR. But TARGET is unchanged.) > > > > > >Any differences or binary compatibilities aren't present until m3core/*.c #= > >includes varying headers. > >I think it makes more sense probably for people to start editing BUILD_DIR = > >in their config files. > >=A0 I386_FREEBSD1=20 > >=A0 I386_FREEBSD2=20 > >=A0 > >I386_FREEBSD3=20 > >=A0 > >I386_FREEBSD4=20 > >=A0 > >I386_FREEBSD5=20 > >=A0 > >I386_FREEBSD6=20 > >=A0 > >I386_FREEBSD7=20 > >=A0 I386_FREEBSD8 > >=A0 I386_SOLARIS2.8 =A0=20 > > > > > > > >=A0 I386_SOLARIS2.9=A0=20 > > > > > >=A0 I386_SOLARIS2.10=20 > > > > > > > >=A0 I386_SOLARIS2.11=A0=20 > > > > > > > > > >Exposing this explosion in more than maybe one directory=2C I quite dislike= > >. > >They could be config files that set BUILD_DIR=2C maybe THREAD_LIBRARY (whic= > >h I just made up) and then include(I386_FREEBSD). > >I like to think they are "configurations"=2C lightweight toplevel things=2C= > > many of them=2C that quickly devolve into a small number of "targets". > > > > > > > >Maybe what we should really=2C like=2C is run config.guess and use its enti= > >re output: i386-unknown-freebsd4.11 > >Unknown is unsightly.. Specifically for BUILD_DIR. TARGET would be somehow = > >computed from that? > > > > > > > > > >BUILD_DIR is arbitrary. See how profiling appends "p" to it? Not that I eve= > >r use that. > >Perhaps not that anyone ever has TARGET !=3D BUILD_DIR. > >=A0 Though that is how Modula-3 works for Cygwin. > > > > > >I am slowly believing in the way of autoconf and the GNU build system. It m= > >ust be observed. > >On one hand that exposes a combinatorial explosion of configurations. > >On the other=2C it avoids canonizing any particular combination as special.= > >=20 > > > > > >If cm3 were to discover jmpbuf size in some sort of autoconf-ish thing=2C a= > >nd record that merely in the config file=2C > >we'd be left with basically only four architectures in cm3: little endian32= > >=2C little endian64=2C big endian32=2C big endian64. > > > > > >Heck=2C it doesn't even need to be autoconfish. It just needs to be in the = > >config files. > >And a very small number of other things: the name of setjmp (_setjmp or set= > >jmp)=2C if there is a stack walker (usually false but sometimes true). > > > > > > > >=A0- Jay > > > >---------------------------------------- > >> To: jay.krell at cornell.edu > >> Date: Mon=2C 19 Jul 2010 04:02:07 -0700 > >> From: mika at async.async.caltech.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] moving to new target names=2C in Hudson? > >> > >> Jay K writes: > >> > > >> >The old target names are still available. > >> > > >> > > >> ... > >> > > >> >*However* notice that cm3 is *not* preconfigured/predisposed for any par= > >tic=3D > >> >ular target. > >> > >> cm3 -version prints a target... > >> > >> > > >> > > >> >It has a list of targets and it can handle any of them. The config file = > >dec=3D > >> >ides the target. > >> >=3DA0In fact=3D2C neither cm3 nor the config files are particularly know= > >ledable=3D > >> > about targets. > >> >=3DA0 The config files vary a little in how they run the compiler or lin= > >ker. > >> >=3DA0 cm3 varies mainly in word size=3D2C endianness=3D2C and jmpbuf siz= > >e. > >> >=3DA0 All the real work of knowing about targets is buried in gcc. > >> >=3DA0 And a smattering of #ifdefs in C code. Some of which could be push= > >ed to=3D > >> > autoconf. > >> > > >> > > >> >The old names confuse people -- you=3D2C for example. > >> >They are inconsistent. > >> >They don't specify processor architecture. > >> > > >> > >> Well I agree with that much.. > >> > >> > > >> >What pain did you all go through when FreeBSD changed to FreeBSD2 change= > >d t=3D > >> >o FreeBSD3 changed to FreeBSD4? > >> >Or LINUX to LINUXELF to LINUXLIBC6? > >> >So long ago nobody remembers? > >> >I used LINUXELF a little=3D2C built it=3D2C went away=3D2C came back and= > > there wa=3D > >> >s LINUXLIBC6. I had no code. It didn't matter to me. > >> > > >> > >> The point of these names=2C I thought=2C was that they were supposed to m= > >ap > >> to binary-incompatible systems. I remember having FreeBSD2 and FreeBSD3 > >> at the same time. We had a cluster with machines with both OSes=2C which > >> were not binary compatible. The point is so that you can run cm3/m3build > >> for both in the same repository (even concurrently)=2C and not have them > >> interfere with each other. It's not a pain to have different names > >> if they actually mean different things. If you just call everything > >> I386_FREEBSD all hell will break loose in that situation... (just as when > >> I by mistake run "FreeBSD4" (really FreeBSD6) CM3 in a directory where > >> I have already compiled things with "FreeBSD4" (really FreeBSD4) PM3...) > >> > >> Or am I misunderstanding something here? I would have thought you really > >> wanted to have a different name for each binary-incompatible system so > >> you can build them all in the same place. Consistency in naming would be > >> nice but I think it is secondary. > >> > >> Mika > > = From wagner at elegosoft.com Tue Jul 20 08:25:12 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 20 Jul 2010 08:25:12 +0200 Subject: [M3devel] NT386 builds fail on m3cc, was: Fwd: Re: elego-win-vm again Message-ID: <20100720082512.3ec0051v4ok8swo0@mail.elegosoft.com> It seems that current tries to build m3cc for NT386, which it shouldn't do and therefore fails. Why has this been changed? See http://hudson.modula3.com:8080/job/cm3-current-build-NT386/6/console for details. Please fix! Olaf ----- Forwarded message from michael.anderson at elego.de ----- Date: Mon, 19 Jul 2010 23:05:53 +0200 From: Michael Anderson Reply-To: Michael Anderson Subject: Re: elego-win-vm again To: Olaf Wagner Cc: manderson at elego.de, khaeusler at elego.de Quoting Olaf Wagner : > Can we somehow get that vm back online for some builds? > > http://hudson.modula3.com:8080/computer/elego-win-vm/log > Well, the vm is alive again, but the cm3-current-build-NT386 job is dying here: ... /home/elego/workspace/cm3-current-build-NT386/cm3/scripts/install-cm3-compiler.sh upgrade cp /home/elego/work/cm3-inst/wagner/current--release-build/bin/cm3.exe /home/elego/work/cm3-inst/wagner/current--release-build/bin/cm3-d5.8.2.exe cp_if: source does not exist: /home/elego/work/cm3-inst/wagner/current--release-build/bin/cm3cg Finished: FAILURE Where is cm3cg supposed to come from? > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 ----- End forwarded message ----- -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Tue Jul 20 08:51:03 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 20 Jul 2010 08:51:03 +0200 Subject: [M3devel] spin sources Message-ID: <1279608663.2648.3.camel@localhost> I tried to get them few moments ago, and download link is dead... Does anybody have them? -- Dragi?a Duri? From mark at wickensonline.co.uk Tue Jul 20 09:26:43 2010 From: mark at wickensonline.co.uk (Mark Wickens) Date: Tue, 20 Jul 2010 08:26:43 +0100 Subject: [M3devel] Just putting it out there... In-Reply-To: References: , , <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com> , , <20100719090459.4CE191A2084@async.async.caltech.edu> , , <20100719110208.011521A2091@async.async.caltech.edu> , <20100719143844.03al7scsg0g400so@mail.elegosoft.com> Message-ID: <1279610803.1935.1.camel@x60.appsoftint.co.uk> Hi guys, Has there been any discussion/moves about implementing Modula-3 as a language that runs on the Sun JVM? Seems a logical step given the similarities of Java to Modula-3 (I got that phrase the right way round, didn't I?) That is something I would definitely be able to provide help for. Regards, Mark. From mark at wickensonline.co.uk Tue Jul 20 09:33:09 2010 From: mark at wickensonline.co.uk (Mark Wickens) Date: Tue, 20 Jul 2010 08:33:09 +0100 Subject: [M3devel] Another thing Message-ID: <1279611189.1935.3.camel@x60.appsoftint.co.uk> Hi guys, I just subscribed to comp.os.modula3 and noticed the 5.8.6 release note - does the recent work on Digital Unix/tru64 platform mean that it will be promoted to an 'official' platform? Regards, Mark From jay.krell at cornell.edu Tue Jul 20 11:22:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 20 Jul 2010 09:22:39 +0000 Subject: [M3devel] Another thing In-Reply-To: <1279611189.1935.3.camel@x60.appsoftint.co.uk> References: <1279611189.1935.3.camel@x60.appsoftint.co.uk> Message-ID: Not for 5.8.6. It is already done and the changes for Mika and you are in "head". Maybe for the 5.9 release. I'm not sure the distinction matters. I don't think many people are using OSF1 any longer. You have a working system. Modulo the inefficient exception handling, like all other platforms (with one exception). Will you be using it much/long? Maybe you can try building it yourself, and then stay up to date with CVS and rebuild/test? Currently to do a "proper", "full", somewhat tested release requires recent Java 1.5 and sshd on a system. The distribution format might change or optionally change in 5.9 so we can provide a "full" albeit untested release for platforms we don't have automation on. - Jay > From: mark at wickensonline.co.uk > To: m3devel at elegosoft.com > Date: Tue, 20 Jul 2010 08:33:09 +0100 > Subject: [M3devel] Another thing > > Hi guys, > > I just subscribed to comp.os.modula3 and noticed the 5.8.6 release note > - does the recent work on Digital Unix/tru64 platform mean that it will > be promoted to an 'official' platform? > > Regards, Mark > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Jul 20 12:31:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 20 Jul 2010 10:31:31 +0000 Subject: [M3devel] some current/hudson problems? Message-ID: 1) Is cm3-current-build-target supposed to build everything, ? or not much more than the compiler? I looked at a a few (I386_OPENBSD, FreeBSD4, LINUXLIBC6) and they aren't building much more than compiler. Or is that supposed to be deferred to test-all? I was wanting to check if I386_OPENBSD hung. ? Either way, I think I have the fix. ? ? 2) cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/INSTALL' cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/fixincludes' I believe this is an artifact of cvs not working well in general. In particular, switching branches, doesn't handle deletes, or something. 3) "/home/hudson/workspace/cm3-current-test-all-pkgs-SOLgnu/ cm3/m3-db/odbc/src/m3makefile", line 4: quake runtime error: undefined variable: configure_system_libs My fault. I'll fix. ?- Jay From jay.krell at cornell.edu Tue Jul 20 12:46:47 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 20 Jul 2010 10:46:47 +0000 Subject: [M3devel] NT386 builds fail on m3cc, was: Fwd: Re: elego-win-vm again In-Reply-To: <20100720082512.3ec0051v4ok8swo0@mail.elegosoft.com> References: <20100720082512.3ec0051v4ok8swo0@mail.elegosoft.com> Message-ID: Olaf, I see what you mean in Hudson/current. I haven't compared to Hudson/release. I haven't pieced much together here as to what is going on. I do see precious few uses of FilterPackages in release or head though. Surprising. ?- Jay ---------------------------------------- > Date: Tue, 20 Jul 2010 08:25:12 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] NT386 builds fail on m3cc, was: Fwd: Re: elego-win-vm again > > It seems that current tries to build m3cc for NT386, which it shouldn't > do and therefore fails. > > Why has this been changed? > > See http://hudson.modula3.com:8080/job/cm3-current-build-NT386/6/console > for details. > > Please fix! > > Olaf > > ----- Forwarded message from michael.anderson at elego.de ----- > Date: Mon, 19 Jul 2010 23:05:53 +0200 > From: Michael Anderson > Reply-To: Michael Anderson > Subject: Re: elego-win-vm again > To: Olaf Wagner > Cc: manderson at elego.de, khaeusler at elego.de > > Quoting Olaf Wagner : > > > Can we somehow get that vm back online for some builds? > > > > http://hudson.modula3.com:8080/computer/elego-win-vm/log > > > > > Well, the vm is alive again, but the cm3-current-build-NT386 job is > dying here: > > > ... > /home/elego/workspace/cm3-current-build-NT386/cm3/scripts/install-cm3-compiler.sh > upgrade > cp /home/elego/work/cm3-inst/wagner/current--release-build/bin/cm3.exe > /home/elego/work/cm3-inst/wagner/current--release-build/bin/cm3-d5.8.2.exe > cp_if: source does not exist: > /home/elego/work/cm3-inst/wagner/current--release-build/bin/cm3cg > Finished: FAILURE > > Where is cm3cg supposed to come from? > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > > > -- > Michael Anderson > IT Services & Support > > elego Software Solutions GmbH > Gustav-Meyer-Allee 25 > Building 12.3 (BIG) room 227 > 13355 Berlin, Germany > > phone +49 30 23 45 86 96 michael.anderson at elegosoft.com > fax +49 30 23 45 86 95 http://www.elegosoft.com > > Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin > Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 > > > > > ----- End forwarded message ----- > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Tue Jul 20 13:26:42 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 20 Jul 2010 11:26:42 +0000 Subject: [M3devel] NT386 builds fail on m3cc, was: Fwd: Re: elego-win-vm again In-Reply-To: References: <20100720082512.3ec0051v4ok8swo0@mail.elegosoft.com>, Message-ID: I had churned sysinfo.sh a lot in head. With some reason -- it was confusing when ? it was defaulting stuff vs. when it was deciding stuff that should affect defaulting. I made it first decide TARGET, then decide what follows from target. It should be clearer now. There was an obvious problem though. if xFOO = BAR instead of xFOO = xBAR or FOO=BAR. And an unclear part, given my ignorance of sh, if the spaces mean anything in a case. Both fixed. We'll see. FilterPackages isn't entirely relevant. UsePackage is similar, and used. ?(I looked at the release console output to get some hints.) Thanks for the heads up, ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Date: Tue, 20 Jul 2010 10:46:47 +0000 > Subject: Re: [M3devel] NT386 builds fail on m3cc, was: Fwd: Re: elego-win-vm again > > > Olaf, I see what you mean in Hudson/current. > I haven't compared to Hudson/release. > I haven't pieced much together here as to what is going on. > I do see precious few uses of FilterPackages in release or head though. Surprising. > > - Jay > > ---------------------------------------- > > Date: Tue, 20 Jul 2010 08:25:12 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: [M3devel] NT386 builds fail on m3cc, was: Fwd: Re: elego-win-vm again > > > > It seems that current tries to build m3cc for NT386, which it shouldn't > > do and therefore fails. > > > > Why has this been changed? > > > > See http://hudson.modula3.com:8080/job/cm3-current-build-NT386/6/console > > for details. > > > > Please fix! > > > > Olaf > > > > ----- Forwarded message from michael.anderson at elego.de ----- > > Date: Mon, 19 Jul 2010 23:05:53 +0200 > > From: Michael Anderson > > Reply-To: Michael Anderson > > Subject: Re: elego-win-vm again > > To: Olaf Wagner > > Cc: manderson at elego.de, khaeusler at elego.de > > > > Quoting Olaf Wagner : > > > > > Can we somehow get that vm back online for some builds? > > > > > > http://hudson.modula3.com:8080/computer/elego-win-vm/log > > > > > > > > > Well, the vm is alive again, but the cm3-current-build-NT386 job is > > dying here: > > > > > > ... > > /home/elego/workspace/cm3-current-build-NT386/cm3/scripts/install-cm3-compiler.sh > > upgrade > > cp /home/elego/work/cm3-inst/wagner/current--release-build/bin/cm3.exe > > /home/elego/work/cm3-inst/wagner/current--release-build/bin/cm3-d5.8.2.exe > > cp_if: source does not exist: > > /home/elego/work/cm3-inst/wagner/current--release-build/bin/cm3cg > > Finished: FAILURE > > > > Where is cm3cg supposed to come from? > > > > > Olaf > > > -- > > > Olaf Wagner -- elego Software Solutions GmbH > > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > > > > > > > -- > > Michael Anderson > > IT Services & Support > > > > elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 > > Building 12.3 (BIG) room 227 > > 13355 Berlin, Germany > > > > phone +49 30 23 45 86 96 michael.anderson at elegosoft.com > > fax +49 30 23 45 86 95 http://www.elegosoft.com > > > > Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin > > Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 > > > > > > > > > > ----- End forwarded message ----- > > > > > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > > From jay.krell at cornell.edu Tue Jul 20 14:28:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 20 Jul 2010 12:28:36 +0000 Subject: [M3devel] LongrealType missed, was: Re: "FreeBSD4" false advertising In-Reply-To: References: <20100714094120.93B001A2098@async.async.caltech.edu>, <20100714114648.nhnwruh008840wso@mail.elegosoft.com>, <20100714100138.631581A2098@async.async.caltech.edu>, <20100714100525.BEE931A2096@async.async.caltech.edu>, , <20100714104312.155351A2098@async.async.caltech.edu>, <20100714125516.1mzfehgnkgcs800w@mail.elegosoft.com>, Message-ID: Mika, did this work for you? ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > CC: mika at async.caltech.edu > Subject: RE: LongrealType missed, was: Re: [M3devel] "FreeBSD4" false advertising > Date: Wed, 14 Jul 2010 11:23:49 +0000 > > > Mika, Please try updating libm3 and see if that works for you. Thanks. > > - Jay > > ---------------------------------------- > > Date: Wed, 14 Jul 2010 12:55:16 +0200 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > CC: jay.krell at cornell.edu; mika at async.caltech.edu > > Subject: LongrealType missed, was: Re: [M3devel] "FreeBSD4" false advertising > > > > Quoting Mika Nystrom : > > > > > Argh is it really necessary to break source compatibility here? > > > > > > I also don't like that I as a client have to import IEEE things when all > > > I want is "LONGREAL" (and let Modula-3 do whatever it wants with that). > > > > > > I would propose at least having an interface LongrealType with > > > > > > CONST Hash = Longreal.Hash > > > > > > etc. so as not to force clients to import all the nitty-gritty about > > > various floating point representations. And so as not to break source > > > compatibility! If I change this by removing Type, my code will no longer > > > compile with the old compilers.... > > > > Hm, I'm a little bit out of context here... > > What was the reason for this change? It seems nobody else has bothered > > so far. > > > > This was the commit in question: > > > > 2009-12-23 21:43 hosking > > > > * m3-libs/: m3core/src/m3makefile, libm3/src/types/ASCII.i3, > > libm3/src/types/ASCII.m3, libm3/src/types/Boolean.i3, > > libm3/src/types/Boolean.m3, libm3/src/types/COPYRIGHT-CMASS, > > libm3/src/types/Char.i3, libm3/src/types/Char.m3, > > libm3/src/types/Int32.i3, libm3/src/types/Int32.m3, > > libm3/src/types/Int64.i3, libm3/src/types/Int64.m3, > > libm3/src/types/Integer.i3, libm3/src/types/Integer.m3, > > libm3/src/types/Longint.i3, libm3/src/types/Longint.m3, > > libm3/src/types/LongrealType.i3, libm3/src/types/LongrealType.m3, > > libm3/src/types/RealType.i3, libm3/src/types/RealType.m3, > > libm3/src/types/Refany.i3, libm3/src/types/Refany.m3, > > libm3/src/types/Unicode.i3, libm3/src/types/Unicode.m3, > > libm3/src/types/WideChar.i3, libm3/src/types/WideChar.m3, > > libm3/src/types/m3makefile, m3core/src/float/Common/Extended.m3, > > m3core/src/float/Common/LongReal.m3, m3core/src/float/Common/Real.m3, > > m3core/src/float/IEEE/Extended.i3, m3core/src/float/IEEE/LongReal.i3, > > m3core/src/float/IEEE/Real.i3, m3core/src/float/VAX/Extended.i3, > > m3core/src/float/VAX/LongReal.i3, m3core/src/float/VAX/Real.i3: > > > > Move libm3/src/types into m3core. > > Note that LongrealType and RealType have been folded into m3core/src/float. > > Clients will need adjustment. > > > > Any comments? > > > > Olaf > > > > > Mika > > > > > > Jay K writes: > > >> > > >> Remove "Type" it appears. > > >> > > >> > > >> http://modula3.elegosoft.com/cm3/ChangeLog-2009 > > >> > > >> search for "clients will need". > > >> > > >> e.g. > > >> > > >> +++ cm3/m3-demo/mentor/src/binpack/m3makefile 2009/12/23 22:05:06 1.2 > > >> @@ -10=2C7 +10=2C7 @@ > > >> =20 > > >> import ("zeus") > > >> =20 > > >> -list ("Real"=2C "RealType") > > >> +list ("Real"=2C "Real") > > >> =20 > > >> zume ("Binpack") > > >> oblume ("Binpack"=2C "myview") > > >> > > >> --- cm3/m3-demo/mentor/src/binpack/RealList.i3 2001/01/13 14:18:20 1.1 > > >> +++ cm3/m3-demo/mentor/src/binpack/RealList.i3 2009/12/23 22:05:05 1.2 > > >> @@ -2=2C4 +2=2C4 @@ > > >> (* Distributed only by permission. *) > > >> (* Last modified on Fri Jul 9 16:36:47 PDT 1993 by mhb *) > > >> =20 > > >> -INTERFACE RealList =3D List(RealType) END RealList. > > >> +INTERFACE RealList =3D List(Real) END RealList. > > >> > > >> --- cm3/m3-demo/mentor/src/binpack/RealList.m3 2001/01/13 14:18:20 1.1 > > >> +++ cm3/m3-demo/mentor/src/binpack/RealList.m3 2009/12/23 22:05:06 1.2 > > >> @@ -2=2C4 +2=2C4 @@ > > >> (* All rights reserved. *) > > >> (* See the file COPYRIGHT for a full description. *) > > >> =20 > > >> -MODULE RealList =3D List(RealType) END RealList. > > >> +MODULE RealList =3D List(Real) END RealList. > > >> > > >> =A0- Jay > > >> > > >> ---------------------------------------- > > >>> To: wagner at elegosoft.com > > >>> CC: jay.krell at cornell.edu=3B mika at async.caltech.edu > > >>> Subject: Re: [M3devel] "FreeBSD4" false advertising > > >>> Date: Wed=2C 14 Jul 2010 03:05:25 -0700 > > >>> From: mika at async.async.caltech.edu > > >>> > > >>> I'm not actually sure I understand the intent of the changes in this area= > > >> . > > >>> > > >>> My old m3makefile has: > > >>> > > >>> Table("TextLongReal"=2C "Text"=2C "LongrealType") > > >>> > > >>> What am I supposed to use now? > > >>> > > >>> Mika > > >>> > > >>> Mika Nystrom writes: > > >>> >Olaf Wagner writes: > > >>> >>Quoting Mika Nystrom : > > >>> >> > > >>> >>> Hi Jay=2C Olaf=2C > > >>> >>> > > >>> >>> I actually built everything! After backing out some of my changes > > >>> >>> that I had tried to get 5.8.6-REL to build with=2C it worked=2C and m= > > >> entor > > >>> >>> ran=2C even. > > >>> >> > > >>> >>Great! So it's still possible to build cm3 on FreeBSD 4=2C though > > >>> >>not our release code. > > >>> > > > >>> >The differences relative to the current CVS head are very minor. > > >>> > > > >>> >1. Added FreeBSD4 to thread.quake as a non-pthread platform > > >>> > > > >>> >2. got rid of the -m32 flags in FreeBSD4.conf > > >>> > > > >>> >Everything else that needed to change I think Jay has managed to put in > > >>> >the CVS head. > > >>> > > > >>> >> > > >>> >>> But... what happened to libm3/src/types? Building my own code I get > > >>> >>> the following errors: > > >>> >>> > > >>> >>> new source -> compiling LRInterval.i3 > > >>> >>> "../FreeBSD4/LRInterval.i3 =3D3D> ../src/Interval.ig"=2C line 5: unab= > > >> le to =3D20 > > >>> >>> find interface (LongrealType) > > >>> >>> 1 error encountered > > >>> >>> > > >>> >>> I can't find LongrealType anywhere=2C do I have a broken checkout? We= > > >> ll=2C it > > >>> >>> is in one place=2C in "doc". (Same for RealType=2C maybe others?) > > >>> >> > > >>> >>See =3D20 > > >>> >>http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/t= > > >> ypes/=3D > > >>> >>Attic/LongrealType.i3 > > >>> > > > >>> >Surely this is wrong?? I am looking for an interface that has T =3D > > >>> >LONGREAL=2C not something that lets me muck around with the representati= > > >> on > > >>> >of IEEE=2C VAX=2C etc.=2C floating-point formats. > > >>> > > > >>> >Why is it even in m3core? This seems clearly like libm3 stuff.. I notice= > > >> d > > >>> >Boolean.i3 also moved. > > >>> > > > >>> >Also if there is no importable interface called LongrealType that is goi= > > >> ng > > >>> >to cause endless problems with source that is supposed to compile under > > >>> >different versions of Modula-3. Even relatively recent CM3s required > > >>> >you to use LongrealType to instantiate generics. > > >>> > > > >>> > Mika > > >> = > > > > > > > > > > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 m3 at sol42.com Tue Jul 20 14:28:45 2010 From: m3 at sol42.com (m3 at sol42.com) Date: Tue, 20 Jul 2010 14:28:45 +0200 Subject: [M3devel] spin sources In-Reply-To: <1279608663.2648.3.camel@localhost> References: <1279608663.2648.3.camel@localhost> Message-ID: <27F80E57-716A-47ED-95DE-A73B51E580ED@sol42.com> Hello. I have spin-33.2.tar.gz from many many years ago. It is now available at http://www.sol42.com/spin-33.2.tar.gz Its size is 27.675.835 bytes compressed, 119.961.600 uncompressed. MD5 (spin-33.2.tar.gz) = 8fcd9457f1298eaef8819a21ab931712 GNU tar complains about zero data at the end of the archive, Solaris tar just stops there. Hopefully nothing is missing. Regards. -Daniel From wagner at elegosoft.com Tue Jul 20 14:48:14 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 20 Jul 2010 14:48:14 +0200 Subject: [M3devel] some current/hudson problems? In-Reply-To: References: Message-ID: <20100720144814.p091gtc6g0kggwwg@mail.elegosoft.com> Quoting Jay K : > 1) > Is cm3-current-build-target supposed to build everything, > ? or not much more than the compiler? > > I looked at a a few (I386_OPENBSD, FreeBSD4, LINUXLIBC6) and they > aren't building much more than compiler. Just the core system and perform an `upgrade' if needed. > Or is that supposed to be deferred to test-all? cm3-current-test-all-pkgs will build everything and perform all associated regression tests. If will also write reports in XML and HTML format. > I was wanting to check if I386_OPENBSD hung. > ? Either way, I think I have the fix. > ? > 2) > cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/INSTALL' > cvs update: use `cvs add' to create an entry for > `m3-sys/m3cc/gcc/fixincludes' > > I believe this is an artifact of cvs not working well in general. > In particular, switching branches, doesn't handle deletes, or something. Probably some confused workspace entries; should not be critical. > 3) > "/home/hudson/workspace/cm3-current-test-all-pkgs-SOLgnu/ > cm3/m3-db/odbc/src/m3makefile", line 4: quake runtime error: > undefined variable: > configure_system_libs > > My fault. I'll fix. Fine. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Jul 20 15:26:33 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 20 Jul 2010 09:26:33 -0400 Subject: [M3devel] Just putting it out there... In-Reply-To: <1279610803.1935.1.camel@x60.appsoftint.co.uk> References: , , <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com> , , <20100719090459.4CE191A2084@async.async.caltech.edu> , , <20100719110208.011521A2091@async.async.caltech.edu> , <20100719143844.03al7scsg0g400so@mail.elegosoft.com> <1279610803.1935.1.camel@x60.appsoftint.co.uk> Message-ID: Running Modula-3 on the Sun JVM poses several difficulties, not least that Modula-3 is a systems programming language like C/C++. Getting C, C++, or Modula-3 to run on the JVM would all be the same level of difficulty. The safe subset of Modula-3 would be less difficult, but the unsafe operations would probably be a showstopper. On the other hand, at one point there was a version of Java running in the Modula-3 run-time. On 20 Jul 2010, at 03:26, Mark Wickens wrote: > Hi guys, > > Has there been any discussion/moves about implementing Modula-3 as a > language that runs on the Sun JVM? > > Seems a logical step given the similarities of Java to Modula-3 (I got > that phrase the right way round, didn't I?) > > That is something I would definitely be able to provide help for. > > Regards, Mark. From mark at wickensonline.co.uk Tue Jul 20 15:36:50 2010 From: mark at wickensonline.co.uk (Mark Wickens) Date: Tue, 20 Jul 2010 14:36:50 +0100 Subject: [M3devel] Just putting it out there... In-Reply-To: References: , , <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com> , , <20100719090459.4CE191A2084@async.async.caltech.edu> , , <20100719110208.011521A2091@async.async.caltech.edu> , <20100719143844.03al7scsg0g400so@mail.elegosoft.com> <1279610803.1935.1.camel@x60.appsoftint.co.uk> Message-ID: <1279633010.1935.11.camel@x60.appsoftint.co.uk> Tony, Yes, after I'd written the email and thought about it I realised it was a pretty stupid idea. Mark. On Tue, 2010-07-20 at 09:26 -0400, Tony Hosking wrote: > Running Modula-3 on the Sun JVM poses several difficulties, not least that Modula-3 is a systems programming language like C/C++. Getting C, C++, or Modula-3 to run on the JVM would all be the same level of difficulty. The safe subset of Modula-3 would be less difficult, but the unsafe operations would probably be a showstopper. On the other hand, at one point there was a version of Java running in the Modula-3 run-time. > > On 20 Jul 2010, at 03:26, Mark Wickens wrote: > > > Hi guys, > > > > Has there been any discussion/moves about implementing Modula-3 as a > > language that runs on the Sun JVM? > > > > Seems a logical step given the similarities of Java to Modula-3 (I got > > that phrase the right way round, didn't I?) > > > > That is something I would definitely be able to provide help for. > > > > Regards, Mark. > From jay.krell at cornell.edu Tue Jul 20 15:39:46 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 20 Jul 2010 13:39:46 +0000 Subject: [M3devel] merging gdb from 6.4 to 7.1? Message-ID: The merge of m3cc/gcc from 4.3.0 to 4.3.5 went well enough. I'll volunteer to merge m3gdb from 6.4 to 7.1. Are people interested? I saw some mention of 6.4.3 in our history. But there's no release called that. What is it? Some of the conflicts are about? SYMBOL_TYP vs. LHS_SYMBOL_TYPE. What that a deliberate important change on our port? Thanks, ?- Jay From m3 at sol42.com Tue Jul 20 16:14:30 2010 From: m3 at sol42.com (m3 at sol42.com) Date: Tue, 20 Jul 2010 16:14:30 +0200 Subject: [M3devel] Just putting it out there... In-Reply-To: <1279633010.1935.11.camel@x60.appsoftint.co.uk> References: , , <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com> , , <20100719090459.4CE191A2084@async.async.caltech.edu> , , <20100719110208.011521A2091@async.async.caltech.edu> , <20100719143844.03al7scsg0g400so@mail.elegosoft.com> <1279610803.1935.1.camel@x60.appsoftint.co.uk> <1279633010.1935.11.camel@x60.appsoftint.co.uk> Message-ID: On 20 Jul 2010, at 15:36, Mark Wickens wrote: > Yes, after I'd written the email and thought about it I realised it was > a pretty stupid idea. Well, not stupid at all. Java may suck but the JVM certainly does not. There is a lot of interest now in compiling languages other than Java on the JVM, which has turned out to be a sort of universal runtime. Only that it was designed with Java in mind, and you would end up with something *like* Modula-3, not Modula-3 itself: what you can do in JVM "assembly" is limited, no PACKED types, no BITS x FOR y .. z, LOOPHOLE may or may not be always possible, UNTRACED would be problematic, pointer arithmetic in UNSAFE modules might require JNI and who knows what else, forget about <*EXTERNAL*> C calls, full interoperability with Java would require supporting Java interfaces (at the language level I think)... and these are just the few I can think of right now. On the other hand I would really like to code in this superset-of-a-subset of Modula-3 and run it on a JVM. Regarding the Critical Mass JVM described in Threads 3, are the sources available? Regards. -Daniel From dabenavidesd at yahoo.es Tue Jul 20 16:17:02 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 20 Jul 2010 14:17:02 +0000 (GMT) Subject: [M3devel] Just putting it out there... In-Reply-To: Message-ID: <562804.32217.qm@web23606.mail.ird.yahoo.com> Hi all: Its interesting that after all, being Modula-3 a systems programming language any of its unsafe features are still as it is written in Modula-3 itself no harm to the Modula-3 runtime itself you can isolate the unsafe features to allow pretty clean representation of the system. Java had from the beginning an unsafe feature (not sure what it looks today) for type checking unsound with respect to its static semantics a type rule of array of objects subtyping, but they cleaned the missing check in the JVM as a runtime error. Original JVM M3 implementation had a C based interface to it so you could run things in the native part of a Java execution using Modula-3 runtime fetures which doesn't allow messing with the safe modules but they can play with it. In the other hand SPIN had some small extensions to allow type checking of some extra type rules to allow dynamic conversions in a safe way. It allows a little bit of extra freedom. So both solutions could create a space for executing, for handling unsafe features to pass under safe threshold. Hope it helps --- El mar, 20/7/10, Tony Hosking escribi?: > De: Tony Hosking > Asunto: Re: [M3devel] Just putting it out there... > Para: "Mark Wickens" > CC: "m3devel" > Fecha: martes, 20 de julio, 2010 08:26 > Running Modula-3 on the Sun JVM poses > several difficulties, not least that Modula-3 is a systems > programming language like C/C++. Getting C, C++, or > Modula-3 to run on the JVM would all be the same level of > difficulty. The safe subset of Modula-3 would be less > difficult, but the unsafe operations would probably be a > showstopper. On the other hand, at one point there was > a version of Java running in the Modula-3 run-time. > > On 20 Jul 2010, at 03:26, Mark Wickens wrote: > > > Hi guys, > > > > Has there been any discussion/moves about implementing > Modula-3 as a > > language that runs on the Sun JVM? > > > > Seems a logical step given the similarities of Java to > Modula-3 (I got > > that phrase the right way round, didn't I?) > > > > That is something I would definitely be able to > provide help for. > > > > Regards, Mark. > > From rodney_bates at lcwb.coop Tue Jul 20 17:20:38 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 20 Jul 2010 10:20:38 -0500 Subject: [M3devel] merging gdb from 6.4 to 7.1? In-Reply-To: References: Message-ID: <4C45BEC6.40603@lcwb.coop> I have been thinking about doing this myself for some time, but up to now, have not had the time. I can certainly help, if you want to do it, or maybe take it on myself. I think I will be having more time soon. I have done it a couple of times before. A few things can be hard to figure out, because they rework existing stuff in gdb and it's hard to dig out what the new equivalent of the old mechanism is. A lot of the M3-specific code I either heavily modified or wrote. Jay K wrote: > The merge of m3cc/gcc from 4.3.0 to 4.3.5 went well enough. > > I'll volunteer to merge m3gdb from 6.4 to 7.1. BTW, there is now or will be very soom, a 7.2 gdb. Also, the latest gdb does reverse debugging, by recording snapshots during the forward run. This would be a *very* nice feature to have for Modula-3. > > Are people interested? > > I saw some mention of 6.4.3 in our history. > But there's no release called that. > What is it? I don't remember anything about this. > > Some of the conflicts are about SYMBOL_TYP vs. LHS_SYMBOL_TYPE. > What that a deliberate important change on our port? Yes, this is my change, very deliberate, and gets around a nasty group of dangling pointer bugs. I would have to took at it again, but it used to cache a pointer to a gdb type struct, lazily looked- up the first time, right into an existing field of another gdb struct. When you rerun, gdb reloads the referent structs of such pointers, leaving them dangling. Or maybe I am mixing up two different problems. Anyway, the two macros are essential. I have long thought it might be nice to design a better mechanism, but it's not simple. I strongly recommend not messing with it during merging to a newer gdb. Save that for a subsequent job with a separate CVS tag. It's only a performance matter, and except for debugging work that proceeds without requiring user-types commands all the time, it scarcely matters. Also, we would be a lot better off to dump stabs+ and use whatever latest version of dwarf that gdb already has support for. But that is also a job that should be done separately, with its own tag, after a new merge is working with the existing mechanisms. > > Thanks, > - Jay > > > > > From dabenavidesd at yahoo.es Tue Jul 20 22:13:01 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 20 Jul 2010 20:13:01 +0000 (GMT) Subject: [M3devel] merging gdb from 6.4 to 7.1? In-Reply-To: <4C45BEC6.40603@lcwb.coop> Message-ID: <192662.96738.qm@web23608.mail.ird.yahoo.com> Hi all: Is it possible to include in the m3gdb support for remote debugging like the one introduced by the developers in SPIN (which was based on DEC Firefly teledebug protocol called TTD see doi:10.1145/68210.69219 see doi.org), it is a protocol to remotely debug a target program but in such a case you have the post-mortem abilities is that hard to ask for doing it remotely, though TDD it was implemented for debugging the operating system itself it could be if I'm not wrong easier to debug from a type terminal remotely than in the cellphone or tablet it self when such a target is available for any application. Postmortem would be even nicer since there is general support in high-end cellphones which seem to be a ever increasing range of platforms and operating system versions and vendors. Other version of TTD protocol was used in the ldb debugger, this allowed even to disconnect and connect from cross-platform debugging to target and provide services for the stack walking between other issues its dependence in lcc's c compiler though will it be possible to replace it for an intermediate representation like the one of Modula-3 I just see possible for the m3tk toolkit to do it since support for it would be a nice feature for its debugging features the porting of the M3CG assembly machine language for the lcc framework would be possible, there is support on it for targeting even the CLI .Net framework so it would be good to ask if it isn't too hard to do it for a good reason to do it to host M3CG. Thanks in advance --- El mar, 20/7/10, Rodney M. Bates escribi?: > De: Rodney M. Bates > Asunto: Re: [M3devel] merging gdb from 6.4 to 7.1? > Para: "m3devel" > Fecha: martes, 20 de julio, 2010 10:20 > I have been thinking about doing this > myself for some time, but up to > now, have not had the time. I can certainly help, if > you want to do it, > or maybe take it on myself. I think I will be having > more time soon. > I have done it a couple of times before. A few things > can be hard to > figure out, because they rework existing stuff in gdb and > it's hard to > dig out what the new equivalent of the old mechanism > is. A lot of the > M3-specific code I either heavily modified or wrote. > > Jay K wrote: > > The merge of m3cc/gcc from 4.3.0 to 4.3.5 went well > enough. > > > > I'll volunteer to merge m3gdb from 6.4 to 7.1. > > BTW, there is now or will be very soom, a 7.2 gdb. > Also, the latest gdb does reverse debugging, by recording > snapshots during the forward run. This would be a > *very* > nice feature to have for Modula-3. > > > > > > Are people interested? > > > > I saw some mention of 6.4.3 in our history. > > But there's no release called that. > > What is it? > > I don't remember anything about this. > > > > > Some of the conflicts are about SYMBOL_TYP vs. > LHS_SYMBOL_TYPE. > > What that a deliberate important change on our port? > > Yes, this is my change, very deliberate, and gets around a > nasty > group of dangling pointer bugs. I would have to took > at it again, > but it used to cache a pointer to a gdb type struct, lazily > looked- > up the first time, right into an existing field of another > gdb struct. > When you rerun, gdb reloads the referent structs of such > pointers, > leaving them dangling. Or maybe I am mixing up two > different > problems. Anyway, the two macros are essential. > > I have long thought it might be nice to design a better > mechanism, > but it's not simple. I strongly recommend not messing > with it during > merging to a newer gdb. Save that for a subsequent > job with a separate > CVS tag. It's only a performance matter, and except > for debugging work > that proceeds without requiring user-types commands all the > time, it > scarcely matters. > > Also, we would be a lot better off to dump stabs+ and use > whatever > latest version of dwarf that gdb already has support > for. But that > is also a job that should be done separately, with its own > tag, after > a new merge is working with the existing mechanisms. > > > > > > Thanks, > > - Jay > > > > > > > > > > > > > From jay.krell at cornell.edu Wed Jul 21 04:58:47 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 21 Jul 2010 02:58:47 +0000 Subject: [M3devel] merging gdb from 6.4 to 7.1? In-Reply-To: <4C45BEC6.40603@lcwb.coop> References: , <4C45BEC6.40603@lcwb.coop> Message-ID: Thanks. To be clear then, my initial merge will likely lose some changes, it sounds like you are ok with that, and they can be redone soon thereafter by someone else (e.g. you). I'll be sure it builds and do a minimum of debugging with it. I'll expect it to understand some Modula-3 syntax and esp. decode types. When I use gdb everything is void* so there should be obvious improvement with m3gdb. I'm not sure what the best way to "help" is. I'm not super keen on "sharing diffs" or using branches. Therefore, come up with something reasonable maybe slightly flawed, commit it, someone else can improve it afterward, as long as the initial one isn't too flawed? ok? ok? There is some use of $revision$ and $id$ in there and it makes things slightly messy. There are files we didn't change, but which show as changed because of them. Mostly deleted stuff like hpread.c and the rdi-shared directory. Or we added comments in dwarfread.c which was deleted. I agree -gstabs might not be best. It isn't supported on e.g. HP64_HPUX. But often whenever I try other options like -g or -gcoff or -ggdb or -gdwarf, I get crashes in the backend so I leave the config files with -gstabs+. :( I don't think it matters too much what I merge up to, as long as it is >6.4. 7.1 is out. I didn't see 7.2. Thanks, - Jay > Date: Tue, 20 Jul 2010 10:20:38 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] merging gdb from 6.4 to 7.1? > > I have been thinking about doing this myself for some time, but up to > now, have not had the time. I can certainly help, if you want to do it, > or maybe take it on myself. I think I will be having more time soon. > I have done it a couple of times before. A few things can be hard to > figure out, because they rework existing stuff in gdb and it's hard to > dig out what the new equivalent of the old mechanism is. A lot of the > M3-specific code I either heavily modified or wrote. > > Jay K wrote: > > The merge of m3cc/gcc from 4.3.0 to 4.3.5 went well enough. > > > > I'll volunteer to merge m3gdb from 6.4 to 7.1. > > BTW, there is now or will be very soom, a 7.2 gdb. > Also, the latest gdb does reverse debugging, by recording > snapshots during the forward run. This would be a *very* > nice feature to have for Modula-3. > > > > > > Are people interested? > > > > I saw some mention of 6.4.3 in our history. > > But there's no release called that. > > What is it? > > I don't remember anything about this. > > > > > Some of the conflicts are about SYMBOL_TYP vs. LHS_SYMBOL_TYPE. > > What that a deliberate important change on our port? > > Yes, this is my change, very deliberate, and gets around a nasty > group of dangling pointer bugs. I would have to took at it again, > but it used to cache a pointer to a gdb type struct, lazily looked- > up the first time, right into an existing field of another gdb struct. > When you rerun, gdb reloads the referent structs of such pointers, > leaving them dangling. Or maybe I am mixing up two different > problems. Anyway, the two macros are essential. > > I have long thought it might be nice to design a better mechanism, > but it's not simple. I strongly recommend not messing with it during > merging to a newer gdb. Save that for a subsequent job with a separate > CVS tag. It's only a performance matter, and except for debugging work > that proceeds without requiring user-types commands all the time, it > scarcely matters. > > Also, we would be a lot better off to dump stabs+ and use whatever > latest version of dwarf that gdb already has support for. But that > is also a job that should be done separately, with its own tag, after > a new merge is working with the existing mechanisms. > > > > > > Thanks, > > - Jay > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ttmrichter at gmail.com Wed Jul 21 12:40:55 2010 From: ttmrichter at gmail.com (Michael Richter) Date: Wed, 21 Jul 2010 18:40:55 +0800 Subject: [M3devel] spin sources In-Reply-To: <27F80E57-716A-47ED-95DE-A73B51E580ED@sol42.com> References: <1279608663.2648.3.camel@localhost> <27F80E57-716A-47ED-95DE-A73B51E580ED@sol42.com> Message-ID: OK, Daniel, this is seriously cool! I've been trying to find SPIN source for a while now. On 20 July 2010 20:28, wrote: > Hello. I have spin-33.2.tar.gz from many many years ago. > > It is now available at http://www.sol42.com/spin-33.2.tar.gz > Its size is 27.675.835 bytes compressed, 119.961.600 uncompressed. > MD5 (spin-33.2.tar.gz) = 8fcd9457f1298eaef8819a21ab931712 > > GNU tar complains about zero data at the end of the archive, Solaris tar > just stops there. Hopefully nothing is missing. > > Regards. > -Daniel -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Jul 21 18:57:00 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 21 Jul 2010 16:57:00 +0000 Subject: [M3devel] Alpha/OSF exception handling In-Reply-To: References: , , , Message-ID: It doesn't seem to "just work". Will require some debugging. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Mon, 19 Jul 2010 07:31:22 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Alpha/OSF exception handling > > > I didn't "remove" it, but I did "disable" it. Similar. > I didn't want to have to spend any time debugging it if it didn't work any longer. > I'm sure we have precious few users of this system (2 this month though, quite a surge) and they can probably live with > an equally bad implementation as all the other platforms (except for Solaris/sparc). > Granted, they have slower than average systems, would benefit more perhaps from the optimization. > > We can try it out I guess. > > I do hope we can improve this across the aboard. > Even if we don't use the tree exception handling nodes, we can probably at least use the same runtime support (libunwind in libgcc). > Even then, Alpha/OSF won't be important. > > - Jay > > ---------------------------------------- > > From: hosking at cs.purdue.edu > > Date: Sun, 18 Jul 2010 14:22:41 -0400 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Alpha/OSF exception handling > > > > That is a huge shame. Why did you remove it? It used to be there and functional. > > > > On 18 Jul 2010, at 09:35, Jay K wrote: > > > > > > > > Modula-3 for ALPHA_OSF historically had the best exception handling implementation. > > > > > > With Solaris/sparc32 second best. > > > > > > And then everything else equally bad. > > > > > > > > > > > > > > > > > > The current Alpha/osf is now in the "equally bad" category. > > > Because I'm lazy. > > > > > > It might be worth restoring its former glory. > > > > > > > > > > > > Maybe a small project for someone? > > > > > > > > > The code is still in there. I just tweaked the m3makefiles to avoid trying it. > > > > > > > > > jbook2:runtime jay$ pwd > > > /dev2/cm3/m3-libs/m3core/src/runtime > > > jbook2:runtime jay$ find ALPHA_OSF > > > ALPHA_OSF/m3makefile-old > > > > > > Renaming that m3makefile. > > > > > > Fiddling with this: > > > > > > book2:runtime jay$ grep STACK * > > > m3makefile:readonly HAS_STACK_WALKER = { > > > m3makefile:if defined("M3_USE_STACK_WALKER") > > > m3makefile: if M3_USE_STACK_WALKER and HAS_STACK_WALKER contains TARGET > > > m3makefile: if HAS_STACK_WALKER{TARGET} > > > > > > > > > and this: > > > > > > > > > jbook2:src jay$ pwd > > > /dev2/cm3/m3-sys/m3middle/src > > > > > > > > > book2:src jay$ grep -i _stack *m3 > > > Target.m3: Has_stack_walker := FALSE; > > > Target.m3: Has_stack_walker := TRUE; > > > > > > > > > - Jay > > > > > > From rcolebur at SCIRES.COM Wed Jul 21 20:52:05 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Wed, 21 Jul 2010 14:52:05 -0400 Subject: [M3devel] compiler version number Message-ID: I grabbed the minimal 5.8.6 archive for Windows. Using this archive, "cm3 -version" yields: Critical Mass Modula-3 version 5.8.6 last updated: 2010-04-11 compiled: 2010-07-12 21:11:13 configuration: .\cm3.cfg host: NT386 target: NT386 But, when I use this edition to rebuild everything from the main trunk, "cm3 -version" now yields: Critical Mass Modula-3 version d5.8.2 last updated: 2009-07-15 compiled: 2010-07-21 17:29:53 configuration: C:\cm3\bin\cm3.cfg host: NT386 defaulting to native build: I386_NT target: I386_NT Can someone please explain how the version number and timestamp info get integrated into the compiler? If I can get a handle on the way it's currently done, I'll try to fix the problem I'm having on Windows with the info regressing. Regards, Randy Coleburn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Jul 21 22:31:42 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 21 Jul 2010 20:31:42 +0000 Subject: [M3devel] compiler version number In-Reply-To: References: Message-ID: It's working on Windows. jbook2:~ jay$ cat /dev2/cm3/scripts/version.quake CM3VERSION = "d5.8.2" CM3VERSIONNUM = "050802" CM3LASTCHANGED = "2009-07-15" jbook2:~ jay$ cat /dev2/cm3/scripts/version CM3VERSION d5.8.2 CM3VERSIONNUM 050802 CM3LASTCHANGED 2009-07-15 ?- Jay ________________________________ > From: rcolebur at SCIRES.COM > To: m3devel at elegosoft.com > Date: Wed, 21 Jul 2010 14:52:05 -0400 > Subject: [M3devel] compiler version number > > > I grabbed the minimal 5.8.6 archive for Windows. > > > > Using this archive, ?cm3 ?version? yields: > > > > Critical Mass Modula-3 version 5.8.6 > > last updated: 2010-04-11 > > compiled: 2010-07-12 21:11:13 > > configuration: .\cm3.cfg > > host: NT386 > > target: NT386 > > > > But, when I use this edition to rebuild everything from the main trunk, > ?cm3 ?version? now yields: > > > > Critical Mass Modula-3 version d5.8.2 > > last updated: 2009-07-15 > > compiled: 2010-07-21 17:29:53 > > configuration: C:\cm3\bin\cm3.cfg > > host: NT386 > > defaulting to native build: I386_NT > > target: I386_NT > > > > Can someone please explain how the version number and timestamp info > get integrated into the compiler? > > > > If I can get a handle on the way it?s currently done, I?ll try to fix > the problem I?m having on Windows with the info regressing. > > > > Regards, > > Randy Coleburn > > From wagner at elegosoft.com Wed Jul 21 22:42:36 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 21 Jul 2010 22:42:36 +0200 Subject: [M3devel] compiler version number In-Reply-To: References: Message-ID: <20100721224236.7jkk3bregwk4w8o8@mail.elegosoft.com> Quoting "Coleburn, Randy" : > I grabbed the minimal 5.8.6 archive for Windows. > > Using this archive, "cm3 -version" yields: > > Critical Mass Modula-3 version 5.8.6 > last updated: 2010-04-11 > compiled: 2010-07-12 21:11:13 > configuration: .\cm3.cfg > host: NT386 > target: NT386 > > But, when I use this edition to rebuild everything from the main > trunk, "cm3 -version" now yields: > > Critical Mass Modula-3 version d5.8.2 > last updated: 2009-07-15 > compiled: 2010-07-21 17:29:53 > configuration: C:\cm3\bin\cm3.cfg > host: NT386 > defaulting to native build: I386_NT > target: I386_NT > > Can someone please explain how the version number and timestamp info > get integrated into the compiler? > > If I can get a handle on the way it's currently done, I'll try to > fix the problem I'm having on Windows with the info regressing. You're right, it's still wrong on the trunk. I've only cared for the release branch during the recent months, but I've just checked in a fix: % cvs -q diff -u Index: version =================================================================== RCS file: /usr/cvs/cm3/scripts/version,v retrieving revision 1.5 diff -u -u -r1.5 version --- version 15 Jul 2009 06:14:01 -0000 1.5 +++ version 21 Jul 2010 20:39:06 -0000 @@ -1,3 +1,3 @@ -CM3VERSION d5.8.2 -CM3VERSIONNUM 050802 -CM3LASTCHANGED 2009-07-15 +CM3VERSION d5.9.0 +CM3VERSIONNUM 050900 +CM3LASTCHANGED 2010-07-21 Index: version.quake =================================================================== RCS file: /usr/cvs/cm3/scripts/version.quake,v retrieving revision 1.1 diff -u -u -r1.1 version.quake --- version.quake 13 Apr 2010 11:14:22 -0000 1.1 +++ version.quake 21 Jul 2010 20:39:06 -0000 @@ -1,3 +1,3 @@ -CM3VERSION = "d5.8.2" -CM3VERSIONNUM = "050802" -CM3LASTCHANGED = "2009-07-15" +CM3VERSION = "d5.9.0" +CM3VERSIONNUM = "050900" +CM3LASTCHANGED = "2010-07-21" luthien [/d/home/wagner/work/cm3/scripts] wagner % cvs commit -m 'fix version number on trunk for 5.9 development' c/usr/cvs/cm3/scripts/version,v <-- version new revision: 1.6; previous revision: 1.5 /usr/cvs/cm3/scripts/version.quake,v <-- version.quake new revision: 1.2; previous revision: 1.1 All scripts should pick up the version from those files. Thanks for the hint, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Jul 22 16:25:06 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 22 Jul 2010 14:25:06 +0000 Subject: [M3devel] Hudson updating config files or not In-Reply-To: References: <20100721155314.E1BC6CC389@birch.elegosoft.com>, , , , <20100722085323.0nmmjnom94osso88@mail.elegosoft.com>, , <20100722091912.bibr9p0z1q88wog4@mail.elegosoft.com>, Message-ID: I'm not sure, but here is some analysis. In the release hudson tasks, we have http://hudson.modula3.com:8080/view/SOLgnu/job/cm3-release-build-SOLgnu/110/consoleFull and http://hudson.modula3.com:8080/view/SOLgnu/job/cm3-build-SOLgnu/163/console "build" and "release-build". I think these are, like, "build from last release" and "build from latest successful build". I'm not sure what they do, but instead of fighting over installs and CVS trees, they should perhaps just each maintain their own. That way, e.g., they could both update config files. ? Well, except if we are low on diskspace, which we are. And it is a defficiency of the system to put outputs in the source tree. ? We should be able to ge by with one source tree per node, and all outputs should go elsewhere, including the PGS files and ? including those install.sh that get generated. The source tree should never be written to, as an option at least. Anyway. In regression/defs.sh I believe they go here: test_build_current ... ? if [ "$1" = "rel" ]; then?? # This is the important recurring thing that makes things different? ? ? "release" goes here, "build" does not ? This path does update config files. ? ? ??? echo " === clean up before cm3 upgrade " ??? if [ -z "$NOCLEAN" ]; then ????? OMIT_GCC=yes ./scripts/do-cm3-core.sh realclean || exit 1 ????? ./scripts/do-pkg.sh realclean cminstall ??? fi ??? echo " === perform cm3 upgrade " ??? UPGRADE_CM3_CFG=yes ./scripts/upgrade.sh || exit 1 ??? echo " >>> OK build_${1}_upgrade ${DS} ${WS}" ? fi and then: ? echo " === build ${BSET} system with current compiler" ? BUILDSCRIPT="./scripts/do-cm3-${BSET}.sh" ? if [ "$1" = "rel" ]; then?? # This is the important recurring thing that makes things different? ??? if [ -z "$NOCLEAN" ]; then ????? OMIT_GCC=yes ./scripts/do-cm3-core.sh realclean || exit 1 ??? fi ? else ??? if [ -z "$NOCLEAN" ]; then ????? $BUILDSCRIPT realclean || exit 1 ??? fi ? fi ? $BUILDSCRIPT buildship || exit 1 or, oh no, now I'm confused, here?: test_build_system ? test_build_system and test_build_current are very similar! Confusing?! ? ? echo " === build core system with current compiler" ? BUILDSCRIPT="./scripts/do-cm3-core.sh" ? if [ -z "$NOCLEAN" ]; then ??? $BUILDSCRIPT realclean || exit 1 ? fi ? if $BUILDSCRIPT build; then ??? echo " >>> OK build_system ${DS} ${WS}; now rebuild and ship" ??? $BUILDSCRIPT buildship ??? echo " === install new compiler" ??? ????? This is what we are running for head, I think. ????? Historically it didn't touch config files. ????? This is what I changed a day or so ago, to update them. ??? if ./scripts/install-cm3-compiler.sh upgrade; then ????? echo "compiler upgraded successfully" ????? cm3 -version ??? else ????? echo "compiler upgrade failed" 1>&2 ????? exit 1 ??? fi ? else ? ??? There is this which will update config files, but only if the previous fails. ??? echo " === perform cm3 upgrade after cleaning everything" ??? $BUILDSCRIPT realclean || exit 1 ??? UPGRADE_CM3_CFG=yes ./scripts/upgrade.sh || exit 1 ??? echo " >>> OK build_upgrade ${DS} ${WS}" ? fi Anyway, it is confusing, release has a pair of tasks and only some paths updated config files, even if other/more/different paths update the compiler. I think: ? - we want the pairs of tasks, at least for testing coverage ? - or, I guess, just build from previous release ??? which can be constraining, it is a policy issue ? - whichever tasks we have, we should have config file updating ? - tangentially: we should get all outputs, *all* outouts out of the source tree ???? The original design was nice, get outputs "per package" outside of source, ???? but it failed to address a multi-package tree. This is a big change I'm proposing. ???? I guess another mail on the topic. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > CC: m3commit at elegosoft.com > Subject: RE: [M3commit] CVS Update: cm3 > Date: Thu, 22 Jul 2010 07:21:33 +0000 > > > (ps: the change I made does do the backup foo-date thing, parallel to cm3 and cm3cg > yes I'll compare the branches, can't promise a full merge though) > > > ---------------------------------------- > > Date: Thu, 22 Jul 2010 09:19:12 +0200 > > From: wagner at elegosoft.com > > To: jay.krell at cornell.edu > > CC: m3commit at elegosoft.com > > Subject: Re: [M3commit] CVS Update: cm3 > > > > I can live with a cm3-local.cfg file which gets included when it exists, > > contains local overrides and is never touched by he installation. > > > > We have to be careful to backup existing configs and informing the > > users before the installation though. > > > > I think upgrade did backups of the config, too. > > > > Can you check the scripts in the release branch if anything needs > > to be merged back? I won't be able to do that today. > > > > Olaf > > > > Quoting Jay K : > > > > > I thought it was too, before I looked at it. > > > Could be that head and release are very divergent. > > > I didn't look at release, oops. > > > I probably will "soon". > > > > > > > > > The config files are "partly part of the compiler", and partly > > > system-specific. > > > So they might have to be updated with the compiler. > > > > > > > > > Perhaps we can have cm3.cfg.user or cm3.cfg.local, that we never edit, > > > and maybe we should constrain it, like very line > > > must have an equals sign, and if it has a percent, percent must > > > follow equals. > > > > > > > > > e.g. > > > m3back_flags = "-custom" > > > SYSTEM_CC = "custom" % comment blah blah > > > SYSTEM_LIBS{"LIBC"} = "custom" > > > SYSTEM_LIBORDER += [custom] > > > > > > But that might not be flexible enough. > > > > > > Another option is that cm3.cfg file do like: > > > if exists("cm3.cfg.user.first") > > > include("cm3.cfg.user.first") > > > end > > > ... > > > if exists("cm3.cfg.user.last") > > > > > > include("cm3.cfg.user.last > > > > > > end > > > > > > > > > > > > which is infinitely flexible and not well defined. > > > Even limiting to assignments is not well defined. > > > You know, there's an interface somewhere in there, but it isn't > > > well specified. My fault. > > > I let things evolve and get discovered gradually, sometimes hard > > > to know ahead of time what the result will be. > > > > > > > > > I've made changes since 5.8.6 released such that config files from > > > prior to 5.8.6 will not suffice. > > > I can undo that, but there is an important policy and architecture question. > > > > > > > > > - Jay > > > > > > ---------------------------------------- > > >> Date: Thu, 22 Jul 2010 08:53:23 +0200 > > >> From: wagner at elegosoft.com > > >> To: m3commit at elegosoft.com > > >> Subject: Re: [M3commit] CVS Update: cm3 > > >> > > >> Quoting Jay K : > > >> > > >> > I've manually updated the config files on SPARC32_LINUX Hudson node > > >> > to try to fix this. > > >> > > >> That should be done by the upgrade script (and it already was AFAIR). > > >> I wouldn't like the script shipping a newly built compiler to > > >> unconditionally overwrite all my local configuration. > > >> > > >> Olaf > > >> > > >> > > > >> > - Jay > > >> > > > >> > ---------------------------------------- > > >> >> Date: Wed, 21 Jul 2010 17:53:14 +0000 > > >> >> To: m3commit at elegosoft.com > > >> >> From: jkrell at elego.de > > >> >> Subject: [M3commit] CVS Update: cm3 > > >> >> > > >> >> CVSROOT: /usr/cvs > > >> >> Changes by: jkrell at birch. 10/07/21 17:53:14 > > >> >> > > >> >> Modified files: > > >> >> cm3/scripts/: install-cm3-compiler.sh > > >> >> > > >> >> Log message: > > >> >> upgrade config files when upgrading compiler > > >> >> > > >> > > > >> > > >> > > >> > > >> -- > > >> Olaf Wagner -- elego Software Solutions GmbH > > >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 jay.krell at cornell.edu Thu Jul 22 16:47:22 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 22 Jul 2010 14:47:22 +0000 Subject: [M3devel] getting outputs out of the source tree? reducing "ship"? Message-ID: Today we have: /cvsroot/pkg1/src outputs to /src/pkg1/target /cvsroot/pkg2/src outputs to /src/pkg2/target This was good for its time, better than e.g. outputs to /cvsroot/pkg1/src ! However I want more. I want /cvsroot to be read only. So how about: ?outputs to /cvsroot-out/pkg1/target This is probably easy to achieve. e.g. introduce BUILD_DIR_ROOT (or OUTPUT_ROOT) and it is defined, prefix to BUILD_DIR. Probably would have to be accompanied by SOURCE_ROOT, prefix it as needed. ?e.g. relative paths that go from output to source would need to be fixed. an maybe much more so, remove ship as a separate step: ? outputs to /cvsroot-out/intermed/pkg1/target/*.mo? ? outputs to /cvsroot-out/inst/lib/libpkg1.so The one and only copy.? ? outputs to /cvsroot-out/inst/pkg/pkg1/src (maybe, separate ship step! because is a waste when still testing) To "clean", you would have a choice of rm -rf /cvsroot-out/* or mkdir /cvsroot-out2 ?and point whatever environment variable at -inst2. ?? (possibly by copying cm3 into out2 and pointing $PATH at it) The buildlocal vs. buildglobal distinction would go away. buildlocal + ship (which you can't do today, except by copying manually) would be equiv of ? set CM3_OUTPUT_ROOT=/cm3-inst.new? (or again, copy cm3/cm3cfg/config and set PATH) ? build everything ? To try it out, either change PATH, or ? mv /cm-inst /cm3-inst.old ? mv /cm3-inst.new /cm3-inst ? unset CM3_OUTPUT_ROOT If you want to build less, and remain isolated like buildlocal: ? cp -pr /cm3-inst $CM3_OUTPUT_ROOT ? build seletctively ? To try it out, either change PATH, or ? mv /cm-inst /cm3-inst.old ? mv /cm3-inst.new /cm3-inst ? unset CM3_OUTPUT_ROOT One of the points is: the immediate output of compilation could have the same structure as the installation. Installation can be just renaming or copying directories. Not reorganizing directory layout. buildglobal would be building into a new empty directory.-- instead of build + don't ship buildglobal would be building top of the in-use directory -- instead of build + ship Positive consequences: ? All unshipped binaries would work even if linked dynamically, e.g. with $ORIGIN, e.g. without static. ? It still doesn't address systems without $ORIGIN though. There are major advantages either way -- ie. without ORIGIN you can "stitch together" binaries whose paths have no relationship to each other, and you can move around at least the executables arbitrarily. ? Though you can't move the libraries at all. ?? chroot is another way people deal with this -- using absolute paths, but isolated from existing files. ??? It is kind of partial cheap virtual machine, chroot. Now, I have to admit, this is more of an intellectual exercise right now, as I don't have the time/inclination to do it soon. :( ? - Jay From rodney_bates at lcwb.coop Thu Jul 22 23:23:51 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 22 Jul 2010 16:23:51 -0500 Subject: [M3devel] merging gdb from 6.4 to 7.1? In-Reply-To: References: , <4C45BEC6.40603@lcwb.coop> Message-ID: <4C48B6E7.6060908@lcwb.coop> This sounds fine with me, as long as there is one branch for the entire merge process, which will be broken for a while. Jay K wrote: > Thanks. To be clear then, my initial merge will likely lose some changes, > it sounds like you are ok with that, and they can be redone soon > thereafter by someone else (e.g. you). > I'll be sure it builds and do a minimum of debugging with it. > I'll expect it to understand some Modula-3 syntax and esp. decode types. > When I use gdb everything is void* so there should be obvious improvement > with m3gdb. > I'm not sure what the best way to "help" is. I'm not super keen on > "sharing diffs" or using branches. Therefore, come up with something > reasonable maybe slightly flawed, commit it, someone else can improve it > afterward, as long as the initial one isn't too flawed? ok? > > > ok? > > > There is some use of $revision$ and $id$ in there and it makes things > slightly messy. > There are files we didn't change, but which show as changed because of them. > Mostly deleted stuff like hpread.c and the rdi-shared directory. > Or we added comments in dwarfread.c which was deleted. > > > I agree -gstabs might not be best. > It isn't supported on e.g. HP64_HPUX. > But often whenever I try other options like -g or -gcoff or -ggdb or > -gdwarf, > I get crashes in the backend so I leave the config files with -gstabs+. :( > > > I don't think it matters too much what I merge up to, as long as it is >6.4. > 7.1 is out. I didn't see 7.2. > > > Thanks, > - Jay > > > > Date: Tue, 20 Jul 2010 10:20:38 -0500 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] merging gdb from 6.4 to 7.1? > > > > I have been thinking about doing this myself for some time, but up to > > now, have not had the time. I can certainly help, if you want to do it, > > or maybe take it on myself. I think I will be having more time soon. > > I have done it a couple of times before. A few things can be hard to > > figure out, because they rework existing stuff in gdb and it's hard to > > dig out what the new equivalent of the old mechanism is. A lot of the > > M3-specific code I either heavily modified or wrote. > > > > Jay K wrote: > > > The merge of m3cc/gcc from 4.3.0 to 4.3.5 went well enough. > > > > > > I'll volunteer to merge m3gdb from 6.4 to 7.1. > > > > BTW, there is now or will be very soom, a 7.2 gdb. > > Also, the latest gdb does reverse debugging, by recording > > snapshots during the forward run. This would be a *very* > > nice feature to have for Modula-3. > > > > > > > > > > Are people interested? > > > > > > I saw some mention of 6.4.3 in our history. > > > But there's no release called that. > > > What is it? > > > > I don't remember anything about this. > > > > > > > > Some of the conflicts are about SYMBOL_TYP vs. LHS_SYMBOL_TYPE. > > > What that a deliberate important change on our port? > > > > Yes, this is my change, very deliberate, and gets around a nasty > > group of dangling pointer bugs. I would have to took at it again, > > but it used to cache a pointer to a gdb type struct, lazily looked- > > up the first time, right into an existing field of another gdb struct. > > When you rerun, gdb reloads the referent structs of such pointers, > > leaving them dangling. Or maybe I am mixing up two different > > problems. Anyway, the two macros are essential. > > > > I have long thought it might be nice to design a better mechanism, > > but it's not simple. I strongly recommend not messing with it during > > merging to a newer gdb. Save that for a subsequent job with a separate > > CVS tag. It's only a performance matter, and except for debugging work > > that proceeds without requiring user-types commands all the time, it > > scarcely matters. > > > > Also, we would be a lot better off to dump stabs+ and use whatever > > latest version of dwarf that gdb already has support for. But that > > is also a job that should be done separately, with its own tag, after > > a new merge is working with the existing mechanisms. > > > > > > > > > > Thanks, > > > - Jay > > > > > > > > > > > > > > > From rodney_bates at lcwb.coop Thu Jul 22 23:48:11 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 22 Jul 2010 16:48:11 -0500 Subject: [M3devel] merging gdb from 6.4 to 7.1? More info on LHS_SYMBOL_TYPE In-Reply-To: <4C45BEC6.40603@lcwb.coop> References: <4C45BEC6.40603@lcwb.coop> Message-ID: <4C48BC9B.4020708@lcwb.coop> Rodney M. Bates wrote: > I have been thinking about doing this myself for some time, but up to > now, have not had the time. I can certainly help, if you want to do it, > or maybe take it on myself. I think I will be having more time soon. > I have done it a couple of times before. A few things can be hard to > figure out, because they rework existing stuff in gdb and it's hard to > dig out what the new equivalent of the old mechanism is. A lot of the > M3-specific code I either heavily modified or wrote. > > Jay K wrote: >> The merge of m3cc/gcc from 4.3.0 to 4.3.5 went well enough. >> >> I'll volunteer to merge m3gdb from 6.4 to 7.1. > > BTW, there is now or will be very soom, a 7.2 gdb. > Also, the latest gdb does reverse debugging, by recording > snapshots during the forward run. This would be a *very* > nice feature to have for Modula-3. > > >> >> Are people interested? >> >> I saw some mention of 6.4.3 in our history. >> But there's no release called that. >> What is it? > > I don't remember anything about this. > >> >> Some of the conflicts are about SYMBOL_TYP vs. LHS_SYMBOL_TYPE. >> What that a deliberate important change on our port? > > Yes, this is my change, very deliberate, and gets around a nasty > group of dangling pointer bugs. I would have to took at it again, > but it used to cache a pointer to a gdb type struct, lazily looked- > up the first time, right into an existing field of another gdb struct. > When you rerun, gdb reloads the referent structs of such pointers, > leaving them dangling. Or maybe I am mixing up two different > problems. Anyway, the two macros are essential. > > I have long thought it might be nice to design a better mechanism, > but it's not simple. I strongly recommend not messing with it during > merging to a newer gdb. Save that for a subsequent job with a separate > CVS tag. It's only a performance matter, and except for debugging work > that proceeds without requiring user-types commands all the time, it > scarcely matters. I looked back at this. Actually, I am not sure the split of SYMBOL_TYPE into LHS_SYMBOL_TYPE and SYMBOL_TYPE was my original doing, but part of the original mods from stock gdb to m3gdb. I just remember having to figure out in a number of places, which occurrences should be which macro. In stock gdb, there is only SYMBOL_TYPE. It expands to an lvalue that denotes the type member of a symbol. It is used both to assign to and to fetch that member. SYMBOL_TYPE, in m3gdb is effectively an accessor or getter function, but it does some computation to resolve the type using a UID, rather than just fetching a field. it expands to a non-lvalue. Use it to get the type when you have a symbol. In m3gdb, LHS_SYMBOL_TYPE is the corresponding mutator or setter function. I think it's actually the same macro as SYMBOL_TYPE is in gdb. Places in stock gdb that assign to the type field need to be changed to use LHS_SYMBOL_TYPE in m3gdb, to work. Except for a couple of places where a null is assigned, all uses of LHS_SYMBOL_TYPE are in code that is non-m3gdb-specific. I guess it would make future merges easier if LHS_SYMBOL_TYPE were changed back to the original SYMBOL_TYPE and the M3-specific accessor were renamed to something else, perhaps M3_SYMBOL_TYPE or M3_RESOLVE_SYMBOL_TYPE. This would move the changes to be merged out of gdb source files that are not m3gdb-specific. The caching that caused the dangling pointer bugs can be seen in the m3gdb version of the definition of SYMBOL_TYPE, but is it commented out. The resolution is always done over every time. If only gdb had a garbage collector, this would be easier. Actually, I suppose it would need weak references to make the caching work. > > Also, we would be a lot better off to dump stabs+ and use whatever > latest version of dwarf that gdb already has support for. But that > is also a job that should be done separately, with its own tag, after > a new merge is working with the existing mechanisms. > > >> >> Thanks, >> - Jay >> >> >> >> >> > From rodney_bates at lcwb.coop Thu Jul 22 23:57:36 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 22 Jul 2010 16:57:36 -0500 Subject: [M3devel] gdb versions to merge m3gdb into Message-ID: <4C48BED0.2020707@lcwb.coop> The following were recently posted on the gdb development mailing list. If we go to all the work of merging a new gdb, it would be worth waiting a bit if necessary, to get the very latest. Otherwise, our m3gdb is outdated before it even gets working. I don't know more than this about the schedule, but new release branches usually become releases fairly quickly. Both these were posted by Joel Brobecker, on 07/07/2010. I don't know what the relationship between 7.2 and 7.1.90 pre-releases is. -------------------------------------------------------------------------- Hello, A quick message to announce that the GDB 7.2 branch has just been created. The prerelease snapshots will be available at: ftp://sourceware.org/pub/gdb/snapshots/branch/gdb.tar.bz2 The sources are also accessible via CVS: cvs -d :pserver:anoncvs at sourceware.org:/cvs/src co -r gdb_7_2-branch gdb This announcement has also been posted on the GDB web site at: http://www.sourceware.org/gdb/ -- Joel -------------------------------------------------------------------------- Hello, I have just finished creating the gdb-7.1.90 pre-release. It is available for download at the following location: ftp://sourceware.org/pub/gdb/snapshots/branch/gdb-7.1.90.tar.bz2 A gzip'ed version is also available: gdb-7.1.90.tar.gz. Please give it a test if you can and report any problems you might find. x64-windows users, please note the following which is not part of this pre-release: http://www.sourceware.org/ml/gdb-patches/2010-07/msg00130.html On behalf of all the GDB contributors, thank you! -- Joel -------------------------------------------------------------------------- From rcolebur at SCIRES.COM Fri Jul 23 06:46:29 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Fri, 23 Jul 2010 00:46:29 -0400 Subject: [M3devel] Just putting it out there... In-Reply-To: References: , , <20100718170426.12dy7y4iogcwcwgo@mail.elegosoft.com> , , <20100719090459.4CE191A2084@async.async.caltech.edu> , , <20100719110208.011521A2091@async.async.caltech.edu> , <20100719143844.03al7scsg0g400so@mail.elegosoft.com> <1279610803.1935.1.camel@x60.appsoftint.co.uk> <1279633010.1935.11.camel@x60.appsoftint.co.uk> Message-ID: I don't think the sources are available to the M3 JVM, but Olaf would know best on this. If they aren't available, we could check with Farshad Nayeri, one of the original owners/developers of Critical Mass, to see if he might consent to make them available, but this would be a long shot. Regards, Randy Coleburn -----Original Message----- From: m3 at sol42.com [mailto:m3 at sol42.com] Sent: Tuesday, July 20, 2010 10:15 AM To: m3devel Subject: Re: [M3devel] Just putting it out there... On 20 Jul 2010, at 15:36, Mark Wickens wrote: > Yes, after I'd written the email and thought about it I realised it was > a pretty stupid idea. Well, not stupid at all. Java may suck but the JVM certainly does not. There is a lot of interest now in compiling languages other than Java on the JVM, which has turned out to be a sort of universal runtime. Only that it was designed with Java in mind, and you would end up with something *like* Modula-3, not Modula-3 itself: what you can do in JVM "assembly" is limited, no PACKED types, no BITS x FOR y .. z, LOOPHOLE may or may not be always possible, UNTRACED would be problematic, pointer arithmetic in UNSAFE modules might require JNI and who knows what else, forget about <*EXTERNAL*> C calls, full interoperability with Java would require supporting Java interfaces (at the language level I think)... and these are just the few I can think of right now. On the other hand I would really like to code in this superset-of-a-subset of Modula-3 and run it on a JVM. Regarding the Critical Mass JVM described in Threads 3, are the sources available? Regards. -Daniel From wagner at elegosoft.com Fri Jul 23 08:39:49 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 23 Jul 2010 08:39:49 +0200 Subject: [M3devel] Hudson updating config files or not In-Reply-To: References: <20100721155314.E1BC6CC389@birch.elegosoft.com>, , , , <20100722085323.0nmmjnom94osso88@mail.elegosoft.com>, , <20100722091912.bibr9p0z1q88wog4@mail.elegosoft.com>, Message-ID: <20100723083949.l0e85r6j34gks04w@mail.elegosoft.com> The distinction between lastok-build and release-build jobs is obsolete; they have been combined to the -build- jobs ,amy months ago. Just forget about all lastok-build and release-build jobs that may still linger there; they should all be disabled. The -build- jobs should all try a straight forward compile with the cm3 built the last time; if that fails, they will clean everything and start over again with upgrade.sh. That's the only one where configuration files used to get changed. Only the -build- and -test- jobs have been copied over to current. Almost all sources for the hudson jobs should reside in the scripts/regression directory and be under version control. I don't think updates/merges are needed there. Where I wasn't so sure are the scripts one level above. Olaf Quoting Jay K : > I'm not sure, but here is some analysis. > > In the release hudson tasks, we have > http://hudson.modula3.com:8080/view/SOLgnu/job/cm3-release-build-SOLgnu/110/consoleFull > and > http://hudson.modula3.com:8080/view/SOLgnu/job/cm3-build-SOLgnu/163/console > > > "build" and "release-build". > I think these are, like, "build from last release" and "build from > latest successful build". > I'm not sure what they do, but instead of fighting over installs and > CVS trees, they should perhaps just each maintain their own. > That way, e.g., they could both update config files. > > ? Well, except if we are low on diskspace, which we are. And it is a > defficiency of the system to put outputs in the source tree. > ? We should be able to ge by with one source tree per node, and all > outputs should go elsewhere, including the PGS files and > ? including those install.sh that get generated. The source tree > should never be written to, as an option at least. Anyway. > > > In regression/defs.sh I believe they go here: > > > test_build_current > ... > ? if [ "$1" = "rel" ]; then?? # This is the important recurring > thing that makes things different? > ? > ? "release" goes here, "build" does not > ? This path does update config files. > ? > ? > ??? echo " === clean up before cm3 upgrade " > ??? if [ -z "$NOCLEAN" ]; then > ????? OMIT_GCC=yes ./scripts/do-cm3-core.sh realclean || exit 1 > ????? ./scripts/do-pkg.sh realclean cminstall > ??? fi > ??? echo " === perform cm3 upgrade " > ??? UPGRADE_CM3_CFG=yes ./scripts/upgrade.sh || exit 1 > ??? echo " >>> OK build_${1}_upgrade ${DS} ${WS}" > ? fi > > > and then: > > > ? echo " === build ${BSET} system with current compiler" > ? BUILDSCRIPT="./scripts/do-cm3-${BSET}.sh" > ? if [ "$1" = "rel" ]; then?? # This is the important recurring > thing that makes things different? > ??? if [ -z "$NOCLEAN" ]; then > ????? OMIT_GCC=yes ./scripts/do-cm3-core.sh realclean || exit 1 > ??? fi > ? else > ??? if [ -z "$NOCLEAN" ]; then > ????? $BUILDSCRIPT realclean || exit 1 > ??? fi > ? fi > ? $BUILDSCRIPT buildship || exit 1 > > > or, oh no, now I'm confused, here?: > > > test_build_system > > ? test_build_system and test_build_current are very similar! Confusing?! > ? > > ? echo " === build core system with current compiler" > ? BUILDSCRIPT="./scripts/do-cm3-core.sh" > ? if [ -z "$NOCLEAN" ]; then > ??? $BUILDSCRIPT realclean || exit 1 > ? fi > ? if $BUILDSCRIPT build; then > ??? echo " >>> OK build_system ${DS} ${WS}; now rebuild and ship" > ??? $BUILDSCRIPT buildship > ??? echo " === install new compiler" > ??? > ????? This is what we are running for head, I think. > ????? Historically it didn't touch config files. > ????? This is what I changed a day or so ago, to update them. > > ??? if ./scripts/install-cm3-compiler.sh upgrade; then > ????? echo "compiler upgraded successfully" > ????? cm3 -version > ??? else > ????? echo "compiler upgrade failed" 1>&2 > ????? exit 1 > ??? fi > ? else > ? > ??? There is this which will update config files, but only if the > previous fails. > > ??? echo " === perform cm3 upgrade after cleaning everything" > ??? $BUILDSCRIPT realclean || exit 1 > ??? UPGRADE_CM3_CFG=yes ./scripts/upgrade.sh || exit 1 > ??? echo " >>> OK build_upgrade ${DS} ${WS}" > ? fi > > > Anyway, it is confusing, release has a pair of tasks and only some > paths updated config files, even if other/more/different paths > update the compiler. > > > I think: > ? - we want the pairs of tasks, at least for testing coverage > ? - or, I guess, just build from previous release > ??? which can be constraining, it is a policy issue > ? - whichever tasks we have, we should have config file updating > ? - tangentially: we should get all outputs, *all* outouts out of > the source tree > ???? The original design was nice, get outputs "per package" outside > of source, > ???? but it failed to address a multi-package tree. This is a big > change I'm proposing. > ???? I guess another mail on the topic. > > ?- Jay > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: wagner at elegosoft.com >> CC: m3commit at elegosoft.com >> Subject: RE: [M3commit] CVS Update: cm3 >> Date: Thu, 22 Jul 2010 07:21:33 +0000 >> >> >> (ps: the change I made does do the backup foo-date thing, parallel >> to cm3 and cm3cg >> yes I'll compare the branches, can't promise a full merge though) >> >> >> ---------------------------------------- >> > Date: Thu, 22 Jul 2010 09:19:12 +0200 >> > From: wagner at elegosoft.com >> > To: jay.krell at cornell.edu >> > CC: m3commit at elegosoft.com >> > Subject: Re: [M3commit] CVS Update: cm3 >> > >> > I can live with a cm3-local.cfg file which gets included when it exists, >> > contains local overrides and is never touched by he installation. >> > >> > We have to be careful to backup existing configs and informing the >> > users before the installation though. >> > >> > I think upgrade did backups of the config, too. >> > >> > Can you check the scripts in the release branch if anything needs >> > to be merged back? I won't be able to do that today. >> > >> > Olaf >> > >> > Quoting Jay K : >> > >> > > I thought it was too, before I looked at it. >> > > Could be that head and release are very divergent. >> > > I didn't look at release, oops. >> > > I probably will "soon". >> > > >> > > >> > > The config files are "partly part of the compiler", and partly >> > > system-specific. >> > > So they might have to be updated with the compiler. >> > > >> > > >> > > Perhaps we can have cm3.cfg.user or cm3.cfg.local, that we never edit, >> > > and maybe we should constrain it, like very line >> > > must have an equals sign, and if it has a percent, percent must >> > > follow equals. >> > > >> > > >> > > e.g. >> > > m3back_flags = "-custom" >> > > SYSTEM_CC = "custom" % comment blah blah >> > > SYSTEM_LIBS{"LIBC"} = "custom" >> > > SYSTEM_LIBORDER += [custom] >> > > >> > > But that might not be flexible enough. >> > > >> > > Another option is that cm3.cfg file do like: >> > > if exists("cm3.cfg.user.first") >> > > include("cm3.cfg.user.first") >> > > end >> > > ... >> > > if exists("cm3.cfg.user.last") >> > > >> > > include("cm3.cfg.user.last >> > > >> > > end >> > > >> > > >> > > >> > > which is infinitely flexible and not well defined. >> > > Even limiting to assignments is not well defined. >> > > You know, there's an interface somewhere in there, but it isn't >> > > well specified. My fault. >> > > I let things evolve and get discovered gradually, sometimes hard >> > > to know ahead of time what the result will be. >> > > >> > > >> > > I've made changes since 5.8.6 released such that config files from >> > > prior to 5.8.6 will not suffice. >> > > I can undo that, but there is an important policy and >> architecture question. >> > > >> > > >> > > - Jay >> > > >> > > ---------------------------------------- >> > >> Date: Thu, 22 Jul 2010 08:53:23 +0200 >> > >> From: wagner at elegosoft.com >> > >> To: m3commit at elegosoft.com >> > >> Subject: Re: [M3commit] CVS Update: cm3 >> > >> >> > >> Quoting Jay K : >> > >> >> > >> > I've manually updated the config files on SPARC32_LINUX Hudson node >> > >> > to try to fix this. >> > >> >> > >> That should be done by the upgrade script (and it already was AFAIR). >> > >> I wouldn't like the script shipping a newly built compiler to >> > >> unconditionally overwrite all my local configuration. >> > >> >> > >> Olaf >> > >> >> > >> > >> > >> > - Jay >> > >> > >> > >> > ---------------------------------------- >> > >> >> Date: Wed, 21 Jul 2010 17:53:14 +0000 >> > >> >> To: m3commit at elegosoft.com >> > >> >> From: jkrell at elego.de >> > >> >> Subject: [M3commit] CVS Update: cm3 >> > >> >> >> > >> >> CVSROOT: /usr/cvs >> > >> >> Changes by: jkrell at birch. 10/07/21 17:53:14 >> > >> >> >> > >> >> Modified files: >> > >> >> cm3/scripts/: install-cm3-compiler.sh >> > >> >> >> > >> >> Log message: >> > >> >> upgrade config files when upgrading compiler >> > >> >> >> > >> > >> > >> >> > >> >> > >> >> > >> -- >> > >> Olaf Wagner -- elego Software Solutions GmbH >> > >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> > >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 >> > >> > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Fri Jul 23 09:14:13 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 23 Jul 2010 09:14:13 +0200 Subject: [M3devel] getting outputs out of the source tree? reducing "ship"? In-Reply-To: References: Message-ID: <20100723091413.tjia6l308wks80ks@mail.elegosoft.com> You're writing from a perspective of building the complete CM3 distribution. The designers of the package system intentionally made working in the locality of one package easy. Package local build and ship are two of the abstractions that make M3 well suited for large projects, where the isolation of one package is the working context of one developer. Actually, M3 offers many levels/layers of this kind of abstraction that all have its use: o opaque type definition o partial revelation o modules with interfaces o generics for parametric type abstraction o packages with visible and invisible interfaces I wouldn't wnat to loose any of them. So I'm against changing anything regarding build and ship _as default_. I don't object to beging able to override the output directory of package building to another derived hierarchy, and to use that for building the distribution archives. If anybody wants to work on that, I'd expect it being written and tested in isolation, until it is mature enough to actually replace our existing infrastructure. As you mention, it will be a lot of work. Olaf Quoting Jay K : > Today we have: > > > /cvsroot/pkg1/src > outputs to /src/pkg1/target > > > /cvsroot/pkg2/src > > outputs to /src/pkg2/target > > > > This was good for its time, better than e.g. > outputs to /cvsroot/pkg1/src ! > > > However I want more. > > > I want /cvsroot to be read only. > > > So how about: > ?outputs to /cvsroot-out/pkg1/target > > > This is probably easy to achieve. > e.g. introduce BUILD_DIR_ROOT (or OUTPUT_ROOT) and it is defined, > prefix to BUILD_DIR. > Probably would have to be accompanied by SOURCE_ROOT, prefix it as needed. > ?e.g. relative paths that go from output to source would need to be fixed. > > > > an maybe much more so, remove ship as a separate step: > > > ? outputs to /cvsroot-out/intermed/pkg1/target/*.mo? > ? > > outputs to /cvsroot-out/inst/lib/libpkg1.so The one and only copy.? > ? outputs to /cvsroot-out/inst/pkg/pkg1/src (maybe, separate ship > step! because is a waste when still testing) > > > To "clean", you would have a choice of > > > rm -rf /cvsroot-out/* > > or mkdir /cvsroot-out2 > ?and point whatever environment variable at -inst2. > ?? (possibly by copying cm3 into out2 and pointing $PATH at it) > > > The buildlocal vs. buildglobal distinction would go away. > buildlocal + ship (which you can't do today, except by copying > manually) would be equiv of > ? set CM3_OUTPUT_ROOT=/cm3-inst.new? (or again, copy > cm3/cm3cfg/config and set PATH) > ? build everything > ? To try it out, either change PATH, or > > > ? mv /cm-inst /cm3-inst.old > ? mv /cm3-inst.new /cm3-inst > ? unset CM3_OUTPUT_ROOT > > > > If you want to build less, and remain isolated like buildlocal: > > > ? cp -pr /cm3-inst $CM3_OUTPUT_ROOT > ? build seletctively > ? To try it out, either change PATH, or > > ? mv /cm-inst /cm3-inst.old > > ? mv /cm3-inst.new /cm3-inst > > ? unset CM3_OUTPUT_ROOT > > > > > One of the points is: the immediate output of compilation could have > the same structure as the installation. > Installation can be just renaming or copying directories. Not > reorganizing directory layout. > > > buildglobal would be building into a new empty directory.-- instead > of build + don't ship > buildglobal would be building top of the in-use directory -- instead > of build + ship > > Positive consequences: > ? All unshipped binaries would work even if linked dynamically, e.g. > with $ORIGIN, e.g. without static. > ? It still doesn't address systems without $ORIGIN though. > > > There are major advantages either way -- ie. without ORIGIN you can > "stitch together" binaries whose > paths have no relationship to each other, and you can move around at > least the executables arbitrarily. > ? Though you can't move the libraries at all. > ?? chroot is another way people deal with this -- using absolute > paths, but isolated from existing files. > ??? It is kind of partial cheap virtual machine, chroot. > > > Now, I have to admit, this is more of an intellectual exercise right > now, as I don't have the time/inclination to do it soon. :( > > > ? > - Jay > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Fri Jul 23 21:13:52 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 23 Jul 2010 19:13:52 +0000 Subject: [M3devel] openbsd threading Message-ID: If we use -pthread or -lpthread, the call to sigsuspend hangs. If we don't use -pthread or -lpthread, some tests fail to build. So I think we are stuck going back to setjmp munging, which is what 5.8.6 does. Just for OpenBSD. Darwin/amd64 and old FreeBSD can hopefully still use sigaltstack. Linux, Solaris, Darwin/non-amd64, current FreeBSD can still use get/set/make/swapcontext. Maybe I'll upgrade to OpenBSD 4.7 first and give that a shot. I'm one version behind, 4.6. ?- Jay From wagner at elegosoft.com Sat Jul 24 11:08:17 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 24 Jul 2010 11:08:17 +0200 Subject: [M3devel] m3test failure on FreeBSD Message-ID: <20100724110817.uct40io1sw0ggg88@mail.elegosoft.com> Has anybody any idea why this stubbornly fails on FreeBSD4 in current: http://hudson.modula3.com:8080/job/cm3-current-test-m3tests-FreeBSD4/10/console Obviously, the subdirectory cannot be removed by FSUtils.RmRec; error code 66 means it is not empty. I've written this small test program MODULE rmtest EXPORTS Main; IMPORT IO, FSUtils; CONST d = "/pub/users/hudson/workspace/cm3-current-test-m3tests-FreeBSD4/cm3/m3-sys/m3tests/src/p2/p240/FreeBSD4"; BEGIN TRY FSUtils.RmRec( d ); EXCEPT FSUtils.E(m) => IO.Put( m ); END; END rmtest. and of course it runs without a problem :-/ There is nothing suspicious in that directory after the test, at least I cannot see anything. I haven't noticed this problem on any other platform, and in the release branch the tests ran, too. 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 jay.krell at cornell.edu Sat Jul 24 16:34:55 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 24 Jul 2010 14:34:55 +0000 Subject: [M3devel] m3test failure on FreeBSD In-Reply-To: <20100724110817.uct40io1sw0ggg88@mail.elegosoft.com> References: <20100724110817.uct40io1sw0ggg88@mail.elegosoft.com> Message-ID: Could it be open files subject to garbage collection? Could we get more information reported at the time of the failure? ?- Jay ---------------------------------------- > Date: Sat, 24 Jul 2010 11:08:17 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] m3test failure on FreeBSD > > Has anybody any idea why this stubbornly fails on FreeBSD4 in current: > > > http://hudson.modula3.com:8080/job/cm3-current-test-m3tests-FreeBSD4/10/console > > Obviously, the subdirectory cannot be removed by FSUtils.RmRec; error > code 66 means it is not empty. > > I've written this small test program > > MODULE rmtest EXPORTS Main; > > IMPORT IO, FSUtils; > > CONST d = > "/pub/users/hudson/workspace/cm3-current-test-m3tests-FreeBSD4/cm3/m3-sys/m3tests/src/p2/p240/FreeBSD4"; > > BEGIN > TRY > FSUtils.RmRec( d ); > EXCEPT > FSUtils.E(m) => IO.Put( m ); > END; > END rmtest. > > and of course it runs without a problem :-/ > > There is nothing suspicious in that directory after the test, at least > I cannot see anything. I haven't noticed this problem on any other platform, > and in the release branch the tests ran, too. > > 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 jay.krell at cornell.edu Sun Jul 25 12:58:42 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 25 Jul 2010 10:58:42 +0000 Subject: [M3devel] FreeBSD gc stack? Message-ID: So, my real goal here is I'm reviewing why we can't/don't use pthreads on OpenBSD. ? I have a new system and would rather not do the jmpbuf munging. OpenBSD has suspend/resume like FreeBSD. You can inquire as to the stack, but it looks like you get the whole thing, not just the part currently used. And the FreeBSD code appears similar, and appears to walk it incorrectly (no, see below the code before reading the code)? void ThreadPThread__ProcessStopped (m3_pthread_t mt, void *bottom, void *context, ????????????????????????????? void (*p)(void *start, void *limit)) { ? pthread_attr_t attr; ? char *stackaddr; ? WORD_T stacksize; ? /* process the stacks */ ? if (pthread_attr_init(&attr) != 0) abort(); ? if (pthread_attr_get_np(PTHREAD_FROM_M3(mt), &attr) != 0) abort(); ? if (pthread_attr_getstack(&attr, (void **)&stackaddr, &stacksize) != 0) abort(); ? if (pthread_attr_destroy(&attr) != 0) abort(); #if 0 ? assert(stack_grows_down); /* See ThreadPThreadC.c */ #endif ? assert(context == 0); ? assert((char *)bottom >= stackaddr); ? assert((char *)bottom <= (stackaddr + stacksize)); ? p(stackaddr, bottom); ? /* assume registers are stored in the stack */ ? /* but call p to simulate processing registers: see RTHeapStats.m3 */ ? p(0, 0); } ok..it turns out "bottom" is "top"..probably you can define them either way.. it is the highest address. But still, this does have the unfortunate characteristic of scanning the entire stack, not just the "live" part, right? It looks the like the same compromise is easy to achieve on OpenBSD. I think I'll try pthreads there again. I understand it is still usermode and won't run on multiple processors, but it also provides for better portability (no setjmp munging). ?- Jay From jay.krell at cornell.edu Mon Jul 26 13:18:26 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 26 Jul 2010 11:18:26 +0000 Subject: [M3devel] pthread_self == null? Message-ID: I don't see that the standard prohibits NULL from being a valid pthread_t. ? I happened upon this only due to a problem though: OpenBSD x86 4.6 -lX11 -static gives a broken pthreads. We should add an extra boolean to this code, like, before: VAR ? holder: pthread_t; ? inCritical := 0; PROCEDURE LockHeap () = ? VAR self := pthread_self(); ? BEGIN ??? IF pthread_equal(holder, self) = 0 THEN ????? WITH r = pthread_mutex_lock(heapMu) DO <*ASSERT r=0*> END; ????? holder := self; ??? END; ??? INC(inCritical); ? END LockHeap; PROCEDURE UnlockHeap () = ? BEGIN ??? <*ASSERT pthread_equal(holder, pthread_self()) # 0*> ??? DEC(inCritical); ??? IF inCritical = 0 THEN ????? holder := NIL; ????? WITH r = pthread_mutex_unlock(heapMu) DO <*ASSERT r=0*> END; ??? END; ? END UnlockHeap; after: VAR ? holder: pthread_t; +? holder_valid: BOOLEAN; ? inCritical := 0; PROCEDURE LockHeap () = ? VAR self := pthread_self(); ? BEGIN *??? IF NOT holder_valid OR pthread_equal(holder, self) = 0 THEN ????? WITH r = pthread_mutex_lock(heapMu) DO <*ASSERT r=0*> END; ????? holder := self; +???? holder_valid := TRUE;? ??? END; ??? INC(inCritical); ? END LockHeap; PROCEDURE UnlockHeap () = ? BEGIN *??? <*ASSERT holder_valid AND pthread_equal(holder, pthread_self()) # 0*> ??? DEC(inCritical); ??? IF inCritical = 0 THEN ????? holder := NIL; +???? holder_valid := FALSE? ????? WITH r = pthread_mutex_unlock(heapMu) DO <*ASSERT r=0*> END; ??? END; ? END UnlockHeap; I think so. ?- Jay From jay.krell at cornell.edu Mon Jul 26 14:39:55 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 26 Jul 2010 12:39:55 +0000 Subject: [M3devel] newly discoved quake feature Message-ID: I didn't realize, but hash tables don't have to have values. You can say: {"key1", "key2"} contains "foo" You don't need: {"key1" : 1, "key2" : 1} contains "foo" ?- Jay From hosking at cs.purdue.edu Mon Jul 26 21:00:29 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 26 Jul 2010 15:00:29 -0400 Subject: [M3devel] pthread_self == null? In-Reply-To: References: Message-ID: <8599A6EE-9456-440F-A06D-6A3077E4BF8F@cs.purdue.edu> The standard doesn't even say that a pthread_t is a pointer. It might be an int, in which case 0 might be a valid pthread_t. On 26 Jul 2010, at 07:18, Jay K wrote: > > I don't see that the standard prohibits NULL from being a valid pthread_t. > ? > I happened upon this only due to a problem though: OpenBSD x86 4.6 -lX11 -static gives a broken pthreads. > > > We should add an extra boolean to this code, like, before: > > > VAR > holder: pthread_t; > inCritical := 0; > > PROCEDURE LockHeap () = > VAR self := pthread_self(); > BEGIN > IF pthread_equal(holder, self) = 0 THEN > WITH r = pthread_mutex_lock(heapMu) DO <*ASSERT r=0*> END; > holder := self; > END; > INC(inCritical); > END LockHeap; > > PROCEDURE UnlockHeap () = > BEGIN > <*ASSERT pthread_equal(holder, pthread_self()) # 0*> > DEC(inCritical); > IF inCritical = 0 THEN > holder := NIL; > WITH r = pthread_mutex_unlock(heapMu) DO <*ASSERT r=0*> END; > END; > END UnlockHeap; > > > > after: > > VAR > holder: pthread_t; > + holder_valid: BOOLEAN; > inCritical := 0; > > PROCEDURE LockHeap () = > VAR self := pthread_self(); > BEGIN > * IF NOT holder_valid OR pthread_equal(holder, self) = 0 THEN > WITH r = pthread_mutex_lock(heapMu) DO <*ASSERT r=0*> END; > holder := self; > + holder_valid := TRUE; > END; > INC(inCritical); > END LockHeap; > > PROCEDURE UnlockHeap () = > BEGIN > * <*ASSERT holder_valid AND pthread_equal(holder, pthread_self()) # 0*> > DEC(inCritical); > IF inCritical = 0 THEN > holder := NIL; > + holder_valid := FALSE > > WITH r = pthread_mutex_unlock(heapMu) DO <*ASSERT r=0*> END; > END; > END UnlockHeap; > > > I think so. > > > - Jay > > From jay.krell at cornell.edu Mon Jul 26 22:02:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 26 Jul 2010 20:02:44 +0000 Subject: [M3devel] pthread_self == null? In-Reply-To: <8599A6EE-9456-440F-A06D-6A3077E4BF8F@cs.purdue.edu> References: , <8599A6EE-9456-440F-A06D-6A3077E4BF8F@cs.purdue.edu> Message-ID: Agreed. So agreed with the approximate change? ?- Jay ---------------------------------------- > Subject: Re: [M3devel] pthread_self == null? > From: hosking at cs.purdue.edu > Date: Mon, 26 Jul 2010 15:00:29 -0400 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > The standard doesn't even say that a pthread_t is a pointer. > It might be an int, in which case 0 might be a valid pthread_t. > > On 26 Jul 2010, at 07:18, Jay K wrote: > > > > > I don't see that the standard prohibits NULL from being a valid pthread_t. > > ? > > I happened upon this only due to a problem though: OpenBSD x86 4.6 -lX11 -static gives a broken pthreads. > > > > > > We should add an extra boolean to this code, like, before: > > > > > > VAR > > holder: pthread_t; > > inCritical := 0; > > > > PROCEDURE LockHeap () = > > VAR self := pthread_self(); > > BEGIN > > IF pthread_equal(holder, self) = 0 THEN > > WITH r = pthread_mutex_lock(heapMu) DO <*ASSERT r=0*> END; > > holder := self; > > END; > > INC(inCritical); > > END LockHeap; > > > > PROCEDURE UnlockHeap () = > > BEGIN > > <*ASSERT pthread_equal(holder, pthread_self()) # 0*> > > DEC(inCritical); > > IF inCritical = 0 THEN > > holder := NIL; > > WITH r = pthread_mutex_unlock(heapMu) DO <*ASSERT r=0*> END; > > END; > > END UnlockHeap; > > > > > > > > after: > > > > VAR > > holder: pthread_t; > > + holder_valid: BOOLEAN; > > inCritical := 0; > > > > PROCEDURE LockHeap () = > > VAR self := pthread_self(); > > BEGIN > > * IF NOT holder_valid OR pthread_equal(holder, self) = 0 THEN > > WITH r = pthread_mutex_lock(heapMu) DO <*ASSERT r=0*> END; > > holder := self; > > + holder_valid := TRUE; > > END; > > INC(inCritical); > > END LockHeap; > > > > PROCEDURE UnlockHeap () = > > BEGIN > > * <*ASSERT holder_valid AND pthread_equal(holder, pthread_self()) # 0*> > > DEC(inCritical); > > IF inCritical = 0 THEN > > holder := NIL; > > + holder_valid := FALSE > > > > WITH r = pthread_mutex_unlock(heapMu) DO <*ASSERT r=0*> END; > > END; > > END UnlockHeap; > > > > > > I think so. > > > > > > - Jay > > > > > From wagner at elegosoft.com Tue Jul 27 11:26:02 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 27 Jul 2010 11:26:02 +0200 Subject: [M3devel] m3test failure on FreeBSD In-Reply-To: References: <20100724110817.uct40io1sw0ggg88@mail.elegosoft.com> Message-ID: <20100727112602.hp43lj5a4g8cc0kw@mail.elegosoft.com> Quoting Jay K : > Could it be open files subject to garbage collection? > Could we get more information reported at the time of the failure? See http://hudson.modula3.com:8080/job/cm3-current-test-m3tests-FreeBSD4/12/console The directory is listed directly before the RmRec operation fails. I still don't see anything suspicious :-( Olaf > ?- Jay > > > ---------------------------------------- >> Date: Sat, 24 Jul 2010 11:08:17 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: [M3devel] m3test failure on FreeBSD >> >> Has anybody any idea why this stubbornly fails on FreeBSD4 in current: >> >> >> http://hudson.modula3.com:8080/job/cm3-current-test-m3tests-FreeBSD4/10/console >> >> Obviously, the subdirectory cannot be removed by FSUtils.RmRec; error >> code 66 means it is not empty. >> >> I've written this small test program >> >> MODULE rmtest EXPORTS Main; >> >> IMPORT IO, FSUtils; >> >> CONST d = >> "/pub/users/hudson/workspace/cm3-current-test-m3tests-FreeBSD4/cm3/m3-sys/m3tests/src/p2/p240/FreeBSD4"; >> >> BEGIN >> TRY >> FSUtils.RmRec( d ); >> EXCEPT >> FSUtils.E(m) => IO.Put( m ); >> END; >> END rmtest. >> >> and of course it runs without a problem :-/ >> >> There is nothing suspicious in that directory after the test, at least >> I cannot see anything. I haven't noticed this problem on any other platform, >> and in the release branch the tests ran, too. >> >> 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 >> > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Wed Jul 28 11:35:31 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 28 Jul 2010 11:35:31 +0200 Subject: [M3devel] recent build failures in Hudson Message-ID: <20100728113531.ryhlvr680w8gk880@mail.elegosoft.com> Hi Jay, the recent commits seem to have negative effects on several build jobs. Unfortunately, the Hudson's CVS polling was broken for some days, so it may not be as easy as it should be to pin down the culprit(s). Can you have a look (as you've made of the changes): http://hudson.modula3.com:8080/job/cm3-current-build-AMD64_LINUX/lastBuild http://hudson.modula3.com:8080/job/cm3-current-build-PPC_LINUX/lastBuild http://hudson.modula3.com:8080/job/cm3-current-m3cc-AMD64_LINUX/lastBuild http://hudson.modula3.com:8080/job/cm3-current-m3cc-FreeBSD4/lastBuild/ http://hudson.modula3.com:8080/job/cm3-current-test-all-pkgs-FreeBSD4/lastBuild This has been broken since the start of regression for current: http://hudson.modula3.com:8080/job/cm3-current-build-SPARC32_LINUX/lastBuild Thanks in advance, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 28 12:04:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 28 Jul 2010 10:04:20 +0000 Subject: [M3devel] recent build failures in Hudson In-Reply-To: <20100728113531.ryhlvr680w8gk880@mail.elegosoft.com> References: <20100728113531.ryhlvr680w8gk880@mail.elegosoft.com> Message-ID: Mostly this is again just due to older config files. I thought the config files would have been updated by new. I'll fix it to not need them, for now. SPARC32_LINUX is different, unique to it, I'll get to it (I don't know the *exact* fix, but I understand somewhat the problem), but it isn't urgent. Thanks for the heads up. - Jay > Date: Wed, 28 Jul 2010 11:35:31 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: recent build failures in Hudson > > Hi Jay, > > the recent commits seem to have negative effects on several build jobs. > Unfortunately, the Hudson's CVS polling was broken for some days, so > it may not be as easy as it should be to pin down the culprit(s). > > Can you have a look (as you've made of the changes): > > http://hudson.modula3.com:8080/job/cm3-current-build-AMD64_LINUX/lastBuild > http://hudson.modula3.com:8080/job/cm3-current-build-PPC_LINUX/lastBuild > http://hudson.modula3.com:8080/job/cm3-current-m3cc-AMD64_LINUX/lastBuild > http://hudson.modula3.com:8080/job/cm3-current-m3cc-FreeBSD4/lastBuild/ > > http://hudson.modula3.com:8080/job/cm3-current-test-all-pkgs-FreeBSD4/lastBuild > > This has been broken since the start of regression for current: > > http://hudson.modula3.com:8080/job/cm3-current-build-SPARC32_LINUX/lastBuild > > Thanks in advance, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Jul 28 12:09:27 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 28 Jul 2010 12:09:27 +0200 Subject: [M3devel] recent build failures in Hudson In-Reply-To: References: <20100728113531.ryhlvr680w8gk880@mail.elegosoft.com> Message-ID: <20100728120927.ey5hfhm0xs0c8kg4@mail.elegosoft.com> Quoting Jay K : > Mostly this is again just due to older config files. > I thought the config files would have been updated by new. I'll fix > it to not need them, for now. > SPARC32_LINUX is different, unique to it, I'll get to it (I don't > know the *exact* fix, but > I understand somewhat the problem), but it isn't urgent. OK. I'm still trying to figure out the problem with CVS polling. It seems to work for some nodes, but Hudson keeps displaying its warning that something's wrong. Olaf > Thanks for the heads up. > - Jay > > >> Date: Wed, 28 Jul 2010 11:35:31 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: recent build failures in Hudson >> >> Hi Jay, >> >> the recent commits seem to have negative effects on several build jobs. >> Unfortunately, the Hudson's CVS polling was broken for some days, so >> it may not be as easy as it should be to pin down the culprit(s). >> >> Can you have a look (as you've made of the changes): >> >> http://hudson.modula3.com:8080/job/cm3-current-build-AMD64_LINUX/lastBuild >> http://hudson.modula3.com:8080/job/cm3-current-build-PPC_LINUX/lastBuild >> http://hudson.modula3.com:8080/job/cm3-current-m3cc-AMD64_LINUX/lastBuild >> http://hudson.modula3.com:8080/job/cm3-current-m3cc-FreeBSD4/lastBuild/ >> >> http://hudson.modula3.com:8080/job/cm3-current-test-all-pkgs-FreeBSD4/lastBuild >> >> This has been broken since the start of regression for current: >> >> http://hudson.modula3.com:8080/job/cm3-current-build-SPARC32_LINUX/lastBuild >> >> Thanks in advance, >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 jay.krell at cornell.edu Wed Jul 28 12:08:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 28 Jul 2010 10:08:02 +0000 Subject: [M3devel] recent build failures in Hudson In-Reply-To: References: <20100728113531.ryhlvr680w8gk880@mail.elegosoft.com>, Message-ID: --- building in FreeBSD4 --- ignoring ../src/m3overrides rm ./config.status rm ./.M3SHIP rm ./serdep.tmp rm ./cm3cg rm ./config.log rm ./Makefile rm ./m3make.args rm ./_m3.log rm -rf ./libcpp rm -rf ./build-i586-unknown-freebsd4 rm -rf ./gmp "/pub/users/hudson/workspace/cm3-current-m3cc-FreeBSD4/cm3/m3-sys/m3cc/src/m3makefile", line 369: quake runtime error: cannot remove recursively ./gmp: error traversing directory ./gmp/.libs: errno=2 This is wierd. I think we have good evidence now that RmRec has problems -- that is what is being used here and what is failing on FreeBSD4 tests that you have been asking about. This code in m3cc/src/m3makefile is attempting a clean build, by deleting outputs. For now I'll connect to the machines and manually delete the output directory. This RmRec stuff needs more investigation though. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com CC: m3devel at elegosoft.com Subject: RE: recent build failures in Hudson Date: Wed, 28 Jul 2010 10:04:20 +0000 Mostly this is again just due to older config files. I thought the config files would have been updated by new. I'll fix it to not need them, for now. SPARC32_LINUX is different, unique to it, I'll get to it (I don't know the *exact* fix, but I understand somewhat the problem), but it isn't urgent. Thanks for the heads up. - Jay > Date: Wed, 28 Jul 2010 11:35:31 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: recent build failures in Hudson > > Hi Jay, > > the recent commits seem to have negative effects on several build jobs. > Unfortunately, the Hudson's CVS polling was broken for some days, so > it may not be as easy as it should be to pin down the culprit(s). > > Can you have a look (as you've made of the changes): > > http://hudson.modula3.com:8080/job/cm3-current-build-AMD64_LINUX/lastBuild > http://hudson.modula3.com:8080/job/cm3-current-build-PPC_LINUX/lastBuild > http://hudson.modula3.com:8080/job/cm3-current-m3cc-AMD64_LINUX/lastBuild > http://hudson.modula3.com:8080/job/cm3-current-m3cc-FreeBSD4/lastBuild/ > > http://hudson.modula3.com:8080/job/cm3-current-test-all-pkgs-FreeBSD4/lastBuild > > This has been broken since the start of regression for current: > > http://hudson.modula3.com:8080/job/cm3-current-build-SPARC32_LINUX/lastBuild > > Thanks in advance, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Jul 28 12:18:50 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 28 Jul 2010 12:18:50 +0200 Subject: [M3devel] recent build failures in Hudson In-Reply-To: References: <20100728113531.ryhlvr680w8gk880@mail.elegosoft.com>, Message-ID: <20100728121850.uqea76js00oosocg@mail.elegosoft.com> Quoting Jay K : > --- building in FreeBSD4 --- > > ignoring ../src/m3overrides > > rm ./config.status > rm ./.M3SHIP > rm ./serdep.tmp > rm ./cm3cg > rm ./config.log > rm ./Makefile > rm ./m3make.args > rm ./_m3.log > rm -rf ./libcpp > rm -rf ./build-i586-unknown-freebsd4 > rm -rf ./gmp > "/pub/users/hudson/workspace/cm3-current-m3cc-FreeBSD4/cm3/m3-sys/m3cc/src/m3makefile", line 369: quake runtime error: cannot remove recursively ./gmp: error traversing directory ./gmp/.libs: > errno=2 > > This is wierd. > I think we have good evidence now that RmRec has problems -- that is > what is being used here and what is failing on FreeBSD4 tests that > you have been asking about. > > This code in m3cc/src/m3makefile is attempting a clean build, by > deleting outputs. > For now I'll connect to the machines and manually delete the output > directory. > This RmRec stuff needs more investigation though. It didn't fail for FreeBSD before, i.e. on the release branch. And it's only on the i386 machine (running FreeBSD 6.4), not on my amd64 running FreeBSD 8.1. Any ideas what I could check again tonight? Any specific changes for this target? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 28 12:36:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 28 Jul 2010 10:36:32 +0000 Subject: [M3devel] recent build failures in Hudson In-Reply-To: <20100728121850.uqea76js00oosocg@mail.elegosoft.com> References: <20100728113531.ryhlvr680w8gk880@mail.elegosoft.com>, , , <20100728121850.uqea76js00oosocg@mail.elegosoft.com> Message-ID: Oops, to clarify, it isn't only on FreeBSD4, also http://hudson.modula3.com:8080/job/cm3-current-m3cc-AMD64_LINUX/lastBuild/console I might debug this is a bit first, before just deleting the directories. ?- Jay ---------------------------------------- > Date: Wed, 28 Jul 2010 12:18:50 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: recent build failures in Hudson > > Quoting Jay K : > > > --- building in FreeBSD4 --- > > > > ignoring ../src/m3overrides > > > > rm ./config.status > > rm ./.M3SHIP > > rm ./serdep.tmp > > rm ./cm3cg > > rm ./config.log > > rm ./Makefile > > rm ./m3make.args > > rm ./_m3.log > > rm -rf ./libcpp > > rm -rf ./build-i586-unknown-freebsd4 > > rm -rf ./gmp > > "/pub/users/hudson/workspace/cm3-current-m3cc-FreeBSD4/cm3/m3-sys/m3cc/src/m3makefile", line 369: quake runtime error: cannot remove recursively ./gmp: error traversing directory ./gmp/.libs: > > errno=2 > > > > This is wierd. > > I think we have good evidence now that RmRec has problems -- that is > > what is being used here and what is failing on FreeBSD4 tests that > > you have been asking about. > > > > This code in m3cc/src/m3makefile is attempting a clean build, by > > deleting outputs. > > For now I'll connect to the machines and manually delete the output > > directory. > > This RmRec stuff needs more investigation though. > > It didn't fail for FreeBSD before, i.e. on the release branch. > And it's only on the i386 machine (running FreeBSD 6.4), not on > my amd64 running FreeBSD 8.1. > > Any ideas what I could check again tonight? > Any specific changes for this target? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Wed Jul 28 13:13:55 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 28 Jul 2010 11:13:55 +0000 Subject: [M3devel] CVS polling related? Message-ID: CVS polling related? % Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... birch cvs: cvs update: New directory `m3-sys/m3cc/gcc/gcc/config/vax' -- ignored Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... birch cvs: error (1, 0) called recursively.? Second message was: Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... birch cvs: cvs update: New directory `m3-sys/m3cc/gcc/gcc/config/vax' -- ignored Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... birch cvs: error (1, 0) called recursively.? Second message was: Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... birch cvs: error (0, 0) called recursively.? Original message was: Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... birch cvs: cvs [update aborted]: received broken pipe signal Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... birch cvs: error (0, 0) called recursively.? Original message was: Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... birch cvs: cvs [update aborted]: received broken pipe signal Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... birch cvs: Aborting. Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... birch cvs: Aborting. From jay.krell at cornell.edu Wed Jul 28 13:19:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 28 Jul 2010 11:19:08 +0000 Subject: [M3devel] recent build failures in Hudson In-Reply-To: References: <20100728113531.ryhlvr680w8gk880@mail.elegosoft.com>, , , , , , <20100728121850.uqea76js00oosocg@mail.elegosoft.com>, Message-ID: I manually deleted the gmp directory on AMD64_LINUX and will get FreeBSD4. "Very soon" I'll trigger this code again -- but this time, sysutils might report more information before the error. I wonder if it has to do with the symlink in there, but the code looks correct -- it'd treat symlinks as a regular file. We'll see what the sysutils/RTIO reports when we get the failure next. The sysutils/RTIO code might mix up other code, e.g. diffs in the tests. Please ignore that for a bit unless it is too catastrophic -- ie. if building stuff is also broken by it. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com > Date: Wed, 28 Jul 2010 10:36:32 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] recent build failures in Hudson > > > Oops, to clarify, it isn't only on FreeBSD4, also http://hudson.modula3.com:8080/job/cm3-current-m3cc-AMD64_LINUX/lastBuild/console > I might debug this is a bit first, before just deleting the directories. > > - Jay > > ---------------------------------------- > > Date: Wed, 28 Jul 2010 12:18:50 +0200 > > From: wagner at elegosoft.com > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: RE: recent build failures in Hudson > > > > Quoting Jay K : > > > > > --- building in FreeBSD4 --- > > > > > > ignoring ../src/m3overrides > > > > > > rm ./config.status > > > rm ./.M3SHIP > > > rm ./serdep.tmp > > > rm ./cm3cg > > > rm ./config.log > > > rm ./Makefile > > > rm ./m3make.args > > > rm ./_m3.log > > > rm -rf ./libcpp > > > rm -rf ./build-i586-unknown-freebsd4 > > > rm -rf ./gmp > > > "/pub/users/hudson/workspace/cm3-current-m3cc-FreeBSD4/cm3/m3-sys/m3cc/src/m3makefile", line 369: quake runtime error: cannot remove recursively ./gmp: error traversing directory ./gmp/.libs: > > > errno=2 > > > > > > This is wierd. > > > I think we have good evidence now that RmRec has problems -- that is > > > what is being used here and what is failing on FreeBSD4 tests that > > > you have been asking about. > > > > > > This code in m3cc/src/m3makefile is attempting a clean build, by > > > deleting outputs. > > > For now I'll connect to the machines and manually delete the output > > > directory. > > > This RmRec stuff needs more investigation though. > > > > It didn't fail for FreeBSD before, i.e. on the release branch. > > And it's only on the i386 machine (running FreeBSD 6.4), not on > > my amd64 running FreeBSD 8.1. > > > > Any ideas what I could check again tonight? > > Any specific changes for this target? > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Wed Jul 28 13:26:55 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 28 Jul 2010 13:26:55 +0200 Subject: [M3devel] CVS polling related? In-Reply-To: References: Message-ID: <20100728132655.e60y0jalckwkw08w@mail.elegosoft.com> Quoting Jay K : > CVS polling related? Probably. The 'cvs: error (1, 0) called recursively' are a known annoyance though. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=386153 http://savannah.nongnu.org/bugs/?26608 for details. Olaf > % > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > birch cvs: cvs update: New directory > `m3-sys/m3cc/gcc/gcc/config/vax' -- ignored > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > birch cvs: error (1, 0) called recursively.? Second message was: > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > birch cvs: cvs update: New directory > `m3-sys/m3cc/gcc/gcc/config/vax' -- ignored > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > birch cvs: error (1, 0) called recursively.? Second message was: > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > birch cvs: error (0, 0) called recursively.? Original message was: > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > birch cvs: cvs [update aborted]: received broken pipe signal > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > birch cvs: error (0, 0) called recursively.? Original message was: > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > birch cvs: cvs [update aborted]: received broken pipe signal > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > birch cvs: Aborting. > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > birch cvs: Aborting. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 28 13:38:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 28 Jul 2010 11:38:31 +0000 Subject: [M3devel] CVS polling related? In-Reply-To: <20100728132655.e60y0jalckwkw08w@mail.elegosoft.com> References: , <20100728132655.e60y0jalckwkw08w@mail.elegosoft.com> Message-ID: bug was reported in 2006. Presumably the fix is to not use CVS! What bothers me about CVS: 1) When there is a multi-file commit, there is no one link to follow to see the diffs. Hudson helps. But I want cvsweb to provide it. This is usually naturally fixed by any system with atomic commit as they identity the multi-file commit with one identifiers. 2) Everything is excruciatingly slow because everything goes to the network. 2a) I want cvs diff to not go to the network. 2b) I want a "cvs revert" command; what I frequently do is rename or delete my edits and then cvs upd to get the file back. In Perforce this is just p4 revert ... 3) I don't want it dropping CVS directories in every single directory. Just at the top of the tree, or preferably just one file or preferably in a parallel location; diffing two checkouts is made awful by this. I believe subversion has the same bug. Perforce does not. More cvs oddity, like, it was missing everything, and printed lots of odd stuff: http://hudson.modula3.com:8080/job/cm3-current-build-PPC_LINUX/25/consoleFull I'll poke at that some. I don't even see the workspace anywhere. ?- Jay ---------------------------------------- > Date: Wed, 28 Jul 2010 13:26:55 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: CVS polling related? > > Quoting Jay K : > > > CVS polling related? > > Probably. The 'cvs: error (1, 0) called recursively' are a > known annoyance though. See > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=386153 > http://savannah.nongnu.org/bugs/?26608 > > for details. > > Olaf > > > % > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > > birch cvs: cvs update: New directory > > `m3-sys/m3cc/gcc/gcc/config/vax' -- ignored > > > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > > birch cvs: error (1, 0) called recursively. Second message was: > > > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > > birch cvs: cvs update: New directory > > `m3-sys/m3cc/gcc/gcc/config/vax' -- ignored > > > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > > birch cvs: error (1, 0) called recursively. Second message was: > > > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > > birch cvs: error (0, 0) called recursively. Original message was: > > > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > > birch cvs: cvs [update aborted]: received broken pipe signal > > > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > > birch cvs: error (0, 0) called recursively. Original message was: > > > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > > birch cvs: cvs [update aborted]: received broken pipe signal > > > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > > birch cvs: Aborting. > > > > Message from syslogd at birch at Wed Jul 28 13:07:33 2010 ... > > birch cvs: Aborting. > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Wed Jul 28 16:17:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 28 Jul 2010 14:17:24 +0000 Subject: [M3devel] The various hudson tasks Message-ID: Olaf, it is a bit odd that there are "m3cc" tasks and "other", but yet "other" does build m3cc. e.g.: http://hudson.modula3.com:8080/job/cm3-current-build-SPARC32_LINUX/35/console I seem to always be confused by what the tasks are. :( ?- Jay From wagner at elegosoft.com Wed Jul 28 16:49:21 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 28 Jul 2010 16:49:21 +0200 Subject: [M3devel] The various hudson tasks In-Reply-To: References: Message-ID: <20100728164921.2u9en41kgswgc88k@mail.elegosoft.com> Quoting Jay K : > Olaf, it is a bit odd that there are "m3cc" tasks and "other", but > yet "other" does build m3cc. > e.g.: > > http://hudson.modula3.com:8080/job/cm3-current-build-SPARC32_LINUX/35/console > > I seem to always be confused by what the tasks are. :( There is such a thing as a "standard CM3 system build and if necessary upgrade". This is included in the (1) cm3-current-build-* jobs for the CVS trunk. The build of the gcc backend has been extracted from that task, as it is based on different and differently licensed sources and takes quite a long time compared to M3 builds. The gcc backend builds are contained in the (2) cm3-current-m3cc-* jobs. The result of this job is used by other build jobs if available. There are two classes of test jobs: (3) cm3-current-test-m3tests-* just runs the m3tests package tests for the compiler. (4) cm3-current-test-all-pkgs-* is like a "build world"; i.e. it compiles all packages, compiles all associated test packages, and runs all associated tests if available. Apart from those there are groups of jobs for building distribution archives and for downloading and testing those. Any suggestions for a better setup are welcome. The existing setup has worked reasonably well in the past though. If anybody wants to play with the Hudson job and try something new, he is welcome if he promises not to bring down the existing Hudson tasks and other services. Hudson can be completely controlled via the HTTP GUI. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 28 17:23:29 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 28 Jul 2010 15:23:29 +0000 Subject: [M3devel] cvs warning about gcc/install,fixincludes directories Message-ID: http://hudson.modula3.com:8080/job/cm3-current-build-FreeBSD4/7/console P m3-sys/cm3/src/M3Build.m3 cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/INSTALL' cvs update: use `cvs add' to create an entry for `m3-sys/m3cc/gcc/fixincludes' Some CVS weirdness here. I've resorted to deleting these directories on machines I can be hudson on. Then they come back and I think they are ok. i.e. not PPC_LINUX, FreeBSD4. We could also just delete these directories from cvs. - Jay From jay.krell at cornell.edu Wed Jul 28 17:32:23 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 28 Jul 2010 15:32:23 +0000 Subject: [M3devel] The various hudson tasks In-Reply-To: <20100728164921.2u9en41kgswgc88k@mail.elegosoft.com> References: , <20100728164921.2u9en41kgswgc88k@mail.elegosoft.com> Message-ID: m3cc is both in its own task and in the cm3 task. I don't understand why it is in both. This also causes the sources to be duplicated more. Given proper incrementality, the split shouldn't be needed. ? But ok. Splitting might resemble the future distribution form as well -- ie, one that is more like the old DEC SRC one. And I'm sure there are incrementality bugs, e.g. like when files are added/deleted/moved. ? Every time I've moved a file it has caused problems. I kind of think it should always "upgrade" for some definition of that. Always start with cm3/cm3cg/m3core/config files, and I guess libm3. Build up to cm3, skipping cm3cg, m3core, libm3. Copy/install cm3. Build cm3cg incrementally Clean everything but cm3cg. Too expensive? Build m3core up to cm3. Copy/install cm3. clean everything but cm3cg. Too expensive? Build everything. I can see that might be too expensive though. On the other hand, if the compiler changes, you really need to buid everything clean. As I assume incrementality doesn't take into account the compiler's timestamp, and if it did, it'd all be clean anyway. But I'm not keen on changing this stuff. It seems kind of difficult and very time consuming to get working, and extremely nice to have in almost any working form. Thanks, ?- Jay ---------------------------------------- > Date: Wed, 28 Jul 2010 16:49:21 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: The various hudson tasks > > Quoting Jay K : > > > Olaf, it is a bit odd that there are "m3cc" tasks and "other", but > > yet "other" does build m3cc. > > e.g.: > > > > http://hudson.modula3.com:8080/job/cm3-current-build-SPARC32_LINUX/35/console > > > > I seem to always be confused by what the tasks are. :( > > There is such a thing as a "standard CM3 system build and if necessary > upgrade". > This is included in the (1) cm3-current-build-* jobs for the CVS trunk. > > The build of the gcc backend has been extracted from that task, as > it is based on different and differently licensed sources and takes > quite a long time compared to M3 builds. > > The gcc backend builds are contained in the (2) cm3-current-m3cc-* jobs. > The result of this job is used by other build jobs if available. > > There are two classes of test jobs: > > (3) cm3-current-test-m3tests-* just runs the m3tests package tests > for the compiler. > > (4) cm3-current-test-all-pkgs-* is like a "build world"; i.e. it > compiles all packages, compiles all associated test packages, > and runs all associated tests if available. > > Apart from those there are groups of jobs for building distribution > archives and for downloading and testing those. > > Any suggestions for a better setup are welcome. > The existing setup has worked reasonably well in the past though. > > If anybody wants to play with the Hudson job and try something new, > he is welcome if he promises not to bring down the existing Hudson > tasks and other services. Hudson can be completely controlled via > the HTTP GUI. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > From jay.krell at cornell.edu Wed Jul 28 18:32:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 28 Jul 2010 16:32:10 +0000 Subject: [M3devel] FreeBSD atomics Message-ID: There seems to be a problem where the atomics are all failing on FreeBSD4. http://hudson.modula3.com:8080/job/cm3-current-test-all-pkgs-FreeBSD4/ I'll investigate. All the x86 config files share code: -march=i586. So it is surprising. Possibly in parse.c we should make it at least 586 independent of the command line. ?- Jay From jay.krell at cornell.edu Wed Jul 28 18:38:49 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 28 Jul 2010 16:38:49 +0000 Subject: [M3devel] openbsd/pthread/sigaltstack.. Message-ID: For the record..: Latest experiments: pthreads on OpenBSD hit some problems, assertion failures. I didn't debug. Maybe should. The sigaltstack strategy to portable user threads works. But it hangs on OpenBSD if you use -pthread. I didn't debug the hang. Maybe should. So it seems viable to be portable with sigaltstack and omit -pthread. But if you omit -pthread, then you run into e.g.: http://hudson.modula3.com:8080/job/cm3-current-test-all-pkgs-I386_OPENBSD/3/artifact/cm3-pkg-report-I386_OPENBSD.html#tr_m3-db-odbc /usr/local/lib/libiodbc.so.3.15: undefined reference to `pthread_mutex_unlock' /usr/local/lib/libiodbc.so.3.15: undefined reference to `pthread_self' /usr/local/lib/libiodbc.so.3.15: undefined reference to `pthread_mutex_lock' /usr/local/lib/libiodbc.so.3.15: undefined reference to `pthread_mutex_init' So the choice is unfortunate: much more portability with sigaltstack, or don't support packages such as odbc, or heck, just don't support OpenBSD, or debug the pthread problem (not the hang, though there is that, the problem of using actual pthreads). I'm also not keen on a solutiion that "randomly" stops working when user links with -pthread. It should work the same either way (at least if it links either way). For now I'm ok with jmpbuf hacking, but it disappointing. 5.8.6 used jmpbug hacking. ?- Jay From jay.krell at cornell.edu Wed Jul 28 18:47:56 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 28 Jul 2010 16:47:56 +0000 Subject: [M3devel] OpenBSD/powerpc Message-ID: There are very recent min/all distributions of openbsd/powerpc here: ? http://modula3.elegosoft.com/cm3/uploaded-archives/ I disabled dynamic linking of Modula-3 libraries, via config files, commited. Using -fPIC results in assembly errors all over the place. (Maybe I should try lowercase -fpic?) Not using -fPIC..I get a bunch of "unresolved symbol ''" at runtime -- like that, it reports the symbol name in single quotes and it is empty. Presumably this could be fixed, but presumably it doesn't matter much either. OpenBSD seems to like a pretty nice system (for a Posix system, other than MacOSX...), unless you try to get Modula-3 running on it. ?Then it seems kind of like the odd one out. Current OpenBSD is "stuck" with old gcc 3.x (I think even 2.x for some targets). It might be a good approach to import and patch their gcc fork, if anyone really wanted this to work. ? Or the hypothetical C-generating backend.. Given we already have 3 copies of gcc, I'm reluctant. Maybe when we move from 4.3 to 4.5 and delete one. Java doesn't seem to be available (a systematic problem across a certain range of systems), so Hudson won't be available so just these occasional unofficial releases I think will be it. (nice: 1) it isn't badly fractured like Linux; 2) comes with full source to the system like all *BSD; nice package system like all *BSD 3) easy to install, including you need merely one file locally and everything else can be installed over the net, very good device support.) ?- Jay From wagner at elegosoft.com Wed Jul 28 18:53:51 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 28 Jul 2010 18:53:51 +0200 Subject: [M3devel] The various hudson tasks In-Reply-To: References: , <20100728164921.2u9en41kgswgc88k@mail.elegosoft.com> Message-ID: <20100728185351.c50y1dwpwwcwcw8s@mail.elegosoft.com> Quoting Jay K : > m3cc is both in its own task and in the cm3 task. > I don't understand why it is in both. > This also causes the sources to be duplicated more. I don't follow you here. If the backend has already be built by the m3cc job, it should be used by the M3 builds. > Given proper incrementality, the split shouldn't be needed. ? > But ok. > Splitting might resemble the future distribution form as well -- ie, > one that is more like the old DEC SRC one. > And I'm sure there are incrementality bugs, e.g. like when files are > added/deleted/moved. > ? Every time I've moved a file it has caused problems. Yes. This is a known problem with the package-oriented builder. > I kind of think it should always "upgrade" for some definition of that. > Always start with cm3/cm3cg/m3core/config files, and I guess libm3. > Build up to cm3, skipping cm3cg, m3core, libm3. > Copy/install cm3. > Build cm3cg incrementally > Clean everything but cm3cg. Too expensive? Yes. > Build m3core up to cm3. > Copy/install cm3. > clean everything but cm3cg. Too expensive? > Build everything. > > I can see that might be too expensive though. > On the other hand, if the compiler changes, you really need to buid > everything clean. Yes. I'll be happy if I find an easy way to incorporate this into the existing tasks. If I only had more spare time... > As I assume incrementality doesn't take into account the compiler's > timestamp, and if it did, it'd all be clean anyway. > > But I'm not keen on changing this stuff. > It seems kind of difficult and very time consuming to get working, > and extremely nice to have in almost any working form. Thanks. I'll try to make incremental improvements as I find the time, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Jul 28 19:40:26 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 28 Jul 2010 17:40:26 +0000 Subject: [M3devel] FreeBSD atomics In-Reply-To: References: Message-ID: I don't get it. Maybe old config files still?? It works for me: %./gcc 1.c -march=i586 %cat 1.c long long F1(long long* a, long long b) { ? return __sync_fetch_and_and_8(a, b); } int main() { } %uname -a FreeBSD fbsd4 4.11-RELEASE FreeBSD 4.11-RELEASE #0: Fri Jan 21 17:21:22 GMT 2005???? root at perseus.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC? i386 %./gcc -v Using built-in specs. Target: i386-unknown-freebsd4.11 Configured with: /home/jay/src/gcc-4.3.4/configure -disable-nls -prefix=/home/jay/gcc-4.3.4 Thread model: posix gcc version 4.3.4 (GCC) % I'll wait. Maybe the config files are old. Really this stuff should be the same across all I386 targets, unless maybe sometimes the "operating system" implies a minimum supported processor architecture. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Subject: FreeBSD atomics > Date: Wed, 28 Jul 2010 16:32:10 +0000 > > > There seems to be a problem where the atomics are all failing on FreeBSD4. > > http://hudson.modula3.com:8080/job/cm3-current-test-all-pkgs-FreeBSD4/ > > I'll investigate. > > All the x86 config files share code: -march=i586. > So it is surprising. > Possibly in parse.c we should make it at least 586 independent of the command line. > > - Jay > > > > > From michael.anderson at elego.de Thu Jul 29 13:50:16 2010 From: michael.anderson at elego.de (Michael Anderson) Date: Thu, 29 Jul 2010 13:50:16 +0200 Subject: [M3devel] [elego Server Maintenance] Friday 30.07.2010 20:00 Message-ID: <20100729135016.0wuslzeyccs0cw4k@mail.elego.de> Hello, On Friday, July 30 at 8 PM CEST, we will perform scheduled maintenance on our servers, including the modula3 CVS server and Hudson CI server. Expected duration: 120 Min. We apologize for any inconvenience. - the elego Admins -- Michael Anderson IT Services & Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From rcolebur at SCIRES.COM Fri Jul 30 03:35:30 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Thu, 29 Jul 2010 21:35:30 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20100728142204.996F52474003@birch.elegosoft.com> References: <20100728142204.996F52474003@birch.elegosoft.com> Message-ID: Jay, before you go removing stuff on an assumption, maybe you should check with the group. I do know what this message means and it does have value. Regards, Randy ________________________________________ From: Jay Krell [jkrell at elego.de] Sent: Wednesday, July 28, 2010 12:22 PM To: m3commit at elegosoft.com Subject: [M3commit] CVS Update: cm3 CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/07/28 16:22:03 Modified files: cm3/m3-sys/cm3/src/: M3Build.m3 Log message: remove more of the code for: remove the "ignoring override" print out, I think few people know it means and fewer (nobody) finds it useful From jay.krell at cornell.edu Fri Jul 30 03:58:45 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 30 Jul 2010 01:58:45 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: <20100728142204.996F52474003@birch.elegosoft.com>, Message-ID: Randy, Without reading the code, what does it mean? My first guess was I believe wrong and based on reading the code I think it is even more pointless than I previously thought. It gets printed *all the time*, when using overrides. Look at any of the Hudson logs. It wouldn't be printed so much in the older way of doing things, where overrides were applied haphazardly and incompletely. Now that they are used fairly consistently/correctly, it always triggers. I hope to eventually replace the overrides mechanism -- if we just put files into a designated root directory, with the same structure as "the install", then "override" is just setting that directory, optionally prepopulating with an entire copy of the current install -- depending on if you want to build up from scratch or selectively override. You could use hardlinks to speed it up, as long as our copy is delete + copy and not just copy (sometimes a copy will share with the original link(s), sometimes it will unshare, depending on the open flags (I think) or if you first delete). And "install" becomes just moving the install root, if the new one is complete. What isn't easy though is "stitching together of multiple sparse pieces". overrides can do that today. $ORIGIN and the old full paths are both at odds with that though. If you make a complete, full paths are wrong. If you make an incomplete copy, $ORIGIN is wrong. "stitching together of multipl sparse pieces" is maybe the job of LD_LIBARY_PATH though, and makes no guarantees (since you might have duplicates and it becomes order-dependent). It might help if the "new" root is symlinks..except it doesn't -- no way for old files to point to new. General point noted. And if I fail, we have m3commit. Gotta run, - Jay > From: rcolebur at SCIRES.COM > To: m3devel at elegosoft.com > Date: Thu, 29 Jul 2010 21:35:30 -0400 > Subject: Re: [M3devel] [M3commit] CVS Update: cm3 > > Jay, before you go removing stuff on an assumption, maybe you should check with the group. I do know what this message means and it does have value. > Regards, > Randy > > ________________________________________ > From: Jay Krell [jkrell at elego.de] > Sent: Wednesday, July 28, 2010 12:22 PM > To: m3commit at elegosoft.com > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/07/28 16:22:03 > > Modified files: > cm3/m3-sys/cm3/src/: M3Build.m3 > > Log message: > remove more of the code for: remove the "ignoring override" print out, I think few people know it means and fewer (nobody) finds it useful -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jul 30 15:20:40 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 30 Jul 2010 13:20:40 +0000 Subject: [M3devel] rmrec problems Message-ID: Olaf, I suggest that maybe deleting while enumerating is undefined? We should try enumerating first, and then deleting, at least on a per-directory basis, not recursively. ? Even though that is bad in terms of working set -- small constant to unbounded. As well, recursion on the machine stack that is bounded by user input, is to be avoided. User can provide arbitrarily deep input and you blow the stack. Better to use a queue or stack data structure, add elements, and loop while not empty. I can try something here within a week, we can see if it helps. Stopgap might be to double up the rmrec calls and see what happens. Maybe delete while enumerate works under some conditions. Maybe I'm just randomly guessing (yes) and am way off (unknown). ?- Jay From jay.krell at cornell.edu Fri Jul 30 15:23:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 30 Jul 2010 13:23:43 +0000 Subject: [M3devel] rmrec problems In-Reply-To: References: Message-ID: Better theory: readdir uses globals. Suggest readdir_r... ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Subject: rmrec problems > Date: Fri, 30 Jul 2010 13:20:40 +0000 > > > Olaf, I suggest that maybe deleting while enumerating is undefined? > We should try enumerating first, and then deleting, at least on a per-directory basis, not recursively. > Even though that is bad in terms of working set -- small constant to unbounded. > > > As well, recursion on the machine stack that is bounded by user input, is to be avoided. > User can provide arbitrarily deep input and you blow the stack. > Better to use a queue or stack data structure, add elements, and loop while not empty. > > > I can try something here within a week, we can see if it helps. > > > Stopgap might be to double up the rmrec calls and see what happens. > Maybe delete while enumerate works under some conditions. > > > Maybe I'm just randomly guessing (yes) and am way off (unknown). > > - Jay > > > > > From hendrik at topoi.pooq.com Fri Jul 30 23:50:51 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 30 Jul 2010 17:50:51 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: Message-ID: <20100730215051.GA23133@topoi.pooq.com> On Fri, Jul 30, 2010 at 01:58:45AM +0000, Jay K wrote: > > Randy, Without reading the code, what does it mean? > > My first guess was I believe wrong and based on reading the code I think it is even more pointless than I previously thought. > > It gets printed *all the time*, when using overrides. Look at any of the Hudson logs. > > It wouldn't be printed so much in the older way of doing things, where overrides were applied haphazardly and incompletely. Now that they are used fairly consistently/correctly, it always triggers. I hope to eventually replace the overrides mechanism -- if we just put files into a designated root directory, with the same structure as "the install", then "override" is just setting that directory, optionally prepopulating with an entire copy of the current install -- depending on if you want to build up from scratch or selectively override. You could use hardlinks to speed it up, as long as our copy is delete + copy and not just copy (sometimes a copy will share with the original link(s), sometimes it will unshare, depending on the open flags (I think) or if you first delete). And "install" becomes just moving the install root, if the new one is complete. I remember using an override somewhere ... but I don't remember where or why now. But I'd worry if this change broke something. -- hendrik