From jay.krell at cornell.edu Sat Dec 1 03:59:45 2007 From: jay.krell at cornell.edu (Jay) Date: Sat, 1 Dec 2007 02:59:45 +0000 Subject: [M3devel] some more notes on the win32 system In-Reply-To: <4750474F.1E75.00D7.1@scires.com> References: <036701c83256$d553bbf0$7ffb33d0$@com> <4750474F.1E75.00D7.1@scires.com> Message-ID: I don't setup stuff with spaces mostly, but it doesn't matter. In the past, as the install and configuration nudged you, cminstall/cm3.exe/cm3.cfg trafficed in the full paths to cl.exe, link.exe, various .libs, and possibly directories containing .h. In the present, cm3.cfg invokes merely "cl" or "cl.exe", "link" or "link.exe", does not pass any include paths to the compiler, and passes leaf file names of .libs to the linker -- msvcrt.lib, kernel32.lib, etc. If course there must be another side to that. "vcvars32.bat" and such sets %PATH% so that cl and link are on it, sets %INCLUDE% so that the various headers are on it, and %LIB% so that various .libs are on it. My sysinfo.cmd also prepends %ROOT%\lib or whatever to %LIB%, as cm3\m3-win\import-libs makes our own import .libs, since some toolsets, like at least the 7.1 Express Edition and I think 8.0, lack most the usual import .libs -- like they are enough for managed CLR development and "stdio" development, but not native Win32 development. The Platform SDK is also a free download, so I'm not replacing something you can't get for free, but it saves you an extra download and install, perhaps. There are pluses and minuses to this arrangement. I guess you can point cm3.exe at a specific cm3.cfg file? I never do that. Rather than have n different configurations, I have one configuration but vary the environment variables. The downside is that in a "bare" environment, nothing works. Unless you go and foist the vcvars32.bat onto your default environment. There is large general problem around settings, state, install (sometimes called "deployment) that has yet to be solved to most people's satisfaction. This is very much related to that. Environment variables are an ancient crude mechanism, lacking in type, lacking in hierarchy. Their main claims to fame include a) basically the same mechanism on Unix and Win32 b) inheritance through a process tree.) They don't scale well I believe. Anyway, I'm not going to solve this and I doubt any of you will either. Given that the spaces end up buried in %PATH%, %LIB%, and %INCLUDE%, where cmd, cl, link look and can cope, but where cm3 itself doesn't look at, the space problem is solved. I install to \msdev\10 \msdev\15 \msdev\20 \msdev\40 \msdev\41 \msdev\42 \msdev\50 \msdev\60 \msdev\70 \msdev\71 \msdev\80 \mwerks\6 (metrowerks, not that I use it much) \mwerks\7 \mwerks\8 \dm or \dmars (digital mars, no versioning) \cygwin (the default, no versioning) \mingwin (the default, no versioning) etc. I haven't yet settled on a grand unified file system layout for myself, though I do obsess over it, and sometimes give in to the defaults, can't fight every battle, not as often as I resetup machines.. and I haven't figured out what to do about source control and tools. Ideally, you checkin all your tools, but I'm not sure what that implies for copyright, esp. given a hosted source control system I don't control, and it'll bloat up my cheap hosted source control.. I do let the Platform SDK install to its default like \Program Files\Microsoft Platform SDK R2. Bootstrapping current source from the 5.2.6 "min" binary distribution should work. I tested this last night. Should work from the larger "std", "core", etc. whatever there is. I didn't try anything before 5.2.6. There is a question as to which toolsets to support -- which toolset to build the distribution with. The older you pick, the more reach you have to people using older toolsets. However there seems to only be about three of us so I'm barking up a very hypothetical tree.. :( As well a question as to what you can bootstrap with, which Modula-3 tools. I imagine the more you go back, the more contorted things get, and there might be really nothing to gain. Just pick the most recent good enough version and don't care about anything older? Look forward not backward? I haven't seen many problems with %TEMP% and %TMP%. They do often somewhere get changed to short paths. But I did recently have a problem with spaces in them. Realize that "short paths" are NOT predictable. And, btw, they aren't even necessarily "shorter" than the "long" path, though they do lack spaces, etc. Try this: mkdir \1.1.1 dir /x \1* - Jay Date: Fri, 30 Nov 2007 17:24:25 -0500From: rcoleburn at scires.comTo: jay.krell at cornell.edu; m3devel at elegosoft.comSubject: Re: [M3devel] some more notes on the win32 system Jay: Thanks for all your help. Actually, the last time I tried to install cm3, I used the 5.26 tarballs and tried to build, but ran into some compile errors. I'll try it again and report back the actual errors I get (if any). As for Microsoft Visual Studio, yes I'm familiar with setting it up. Are you saying that the cm3install program should no longer be used? I've used this in the past. The big issue I've run into is making sure to give old style 8.3 pathnames without spaces and to edit the cm3.cfg file to find all the libraries and stuff using paths without spaces. I've also set some environment vars, in particular the TEMP and TMP vars, to use paths without spaces. I will try to be very careful to document everything I do in great detail. Perhaps we can use this to give out a better recipe to folks on how to get cm3 working on Windows. Regards, Randy>>> Jay 11/29/2007 8:48 PM >>>some more notes on the win32 system> setup your C++ compiler/linkerYou can/should "play dumb", skip that, and just run upgrade.See what errors you get.I tried to put in the right amount of up front sanity checking.What you need in particular arecl and link on the %PATH%. See, cminstall would have you specify full paths, my configuration uses %PATH%.If using VS2005 (8) or newer, mt on the path.%LIB% is a semicolon delimited list of directories.That is a feature of the Microsoft linker.msvcrt.lib must be in one of them.Any 32 bit version of Visual C++ -- 2.0, 4.0,, 4.1, 4.2, 5.0, 6.0, 7.0, 7.1, 8.0 -- should work.I have tested all of them some and many required small changes in one particular spot, that actually is only used by "maintainers" (C:\dev2\cm3\m3-win\import-libs\src\make-lib-1.cmd).I use 8.0 the most lately.I haven't done much with 9.0. Another thing, fairly redundant: C:\dev2\cm3\m3-win>more vcredist.txtOn computers without Visual C++ 2005 or CLR 2.0 installed, download and run the setup for the Visual C++ runtime -- vcredist_x86.exe -- from either RTM (release to manufacturing): http://www.microsoft.com/downloads/details.aspx?familyid=32BC1BEE-A3F9-4C13-9C99-220B62A191EE or Service Pack 1: http://www.microsoft.com/downloads/details.aspx?FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647You can find those searching the web for vcredist, no real need to recort the URLs. That's about it. - Jay Your smile counts. The more smiles you share, the more we donate. Join in! _________________________________________________________________ Your smile counts. The more smiles you share, the more we donate.? Join in. www.windowslive.com/smile?ocid=TXT_TAGLM_Wave2_oprsmilewlhmtagline -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Dec 1 14:15:47 2007 From: jay.krell at cornell.edu (Jay) Date: Sat, 1 Dec 2007 13:15:47 +0000 Subject: [M3devel] returning record by value vs. by ref? Message-ID: This is a language question based on the x86 code gen.It isn't a code gen question at all, just related to m3 constructs the code gen happens to use. The code gen has a stack of operands, I've said many times. This is partly made up. type loc_t = [ imm, reg, mvar ] (* location: variable in memory, register, immediate/constant *) type reg_t = [ eax, esi, edi, ...] (* register *) type operand_t = record loc : loc_t; reg : reg_t; imm : integer; (* immediate or constant *) (* some data associated with mvar... *) end; The type is a bit bigger than this, and that is relevant. interface stack allows access both to entire operands, or their fields, based on an index into the stack. The stack is not fixed size. I think this becomes important. Pardon my mix of M3, C, C++ and made up syntax. interface and module stack; private s: array of operand; procedure getloc(n: integer) : loc_t = begin return s[n].loc; end getloc; procedure getimm(n: integer) : INTEGER = begin return s[n].imm; end getimm; procedure getreg(n: integer) : reg_t = begin return s[n].reg; end getreg; procedure getop(n: integer) : operand_t = (* get entire operand *) begin return s[n]; end getop; A cursory read of the source code, not yet of the object code, from the point of view of a C/C++ programmersays to me that this last function getop returns a copy of an entire record. Again, the record is a bit largerthan this. I made it still larger, and I started getting warnings about that. What I would really like is for getop to return the operands by pointer. procedure getop(n: integer) : REF operand_t = (* get entire operand *) begin return s[n]; end getop; From my point of view, this is very natural. And far more efficient. But I couldn't get anything to compile along these lines. Now, as I said, the stack does grow sometimes, so the array could get realloced, and outstanding pointers invalidated. I guess that is the point? You can't "safely" get a pointer? I could make it an array of REFs I guess, heap-fragmentation-unfriendly, but given that it grows rarely, probably ok. I guess maybe gcc does a good job with this stuff? Optimzing away the copies, inlining the array access, etc.? Thoughts? One just needs to get over worrying about the perf at this level for one's sanity to survive programming in Modula-3? Safe languages are simply stuck with either a lot of garbage collected separate heap allocations or a lot of copying? Pointers as I think about them exude "danger" all over the place? (Yes, I know that "safely" and "danger" are technical terms and I know what they mean, at least roughly, no dangling pointers to stack, no double frees, no unbounded array access, no unchecked type conversions, the system remains type safe and the rules of the language remain unbroken, however I live and breathe C/C++ so it is hard to adjust my mindset, even if I understand the issues fairly deeply.) The problem one runs into, is that of the pretty darn good C and C++ programmers who, whilenot perfect, are pretty darn good. A "safe" language throws you to quite an extremeof perf compromise to nail the last little bit of guaranteed safety, when you really weren't doing sucha bad job in the first place through brute force of careful coding.. You pay a lot for a little.Lesser programmers, sure, they need the hand holding... I've been experimenting lately, and C just isn't actually all that bad.Ok, actually most recently I'm writing more Perl, also not bad.See, there's another extreme. Traditional and semi-traditional languageand compilation systems like C and Modula-3 and even Java and C# actuallyobsess far more about performance than many many problems need.Perl (Python, Ruby presumably, but Perl is the only one available to me,that has cleared legal/licensing hurdles) is plenty adequate for tons of tasks.If my task requires some i/o, then i/o cost might dominate the overall perf cost... I realize I'm all over the place here, arguing for and against optimizing. I don't like Perl's funny characters, or lack of a standard OO approach,(using hash tables for everything really is bad..) but it's still surprisingly good.I noticed some job descriptions lately for Perl programmers that specificallysaid they were not "scripting" jobs but, like, real industrial strength software engineering.I think those people get it.You get to a certain point of general purposeness and performance and hopefullystatic checking, and a lot things don't matter as much as people think.... Anyway. - Jay _________________________________________________________________ Share life as it happens with the new Windows Live.Download today it's FREE! http://www.windowslive.com/share.html?ocid=TXT_TAGLM_Wave2_sharelife_112007 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Dec 1 17:03:44 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 1 Dec 2007 11:03:44 -0500 Subject: [M3devel] returning record by value vs. by ref? In-Reply-To: References: Message-ID: <1560FF15-8486-4388-ADAE-FADCF71FC5F3@cs.purdue.edu> I am assuming 's' here is an open array (REF ARRAY OF item) in which case it is allocated in the GC'd heap. There is certainly no way of safely getting an interior pointer to items in the stack in Modula-3 -- at least not one that you can upward expose (to callers) via return from a procedure. The difficulty in doing this is that the GC moves objects around and would need to know where your manufactured interior pointer is being held and to which *object* (ie, the open array in this case) it refers so that it can 'fix' the pointer when the array object moves. Modula-3 provides a small concession to obtaining downward exposed interior pointers using the VAR parameter mode. For example you can pass 's[i]' as an actual parameter to a VAR mode formal, effectively passing a pointer to the callee. GC can cope with this in one of two possible ways: 1) "Pin" the array so that it cannot be moved while the interior pointer is held on the stack or registers of any thread (this is the approach that CM3's conservative collector uses for now); or 2) track the creation of such interior pointers and how they are derived from base object references for use during GC. 2) requires much more co-operation from the compiler than the current gcc-based backend (with all of its lovely optimizations and register allocation) is capable of doing. 1) is very cheap and does not impede optimizations and register allocation. On Dec 1, 2007, at 8:15 AM, Jay wrote: > This is a language question based on the x86 code gen. > It isn't a code gen question at all, just related to m3 constructs > the code gen happens to use. > > The code gen has a stack of operands, I've said many times. > > This is partly made up. > > type loc_t = [ imm, reg, mvar ] (* location: variable in memory, > register, immediate/constant *) > type reg_t = [ eax, esi, edi, ...] (* register *) > > type operand_t = record > loc : loc_t; > reg : reg_t; > imm : integer; (* immediate or constant *) > (* some data associated with mvar... *) > end; > > The type is a bit bigger than this, and that is relevant. > > interface stack allows access both to entire operands, or their > fields, based on an index into the stack. > > The stack is not fixed size. I think this becomes important. > > Pardon my mix of M3, C, C++ and made up syntax. > > interface and module stack; > > private s: array of operand; > > procedure getloc(n: integer) : loc_t = > begin > return s[n].loc; > end getloc; > > procedure getimm(n: integer) : INTEGER = > begin > return s[n].imm; > end getimm; > > procedure getreg(n: integer) : reg_t = > begin > return s[n].reg; > end getreg; > > procedure getop(n: integer) : operand_t = (* get entire operand *) > begin > return s[n]; > end getop; > > A cursory read of the source code, not yet of the object code, > from the point of view of a C/C++ programmer > says to me that this last function getop returns a copy of an > entire record. Again, the record is a bit larger > than this. I made it still larger, and I started getting warnings > about that. > > What I would really like is for getop to return the operands by > pointer. > > procedure getop(n: integer) : REF operand_t = (* get entire > operand *) > begin > return s[n]; > end getop; > > From my point of view, this is very natural. And far more efficient. > But I couldn't get anything to compile along these lines. > > Now, as I said, the stack does grow sometimes, so the array could > get realloced, and outstanding > pointers invalidated. I guess that is the point? You can't > "safely" get a pointer? > I could make it an array of REFs I guess, heap-fragmentation- > unfriendly, but given that it grows > rarely, probably ok. > > I guess maybe gcc does a good job with this stuff? Optimzing away > the copies, inlining the array access, etc.? > > Thoughts? > One just needs to get over worrying about the perf at this level > for one's sanity > to survive programming in Modula-3? > > Safe languages are simply stuck with either a lot of garbage > collected separate heap allocations > or a lot of copying? Pointers as I think about them exude "danger" > all over the place? > (Yes, I know that "safely" and "danger" are technical terms and I > know what they mean, > at least roughly, no dangling pointers to stack, no double frees, > no unbounded > array access, no unchecked type conversions, the system remains > type safe and > the rules of the language remain unbroken, however I live and > breathe C/C++ so it > is hard to adjust my mindset, even if I understand the issues > fairly deeply.) > > The problem one runs into, is that of the pretty darn good C and C+ > + programmers who, while > not perfect, are pretty darn good. A "safe" language throws you to > quite an extreme > of perf compromise to nail the last little bit of guaranteed > safety, when you really weren't doing such > a bad job in the first place through brute force of careful > coding.. You pay a lot for a little. > Lesser programmers, sure, they need the hand holding... > > I've been experimenting lately, and C just isn't actually all that > bad. > Ok, actually most recently I'm writing more Perl, also not bad. > See, there's another extreme. Traditional and semi-traditional > language > and compilation systems like C and Modula-3 and even Java and C# > actually > obsess far more about performance than many many problems need. > Perl (Python, Ruby presumably, but Perl is the only one available > to me, > that has cleared legal/licensing hurdles) is plenty adequate for > tons of tasks. > If my task requires some i/o, then i/o cost might dominate the > overall perf cost... > > I realize I'm all over the place here, arguing for and against > optimizing. > > I don't like Perl's funny characters, or lack of a standard OO > approach, > (using hash tables for everything really is bad..) but it's still > surprisingly good. > I noticed some job descriptions lately for Perl programmers that > specifically > said they were not "scripting" jobs but, like, real industrial > strength software engineering. > I think those people get it. > You get to a certain point of general purposeness and performance > and hopefully > static checking, and a lot things don't matter as much as people > think.... > > Anyway. > - Jay > > > Share life as it happens with the new Windows Live. Share now! From rodney.bates at wichita.edu Sat Dec 1 20:31:39 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Sat, 01 Dec 2007 13:31:39 -0600 Subject: [M3devel] returning record by value vs. by ref? In-Reply-To: <1560FF15-8486-4388-ADAE-FADCF71FC5F3@cs.purdue.edu> References: <1560FF15-8486-4388-ADAE-FADCF71FC5F3@cs.purdue.edu> Message-ID: <4751B69B.1090907@wichita.edu> Tony Hosking wrote: > I am assuming 's' here is an open array (REF ARRAY OF item) in which > case it is allocated in the GC'd heap. There is certainly no way of > safely getting an interior pointer to items in the stack in Modula-3 -- > at least not one that you can upward expose (to callers) via return > from a procedure. The difficulty in doing this is that the GC moves > objects around and would need to know where your manufactured interior > pointer is being held and to which *object* (ie, the open array in this > case) it refers so that it can 'fix' the pointer when the array object > moves. Modula-3 provides a small concession to obtaining downward > exposed interior pointers using the VAR parameter mode. For example > you can pass 's[i]' as an actual parameter to a VAR mode formal, > effectively passing a pointer to the callee. GC can cope with this in > one of two possible ways: 1) "Pin" the array so that it cannot be moved > while the interior pointer is held on the stack or registers of any > thread (this is the approach that CM3's conservative collector uses for > now); or 2) track the creation of such interior pointers and how they > are derived from base object references for use during GC. 2) requires > much more co-operation from the compiler than the current gcc-based > backend (with all of its lovely optimizations and register allocation) > is capable of doing. 1) is very cheap and does not impede > optimizations and register allocation. > Presumably, this all also applies WITH-bound identifiers, when they are designators of interior components of heap objects? Are there any other cases? -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From hosking at cs.purdue.edu Sat Dec 1 21:23:19 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 1 Dec 2007 15:23:19 -0500 Subject: [M3devel] returning record by value vs. by ref? In-Reply-To: <4751B69B.1090907@wichita.edu> References: <1560FF15-8486-4388-ADAE-FADCF71FC5F3@cs.purdue.edu> <4751B69B.1090907@wichita.edu> Message-ID: Correct! Anytime you create an l-value pointer. On Dec 1, 2007, at 2:31 PM, Rodney M. Bates wrote: > Tony Hosking wrote: >> I am assuming 's' here is an open array (REF ARRAY OF item) in >> which case it is allocated in the GC'd heap. There is certainly >> no way of safely getting an interior pointer to items in the >> stack in Modula-3 -- at least not one that you can upward expose >> (to callers) via return from a procedure. The difficulty in >> doing this is that the GC moves objects around and would need to >> know where your manufactured interior pointer is being held and >> to which *object* (ie, the open array in this case) it refers so >> that it can 'fix' the pointer when the array object moves. >> Modula-3 provides a small concession to obtaining downward >> exposed interior pointers using the VAR parameter mode. For >> example you can pass 's[i]' as an actual parameter to a VAR mode >> formal, effectively passing a pointer to the callee. GC can cope >> with this in one of two possible ways: 1) "Pin" the array so that >> it cannot be moved while the interior pointer is held on the >> stack or registers of any thread (this is the approach that CM3's >> conservative collector uses for now); or 2) track the creation of >> such interior pointers and how they are derived from base object >> references for use during GC. 2) requires much more co-operation >> from the compiler than the current gcc-based backend (with all of >> its lovely optimizations and register allocation) is capable of >> doing. 1) is very cheap and does not impede optimizations and >> register allocation. > > Presumably, this all also applies WITH-bound identifiers, when they > are > designators of interior components of heap objects? Are there any > other > cases? > > -- > ------------------------------------------------------------- > Rodney M. Bates, retired assistant professor > Dept. of Computer Science, Wichita State University > Wichita, KS 67260-0083 > 316-978-3922 > rodney.bates at wichita.edu From jay.krell at cornell.edu Sat Dec 1 23:14:18 2007 From: jay.krell at cornell.edu (Jay) Date: Sat, 1 Dec 2007 22:14:18 +0000 Subject: [M3devel] returning record by value vs. by ref? In-Reply-To: References: <1560FF15-8486-4388-ADAE-FADCF71FC5F3@cs.purdue.edu> <4751B69B.1090907@wichita.edu> Message-ID: 1) Can pinning not be exposed reasonably in the language? I'll keep my pointer just a short time, in a local. 2) surely it could be done at an outer layer? Make volatile locals for things you don't want enregistered? Even the accessor function approach seems lame, given that I believe the Win32/x86 compiler doesn't inline.. :( (does the gcc m3 inline across modules, or just compiles one at a time?) - Jay > CC: jay.krell at cornell.edu; m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] returning record by value vs. by ref?> Date: Sat, 1 Dec 2007 15:23:19 -0500> To: rodney.bates at wichita.edu> > Correct! Anytime you create an l-value pointer.> > On Dec 1, 2007, at 2:31 PM, Rodney M. Bates wrote:> > > Tony Hosking wrote:> >> I am assuming 's' here is an open array (REF ARRAY OF item) in > >> which case it is allocated in the GC'd heap. There is certainly > >> no way of safely getting an interior pointer to items in the > >> stack in Modula-3 -- at least not one that you can upward expose > >> (to callers) via return from a procedure. The difficulty in > >> doing this is that the GC moves objects around and would need to > >> know where your manufactured interior pointer is being held and > >> to which *object* (ie, the open array in this case) it refers so > >> that it can 'fix' the pointer when the array object moves. > >> Modula-3 provides a small concession to obtaining downward > >> exposed interior pointers using the VAR parameter mode. For > >> example you can pass 's[i]' as an actual parameter to a VAR mode > >> formal, effectively passing a pointer to the callee. GC can cope > >> with this in one of two possible ways: 1) "Pin" the array so that > >> it cannot be moved while the interior pointer is held on the > >> stack or registers of any thread (this is the approach that CM3's > >> conservative collector uses for now); or 2) track the creation of > >> such interior pointers and how they are derived from base object > >> references for use during GC. 2) requires much more co-operation > >> from the compiler than the current gcc-based backend (with all of > >> its lovely optimizations and register allocation) is capable of > >> doing. 1) is very cheap and does not impede optimizations and > >> register allocation.> >> > Presumably, this all also applies WITH-bound identifiers, when they > > are> > designators of interior components of heap objects? Are there any > > other> > cases?> >> > -- > > -------------------------------------------------------------> > Rodney M. Bates, retired assistant professor> > Dept. of Computer Science, Wichita State University> > Wichita, KS 67260-0083> > 316-978-3922> > rodney.bates at wichita.edu> _________________________________________________________________ Your smile counts. The more smiles you share, the more we donate.? Join in. www.windowslive.com/smile?ocid=TXT_TAGLM_Wave2_oprsmilewlhmtagline -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Dec 1 23:19:46 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 1 Dec 2007 17:19:46 -0500 Subject: [M3devel] returning record by value vs. by ref? In-Reply-To: References: <1560FF15-8486-4388-ADAE-FADCF71FC5F3@cs.purdue.edu> <4751B69B.1090907@wichita.edu> Message-ID: On Dec 1, 2007, at 5:14 PM, Jay wrote: > 1) Can pinning not be exposed reasonably in the language? > I'll keep my pointer just a short time, in a local. Yes, that is a *hack* that will work only with the current conservative garbage collector. In general, the compiler might record that the local is a pointer derived from some base reference and if the GC decides to move the base object it can adjust the local derived pointer accordingly. > 2) surely it could be done at an outer layer? > Make volatile locals for things you don't want enregistered? I don't understand what you mean by this. > Even the accessor function approach seems lame, given that I > believe the Win32/x86 compiler doesn't inline.. :( > (does the gcc m3 inline across modules, or just compiles one at a > time?) gcc m3 inlines only within compilation units. > > > - Jay > > > > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] returning record by value vs. by ref? > > Date: Sat, 1 Dec 2007 15:23:19 -0500 > > To: rodney.bates at wichita.edu > > > > Correct! Anytime you create an l-value pointer. > > > > On Dec 1, 2007, at 2:31 PM, Rodney M. Bates wrote: > > > > > Tony Hosking wrote: > > >> I am assuming 's' here is an open array (REF ARRAY OF item) in > > >> which case it is allocated in the GC'd heap. There is certainly > > >> no way of safely getting an interior pointer to items in the > > >> stack in Modula-3 -- at least not one that you can upward expose > > >> (to callers) via return from a procedure. The difficulty in > > >> doing this is that the GC moves objects around and would need to > > >> know where your manufactured interior pointer is being held and > > >> to which *object* (ie, the open array in this case) it refers so > > >> that it can 'fix' the pointer when the array object moves. > > >> Modula-3 provides a small concession to obtaining downward > > >> exposed interior pointers using the VAR parameter mode. For > > >> example you can pass 's[i]' as an actual parameter to a VAR mode > > >> formal, effectively passing a pointer to the callee. GC can cope > > >> with this in one of two possible ways: 1) "Pin" the array so that > > >> it cannot be moved while the interior pointer is held on the > > >> stack or registers of any thread (this is the approach that CM3's > > >> conservative collector uses for now); or 2) track the creation of > > >> such interior pointers and how they are derived from base object > > >> references for use during GC. 2) requires much more co-operation > > >> from the compiler than the current gcc-based backend (with all of > > >> its lovely optimizations and register allocation) is capable of > > >> doing. 1) is very cheap and does not impede optimizations and > > >> register allocation. > > > > > > Presumably, this all also applies WITH-bound identifiers, when > they > > > are > > > designators of interior components of heap objects? Are there any > > > other > > > cases? > > > > > > -- > > > ------------------------------------------------------------- > > > Rodney M. Bates, retired assistant professor > > > Dept. of Computer Science, Wichita State University > > > Wichita, KS 67260-0083 > > > 316-978-3922 > > > rodney.bates at wichita.edu > > > > > Your smile counts. The more smiles you share, the more we donate. > Join in! From jay.krell at cornell.edu Sat Dec 1 23:36:03 2007 From: jay.krell at cornell.edu (Jay) Date: Sat, 1 Dec 2007 22:36:03 +0000 Subject: [M3devel] returning record by value vs. by ref? In-Reply-To: References: <1560FF15-8486-4388-ADAE-FADCF71FC5F3@cs.purdue.edu> <4751B69B.1090907@wichita.edu> Message-ID: > 2, don't understand You said it'd take much cooperation with the compiler, due its optimizations, but optimizations can be defeated as necessary. Interior pointers could be marked, perhaps, volatile, so prevent enregistration. I can see that's a potentially high cost though. like Record_t *Record = GetRecord(); unsigned i; for (i = 0 ; i != Record->j ; ++i) { ... } You'd really like Record->j to not be refetched for every loop iteration, but if Record is volatile so the GC can move what it points to and update outstanding pointers, you'd be stuck with something like that. Besides, if j can't be read in one instruction, more problems, assuming a concurrent GC, that cannot reliably get/set the context of other threads. I think, like, you could reliably get/set context on a uniprocessor system, but not a multiprocessor. You'd have to suspend, wait for the suspend to happen.. I guess that could work, but it seems like you'd want to avoid designs that require suspending threads. ? Hm. No, it's difficult. This being a short lived pointer, gc happening on another thread, you'd have to, like, "register" its location with the gc. Hm. Just how does it work? gc suspends threads and updates variables? I don't think so. Variables that are moved leave some sort of "forwarding address" for holders of the old value? The gc isn't concurrent but is called at function entry/exit? I don't think so. I should check the docs and code.. - Jay > From: hosking at cs.purdue.edu> Date: Sat, 1 Dec 2007 17:19:46 -0500> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] returning record by value vs. by ref?> > > On Dec 1, 2007, at 5:14 PM, Jay wrote:> > > 1) Can pinning not be exposed reasonably in the language?> > I'll keep my pointer just a short time, in a local.> > Yes, that is a *hack* that will work only with the current > conservative garbage collector. In general, the compiler might > record that the local is a pointer derived from some base reference > and if the GC decides to move the base object it can adjust the local > derived pointer accordingly.> > > 2) surely it could be done at an outer layer?> > Make volatile locals for things you don't want enregistered?> > I don't understand what you mean by this.> > > Even the accessor function approach seems lame, given that I > > believe the Win32/x86 compiler doesn't inline.. :(> > (does the gcc m3 inline across modules, or just compiles one at a > > time?)> > gcc m3 inlines only within compilation units.> > >> >> > - Jay> >> >> > > CC: jay.krell at cornell.edu; m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > Subject: Re: [M3devel] returning record by value vs. by ref?> > > Date: Sat, 1 Dec 2007 15:23:19 -0500> > > To: rodney.bates at wichita.edu> > >> > > Correct! Anytime you create an l-value pointer.> > >> > > On Dec 1, 2007, at 2:31 PM, Rodney M. Bates wrote:> > >> > > > Tony Hosking wrote:> > > >> I am assuming 's' here is an open array (REF ARRAY OF item) in> > > >> which case it is allocated in the GC'd heap. There is certainly> > > >> no way of safely getting an interior pointer to items in the> > > >> stack in Modula-3 -- at least not one that you can upward expose> > > >> (to callers) via return from a procedure. The difficulty in> > > >> doing this is that the GC moves objects around and would need to> > > >> know where your manufactured interior pointer is being held and> > > >> to which *object* (ie, the open array in this case) it refers so> > > >> that it can 'fix' the pointer when the array object moves.> > > >> Modula-3 provides a small concession to obtaining downward> > > >> exposed interior pointers using the VAR parameter mode. For> > > >> example you can pass 's[i]' as an actual parameter to a VAR mode> > > >> formal, effectively passing a pointer to the callee. GC can cope> > > >> with this in one of two possible ways: 1) "Pin" the array so that> > > >> it cannot be moved while the interior pointer is held on the> > > >> stack or registers of any thread (this is the approach that CM3's> > > >> conservative collector uses for now); or 2) track the creation of> > > >> such interior pointers and how they are derived from base object> > > >> references for use during GC. 2) requires much more co-operation> > > >> from the compiler than the current gcc-based backend (with all of> > > >> its lovely optimizations and register allocation) is capable of> > > >> doing. 1) is very cheap and does not impede optimizations and> > > >> register allocation.> > > >> > > > Presumably, this all also applies WITH-bound identifiers, when > > they> > > > are> > > > designators of interior components of heap objects? Are there any> > > > other> > > > cases?> > > >> > > > --> > > > -------------------------------------------------------------> > > > Rodney M. Bates, retired assistant professor> > > > Dept. of Computer Science, Wichita State University> > > > Wichita, KS 67260-0083> > > > 316-978-3922> > > > rodney.bates at wichita.edu> > >> >> >> > Your smile counts. The more smiles you share, the more we donate. > > Join in!> _________________________________________________________________ Put your friends on the big screen with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_102007 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Dec 1 23:42:02 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 1 Dec 2007 17:42:02 -0500 Subject: [M3devel] returning record by value vs. by ref? In-Reply-To: References: <1560FF15-8486-4388-ADAE-FADCF71FC5F3@cs.purdue.edu> <4751B69B.1090907@wichita.edu> Message-ID: If this really interests you then you might read this paper: http:// doi.acm.org/10.1145/143095.143140 . On Dec 1, 2007, at 5:36 PM, Jay wrote: > > 2, don't understand > > You said it'd take much cooperation with the compiler, due its > optimizations, but optimizations can be defeated as necessary. > Interior pointers could be marked, perhaps, volatile, so prevent > enregistration. I can see that's a potentially high cost though. > > like > Record_t *Record = GetRecord(); > unsigned i; > for (i = 0 ; i != Record->j ; ++i) > { > ... > } > > You'd really like Record->j to not be refetched for every loop > iteration, but if Record is volatile so the GC can move what it > points to and update outstanding pointers, you'd be stuck with > something like that. Besides, if j can't be read in one > instruction, more problems, assuming a concurrent GC, that cannot > reliably get/set the context of other threads. I think, like, you > could reliably get/set context on a uniprocessor system, but not a > multiprocessor. You'd have to suspend, wait for the suspend to > happen.. I guess that could work, but it seems like you'd want to > avoid designs that require suspending threads. ? > Hm. No, it's difficult. This being a short lived pointer, gc > happening on another thread, you'd have to, like, "register" its > location with the gc. > > Hm. Just how does it work? > > gc suspends threads and updates variables? I don't think so. > > Variables that are moved leave some sort of "forwarding address" > for holders of the old value? > > The gc isn't concurrent but is called at function entry/exit? I > don't think so. > > I should check the docs and code.. > > - Jay > > > > > From: hosking at cs.purdue.edu > > Date: Sat, 1 Dec 2007 17:19:46 -0500 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] returning record by value vs. by ref? > > > > > > On Dec 1, 2007, at 5:14 PM, Jay wrote: > > > > > 1) Can pinning not be exposed reasonably in the language? > > > I'll keep my pointer just a short time, in a local. > > > > Yes, that is a *hack* that will work only with the current > > conservative garbage collector. In general, the compiler might > > record that the local is a pointer derived from some base reference > > and if the GC decides to move the base object it can adjust the > local > > derived pointer accordingly. > > > > > 2) surely it could be done at an outer layer? > > > Make volatile locals for things you don't want enregistered? > > > > I don't understand what you mean by this. > > > > > Even the accessor function approach seems lame, given that I > > > believe the Win32/x86 compiler doesn't inline.. :( > > > (does the gcc m3 inline across modules, or just compiles one at a > > > time?) > > > > gcc m3 inlines only within compilation units. > > > > > > > > > > > - Jay > > > > > > > > > > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > > > > From: hosking at cs.purdue.edu > > > > Subject: Re: [M3devel] returning record by value vs. by ref? > > > > Date: Sat, 1 Dec 2007 15:23:19 -0500 > > > > To: rodney.bates at wichita.edu > > > > > > > > Correct! Anytime you create an l-value pointer. > > > > > > > > On Dec 1, 2007, at 2:31 PM, Rodney M. Bates wrote: > > > > > > > > > Tony Hosking wrote: > > > > >> I am assuming 's' here is an open array (REF ARRAY OF > item) in > > > > >> which case it is allocated in the GC'd heap. There is > certainly > > > > >> no way of safely getting an interior pointer to items in the > > > > >> stack in Modula-3 -- at least not one that you can upward > expose > > > > >> (to callers) via return from a procedure. The difficulty in > > > > >> doing this is that the GC moves objects around and would > need to > > > > >> know where your manufactured interior pointer is being > held and > > > > >> to which *object* (ie, the open array in this case) it > refers so > > > > >> that it can 'fix' the pointer when the array object moves. > > > > >> Modula-3 provides a small concession to obtaining downward > > > > >> exposed interior pointers using the VAR parameter mode. For > > > > >> example you can pass 's[i]' as an actual parameter to a > VAR mode > > > > >> formal, effectively passing a pointer to the callee. GC > can cope > > > > >> with this in one of two possible ways: 1) "Pin" the array > so that > > > > >> it cannot be moved while the interior pointer is held on the > > > > >> stack or registers of any thread (this is the approach > that CM3's > > > > >> conservative collector uses for now); or 2) track the > creation of > > > > >> such interior pointers and how they are derived from base > object > > > > >> references for use during GC. 2) requires much more co- > operation > > > > >> from the compiler than the current gcc-based backend (with > all of > > > > >> its lovely optimizations and register allocation) is > capable of > > > > >> doing. 1) is very cheap and does not impede optimizations and > > > > >> register allocation. > > > > > > > > > > Presumably, this all also applies WITH-bound identifiers, when > > > they > > > > > are > > > > > designators of interior components of heap objects? Are > there any > > > > > other > > > > > cases? > > > > > > > > > > -- > > > > > ------------------------------------------------------------- > > > > > Rodney M. Bates, retired assistant professor > > > > > Dept. of Computer Science, Wichita State University > > > > > Wichita, KS 67260-0083 > > > > > 316-978-3922 > > > > > rodney.bates at wichita.edu > > > > > > > > > > > > > Your smile counts. The more smiles you share, the more we donate. > > > Join in! > > > > > Get the power of Windows + Web with the new Windows Live. Power up! From jay.krell at cornell.edu Sun Dec 2 05:11:04 2007 From: jay.krell at cornell.edu (Jay) Date: Sun, 2 Dec 2007 04:11:04 +0000 Subject: [M3devel] returning record by value vs. by ref? In-Reply-To: References: <1560FF15-8486-4388-ADAE-FADCF71FC5F3@cs.purdue.edu> <4751B69B.1090907@wichita.edu> Message-ID: Thanks! I haven't finished reading it, but it sounds like an optimizing compiler is ok, due to the reliance on "gc points", which I read ahead to find out how they are defined. And I'm GUESSING that CM3 already generates and depends on the sort of data described there. But maybe not. I wonder what the size of the data looks like if you allow a gc point at every instruction. I guess it probably be too large -- figure a byte or two extra for every instruction, but maybe not. Perhaps it could be encoded in bits instead of bytes and given that most instructions don't affect the state (ie: operations on integers, floats, comparisons, branches), maybe just a zero bit for most instructions. So then figure a byte or two for every instruction that moves (load or store) or adds/substracts a pointer. Or more than that. A byte or two could describe enregistration and small adds/subtracts, but not large adds/subtracts or memory offsets. OR perhaps it'd just read the code itself. That's easier with Win32/x86 since it is so constrained as to what it outputs. That should be feasible. I realize I'm changing subjects between the different backends. The Windows AMD64 calling convention relies on something LIKE this. In particular, there is a little encoding associated with every prolog/epilog so that exception handling can undo the prolog's effects. It describes a tiny subset of the instruction set, like register moves. Kind of funny -- once you get into the business of wanting to read the code to know what it does, you then get tempted to define your own code, for runtime and information, and then a possible trick is to adopt the existing machine code as your code, or whatever subset your compiler produces. Hm. The existing machine isn't sufficient. You would need type information to augment it. Which reminds. Another OBVIOUS backend for CM3 for easier portability is to persist the calls to m3cg and then write an interpreter for that in C. - Jay > From: hosking at cs.purdue.edu> Date: Sat, 1 Dec 2007 17:42:02 -0500> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] returning record by value vs. by ref?> > If this really interests you then you might read this paper: http:// > doi.acm.org/10.1145/143095.143140 .> > On Dec 1, 2007, at 5:36 PM, Jay wrote:> > > > 2, don't understand> >> > You said it'd take much cooperation with the compiler, due its > > optimizations, but optimizations can be defeated as necessary.> > Interior pointers could be marked, perhaps, volatile, so prevent > > enregistration. I can see that's a potentially high cost though.> >> > like> > Record_t *Record = GetRecord();> > unsigned i;> > for (i = 0 ; i != Record->j ; ++i)> > {> > ...> > }> >> > You'd really like Record->j to not be refetched for every loop > > iteration, but if Record is volatile so the GC can move what it > > points to and update outstanding pointers, you'd be stuck with > > something like that. Besides, if j can't be read in one > > instruction, more problems, assuming a concurrent GC, that cannot > > reliably get/set the context of other threads. I think, like, you > > could reliably get/set context on a uniprocessor system, but not a > > multiprocessor. You'd have to suspend, wait for the suspend to > > happen.. I guess that could work, but it seems like you'd want to > > avoid designs that require suspending threads. ?> > Hm. No, it's difficult. This being a short lived pointer, gc > > happening on another thread, you'd have to, like, "register" its > > location with the gc.> >> > Hm. Just how does it work?> >> > gc suspends threads and updates variables? I don't think so.> >> > Variables that are moved leave some sort of "forwarding address" > > for holders of the old value?> >> > The gc isn't concurrent but is called at function entry/exit? I > > don't think so.> >> > I should check the docs and code..> >> > - Jay> >> >> >> > > From: hosking at cs.purdue.edu> > > Date: Sat, 1 Dec 2007 17:19:46 -0500> > > To: jay.krell at cornell.edu> > > CC: m3devel at elegosoft.com> > > Subject: Re: [M3devel] returning record by value vs. by ref?> > >> > >> > > On Dec 1, 2007, at 5:14 PM, Jay wrote:> > >> > > > 1) Can pinning not be exposed reasonably in the language?> > > > I'll keep my pointer just a short time, in a local.> > >> > > Yes, that is a *hack* that will work only with the current> > > conservative garbage collector. In general, the compiler might> > > record that the local is a pointer derived from some base reference> > > and if the GC decides to move the base object it can adjust the > > local> > > derived pointer accordingly.> > >> > > > 2) surely it could be done at an outer layer?> > > > Make volatile locals for things you don't want enregistered?> > >> > > I don't understand what you mean by this.> > >> > > > Even the accessor function approach seems lame, given that I> > > > believe the Win32/x86 compiler doesn't inline.. :(> > > > (does the gcc m3 inline across modules, or just compiles one at a> > > > time?)> > >> > > gcc m3 inlines only within compilation units.> > >> > > >> > > >> > > > - Jay> > > >> > > >> > > > > CC: jay.krell at cornell.edu; m3devel at elegosoft.com> > > > > From: hosking at cs.purdue.edu> > > > > Subject: Re: [M3devel] returning record by value vs. by ref?> > > > > Date: Sat, 1 Dec 2007 15:23:19 -0500> > > > > To: rodney.bates at wichita.edu> > > > >> > > > > Correct! Anytime you create an l-value pointer.> > > > >> > > > > On Dec 1, 2007, at 2:31 PM, Rodney M. Bates wrote:> > > > >> > > > > > Tony Hosking wrote:> > > > > >> I am assuming 's' here is an open array (REF ARRAY OF > > item) in> > > > > >> which case it is allocated in the GC'd heap. There is > > certainly> > > > > >> no way of safely getting an interior pointer to items in the> > > > > >> stack in Modula-3 -- at least not one that you can upward > > expose> > > > > >> (to callers) via return from a procedure. The difficulty in> > > > > >> doing this is that the GC moves objects around and would > > need to> > > > > >> know where your manufactured interior pointer is being > > held and> > > > > >> to which *object* (ie, the open array in this case) it > > refers so> > > > > >> that it can 'fix' the pointer when the array object moves.> > > > > >> Modula-3 provides a small concession to obtaining downward> > > > > >> exposed interior pointers using the VAR parameter mode. For> > > > > >> example you can pass 's[i]' as an actual parameter to a > > VAR mode> > > > > >> formal, effectively passing a pointer to the callee. GC > > can cope> > > > > >> with this in one of two possible ways: 1) "Pin" the array > > so that> > > > > >> it cannot be moved while the interior pointer is held on the> > > > > >> stack or registers of any thread (this is the approach > > that CM3's> > > > > >> conservative collector uses for now); or 2) track the > > creation of> > > > > >> such interior pointers and how they are derived from base > > object> > > > > >> references for use during GC. 2) requires much more co- > > operation> > > > > >> from the compiler than the current gcc-based backend (with > > all of> > > > > >> its lovely optimizations and register allocation) is > > capable of> > > > > >> doing. 1) is very cheap and does not impede optimizations and> > > > > >> register allocation.> > > > > >> > > > > > Presumably, this all also applies WITH-bound identifiers, when> > > > they> > > > > > are> > > > > > designators of interior components of heap objects? Are > > there any> > > > > > other> > > > > > cases?> > > > > >> > > > > > --> > > > > > -------------------------------------------------------------> > > > > > Rodney M. Bates, retired assistant professor> > > > > > Dept. of Computer Science, Wichita State University> > > > > > Wichita, KS 67260-0083> > > > > > 316-978-3922> > > > > > rodney.bates at wichita.edu> > > > >> > > >> > > >> > > > Your smile counts. The more smiles you share, the more we donate.> > > > Join in!> > >> >> >> > Get the power of Windows + Web with the new Windows Live. Power up!> _________________________________________________________________ You keep typing, we keep giving. Download Messenger and join the i?m Initiative now. http://im.live.com/messenger/im/home/?source=TAGLM -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 2 06:16:05 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 2 Dec 2007 00:16:05 -0500 Subject: [M3devel] returning record by value vs. by ref? In-Reply-To: References: <1560FF15-8486-4388-ADAE-FADCF71FC5F3@cs.purdue.edu> <4751B69B.1090907@wichita.edu> Message-ID: <2B3B82B5-B989-4AC9-8156-02B3B8AC5B46@cs.purdue.edu> On Dec 1, 2007, at 11:11 PM, Jay wrote: > Thanks! > > I haven't finished reading it, but it sounds like an optimizing > compiler is ok, due > to the reliance on "gc points", which I read ahead to find out how > they are defined. If you want fully accurate (non-ambiguous roots) GC then yes you need gc-points to avoid having to store pointer information for every PC location. > And I'm GUESSING that CM3 already generates and depends on the sort > of data described there. > But maybe not. Umm, no. CM3 uses an ambiguous roots technique for thread stacks/ registers that avoids the need for gc-points. Hence, we can use preemptive system-level thread scheduling. > I wonder what the size of the data looks like if you allow a gc > point at every instruction. > I guess it probably be too large -- figure a byte or two extra for > every instruction, but maybe not. > > Perhaps it could be encoded in bits instead of bytes and given that > most instructions don't affect the state > (ie: operations on integers, floats, comparisons, branches), maybe > just a zero bit for most instructions. > So then figure a byte or two for every instruction that moves (load > or store) or adds/substracts a pointer. > Or more than that. A byte or two could describe enregistration and > small adds/subtracts, but not large adds/subtracts > or memory offsets. > > OR perhaps it'd just read the code itself. That's easier with Win32/ > x86 since it is so constrained > as to what it outputs. That should be feasible. I realize I'm > changing subjects between the different backends. > > The Windows AMD64 calling convention relies on something LIKE this. > In particular, there is a little encoding associated with every > prolog/epilog so that exception handling can undo the prolog's > effects. > It describes a tiny subset of the instruction set, like register > moves. > > Kind of funny -- once you get into the business of wanting to read > the code to know what it does, > you then get tempted to define your own code, for runtime and > information, and then a possible trick > is to adopt the existing machine code as your code, or whatever > subset your compiler produces. > Hm. The existing machine isn't sufficient. You would need type > information to augment it. > > Which reminds. Another OBVIOUS backend for CM3 for easier > portability is to persist the calls to m3cg and then > write an interpreter for that in C. > > - Jay > > > > From: hosking at cs.purdue.edu > > Date: Sat, 1 Dec 2007 17:42:02 -0500 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] returning record by value vs. by ref? > > > > If this really interests you then you might read this paper: http:// > > doi.acm.org/10.1145/143095.143140 . > > > > On Dec 1, 2007, at 5:36 PM, Jay wrote: > > > > > > 2, don't understand > > > > > > You said it'd take much cooperation with the compiler, due its > > > optimizations, but optimizations can be defeated as necessary. > > > Interior pointers could be marked, perhaps, volatile, so prevent > > > enregistration. I can see that's a potentially high cost though. > > > > > > like > > > Record_t *Record = GetRecord(); > > > unsigned i; > > > for (i = 0 ; i != Record->j ; ++i) > > > { > > > ... > > > } > > > > > > You'd really like Record->j to not be refetched for every loop > > > iteration, but if Record is volatile so the GC can move what it > > > points to and update outstanding pointers, you'd be stuck with > > > something like that. Besides, if j can't be read in one > > > instruction, more problems, assuming a concurrent GC, that cannot > > > reliably get/set the context of other threads. I think, like, you > > > could reliably get/set context on a uniprocessor system, but not a > > > multiprocessor. You'd have to suspend, wait for the suspend to > > > happen.. I guess that could work, but it seems like you'd want to > > > avoid designs that require suspending threads. ? > > > Hm. No, it's difficult. This being a short lived pointer, gc > > > happening on another thread, you'd have to, like, "register" its > > > location with the gc. > > > > > > Hm. Just how does it work? > > > > > > gc suspends threads and updates variables? I don't think so. > > > > > > Variables that are moved leave some sort of "forwarding address" > > > for holders of the old value? > > > > > > The gc isn't concurrent but is called at function entry/exit? I > > > don't think so. > > > > > > I should check the docs and code.. > > > > > > - Jay > > > > > > > > > > > > > From: hosking at cs.purdue.edu > > > > Date: Sat, 1 Dec 2007 17:19:46 -0500 > > > > To: jay.krell at cornell.edu > > > > CC: m3devel at elegosoft.com > > > > Subject: Re: [M3devel] returning record by value vs. by ref? > > > > > > > > > > > > On Dec 1, 2007, at 5:14 PM, Jay wrote: > > > > > > > > > 1) Can pinning not be exposed reasonably in the language? > > > > > I'll keep my pointer just a short time, in a local. > > > > > > > > Yes, that is a *hack* that will work only with the current > > > > conservative garbage collector. In general, the compiler might > > > > record that the local is a pointer derived from some base > reference > > > > and if the GC decides to move the base object it can adjust the > > > local > > > > derived pointer accordingly. > > > > > > > > > 2) surely it could be done at an outer layer? > > > > > Make volatile locals for things you don't want enregistered? > > > > > > > > I don't understand what you mean by this. > > > > > > > > > Even the accessor function approach seems lame, given that I > > > > > believe the Win32/x86 compiler doesn't inline.. :( > > > > > (does the gcc m3 inline across modules, or just compiles > one at a > > > > > time?) > > > > > > > > gcc m3 inlines only within compilation units. > > > > > > > > > > > > > > > > > > > - Jay > > > > > > > > > > > > > > > > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > > > > > > From: hosking at cs.purdue.edu > > > > > > Subject: Re: [M3devel] returning record by value vs. by ref? > > > > > > Date: Sat, 1 Dec 2007 15:23:19 -0500 > > > > > > To: rodney.bates at wichita.edu > > > > > > > > > > > > Correct! Anytime you create an l-value pointer. > > > > > > > > > > > > On Dec 1, 2007, at 2:31 PM, Rodney M. Bates wrote: > > > > > > > > > > > > > Tony Hosking wrote: > > > > > > >> I am assuming 's' here is an open array (REF ARRAY OF > > > item) in > > > > > > >> which case it is allocated in the GC'd heap. There is > > > certainly > > > > > > >> no way of safely getting an interior pointer to items > in the > > > > > > >> stack in Modula-3 -- at least not one that you can upward > > > expose > > > > > > >> (to callers) via return from a procedure. The > difficulty in > > > > > > >> doing this is that the GC moves objects around and would > > > need to > > > > > > >> know where your manufactured interior pointer is being > > > held and > > > > > > >> to which *object* (ie, the open array in this case) it > > > refers so > > > > > > >> that it can 'fix' the pointer when the array object > moves. > > > > > > >> Modula-3 provides a small concession to obtaining > downward > > > > > > >> exposed interior pointers using the VAR parameter > mode. For > > > > > > >> example you can pass 's[i]' as an actual parameter to a > > > VAR mode > > > > > > >> formal, effectively passing a pointer to the callee. GC > > > can cope > > > > > > >> with this in one of two possible ways: 1) "Pin" the array > > > so that > > > > > > >> it cannot be moved while the interior pointer is held > on the > > > > > > >> stack or registers of any thread (this is the approach > > > that CM3's > > > > > > >> conservative collector uses for now); or 2) track the > > > creation of > > > > > > >> such interior pointers and how they are derived from base > > > object > > > > > > >> references for use during GC. 2) requires much more co- > > > operation > > > > > > >> from the compiler than the current gcc-based backend > (with > > > all of > > > > > > >> its lovely optimizations and register allocation) is > > > capable of > > > > > > >> doing. 1) is very cheap and does not impede > optimizations and > > > > > > >> register allocation. > > > > > > > > > > > > > > Presumably, this all also applies WITH-bound > identifiers, when > > > > > they > > > > > > > are > > > > > > > designators of interior components of heap objects? Are > > > there any > > > > > > > other > > > > > > > cases? > > > > > > > > > > > > > > -- > > > > > > > > ------------------------------------------------------------- > > > > > > > Rodney M. Bates, retired assistant professor > > > > > > > Dept. of Computer Science, Wichita State University > > > > > > > Wichita, KS 67260-0083 > > > > > > > 316-978-3922 > > > > > > > rodney.bates at wichita.edu > > > > > > > > > > > > > > > > > > > > > Your smile counts. The more smiles you share, the more we > donate. > > > > > Join in! > > > > > > > > > > > > > Get the power of Windows + Web with the new Windows Live. Power > up! > > > > > You keep typing, we keep giving. Download Messenger and join the > i?m Initiative now. Join in! From jay.krell at cornell.edu Sun Dec 2 07:15:18 2007 From: jay.krell at cornell.edu (Jay) Date: Sun, 2 Dec 2007 06:15:18 +0000 Subject: [M3devel] returning record by value vs. by ref? In-Reply-To: <2B3B82B5-B989-4AC9-8156-02B3B8AC5B46@cs.purdue.edu> References: <1560FF15-8486-4388-ADAE-FADCF71FC5F3@cs.purdue.edu> <4751B69B.1090907@wichita.edu> <2B3B82B5-B989-4AC9-8156-02B3B8AC5B46@cs.purdue.edu> Message-ID: My quick understanding was that gc-points and mostly preemptive thread scheduling could be combined. You would have to cooperatively yield at gc-points, but you could be preemptively yielded anywhere. Er, maybe that's the point -- no cooperative yielding at all, no computation of gc-points, maybe none of this data. But you do end up I guess suspending all the threads and reading their registers and guessing as to the contents..the ambiguity you mention. I wonder how that is dealt with, since any integer can be an arbitrarily ffset pointer..I'll have to read more of the code.. - Jay > From: hosking at cs.purdue.edu> Date: Sun, 2 Dec 2007 00:16:05 -0500> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] returning record by value vs. by ref?> > > On Dec 1, 2007, at 11:11 PM, Jay wrote:> > > Thanks!> >> > I haven't finished reading it, but it sounds like an optimizing > > compiler is ok, due> > to the reliance on "gc points", which I read ahead to find out how > > they are defined.> > If you want fully accurate (non-ambiguous roots) GC then yes you need > gc-points to avoid having to store pointer information for every PC > location.> > > And I'm GUESSING that CM3 already generates and depends on the sort > > of data described there.> > But maybe not.> > Umm, no. CM3 uses an ambiguous roots technique for thread stacks/ > registers that avoids the need for gc-points. Hence, we can use > preemptive system-level thread scheduling.> > > I wonder what the size of the data looks like if you allow a gc > > point at every instruction.> > I guess it probably be too large -- figure a byte or two extra for > > every instruction, but maybe not.> >> > Perhaps it could be encoded in bits instead of bytes and given that > > most instructions don't affect the state> > (ie: operations on integers, floats, comparisons, branches), maybe > > just a zero bit for most instructions.> > So then figure a byte or two for every instruction that moves (load > > or store) or adds/substracts a pointer.> > Or more than that. A byte or two could describe enregistration and > > small adds/subtracts, but not large adds/subtracts> > or memory offsets.> >> > OR perhaps it'd just read the code itself. That's easier with Win32/ > > x86 since it is so constrained> > as to what it outputs. That should be feasible. I realize I'm > > changing subjects between the different backends.> >> > The Windows AMD64 calling convention relies on something LIKE this.> > In particular, there is a little encoding associated with every > > prolog/epilog so that exception handling can undo the prolog's > > effects.> > It describes a tiny subset of the instruction set, like register > > moves.> >> > Kind of funny -- once you get into the business of wanting to read > > the code to know what it does,> > you then get tempted to define your own code, for runtime and > > information, and then a possible trick> > is to adopt the existing machine code as your code, or whatever > > subset your compiler produces.> > Hm. The existing machine isn't sufficient. You would need type > > information to augment it.> >> > Which reminds. Another OBVIOUS backend for CM3 for easier > > portability is to persist the calls to m3cg and then> > write an interpreter for that in C.> >> > - Jay> >> >> > > From: hosking at cs.purdue.edu> > > Date: Sat, 1 Dec 2007 17:42:02 -0500> > > To: jay.krell at cornell.edu> > > CC: m3devel at elegosoft.com> > > Subject: Re: [M3devel] returning record by value vs. by ref?> > >> > > If this really interests you then you might read this paper: http://> > > doi.acm.org/10.1145/143095.143140 .> > >> > > On Dec 1, 2007, at 5:36 PM, Jay wrote:> > >> > > > > 2, don't understand> > > >> > > > You said it'd take much cooperation with the compiler, due its> > > > optimizations, but optimizations can be defeated as necessary.> > > > Interior pointers could be marked, perhaps, volatile, so prevent> > > > enregistration. I can see that's a potentially high cost though.> > > >> > > > like> > > > Record_t *Record = GetRecord();> > > > unsigned i;> > > > for (i = 0 ; i != Record->j ; ++i)> > > > {> > > > ...> > > > }> > > >> > > > You'd really like Record->j to not be refetched for every loop> > > > iteration, but if Record is volatile so the GC can move what it> > > > points to and update outstanding pointers, you'd be stuck with> > > > something like that. Besides, if j can't be read in one> > > > instruction, more problems, assuming a concurrent GC, that cannot> > > > reliably get/set the context of other threads. I think, like, you> > > > could reliably get/set context on a uniprocessor system, but not a> > > > multiprocessor. You'd have to suspend, wait for the suspend to> > > > happen.. I guess that could work, but it seems like you'd want to> > > > avoid designs that require suspending threads. ?> > > > Hm. No, it's difficult. This being a short lived pointer, gc> > > > happening on another thread, you'd have to, like, "register" its> > > > location with the gc.> > > >> > > > Hm. Just how does it work?> > > >> > > > gc suspends threads and updates variables? I don't think so.> > > >> > > > Variables that are moved leave some sort of "forwarding address"> > > > for holders of the old value?> > > >> > > > The gc isn't concurrent but is called at function entry/exit? I> > > > don't think so.> > > >> > > > I should check the docs and code..> > > >> > > > - Jay> > > >> > > >> > > >> > > > > From: hosking at cs.purdue.edu> > > > > Date: Sat, 1 Dec 2007 17:19:46 -0500> > > > > To: jay.krell at cornell.edu> > > > > CC: m3devel at elegosoft.com> > > > > Subject: Re: [M3devel] returning record by value vs. by ref?> > > > >> > > > >> > > > > On Dec 1, 2007, at 5:14 PM, Jay wrote:> > > > >> > > > > > 1) Can pinning not be exposed reasonably in the language?> > > > > > I'll keep my pointer just a short time, in a local.> > > > >> > > > > Yes, that is a *hack* that will work only with the current> > > > > conservative garbage collector. In general, the compiler might> > > > > record that the local is a pointer derived from some base > > reference> > > > > and if the GC decides to move the base object it can adjust the> > > > local> > > > > derived pointer accordingly.> > > > >> > > > > > 2) surely it could be done at an outer layer?> > > > > > Make volatile locals for things you don't want enregistered?> > > > >> > > > > I don't understand what you mean by this.> > > > >> > > > > > Even the accessor function approach seems lame, given that I> > > > > > believe the Win32/x86 compiler doesn't inline.. :(> > > > > > (does the gcc m3 inline across modules, or just compiles > > one at a> > > > > > time?)> > > > >> > > > > gcc m3 inlines only within compilation units.> > > > >> > > > > >> > > > > >> > > > > > - Jay> > > > > >> > > > > >> > > > > > > CC: jay.krell at cornell.edu; m3devel at elegosoft.com> > > > > > > From: hosking at cs.purdue.edu> > > > > > > Subject: Re: [M3devel] returning record by value vs. by ref?> > > > > > > Date: Sat, 1 Dec 2007 15:23:19 -0500> > > > > > > To: rodney.bates at wichita.edu> > > > > > >> > > > > > > Correct! Anytime you create an l-value pointer.> > > > > > >> > > > > > > On Dec 1, 2007, at 2:31 PM, Rodney M. Bates wrote:> > > > > > >> > > > > > > > Tony Hosking wrote:> > > > > > > >> I am assuming 's' here is an open array (REF ARRAY OF> > > > item) in> > > > > > > >> which case it is allocated in the GC'd heap. There is> > > > certainly> > > > > > > >> no way of safely getting an interior pointer to items > > in the> > > > > > > >> stack in Modula-3 -- at least not one that you can upward> > > > expose> > > > > > > >> (to callers) via return from a procedure. The > > difficulty in> > > > > > > >> doing this is that the GC moves objects around and would> > > > need to> > > > > > > >> know where your manufactured interior pointer is being> > > > held and> > > > > > > >> to which *object* (ie, the open array in this case) it> > > > refers so> > > > > > > >> that it can 'fix' the pointer when the array object > > moves.> > > > > > > >> Modula-3 provides a small concession to obtaining > > downward> > > > > > > >> exposed interior pointers using the VAR parameter > > mode. For> > > > > > > >> example you can pass 's[i]' as an actual parameter to a> > > > VAR mode> > > > > > > >> formal, effectively passing a pointer to the callee. GC> > > > can cope> > > > > > > >> with this in one of two possible ways: 1) "Pin" the array> > > > so that> > > > > > > >> it cannot be moved while the interior pointer is held > > on the> > > > > > > >> stack or registers of any thread (this is the approach> > > > that CM3's> > > > > > > >> conservative collector uses for now); or 2) track the> > > > creation of> > > > > > > >> such interior pointers and how they are derived from base> > > > object> > > > > > > >> references for use during GC. 2) requires much more co-> > > > operation> > > > > > > >> from the compiler than the current gcc-based backend > > (with> > > > all of> > > > > > > >> its lovely optimizations and register allocation) is> > > > capable of> > > > > > > >> doing. 1) is very cheap and does not impede > > optimizations and> > > > > > > >> register allocation.> > > > > > > >> > > > > > > > Presumably, this all also applies WITH-bound > > identifiers, when> > > > > > they> > > > > > > > are> > > > > > > > designators of interior components of heap objects? Are> > > > there any> > > > > > > > other> > > > > > > > cases?> > > > > > > >> > > > > > > > --> > > > > > > > > > -------------------------------------------------------------> > > > > > > > Rodney M. Bates, retired assistant professor> > > > > > > > Dept. of Computer Science, Wichita State University> > > > > > > > Wichita, KS 67260-0083> > > > > > > > 316-978-3922> > > > > > > > rodney.bates at wichita.edu> > > > > > >> > > > > >> > > > > >> > > > > > Your smile counts. The more smiles you share, the more we > > donate.> > > > > > Join in!> > > > >> > > >> > > >> > > > Get the power of Windows + Web with the new Windows Live. Power > > up!> > >> >> >> > You keep typing, we keep giving. Download Messenger and join the > > i?m Initiative now. Join in!> _________________________________________________________________ Share life as it happens with the new Windows Live.Download today it's FREE! http://www.windowslive.com/share.html?ocid=TXT_TAGLM_Wave2_sharelife_112007 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 2 18:23:29 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 2 Dec 2007 12:23:29 -0500 Subject: [M3devel] returning record by value vs. by ref? In-Reply-To: References: <1560FF15-8486-4388-ADAE-FADCF71FC5F3@cs.purdue.edu> <4751B69B.1090907@wichita.edu> <2B3B82B5-B989-4AC9-8156-02B3B8AC5B46@cs.purdue.edu> Message-ID: <6A62D86F-1AAD-4CBE-9348-C0A0210AA291@cs.purdue.edu> On Dec 2, 2007, at 1:15 AM, Jay wrote: > My quick understanding was that gc-points and mostly preemptive > thread scheduling could be combined. A little but doable: if a thread is preempted and GC occurs then you have a problem, needing to roll the thread forward to a GC point. > You would have to cooperatively yield at gc-points, but you could > be preemptively yielded anywhere. > Er, maybe that's the point -- no cooperative yielding at all, no > computation of gc-points, maybe none of this data. Yes, that's the point about ambiguous roots collection. > But you do end up I guess suspending all the threads and reading > their registers and guessing as to the contents..the ambiguity you > mention. I wonder how that is dealt with, since any integer can be > an arbitrarily ffset pointer.. The current ambiguous roots collector pins objects referred to by ambiguous roots (thread stacks/registers). It moves objects that are not referred to by ambiguous roots. > I'll have to read more of the code.. > > - Jay > > > > From: hosking at cs.purdue.edu > > Date: Sun, 2 Dec 2007 00:16:05 -0500 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] returning record by value vs. by ref? > > > > > > On Dec 1, 2007, at 11:11 PM, Jay wrote: > > > > > Thanks! > > > > > > I haven't finished reading it, but it sounds like an optimizing > > > compiler is ok, due > > > to the reliance on "gc points", which I read ahead to find out how > > > they are defined. > > > > If you want fully accurate (non-ambiguous roots) GC then yes you > need > > gc-points to avoid having to store pointer information for every PC > > location. > > > > > And I'm GUESSING that CM3 already generates and depends on the > sort > > > of data described there. > > > But maybe not. > > > > Umm, no. CM3 uses an ambiguous roots technique for thread stacks/ > > registers that avoids the need for gc-points. Hence, we can use > > preemptive system-level thread scheduling. > > > > > I wonder what the size of the data looks like if you allow a gc > > > point at every instruction. > > > I guess it probably be too large -- figure a byte or two extra for > > > every instruction, but maybe not. > > > > > > Perhaps it could be encoded in bits instead of bytes and given > that > > > most instructions don't affect the state > > > (ie: operations on integers, floats, comparisons, branches), maybe > > > just a zero bit for most instructions. > > > So then figure a byte or two for every instruction that moves > (load > > > or store) or adds/substracts a pointer. > > > Or more than that. A byte or two could describe enregistration and > > > small adds/subtracts, but not large adds/subtracts > > > or memory offsets. > > > > > > OR perhaps it'd just read the code itself. That's easier with > Win32/ > > > x86 since it is so constrained > > > as to what it outputs. That should be feasible. I realize I'm > > > changing subjects between the different backends. > > > > > > The Windows AMD64 calling convention relies on something LIKE > this. > > > In particular, there is a little encoding associated with every > > > prolog/epilog so that exception handling can undo the prolog's > > > effects. > > > It describes a tiny subset of the instruction set, like register > > > moves. > > > > > > Kind of funny -- once you get into the business of wanting to read > > > the code to know what it does, > > > you then get tempted to define your own code, for runtime and > > > information, and then a possible trick > > > is to adopt the existing machine code as your code, or whatever > > > subset your compiler produces. > > > Hm. The existing machine isn't sufficient. You would need type > > > information to augment it. > > > > > > Which reminds. Another OBVIOUS backend for CM3 for easier > > > portability is to persist the calls to m3cg and then > > > write an interpreter for that in C. > > > > > > - Jay > > > > > > > > > > From: hosking at cs.purdue.edu > > > > Date: Sat, 1 Dec 2007 17:42:02 -0500 > > > > To: jay.krell at cornell.edu > > > > CC: m3devel at elegosoft.com > > > > Subject: Re: [M3devel] returning record by value vs. by ref? > > > > > > > > If this really interests you then you might read this paper: > http:// > > > > doi.acm.org/10.1145/143095.143140 . > > > > > > > > On Dec 1, 2007, at 5:36 PM, Jay wrote: > > > > > > > > > > 2, don't understand > > > > > > > > > > You said it'd take much cooperation with the compiler, due its > > > > > optimizations, but optimizations can be defeated as necessary. > > > > > Interior pointers could be marked, perhaps, volatile, so > prevent > > > > > enregistration. I can see that's a potentially high cost > though. > > > > > > > > > > like > > > > > Record_t *Record = GetRecord(); > > > > > unsigned i; > > > > > for (i = 0 ; i != Record->j ; ++i) > > > > > { > > > > > ... > > > > > } > > > > > > > > > > You'd really like Record->j to not be refetched for every loop > > > > > iteration, but if Record is volatile so the GC can move > what it > > > > > points to and update outstanding pointers, you'd be stuck with > > > > > something like that. Besides, if j can't be read in one > > > > > instruction, more problems, assuming a concurrent GC, that > cannot > > > > > reliably get/set the context of other threads. I think, > like, you > > > > > could reliably get/set context on a uniprocessor system, > but not a > > > > > multiprocessor. You'd have to suspend, wait for the suspend to > > > > > happen.. I guess that could work, but it seems like you'd > want to > > > > > avoid designs that require suspending threads. ? > > > > > Hm. No, it's difficult. This being a short lived pointer, gc > > > > > happening on another thread, you'd have to, like, > "register" its > > > > > location with the gc. > > > > > > > > > > Hm. Just how does it work? > > > > > > > > > > gc suspends threads and updates variables? I don't think so. > > > > > > > > > > Variables that are moved leave some sort of "forwarding > address" > > > > > for holders of the old value? > > > > > > > > > > The gc isn't concurrent but is called at function entry/ > exit? I > > > > > don't think so. > > > > > > > > > > I should check the docs and code.. > > > > > > > > > > - Jay > > > > > > > > > > > > > > > > > > > > > From: hosking at cs.purdue.edu > > > > > > Date: Sat, 1 Dec 2007 17:19:46 -0500 > > > > > > To: jay.krell at cornell.edu > > > > > > CC: m3devel at elegosoft.com > > > > > > Subject: Re: [M3devel] returning record by value vs. by ref? > > > > > > > > > > > > > > > > > > On Dec 1, 2007, at 5:14 PM, Jay wrote: > > > > > > > > > > > > > 1) Can pinning not be exposed reasonably in the language? > > > > > > > I'll keep my pointer just a short time, in a local. > > > > > > > > > > > > Yes, that is a *hack* that will work only with the current > > > > > > conservative garbage collector. In general, the compiler > might > > > > > > record that the local is a pointer derived from some base > > > reference > > > > > > and if the GC decides to move the base object it can > adjust the > > > > > local > > > > > > derived pointer accordingly. > > > > > > > > > > > > > 2) surely it could be done at an outer layer? > > > > > > > Make volatile locals for things you don't want > enregistered? > > > > > > > > > > > > I don't understand what you mean by this. > > > > > > > > > > > > > Even the accessor function approach seems lame, given > that I > > > > > > > believe the Win32/x86 compiler doesn't inline.. :( > > > > > > > (does the gcc m3 inline across modules, or just compiles > > > one at a > > > > > > > time?) > > > > > > > > > > > > gcc m3 inlines only within compilation units. > > > > > > > > > > > > > > > > > > > > > > > > > > > - Jay > > > > > > > > > > > > > > > > > > > > > > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > > > > > > > > From: hosking at cs.purdue.edu > > > > > > > > Subject: Re: [M3devel] returning record by value vs. > by ref? > > > > > > > > Date: Sat, 1 Dec 2007 15:23:19 -0500 > > > > > > > > To: rodney.bates at wichita.edu > > > > > > > > > > > > > > > > Correct! Anytime you create an l-value pointer. > > > > > > > > > > > > > > > > On Dec 1, 2007, at 2:31 PM, Rodney M. Bates wrote: > > > > > > > > > > > > > > > > > Tony Hosking wrote: > > > > > > > > >> I am assuming 's' here is an open array (REF ARRAY OF > > > > > item) in > > > > > > > > >> which case it is allocated in the GC'd heap. There is > > > > > certainly > > > > > > > > >> no way of safely getting an interior pointer to items > > > in the > > > > > > > > >> stack in Modula-3 -- at least not one that you can > upward > > > > > expose > > > > > > > > >> (to callers) via return from a procedure. The > > > difficulty in > > > > > > > > >> doing this is that the GC moves objects around and > would > > > > > need to > > > > > > > > >> know where your manufactured interior pointer is > being > > > > > held and > > > > > > > > >> to which *object* (ie, the open array in this > case) it > > > > > refers so > > > > > > > > >> that it can 'fix' the pointer when the array object > > > moves. > > > > > > > > >> Modula-3 provides a small concession to obtaining > > > downward > > > > > > > > >> exposed interior pointers using the VAR parameter > > > mode. For > > > > > > > > >> example you can pass 's[i]' as an actual parameter > to a > > > > > VAR mode > > > > > > > > >> formal, effectively passing a pointer to the > callee. GC > > > > > can cope > > > > > > > > >> with this in one of two possible ways: 1) "Pin" > the array > > > > > so that > > > > > > > > >> it cannot be moved while the interior pointer is held > > > on the > > > > > > > > >> stack or registers of any thread (this is the > approach > > > > > that CM3's > > > > > > > > >> conservative collector uses for now); or 2) track the > > > > > creation of > > > > > > > > >> such interior pointers and how they are derived > from base > > > > > object > > > > > > > > >> references for use during GC. 2) requires much > more co- > > > > > operation > > > > > > > > >> from the compiler than the current gcc-based backend > > > (with > > > > > all of > > > > > > > > >> its lovely optimizations and register allocation) is > > > > > capable of > > > > > > > > >> doing. 1) is very cheap and does not impede > > > optimizations and > > > > > > > > >> register allocation. > > > > > > > > > > > > > > > > > > Presumably, this all also applies WITH-bound > > > identifiers, when > > > > > > > they > > > > > > > > > are > > > > > > > > > designators of interior components of heap objects? > Are > > > > > there any > > > > > > > > > other > > > > > > > > > cases? > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > ------------------------------------------------------------- > > > > > > > > > Rodney M. Bates, retired assistant professor > > > > > > > > > Dept. of Computer Science, Wichita State University > > > > > > > > > Wichita, KS 67260-0083 > > > > > > > > > 316-978-3922 > > > > > > > > > rodney.bates at wichita.edu > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your smile counts. The more smiles you share, the more we > > > donate. > > > > > > > Join in! > > > > > > > > > > > > > > > > > > > > > Get the power of Windows + Web with the new Windows Live. > Power > > > up! > > > > > > > > > > > > > You keep typing, we keep giving. Download Messenger and join the > > > i?m Initiative now. Join in! > > > > > Share life as it happens with the new Windows Live. Share now! From jay.krell at cornell.edu Sun Dec 2 19:54:25 2007 From: jay.krell at cornell.edu (Jay) Date: Sun, 2 Dec 2007 18:54:25 +0000 Subject: [M3devel] returning record by value vs. by ref? In-Reply-To: <6A62D86F-1AAD-4CBE-9348-C0A0210AA291@cs.purdue.edu> References: <1560FF15-8486-4388-ADAE-FADCF71FC5F3@cs.purdue.edu> <4751B69B.1090907@wichita.edu> <2B3B82B5-B989-4AC9-8156-02B3B8AC5B46@cs.purdue.edu> <6A62D86F-1AAD-4CBE-9348-C0A0210AA291@cs.purdue.edu> Message-ID: > roll forward to gc-point Right, the paper says the gc will wait till all threads are at gc-points, and gc-points are defined/inserted enough to make it probably not long -- allocations, calls/returns, loop boundaries, roughly. > ambiguous.. The problem in my mind is "how ambiguous?". Can't almost anything be a pointer in disguise? This example from the paper: Double Indexing: The code A[i] := 1; B[i] := 2; may be optimized to t1 = &A[0] + (i * sizeof(int)); t2 = &B[0] - &A[0]; *tl = 1; *(tl + t2) = 2; which is useful on machines that have addressing modes with two or more index registers, such as the SPARC. More from the paper, emphasis mine: Note that a derived value may bean untidy pointer to the interior of an object (strength reduction example), an untidy pointer that points outside the object to which it refers (virtual array origin example), or even a non-pointer value (double indexing example), and the examples given above may not exhaust the possibilities - Jay > From: hosking at cs.purdue.edu> Date: Sun, 2 Dec 2007 12:23:29 -0500> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] returning record by value vs. by ref?> > > On Dec 2, 2007, at 1:15 AM, Jay wrote:> > > My quick understanding was that gc-points and mostly preemptive > > thread scheduling could be combined.> > A little but doable: if a thread is preempted and GC occurs then you > have a problem, needing to roll the thread forward to a GC point.> > > You would have to cooperatively yield at gc-points, but you could > > be preemptively yielded anywhere.> > Er, maybe that's the point -- no cooperative yielding at all, no > > computation of gc-points, maybe none of this data.> > Yes, that's the point about ambiguous roots collection.> > > But you do end up I guess suspending all the threads and reading > > their registers and guessing as to the contents..the ambiguity you > > mention. I wonder how that is dealt with, since any integer can be > > an arbitrarily ffset pointer..> > The current ambiguous roots collector pins objects referred to by > ambiguous roots (thread stacks/registers). It moves objects that are > not referred to by ambiguous roots.> > > I'll have to read more of the code..> >> > - Jay> >> >> > > From: hosking at cs.purdue.edu> > > Date: Sun, 2 Dec 2007 00:16:05 -0500> > > To: jay.krell at cornell.edu> > > CC: m3devel at elegosoft.com> > > Subject: Re: [M3devel] returning record by value vs. by ref?> > >> > >> > > On Dec 1, 2007, at 11:11 PM, Jay wrote:> > >> > > > Thanks!> > > >> > > > I haven't finished reading it, but it sounds like an optimizing> > > > compiler is ok, due> > > > to the reliance on "gc points", which I read ahead to find out how> > > > they are defined.> > >> > > If you want fully accurate (non-ambiguous roots) GC then yes you > > need> > > gc-points to avoid having to store pointer information for every PC> > > location.> > >> > > > And I'm GUESSING that CM3 already generates and depends on the > > sort> > > > of data described there.> > > > But maybe not.> > >> > > Umm, no. CM3 uses an ambiguous roots technique for thread stacks/> > > registers that avoids the need for gc-points. Hence, we can use> > > preemptive system-level thread scheduling.> > >> > > > I wonder what the size of the data looks like if you allow a gc> > > > point at every instruction.> > > > I guess it probably be too large -- figure a byte or two extra for> > > > every instruction, but maybe not.> > > >> > > > Perhaps it could be encoded in bits instead of bytes and given > > that> > > > most instructions don't affect the state> > > > (ie: operations on integers, floats, comparisons, branches), maybe> > > > just a zero bit for most instructions.> > > > So then figure a byte or two for every instruction that moves > > (load> > > > or store) or adds/substracts a pointer.> > > > Or more than that. A byte or two could describe enregistration and> > > > small adds/subtracts, but not large adds/subtracts> > > > or memory offsets.> > > >> > > > OR perhaps it'd just read the code itself. That's easier with > > Win32/> > > > x86 since it is so constrained> > > > as to what it outputs. That should be feasible. I realize I'm> > > > changing subjects between the different backends.> > > >> > > > The Windows AMD64 calling convention relies on something LIKE > > this.> > > > In particular, there is a little encoding associated with every> > > > prolog/epilog so that exception handling can undo the prolog's> > > > effects.> > > > It describes a tiny subset of the instruction set, like register> > > > moves.> > > >> > > > Kind of funny -- once you get into the business of wanting to read> > > > the code to know what it does,> > > > you then get tempted to define your own code, for runtime and> > > > information, and then a possible trick> > > > is to adopt the existing machine code as your code, or whatever> > > > subset your compiler produces.> > > > Hm. The existing machine isn't sufficient. You would need type> > > > information to augment it.> > > >> > > > Which reminds. Another OBVIOUS backend for CM3 for easier> > > > portability is to persist the calls to m3cg and then> > > > write an interpreter for that in C.> > > >> > > > - Jay> > > >> > > >> > > > > From: hosking at cs.purdue.edu> > > > > Date: Sat, 1 Dec 2007 17:42:02 -0500> > > > > To: jay.krell at cornell.edu> > > > > CC: m3devel at elegosoft.com> > > > > Subject: Re: [M3devel] returning record by value vs. by ref?> > > > >> > > > > If this really interests you then you might read this paper: > > http://> > > > > doi.acm.org/10.1145/143095.143140 .> > > > >> > > > > On Dec 1, 2007, at 5:36 PM, Jay wrote:> > > > >> > > > > > > 2, don't understand> > > > > >> > > > > > You said it'd take much cooperation with the compiler, due its> > > > > > optimizations, but optimizations can be defeated as necessary.> > > > > > Interior pointers could be marked, perhaps, volatile, so > > prevent> > > > > > enregistration. I can see that's a potentially high cost > > though.> > > > > >> > > > > > like> > > > > > Record_t *Record = GetRecord();> > > > > > unsigned i;> > > > > > for (i = 0 ; i != Record->j ; ++i)> > > > > > {> > > > > > ...> > > > > > }> > > > > >> > > > > > You'd really like Record->j to not be refetched for every loop> > > > > > iteration, but if Record is volatile so the GC can move > > what it> > > > > > points to and update outstanding pointers, you'd be stuck with> > > > > > something like that. Besides, if j can't be read in one> > > > > > instruction, more problems, assuming a concurrent GC, that > > cannot> > > > > > reliably get/set the context of other threads. I think, > > like, you> > > > > > could reliably get/set context on a uniprocessor system, > > but not a> > > > > > multiprocessor. You'd have to suspend, wait for the suspend to> > > > > > happen.. I guess that could work, but it seems like you'd > > want to> > > > > > avoid designs that require suspending threads. ?> > > > > > Hm. No, it's difficult. This being a short lived pointer, gc> > > > > > happening on another thread, you'd have to, like, > > "register" its> > > > > > location with the gc.> > > > > >> > > > > > Hm. Just how does it work?> > > > > >> > > > > > gc suspends threads and updates variables? I don't think so.> > > > > >> > > > > > Variables that are moved leave some sort of "forwarding > > address"> > > > > > for holders of the old value?> > > > > >> > > > > > The gc isn't concurrent but is called at function entry/ > > exit? I> > > > > > don't think so.> > > > > >> > > > > > I should check the docs and code..> > > > > >> > > > > > - Jay> > > > > >> > > > > >> > > > > >> > > > > > > From: hosking at cs.purdue.edu> > > > > > > Date: Sat, 1 Dec 2007 17:19:46 -0500> > > > > > > To: jay.krell at cornell.edu> > > > > > > CC: m3devel at elegosoft.com> > > > > > > Subject: Re: [M3devel] returning record by value vs. by ref?> > > > > > >> > > > > > >> > > > > > > On Dec 1, 2007, at 5:14 PM, Jay wrote:> > > > > > >> > > > > > > > 1) Can pinning not be exposed reasonably in the language?> > > > > > > > I'll keep my pointer just a short time, in a local.> > > > > > >> > > > > > > Yes, that is a *hack* that will work only with the current> > > > > > > conservative garbage collector. In general, the compiler > > might> > > > > > > record that the local is a pointer derived from some base> > > > reference> > > > > > > and if the GC decides to move the base object it can > > adjust the> > > > > > local> > > > > > > derived pointer accordingly.> > > > > > >> > > > > > > > 2) surely it could be done at an outer layer?> > > > > > > > Make volatile locals for things you don't want > > enregistered?> > > > > > >> > > > > > > I don't understand what you mean by this.> > > > > > >> > > > > > > > Even the accessor function approach seems lame, given > > that I> > > > > > > > believe the Win32/x86 compiler doesn't inline.. :(> > > > > > > > (does the gcc m3 inline across modules, or just compiles> > > > one at a> > > > > > > > time?)> > > > > > >> > > > > > > gcc m3 inlines only within compilation units.> > > > > > >> > > > > > > >> > > > > > > >> > > > > > > > - Jay> > > > > > > >> > > > > > > >> > > > > > > > > CC: jay.krell at cornell.edu; m3devel at elegosoft.com> > > > > > > > > From: hosking at cs.purdue.edu> > > > > > > > > Subject: Re: [M3devel] returning record by value vs. > > by ref?> > > > > > > > > Date: Sat, 1 Dec 2007 15:23:19 -0500> > > > > > > > > To: rodney.bates at wichita.edu> > > > > > > > >> > > > > > > > > Correct! Anytime you create an l-value pointer.> > > > > > > > >> > > > > > > > > On Dec 1, 2007, at 2:31 PM, Rodney M. Bates wrote:> > > > > > > > >> > > > > > > > > > Tony Hosking wrote:> > > > > > > > > >> I am assuming 's' here is an open array (REF ARRAY OF> > > > > > item) in> > > > > > > > > >> which case it is allocated in the GC'd heap. There is> > > > > > certainly> > > > > > > > > >> no way of safely getting an interior pointer to items> > > > in the> > > > > > > > > >> stack in Modula-3 -- at least not one that you can > > upward> > > > > > expose> > > > > > > > > >> (to callers) via return from a procedure. The> > > > difficulty in> > > > > > > > > >> doing this is that the GC moves objects around and > > would> > > > > > need to> > > > > > > > > >> know where your manufactured interior pointer is > > being> > > > > > held and> > > > > > > > > >> to which *object* (ie, the open array in this > > case) it> > > > > > refers so> > > > > > > > > >> that it can 'fix' the pointer when the array object> > > > moves.> > > > > > > > > >> Modula-3 provides a small concession to obtaining> > > > downward> > > > > > > > > >> exposed interior pointers using the VAR parameter> > > > mode. For> > > > > > > > > >> example you can pass 's[i]' as an actual parameter > > to a> > > > > > VAR mode> > > > > > > > > >> formal, effectively passing a pointer to the > > callee. GC> > > > > > can cope> > > > > > > > > >> with this in one of two possible ways: 1) "Pin" > > the array> > > > > > so that> > > > > > > > > >> it cannot be moved while the interior pointer is held> > > > on the> > > > > > > > > >> stack or registers of any thread (this is the > > approach> > > > > > that CM3's> > > > > > > > > >> conservative collector uses for now); or 2) track the> > > > > > creation of> > > > > > > > > >> such interior pointers and how they are derived > > from base> > > > > > object> > > > > > > > > >> references for use during GC. 2) requires much > > more co-> > > > > > operation> > > > > > > > > >> from the compiler than the current gcc-based backend> > > > (with> > > > > > all of> > > > > > > > > >> its lovely optimizations and register allocation) is> > > > > > capable of> > > > > > > > > >> doing. 1) is very cheap and does not impede> > > > optimizations and> > > > > > > > > >> register allocation.> > > > > > > > > >> > > > > > > > > > Presumably, this all also applies WITH-bound> > > > identifiers, when> > > > > > > > they> > > > > > > > > > are> > > > > > > > > > designators of interior components of heap objects? > > Are> > > > > > there any> > > > > > > > > > other> > > > > > > > > > cases?> > > > > > > > > >> > > > > > > > > > --> > > > > > > > > >> > > > -------------------------------------------------------------> > > > > > > > > > Rodney M. Bates, retired assistant professor> > > > > > > > > > Dept. of Computer Science, Wichita State University> > > > > > > > > > Wichita, KS 67260-0083> > > > > > > > > > 316-978-3922> > > > > > > > > > rodney.bates at wichita.edu> > > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > > Your smile counts. The more smiles you share, the more we> > > > donate.> > > > > > > > Join in!> > > > > > >> > > > > >> > > > > >> > > > > > Get the power of Windows + Web with the new Windows Live. > > Power> > > > up!> > > > >> > > >> > > >> > > > You keep typing, we keep giving. Download Messenger and join the> > > > i?m Initiative now. Join in!> > >> >> >> > Share life as it happens with the new Windows Live. Share now!> _________________________________________________________________ Your smile counts. The more smiles you share, the more we donate.? Join in. www.windowslive.com/smile?ocid=TXT_TAGLM_Wave2_oprsmilewlhmtagline -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 2 20:11:55 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 2 Dec 2007 14:11:55 -0500 Subject: [M3devel] returning record by value vs. by ref? In-Reply-To: References: <1560FF15-8486-4388-ADAE-FADCF71FC5F3@cs.purdue.edu> <4751B69B.1090907@wichita.edu> <2B3B82B5-B989-4AC9-8156-02B3B8AC5B46@cs.purdue.edu> <6A62D86F-1AAD-4CBE-9348-C0A0210AA291@cs.purdue.edu> Message-ID: On Dec 2, 2007, at 1:54 PM, Jay wrote: > > roll forward to gc-point > > Right, the paper says the gc will wait till all threads are at gc- > points, and gc-points are defined/inserted enough to make it > probably not long -- allocations, calls/returns, loop boundaries, > roughly. My problem with this for preemptive scheduling is that roll-forward can take a long time -- too long if one wants short GCs. Currently, GC can occur at almost all preemption points. > > ambiguous.. > > The problem in my mind is "how ambiguous?". > Can't almost anything be a pointer in disguise? Indeed, for CM3 currently any word-aligned, word-length bit string in stacks or registers is treated as a potential ambiguous root. > This example from the paper: > > Double Indexing: The code > A[i] := 1; > B[i] := 2; > may be optimized to > t1 = &A[0] + (i * sizeof(int)); > t2 = &B[0] - &A[0]; > *tl = 1; > *(tl + t2) = 2; > > which is useful on machines that have addressing modes > with two or more index registers, such as the SPARC. > > More from the paper, emphasis mine: > > Note that a derived value > may bean untidy pointer to the interior of an object (strength > reduction example), an untidy pointer that points outside the > object to which it refers (virtual array origin example), or > even a non-pointer value (double indexing example), and > the examples given above may not exhaust the possibilities This all depends on what sorts of optimizations are permitted, as you have already noted. > > > - Jay > > > > From: hosking at cs.purdue.edu > > Date: Sun, 2 Dec 2007 12:23:29 -0500 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] returning record by value vs. by ref? > > > > > > On Dec 2, 2007, at 1:15 AM, Jay wrote: > > > > > My quick understanding was that gc-points and mostly preemptive > > > thread scheduling could be combined. > > > > A little but doable: if a thread is preempted and GC occurs then you > > have a problem, needing to roll the thread forward to a GC point. > > > > > You would have to cooperatively yield at gc-points, but you could > > > be preemptively yielded anywhere. > > > Er, maybe that's the point -- no cooperative yielding at all, no > > > computation of gc-points, maybe none of this data. > > > > Yes, that's the point about ambiguous roots collection. > > > > > But you do end up I guess suspending all the threads and reading > > > their registers and guessing as to the contents..the ambiguity you > > > mention. I wonder how that is dealt with, since any integer can be > > > an arbitrarily ffset pointer.. > > > > The current ambiguous roots collector pins objects referred to by > > ambiguous roots (thread stacks/registers). It moves objects that are > > not referred to by ambiguous roots. > > > > > I'll have to read more of the code.. > > > > > > - Jay > > > > > > > > > > From: hosking at cs.purdue.edu > > > > Date: Sun, 2 Dec 2007 00:16:05 -0500 > > > > To: jay.krell at cornell.edu > > > > CC: m3devel at elegosoft.com > > > > Subject: Re: [M3devel] returning record by value vs. by ref? > > > > > > > > > > > > On Dec 1, 2007, at 11:11 PM, Jay wrote: > > > > > > > > > Thanks! > > > > > > > > > > I haven't finished reading it, but it sounds like an > optimizing > > > > > compiler is ok, due > > > > > to the reliance on "gc points", which I read ahead to find > out how > > > > > they are defined. > > > > > > > > If you want fully accurate (non-ambiguous roots) GC then yes you > > > need > > > > gc-points to avoid having to store pointer information for > every PC > > > > location. > > > > > > > > > And I'm GUESSING that CM3 already generates and depends on the > > > sort > > > > > of data described there. > > > > > But maybe not. > > > > > > > > Umm, no. CM3 uses an ambiguous roots technique for thread > stacks/ > > > > registers that avoids the need for gc-points. Hence, we can use > > > > preemptive system-level thread scheduling. > > > > > > > > > I wonder what the size of the data looks like if you allow > a gc > > > > > point at every instruction. > > > > > I guess it probably be too large -- figure a byte or two > extra for > > > > > every instruction, but maybe not. > > > > > > > > > > Perhaps it could be encoded in bits instead of bytes and given > > > that > > > > > most instructions don't affect the state > > > > > (ie: operations on integers, floats, comparisons, > branches), maybe > > > > > just a zero bit for most instructions. > > > > > So then figure a byte or two for every instruction that moves > > > (load > > > > > or store) or adds/substracts a pointer. > > > > > Or more than that. A byte or two could describe > enregistration and > > > > > small adds/subtracts, but not large adds/subtracts > > > > > or memory offsets. > > > > > > > > > > OR perhaps it'd just read the code itself. That's easier with > > > Win32/ > > > > > x86 since it is so constrained > > > > > as to what it outputs. That should be feasible. I realize I'm > > > > > changing subjects between the different backends. > > > > > > > > > > The Windows AMD64 calling convention relies on something LIKE > > > this. > > > > > In particular, there is a little encoding associated with > every > > > > > prolog/epilog so that exception handling can undo the prolog's > > > > > effects. > > > > > It describes a tiny subset of the instruction set, like > register > > > > > moves. > > > > > > > > > > Kind of funny -- once you get into the business of wanting > to read > > > > > the code to know what it does, > > > > > you then get tempted to define your own code, for runtime and > > > > > information, and then a possible trick > > > > > is to adopt the existing machine code as your code, or > whatever > > > > > subset your compiler produces. > > > > > Hm. The existing machine isn't sufficient. You would need type > > > > > information to augment it. > > > > > > > > > > Which reminds. Another OBVIOUS backend for CM3 for easier > > > > > portability is to persist the calls to m3cg and then > > > > > write an interpreter for that in C. > > > > > > > > > > - Jay > > > > > > > > > > > > > > > > From: hosking at cs.purdue.edu > > > > > > Date: Sat, 1 Dec 2007 17:42:02 -0500 > > > > > > To: jay.krell at cornell.edu > > > > > > CC: m3devel at elegosoft.com > > > > > > Subject: Re: [M3devel] returning record by value vs. by ref? > > > > > > > > > > > > If this really interests you then you might read this paper: > > > http:// > > > > > > doi.acm.org/10.1145/143095.143140 . > > > > > > > > > > > > On Dec 1, 2007, at 5:36 PM, Jay wrote: > > > > > > > > > > > > > > 2, don't understand > > > > > > > > > > > > > > You said it'd take much cooperation with the compiler, > due its > > > > > > > optimizations, but optimizations can be defeated as > necessary. > > > > > > > Interior pointers could be marked, perhaps, volatile, so > > > prevent > > > > > > > enregistration. I can see that's a potentially high cost > > > though. > > > > > > > > > > > > > > like > > > > > > > Record_t *Record = GetRecord(); > > > > > > > unsigned i; > > > > > > > for (i = 0 ; i != Record->j ; ++i) > > > > > > > { > > > > > > > ... > > > > > > > } > > > > > > > > > > > > > > You'd really like Record->j to not be refetched for > every loop > > > > > > > iteration, but if Record is volatile so the GC can move > > > what it > > > > > > > points to and update outstanding pointers, you'd be > stuck with > > > > > > > something like that. Besides, if j can't be read in one > > > > > > > instruction, more problems, assuming a concurrent GC, that > > > cannot > > > > > > > reliably get/set the context of other threads. I think, > > > like, you > > > > > > > could reliably get/set context on a uniprocessor system, > > > but not a > > > > > > > multiprocessor. You'd have to suspend, wait for the > suspend to > > > > > > > happen.. I guess that could work, but it seems like you'd > > > want to > > > > > > > avoid designs that require suspending threads. ? > > > > > > > Hm. No, it's difficult. This being a short lived > pointer, gc > > > > > > > happening on another thread, you'd have to, like, > > > "register" its > > > > > > > location with the gc. > > > > > > > > > > > > > > Hm. Just how does it work? > > > > > > > > > > > > > > gc suspends threads and updates variables? I don't > think so. > > > > > > > > > > > > > > Variables that are moved leave some sort of "forwarding > > > address" > > > > > > > for holders of the old value? > > > > > > > > > > > > > > The gc isn't concurrent but is called at function entry/ > > > exit? I > > > > > > > don't think so. > > > > > > > > > > > > > > I should check the docs and code.. > > > > > > > > > > > > > > - Jay > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: hosking at cs.purdue.edu > > > > > > > > Date: Sat, 1 Dec 2007 17:19:46 -0500 > > > > > > > > To: jay.krell at cornell.edu > > > > > > > > CC: m3devel at elegosoft.com > > > > > > > > Subject: Re: [M3devel] returning record by value vs. > by ref? > > > > > > > > > > > > > > > > > > > > > > > > On Dec 1, 2007, at 5:14 PM, Jay wrote: > > > > > > > > > > > > > > > > > 1) Can pinning not be exposed reasonably in the > language? > > > > > > > > > I'll keep my pointer just a short time, in a local. > > > > > > > > > > > > > > > > Yes, that is a *hack* that will work only with the > current > > > > > > > > conservative garbage collector. In general, the compiler > > > might > > > > > > > > record that the local is a pointer derived from some > base > > > > > reference > > > > > > > > and if the GC decides to move the base object it can > > > adjust the > > > > > > > local > > > > > > > > derived pointer accordingly. > > > > > > > > > > > > > > > > > 2) surely it could be done at an outer layer? > > > > > > > > > Make volatile locals for things you don't want > > > enregistered? > > > > > > > > > > > > > > > > I don't understand what you mean by this. > > > > > > > > > > > > > > > > > Even the accessor function approach seems lame, given > > > that I > > > > > > > > > believe the Win32/x86 compiler doesn't inline.. :( > > > > > > > > > (does the gcc m3 inline across modules, or just > compiles > > > > > one at a > > > > > > > > > time?) > > > > > > > > > > > > > > > > gcc m3 inlines only within compilation units. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - Jay > > > > > > > > > > > > > > > > > > > > > > > > > > > > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > > > > > > > > > > From: hosking at cs.purdue.edu > > > > > > > > > > Subject: Re: [M3devel] returning record by value vs. > > > by ref? > > > > > > > > > > Date: Sat, 1 Dec 2007 15:23:19 -0500 > > > > > > > > > > To: rodney.bates at wichita.edu > > > > > > > > > > > > > > > > > > > > Correct! Anytime you create an l-value pointer. > > > > > > > > > > > > > > > > > > > > On Dec 1, 2007, at 2:31 PM, Rodney M. Bates wrote: > > > > > > > > > > > > > > > > > > > > > Tony Hosking wrote: > > > > > > > > > > >> I am assuming 's' here is an open array (REF > ARRAY OF > > > > > > > item) in > > > > > > > > > > >> which case it is allocated in the GC'd heap. > There is > > > > > > > certainly > > > > > > > > > > >> no way of safely getting an interior pointer > to items > > > > > in the > > > > > > > > > > >> stack in Modula-3 -- at least not one that you > can > > > upward > > > > > > > expose > > > > > > > > > > >> (to callers) via return from a procedure. The > > > > > difficulty in > > > > > > > > > > >> doing this is that the GC moves objects around > and > > > would > > > > > > > need to > > > > > > > > > > >> know where your manufactured interior pointer is > > > being > > > > > > > held and > > > > > > > > > > >> to which *object* (ie, the open array in this > > > case) it > > > > > > > refers so > > > > > > > > > > >> that it can 'fix' the pointer when the array > object > > > > > moves. > > > > > > > > > > >> Modula-3 provides a small concession to obtaining > > > > > downward > > > > > > > > > > >> exposed interior pointers using the VAR parameter > > > > > mode. For > > > > > > > > > > >> example you can pass 's[i]' as an actual > parameter > > > to a > > > > > > > VAR mode > > > > > > > > > > >> formal, effectively passing a pointer to the > > > callee. GC > > > > > > > can cope > > > > > > > > > > >> with this in one of two possible ways: 1) "Pin" > > > the array > > > > > > > so that > > > > > > > > > > >> it cannot be moved while the interior pointer > is held > > > > > on the > > > > > > > > > > >> stack or registers of any thread (this is the > > > approach > > > > > > > that CM3's > > > > > > > > > > >> conservative collector uses for now); or 2) > track the > > > > > > > creation of > > > > > > > > > > >> such interior pointers and how they are derived > > > from base > > > > > > > object > > > > > > > > > > >> references for use during GC. 2) requires much > > > more co- > > > > > > > operation > > > > > > > > > > >> from the compiler than the current gcc-based > backend > > > > > (with > > > > > > > all of > > > > > > > > > > >> its lovely optimizations and register > allocation) is > > > > > > > capable of > > > > > > > > > > >> doing. 1) is very cheap and does not impede > > > > > optimizations and > > > > > > > > > > >> register allocation. > > > > > > > > > > > > > > > > > > > > > > Presumably, this all also applies WITH-bound > > > > > identifiers, when > > > > > > > > > they > > > > > > > > > > > are > > > > > > > > > > > designators of interior components of heap > objects? > > > Are > > > > > > > there any > > > > > > > > > > > other > > > > > > > > > > > cases? > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > ------------------------------------------------------------- > > > > > > > > > > > Rodney M. Bates, retired assistant professor > > > > > > > > > > > Dept. of Computer Science, Wichita State > University > > > > > > > > > > > Wichita, KS 67260-0083 > > > > > > > > > > > 316-978-3922 > > > > > > > > > > > rodney.bates at wichita.edu > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your smile counts. The more smiles you share, the > more we > > > > > donate. > > > > > > > > > Join in! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Get the power of Windows + Web with the new Windows Live. > > > Power > > > > > up! > > > > > > > > > > > > > > > > > > > > > You keep typing, we keep giving. Download Messenger and > join the > > > > > i?m Initiative now. Join in! > > > > > > > > > > > > > Share life as it happens with the new Windows Live. Share now! > > > > > Your smile counts. The more smiles you share, the more we donate. > Join in! From mika at async.caltech.edu Mon Dec 10 12:38:44 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 10 Dec 2007 03:38:44 -0800 Subject: [M3devel] Using REFANYs to store integers? Message-ID: <200712101138.lBABci5I022046@camembert.async.caltech.edu> Hello Modula-3ers... I have a question about garbage collecting, pointers, and dirty tricks that I'm curious if anyone (Tony??) can answer. Here it is. I am considering writing a bytecode interpreter that is to run mixed into a Modula-3 environment, that is, it will be able to deal with bytecodes as well as Modula-3 objects. There is no problem with that of course, as bytecodes are "code" and Modula-3 objects are "objects" and can live on separate stacks. However, as an optimization (not an uncommon one in these types of systems), I'd like a space and time efficient representation for "small integers". A tried-and-true method (it goes back at least to the Smalltalk-80 runtime) is to realize that pointers (in my case REFANYs) always point to word-aligned addresses. We can then use integers that are congruent to 1, 2, and 3 (mod 4) to represent other types of data. What will happen if I LOOPHOLE such integers back and forth to REFANY? Will the garbage collector just ignore them? I wrote a test program that does it and it doesn't crash... except when you hit ctrl-C, it often dies with an assertion failure in RTCollector.m3.. (This both with my ancient PM3 on FreeBSD and a relatively recent update of CM3 on PPC_DARWIN.) If the garbage collector somehow disapproves of these integers, is there any conceivable thing that would be broken by making necessary adjustments to the garbage collector such that it would just ignore them? Or is there a better way of solving my problem? Best regards, Mika From hosking at cs.purdue.edu Mon Dec 10 15:08:39 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 10 Dec 2007 09:08:39 -0500 Subject: [M3devel] Using REFANYs to store integers? In-Reply-To: <200712101138.lBABci5I022046@camembert.async.caltech.edu> References: <200712101138.lBABci5I022046@camembert.async.caltech.edu> Message-ID: <09A27D37-5334-4269-98D0-8592F10D3AF7@cs.purdue.edu> Yikes. The current collector will expect to find an aligned reference in any global variable or heap field declared as a subtype of REFANY. It will break if it does not find one. You cannot reliably use the technique you describe with Modula-3 as it is currently defined, nor for that matter with any safe language. To do what you want in Modula-3 you would need to use ADDRESS and explicitly test for low bits when using ADDRESS values. Of course, then you'd need to write your own GC for your interpreter (probably not a bad idea anyway, given that you are in much more control). On Dec 10, 2007, at 6:38 AM, Mika Nystrom wrote: > Hello Modula-3ers... > > I have a question about garbage collecting, pointers, and dirty > tricks that I'm curious if anyone (Tony??) can answer. > > Here it is. I am considering writing a bytecode interpreter that > is to run mixed into a Modula-3 environment, that is, it will be > able to deal with bytecodes as well as Modula-3 objects. There is > no problem with that of course, as bytecodes are "code" and Modula-3 > objects are "objects" and can live on separate stacks. However, > as an optimization (not an uncommon one in these types of systems), > I'd like a space and time efficient representation for "small > integers". A tried-and-true method (it goes back at least to the > Smalltalk-80 runtime) is to realize that pointers (in my case > REFANYs) always point to word-aligned addresses. We can then use > integers that are congruent to 1, 2, and 3 (mod 4) to represent > other types of data. > > What will happen if I LOOPHOLE such integers back and forth to > REFANY? Will the garbage collector just ignore them? I wrote a > test program that does it and it doesn't crash... except when you > hit ctrl-C, it often dies with an assertion failure in > RTCollector.m3.. (This both with my ancient PM3 on FreeBSD and a > relatively recent update of CM3 on PPC_DARWIN.) If the garbage > collector somehow disapproves of these integers, is there any > conceivable thing that would be broken by making necessary adjustments > to the garbage collector such that it would just ignore them? > Or is there a better way of solving my problem? > > Best regards, > Mika From mika at async.caltech.edu Mon Dec 10 21:21:13 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 10 Dec 2007 12:21:13 -0800 Subject: [M3devel] Using REFANYs to store integers? In-Reply-To: Your message of "Mon, 10 Dec 2007 13:50:57 CST." <475D98A1.5080604@wichita.edu> Message-ID: <200712102021.lBAKLD4C037596@camembert.async.caltech.edu> Hi Rodney, You're reading my mind. What I am thinking of doing is that I want to optimize the handling of small integers (only), exactly the way it's done in Smalltalk, that is, immutable, single-instance objects. And only the interpreter will ever dereference the objects, so it would check the LSBs---if they are set to zero, it will assume that it's a heap object, if anything else, it's a special immutable value of some sort. I'm well aware it's a very dirty trick to attempt! But I was thinking that by doing this sort of thing I could avoid having to code my own garbage collector. I'm not surprised that the current garbage collector has issues with it but I also cannot think of a reason why one couldn't make it ignore unaligned "pointers" unless the trick is already used for some purpose I am not aware of. Mika "Rodney M. Bates" writes: >I presume "pointers" that are not 0 MOD 4 "refer to" some kinds >of immutable, single-instance objects and don't actually point >to heap objects in need of collection, as in Smalltalk? I would >think it would be a simple modification of the existing M3 GC to >just make it ignore words containing misaligned pointers. > >Will only interpreted bytecode ever dereference these pointers? >Or does M3 compiler-generated code also dereference them? Then >the compiler would also have to generate checks and do whatever >with misaligned pointers. > >Mika Nystrom wrote: >> Hello Modula-3ers... >> >> I have a question about garbage collecting, pointers, and dirty >> tricks that I'm curious if anyone (Tony??) can answer. >> >> Here it is. I am considering writing a bytecode interpreter that >> is to run mixed into a Modula-3 environment, that is, it will be >> able to deal with bytecodes as well as Modula-3 objects. There is >> no problem with that of course, as bytecodes are "code" and Modula-3 >> objects are "objects" and can live on separate stacks. However, >> as an optimization (not an uncommon one in these types of systems), >> I'd like a space and time efficient representation for "small >> integers". A tried-and-true method (it goes back at least to the >> Smalltalk-80 runtime) is to realize that pointers (in my case >> REFANYs) always point to word-aligned addresses. We can then use >> integers that are congruent to 1, 2, and 3 (mod 4) to represent >> other types of data. >> >> What will happen if I LOOPHOLE such integers back and forth to >> REFANY? Will the garbage collector just ignore them? I wrote a >> test program that does it and it doesn't crash... except when you >> hit ctrl-C, it often dies with an assertion failure in >> RTCollector.m3.. (This both with my ancient PM3 on FreeBSD and a >> relatively recent update of CM3 on PPC_DARWIN.) If the garbage >> collector somehow disapproves of these integers, is there any >> conceivable thing that would be broken by making necessary adjustments >> to the garbage collector such that it would just ignore them? >> Or is there a better way of solving my problem? >> >> Best regards, >> Mika >> > >-- >------------------------------------------------------------- >Rodney M. Bates, retired assistant professor >Dept. of Computer Science, Wichita State University >Wichita, KS 67260-0083 >316-978-3922 >rodney.bates at wichita.edu From hosking at cs.purdue.edu Mon Dec 10 23:51:29 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 10 Dec 2007 17:51:29 -0500 Subject: [M3devel] Using REFANYs to store integers? In-Reply-To: <200712102021.lBAKLD4C037596@camembert.async.caltech.edu> References: <200712102021.lBAKLD4C037596@camembert.async.caltech.edu> Message-ID: <9520B700-D9EE-4A1B-ACD0-CB1DEA6C6A7C@cs.purdue.edu> The LSB trick is something that one could teach the current implementation to handle, but I note that there is *nothing* in the language definition that would mean this hack could ever be portable. Moreover, there is reason to expect that a particular GC implementation might use this same trick internally, in which case you have a conflict between your hack and that implementation. Basically, you should not assume *any* particular representation for REFANY in Modula-3. For example, an implementation would be free to use a level of indirection (ie, "handles" or an object table) to implement M3 REFANY. In sum, I think what you propose is a nasty hack. Better to implement your own GC anyway, since it is likely to be much better to exploit the semantics of your interpreter/language for best behavior. On Dec 10, 2007, at 3:21 PM, Mika Nystrom wrote: > Hi Rodney, > > You're reading my mind. What I am thinking of doing is that I want > to optimize the handling of small integers (only), exactly the way > it's done in Smalltalk, that is, immutable, single-instance objects. > And only the interpreter will ever dereference the objects, so it > would check the LSBs---if they are set to zero, it will assume that > it's a heap object, if anything else, it's a special immutable value > of some sort. > > I'm well aware it's a very dirty trick to attempt! But I was > thinking that by doing this sort of thing I could avoid having to > code my own garbage collector. I'm not surprised that the current > garbage collector has issues with it but I also cannot think of a > reason why one couldn't make it ignore unaligned "pointers" unless > the trick is already used for some purpose I am not aware of. > > Mika > > "Rodney M. Bates" writes: >> I presume "pointers" that are not 0 MOD 4 "refer to" some kinds >> of immutable, single-instance objects and don't actually point >> to heap objects in need of collection, as in Smalltalk? I would >> think it would be a simple modification of the existing M3 GC to >> just make it ignore words containing misaligned pointers. >> >> Will only interpreted bytecode ever dereference these pointers? >> Or does M3 compiler-generated code also dereference them? Then >> the compiler would also have to generate checks and do whatever >> with misaligned pointers. >> >> Mika Nystrom wrote: >>> Hello Modula-3ers... >>> >>> I have a question about garbage collecting, pointers, and dirty >>> tricks that I'm curious if anyone (Tony??) can answer. >>> >>> Here it is. I am considering writing a bytecode interpreter that >>> is to run mixed into a Modula-3 environment, that is, it will be >>> able to deal with bytecodes as well as Modula-3 objects. There is >>> no problem with that of course, as bytecodes are "code" and Modula-3 >>> objects are "objects" and can live on separate stacks. However, >>> as an optimization (not an uncommon one in these types of systems), >>> I'd like a space and time efficient representation for "small >>> integers". A tried-and-true method (it goes back at least to the >>> Smalltalk-80 runtime) is to realize that pointers (in my case >>> REFANYs) always point to word-aligned addresses. We can then use >>> integers that are congruent to 1, 2, and 3 (mod 4) to represent >>> other types of data. >>> >>> What will happen if I LOOPHOLE such integers back and forth to >>> REFANY? Will the garbage collector just ignore them? I wrote a >>> test program that does it and it doesn't crash... except when you >>> hit ctrl-C, it often dies with an assertion failure in >>> RTCollector.m3.. (This both with my ancient PM3 on FreeBSD and a >>> relatively recent update of CM3 on PPC_DARWIN.) If the garbage >>> collector somehow disapproves of these integers, is there any >>> conceivable thing that would be broken by making necessary >>> adjustments >>> to the garbage collector such that it would just ignore them? >>> Or is there a better way of solving my problem? >>> >>> Best regards, >>> Mika >>> >> >> -- >> ------------------------------------------------------------- >> Rodney M. Bates, retired assistant professor >> Dept. of Computer Science, Wichita State University >> Wichita, KS 67260-0083 >> 316-978-3922 >> rodney.bates at wichita.edu From mika at async.caltech.edu Tue Dec 11 00:33:44 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 10 Dec 2007 15:33:44 -0800 Subject: [M3devel] Using REFANYs to store integers? In-Reply-To: Your message of "Mon, 10 Dec 2007 17:51:29 EST." <9520B700-D9EE-4A1B-ACD0-CB1DEA6C6A7C@cs.purdue.edu> Message-ID: <200712102333.lBANXiAe044857@camembert.async.caltech.edu> Well, come to think of it... I'm not sure I can even do my own GC. The idea is that the interpreter I am working on would have more or less unrestricted access to the M3 environment, anyhow, and that many of the objects on its stacks will be plain old M3 objects, which will be handled as opaque handles by the interpreter. In other words, I'd have to have and worry about two garbage collectors (M3 + interpreter) if I follow your suggestion. I was really hoping to avoid that. I was also hoping to use your excellent garbage collector rather than having to worry about that too, in addition to all the other issues that come up in coding bytecode compilers, interpreters, with all the other runtime support etc etc. Since I clearly have to support versions of M3 that don't appreciate the LSB hack I am just going to have to be able to represent small integers as something along the lines of TYPE SmallInteger = OBJECT v : INTEGER END anyhow. This is not a problem, it's just going to be slow, since I anticipate that most of the work done by the interpreter will be manipulating small integers (array indices, etc.) Tony, don't worry, I'm not going to give you (much of) a hard time if you come up with a beautiful garbage collector that's incompatible with my "nasty hack"! In any case, I am just thinking aloud (awrite?) and you gentlemen have fully satisfied my curiosity with your answers to my questions. Thanks! Mika Tony Hosking writes: >The LSB trick is something that one could teach the current >implementation to handle, but I note that there is *nothing* in the >language definition that would mean this hack could ever be >portable. Moreover, there is reason to expect that a particular GC >implementation might use this same trick internally, in which case >you have a conflict between your hack and that implementation. >Basically, you should not assume *any* particular representation for >REFANY in Modula-3. For example, an implementation would be free to >use a level of indirection (ie, "handles" or an object table) to >implement M3 REFANY. In sum, I think what you propose is a nasty >hack. Better to implement your own GC anyway, since it is likely to >be much better to exploit the semantics of your interpreter/language >for best behavior. > >On Dec 10, 2007, at 3:21 PM, Mika Nystrom wrote: > >> Hi Rodney, >> >> You're reading my mind. What I am thinking of doing is that I want >> to optimize the handling of small integers (only), exactly the way >> it's done in Smalltalk, that is, immutable, single-instance objects. >> And only the interpreter will ever dereference the objects, so it >> would check the LSBs---if they are set to zero, it will assume that >> it's a heap object, if anything else, it's a special immutable value >> of some sort. >> >> I'm well aware it's a very dirty trick to attempt! But I was >> thinking that by doing this sort of thing I could avoid having to >> code my own garbage collector. I'm not surprised that the current >> garbage collector has issues with it but I also cannot think of a >> reason why one couldn't make it ignore unaligned "pointers" unless >> the trick is already used for some purpose I am not aware of. >> >> Mika >> >> "Rodney M. Bates" writes: >>> I presume "pointers" that are not 0 MOD 4 "refer to" some kinds >>> of immutable, single-instance objects and don't actually point >>> to heap objects in need of collection, as in Smalltalk? I would >>> think it would be a simple modification of the existing M3 GC to >>> just make it ignore words containing misaligned pointers. >>> >>> Will only interpreted bytecode ever dereference these pointers? >>> Or does M3 compiler-generated code also dereference them? Then >>> the compiler would also have to generate checks and do whatever >>> with misaligned pointers. >>> >>> Mika Nystrom wrote: >>>> Hello Modula-3ers... >>>> >>>> I have a question about garbage collecting, pointers, and dirty >>>> tricks that I'm curious if anyone (Tony??) can answer. >>>> >>>> Here it is. I am considering writing a bytecode interpreter that >>>> is to run mixed into a Modula-3 environment, that is, it will be >>>> able to deal with bytecodes as well as Modula-3 objects. There is >>>> no problem with that of course, as bytecodes are "code" and Modula-3 >>>> objects are "objects" and can live on separate stacks. However, >>>> as an optimization (not an uncommon one in these types of systems), >>>> I'd like a space and time efficient representation for "small >>>> integers". A tried-and-true method (it goes back at least to the >>>> Smalltalk-80 runtime) is to realize that pointers (in my case >>>> REFANYs) always point to word-aligned addresses. We can then use >>>> integers that are congruent to 1, 2, and 3 (mod 4) to represent >>>> other types of data. >>>> >>>> What will happen if I LOOPHOLE such integers back and forth to >>>> REFANY? Will the garbage collector just ignore them? I wrote a >>>> test program that does it and it doesn't crash... except when you >>>> hit ctrl-C, it often dies with an assertion failure in >>>> RTCollector.m3.. (This both with my ancient PM3 on FreeBSD and a >>>> relatively recent update of CM3 on PPC_DARWIN.) If the garbage >>>> collector somehow disapproves of these integers, is there any >>>> conceivable thing that would be broken by making necessary >>>> adjustments >>>> to the garbage collector such that it would just ignore them? >>>> Or is there a better way of solving my problem? >>>> >>>> Best regards, >>>> Mika >>>> >>> >>> -- >>> ------------------------------------------------------------- >>> Rodney M. Bates, retired assistant professor >>> Dept. of Computer Science, Wichita State University >>> Wichita, KS 67260-0083 >>> 316-978-3922 >>> rodney.bates at wichita.edu From hosking at cs.purdue.edu Tue Dec 11 04:24:45 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 10 Dec 2007 22:24:45 -0500 Subject: [M3devel] Using REFANYs to store integers? In-Reply-To: <200712102333.lBANXiAe044857@camembert.async.caltech.edu> References: <200712102333.lBANXiAe044857@camembert.async.caltech.edu> Message-ID: I didn't mean to disparage your suggestion -- just pointing out some of the pitfalls. Certainly, the current collectors will have problems if you store tagged values in REFANY fields, since it expects to find aligned references there. I can see a couple of options that might work, some of which might use the WeakRef interface to control reachability. I imagine we could come up with some sort of API that would support this. It might even be an interesting result... On Dec 10, 2007, at 6:33 PM, Mika Nystrom wrote: > > Well, come to think of it... I'm not sure I can even do my own GC. > The idea is that the interpreter I am working on would have more > or less unrestricted access to the M3 environment, anyhow, and that > many of the objects on its stacks will be plain old M3 objects, > which will be handled as opaque handles by the interpreter. In > other words, I'd have to have and worry about two garbage collectors > (M3 + interpreter) if I follow your suggestion. I was really hoping > to avoid that. I was also hoping to use your excellent garbage > collector rather than having to worry about that too, in addition > to all the other issues that come up in coding bytecode compilers, > interpreters, with all the other runtime support etc etc. > > Since I clearly have to support versions of M3 that don't appreciate > the LSB hack I am just going to have to be able to represent small > integers as something along the lines of > > TYPE SmallInteger = OBJECT v : INTEGER END > > anyhow. This is not a problem, it's just going to be slow, since > I anticipate that most of the work done by the interpreter will be > manipulating small integers (array indices, etc.) Tony, don't > worry, I'm not going to give you (much of) a hard time if you come > up with a beautiful garbage collector that's incompatible with my > "nasty hack"! > > In any case, I am just thinking aloud (awrite?) and you gentlemen > have fully satisfied my curiosity with your answers to my questions. > Thanks! > > Mika > > Tony Hosking writes: >> The LSB trick is something that one could teach the current >> implementation to handle, but I note that there is *nothing* in the >> language definition that would mean this hack could ever be >> portable. Moreover, there is reason to expect that a particular GC >> implementation might use this same trick internally, in which case >> you have a conflict between your hack and that implementation. >> Basically, you should not assume *any* particular representation for >> REFANY in Modula-3. For example, an implementation would be free to >> use a level of indirection (ie, "handles" or an object table) to >> implement M3 REFANY. In sum, I think what you propose is a nasty >> hack. Better to implement your own GC anyway, since it is likely to >> be much better to exploit the semantics of your interpreter/language >> for best behavior. >> >> On Dec 10, 2007, at 3:21 PM, Mika Nystrom wrote: >> >>> Hi Rodney, >>> >>> You're reading my mind. What I am thinking of doing is that I want >>> to optimize the handling of small integers (only), exactly the way >>> it's done in Smalltalk, that is, immutable, single-instance objects. >>> And only the interpreter will ever dereference the objects, so it >>> would check the LSBs---if they are set to zero, it will assume that >>> it's a heap object, if anything else, it's a special immutable value >>> of some sort. >>> >>> I'm well aware it's a very dirty trick to attempt! But I was >>> thinking that by doing this sort of thing I could avoid having to >>> code my own garbage collector. I'm not surprised that the current >>> garbage collector has issues with it but I also cannot think of a >>> reason why one couldn't make it ignore unaligned "pointers" unless >>> the trick is already used for some purpose I am not aware of. >>> >>> Mika >>> >>> "Rodney M. Bates" writes: >>>> I presume "pointers" that are not 0 MOD 4 "refer to" some kinds >>>> of immutable, single-instance objects and don't actually point >>>> to heap objects in need of collection, as in Smalltalk? I would >>>> think it would be a simple modification of the existing M3 GC to >>>> just make it ignore words containing misaligned pointers. >>>> >>>> Will only interpreted bytecode ever dereference these pointers? >>>> Or does M3 compiler-generated code also dereference them? Then >>>> the compiler would also have to generate checks and do whatever >>>> with misaligned pointers. >>>> >>>> Mika Nystrom wrote: >>>>> Hello Modula-3ers... >>>>> >>>>> I have a question about garbage collecting, pointers, and dirty >>>>> tricks that I'm curious if anyone (Tony??) can answer. >>>>> >>>>> Here it is. I am considering writing a bytecode interpreter that >>>>> is to run mixed into a Modula-3 environment, that is, it will be >>>>> able to deal with bytecodes as well as Modula-3 objects. There is >>>>> no problem with that of course, as bytecodes are "code" and >>>>> Modula-3 >>>>> objects are "objects" and can live on separate stacks. However, >>>>> as an optimization (not an uncommon one in these types of >>>>> systems), >>>>> I'd like a space and time efficient representation for "small >>>>> integers". A tried-and-true method (it goes back at least to the >>>>> Smalltalk-80 runtime) is to realize that pointers (in my case >>>>> REFANYs) always point to word-aligned addresses. We can then use >>>>> integers that are congruent to 1, 2, and 3 (mod 4) to represent >>>>> other types of data. >>>>> >>>>> What will happen if I LOOPHOLE such integers back and forth to >>>>> REFANY? Will the garbage collector just ignore them? I wrote a >>>>> test program that does it and it doesn't crash... except when you >>>>> hit ctrl-C, it often dies with an assertion failure in >>>>> RTCollector.m3.. (This both with my ancient PM3 on FreeBSD and a >>>>> relatively recent update of CM3 on PPC_DARWIN.) If the garbage >>>>> collector somehow disapproves of these integers, is there any >>>>> conceivable thing that would be broken by making necessary >>>>> adjustments >>>>> to the garbage collector such that it would just ignore them? >>>>> Or is there a better way of solving my problem? >>>>> >>>>> Best regards, >>>>> Mika >>>>> >>>> >>>> -- >>>> ------------------------------------------------------------- >>>> Rodney M. Bates, retired assistant professor >>>> Dept. of Computer Science, Wichita State University >>>> Wichita, KS 67260-0083 >>>> 316-978-3922 >>>> rodney.bates at wichita.edu From mika at async.caltech.edu Wed Dec 12 10:47:52 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 12 Dec 2007 01:47:52 -0800 Subject: [M3devel] Using REFANYs to store integers? In-Reply-To: Your message of "Mon, 10 Dec 2007 22:24:45 EST." Message-ID: <200712120947.lBC9lq5d019613@camembert.async.caltech.edu> Tony Hosking writes: >I didn't mean to disparage your suggestion -- just pointing out some >of the pitfalls. Certainly, the current collectors will have >problems if you store tagged values in REFANY fields, since it >expects to find aligned references there. I can see a couple of >options that might work, some of which might use the WeakRef >interface to control reachability. I imagine we could come up with >some sort of API that would support this. It might even be an >interesting result... > Oh I know that. It's clear that even if one does use the hack I have described, it would be criminal to release code that couldn't survive without it. As you point out there are many conceivable M3 implementations that might not support such a nasty hack. I think your idea of an API could be an interesting exercise---you could "squirrel away" data in REFANYs that don't actually refer to anything but are themselves values (ANYs?). Of course there's not much point (is there?) unless the squirreling and un-squirreling is more efficient than an extra memory allocation and dereference. I take it that the API could also tell the hacker when the hack is unavailable, for any of the reasons you have mentioned... Mika >On Dec 10, 2007, at 6:33 PM, Mika Nystrom wrote: > >> >> Well, come to think of it... I'm not sure I can even do my own GC. >> The idea is that the interpreter I am working on would have more >> or less unrestricted access to the M3 environment, anyhow, and that >> many of the objects on its stacks will be plain old M3 objects, >> which will be handled as opaque handles by the interpreter. In >> other words, I'd have to have and worry about two garbage collectors >> (M3 + interpreter) if I follow your suggestion. I was really hoping >> to avoid that. I was also hoping to use your excellent garbage >> collector rather than having to worry about that too, in addition >> to all the other issues that come up in coding bytecode compilers, >> interpreters, with all the other runtime support etc etc. >> >> Since I clearly have to support versions of M3 that don't appreciate >> the LSB hack I am just going to have to be able to represent small >> integers as something along the lines of >> >> TYPE SmallInteger = OBJECT v : INTEGER END >> >> anyhow. This is not a problem, it's just going to be slow, since >> I anticipate that most of the work done by the interpreter will be >> manipulating small integers (array indices, etc.) Tony, don't >> worry, I'm not going to give you (much of) a hard time if you come >> up with a beautiful garbage collector that's incompatible with my >> "nasty hack"! >> >> In any case, I am just thinking aloud (awrite?) and you gentlemen >> have fully satisfied my curiosity with your answers to my questions. >> Thanks! >> >> Mika >> >> Tony Hosking writes: >>> The LSB trick is something that one could teach the current >>> implementation to handle, but I note that there is *nothing* in the >>> language definition that would mean this hack could ever be >>> portable. Moreover, there is reason to expect that a particular GC >>> implementation might use this same trick internally, in which case >>> you have a conflict between your hack and that implementation. >>> Basically, you should not assume *any* particular representation for >>> REFANY in Modula-3. For example, an implementation would be free to >>> use a level of indirection (ie, "handles" or an object table) to >>> implement M3 REFANY. In sum, I think what you propose is a nasty >>> hack. Better to implement your own GC anyway, since it is likely to >>> be much better to exploit the semantics of your interpreter/language >>> for best behavior. >>> >>> On Dec 10, 2007, at 3:21 PM, Mika Nystrom wrote: >>> >>>> Hi Rodney, >>>> >>>> You're reading my mind. What I am thinking of doing is that I want >>>> to optimize the handling of small integers (only), exactly the way >>>> it's done in Smalltalk, that is, immutable, single-instance objects. >>>> And only the interpreter will ever dereference the objects, so it >>>> would check the LSBs---if they are set to zero, it will assume that >>>> it's a heap object, if anything else, it's a special immutable value >>>> of some sort. >>>> >>>> I'm well aware it's a very dirty trick to attempt! But I was >>>> thinking that by doing this sort of thing I could avoid having to >>>> code my own garbage collector. I'm not surprised that the current >>>> garbage collector has issues with it but I also cannot think of a >>>> reason why one couldn't make it ignore unaligned "pointers" unless >>>> the trick is already used for some purpose I am not aware of. >>>> >>>> Mika >>>> >>>> "Rodney M. Bates" writes: >>>>> I presume "pointers" that are not 0 MOD 4 "refer to" some kinds >>>>> of immutable, single-instance objects and don't actually point >>>>> to heap objects in need of collection, as in Smalltalk? I would >>>>> think it would be a simple modification of the existing M3 GC to >>>>> just make it ignore words containing misaligned pointers. >>>>> >>>>> Will only interpreted bytecode ever dereference these pointers? >>>>> Or does M3 compiler-generated code also dereference them? Then >>>>> the compiler would also have to generate checks and do whatever >>>>> with misaligned pointers. >>>>> >>>>> Mika Nystrom wrote: >>>>>> Hello Modula-3ers... >>>>>> >>>>>> I have a question about garbage collecting, pointers, and dirty >>>>>> tricks that I'm curious if anyone (Tony??) can answer. >>>>>> >>>>>> Here it is. I am considering writing a bytecode interpreter that >>>>>> is to run mixed into a Modula-3 environment, that is, it will be >>>>>> able to deal with bytecodes as well as Modula-3 objects. There is >>>>>> no problem with that of course, as bytecodes are "code" and >>>>>> Modula-3 >>>>>> objects are "objects" and can live on separate stacks. However, >>>>>> as an optimization (not an uncommon one in these types of >>>>>> systems), >>>>>> I'd like a space and time efficient representation for "small >>>>>> integers". A tried-and-true method (it goes back at least to the >>>>>> Smalltalk-80 runtime) is to realize that pointers (in my case >>>>>> REFANYs) always point to word-aligned addresses. We can then use >>>>>> integers that are congruent to 1, 2, and 3 (mod 4) to represent >>>>>> other types of data. >>>>>> >>>>>> What will happen if I LOOPHOLE such integers back and forth to >>>>>> REFANY? Will the garbage collector just ignore them? I wrote a >>>>>> test program that does it and it doesn't crash... except when you >>>>>> hit ctrl-C, it often dies with an assertion failure in >>>>>> RTCollector.m3.. (This both with my ancient PM3 on FreeBSD and a >>>>>> relatively recent update of CM3 on PPC_DARWIN.) If the garbage >>>>>> collector somehow disapproves of these integers, is there any >>>>>> conceivable thing that would be broken by making necessary >>>>>> adjustments >>>>>> to the garbage collector such that it would just ignore them? >>>>>> Or is there a better way of solving my problem? >>>>>> >>>>>> Best regards, >>>>>> Mika >>>>>> >>>>> >>>>> -- >>>>> ------------------------------------------------------------- >>>>> Rodney M. Bates, retired assistant professor >>>>> Dept. of Computer Science, Wichita State University >>>>> Wichita, KS 67260-0083 >>>>> 316-978-3922 >>>>> rodney.bates at wichita.edu From wagner at elegosoft.com Sat Dec 15 23:50:51 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 15 Dec 2007 23:50:51 +0100 Subject: [M3devel] Spanish speaking CM3 users? Message-ID: <20071215235051.rhq0fgeabk4k48gk@mail.elegosoft.com> Hi, I found this in our company's contact box. Is there somebody here with better Spanish knowledge than me who'd like to help? Olaf ----- Forwarded message from anietog at unal.edu.co ----- Date: Sat, 15 Dec 2007 17:55:45 +0100 (CET) From: Angela Reply-To: Angela Subject: Anfrage Mailformular To: info at elego.de NAME: Angela EMAIL: anietog at unal.edu.co ADDRESS: Hola, escribo porque tengo un problema al tratar de compilar el compilador de fase 1, esto es lo que me aparece: .... new source -> compiling Text.i3 new source -> compiling RTProcedureSRC.i3 new source -> compiling Fingerprint.i3 new source -> compiling RTProcedure.i3 new source -> compiling RTStack.i3 new source -> compiling RTAllocStats.m3 "../src/runtime/common/RTAllocStats.m3", line 46: undefined runtime symbol !! (RTHooks.AllocateTracedRef) *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x80c5c3c = StartCall + 0x18 in ../src/values/Procedure.m3 *** Aborted (core dumped) *** execution of failed *** Agradezco cualquier colaboraci?n ya que aun no he podido culminar mi instalacion de cm3. ----- End forwarded message ----- -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- NAME: Angela EMAIL: anietog at unal.edu.co ADDRESS: Hola, escribo porque tengo un problema al tratar de compilar el compilador de fase 1, esto es lo que me aparece: .... new source -> compiling Text.i3 new source -> compiling RTProcedureSRC.i3 new source -> compiling Fingerprint.i3 new source -> compiling RTProcedure.i3 new source -> compiling RTStack.i3 new source -> compiling RTAllocStats.m3 "../src/runtime/common/RTAllocStats.m3", line 46: undefined runtime symbol !! (RTHooks.AllocateTracedRef) *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x80c5c3c = StartCall + 0x18 in ../src/values/Procedure.m3 *** Aborted (core dumped) *** execution of failed *** Agradezco cualquier colaboraci?n ya que aun no he podido culminar mi instalacion de cm3. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ndantam at purdue.edu Sun Dec 16 00:42:11 2007 From: ndantam at purdue.edu (Neil T. Dantam) Date: Sat, 15 Dec 2007 18:42:11 -0500 Subject: [M3devel] Spanish speaking CM3 users? In-Reply-To: <20071215235051.rhq0fgeabk4k48gk@mail.elegosoft.com> References: <20071215235051.rhq0fgeabk4k48gk@mail.elegosoft.com> Message-ID: <47646653.4070106@purdue.edu> Olaf, I can at least translate the Spanish for you. Angela, ?Tratar los instrucciones de este mensaje? (Did you try the instructions in this email?) https://mail.elegosoft.com/pipermail/m3devel/2007-June/000227.html Describen como compilar el compilador. (They describe how to bootstrap the compiler.) Olaf Wagner wrote: > ----- Forwarded message from anietog at unal.edu.co ----- > Date: Sat, 15 Dec 2007 17:55:45 +0100 (CET) > From: Angela > Reply-To: Angela > Subject: Anfrage Mailformular > To: info at elego.de > > NAME: Angela > EMAIL: anietog at unal.edu.co > ADDRESS: > Hola, escribo porque tengo un problema al tratar de compilar el > compilador de fase 1, esto es lo que me aparece: Hello, I'm writing because I have a problem regarding compiling phase one of the compiler. This is what I see: > .... > new source -> compiling Text.i3 > new source -> compiling RTProcedureSRC.i3 > new source -> compiling Fingerprint.i3 > new source -> compiling RTProcedure.i3 > new source -> compiling RTStack.i3 > new source -> compiling RTAllocStats.m3 > "../src/runtime/common/RTAllocStats.m3", line 46: undefined runtime > symbol !! (RTHooks.AllocateTracedRef) > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0x80c5c3c = StartCall + 0x18 in ../src/values/Procedure.m3 > *** > > Aborted (core dumped) > *** execution of failed *** > > > Agradezco cualquier colaboraci?n ya que aun no he podido culminar mi > instalacion de cm3. I would appreciate any help, because I could not finish my installation of cm3. > > ----- End forwarded message ----- -- Neil T. Dantam From mika at async.caltech.edu Sun Dec 16 01:18:29 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 15 Dec 2007 16:18:29 -0800 Subject: [M3devel] Ubuntu problems Message-ID: <200712160018.lBG0ITO5026048@camembert.async.caltech.edu> Hello Modula-3 people, I am trying to build things with CM3 on a relatively recent Ubuntu system (don't ask me why...) and I am running into a segfault that I haven't seen mentioned before. I have a feeling it has something to do with stack formats, but I'm not sure what to do next. I downloaded the cm3-5.4.0 binaries and started with that. The compiler in the binary distribution runs, but it appears to produce garbage. I first tried bootstrapping but it crashes the moment it tries to execute something it has compiled itself. So then I tried hello, world, with the same results... Here's the system identification: mika at edwards:~/test/src$ uname -a Linux edwards 2.6.20-16-386 #2 Sun Sep 23 19:47:10 UTC 2007 i686 GNU/Linux I made a "hello, world" program as follows: MODULE Main; IMPORT IO; BEGIN IO.Put("Hello, world!\n") END Main. Compiled with cm3 directly from the distributed cm3-5.4.0 for LINUXLIBC6 and I get a crash in CsetjmpASM.s (as far as I can tell). The last unclobbered stack I seem to be able to get in m3gdb is this: Breakpoint 5, 0xb75e5fb4 in _setjmp () at ../src/C/LINUXLIBC6/CsetjmpASM.s:31 31 in ../src/C/LINUXLIBC6/CsetjmpASM.s (m3gdb) where #0 0xb75e5fb4 in _setjmp () at ../src/C/LINUXLIBC6/CsetjmpASM.s:31 #1 0xb75dbd51 in RTThread__Transfer (from=0xbfe28530, to=0xbfe28530) at ../src/runtime/LINUXLIBC6/RTThreadC.c:14 #2 0xb75dbaed in FlushStackCache () at RTThread.m3:65 #3 0xb75e27c9 in DetermineContext (oldSP=Invalid C/C++ type code 35 in symbol table. ) at ThreadPosix.m3:1101 #4 0xb75e270d in InitTopContext (c=Invalid C/C++ type code 30 in symbol table. ) at ThreadPosix.m3:1076 #5 0xb75e4325 in Init () at ThreadPosix.m3:1498 #6 0xb75c9592 in InitRuntime (p_argc=Invalid C/C++ type code 39 in symbol table. ) at RTLinker.m3:59 #7 0x08048861 in main (argc=1, argv=0xbfe28824, envp=0xbfe2882c) at _m3main.mc:3 (m3gdb) cont Continuing. Program received signal SIGSEGV, Segmentation fault. 0xa8dbaede in ?? () s.sp was lately 16_b75af6b9, if that means anything at all. Oh yes, one more thing: setting LD_POINTER_GUARD to 0 before running the program has no effect on the crash. Any suggestions for how one might make progress on this? Mika From mika at async.caltech.edu Sun Dec 16 02:35:54 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 15 Dec 2007 17:35:54 -0800 Subject: [M3devel] Ubuntu problems In-Reply-To: Your message of "Sat, 15 Dec 2007 16:18:29 PST." <200712160018.lBG0ITO5026048@camembert.async.caltech.edu> Message-ID: <200712160135.lBG1ZsZ2028488@camembert.async.caltech.edu> Sorry, I have now read the mailing list archives a bit better. I am going to try bootstrapping the latest CVS with Tony's cm3 binary, to use pthreads... Mika Mika Nystrom writes: >Hello Modula-3 people, > >I am trying to build things with CM3 on a relatively recent Ubuntu >system (don't ask me why...) and I am running into a segfault that >I haven't seen mentioned before. I have a feeling it has something >to do with stack formats, but I'm not sure what to do next. > >I downloaded the cm3-5.4.0 binaries and started with that. The >compiler in the binary distribution runs, but it appears to produce >garbage. I first tried bootstrapping but it crashes the moment it >tries to execute something it has compiled itself. So then I tried >hello, world, with the same results... > >Here's the system identification: > >mika at edwards:~/test/src$ uname -a >Linux edwards 2.6.20-16-386 #2 Sun Sep 23 19:47:10 UTC 2007 i686 GNU/Linux > >I made a "hello, world" program as follows: > >MODULE Main; >IMPORT IO; > >BEGIN IO.Put("Hello, world!\n") END Main. > >Compiled with cm3 directly from the distributed cm3-5.4.0 for >LINUXLIBC6 and I get a crash in CsetjmpASM.s (as far as I can tell). >The last unclobbered stack I seem to be able to get in m3gdb is >this: > >Breakpoint 5, 0xb75e5fb4 in _setjmp () at ../src/C/LINUXLIBC6/CsetjmpASM.s:31 >31 in ../src/C/LINUXLIBC6/CsetjmpASM.s >(m3gdb) where >#0 0xb75e5fb4 in _setjmp () at ../src/C/LINUXLIBC6/CsetjmpASM.s:31 >#1 0xb75dbd51 in RTThread__Transfer (from=0xbfe28530, to=0xbfe28530) at ../sr >c/runtime/LINUXLIBC6/RTThreadC.c:14 >#2 0xb75dbaed in FlushStackCache () at RTThread.m3:65 >#3 0xb75e27c9 in DetermineContext (oldSP=Invalid C/C++ type code 35 in symbol > table. >) at ThreadPosix.m3:1101 >#4 0xb75e270d in InitTopContext (c=Invalid C/C++ type code 30 in symbol table >. >) at ThreadPosix.m3:1076 >#5 0xb75e4325 in Init () at ThreadPosix.m3:1498 >#6 0xb75c9592 in InitRuntime (p_argc=Invalid C/C++ type code 39 in symbol tab >le. >) at RTLinker.m3:59 >#7 0x08048861 in main (argc=1, argv=0xbfe28824, envp=0xbfe2882c) at _m3main.m >c:3 >(m3gdb) cont >Continuing. > >Program received signal SIGSEGV, Segmentation fault. >0xa8dbaede in ?? () > >s.sp was lately 16_b75af6b9, if that means anything at all. > >Oh yes, one more thing: setting LD_POINTER_GUARD to 0 before running >the program has no effect on the crash. > >Any suggestions for how one might make progress on this? > > Mika From dabenavidesd at yahoo.es Sun Dec 16 02:38:03 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 16 Dec 2007 02:38:03 +0100 (CET) Subject: [M3devel] Ubuntu problems In-Reply-To: <200712160018.lBG0ITO5026048@camembert.async.caltech.edu> Message-ID: <147313.32986.qm@web27106.mail.ukl.yahoo.com> Hi Mika, what are you seeing is the problem of libc setjmp/longjmp issue that we maybe have to advise more to cm3 users, and in general *m3 (dec-src,pm3,ezm3,and cm3 too) users that () user level thread implementation which is part of m3core is not working at this moment, so until community can make a functioning a new implementation, we will use only PTHREAD implementation on most new Linux distributions. Of course this solves the problems you are noticing, so my advise in order to this do not happen any more is write a note on the Download Area and maybe also in (like a note in the Known issues), www.modula3.org (If you allow me, I can do it) The most common case I know a (not very recent) of distribution that works with user level implementation that I use is Ubuntu Dapper 6.06, the libray is 2.3.6 http://packages.ubuntu.com/dapper/libdevel/libc6-dev The next version of Ubuntu breaks when the Juno package is compiling (pkl-fonts program executes), the library libc6 is http://packages.ubuntu.com/edgy/libdevel/libc6-dev. So for 5.4 sources use use the next CM3 variable export CM3="/usr/local/cm3/bin/cm3 -DPTHREAD" This enable the system level thread implementation in a earlier version of it (of cvs), but in the first step bootstrap compiler you will ran in same problems (in Edgy I got breack when running pkl-fonts, but after that break you can re-compile it all well with no problems, after you have build the new m3core). If you can update the sources with the most recent (in a personal opinion, stable version) would be better, but here I would like to know if the script upgrade.sh can do that work, i have not use it. For me the most easy way for me was use the instruction given by Tony for the cvs version, from I take his words and make a relatively simple instructions. Thanks --- Mika Nystrom wrote: > Hello Modula-3 people, > > I am trying to build things with CM3 on a relatively > recent Ubuntu > system (don't ask me why...) and I am running into a > segfault that > I haven't seen mentioned before. I have a feeling > it has something > to do with stack formats, but I'm not sure what to > do next. > > I downloaded the cm3-5.4.0 binaries and started with > that. The > compiler in the binary distribution runs, but it > appears to produce > garbage. I first tried bootstrapping but it crashes > the moment it > tries to execute something it has compiled itself. > So then I tried > hello, world, with the same results... > > Here's the system identification: > > mika at edwards:~/test/src$ uname -a > Linux edwards 2.6.20-16-386 #2 Sun Sep 23 19:47:10 > UTC 2007 i686 GNU/Linux > > I made a "hello, world" program as follows: > > MODULE Main; > IMPORT IO; > > BEGIN IO.Put("Hello, world!\n") END Main. > > Compiled with cm3 directly from the distributed > cm3-5.4.0 for > LINUXLIBC6 and I get a crash in CsetjmpASM.s (as far > as I can tell). > The last unclobbered stack I seem to be able to get > in m3gdb is > this: > > Breakpoint 5, 0xb75e5fb4 in _setjmp () at > ../src/C/LINUXLIBC6/CsetjmpASM.s:31 > 31 in ../src/C/LINUXLIBC6/CsetjmpASM.s > (m3gdb) where > #0 0xb75e5fb4 in _setjmp () at > ../src/C/LINUXLIBC6/CsetjmpASM.s:31 > #1 0xb75dbd51 in RTThread__Transfer > (from=0xbfe28530, to=0xbfe28530) at > ../src/runtime/LINUXLIBC6/RTThreadC.c:14 > #2 0xb75dbaed in FlushStackCache () at > RTThread.m3:65 > #3 0xb75e27c9 in DetermineContext (oldSP=Invalid > C/C++ type code 35 in symbol table. > ) at ThreadPosix.m3:1101 > #4 0xb75e270d in InitTopContext (c=Invalid C/C++ > type code 30 in symbol table. > ) at ThreadPosix.m3:1076 > #5 0xb75e4325 in Init () at ThreadPosix.m3:1498 > #6 0xb75c9592 in InitRuntime (p_argc=Invalid C/C++ > type code 39 in symbol table. > ) at RTLinker.m3:59 > #7 0x08048861 in main (argc=1, argv=0xbfe28824, > envp=0xbfe2882c) at _m3main.mc:3 > (m3gdb) cont > Continuing. > > Program received signal SIGSEGV, Segmentation fault. > 0xa8dbaede in ?? () > > s.sp was lately 16_b75af6b9, if that means anything > at all. > > Oh yes, one more thing: setting LD_POINTER_GUARD to > 0 before running > the program has no effect on the crash. > > Any suggestions for how one might make progress on > this? > > Mika > ______________________________________________ ?Chef por primera vez? S? un mejor Cocinillas. http://es.answers.yahoo.com/info/welcome From jay.krell at cornell.edu Sun Dec 16 03:14:29 2007 From: jay.krell at cornell.edu (Jay) Date: Sun, 16 Dec 2007 02:14:29 +0000 Subject: [M3devel] Ubuntu problems In-Reply-To: <147313.32986.qm@web27106.mail.ukl.yahoo.com> References: <200712160018.lBG0ITO5026048@camembert.async.caltech.edu> <147313.32986.qm@web27106.mail.ukl.yahoo.com> Message-ID: Maybe time to grab a BSD setjmp/longjmp or getcontext/setcontext, rename by prepending with m3_, and be done with it?? e.g.http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/arch/i386/sys/getcontext.S?rev=1.2&content-type=text/x-cvsweb-markuphttp://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/arch/powerpc/sys/getcontext.S?rev=1.3&content-type=text/x-cvsweb-markup My goodness, none of FreeBSD, OpenBSD, NetBSD have web searchable CVS archives.. better links later.. Regarding upgrade.sh, well, on Windows upgrade.cmd works. :) They are all "just" wrappers around cd'ing and building, but perhaps not trivial. - Jay > Date: Sun, 16 Dec 2007 02:38:03 +0100> From: dabenavidesd at yahoo.es> To: mika at async.caltech.edu; m3devel at elegosoft.com> CC: mika at camembert.async.caltech.edu> Subject: Re: [M3devel] Ubuntu problems> > Hi Mika,> what are you seeing is the problem of libc> setjmp/longjmp issue that we maybe have to advise more> to cm3 users, and in general *m3 (dec-src,pm3,ezm3,and> cm3 too) users that () user level thread> implementation which is part of m3core is not working> at this moment, so until community can make a> functioning a new implementation, we will use only> PTHREAD implementation on most new Linux> distributions.> Of course this solves the problems you are noticing,> so my advise in order to this do not happen any more> is write a note on the Download Area and maybe also in> (like a note in the Known issues), www.modula3.org> (If you allow me, I can do it)> > The most common case I know a (not very recent) of > distribution that works with user level implementation> that I use is Ubuntu Dapper 6.06, the libray is 2.3.6> http://packages.ubuntu.com/dapper/libdevel/libc6-dev> The next version of Ubuntu breaks when the Juno> package is compiling (pkl-fonts program executes), the> library libc6 is> http://packages.ubuntu.com/edgy/libdevel/libc6-dev.> > So for 5.4 sources use use the next CM3 variable> export CM3="/usr/local/cm3/bin/cm3 -DPTHREAD"> > This enable the system level thread implementation in> a earlier version of it (of cvs), but in the first> step bootstrap compiler you will ran in same problems> (in Edgy I got breack when running pkl-fonts, but> after that break you can re-compile it all well with> no problems, after you have build the new m3core).> If you can update the sources with the most recent (in> a personal opinion, stable version) would be better,> but here I would like to know if the script upgrade.sh> can do that work, i have not use it.> For me the most easy way for me was use the> instruction given by Tony for the cvs version, from I> take his words and make a relatively simple> instructions.> > Thanks> > > > > > > --- Mika Nystrom wrote:> > > Hello Modula-3 people,> > > > I am trying to build things with CM3 on a relatively> > recent Ubuntu> > system (don't ask me why...) and I am running into a> > segfault that> > I haven't seen mentioned before. I have a feeling> > it has something> > to do with stack formats, but I'm not sure what to> > do next.> > > > I downloaded the cm3-5.4.0 binaries and started with> > that. The > > compiler in the binary distribution runs, but it> > appears to produce> > garbage. I first tried bootstrapping but it crashes> > the moment it> > tries to execute something it has compiled itself. > > So then I tried> > hello, world, with the same results...> > > > Here's the system identification:> > > > mika at edwards:~/test/src$ uname -a> > Linux edwards 2.6.20-16-386 #2 Sun Sep 23 19:47:10> > UTC 2007 i686 GNU/Linux> > > > I made a "hello, world" program as follows:> > > > MODULE Main;> > IMPORT IO;> > > > BEGIN IO.Put("Hello, world!\n") END Main.> > > > Compiled with cm3 directly from the distributed> > cm3-5.4.0 for > > LINUXLIBC6 and I get a crash in CsetjmpASM.s (as far> > as I can tell).> > The last unclobbered stack I seem to be able to get> > in m3gdb is> > this:> > > > Breakpoint 5, 0xb75e5fb4 in _setjmp () at> > ../src/C/LINUXLIBC6/CsetjmpASM.s:31> > 31 in ../src/C/LINUXLIBC6/CsetjmpASM.s> > (m3gdb) where> > #0 0xb75e5fb4 in _setjmp () at> > ../src/C/LINUXLIBC6/CsetjmpASM.s:31> > #1 0xb75dbd51 in RTThread__Transfer> > (from=0xbfe28530, to=0xbfe28530) at> > ../src/runtime/LINUXLIBC6/RTThreadC.c:14> > #2 0xb75dbaed in FlushStackCache () at> > RTThread.m3:65> > #3 0xb75e27c9 in DetermineContext (oldSP=Invalid> > C/C++ type code 35 in symbol table.> > ) at ThreadPosix.m3:1101> > #4 0xb75e270d in InitTopContext (c=Invalid C/C++> > type code 30 in symbol table.> > ) at ThreadPosix.m3:1076> > #5 0xb75e4325 in Init () at ThreadPosix.m3:1498> > #6 0xb75c9592 in InitRuntime (p_argc=Invalid C/C++> > type code 39 in symbol table.> > ) at RTLinker.m3:59> > #7 0x08048861 in main (argc=1, argv=0xbfe28824,> > envp=0xbfe2882c) at _m3main.mc:3> > (m3gdb) cont> > Continuing.> > > > Program received signal SIGSEGV, Segmentation fault.> > 0xa8dbaede in ?? ()> > > > s.sp was lately 16_b75af6b9, if that means anything> > at all.> > > > Oh yes, one more thing: setting LD_POINTER_GUARD to> > 0 before running> > the program has no effect on the crash.> > > > Any suggestions for how one might make progress on> > this?> > > > Mika> > > > > > > ______________________________________________ > ?Chef por primera vez?> S? un mejor Cocinillas. > http://es.answers.yahoo.com/info/welcome _________________________________________________________________ Don't get caught with egg on your face. Play Chicktionary! http://club.live.com/chicktionary.aspx?icid=chick_wlhmtextlink1_dec -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 16 03:40:19 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 15 Dec 2007 21:40:19 -0500 Subject: [M3devel] Ubuntu problems In-Reply-To: References: <200712160018.lBG0ITO5026048@camembert.async.caltech.edu> <147313.32986.qm@web27106.mail.ukl.yahoo.com> Message-ID: It may be slightly trickier than that, since appropriately sized jmpbuf/ucontext needs to be declared. On Dec 15, 2007, at 9:14 PM, Jay wrote: > Maybe time to grab a BSD setjmp/longjmp or getcontext/setcontext, > rename by prepending with m3_, and be done with it?? > e.g. > http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/arch/i386/sys/ > getcontext.S?rev=1.2&content-type=text/x-cvsweb-markup > http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/arch/powerpc/sys/ > getcontext.S?rev=1.3&content-type=text/x-cvsweb-markup > > My goodness, none of FreeBSD, OpenBSD, NetBSD have web searchable > CVS archives.. > better links later.. > > Regarding upgrade.sh, well, on Windows upgrade.cmd works. :) > They are all "just" wrappers around cd'ing and building, but > perhaps not trivial. > > - Jay > > > > Date: Sun, 16 Dec 2007 02:38:03 +0100 > > From: dabenavidesd at yahoo.es > > To: mika at async.caltech.edu; m3devel at elegosoft.com > > CC: mika at camembert.async.caltech.edu > > Subject: Re: [M3devel] Ubuntu problems > > > > Hi Mika, > > what are you seeing is the problem of libc > > setjmp/longjmp issue that we maybe have to advise more > > to cm3 users, and in general *m3 (dec-src,pm3,ezm3,and > > cm3 too) users that () user level thread > > implementation which is part of m3core is not working > > at this moment, so until community can make a > > functioning a new implementation, we will use only > > PTHREAD implementation on most new Linux > > distributions. > > Of course this solves the problems you are noticing, > > so my advise in order to this do not happen any more > > is write a note on the Download Area and maybe also in > > (like a note in the Known issues), www.modula3.org > > (If you allow me, I can do it) > > > > The most common case I know a (not very recent) of > > distribution that works with user level implementation > > that I use is Ubuntu Dapper 6.06, the libray is 2.3.6 > > http://packages.ubuntu.com/dapper/libdevel/libc6-dev > > The next version of Ubuntu breaks when the Juno > > package is compiling (pkl-fonts program executes), the > > library libc6 is > > http://packages.ubuntu.com/edgy/libdevel/libc6-dev. > > > > So for 5.4 sources use use the next CM3 variable > > export CM3="/usr/local/cm3/bin/cm3 -DPTHREAD" > > > > This enable the system level thread implementation in > > a earlier version of it (of cvs), but in the first > > step bootstrap compiler you will ran in same problems > > (in Edgy I got breack when running pkl-fonts, but > > after that break you can re-compile it all well with > > no problems, after you have build the new m3core). > > If you can update the sources with the most recent (in > > a personal opinion, stable version) would be better, > > but here I would like to know if the script upgrade.sh > > can do that work, i have not use it. > > For me the most easy way for me was use the > > instruction given by Tony for the cvs version, from I > > take his words and make a relatively simple > > instructions. > > > > Thanks > > > > > > > > > > > > > > --- Mika Nystrom wrote: > > > > > Hello Modula-3 people, > > > > > > I am trying to build things with CM3 on a relatively > > > recent Ubuntu > > > system (don't ask me why...) and I am running into a > > > segfault that > > > I haven't seen mentioned before. I have a feeling > > > it has something > > > to do with stack formats, but I'm not sure what to > > > do next. > > > > > > I downloaded the cm3-5.4.0 binaries and started with > > > that. The > > > compiler in the binary distribution runs, but it > > > appears to produce > > > garbage. I first tried bootstrapping but it crashes > > > the moment it > > > tries to execute something it has compiled itself. > > > So then I tried > > > hello, world, with the same results... > > > > > > Here's the system identification: > > > > > > mika at edwards:~/test/src$ uname -a > > > Linux edwards 2.6.20-16-386 #2 Sun Sep 23 19:47:10 > > > UTC 2007 i686 GNU/Linux > > > > > > I made a "hello, world" program as follows: > > > > > > MODULE Main; > > > IMPORT IO; > > > > > > BEGIN IO.Put("Hello, world!\n") END Main. > > > > > > Compiled with cm3 directly from the distributed > > > cm3-5.4.0 for > > > LINUXLIBC6 and I get a crash in CsetjmpASM.s (as far > > > as I can tell). > > > The last unclobbered stack I seem to be able to get > > > in m3gdb is > > > this: > > > > > > Breakpoint 5, 0xb75e5fb4 in _setjmp () at > > > ../src/C/LINUXLIBC6/CsetjmpASM.s:31 > > > 31 in ../src/C/LINUXLIBC6/CsetjmpASM.s > > > (m3gdb) where > > > #0 0xb75e5fb4 in _setjmp () at > > > ../src/C/LINUXLIBC6/CsetjmpASM.s:31 > > > #1 0xb75dbd51 in RTThread__Transfer > > > (from=0xbfe28530, to=0xbfe28530) at > > > ../src/runtime/LINUXLIBC6/RTThreadC.c:14 > > > #2 0xb75dbaed in FlushStackCache () at > > > RTThread.m3:65 > > > #3 0xb75e27c9 in DetermineContext (oldSP=Invalid > > > C/C++ type code 35 in symbol table. > > > ) at ThreadPosix.m3:1101 > > > #4 0xb75e270d in InitTopContext (c=Invalid C/C++ > > > type code 30 in symbol table. > > > ) at ThreadPosix.m3:1076 > > > #5 0xb75e4325 in Init () at ThreadPosix.m3:1498 > > > #6 0xb75c9592 in InitRuntime (p_argc=Invalid C/C++ > > > type code 39 in symbol table. > > > ) at RTLinker.m3:59 > > > #7 0x08048861 in main (argc=1, argv=0xbfe28824, > > > envp=0xbfe2882c) at _m3main.mc:3 > > > (m3gdb) cont > > > Continuing. > > > > > > Program received signal SIGSEGV, Segmentation fault. > > > 0xa8dbaede in ?? () > > > > > > s.sp was lately 16_b75af6b9, if that means anything > > > at all. > > > > > > Oh yes, one more thing: setting LD_POINTER_GUARD to > > > 0 before running > > > the program has no effect on the crash. > > > > > > Any suggestions for how one might make progress on > > > this? > > > > > > Mika > > > > > > > > > > > > > ______________________________________________ > > ?Chef por primera vez? > > S? un mejor Cocinillas. > > http://es.answers.yahoo.com/info/welcome > > > Don't get caught with egg on your face. Play Chicktionary! Check it > out! From jay.krell at cornell.edu Sun Dec 16 06:33:20 2007 From: jay.krell at cornell.edu (Jay) Date: Sun, 16 Dec 2007 05:33:20 +0000 Subject: [M3devel] Ubuntu problems In-Reply-To: References: <200712160018.lBG0ITO5026048@camembert.async.caltech.edu> <147313.32986.qm@web27106.mail.ukl.yahoo.com> Message-ID: http://opengrok.netbsd.org/source/search?q=&defs=setjmphttp://opengrok.netbsd.org/source/search?q=&defs=longjmp oh -- hopefully the existing sizes are correct for this code, else an interface break, not that m3 seems to mind binary compatibility breaks and all or stick version numbers in places, though maybe there are runtime checks for binary compat, at least for higher levels. On Windows, setjmp/longjmp optionally interact "correctly" with exception handling -- running __finally blocks and C++ destructors. I wonder if the same is true for gcc? (At some I'd really like to switch NT386 to not use setjmp/longjmp or TlsGetValue/TlsSetValue for this stuff.. after 64bit integer support...) - Jay > From: hosking at cs.purdue.edu> Date: Sat, 15 Dec 2007 21:40:19 -0500> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com; mika at camembert.async.caltech.edu> Subject: Re: [M3devel] Ubuntu problems> > It may be slightly trickier than that, since appropriately sized > jmpbuf/ucontext needs to be declared.> > On Dec 15, 2007, at 9:14 PM, Jay wrote:> > > Maybe time to grab a BSD setjmp/longjmp or getcontext/setcontext, > > rename by prepending with m3_, and be done with it??> > e.g.> > http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/arch/i386/sys/ > > getcontext.S?rev=1.2&content-type=text/x-cvsweb-markup> > http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/arch/powerpc/sys/ > > getcontext.S?rev=1.3&content-type=text/x-cvsweb-markup> >> > My goodness, none of FreeBSD, OpenBSD, NetBSD have web searchable > > CVS archives..> > better links later..> >> > Regarding upgrade.sh, well, on Windows upgrade.cmd works. :)> > They are all "just" wrappers around cd'ing and building, but > > perhaps not trivial.> >> > - Jay> >> >> > > Date: Sun, 16 Dec 2007 02:38:03 +0100> > > From: dabenavidesd at yahoo.es> > > To: mika at async.caltech.edu; m3devel at elegosoft.com> > > CC: mika at camembert.async.caltech.edu> > > Subject: Re: [M3devel] Ubuntu problems> > >> > > Hi Mika,> > > what are you seeing is the problem of libc> > > setjmp/longjmp issue that we maybe have to advise more> > > to cm3 users, and in general *m3 (dec-src,pm3,ezm3,and> > > cm3 too) users that () user level thread> > > implementation which is part of m3core is not working> > > at this moment, so until community can make a> > > functioning a new implementation, we will use only> > > PTHREAD implementation on most new Linux> > > distributions.> > > Of course this solves the problems you are noticing,> > > so my advise in order to this do not happen any more> > > is write a note on the Download Area and maybe also in> > > (like a note in the Known issues), www.modula3.org> > > (If you allow me, I can do it)> > >> > > The most common case I know a (not very recent) of> > > distribution that works with user level implementation> > > that I use is Ubuntu Dapper 6.06, the libray is 2.3.6> > > http://packages.ubuntu.com/dapper/libdevel/libc6-dev> > > The next version of Ubuntu breaks when the Juno> > > package is compiling (pkl-fonts program executes), the> > > library libc6 is> > > http://packages.ubuntu.com/edgy/libdevel/libc6-dev.> > >> > > So for 5.4 sources use use the next CM3 variable> > > export CM3="/usr/local/cm3/bin/cm3 -DPTHREAD"> > >> > > This enable the system level thread implementation in> > > a earlier version of it (of cvs), but in the first> > > step bootstrap compiler you will ran in same problems> > > (in Edgy I got breack when running pkl-fonts, but> > > after that break you can re-compile it all well with> > > no problems, after you have build the new m3core).> > > If you can update the sources with the most recent (in> > > a personal opinion, stable version) would be better,> > > but here I would like to know if the script upgrade.sh> > > can do that work, i have not use it.> > > For me the most easy way for me was use the> > > instruction given by Tony for the cvs version, from I> > > take his words and make a relatively simple> > > instructions.> > >> > > Thanks> > >> > >> > >> > >> > >> > >> > > --- Mika Nystrom wrote:> > >> > > > Hello Modula-3 people,> > > >> > > > I am trying to build things with CM3 on a relatively> > > > recent Ubuntu> > > > system (don't ask me why...) and I am running into a> > > > segfault that> > > > I haven't seen mentioned before. I have a feeling> > > > it has something> > > > to do with stack formats, but I'm not sure what to> > > > do next.> > > >> > > > I downloaded the cm3-5.4.0 binaries and started with> > > > that. The> > > > compiler in the binary distribution runs, but it> > > > appears to produce> > > > garbage. I first tried bootstrapping but it crashes> > > > the moment it> > > > tries to execute something it has compiled itself.> > > > So then I tried> > > > hello, world, with the same results...> > > >> > > > Here's the system identification:> > > >> > > > mika at edwards:~/test/src$ uname -a> > > > Linux edwards 2.6.20-16-386 #2 Sun Sep 23 19:47:10> > > > UTC 2007 i686 GNU/Linux> > > >> > > > I made a "hello, world" program as follows:> > > >> > > > MODULE Main;> > > > IMPORT IO;> > > >> > > > BEGIN IO.Put("Hello, world!\n") END Main.> > > >> > > > Compiled with cm3 directly from the distributed> > > > cm3-5.4.0 for> > > > LINUXLIBC6 and I get a crash in CsetjmpASM.s (as far> > > > as I can tell).> > > > The last unclobbered stack I seem to be able to get> > > > in m3gdb is> > > > this:> > > >> > > > Breakpoint 5, 0xb75e5fb4 in _setjmp () at> > > > ../src/C/LINUXLIBC6/CsetjmpASM.s:31> > > > 31 in ../src/C/LINUXLIBC6/CsetjmpASM.s> > > > (m3gdb) where> > > > #0 0xb75e5fb4 in _setjmp () at> > > > ../src/C/LINUXLIBC6/CsetjmpASM.s:31> > > > #1 0xb75dbd51 in RTThread__Transfer> > > > (from=0xbfe28530, to=0xbfe28530) at> > > > ../src/runtime/LINUXLIBC6/RTThreadC.c:14> > > > #2 0xb75dbaed in FlushStackCache () at> > > > RTThread.m3:65> > > > #3 0xb75e27c9 in DetermineContext (oldSP=Invalid> > > > C/C++ type code 35 in symbol table.> > > > ) at ThreadPosix.m3:1101> > > > #4 0xb75e270d in InitTopContext (c=Invalid C/C++> > > > type code 30 in symbol table.> > > > ) at ThreadPosix.m3:1076> > > > #5 0xb75e4325 in Init () at ThreadPosix.m3:1498> > > > #6 0xb75c9592 in InitRuntime (p_argc=Invalid C/C++> > > > type code 39 in symbol table.> > > > ) at RTLinker.m3:59> > > > #7 0x08048861 in main (argc=1, argv=0xbfe28824,> > > > envp=0xbfe2882c) at _m3main.mc:3> > > > (m3gdb) cont> > > > Continuing.> > > >> > > > Program received signal SIGSEGV, Segmentation fault.> > > > 0xa8dbaede in ?? ()> > > >> > > > s.sp was lately 16_b75af6b9, if that means anything> > > > at all.> > > >> > > > Oh yes, one more thing: setting LD_POINTER_GUARD to> > > > 0 before running> > > > the program has no effect on the crash.> > > >> > > > Any suggestions for how one might make progress on> > > > this?> > > >> > > > Mika> > > >> > >> > >> > >> > >> > > ______________________________________________> > > ?Chef por primera vez?> > > S? un mejor Cocinillas.> > > http://es.answers.yahoo.com/info/welcome> >> >> > Don't get caught with egg on your face. Play Chicktionary! Check it > > out!> _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sun Dec 16 07:56:33 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 15 Dec 2007 22:56:33 -0800 Subject: [M3devel] Ubuntu problems In-Reply-To: Your message of "Sat, 15 Dec 2007 17:35:54 PST." <200712160135.lBG1ZsZ2028488@camembert.async.caltech.edu> Message-ID: <200712160656.lBG6uXRg038351@camembert.async.caltech.edu> All right, thanks for your suggestions. I seem to have made a working compiler. Even mentor works on this Ubuntu 2.6.20. My main observation is that M3/Linux is crying out for a new bootstrap compiler binary. Neither the one from Tony's site nor the 5.4.0 cm3 is actually able to compile the CVS head. The problems come from Long.m3 (instance of GenWord.mg) and Int64.i3. I was able to work around these issues by putting in some garbage in these files and bootstrapping twice---the second time with the proper code in Long.m3 and Int64.i3. It's not that the bootstrapping compiler doesn't know about long (at least one of them does), it just crashes. But no harm done, it all seems to work after fiddling with it. Another issue---and I feel stupid for asking, it seems so basic---is that Linux is really stingy with static archives (.a files), and my cm3.cfg was asking for -lXaw, which didn't work, even though there was a libXaw.so.6 present. I changed the cfg to link explicitly with /usr/lib/libXaw.so.6, but that can't be the right way to do it?? Oh the 5.4.0 cm3.cfg also wraps the "utimes" call. I took this out, as no one was supplying wrap_utimes. I take it this is safe... (a GC-related modification?) Mika Mika Nystrom writes: >Sorry, I have now read the mailing list archives a bit better. > >I am going to try bootstrapping the latest CVS with Tony's cm3 binary, >to use pthreads... > > Mika > > >Mika Nystrom writes: >>Hello Modula-3 people, >> >>I am trying to build things with CM3 on a relatively recent Ubuntu >>system (don't ask me why...) and I am running into a segfault that >>I haven't seen mentioned before. I have a feeling it has something >>to do with stack formats, but I'm not sure what to do next. >> >>I downloaded the cm3-5.4.0 binaries and started with that. The >>compiler in the binary distribution runs, but it appears to produce >>garbage. I first tried bootstrapping but it crashes the moment it >>tries to execute something it has compiled itself. So then I tried >>hello, world, with the same results... >> >>Here's the system identification: >> >>mika at edwards:~/test/src$ uname -a >>Linux edwards 2.6.20-16-386 #2 Sun Sep 23 19:47:10 UTC 2007 i686 GNU/Linux >> >>I made a "hello, world" program as follows: >> >>MODULE Main; >>IMPORT IO; >> >>BEGIN IO.Put("Hello, world!\n") END Main. >> >>Compiled with cm3 directly from the distributed cm3-5.4.0 for >>LINUXLIBC6 and I get a crash in CsetjmpASM.s (as far as I can tell). >>The last unclobbered stack I seem to be able to get in m3gdb is >>this: >> >>Breakpoint 5, 0xb75e5fb4 in _setjmp () at ../src/C/LINUXLIBC6/CsetjmpASM.s:31 >>31 in ../src/C/LINUXLIBC6/CsetjmpASM.s >>(m3gdb) where >>#0 0xb75e5fb4 in _setjmp () at ../src/C/LINUXLIBC6/CsetjmpASM.s:31 >>#1 0xb75dbd51 in RTThread__Transfer (from=0xbfe28530, to=0xbfe28530) at ../s >r >>c/runtime/LINUXLIBC6/RTThreadC.c:14 >>#2 0xb75dbaed in FlushStackCache () at RTThread.m3:65 >>#3 0xb75e27c9 in DetermineContext (oldSP=Invalid C/C++ type code 35 in symbo >l >> table. >>) at ThreadPosix.m3:1101 >>#4 0xb75e270d in InitTopContext (c=Invalid C/C++ type code 30 in symbol tabl >e >>. >>) at ThreadPosix.m3:1076 >>#5 0xb75e4325 in Init () at ThreadPosix.m3:1498 >>#6 0xb75c9592 in InitRuntime (p_argc=Invalid C/C++ type code 39 in symbol ta >b >>le. >>) at RTLinker.m3:59 >>#7 0x08048861 in main (argc=1, argv=0xbfe28824, envp=0xbfe2882c) at _m3main. >m >>c:3 >>(m3gdb) cont >>Continuing. >> >>Program received signal SIGSEGV, Segmentation fault. >>0xa8dbaede in ?? () >> >>s.sp was lately 16_b75af6b9, if that means anything at all. >> >>Oh yes, one more thing: setting LD_POINTER_GUARD to 0 before running >>the program has no effect on the crash. >> >>Any suggestions for how one might make progress on this? >> >> Mika From wagner at elegosoft.com Sun Dec 16 17:31:03 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 16 Dec 2007 17:31:03 +0100 Subject: [M3devel] Spanish speaking CM3 users? In-Reply-To: <47646653.4070106@purdue.edu> References: <20071215235051.rhq0fgeabk4k48gk@mail.elegosoft.com> <47646653.4070106@purdue.edu> Message-ID: <20071216173103.3864tbyzs4so4s8c@mail.elegosoft.com> Quoting "Neil T. Dantam" : > Olaf, > I can at least translate the Spanish for you. Thanks for the translation. > Angela, > ?Tratar los instrucciones de este mensaje? (Did you try the instructions > in this email?) > > https://mail.elegosoft.com/pipermail/m3devel/2007-June/000227.html > > Describen como compilar el compilador. (They describe how to bootstrap > the compiler.) Angela, I have subscribed you to this list and hope that you undestand this. The failure you see is probably due to fundamental changes in the compiler since the last release (addition of 64 bit integers and changes in the garbage collector and threads runtime) which makes a more complex upgrade necessary. Current boot/installation archives for all platforms are overdue; I'm currently trying to build the one for FreeBSD on my home computer. I think we could get something more up-to-date and easier to install for Linux, Solaris, and Darwin within the next week(s). Please stay tuned, Olaf PS: If you send bug reports to the list, you should always add the exact system and environment you are using (uname -a, which archives did you use, what were the exact commands you issed that led to the failure). > Olaf Wagner wrote: >> ----- Forwarded message from anietog at unal.edu.co ----- >> Date: Sat, 15 Dec 2007 17:55:45 +0100 (CET) >> From: Angela >> Reply-To: Angela >> Subject: Anfrage Mailformular >> To: info at elego.de >> >> NAME: Angela >> EMAIL: anietog at unal.edu.co >> ADDRESS: >> Hola, escribo porque tengo un problema al tratar de compilar el >> compilador de fase 1, esto es lo que me aparece: > > Hello, I'm writing because I have a problem regarding compiling phase > one of the compiler. This is what I see: > >> .... >> new source -> compiling Text.i3 >> new source -> compiling RTProcedureSRC.i3 >> new source -> compiling Fingerprint.i3 >> new source -> compiling RTProcedure.i3 >> new source -> compiling RTStack.i3 >> new source -> compiling RTAllocStats.m3 >> "../src/runtime/common/RTAllocStats.m3", line 46: undefined runtime >> symbol !! (RTHooks.AllocateTracedRef) >> >> >> *** >> *** runtime error: >> *** Segmentation violation - possible attempt to dereference NIL >> *** pc = 0x80c5c3c = StartCall + 0x18 in ../src/values/Procedure.m3 >> *** >> >> Aborted (core dumped) >> *** execution of failed *** >> >> >> Agradezco cualquier colaboraci?n ya que aun no he podido culminar mi >> instalacion de cm3. > > I would appreciate any help, because I could not finish my > installation of cm3. > >> >> ----- End forwarded message ----- > > > -- > Neil T. Dantam > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sun Dec 16 17:35:40 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 16 Dec 2007 11:35:40 -0500 Subject: [M3devel] Ubuntu problems In-Reply-To: References: <200712160018.lBG0ITO5026048@camembert.async.caltech.edu> <147313.32986.qm@web27106.mail.ukl.yahoo.com> Message-ID: <324F7DBA-ECF9-4382-A1F1-FA5D4B380247@cs.purdue.edu> There are two places where setjmp/longjmp are used: user-level threading and exception handling. On Windows, they are only used for exception handling since we rely on system threads. On Solaris and Alpha/OSF they are not used for exception handling since those targets have stack unwinding support. Converting user-level threading to use setcontext/getcontext should be relatively straightforward, based on the model already implemented for Solaris which I converted to setcontext/getcontext many years ago. On Dec 16, 2007, at 12:33 AM, Jay wrote: > http://opengrok.netbsd.org/source/search?q=&defs=setjmp > http://opengrok.netbsd.org/source/search?q=&defs=longjmp > > oh -- hopefully the existing sizes are correct for this code, else > an interface break, not that m3 seems to mind binary compatibility > breaks and all or stick version numbers in places, though maybe > there are runtime checks for binary compat, at least for higher > levels. > > On Windows, setjmp/longjmp optionally interact "correctly" with > exception handling -- running __finally blocks and C++ destructors. > I wonder if the same is true for gcc? > (At some I'd really like to switch NT386 to not use setjmp/longjmp > or TlsGetValue/TlsSetValue for this stuff.. after 64bit integer > support...) > > - Jay > > > > From: hosking at cs.purdue.edu > > Date: Sat, 15 Dec 2007 21:40:19 -0500 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com; mika at camembert.async.caltech.edu > > Subject: Re: [M3devel] Ubuntu problems > > > > It may be slightly trickier than that, since appropriately sized > > jmpbuf/ucontext needs to be declared. > > > > On Dec 15, 2007, at 9:14 PM, Jay wrote: > > > > > Maybe time to grab a BSD setjmp/longjmp or getcontext/setcontext, > > > rename by prepending with m3_, and be done with it?? > > > e.g. > > > http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/arch/i386/sys/ > > > getcontext.S?rev=1.2&content-type=text/x-cvsweb-markup > > > http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/arch/powerpc/sys/ > > > getcontext.S?rev=1.3&content-type=text/x-cvsweb-markup > > > > > > My goodness, none of FreeBSD, OpenBSD, NetBSD have web searchable > > > CVS archives.. > > > better links later.. > > > > > > Regarding upgrade.sh, well, on Windows upgrade.cmd works. :) > > > They are all "just" wrappers around cd'ing and building, but > > > perhaps not trivial. > > > > > > - Jay > > > > > > > > > > Date: Sun, 16 Dec 2007 02:38:03 +0100 > > > > From: dabenavidesd at yahoo.es > > > > To: mika at async.caltech.edu; m3devel at elegosoft.com > > > > CC: mika at camembert.async.caltech.edu > > > > Subject: Re: [M3devel] Ubuntu problems > > > > > > > > Hi Mika, > > > > what are you seeing is the problem of libc > > > > setjmp/longjmp issue that we maybe have to advise more > > > > to cm3 users, and in general *m3 (dec-src,pm3,ezm3,and > > > > cm3 too) users that () user level thread > > > > implementation which is part of m3core is not working > > > > at this moment, so until community can make a > > > > functioning a new implementation, we will use only > > > > PTHREAD implementation on most new Linux > > > > distributions. > > > > Of course this solves the problems you are noticing, > > > > so my advise in order to this do not happen any more > > > > is write a note on the Download Area and maybe also in > > > > (like a note in the Known issues), www.modula3.org > > > > (If you allow me, I can do it) > > > > > > > > The most common case I know a (not very recent) of > > > > distribution that works with user level implementation > > > > that I use is Ubuntu Dapper 6.06, the libray is 2.3.6 > > > > http://packages.ubuntu.com/dapper/libdevel/libc6-dev > > > > The next version of Ubuntu breaks when the Juno > > > > package is compiling (pkl-fonts program executes), the > > > > library libc6 is > > > > http://packages.ubuntu.com/edgy/libdevel/libc6-dev. > > > > > > > > So for 5.4 sources use use the next CM3 variable > > > > export CM3="/usr/local/cm3/bin/cm3 -DPTHREAD" > > > > > > > > This enable the system level thread implementation in > > > > a earlier version of it (of cvs), but in the first > > > > step bootstrap compiler you will ran in same problems > > > > (in Edgy I got breack when running pkl-fonts, but > > > > after that break you can re-compile it all well with > > > > no problems, after you have build the new m3core). > > > > If you can update the sources with the most recent (in > > > > a personal opinion, stable version) would be better, > > > > but here I would like to know if the script upgrade.sh > > > > can do that work, i have not use it. > > > > For me the most easy way for me was use the > > > > instruction given by Tony for the cvs version, from I > > > > take his words and make a relatively simple > > > > instructions. > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > > --- Mika Nystrom wrote: > > > > > > > > > Hello Modula-3 people, > > > > > > > > > > I am trying to build things with CM3 on a relatively > > > > > recent Ubuntu > > > > > system (don't ask me why...) and I am running into a > > > > > segfault that > > > > > I haven't seen mentioned before. I have a feeling > > > > > it has something > > > > > to do with stack formats, but I'm not sure what to > > > > > do next. > > > > > > > > > > I downloaded the cm3-5.4.0 binaries and started with > > > > > that. The > > > > > compiler in the binary distribution runs, but it > > > > > appears to produce > > > > > garbage. I first tried bootstrapping but it crashes > > > > > the moment it > > > > > tries to execute something it has compiled itself. > > > > > So then I tried > > > > > hello, world, with the same results... > > > > > > > > > > Here's the system identification: > > > > > > > > > > mika at edwards:~/test/src$ uname -a > > > > > Linux edwards 2.6.20-16-386 #2 Sun Sep 23 19:47:10 > > > > > UTC 2007 i686 GNU/Linux > > > > > > > > > > I made a "hello, world" program as follows: > > > > > > > > > > MODULE Main; > > > > > IMPORT IO; > > > > > > > > > > BEGIN IO.Put("Hello, world!\n") END Main. > > > > > > > > > > Compiled with cm3 directly from the distributed > > > > > cm3-5.4.0 for > > > > > LINUXLIBC6 and I get a crash in CsetjmpASM.s (as far > > > > > as I can tell). > > > > > The last unclobbered stack I seem to be able to get > > > > > in m3gdb is > > > > > this: > > > > > > > > > > Breakpoint 5, 0xb75e5fb4 in _setjmp () at > > > > > ../src/C/LINUXLIBC6/CsetjmpASM.s:31 > > > > > 31 in ../src/C/LINUXLIBC6/CsetjmpASM.s > > > > > (m3gdb) where > > > > > #0 0xb75e5fb4 in _setjmp () at > > > > > ../src/C/LINUXLIBC6/CsetjmpASM.s:31 > > > > > #1 0xb75dbd51 in RTThread__Transfer > > > > > (from=0xbfe28530, to=0xbfe28530) at > > > > > ../src/runtime/LINUXLIBC6/RTThreadC.c:14 > > > > > #2 0xb75dbaed in FlushStackCache () at > > > > > RTThread.m3:65 > > > > > #3 0xb75e27c9 in DetermineContext (oldSP=Invalid > > > > > C/C++ type code 35 in symbol table. > > > > > ) at ThreadPosix.m3:1101 > > > > > #4 0xb75e270d in InitTopContext (c=Invalid C/C++ > > > > > type code 30 in symbol table. > > > > > ) at ThreadPosix.m3:1076 > > > > > #5 0xb75e4325 in Init () at ThreadPosix.m3:1498 > > > > > #6 0xb75c9592 in InitRuntime (p_argc=Invalid C/C++ > > > > > type code 39 in symbol table. > > > > > ) at RTLinker.m3:59 > > > > > #7 0x08048861 in main (argc=1, argv=0xbfe28824, > > > > > envp=0xbfe2882c) at _m3main.mc:3 > > > > > (m3gdb) cont > > > > > Continuing. > > > > > > > > > > Program received signal SIGSEGV, Segmentation fault. > > > > > 0xa8dbaede in ?? () > > > > > > > > > > s.sp was lately 16_b75af6b9, if that means anything > > > > > at all. > > > > > > > > > > Oh yes, one more thing: setting LD_POINTER_GUARD to > > > > > 0 before running > > > > > the program has no effect on the crash. > > > > > > > > > > Any suggestions for how one might make progress on > > > > > this? > > > > > > > > > > Mika > > > > > > > > > > > > > > > > > > > > > > > > > ______________________________________________ > > > > ?Chef por primera vez? > > > > S? un mejor Cocinillas. > > > > http://es.answers.yahoo.com/info/welcome > > > > > > > > > Don't get caught with egg on your face. Play Chicktionary! > Check it > > > out! > > > > > Share life as it happens with the new Windows Live. Share now! From hosking at cs.purdue.edu Sun Dec 16 17:37:35 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 16 Dec 2007 11:37:35 -0500 Subject: [M3devel] Ubuntu problems In-Reply-To: <200712160656.lBG6uXRg038351@camembert.async.caltech.edu> References: <200712160656.lBG6uXRg038351@camembert.async.caltech.edu> Message-ID: On Dec 16, 2007, at 1:56 AM, Mika Nystrom wrote: > > All right, thanks for your suggestions. I seem to have made a > working compiler. Even mentor works on this Ubuntu 2.6.20. > > My main observation is that M3/Linux is crying out for a new bootstrap > compiler binary. Neither the one from Tony's site nor the 5.4.0 > cm3 is actually able to compile the CVS head. The problems come > from Long.m3 (instance of GenWord.mg) and Int64.i3. I was able to > work around these issues by putting in some garbage in these files > and bootstrapping twice---the second time with the proper code in > Long.m3 and Int64.i3. It's not that the bootstrapping compiler > doesn't > know about long (at least one of them does), it just crashes. But > no harm done, it all seems to work after fiddling with it. I need to update my ftp site with a version of the Linux bootstrap compiler that will work for the LONGINT support. > Another issue---and I feel stupid for asking, it seems so basic---is > that Linux is really stingy with static archives (.a files), and > my cm3.cfg was asking for -lXaw, which didn't work, even though > there was a libXaw.so.6 present. I changed the cfg to link explicitly > with /usr/lib/libXaw.so.6, but that can't be the right way to do it?? > Oh the 5.4.0 cm3.cfg also wraps the "utimes" call. I took this out, > as no one was supplying wrap_utimes. I take it this is safe... (a > GC-related modification?) You are working off of a very old cm3.cfg -- try the one from my ftp site. > > Mika > > Mika Nystrom writes: >> Sorry, I have now read the mailing list archives a bit better. >> >> I am going to try bootstrapping the latest CVS with Tony's cm3 >> binary, >> to use pthreads... >> >> Mika >> >> >> Mika Nystrom writes: >>> Hello Modula-3 people, >>> >>> I am trying to build things with CM3 on a relatively recent Ubuntu >>> system (don't ask me why...) and I am running into a segfault that >>> I haven't seen mentioned before. I have a feeling it has something >>> to do with stack formats, but I'm not sure what to do next. >>> >>> I downloaded the cm3-5.4.0 binaries and started with that. The >>> compiler in the binary distribution runs, but it appears to produce >>> garbage. I first tried bootstrapping but it crashes the moment it >>> tries to execute something it has compiled itself. So then I tried >>> hello, world, with the same results... >>> >>> Here's the system identification: >>> >>> mika at edwards:~/test/src$ uname -a >>> Linux edwards 2.6.20-16-386 #2 Sun Sep 23 19:47:10 UTC 2007 i686 >>> GNU/Linux >>> >>> I made a "hello, world" program as follows: >>> >>> MODULE Main; >>> IMPORT IO; >>> >>> BEGIN IO.Put("Hello, world!\n") END Main. >>> >>> Compiled with cm3 directly from the distributed cm3-5.4.0 for >>> LINUXLIBC6 and I get a crash in CsetjmpASM.s (as far as I can tell). >>> The last unclobbered stack I seem to be able to get in m3gdb is >>> this: >>> >>> Breakpoint 5, 0xb75e5fb4 in _setjmp () at ../src/C/LINUXLIBC6/ >>> CsetjmpASM.s:31 >>> 31 in ../src/C/LINUXLIBC6/CsetjmpASM.s >>> (m3gdb) where >>> #0 0xb75e5fb4 in _setjmp () at ../src/C/LINUXLIBC6/CsetjmpASM.s:31 >>> #1 0xb75dbd51 in RTThread__Transfer (from=0xbfe28530, >>> to=0xbfe28530) at ../s >> r >>> c/runtime/LINUXLIBC6/RTThreadC.c:14 >>> #2 0xb75dbaed in FlushStackCache () at RTThread.m3:65 >>> #3 0xb75e27c9 in DetermineContext (oldSP=Invalid C/C++ type code >>> 35 in symbo >> l >>> table. >>> ) at ThreadPosix.m3:1101 >>> #4 0xb75e270d in InitTopContext (c=Invalid C/C++ type code 30 in >>> symbol tabl >> e >>> . >>> ) at ThreadPosix.m3:1076 >>> #5 0xb75e4325 in Init () at ThreadPosix.m3:1498 >>> #6 0xb75c9592 in InitRuntime (p_argc=Invalid C/C++ type code 39 >>> in symbol ta >> b >>> le. >>> ) at RTLinker.m3:59 >>> #7 0x08048861 in main (argc=1, argv=0xbfe28824, envp=0xbfe2882c) >>> at _m3main. >> m >>> c:3 >>> (m3gdb) cont >>> Continuing. >>> >>> Program received signal SIGSEGV, Segmentation fault. >>> 0xa8dbaede in ?? () >>> >>> s.sp was lately 16_b75af6b9, if that means anything at all. >>> >>> Oh yes, one more thing: setting LD_POINTER_GUARD to 0 before running >>> the program has no effect on the crash. >>> >>> Any suggestions for how one might make progress on this? >>> >>> Mika From wagner at elegosoft.com Sun Dec 16 18:10:59 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 16 Dec 2007 18:10:59 +0100 Subject: [M3devel] Info about Jay Krell? Fwd: Uncaught bounce notification Message-ID: <20071216181059.8vpo9jtzijo8k0g8@mail.elegosoft.com> Hi, I wouldn't normally forward this to the list, but since Jay has been such an eager contributor to cm3 on windows: does anybody know why all his mail bounces and how he can be reached? Thanks, Olaf Date: Sun, 16 Dec 2007 11:31:15 -0500 (EST) Subject: Problems delivering your mail From: MAILER-DAEMON at cornell.edu To: m3devel-bounces at elegosoft.com 2.1 unnamed [text/plain] 5.58 KB Download I'm sorry, but we had problems delivering your mail. The errors we encountered appear below. If you have any questions, contact the Cornell Postmaster as . Please include a copy of this message with your correspondence. -------- The following addresses could not be found at all in our Directory. Please make sure you have the correct address. jay.krell at cornell.edu -------- -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Dec 16 22:23:01 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 16 Dec 2007 22:23:01 +0100 Subject: [M3devel] m3cg build failure on powerpc/darwin Message-ID: <20071216212301.GA25212@elegosoft.com> Hi, while trying to build some boot archives build on my PowerBook G4, uname -a Darwin apple.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power Macintosh powerpc the compilation died with /Users/wagner/work/cm3/m3-sys/m3cc/PPC_DARWIN/./gcc/xgcc -B/Users/wagner/work/cm3/m3-sys/m3cc/PPC_DARWIN/./gcc/ -B/usr/local/powerpc-apple-darwin7.9.0/bin/ -B/usr/local/powerpc-apple-darwin7.9.0/lib/ -isystem /usr/local/powerpc-apple-darwin7.9.0/include -isystem /usr/local/powerpc-apple-darwin7.9.0/sys-include -c -DHAVE_CONFIG_H -O2 -O2 -g -I. -I../../../gcc/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../../gcc/libiberty/floatformat.c -o floatformat.o ../../../gcc/libiberty/floatformat.c: In function 'floatformat_to_double': ../../../gcc/libiberty/floatformat.c:354: warning: floating constant exceeds range of 'float' /var/tmp/cccvQbrs.s:508:stfiwx instruction is optional for the PowerPC (not allowed without -force_cpusubtype_ALL option) /var/tmp/cccvQbrs.s:550:stfiwx instruction is optional for the PowerPC (not allowed without -force_cpusubtype_ALL option) make[2]: *** [floatformat.o] Error 1 make[1]: *** [all-target-libiberty] Error 2 make: *** [all] Error 2 "/Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile", line 188: quake runtime error: exit 512: cd .; make CC="gcc" CFLAGS="-O2 -g" --procedure-- -line- -file--- exec -- include_dir 188 /Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile 5 /Users/wagner/work/cm3/m3-sys/m3cc/PPC_DARWIN/m3make.args Fatal Error: package build failed Any ideas? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sun Dec 16 23:02:58 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 16 Dec 2007 23:02:58 +0100 Subject: [M3devel] m3cg build failure on powerpc/darwin In-Reply-To: <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> Message-ID: <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> Quoting Tony Hosking : > That is a very old Darwin distro. Here is my G4: > > Darwin Kernel Version 8.10.0: Wed May 23 16:50:59 PDT 2007; > root:xnu-792.21.3~1/RELEASE_PPC Seems I'm stuck then. Newer versions of the OS won't run on this PowerBook according to specification. So current versions of CM3 aren't possible anymore, too... It seems that it isn't possible anymore to use a computer that is older than two years to run any medium to large-size current software :-( The upgrade script for Linux just died with === package m3-sys/cm3 === +++ cm3 -build -DROOT='/home/wagner/work/cm3' && cm3 -ship -DROOT='/home/wagner/work/cm3' +++ --- building in LINUXLIBC6 --- ignoring ../src/m3overrides -> linking cm3 /usr/local/cm3/pkg/libm3/LINUXLIBC6/libm3.a(FSPosix.mo): In function `FS__SetModificationTime': /home/wagner/work/cm3/m3-libs/libm3/LINUXLIBC6/FSPosix.m3:348: undefined reference to `__wrap_utimes' collect2: ld returned 1 exit status Fatal Error: package build failed on birch.elegosoft.com. So the only thing I've succeeded in today is building a bootstrap for FreeBSD 6.3. Olaf > On Dec 16, 2007, at 4:23 PM, Olaf Wagner wrote: > >> Hi, >> >> while trying to build some boot archives build on my PowerBook >> G4, uname -a >> >> Darwin apple.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 >> 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power >> Macintosh powerpc >> >> the compilation died with >> >> /Users/wagner/work/cm3/m3-sys/m3cc/PPC_DARWIN/./gcc/xgcc >> -B/Users/wagner/work/cm3/m3-sys/m3cc/PPC_DARWIN/./gcc/ >> -B/usr/local/powerpc-apple-darwin7.9.0/bin/ >> -B/usr/local/powerpc-apple-darwin7.9.0/lib/ -isystem >> /usr/local/powerpc-apple-darwin7.9.0/include -isystem >> /usr/local/powerpc-apple-darwin7.9.0/sys-include -c -DHAVE_CONFIG_H >> -O2 -O2 -g -I. -I../../../gcc/libiberty/../include -W -Wall >> -pedantic -Wwrite-strings -Wstrict-prototypes >> ../../../gcc/libiberty/floatformat.c -o floatformat.o >> ../../../gcc/libiberty/floatformat.c: In function 'floatformat_to_double': >> ../../../gcc/libiberty/floatformat.c:354: warning: floating >> constant exceeds range of 'float' >> /var/tmp/cccvQbrs.s:508:stfiwx instruction is optional for the >> PowerPC (not allowed without -force_cpusubtype_ALL option) >> /var/tmp/cccvQbrs.s:550:stfiwx instruction is optional for the >> PowerPC (not allowed without -force_cpusubtype_ALL option) >> make[2]: *** [floatformat.o] Error 1 >> make[1]: *** [all-target-libiberty] Error 2 >> make: *** [all] Error 2 >> "/Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile", line 188: >> quake runtime error: exit 512: cd .; make CC="gcc" CFLAGS="-O2 -g" >> >> --procedure-- -line- -file--- >> exec -- >> include_dir 188 /Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile >> 5 >> /Users/wagner/work/cm3/m3-sys/m3cc/PPC_DARWIN/m3make.args >> >> Fatal Error: package build failed >> >> 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 mika at async.caltech.edu Sun Dec 16 23:14:35 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 16 Dec 2007 14:14:35 -0800 Subject: [M3devel] m3cg build failure on powerpc/darwin In-Reply-To: Your message of "Sun, 16 Dec 2007 23:02:58 +0100." <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> Message-ID: <200712162214.lBGMEagW066782@camembert.async.caltech.edu> Olaf Wagner writes: ... >The upgrade script for Linux just died with > >=== package m3-sys/cm3 === > +++ cm3 -build -DROOT='/home/wagner/work/cm3' && cm3 -ship >-DROOT='/home/wagner/work/cm3' +++ >--- building in LINUXLIBC6 --- > >ignoring ../src/m3overrides > > -> linking cm3 >/usr/local/cm3/pkg/libm3/LINUXLIBC6/libm3.a(FSPosix.mo): In function >`FS__SetModificationTime': >/home/wagner/work/cm3/m3-libs/libm3/LINUXLIBC6/FSPosix.m3:348: >undefined reference to `__wrap_utimes' >collect2: ld returned 1 exit status >Fatal Error: package build failed > >on birch.elegosoft.com. This is the same problem I had on Ubuntu yesterday. You need to remove -wrap,utimes from your cm3.cfg, or use Tony's newer cm3.cfg. > >So the only thing I've succeeded in today is building a bootstrap >for FreeBSD 6.3. Ironically, FreeBSD is extremely good at backward-compatibility of binaries! I think I may still have a FreeBSD 3.x system somewhere with Modula-3 on it... This is just for historical reasons, but we still do use 4.11 systems in production, so it would be nice if there were bootstraps on 4.11. (4.11-generated compilers work fine w/o modification on 5.x.) Mika > >Olaf > >> On Dec 16, 2007, at 4:23 PM, Olaf Wagner wrote: >> >>> Hi, >>> >>> while trying to build some boot archives build on my PowerBook >>> G4, uname -a >>> >>> Darwin apple.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 >>> 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power >>> Macintosh powerpc >>> >>> the compilation died with >>> >>> /Users/wagner/work/cm3/m3-sys/m3cc/PPC_DARWIN/./gcc/xgcc >>> -B/Users/wagner/work/cm3/m3-sys/m3cc/PPC_DARWIN/./gcc/ >>> -B/usr/local/powerpc-apple-darwin7.9.0/bin/ >>> -B/usr/local/powerpc-apple-darwin7.9.0/lib/ -isystem >>> /usr/local/powerpc-apple-darwin7.9.0/include -isystem >>> /usr/local/powerpc-apple-darwin7.9.0/sys-include -c -DHAVE_CONFIG_H >>> -O2 -O2 -g -I. -I../../../gcc/libiberty/../include -W -Wall >>> -pedantic -Wwrite-strings -Wstrict-prototypes >>> ../../../gcc/libiberty/floatformat.c -o floatformat.o >>> ../../../gcc/libiberty/floatformat.c: In function 'floatformat_to_double': >>> ../../../gcc/libiberty/floatformat.c:354: warning: floating >>> constant exceeds range of 'float' >>> /var/tmp/cccvQbrs.s:508:stfiwx instruction is optional for the >>> PowerPC (not allowed without -force_cpusubtype_ALL option) >>> /var/tmp/cccvQbrs.s:550:stfiwx instruction is optional for the >>> PowerPC (not allowed without -force_cpusubtype_ALL option) >>> make[2]: *** [floatformat.o] Error 1 >>> make[1]: *** [all-target-libiberty] Error 2 >>> make: *** [all] Error 2 >>> "/Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile", line 188: >>> quake runtime error: exit 512: cd .; make CC="gcc" CFLAGS="-O2 -g" >>> >>> --procedure-- -line- -file--- >>> exec -- >>> include_dir 188 /Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile >>> 5 >>> /Users/wagner/work/cm3/m3-sys/m3cc/PPC_DARWIN/m3make.args >>> >>> Fatal Error: package build failed >>> >>> 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 mika at async.caltech.edu Sun Dec 16 23:25:43 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 16 Dec 2007 14:25:43 -0800 Subject: [M3devel] m3cg build failure on powerpc/darwin In-Reply-To: Your message of "Sun, 16 Dec 2007 14:14:35 PST." <200712162214.lBGMEagW066782@camembert.async.caltech.edu> Message-ID: <200712162225.lBGMPhm5067188@camembert.async.caltech.edu> Mika Nystrom writes: ... >we still do use 4.11 systems in production, so it would be nice if >there were bootstraps on 4.11. (4.11-generated compilers work fine >w/o modification on 5.x.) I should add, in case it's not clearly understood from the above, that I'd be more than happy to help generating such a bootstrap if it's going to be a release version! From wagner at elegosoft.com Sun Dec 16 23:32:59 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 16 Dec 2007 23:32:59 +0100 Subject: [M3devel] m3cg build failure on powerpc/darwin In-Reply-To: <28256359-D312-4D47-9A38-7A245D6AEAE5@cs.purdue.edu> References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> <28256359-D312-4D47-9A38-7A245D6AEAE5@cs.purdue.edu> Message-ID: <20071216233259.ukim9ntk6cw8gsgc@mail.elegosoft.com> Quoting Tony Hosking : >> Seems I'm stuck then. Newer versions of the OS won't run on this >> PowerBook according to specification. So current versions of CM3 >> aren't possible anymore, too... >> >> It seems that it isn't possible anymore to use a computer that is >> older than two years to run any medium to large-size current >> software :-( > > I can build a bootstrap for PPC_DARWIN if you like. That would be great (and may be the fastest solution). >> The upgrade script for Linux just died with [...] > Looks like you have an old cm3.cfg with the wrapper link commands in > it. Delete those and you should be good. Found that, removed it and redid everything from start after several spurious errors (Mika mentioned it, too). Now I get this: ... /home/wagner/work/cm3/scripts/install-cm3-compiler.sh upgrade cp_if: /usr/local/cm3/bin/cm3 and /usr/local/cm3/bin/cm3-d5.5.0 identical cp_if: /usr/local/cm3/bin/cm3cg and /usr/local/cm3/bin/cm3cg-d5.5.0 identical /home/wagner/work/cm3/scripts/install-cm3-compiler.sh: line 109: /home/wagner/work/cm3/m3-sys/cm3/LINUXLIBC6/cm3: No such file or directory cp /home/wagner/work/cm3/m3-sys/cm3/LINUXLIBC6/cm3 /usr/local/cm3/bin/cm3- cp_if: /home/wagner/work/cm3/m3-sys/m3cc/LINUXLIBC6/cm3cg and /usr/local/cm3/bin/cm3cg- identical cp /usr/local/cm3/bin/cm3- /usr/local/cm3/bin/cm3 cp /usr/local/cm3/bin/cm3cg- /usr/local/cm3/bin/cm3cg /home/wagner/work/cm3/scripts/do-cm3-core.sh buildship CM3C = /home/wagner/work/cm3/scripts/pkgmap.sh -c "cm3 -build -DROOT='/home/wagner/work/cm3' && cm3 -ship -DROOT='/home/wagner/work/cm3' " m3core libm3 patternmatching m3middle m3linker m3front m3quake m3cc cm3 m3scanner m3tools m3cgcat m3cggen m3bundle bitvector digraph parseparams realgeometry set slisp sortedtableextras table-list tempfiles === package m3-libs/m3core === +++ cm3 -build -DROOT='/home/wagner/work/cm3' && cm3 -ship -DROOT='/home/wagner/work/cm3' +++ /bin/sh: /usr/local/cm3/bin/cm3: No such file or directory *** execution of failed *** birch [~/work/cm3] wagner % ls -l /home/wagner/work/cm3/m3-sys/cm3/LINUXLIBC6/cm3 -rwxr-xr-x 1 wagner 5906103 2007-12-16 23:26 /home/wagner/work/cm3/m3-sys/cm3/LINUXLIBC6/cm3* % ldd /home/wagner/work/cm3/m3-sys/cm3/LINUXLIBC6/cm3 /usr/bin/ldd: line 117: /home/wagner/work/cm3/m3-sys/cm3/LINUXLIBC6/cm3: No such file or directory ??? Looks like I need a break 8-/ Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Mon Dec 17 06:24:19 2007 From: jayk123 at hotmail.com (Jay) Date: Mon, 17 Dec 2007 05:24:19 +0000 Subject: [M3devel] Info about Jay Krell? Fwd: Uncaught bounce notification In-Reply-To: <20071216181059.8vpo9jtzijo8k0g8@mail.elegosoft.com> References: <20071216181059.8vpo9jtzijo8k0g8@mail.elegosoft.com> Message-ID: I know what the problem and I will fix shortly, maybe as early as Monday. The details won't interest anyone.. For now..jayk123 at hotmail.com. (not sure why they don't bounce 100%, but problems as of 12/15 were expected and I didn't act to prevent them..a policy changed after 15+ years...) - Jay > Date: Sun, 16 Dec 2007 18:10:59 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] Info about Jay Krell? Fwd: Uncaught bounce notification> > Hi,> > I wouldn't normally forward this to the list, but since Jay has been> such an eager contributor to cm3 on windows: does anybody know why> all his mail bounces and how he can be reached?> > Thanks,> > Olaf> > > Date: Sun, 16 Dec 2007 11:31:15 -0500 (EST)> Subject: Problems delivering your mail> From: MAILER-DAEMON at cornell.edu> To: m3devel-bounces at elegosoft.com> 2.1 unnamed [text/plain] 5.58 KB Download> I'm sorry, but we had problems delivering your mail.> The errors we encountered appear below. If you have any questions,> contact the Cornell Postmaster as .> Please include a copy of this message with your correspondence.> > --------> > The following addresses could not be found at all in our Directory.> Please make sure you have the correct address.> > jay.krell at cornell.edu> > --------> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ i?m is proud to present Cause Effect, a series about real people making a difference. http://im.live.com/Messenger/IM/MTV/?source=text_Cause_Effect -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Dec 17 12:03:31 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 17 Dec 2007 12:03:31 +0100 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/darwin In-Reply-To: <723A4C34-1B58-4F26-891C-45F764CAEEB5@cs.purdue.edu> References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> <28256359-D312-4D47-9A38-7A245D6AEAE5@cs.purdue.edu> <20071216233259.ukim9ntk6cw8gsgc@mail.elegosoft.com> <723A4C34-1B58-4F26-891C-45F764CAEEB5@cs.purdue.edu> Message-ID: <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> Quoting Tony Hosking : > A break is always good. :-) Hi again, after some hours of sleep I can report at least some success on my old Darwin installation. I've put the archives on our web server for public access, and would like to add some more. I still think a Darwin build on a newer system may be a good idea (we can offer both on our web pages), and we definitely need some for Linux (perhaps multiple distros, too, there?) Solaris and Darwin/i386 would be great, too, and NetBSD, and of course Windows. Mika offered to provide an archive for old FreeBSD distributions (4.x). So everybody who is willing to produce some installation archives, please let me know, and I'll make sure they get shipped to our server. Please note that for the scripts/make-bin-dist-min.sh to work, you need a sample configuration file in cm3/m3-sys/cm3/src/config/XXX, as the ones in cminstall/src/config must be processed by the installer first. Jay has removed the samples there a little bit too eagerly, but most where outdated anyway. To upgrade from an older compiler I have successfully used the upgrade.sh script. So the complete sequence to build a bootstrap on your favourite platform would be: 1. Check out the current CVS head 2. Copy your (working) configuration file to cm3/src/config/ 3. Adapt the installer configuration file if necessary in cminstall/src/config/. Make sure that all system libraries get dynamically linked, for instance. 4. scripts/upgrade.sh 5. scripts/make-bin-dist-min.sh Any help will be appreciated. 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 jayk123 at hotmail.com Tue Dec 18 08:56:24 2007 From: jayk123 at hotmail.com (Jay) Date: Tue, 18 Dec 2007 07:56:24 +0000 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc In-Reply-To: <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> <28256359-D312-4D47-9A38-7A245D6AEAE5@cs.purdue.edu> <20071216233259.ukim9ntk6cw8gsgc@mail.elegosoft.com> <723A4C34-1B58-4F26-891C-45F764CAEEB5@cs.purdue.edu> <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> Message-ID: Blech, so much duplication.. oops/sorry.I'll make a new Windows archive and put it in my user directory on m3.elegosoft.com. 64 bit integer support will have to wait. I assume we are in a "release push" here? I COULD if really necessary do about any x86 Linux (maybe x86 Solaris, don't think it is supported) or PowerPC Linux or PowerPC Darwin..in a virtual machine if nothing else.. > for Linux (perhaps multiple distros, too, there?) Oh for just a bit of compatibility... :) > 1. Check out the current CVS head> 2. Copy your (working) configuration file to cm3/src/config/> 3. Adapt the installer configuration file if necessary in> cminstall/src/config/. Make sure that all system libraries> get dynamically linked, for instance.> 4. scripts/upgrade.sh> 5. scripts/make-bin-dist-min.sh Hey! :) 1. Checkout current CVS head. 2. cminstall/src/config/NT386 should work for everyone. 3. ditto 4. scripts/win/upgrade.cmd 5. scripts/win/make-dist.cmd. I'm just being obnoxious. :) Oh btw, anyone want to make an executive decision on a minor detail? .zip or .tar.gz or .tar.bz2 or self expanding .zip in an .exe? make-dist.cmd is setup to make any of these. I don't know how to make a self expanding .tar.gz or .tar.bz2...though should be easy, perhaps not with the following feature: The .exes can either be run, or can be used as direct input to unzip, or renamed to .zip and probably opened with Windows Explorer. It's pretty neat. .tar.bz2 is always the smallest in my experience and that's what I left make-dist.cmd doing. .tar.gz is usually in the middle. .zip usually largest, though more efficient for extracting less than the whole archive -- the files are compressed individually instead of compressing the entire stream at once. Self expanding .zip adds a small fixed constant prefix. I wonder if cminstall can be "better" on Unix, comparable to it being gone on Windows, but I don't care. You know, either make it unnecessary or make it totally automatic. I know it tries to figure out the defaults. I don't know how correct it tends to be. Oh and then a really obvious obnoxious question is if we should be building .debs, .rpms, Mac .pkg/.img/.dmg etc.. Personally I don't mind the lowest tech current approach. Slackware anyone? :) (I used it in the Linux kernel 1.x time, which is when most of my Linux use ever was..) - Jay > Date: Mon, 17 Dec 2007 12:03:31 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> CC: m3-support at elegosoft.com; admins at elegosoft.com> Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/darwin> > Quoting Tony Hosking :> > A break is always good. :-)> > Hi again,> > after some hours of sleep I can report at least some success on> my old Darwin installation. I've put the archives on our web server> for public access, and would like to add some more.> > I still think a Darwin build on a newer system may be a good idea (we> can offer both on our web pages), and we definitely need some> for Linux (perhaps multiple distros, too, there?)> Solaris and Darwin/i386 would be great, too, and NetBSD, and of> course Windows. Mika offered to provide an archive for old FreeBSD> distributions (4.x).> > So everybody who is willing to produce some installation archives,> please let me know, and I'll make sure they get shipped to our> server.> > Please note that for the scripts/make-bin-dist-min.sh to work,> you need a sample configuration file in cm3/m3-sys/cm3/src/config/XXX,> as the ones in cminstall/src/config must be processed by the installer> first. Jay has removed the samples there a little bit too eagerly,> but most where outdated anyway.> > To upgrade from an older compiler I have successfully used the> upgrade.sh script. So the complete sequence to build a bootstrap> on your favourite platform would be:> > 1. Check out the current CVS head> 2. Copy your (working) configuration file to cm3/src/config/> 3. Adapt the installer configuration file if necessary in> cminstall/src/config/. Make sure that all system libraries> get dynamically linked, for instance.> 4. scripts/upgrade.sh> 5. scripts/make-bin-dist-min.sh> > Any help will be appreciated.> > 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> _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Dec 18 09:01:19 2007 From: jayk123 at hotmail.com (Jay) Date: Tue, 18 Dec 2007 08:01:19 +0000 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc In-Reply-To: <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> <28256359-D312-4D47-9A38-7A245D6AEAE5@cs.purdue.edu> <20071216233259.ukim9ntk6cw8gsgc@mail.elegosoft.com> <723A4C34-1B58-4F26-891C-45F764CAEEB5@cs.purdue.edu> <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> Message-ID: Strange that seemed to have gotten truncated.. I wonder if cminstall can be "better" on Unix, comparable to it being gone on Windows, but I don't care.You know, either make it unnecessary or make it totally automatic. I know it tries to figure out the defaults. I don't know how correct it tends to be. Oh and then a really obvious obnoxious question is if we should be building .debs, .rpms, Mac .pkg/.img/.dmg etc..Personally I don't mind the lowest tech current approach. Slackware anyone? :) (I used it in the Linux kernel 1.x time, which is when most of my Linux use ever was..) - Jay From: jayk123 at hotmail.com _________________________________________________________________ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_122007 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Dec 18 10:00:03 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 18 Dec 2007 10:00:03 +0100 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc In-Reply-To: References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> <28256359-D312-4D47-9A38-7A245D6AEAE5@cs.purdue.edu> <20071216233259.ukim9ntk6cw8gsgc@mail.elegosoft.com> <723A4C34-1B58-4F26-891C-45F764CAEEB5@cs.purdue.edu> <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> Message-ID: <20071218100003.12irq679c4o404go@mail.elegosoft.com> Quoting Jay : > 64 bit integer support will have to wait. As long as the binary does compile the current code base, it will be OK, I think. > I assume we are in a "release push" here? No, this is not really a release, I just had the impression that some current snapshots were required. > I COULD if really necessary do about any x86 Linux (maybe x86 > Solaris, don't think it is supported) or PowerPC Linux or PowerPC > Darwin..in a virtual machine if nothing else.. I think PowerPC Linux would be great, if you find the time. I don't know of many people who could build that. >> for Linux (perhaps multiple distros, too, there?) > Oh for just a bit of compatibility... :) I've done a build on Debian now. > Oh btw, anyone want to make an executive decision on a minor detail? > .zip or .tar.gz or .tar.bz2 or self expanding .zip in an .exe? > make-dist.cmd is setup to make any of these. > I don't know how to make a self expanding .tar.gz or > .tar.bz2...though should be easy, perhaps not with the following > feature: > The .exes can either be run, or can be used as direct input to > unzip, or renamed to .zip and probably opened with Windows Explorer. > It's pretty neat. > .tar.bz2 is always the smallest in my experience and that's what > I left make-dist.cmd doing. > .tar.gz is usually in the middle. > .zip usually largest, though more efficient for extracting less > than the whole archive -- the files are compressed individually > instead of compressing the entire stream at once. > Self expanding .zip adds a small fixed constant prefix. I'm fine with any of these. Since Windows does seem to use other approaches and conventions in most aspects anyway, we should just go with what is easiest for beginners. What would you suggest? Self-extracting .exe? > I wonder if cminstall can be "better" on Unix, comparable to it > being gone on Windows, but I don't care. No, it's not really better on Unix, but it's better than nothing for many, and it takes efforts to change or improve it (including all documentation), which nobody seems interested to invest. > You know, either make it unnecessary or make it totally automatic. I > know it tries to figure out the defaults. I don't know how correct > it tends to be. Making such things completely automatic on many different target platform always ends in unmanageable efforts for small teams in my experience. CM3 has no resources for this I'm afraid. > Oh and then a really obvious obnoxious question is if we should be > building .debs, .rpms, Mac .pkg/.img/.dmg etc.. This again is the question who wants to maintain all that stuff. IMO it's OK if we have special support contributed for this or that target, but nobody ever showed real interest in maintaining such support through several release cycles. > Personally I don't mind the lowest tech current approach. Slackware > anyone? :) (I used it in the Linux kernel 1.x time, which is when > most of my Linux use ever was..) I tend to agree that low-tech in the installation area may be appropriate for CM3 ;-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Tue Dec 18 10:21:24 2007 From: jayk123 at hotmail.com (Jay) Date: Tue, 18 Dec 2007 09:21:24 +0000 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc In-Reply-To: <20071218100003.12irq679c4o404go@mail.elegosoft.com> References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> <28256359-D312-4D47-9A38-7A245D6AEAE5@cs.purdue.edu> <20071216233259.ukim9ntk6cw8gsgc@mail.elegosoft.com> <723A4C34-1B58-4F26-891C-45F764CAEEB5@cs.purdue.edu> <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> <20071218100003.12irq679c4o404go@mail.elegosoft.com> Message-ID: > > 64 bit integer support will have to wait. > As long as the binary does compile the current code base, it will be OK, > I think. It does. > I think PowerPC Linux would be great, if you find the time. I don't> know of many people who could build that. Ok. Um..gotta wonder what people use here...Mandrake, OpenSuse, YellowDog, Fedora... actually given my opinion of PowerPC and Linux, I bet none. Maybe just AIX. :) (Haven't used it myself.) > > .zip or .tar.gz or .tar.bz2 or self expanding .zip in an .exe?> > I'm fine with any of these. Since Windows does seem to use other> approaches and conventions in most aspects anyway, we should just> go with what is easiest for beginners. What would you suggest?> Self-extracting .exe? Ah. Good point, know the audience. Well, I think a non self expanding .zip might be "best". The self expanding .exes I have made are console apps. The user must be comfortable with the command line (IDE integration anyone? :)) The .zip can be expanded with the builtin support or with unzip. .zip has that small advantage of "built in" support in the gui. > Making such things completely automatic on many different target platform Sounds like a job for Autoconf, eh? Actually I have experimented with Autoconf-ish sorts of stuff on Windows. If you know the local scripting language and even if that language is like 10% of what it should be, not difficult. (That is, cmd kind of stinks, but it is good enough; and on Windows the right answer is probably VBScript or JScript. They are on pretty much every machine now and are very usable from the command line, not just the browser. Soon "PowerShell"..) Thing is, I don't know Bourne shell scripting. I guess these days you could use Perl. It's everywhere and I know it well enough. Of course you still need to know how to answer the questions in an automated fashion. REALLY I have to say, I've been using Perl so much the past few years, I'm kind of torn on static compilation to native code anyway. You know, this stuff could be in Modula-3 or Quake, but Perl suffices plenty...and then you start to realize that it suffices for a heck of a lot of stuff.. I did start some autoconfish-for-Windows stuff in Quake too. :) See..there's this metapoint, metaquestion that I've been obsessing over for years...some languages really do try to be the only language you need for any task -- Java, C, C++, C#, Modula-3 -- are good examples. And then when you find them too heavyweight and start using "scripts", you start to wonder, and when those "scripts" perf and scale just fine, you start to wonder.. Many "scripting" languages are obviously no good, but some seem perhaps good enough. An example of "bad" is Tcl with its ridiculous string-centricity, how braces might LOOK like a scoping mechanism a la C and C++, but they are really a hacky escaping mechanism... cmd is also too string-centric among other things (cmd is much better than people realize, but also seriously flawed). But Perl and probably Ruby and Python really seem to be on to something in terms of "general purpose" programming languages without a "build" step. Heck, I believe Red Hat/Fedora setup is written in Python.. and there's a book out there on linkers and loaders and .obj/.exe formats where the guy developers a linker in Perl. I think that says something..something positive. - Jay _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Dec 18 12:14:23 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 18 Dec 2007 12:14:23 +0100 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc In-Reply-To: References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> <28256359-D312-4D47-9A38-7A245D6AEAE5@cs.purdue.edu> <20071216233259.ukim9ntk6cw8gsgc@mail.elegosoft.com> <723A4C34-1B58-4F26-891C-45F764CAEEB5@cs.purdue.edu> <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> <20071218100003.12irq679c4o404go@mail.elegosoft.com> Message-ID: <20071218121423.6xkl81jou88g8kc4@mail.elegosoft.com> Quoting Jay : >> > .zip or .tar.gz or .tar.bz2 or self expanding .zip in an .exe?> > >> I'm fine with any of these. Since Windows does seem to use other> >> approaches and conventions in most aspects anyway, we should just> >> go with what is easiest for beginners. What would you suggest?> >> Self-extracting .exe? > Ah. Good point, know the audience. > Well, I think a non self expanding .zip might be "best". > The self expanding .exes I have made are console apps. > The user must be comfortable with the command line (IDE integration > anyone? :)) > The .zip can be expanded with the builtin support or with unzip. > .zip has that small advantage of "built in" support in the gui. > > Making such things completely automatic on many different target platform OK, let it be zip then. > Sounds like a job for Autoconf, eh? > Actually I have experimented with Autoconf-ish sorts of stuff on Windows. > If you know the local scripting language and even if that language > is like 10% of what it should be, not difficult. > (That is, cmd kind of stinks, but it is good enough; and on Windows > the right answer is probably VBScript or JScript. They are on pretty > much every machine now and are very usable from the command line, > not just the browser. Soon "PowerShell"..) > Thing is, I don't know Bourne shell scripting. > I guess these days you could use Perl. It's everywhere and I know it > well enough. > Of course you still need to know how to answer the questions in an > automated fashion. Autoconf needs to be adapted to changes in the platforms, too. I'm not against it, it's just becoming a maintenance problem soon. > REALLY I have to say, I've been using Perl so much the past few > years, I'm kind of torn on static compilation to native code anyway. > You know, this stuff could be in Modula-3 or Quake, but Perl > suffices plenty...and then you start to realize that it suffices for > a heck of a lot of stuff.. > I did start some autoconfish-for-Windows stuff in Quake too. :) I would not want to become Perl or anything else to become another prerequisite for CM3 installation. > See..there's this metapoint, metaquestion that I've been obsessing > over for years...some languages really do try to be the only > language you need for any task -- Java, C, C++, C#, Modula-3 -- are > good examples. And then when you find them too heavyweight and start > using "scripts", you start to wonder, and when those "scripts" perf > and scale just fine, you start to wonder.. Many "scripting" > languages are obviously no good, but some seem perhaps good enough. > An example of "bad" is Tcl with its ridiculous string-centricity, > how braces might LOOK like a scoping mechanism a la C and C++, but > they are really a hacky escaping mechanism... cmd is also too > string-centric among other things (cmd is much better than people > realize, but also seriously flawed). But Perl and probably Ruby and > Python really seem to be on to something in terms of "general > purpose" programming languages without a "build" step. Heck, I > believe Red Hat/Fedora setup is written in Python.. and there's a > book out there on linkers and loaders and .obj/.exe formats where > the guy developers a linker in Perl. I think that says > something..something positive. In my opinion there's no language that suits every need. Modula-3 is great for programming large systems and building reusable abstraction. Perl tends to become difficult to read (Write Once Read Never :). Python is really good for a scripting language (we use it a lot at Elego), but should not be needed as prerequisite for CM3 either. Bourne Shell is POSIX and should exist everywhere (with the exception of Windows, which never had a really working POSIX subsystem, but you can easily install Cygwin there via a GUI). Standard POSIX (or Windows) command line tools would be the level of prerequisites I'd accept. Everything else should be discussed here and well considered before introduced. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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.caltech.edu Tue Dec 18 13:38:21 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 18 Dec 2007 04:38:21 -0800 Subject: [M3devel] Unix signals and Modula-3... Message-ID: <200712181238.lBICcL8s052879@camembert.async.caltech.edu> Hello everyone, I am in the process of bootstrapping the CVS head of CM3 on an old FreeBSD-4.11 system, and at one point, when I replaced the old cm3 with the new cm3, the compiler got slower. Not a little bit slower, mind you, but about 10x slower. I remember pointing this out to the m3devel list... oh it must have been three or four years ago; one of our grad students at Caltech (Karl Papadantonakis, also author of the caltech-parser) was the first to notice what was going on. It has to do with Process.Wait. (From ProcessPosix.m3.) To repeat what I said a few years ago, the problem lies here: CONST Delay = 0.1D0; BEGIN IF NOT p.waitOk THEN RAISE WaitAlreadyCalled END; p.waitOk := FALSE; (* By rights, the SchedulerPosix interface should have a WaitPID procedure that is integrated with the thread scheduler. *) LOOP result := Uexec.waitpid(p.pid, ADR(statusT), Uexec.WNOHANG); IF result # 0 THEN EXIT END; Thread.Pause(Delay) END; <* ASSERT result > 0 *> In other words: if Process.Wait is called before the child process is done, then the thread pauses 0.1 seconds. In our local version of m3build, we duplicate the Wait code and set the Delay to 0.0. That's OK in a compiler, but it's not OK in general, because you would chew up the CPU on a machine that was doing a lot of long-term waiting. The problem is that the fix that I suggested way back when requires messing with Unix signals (catching SIGC[H]LD instead of using waitpid), which is why I never submitted a fix to the repository, because I am not sure what such a fix might interact with. It seems to me that the correct way of dealing with Unix signals is to have a single thread that talks to the Unix system, registers signal handlers, and takes care, via some object-oriented mechanism, of calling back any M3 threads that are interested in the signals. Would such a thing be possible? Where are signals used in the system today? Mika From mika at async.caltech.edu Tue Dec 18 13:55:15 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 18 Dec 2007 04:55:15 -0800 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/darwin In-Reply-To: Your message of "Mon, 17 Dec 2007 12:03:31 +0100." <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> Message-ID: <200712181255.lBICtFbG053659@camembert.async.caltech.edu> Hi Olaf, I'm sorry to say there is a bit of a problem with your bootstrap for FreeBSD. FreeBSD is beautifully *backward*-compatible, but it's not *forward*-compatible (it may be within a major release, but it's not generally forward-compatible across major releases). The distribution you built on 6.3-PRERELEASE will work for sure on 6.x (x>=3), may work on 6.x (x<3), and will almost certainly not work on y.x (y<6). To remedy this I built a bootstrap on 4.11. It is located at http://www.async.caltech.edu/~mika/cm3-min-POSIX-FreeBSD4-d5.5.0.tgz This compiler should work on pretty much any FreeBSD 4.x, 5.x, and possibly also 6.x. I have to say that it was a bit of an ordeal. I had problems from an old cm3.cfg (mine just never seems to get upgraded right), with -g instead of -gstabs+. I also had two sets of problems stemming from LONGINT: first, of course, my old compiler didn't know what LONGINT was so I searched through my email and indeed I found something from Tony referring to building a bootstrap on NT386 from which I could infer what to do: one has to check out a "mixed" repository mixing the "devel_LONGINT_start" tagged sources with the CVS head. The problems with Int64.i3 and Long.m3 that I think we've seen on other platforms reared their ugly heads here too (although these may have been due to my -g issues, i.e., not having an up-to-date back-end?) In short, in order to build a bootstrap from a pre-LONGINT compiler at the moment, you have to be an expert at this, pretty much, you have to remember approximately where in the mailing list archive the answers are, and I would say it's a good chance that 100% of the scripts that purport to be able to do things like bootstrap cm3, well, they don't work at all. I don't even want to think about bootstrapping CM3 with PM3 or SRC M3...(I think there are systems for which some of those are all that's available?) Mika P.S. I checked in a little bugfix (C++ism removal) for m3gdb as part of this. Olaf Wagner writes: >Quoting Tony Hosking : >> A break is always good. :-) > >Hi again, > >after some hours of sleep I can report at least some success on >my old Darwin installation. I've put the archives on our web server >for public access, and would like to add some more. > >I still think a Darwin build on a newer system may be a good idea (we >can offer both on our web pages), and we definitely need some >for Linux (perhaps multiple distros, too, there?) >Solaris and Darwin/i386 would be great, too, and NetBSD, and of >course Windows. Mika offered to provide an archive for old FreeBSD >distributions (4.x). > >So everybody who is willing to produce some installation archives, >please let me know, and I'll make sure they get shipped to our >server. > >Please note that for the scripts/make-bin-dist-min.sh to work, >you need a sample configuration file in cm3/m3-sys/cm3/src/config/XXX, >as the ones in cminstall/src/config must be processed by the installer >first. Jay has removed the samples there a little bit too eagerly, >but most where outdated anyway. > >To upgrade from an older compiler I have successfully used the >upgrade.sh script. So the complete sequence to build a bootstrap >on your favourite platform would be: > > 1. Check out the current CVS head > 2. Copy your (working) configuration file to cm3/src/config/ > 3. Adapt the installer configuration file if necessary in > cminstall/src/config/. Make sure that all system libraries > get dynamically linked, for instance. 4. scripts/upgrade.sh > 5. scripts/make-bin-dist-min.sh > >Any help will be appreciated. > >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 wagner at elegosoft.com Tue Dec 18 14:52:15 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 18 Dec 2007 14:52:15 +0100 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/darwin In-Reply-To: <200712181255.lBICtFbG053659@camembert.async.caltech.edu> References: <200712181255.lBICtFbG053659@camembert.async.caltech.edu> Message-ID: <20071218145215.a9btkok1wkokg04s@mail.elegosoft.com> Quoting Mika Nystrom : > > Hi Olaf, > > I'm sorry to say there is a bit of a problem with your bootstrap for > FreeBSD. FreeBSD is beautifully *backward*-compatible, but it's not > *forward*-compatible (it may be within a major release, but it's not > generally forward-compatible across major releases). The distribution > you built on 6.3-PRERELEASE will work for sure on 6.x (x>=3), may work > on 6.x (x<3), and will almost certainly not work on y.x (y<6). To > remedy this I built a bootstrap on 4.11. It is located at > > http://www.async.caltech.edu/~mika/cm3-min-POSIX-FreeBSD4-d5.5.0.tgz > > This compiler should work on pretty much any FreeBSD 4.x, 5.x, and > possibly also 6.x. I was afraid that there is no forward compatibility. So it's great that we've got a 4.11 build, I'll add it to our site this evening. I don't think anybody will still use any older versions. > I have to say that it was a bit of an ordeal. I had problems from > an old cm3.cfg (mine just never seems to get upgraded right), with > -g instead of -gstabs+. I also had two sets of problems stemming > from LONGINT: first, of course, my old compiler didn't know what > LONGINT was so I searched through my email and indeed I found > something from Tony referring to building a bootstrap on NT386 from > which I could infer what to do: one has to check out a "mixed" > repository mixing the "devel_LONGINT_start" tagged sources with the > CVS head. The problems with Int64.i3 and Long.m3 that I think we've > seen on other platforms reared their ugly heads here too (although > these may have been due to my -g issues, i.e., not having an > up-to-date back-end?) > > In short, in order to build a bootstrap from a pre-LONGINT compiler > at the moment, you have to be an expert at this, pretty much, you > have to remember approximately where in the mailing list archive > the answers are, and I would say it's a good chance that 100% of > the scripts that purport to be able to do things like bootstrap > cm3, well, they don't work at all. I don't even want to think about > bootstrapping CM3 with PM3 or SRC M3...(I think there are systems > for which some of those are all that's available?) I thought that the upgrade.sh script would take care of the pre-LONGINT / LONGINT transition, at least it worked for me on FreeBSD. At least if you start with a 5.4 release CM3. Outdated config files are of course always nasty; FreeBSD itself has complex support in form of the mergemaster utilty for its own upgrades for these problems. I'm afraid we'll not easily reach this level in CM3. The bootstrap scripts for CM3 with PM3 or even SRC M3 are from the beginning of the open source CM3 distribution; they did work at some point in time, but have not been used since. Perhaps they should rather be deleted or moved to an old-stuff directory. Sorry for all the inconveniences, but you seem to have coped well ;-) Thank you very much, Olaf > Mika > > P.S. I checked in a little bugfix (C++ism removal) for m3gdb as part > of this. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Dec 18 15:17:03 2007 From: jay.krell at cornell.edu (Jay) Date: Tue, 18 Dec 2007 14:17:03 +0000 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/ In-Reply-To: <20071218145215.a9btkok1wkokg04s@mail.elegosoft.com> References: <200712181255.lBICtFbG053659@camembert.async.caltech.edu> <20071218145215.a9btkok1wkokg04s@mail.elegosoft.com> Message-ID: new Windows builds in ~jkrell on modula3.elegosoft.com from current CVS (ie: a different checkout than where I have edits): % ls -ltotal 4480-rw------- 1 jkrell jkrell 882018 2007-12-18 15:04 cm3-min-WIN32-NT386-d5.5.0-symbols.zip-rw------- 1 jkrell jkrell 3679897 2007-12-18 15:05 cm3-min-WIN32-NT386-d5.5.0.zip Windows /might/ have it easy with LONGINT, however Windows still has it tricky, and maybe not easy, maybe the same trickiness. In particular, what you do is: get an existing binary release That gives you cm3 and a pkg repository with m3core and libm3. buildship ONLY cm3 and upgrade-compiler, since ship of cm3 doesn't actually do anything perhaps, at least on Windows where the file is in use And then, after having built a new compiler, go and build everything else with it. "Normally" you might build things from the bottom of a dependency graph and on up -- m3core, libm3, cm3. However in this case you must stick with the old m3core and libm3 and only build cm3. The current m3core/libm3 cannot be built with an old compiler, but an old compiler can build a new compiler. upgrade.cmd automates this and I suspect upgrade.sh does as well. I'll be able to do Mac OS X 10.4 builds before Linux PowerPC, but should get to Linux PowerPC in a few days. Perl can written in a readable maintainable fashion, really. The bigger "problem" is regular expressions -- with great power/density comes great responsibility.. There is the /x flag to make them able to take comments, but it is badly flawed in that comments confuse the parser. It's a case of regexps being overly woven into the syntax. my $re = RegExp->new("..") sould have sufficed without messing up the syntax. - Jay > Date: Tue, 18 Dec 2007 14:52:15 +0100> From: wagner at elegosoft.com> To: mika at async.caltech.edu> CC: m3devel at elegosoft.com; mika at camembert.async.caltech.edu> Subject: Re: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/darwin> > Quoting Mika Nystrom :> > >> > Hi Olaf,> >> > I'm sorry to say there is a bit of a problem with your bootstrap for> > FreeBSD. FreeBSD is beautifully *backward*-compatible, but it's not> > *forward*-compatible (it may be within a major release, but it's not> > generally forward-compatible across major releases). The distribution> > you built on 6.3-PRERELEASE will work for sure on 6.x (x>=3), may work> > on 6.x (x<3), and will almost certainly not work on y.x (y<6). To> > remedy this I built a bootstrap on 4.11. It is located at> >> > http://www.async.caltech.edu/~mika/cm3-min-POSIX-FreeBSD4-d5.5.0.tgz> >> > This compiler should work on pretty much any FreeBSD 4.x, 5.x, and> > possibly also 6.x.> > I was afraid that there is no forward compatibility. So it's> great that we've got a 4.11 build, I'll add it to our site this evening.> I don't think anybody will still use any older versions.> > > I have to say that it was a bit of an ordeal. I had problems from> > an old cm3.cfg (mine just never seems to get upgraded right), with> > -g instead of -gstabs+. I also had two sets of problems stemming> > from LONGINT: first, of course, my old compiler didn't know what> > LONGINT was so I searched through my email and indeed I found> > something from Tony referring to building a bootstrap on NT386 from> > which I could infer what to do: one has to check out a "mixed"> > repository mixing the "devel_LONGINT_start" tagged sources with the> > CVS head. The problems with Int64.i3 and Long.m3 that I think we've> > seen on other platforms reared their ugly heads here too (although> > these may have been due to my -g issues, i.e., not having an> > up-to-date back-end?)> >> > In short, in order to build a bootstrap from a pre-LONGINT compiler> > at the moment, you have to be an expert at this, pretty much, you> > have to remember approximately where in the mailing list archive> > the answers are, and I would say it's a good chance that 100% of> > the scripts that purport to be able to do things like bootstrap> > cm3, well, they don't work at all. I don't even want to think about> > bootstrapping CM3 with PM3 or SRC M3...(I think there are systems> > for which some of those are all that's available?)> > I thought that the upgrade.sh script would take care of the> pre-LONGINT / LONGINT transition, at least it worked for me> on FreeBSD. At least if you start with a 5.4 release CM3.> > Outdated config files are of course always nasty; FreeBSD itself> has complex support in form of the mergemaster utilty for its> own upgrades for these problems. I'm afraid we'll not easily reach> this level in CM3.> > The bootstrap scripts for CM3 with PM3 or even SRC M3 are from the> beginning of the open source CM3 distribution; they did work at> some point in time, but have not been used since. Perhaps they should> rather be deleted or moved to an old-stuff directory.> > Sorry for all the inconveniences, but you seem to have coped well ;-)> > Thank you very much,> > Olaf> > Mika> >> > P.S. I checked in a little bugfix (C++ism removal) for m3gdb as part> > of this.> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. http://www.xbox.com/en-US/hardware/wheretobuy/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Dec 18 15:20:17 2007 From: jayk123 at hotmail.com (Jay) Date: Tue, 18 Dec 2007 14:20:17 +0000 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/ In-Reply-To: References: <200712181255.lBICtFbG053659@camembert.async.caltech.edu> <20071218145215.a9btkok1wkokg04s@mail.elegosoft.com> Message-ID: ps: speaking of pre-reqs..m3-win/import-libs/m3makefile has a special hack to find my Visual C++ 2.0 toolset. In this way the distribution can support any Visual C++ toolset, probably. However this is not right in terms of letting anyone build a distribution. There remains an open question as to which toolsets to support, er, which Microsoft ones to support. I built this with 8.0. 9.0 has been released now. - Jay From: jay.krell at cornell.eduTo: wagner at elegosoft.com; mika at async.caltech.eduDate: Tue, 18 Dec 2007 14:17:03 +0000CC: m3devel at elegosoft.com; mika at camembert.async.caltech.eduSubject: Re: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/ new Windows builds in ~jkrell on modula3.elegosoft.com from current CVS (ie: a different checkout than where I have edits):% ls -ltotal 4480-rw------- 1 jkrell jkrell 882018 2007-12-18 15:04 cm3-min-WIN32-NT386-d5.5.0-symbols.zip-rw------- 1 jkrell jkrell 3679897 2007-12-18 15:05 cm3-min-WIN32-NT386-d5.5.0.zipWindows /might/ have it easy with LONGINT, however Windows still has it tricky, and maybe not easy, maybe the same trickiness. In particular, what you do is: get an existing binary release That gives you cm3 and a pkg repository with m3core and libm3. buildship ONLY cm3 and upgrade-compiler, since ship of cm3 doesn't actually do anything perhaps, at least on Windows where the file is in use And then, after having built a new compiler, go and build everything else with it. "Normally" you might build things from the bottom of a dependency graph and on up -- m3core, libm3, cm3.However in this case you must stick with the old m3core and libm3 and only build cm3.The current m3core/libm3 cannot be built with an old compiler, but an old compiler can build a new compiler. upgrade.cmd automates this and I suspect upgrade.sh does as well. I'll be able to do Mac OS X 10.4 builds before Linux PowerPC, but should get to Linux PowerPC in a few days. Perl can written in a readable maintainable fashion, really.The bigger "problem" is regular expressions -- with great power/density comes great responsibility..There is the /x flag to make them able to take comments, but it is badly flawed in that commentsconfuse the parser. It's a case of regexps being overly woven into the syntax.my $re = RegExp->new("..") sould have sufficed without messing up the syntax. - Jay > Date: Tue, 18 Dec 2007 14:52:15 +0100> From: wagner at elegosoft.com> To: mika at async.caltech.edu> CC: m3devel at elegosoft.com; mika at camembert.async.caltech.edu> Subject: Re: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/darwin> > Quoting Mika Nystrom :> > >> > Hi Olaf,> >> > I'm sorry to say there is a bit of a problem with your bootstrap for> > FreeBSD. FreeBSD is beautifully *backward*-compatible, but it's not> > *forward*-compatible (it may be within a major release, but it's not> > generally forward-compatible across major releases). The distribution> > you built on 6.3-PRERELEASE will work for sure on 6.x (x>=3), may work> > on 6.x (x<3), and will almost certainly not work on y.x (y<6). To> > remedy this I built a bootstrap on 4.11. It is located at> >> > http://www.async.caltech.edu/~mika/cm3-min-POSIX-FreeBSD4-d5.5.0.tgz> >> > This compiler should work on pretty much any FreeBSD 4.x, 5.x, and> > possibly also 6.x.> > I was afraid that there is no forward compatibility. So it's> great that we've got a 4.11 build, I'll add it to our site this evening.> I don't think anybody will still use any older versions.> > > I have to say that it was a bit of an ordeal. I had problems from> > an old cm3.cfg (mine just never seems to get upgraded right), with> > -g instead of -gstabs+. I also had two sets of problems stemming> > from LONGINT: first, of course, my old compiler didn't know what> > LONGINT was so I searched through my email and indeed I found> > something from Tony referring to building a bootstrap on NT386 from> > which I could infer what to do: one has to check out a "mixed"> > repository mixing the "devel_LONGINT_start" tagged sources with the> > CVS head. The problems with Int64.i3 and Long.m3 that I think we've> > seen on other platforms reared their ugly heads here too (although> > these may have been due to my -g issues, i.e., not having an> > up-to-date back-end?)> >> > In short, in order to build a bootstrap from a pre-LONGINT compiler> > at the moment, you have to be an expert at this, pretty much, you> > have to remember approximately where in the mailing list archive> > the answers are, and I would say it's a good chance that 100% of> > the scripts that purport to be able to do things like bootstrap> > cm3, well, they don't work at all. I don't even want to think about> > bootstrapping CM3 with PM3 or SRC M3...(I think there are systems> > for which some of those are all that's available?)> > I thought that the upgrade.sh script would take care of the> pre-LONGINT / LONGINT transition, at least it worked for me> on FreeBSD. At least if you start with a 5.4 release CM3.> > Outdated config files are of course always nasty; FreeBSD itself> has complex support in form of the mergemaster utilty for its> own upgrades for these problems. I'm afraid we'll not easily reach> this level in CM3.> > The bootstrap scripts for CM3 with PM3 or even SRC M3 are from the> beginning of the open source CM3 distribution; they did work at> some point in time, but have not been used since. Perhaps they should> rather be deleted or moved to an old-stuff directory.> > Sorry for all the inconveniences, but you seem to have coped well ;-)> > Thank you very much,> > Olaf> > Mika> >> > P.S. I checked in a little bugfix (C++ism removal) for m3gdb as part> > of this.> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. Get it now! _________________________________________________________________ The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. http://www.xbox.com/en-US/hardware/wheretobuy/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Dec 18 17:27:03 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 18 Dec 2007 11:27:03 -0500 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/darwin In-Reply-To: <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> <28256359-D312-4D47-9A38-7A245D6AEAE5@cs.purdue.edu> <20071216233259.ukim9ntk6cw8gsgc@mail.elegosoft.com> <723A4C34-1B58-4F26-891C-45F764CAEEB5@cs.purdue.edu> <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> Message-ID: I can provide a 32-bit x86-64(AMD64) build too. It is based on the existing 32-bit LINUXLIBC6, but needs a special cm3.cfg. On Dec 17, 2007, at 6:03 AM, Olaf Wagner wrote: > Quoting Tony Hosking : >> A break is always good. :-) > > Hi again, > > after some hours of sleep I can report at least some success on > my old Darwin installation. I've put the archives on our web server > for public access, and would like to add some more. > > I still think a Darwin build on a newer system may be a good idea (we > can offer both on our web pages), and we definitely need some > for Linux (perhaps multiple distros, too, there?) > Solaris and Darwin/i386 would be great, too, and NetBSD, and of > course Windows. Mika offered to provide an archive for old FreeBSD > distributions (4.x). > > So everybody who is willing to produce some installation archives, > please let me know, and I'll make sure they get shipped to our > server. > > Please note that for the scripts/make-bin-dist-min.sh to work, > you need a sample configuration file in cm3/m3-sys/cm3/src/config/XXX, > as the ones in cminstall/src/config must be processed by the installer > first. Jay has removed the samples there a little bit too eagerly, > but most where outdated anyway. > > To upgrade from an older compiler I have successfully used the > upgrade.sh script. So the complete sequence to build a bootstrap > on your favourite platform would be: > > 1. Check out the current CVS head > 2. Copy your (working) configuration file to cm3/src/config/ > 3. Adapt the installer configuration file if necessary in > cminstall/src/config/. Make sure that all system libraries > get dynamically linked, for instance. > 4. scripts/upgrade.sh > 5. scripts/make-bin-dist-min.sh > > Any help will be appreciated. > > 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 hosking at cs.purdue.edu Tue Dec 18 17:27:49 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 18 Dec 2007 11:27:49 -0500 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/darwin In-Reply-To: <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> <28256359-D312-4D47-9A38-7A245D6AEAE5@cs.purdue.edu> <20071216233259.ukim9ntk6cw8gsgc@mail.elegosoft.com> <723A4C34-1B58-4F26-891C-45F764CAEEB5@cs.purdue.edu> <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> Message-ID: <31F9814D-0409-4B57-BADD-C61DB4C4B14D@cs.purdue.edu> What does an installation archive consist of? I've not used an install archive for several years, since I just bootstrap from my existing installs. On Dec 17, 2007, at 6:03 AM, Olaf Wagner wrote: > Quoting Tony Hosking : >> A break is always good. :-) > > Hi again, > > after some hours of sleep I can report at least some success on > my old Darwin installation. I've put the archives on our web server > for public access, and would like to add some more. > > I still think a Darwin build on a newer system may be a good idea (we > can offer both on our web pages), and we definitely need some > for Linux (perhaps multiple distros, too, there?) > Solaris and Darwin/i386 would be great, too, and NetBSD, and of > course Windows. Mika offered to provide an archive for old FreeBSD > distributions (4.x). > > So everybody who is willing to produce some installation archives, > please let me know, and I'll make sure they get shipped to our > server. > > Please note that for the scripts/make-bin-dist-min.sh to work, > you need a sample configuration file in cm3/m3-sys/cm3/src/config/XXX, > as the ones in cminstall/src/config must be processed by the installer > first. Jay has removed the samples there a little bit too eagerly, > but most where outdated anyway. > > To upgrade from an older compiler I have successfully used the > upgrade.sh script. So the complete sequence to build a bootstrap > on your favourite platform would be: > > 1. Check out the current CVS head > 2. Copy your (working) configuration file to cm3/src/config/ > 3. Adapt the installer configuration file if necessary in > cminstall/src/config/. Make sure that all system libraries > get dynamically linked, for instance. > 4. scripts/upgrade.sh > 5. scripts/make-bin-dist-min.sh > > Any help will be appreciated. > > 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 hosking at cs.purdue.edu Tue Dec 18 17:33:52 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 18 Dec 2007 11:33:52 -0500 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc In-Reply-To: <20071218100003.12irq679c4o404go@mail.elegosoft.com> References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> <28256359-D312-4D47-9A38-7A245D6AEAE5@cs.purdue.edu> <20071216233259.ukim9ntk6cw8gsgc@mail.elegosoft.com> <723A4C34-1B58-4F26-891C-45F764CAEEB5@cs.purdue.edu> <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> <20071218100003.12irq679c4o404go@mail.elegosoft.com> Message-ID: On Dec 18, 2007, at 4:00 AM, Olaf Wagner wrote: > Quoting Jay : > >> 64 bit integer support will have to wait. > As long as the binary does compile the current code base, it will > be OK, > I think. Yes, currently INTEGER=LONGINT on Win32 platforms using the integrated backend. > >> I assume we are in a "release push" here? > No, this is not really a release, I just had the impression that > some current snapshots were required. > >> I COULD if really necessary do about any x86 Linux (maybe x86 >> Solaris, don't think it is supported) or PowerPC Linux or PowerPC >> Darwin..in a virtual machine if nothing else.. > > I think PowerPC Linux would be great, if you find the time. I don't > know of many people who could build that. > >>> for Linux (perhaps multiple distros, too, there?) >> Oh for just a bit of compatibility... :) > I've done a build on Debian now. > >> Oh btw, anyone want to make an executive decision on a minor detail? >> .zip or .tar.gz or .tar.bz2 or self expanding .zip in an .exe? >> make-dist.cmd is setup to make any of these. >> I don't know how to make a self expanding .tar.gz >> or .tar.bz2...though should be easy, perhaps not with the >> following feature: >> The .exes can either be run, or can be used as direct input to >> unzip, or renamed to .zip and probably opened with Windows Explorer. >> It's pretty neat. >> .tar.bz2 is always the smallest in my experience and that's >> what I left make-dist.cmd doing. >> .tar.gz is usually in the middle. >> .zip usually largest, though more efficient for extracting less >> than the whole archive -- the files are compressed individually >> instead of compressing the entire stream at once. >> Self expanding .zip adds a small fixed constant prefix. > > I'm fine with any of these. Since Windows does seem to use other > approaches and conventions in most aspects anyway, we should just > go with what is easiest for beginners. What would you suggest? > Self-extracting .exe? > >> I wonder if cminstall can be "better" on Unix, comparable to it >> being gone on Windows, but I don't care. > No, it's not really better on Unix, but it's better than nothing > for many, and it takes efforts to change or improve it (including all > documentation), which nobody seems interested to invest. > >> You know, either make it unnecessary or make it totally automatic. >> I know it tries to figure out the defaults. I don't know how >> correct it tends to be. > Making such things completely automatic on many different target > platform > always ends in unmanageable efforts for small teams in my experience. > CM3 has no resources for this I'm afraid. > >> Oh and then a really obvious obnoxious question is if we should >> be building .debs, .rpms, Mac .pkg/.img/.dmg etc.. > This again is the question who wants to maintain all that stuff. > IMO it's OK if we have special support contributed for this or that > target, but nobody ever showed real interest in maintaining such > support through several release cycles. > >> Personally I don't mind the lowest tech current approach. >> Slackware anyone? :) (I used it in the Linux kernel 1.x time, >> which is when most of my Linux use ever was..) > I tend to agree that low-tech in the installation area may be > appropriate for CM3 ;-) > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From wagner at elegosoft.com Tue Dec 18 20:05:01 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 18 Dec 2007 20:05:01 +0100 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/darwin In-Reply-To: <31F9814D-0409-4B57-BADD-C61DB4C4B14D@cs.purdue.edu> References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> <28256359-D312-4D47-9A38-7A245D6AEAE5@cs.purdue.edu> <20071216233259.ukim9ntk6cw8gsgc@mail.elegosoft.com> <723A4C34-1B58-4F26-891C-45F764CAEEB5@cs.purdue.edu> <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> <31F9814D-0409-4B57-BADD-C61DB4C4B14D@cs.purdue.edu> Message-ID: <20071218200501.3xmb0yuyha80g8gs@mail.elegosoft.com> Quoting Tony Hosking : > What does an installation archive consist of? I've not used an install > archive for several years, since I just bootstrap from my existing > installs. See far below. They are easily built by the script make-bin-dist-bin.sh within a standard CM3 workspace (step 5). >> 1. Check out the current CVS head >> 2. Copy your (working) configuration file to cm3/src/config/ >> 3. Adapt the installer configuration file if necessary in >> cminstall/src/config/. Make sure that all system libraries >> get dynamically linked, for instance. >> 4. scripts/upgrade.sh >> 5. scripts/make-bin-dist-min.sh This is the exact installation procedure invented by Critical Mass and implemented in cminstall (except for the registration key). These are the contents of a sample: % tar tzf cm3-min-POSIX-FreeBSD6-d5.5.0.tgz cminstall COPYRIGHT-CMASS system.tgz birch [~/cm3-dist] wagner % tar tzf system.tgz ./ ./bin/ ./doc/ ./elisp/ ./examples/ ./lib/ ./man/ ./pkg/ ./pkg/m3core/ ./pkg/libm3/ ./pkg/libm3/FreeBSD4/ ./pkg/libm3/src/ ./pkg/libm3/src/text/ ./pkg/libm3/src/os/ ./pkg/libm3/src/random/ ./pkg/libm3/src/uid/ ./pkg/libm3/src/rw/ ./pkg/libm3/src/fmtlex/ ./pkg/libm3/src/list/ ./pkg/libm3/src/sx/ ./pkg/libm3/src/types/ ./pkg/libm3/src/arith/ ./pkg/libm3/src/geometry/ ./pkg/libm3/src/statistics/ ./pkg/libm3/src/formatter/ ./pkg/libm3/src/params/ ./pkg/libm3/src/property/ ./pkg/libm3/src/table/ ./pkg/libm3/src/atom/ ./pkg/libm3/src/sortedtable/ ./pkg/libm3/src/sort/ ./pkg/libm3/src/sequence/ ./pkg/libm3/src/etimer/ ./pkg/libm3/src/bundleintf/ ./pkg/libm3/src/perftool/ ./pkg/libm3/src/pqueue/ ./pkg/libm3/src/sqrt/ ./pkg/libm3/src/pickle/ ./pkg/libm3/src/pickle/ver1/ ./pkg/libm3/src/pickle/ver2/ ./pkg/libm3/src/pickle/ver2/PklTipeMap.i3 ./pkg/libm3/src/pickle/ver2/PklTipeMap.m3 ./pkg/libm3/src/pickle/ver2/ConvertPacking.i3 ./pkg/libm3/src/pickle/ver2/ConvertPacking.m3 ./pkg/libm3/src/pickle/ver2/PklAction.i3 ./pkg/libm3/src/pickle/ver2/PickleRd.i3 ./pkg/libm3/src/pickle/ver2/PackingTypeCode.m3 ./pkg/libm3/src/pickle/ver2/PackingTypeCode.i3 ./pkg/libm3/src/pickle/ver2/BuiltinSpecials2.m3 ./pkg/libm3/src/pickle/ver2/BuiltinSpecials2.i3 ./pkg/libm3/src/pickle/ver2/Pickle2.i3 ./pkg/libm3/src/pickle/ver2/Pickle2.m3 ./pkg/libm3/src/pickle/ver2/PickleStubs.i3 ./pkg/libm3/src/pickle/ver2/PickleStubs.m3 ./pkg/libm3/src/pickle/ver1/Pickle.m3 ./pkg/libm3/src/pickle/ver1/Pickle.i3 ./pkg/libm3/src/pickle/ver1/BuiltinSpecials.m3 ./pkg/libm3/src/pickle/ver1/BuiltinSpecials.i3 ./pkg/libm3/src/sqrt/FloatExtras.mg ./pkg/libm3/src/sqrt/FloatExtras.ig ./pkg/libm3/src/sqrt/Sqrt.mg ./pkg/libm3/src/sqrt/Sqrt.ig ./pkg/libm3/src/pqueue/pqueue.tmpl ./pkg/libm3/src/pqueue/PQueue.ig ./pkg/libm3/src/pqueue/PQueue.mg ./pkg/libm3/src/pqueue/PQueueRep.ig ./pkg/libm3/src/perftool/Common/ ./pkg/libm3/src/perftool/POSIX/ ./pkg/libm3/src/perftool/POSIX/LowPerfTool.m3 ./pkg/libm3/src/perftool/Common/PerfTool.m3 ./pkg/libm3/src/perftool/Common/PerfTool.i3 ./pkg/libm3/src/perftool/Common/LowPerfTool.i3 ./pkg/libm3/src/perftool/Common/PerfComm.ig ./pkg/libm3/src/perftool/Common/PerfComm.mg ./pkg/libm3/src/bundleintf/bundle.tmpl ./pkg/libm3/src/bundleintf/Bundle.i3 ./pkg/libm3/src/bundleintf/Bundle.m3 ./pkg/libm3/src/bundleintf/BundleRep.i3 ./pkg/libm3/src/etimer/ETimer.i3 ./pkg/libm3/src/etimer/ETimer.m3 ./pkg/libm3/src/sequence/sequence.tmpl ./pkg/libm3/src/sequence/Sequence.mg ./pkg/libm3/src/sequence/Sequence.ig ./pkg/libm3/src/sequence/SequenceRep.ig ./pkg/libm3/src/sort/ArraySort.ig ./pkg/libm3/src/sort/ArraySort.mg ./pkg/libm3/src/sort/arraysort.tmpl ./pkg/libm3/src/sortedtable/sortedtable.tmpl ./pkg/libm3/src/sortedtable/SortedTable.mg ./pkg/libm3/src/sortedtable/SortedTable.ig ./pkg/libm3/src/atom/Atom.i3 ./pkg/libm3/src/atom/Atom.m3 ./pkg/libm3/src/table/table.tmpl ./pkg/libm3/src/table/Table.ig ./pkg/libm3/src/table/Table.mg ./pkg/libm3/src/property/Property.i3 ./pkg/libm3/src/property/Property.m3 ./pkg/libm3/src/property/PropertyV.i3 ./pkg/libm3/src/property/PropertyV.m3 ./pkg/libm3/src/property/MProperty.m3 ./pkg/libm3/src/property/MProperty.i3 ./pkg/libm3/src/property/PropertyF.i3 ./pkg/libm3/src/property/MPropertyF.i3 ./pkg/libm3/src/params/Env.m3 ./pkg/libm3/src/params/Env.i3 ./pkg/libm3/src/params/Params.m3 ./pkg/libm3/src/params/Params.i3 ./pkg/libm3/src/formatter/Formatter.m3 ./pkg/libm3/src/formatter/Formatter.i3 ./pkg/libm3/src/statistics/Stat.m3 ./pkg/libm3/src/statistics/Stat.i3 ./pkg/libm3/src/geometry/Axis.i3 ./pkg/libm3/src/geometry/Axis.m3 ./pkg/libm3/src/geometry/Interval.i3 ./pkg/libm3/src/geometry/Interval.m3 ./pkg/libm3/src/geometry/Point.m3 ./pkg/libm3/src/geometry/Point.i3 ./pkg/libm3/src/geometry/Rect.i3 ./pkg/libm3/src/geometry/Rect.m3 ./pkg/libm3/src/geometry/Transform.i3 ./pkg/libm3/src/geometry/Transform.m3 ./pkg/libm3/src/geometry/Path.m3 ./pkg/libm3/src/geometry/Path.i3 ./pkg/libm3/src/geometry/Region.i3 ./pkg/libm3/src/geometry/Region.m3 ./pkg/libm3/src/geometry/PolyRegion.i3 ./pkg/libm3/src/geometry/PolyRegion.m3 ./pkg/libm3/src/geometry/Trapezoid.i3 ./pkg/libm3/src/geometry/Trapezoid.m3 ./pkg/libm3/src/geometry/RegionRep.i3 ./pkg/libm3/src/geometry/PathPrivate.i3 ./pkg/libm3/src/arith/POSIX/ ./pkg/libm3/src/arith/POSIX/Math.i3 ./pkg/libm3/src/types/Integer.m3 ./pkg/libm3/src/types/Integer.i3 ./pkg/libm3/src/types/Refany.i3 ./pkg/libm3/src/types/Refany.m3 ./pkg/libm3/src/types/Boolean.i3 ./pkg/libm3/src/types/Boolean.m3 ./pkg/libm3/src/types/Char.m3 ./pkg/libm3/src/types/Char.i3 ./pkg/libm3/src/types/Int32.i3 ./pkg/libm3/src/types/Int32.m3 ./pkg/libm3/src/types/Int64.i3 ./pkg/libm3/src/types/Int64.m3 ./pkg/libm3/src/types/Longint.i3 ./pkg/libm3/src/types/Longint.m3 ./pkg/libm3/src/types/ASCII.i3 ./pkg/libm3/src/types/ASCII.m3 ./pkg/libm3/src/types/RealType.i3 ./pkg/libm3/src/types/RealType.m3 ./pkg/libm3/src/types/LongrealType.i3 ./pkg/libm3/src/types/LongrealType.m3 ./pkg/libm3/src/types/WideChar.i3 ./pkg/libm3/src/types/WideChar.m3 ./pkg/libm3/src/types/Unicode.m3 ./pkg/libm3/src/types/Unicode.i3 ./pkg/libm3/src/sx/Sx.m3 ./pkg/libm3/src/sx/Sx.i3 ./pkg/libm3/src/list/list.tmpl ./pkg/libm3/src/list/List.mg ./pkg/libm3/src/list/List.ig ./pkg/libm3/src/list/ListSort.mg ./pkg/libm3/src/list/ListSort.ig ./pkg/libm3/src/fmtlex/Fmt.m3 ./pkg/libm3/src/fmtlex/Fmt.i3 ./pkg/libm3/src/fmtlex/Lex.m3 ./pkg/libm3/src/fmtlex/Lex.i3 ./pkg/libm3/src/fmtlex/Scan.i3 ./pkg/libm3/src/fmtlex/Scan.m3 ./pkg/libm3/src/fmtlex/FmtBuf.m3 ./pkg/libm3/src/fmtlex/FmtBuf.i3 ./pkg/libm3/src/fmtlex/FmtBufF.i3 ./pkg/libm3/src/fmtlex/FmtBufTest.i3 ./pkg/libm3/src/rw/Rd.i3 ./pkg/libm3/src/rw/Rd.m3 ./pkg/libm3/src/rw/RdClass.i3 ./pkg/libm3/src/rw/UnsafeRd.i3 ./pkg/libm3/src/rw/Wr.i3 ./pkg/libm3/src/rw/Wr.m3 ./pkg/libm3/src/rw/WrClass.i3 ./pkg/libm3/src/rw/UnsafeWr.i3 ./pkg/libm3/src/rw/NullRd.m3 ./pkg/libm3/src/rw/NullRd.i3 ./pkg/libm3/src/rw/NullWr.m3 ./pkg/libm3/src/rw/NullWr.i3 ./pkg/libm3/src/rw/RdCopy.i3 ./pkg/libm3/src/rw/RdCopy.m3 ./pkg/libm3/src/rw/TextRd.i3 ./pkg/libm3/src/rw/TextRd.m3 ./pkg/libm3/src/rw/TextWr.m3 ./pkg/libm3/src/rw/TextWr.i3 ./pkg/libm3/src/rw/FileRd.i3 ./pkg/libm3/src/rw/FileRd.m3 ./pkg/libm3/src/rw/FileWr.i3 ./pkg/libm3/src/rw/FileWr.m3 ./pkg/libm3/src/rw/IO.m3 ./pkg/libm3/src/rw/IO.i3 ./pkg/libm3/src/rw/AutoFlushWr.m3 ./pkg/libm3/src/rw/AutoFlushWr.i3 ./pkg/libm3/src/rw/Stdio.m3 ./pkg/libm3/src/rw/Stdio.i3 ./pkg/libm3/src/rw/RdUtils.m3 ./pkg/libm3/src/rw/RdUtils.i3 ./pkg/libm3/src/rw/RdExtras.m3 ./pkg/libm3/src/rw/RdExtras.i3 ./pkg/libm3/src/rw/MsgRd.i3 ./pkg/libm3/src/rw/MsgWr.i3 ./pkg/libm3/src/uid/Common/ ./pkg/libm3/src/uid/POSIX/ ./pkg/libm3/src/uid/POSIX/MachineIDPosixC.i3 ./pkg/libm3/src/uid/POSIX/MachineIDPosixC.c ./pkg/libm3/src/uid/POSIX/MachineIDPosix.m3 ./pkg/libm3/src/uid/Common/TimeStamp.i3 ./pkg/libm3/src/uid/Common/TimeStamp.m3 ./pkg/libm3/src/uid/Common/Capability.i3 ./pkg/libm3/src/uid/Common/Capability.m3 ./pkg/libm3/src/uid/Common/Swap.i3 ./pkg/libm3/src/uid/Common/Swap.m3 ./pkg/libm3/src/uid/Common/MachineID.i3 ./pkg/libm3/src/uid/Common/TimeStampRep.i3 ./pkg/libm3/src/random/Common/ ./pkg/libm3/src/random/IEEE/ ./pkg/libm3/src/random/IEEE/RandomReal.m3 ./pkg/libm3/src/random/Common/Random.m3 ./pkg/libm3/src/random/Common/Random.i3 ./pkg/libm3/src/random/Common/RandomPerm.i3 ./pkg/libm3/src/random/Common/RandomPerm.m3 ./pkg/libm3/src/random/Common/RandomReal.i3 ./pkg/libm3/src/os/Common/ ./pkg/libm3/src/os/POSIX/ ./pkg/libm3/src/os/POSIX/OSConfig.i3 ./pkg/libm3/src/os/POSIX/OSErrorPosix.i3 ./pkg/libm3/src/os/POSIX/OSErrorPosix.m3 ./pkg/libm3/src/os/POSIX/FilePosix.i3 ./pkg/libm3/src/os/POSIX/FilePosix.m3 ./pkg/libm3/src/os/POSIX/FSPosix.m3 ./pkg/libm3/src/os/POSIX/PipePosix.m3 ./pkg/libm3/src/os/POSIX/PathnamePosix.m3 ./pkg/libm3/src/os/POSIX/ProcessPosix.m3 ./pkg/libm3/src/os/POSIX/SocketPosix.m3 ./pkg/libm3/src/os/POSIX/OSConfigPosix.m3 ./pkg/libm3/src/os/Common/OSError.i3 ./pkg/libm3/src/os/Common/File.i3 ./pkg/libm3/src/os/Common/RegularFile.m3 ./pkg/libm3/src/os/Common/RegularFile.i3 ./pkg/libm3/src/os/Common/Pipe.i3 ./pkg/libm3/src/os/Common/Pipe.m3 ./pkg/libm3/src/os/Common/Pathname.i3 ./pkg/libm3/src/os/Common/FS.i3 ./pkg/libm3/src/os/Common/FS.m3 ./pkg/libm3/src/os/Common/Process.i3 ./pkg/libm3/src/os/Common/Socket.m3 ./pkg/libm3/src/os/Common/Socket.i3 ./pkg/libm3/src/os/Common/Terminal.m3 ./pkg/libm3/src/os/Common/Terminal.i3 ./pkg/libm3/src/text/TextExtras.m3 ./pkg/libm3/src/text/TextExtras.i3 ./pkg/libm3/FreeBSD4/.M3EXPORTS ./pkg/libm3/FreeBSD4/libm3.so.5 ./pkg/libm3/FreeBSD4/libm3.so ./pkg/libm3/FreeBSD4/libm3.a ./pkg/libm3/FreeBSD4/libm3.m3x ./pkg/libm3/FreeBSD4/.M3WEB ./pkg/libm3/FreeBSD4/AtomList.m3 ./pkg/libm3/FreeBSD4/AtomList.i3 ./pkg/libm3/FreeBSD4/IntList.i3 ./pkg/libm3/FreeBSD4/IntList.m3 ./pkg/libm3/FreeBSD4/RefList.m3 ./pkg/libm3/FreeBSD4/RefList.i3 ./pkg/libm3/FreeBSD4/TextList.i3 ./pkg/libm3/FreeBSD4/TextList.m3 ./pkg/libm3/FreeBSD4/AtomListSort.i3 ./pkg/libm3/FreeBSD4/AtomListSort.m3 ./pkg/libm3/FreeBSD4/IntListSort.m3 ./pkg/libm3/FreeBSD4/IntListSort.i3 ./pkg/libm3/FreeBSD4/RefListSort.i3 ./pkg/libm3/FreeBSD4/RefListSort.m3 ./pkg/libm3/FreeBSD4/TextListSort.m3 ./pkg/libm3/FreeBSD4/TextListSort.i3 ./pkg/libm3/FreeBSD4/AtomAtomTbl.m3 ./pkg/libm3/FreeBSD4/AtomAtomTbl.i3 ./pkg/libm3/FreeBSD4/AtomIntTbl.i3 ./pkg/libm3/FreeBSD4/AtomIntTbl.m3 ./pkg/libm3/FreeBSD4/AtomRefTbl.m3 ./pkg/libm3/FreeBSD4/AtomRefTbl.i3 ./pkg/libm3/FreeBSD4/AtomTextTbl.i3 ./pkg/libm3/FreeBSD4/AtomTextTbl.m3 ./pkg/libm3/FreeBSD4/IntAtomTbl.i3 ./pkg/libm3/FreeBSD4/IntAtomTbl.m3 ./pkg/libm3/FreeBSD4/IntIntTbl.i3 ./pkg/libm3/FreeBSD4/IntIntTbl.m3 ./pkg/libm3/FreeBSD4/IntRefTbl.i3 ./pkg/libm3/FreeBSD4/IntRefTbl.m3 ./pkg/libm3/FreeBSD4/IntTextTbl.i3 ./pkg/libm3/FreeBSD4/IntTextTbl.m3 ./pkg/libm3/FreeBSD4/RefAtomTbl.m3 ./pkg/libm3/FreeBSD4/RefAtomTbl.i3 ./pkg/libm3/FreeBSD4/RefIntTbl.i3 ./pkg/libm3/FreeBSD4/RefIntTbl.m3 ./pkg/libm3/FreeBSD4/RefRefTbl.i3 ./pkg/libm3/FreeBSD4/RefRefTbl.m3 ./pkg/libm3/FreeBSD4/RefTextTbl.i3 ./pkg/libm3/FreeBSD4/RefTextTbl.m3 ./pkg/libm3/FreeBSD4/TextAtomTbl.m3 ./pkg/libm3/FreeBSD4/TextAtomTbl.i3 ./pkg/libm3/FreeBSD4/TextIntTbl.i3 ./pkg/libm3/FreeBSD4/TextIntTbl.m3 ./pkg/libm3/FreeBSD4/TextRefTbl.i3 ./pkg/libm3/FreeBSD4/TextRefTbl.m3 ./pkg/libm3/FreeBSD4/TextTextTbl.i3 ./pkg/libm3/FreeBSD4/TextTextTbl.m3 ./pkg/libm3/FreeBSD4/SortedAtomAtomTbl.m3 ./pkg/libm3/FreeBSD4/SortedAtomAtomTbl.i3 ./pkg/libm3/FreeBSD4/SortedAtomIntTbl.i3 ./pkg/libm3/FreeBSD4/SortedAtomIntTbl.m3 ./pkg/libm3/FreeBSD4/SortedAtomRefTbl.i3 ./pkg/libm3/FreeBSD4/SortedAtomRefTbl.m3 ./pkg/libm3/FreeBSD4/SortedAtomTextTbl.i3 ./pkg/libm3/FreeBSD4/SortedAtomTextTbl.m3 ./pkg/libm3/FreeBSD4/SortedIntAtomTbl.m3 ./pkg/libm3/FreeBSD4/SortedIntAtomTbl.i3 ./pkg/libm3/FreeBSD4/SortedIntIntTbl.i3 ./pkg/libm3/FreeBSD4/SortedIntIntTbl.m3 ./pkg/libm3/FreeBSD4/SortedIntRefTbl.m3 ./pkg/libm3/FreeBSD4/SortedIntRefTbl.i3 ./pkg/libm3/FreeBSD4/SortedIntTextTbl.i3 ./pkg/libm3/FreeBSD4/SortedIntTextTbl.m3 ./pkg/libm3/FreeBSD4/SortedRefAtomTbl.i3 ./pkg/libm3/FreeBSD4/SortedRefAtomTbl.m3 ./pkg/libm3/FreeBSD4/SortedRefIntTbl.i3 ./pkg/libm3/FreeBSD4/SortedRefIntTbl.m3 ./pkg/libm3/FreeBSD4/SortedRefRefTbl.m3 ./pkg/libm3/FreeBSD4/SortedRefRefTbl.i3 ./pkg/libm3/FreeBSD4/SortedRefTextTbl.i3 ./pkg/libm3/FreeBSD4/SortedRefTextTbl.m3 ./pkg/libm3/FreeBSD4/SortedTextAtomTbl.m3 ./pkg/libm3/FreeBSD4/SortedTextAtomTbl.i3 ./pkg/libm3/FreeBSD4/SortedTextIntTbl.m3 ./pkg/libm3/FreeBSD4/SortedTextIntTbl.i3 ./pkg/libm3/FreeBSD4/SortedTextRefTbl.i3 ./pkg/libm3/FreeBSD4/SortedTextRefTbl.m3 ./pkg/libm3/FreeBSD4/SortedTextTextTbl.m3 ./pkg/libm3/FreeBSD4/SortedTextTextTbl.i3 ./pkg/libm3/FreeBSD4/IntArraySort.i3 ./pkg/libm3/FreeBSD4/IntArraySort.m3 ./pkg/libm3/FreeBSD4/TextArraySort.i3 ./pkg/libm3/FreeBSD4/TextArraySort.m3 ./pkg/libm3/FreeBSD4/AtomSeq.i3 ./pkg/libm3/FreeBSD4/AtomSeq.m3 ./pkg/libm3/FreeBSD4/AtomSeqRep.i3 ./pkg/libm3/FreeBSD4/IntSeq.m3 ./pkg/libm3/FreeBSD4/IntSeq.i3 ./pkg/libm3/FreeBSD4/IntSeqRep.i3 ./pkg/libm3/FreeBSD4/RefSeq.i3 ./pkg/libm3/FreeBSD4/RefSeq.m3 ./pkg/libm3/FreeBSD4/RefSeqRep.i3 ./pkg/libm3/FreeBSD4/TextSeq.m3 ./pkg/libm3/FreeBSD4/TextSeq.i3 ./pkg/libm3/FreeBSD4/TextSeqRep.i3 ./pkg/libm3/FreeBSD4/AtomPQ.i3 ./pkg/libm3/FreeBSD4/AtomPQ.m3 ./pkg/libm3/FreeBSD4/AtomPQRep.i3 ./pkg/libm3/FreeBSD4/IntPQ.m3 ./pkg/libm3/FreeBSD4/IntPQ.i3 ./pkg/libm3/FreeBSD4/IntPQRep.i3 ./pkg/libm3/FreeBSD4/RefPQ.i3 ./pkg/libm3/FreeBSD4/RefPQ.m3 ./pkg/libm3/FreeBSD4/RefPQRep.i3 ./pkg/libm3/FreeBSD4/TextPQ.i3 ./pkg/libm3/FreeBSD4/TextPQ.m3 ./pkg/libm3/FreeBSD4/TextPQRep.i3 ./pkg/libm3/FreeBSD4/RealFloatExtras.m3 ./pkg/libm3/FreeBSD4/RealFloatExtras.i3 ./pkg/libm3/FreeBSD4/LongFloatExtras.i3 ./pkg/libm3/FreeBSD4/LongFloatExtras.m3 ./pkg/libm3/FreeBSD4/RealSqrt.i3 ./pkg/libm3/FreeBSD4/RealSqrt.m3 ./pkg/libm3/FreeBSD4/LongSqrt.i3 ./pkg/libm3/FreeBSD4/LongSqrt.m3 ./pkg/libm3/FreeBSD4/M3Config.i3 ./pkg/libm3/FreeBSD4/PklActionSeq.m3 ./pkg/libm3/FreeBSD4/PklActionSeq.i3 ./pkg/libm3/FreeBSD4/PklActionSeqRep.i3 ./pkg/libm3/FreeBSD4/PackingTbl.i3 ./pkg/libm3/FreeBSD4/PackingTbl.m3 ./pkg/m3core/FreeBSD4/ ./pkg/m3core/src/ ./pkg/m3core/src/Csupport/ ./pkg/m3core/src/runtime/ ./pkg/m3core/src/thread/ ./pkg/m3core/src/unix/ ./pkg/m3core/src/C/ ./pkg/m3core/src/float/ ./pkg/m3core/src/time/ ./pkg/m3core/src/convert/ ./pkg/m3core/src/text/ ./pkg/m3core/src/fingerprint/ ./pkg/m3core/src/main/ ./pkg/m3core/src/weakref/ ./pkg/m3core/src/word/ ./pkg/m3core/src/word/GenWord.ig ./pkg/m3core/src/word/GenWord.mg ./pkg/m3core/src/word/WordRep.i3 ./pkg/m3core/src/word/Word.m3 ./pkg/m3core/src/word/Word.i3 ./pkg/m3core/src/word/LongRep.i3 ./pkg/m3core/src/word/Long.i3 ./pkg/m3core/src/word/Long.m3 ./pkg/m3core/src/weakref/WeakRef.i3 ./pkg/m3core/src/weakref/WeakRef.m3 ./pkg/m3core/src/main/Main.i3 ./pkg/m3core/src/fingerprint/Fingerprint.i3 ./pkg/m3core/src/fingerprint/Fingerprint.m3 ./pkg/m3core/src/fingerprint/Poly.i3 ./pkg/m3core/src/fingerprint/Poly.m3 ./pkg/m3core/src/fingerprint/PolyBasis.m3 ./pkg/m3core/src/fingerprint/PolyBasis.i3 ./pkg/m3core/src/text/String8.i3 ./pkg/m3core/src/text/String8.m3 ./pkg/m3core/src/text/String16.m3 ./pkg/m3core/src/text/String16.i3 ./pkg/m3core/src/text/Text.i3 ./pkg/m3core/src/text/Text.m3 ./pkg/m3core/src/text/TextClass.i3 ./pkg/m3core/src/text/TextClass.m3 ./pkg/m3core/src/text/TextLiteral.m3 ./pkg/m3core/src/text/TextLiteral.i3 ./pkg/m3core/src/text/Text8.i3 ./pkg/m3core/src/text/Text8.m3 ./pkg/m3core/src/text/Text8Short.i3 ./pkg/m3core/src/text/Text8Short.m3 ./pkg/m3core/src/text/Text8CString.i3 ./pkg/m3core/src/text/Text8CString.m3 ./pkg/m3core/src/text/Text16.m3 ./pkg/m3core/src/text/Text16.i3 ./pkg/m3core/src/text/Text16Short.i3 ./pkg/m3core/src/text/Text16Short.m3 ./pkg/m3core/src/text/TextSub.i3 ./pkg/m3core/src/text/TextSub.m3 ./pkg/m3core/src/text/TextCat.m3 ./pkg/m3core/src/text/TextCat.i3 ./pkg/m3core/src/text/TextConv.i3 ./pkg/m3core/src/text/TextConv.m3 ./pkg/m3core/src/convert/CConvert.i3 ./pkg/m3core/src/convert/CConvert.m3 ./pkg/m3core/src/convert/Convert.i3 ./pkg/m3core/src/convert/Convert.m3 ./pkg/m3core/src/time/Common/ ./pkg/m3core/src/time/Portable/ ./pkg/m3core/src/time/POSIX/ ./pkg/m3core/src/time/POSIX/DateBsd.m3 ./pkg/m3core/src/time/POSIX/TimePosix.m3 ./pkg/m3core/src/time/POSIX/TimePosix.i3 ./pkg/m3core/src/time/Portable/TickPortable.m3 ./pkg/m3core/src/time/Common/Time.i3 ./pkg/m3core/src/time/Common/Tick.i3 ./pkg/m3core/src/time/Common/Date.i3 ./pkg/m3core/src/time/Common/FmtTime.i3 ./pkg/m3core/src/time/Common/FmtTime.m3 ./pkg/m3core/src/float/Common/ ./pkg/m3core/src/float/IEEE/ ./pkg/m3core/src/float/IEEE-le/ ./pkg/m3core/src/float/IEEE-default/ ./pkg/m3core/src/float/IEEE-default/FPU.i3 ./pkg/m3core/src/float/IEEE-default/FPU.m3 ./pkg/m3core/src/float/IEEE-default/FloatMode.i3 ./pkg/m3core/src/float/IEEE-default/FloatMode.m3 ./pkg/m3core/src/float/IEEE-le/RealRep.i3 ./pkg/m3core/src/float/IEEE-le/LongRealRep.i3 ./pkg/m3core/src/float/IEEE/RealFloat.m3 ./pkg/m3core/src/float/IEEE/LongFloat.m3 ./pkg/m3core/src/float/IEEE/ExtendedFloat.m3 ./pkg/m3core/src/float/IEEE/Real.i3 ./pkg/m3core/src/float/IEEE/LongReal.i3 ./pkg/m3core/src/float/IEEE/Extended.i3 ./pkg/m3core/src/float/Common/Float.ig ./pkg/m3core/src/float/Common/RealFloat.i3 ./pkg/m3core/src/float/Common/LongFloat.i3 ./pkg/m3core/src/float/Common/ExtendedFloat.i3 ./pkg/m3core/src/float/Common/IEEESpecial.m3 ./pkg/m3core/src/float/Common/IEEESpecial.i3 ./pkg/m3core/src/float/Common/Real.m3 ./pkg/m3core/src/float/Common/LongReal.m3 ./pkg/m3core/src/float/Common/Extended.m3 ./pkg/m3core/src/float/Common/DragonInt.i3 ./pkg/m3core/src/float/Common/DragonInt.m3 ./pkg/m3core/src/float/Common/DragonT.m3 ./pkg/m3core/src/float/Common/DragonT.i3 ./pkg/m3core/src/C/Common/ ./pkg/m3core/src/C/FreeBSD4/ ./pkg/m3core/src/C/32BITS/ ./pkg/m3core/src/C/32BITS/BasicCtypes.i3 ./pkg/m3core/src/C/FreeBSD4/Csetjmp.i3 ./pkg/m3core/src/C/FreeBSD4/Csignal.i3 ./pkg/m3core/src/C/FreeBSD4/Cstring.i3 ./pkg/m3core/src/C/FreeBSD4/Cstdio.i3 ./pkg/m3core/src/C/FreeBSD4/Cstdio.m3 ./pkg/m3core/src/C/FreeBSD4/CstdioC.c ./pkg/m3core/src/C/Common/Cerrno.i3 ./pkg/m3core/src/C/Common/Cstddef.i3 ./pkg/m3core/src/C/Common/Cstdlib.i3 ./pkg/m3core/src/C/Common/Ctypes.i3 ./pkg/m3core/src/C/Common/M3toC.i3 ./pkg/m3core/src/C/Common/M3toC.m3 ./pkg/m3core/src/C/Common/Cstdarg.m3 ./pkg/m3core/src/C/Common/Cstdarg.i3 ./pkg/m3core/src/C/Common/CerrnoC.c ./pkg/m3core/src/unix/freebsd-4/ ./pkg/m3core/src/unix/freebsd-4/Udir.i3 ./pkg/m3core/src/unix/freebsd-4/Uerror.i3 ./pkg/m3core/src/unix/freebsd-4/Uexec.i3 ./pkg/m3core/src/unix/freebsd-4/Ugrp.i3 ./pkg/m3core/src/unix/freebsd-4/Uin.i3 ./pkg/m3core/src/unix/freebsd-4/Uin.m3 ./pkg/m3core/src/unix/freebsd-4/Uipc.i3 ./pkg/m3core/src/unix/freebsd-4/Umman.i3 ./pkg/m3core/src/unix/freebsd-4/Umsg.m3 ./pkg/m3core/src/unix/freebsd-4/Umsg.i3 ./pkg/m3core/src/unix/freebsd-4/Unetdb.i3 ./pkg/m3core/src/unix/freebsd-4/Unetdb.m3 ./pkg/m3core/src/unix/freebsd-4/Unix.i3 ./pkg/m3core/src/unix/freebsd-4/Uprocess.i3 ./pkg/m3core/src/unix/freebsd-4/Upwd.i3 ./pkg/m3core/src/unix/freebsd-4/Uresource.i3 ./pkg/m3core/src/unix/freebsd-4/Usem.i3 ./pkg/m3core/src/unix/freebsd-4/Ushm.i3 ./pkg/m3core/src/unix/freebsd-4/Usignal.i3 ./pkg/m3core/src/unix/freebsd-4/Usignal.m3 ./pkg/m3core/src/unix/freebsd-4/Ustat.i3 ./pkg/m3core/src/unix/freebsd-4/Usocket.i3 ./pkg/m3core/src/unix/freebsd-4/Usyslog.i3 ./pkg/m3core/src/unix/freebsd-4/Utime.i3 ./pkg/m3core/src/unix/freebsd-4/Utypes.i3 ./pkg/m3core/src/unix/freebsd-4/Utypes.m3 ./pkg/m3core/src/unix/freebsd-4/Uugid.i3 ./pkg/m3core/src/unix/freebsd-4/Uuio.i3 ./pkg/m3core/src/unix/freebsd-4/Uutmp.i3 ./pkg/m3core/src/unix/freebsd-4/Uutsname.i3 ./pkg/m3core/src/thread/Common/ ./pkg/m3core/src/thread/POSIX/ ./pkg/m3core/src/thread/POSIX/SchedulerPosix.i3 ./pkg/m3core/src/thread/POSIX/ThreadF.i3 ./pkg/m3core/src/thread/POSIX/ThreadPosix.m3 ./pkg/m3core/src/thread/Common/Thread.i3 ./pkg/m3core/src/thread/Common/Scheduler.i3 ./pkg/m3core/src/thread/Common/MutexRep.i3 ./pkg/m3core/src/thread/Common/ThreadEvent.i3 ./pkg/m3core/src/runtime/common/ ./pkg/m3core/src/runtime/POSIX/ ./pkg/m3core/src/runtime/FreeBSD4/ ./pkg/m3core/src/runtime/ex_frame/ ./pkg/m3core/src/runtime/ex_frame/RTExFrame.i3 ./pkg/m3core/src/runtime/ex_frame/RTExFrame.m3 ./pkg/m3core/src/runtime/ex_frame/RTStackC.c ./pkg/m3core/src/runtime/FreeBSD4/RTSignal.m3 ./pkg/m3core/src/runtime/FreeBSD4/RTThread.m3 ./pkg/m3core/src/runtime/FreeBSD4/RTMachine.i3 ./pkg/m3core/src/runtime/FreeBSD4/RTThreadC.c ./pkg/m3core/src/runtime/FreeBSD4/_fpsetjmp.s ./pkg/m3core/src/runtime/POSIX/RTArgs.m3 ./pkg/m3core/src/runtime/POSIX/RTOS.m3 ./pkg/m3core/src/runtime/POSIX/RTPerfTool.m3 ./pkg/m3core/src/runtime/POSIX/RTPerfTool.i3 ./pkg/m3core/src/runtime/POSIX/RTProcessPosix.m3 ./pkg/m3core/src/runtime/POSIX/RTThread.i3 ./pkg/m3core/src/runtime/POSIX/RTThreadStk.m3 ./pkg/m3core/src/runtime/common/RTHooks.i3 ./pkg/m3core/src/runtime/common/RTHooks.m3 ./pkg/m3core/src/runtime/common/RT0.m3 ./pkg/m3core/src/runtime/common/RT0.i3 ./pkg/m3core/src/runtime/common/RuntimeError.i3 ./pkg/m3core/src/runtime/common/RuntimeError.m3 ./pkg/m3core/src/runtime/common/Compiler.m3 ./pkg/m3core/src/runtime/common/RTAllocator.i3 ./pkg/m3core/src/runtime/common/RTAllocator.m3 ./pkg/m3core/src/runtime/common/RTAllocCnts.i3 ./pkg/m3core/src/runtime/common/RTAllocStats.i3 ./pkg/m3core/src/runtime/common/RTAllocStats.m3 ./pkg/m3core/src/runtime/common/RTHeap.i3 ./pkg/m3core/src/runtime/common/RTHeap.m3 ./pkg/m3core/src/runtime/common/RTHeapInfo.i3 ./pkg/m3core/src/runtime/common/RTHeapInfo.m3 ./pkg/m3core/src/runtime/common/RTHeapMap.m3 ./pkg/m3core/src/runtime/common/RTHeapMap.i3 ./pkg/m3core/src/runtime/common/RTHeapRep.i3 ./pkg/m3core/src/runtime/common/RTHeapRep.m3 ./pkg/m3core/src/runtime/common/RTHeapStats.i3 ./pkg/m3core/src/runtime/common/RTIO.i3 ./pkg/m3core/src/runtime/common/RTHeapStats.m3 ./pkg/m3core/src/runtime/common/RTCollector.m3 ./pkg/m3core/src/runtime/common/RTCollector.i3 ./pkg/m3core/src/runtime/common/RTCollectorSRC.i3 ./pkg/m3core/src/runtime/common/RTWeakRef.i3 ./pkg/m3core/src/runtime/common/RTIO.m3 ./pkg/m3core/src/runtime/common/RTLinkerX.i3 ./pkg/m3core/src/runtime/common/RTLinker.m3 ./pkg/m3core/src/runtime/common/RTLinker.i3 ./pkg/m3core/src/runtime/common/RTDebug.i3 ./pkg/m3core/src/runtime/common/RTDebug.m3 ./pkg/m3core/src/runtime/common/RTError.i3 ./pkg/m3core/src/runtime/common/RTError.m3 ./pkg/m3core/src/runtime/common/RTException.m3 ./pkg/m3core/src/runtime/common/RTException.i3 ./pkg/m3core/src/runtime/common/RTMapOp.i3 ./pkg/m3core/src/runtime/common/RTMapOp.m3 ./pkg/m3core/src/runtime/common/RTMisc.i3 ./pkg/m3core/src/runtime/common/RTMisc.m3 ./pkg/m3core/src/runtime/common/RTModule.i3 ./pkg/m3core/src/runtime/common/RTPacking.m3 ./pkg/m3core/src/runtime/common/RTPacking.i3 ./pkg/m3core/src/runtime/common/RTParams.i3 ./pkg/m3core/src/runtime/common/RTParams.m3 ./pkg/m3core/src/runtime/common/RTProcedure.i3 ./pkg/m3core/src/runtime/common/RTProcedure.m3 ./pkg/m3core/src/runtime/common/RTProcess.i3 ./pkg/m3core/src/runtime/common/RTProcess.m3 ./pkg/m3core/src/runtime/common/RTTipe.m3 ./pkg/m3core/src/runtime/common/RTTipe.i3 ./pkg/m3core/src/runtime/common/RTType.i3 ./pkg/m3core/src/runtime/common/RTType.m3 ./pkg/m3core/src/runtime/common/RTTypeFP.i3 ./pkg/m3core/src/runtime/common/RTTypeFP.m3 ./pkg/m3core/src/runtime/common/RTTypeMap.i3 ./pkg/m3core/src/runtime/common/RTTypeMap.m3 ./pkg/m3core/src/runtime/common/RTutils.m3 ./pkg/m3core/src/runtime/common/RTutils.i3 ./pkg/m3core/src/runtime/common/RTHeapDebug.i3 ./pkg/m3core/src/runtime/common/RTHeapDebug.m3 ./pkg/m3core/src/runtime/common/RTArgs.i3 ./pkg/m3core/src/runtime/common/RTHeapEvent.i3 ./pkg/m3core/src/runtime/common/RTProcedureSRC.i3 ./pkg/m3core/src/runtime/common/RTSignal.i3 ./pkg/m3core/src/runtime/common/RTStack.i3 ./pkg/m3core/src/runtime/common/RTTypeSRC.i3 ./pkg/m3core/src/runtime/common/RTOS.i3 ./pkg/m3core/src/Csupport/Common/ ./pkg/m3core/src/Csupport/FreeBSD4/ ./pkg/m3core/src/Csupport/FreeBSD4/dtoa.c ./pkg/m3core/src/Csupport/Common/dtoa.h ./pkg/m3core/src/Csupport/Common/hand.c ./pkg/m3core/FreeBSD4/.M3EXPORTS ./pkg/m3core/FreeBSD4/libm3core.so.5 ./pkg/m3core/FreeBSD4/libm3core.so ./pkg/m3core/FreeBSD4/libm3core.a ./pkg/m3core/FreeBSD4/libm3core.m3x ./pkg/m3core/FreeBSD4/.M3WEB ./pkg/m3core/FreeBSD4/Compiler.i3 ./lib/libm3core.so.5 ./lib/libm3core.so ./lib/libm3.so.5 ./lib/libm3.so ./bin/cm3 ./bin/cm3cg ./bin/cm3.cfg ./bin/cm3.cfg--default -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Dec 18 23:51:45 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 18 Dec 2007 17:51:45 -0500 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/darwin In-Reply-To: <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> <28256359-D312-4D47-9A38-7A245D6AEAE5@cs.purdue.edu> <20071216233259.ukim9ntk6cw8gsgc@mail.elegosoft.com> <723A4C34-1B58-4F26-891C-45F764CAEEB5@cs.purdue.edu> <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> Message-ID: <1430B28B-A256-4B74-877D-9533183DFA42@cs.purdue.edu> I have put installation archives for I386_DARWIN and PPC_DARWIN at ftp://ftp.cs.purdue.edu/pub/hosking/m3. On Dec 17, 2007, at 6:03 AM, Olaf Wagner wrote: > Quoting Tony Hosking : >> A break is always good. :-) > > Hi again, > > after some hours of sleep I can report at least some success on > my old Darwin installation. I've put the archives on our web server > for public access, and would like to add some more. > > I still think a Darwin build on a newer system may be a good idea (we > can offer both on our web pages), and we definitely need some > for Linux (perhaps multiple distros, too, there?) > Solaris and Darwin/i386 would be great, too, and NetBSD, and of > course Windows. Mika offered to provide an archive for old FreeBSD > distributions (4.x). > > So everybody who is willing to produce some installation archives, > please let me know, and I'll make sure they get shipped to our > server. > > Please note that for the scripts/make-bin-dist-min.sh to work, > you need a sample configuration file in cm3/m3-sys/cm3/src/config/XXX, > as the ones in cminstall/src/config must be processed by the installer > first. Jay has removed the samples there a little bit too eagerly, > but most where outdated anyway. > > To upgrade from an older compiler I have successfully used the > upgrade.sh script. So the complete sequence to build a bootstrap > on your favourite platform would be: > > 1. Check out the current CVS head > 2. Copy your (working) configuration file to cm3/src/config/ > 3. Adapt the installer configuration file if necessary in > cminstall/src/config/. Make sure that all system libraries > get dynamically linked, for instance. > 4. scripts/upgrade.sh > 5. scripts/make-bin-dist-min.sh > > Any help will be appreciated. > > 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 hosking at cs.purdue.edu Wed Dec 19 00:23:49 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 18 Dec 2007 18:23:49 -0500 Subject: [M3devel] Unix signals and Modula-3... In-Reply-To: <200712181238.lBICcL8s052879@camembert.async.caltech.edu> References: <200712181238.lBICcL8s052879@camembert.async.caltech.edu> Message-ID: <92B67E8E-DB72-4436-A096-564DFF214D4D@cs.purdue.edu> I'm assuming that waitpid hanging when using system threads is not a problem, since the system thread scheduler will schedule other threads around the waiting one. The issue is only for the user-level threads implementation where a thread blocking on a waitpid call would prevent other threads being scheduled. On Dec 18, 2007, at 7:38 AM, Mika Nystrom wrote: > Hello everyone, > > I am in the process of bootstrapping the CVS head of CM3 on an old > FreeBSD-4.11 system, and at one point, when I replaced the old cm3 > with the new cm3, the compiler got slower. Not a little bit slower, > mind you, but about 10x slower. I remember pointing this out to > the m3devel list... oh it must have been three or four years ago; > one of our grad students at Caltech (Karl Papadantonakis, also > author of the caltech-parser) was the first to notice what was going > on. > > It has to do with Process.Wait. (From ProcessPosix.m3.) To repeat > what I said a few years ago, the problem lies here: > > CONST Delay = 0.1D0; > BEGIN > IF NOT p.waitOk THEN RAISE WaitAlreadyCalled END; > p.waitOk := FALSE; > (* By rights, the SchedulerPosix interface should have a WaitPID > procedure that is integrated with the thread scheduler. *) > LOOP > result := Uexec.waitpid(p.pid, ADR(statusT), Uexec.WNOHANG); > IF result # 0 THEN EXIT END; > Thread.Pause(Delay) > END; > <* ASSERT result > 0 *> > > In other words: if Process.Wait is called before the child process > is done, then the thread pauses 0.1 seconds. > > In our local version of m3build, we duplicate the Wait code and set > the Delay to 0.0. That's OK in a compiler, but it's not OK in > general, because you would chew up the CPU on a machine that was > doing a lot of long-term waiting. > > The problem is that the fix that I suggested way back when requires > messing with Unix signals (catching SIGC[H]LD instead of using > waitpid), which is why I never submitted a fix to the repository, > because I am not sure what such a fix might interact with. It seems > to me that the correct way of dealing with Unix signals is to have > a single thread that talks to the Unix system, registers signal > handlers, and takes care, via some object-oriented mechanism, of > calling back any M3 threads that are interested in the signals. > Would such a thing be possible? Where are signals used in the > system today? > > Mika From mika at async.caltech.edu Wed Dec 19 00:43:19 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 18 Dec 2007 15:43:19 -0800 Subject: [M3devel] Unix signals and Modula-3... In-Reply-To: Your message of "Tue, 18 Dec 2007 18:23:49 EST." <92B67E8E-DB72-4436-A096-564DFF214D4D@cs.purdue.edu> Message-ID: <200712182343.lBINhJDL084804@camembert.async.caltech.edu> Ah yes, you are right. The original issue is that waitpid would hang the whole runtime and that should not happen with system threads. If using system threads, waitpid should be called with a third argument of zero, I believe. Is this already happening? If not, make the change and if you have a fast machine you may see a spectacular speedup in your compile times. I suppose the easiest solution to this problem is simply to move all active targets to system threads... Still, there are some other areas where Unix signals might be of interest. I am thinking of things like interfacing with readline and other C-based libraries that use signals for concurrency. When I put a readline interface on some Modula-3 programs, I wound up using an external C program to do readline processing and then communicating over a pipe or TCP connection, because dealing with signals seemed like such a hassle. Mika Tony Hosking writes: >I'm assuming that waitpid hanging when using system threads is not a >problem, since the system thread scheduler will schedule other >threads around the waiting one. The issue is only for the user-level >threads implementation where a thread blocking on a waitpid call >would prevent other threads being scheduled. > >On Dec 18, 2007, at 7:38 AM, Mika Nystrom wrote: > >> Hello everyone, >> >> I am in the process of bootstrapping the CVS head of CM3 on an old >> FreeBSD-4.11 system, and at one point, when I replaced the old cm3 >> with the new cm3, the compiler got slower. Not a little bit slower, >> mind you, but about 10x slower. I remember pointing this out to >> the m3devel list... oh it must have been three or four years ago; >> one of our grad students at Caltech (Karl Papadantonakis, also >> author of the caltech-parser) was the first to notice what was going >> on. >> >> It has to do with Process.Wait. (From ProcessPosix.m3.) To repeat >> what I said a few years ago, the problem lies here: >> >> CONST Delay = 0.1D0; >> BEGIN >> IF NOT p.waitOk THEN RAISE WaitAlreadyCalled END; >> p.waitOk := FALSE; >> (* By rights, the SchedulerPosix interface should have a WaitPID >> procedure that is integrated with the thread scheduler. *) >> LOOP >> result := Uexec.waitpid(p.pid, ADR(statusT), Uexec.WNOHANG); >> IF result # 0 THEN EXIT END; >> Thread.Pause(Delay) >> END; >> <* ASSERT result > 0 *> >> >> In other words: if Process.Wait is called before the child process >> is done, then the thread pauses 0.1 seconds. >> >> In our local version of m3build, we duplicate the Wait code and set >> the Delay to 0.0. That's OK in a compiler, but it's not OK in >> general, because you would chew up the CPU on a machine that was >> doing a lot of long-term waiting. >> >> The problem is that the fix that I suggested way back when requires >> messing with Unix signals (catching SIGC[H]LD instead of using >> waitpid), which is why I never submitted a fix to the repository, >> because I am not sure what such a fix might interact with. It seems >> to me that the correct way of dealing with Unix signals is to have >> a single thread that talks to the Unix system, registers signal >> handlers, and takes care, via some object-oriented mechanism, of >> calling back any M3 threads that are interested in the signals. >> Would such a thing be possible? Where are signals used in the >> system today? >> >> Mika From wagner at elegosoft.com Wed Dec 19 00:44:06 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 19 Dec 2007 00:44:06 +0100 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/darwin In-Reply-To: <1430B28B-A256-4B74-877D-9533183DFA42@cs.purdue.edu> References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> <28256359-D312-4D47-9A38-7A245D6AEAE5@cs.purdue.edu> <20071216233259.ukim9ntk6cw8gsgc@mail.elegosoft.com> <723A4C34-1B58-4F26-891C-45F764CAEEB5@cs.purdue.edu> <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> <1430B28B-A256-4B74-877D-9533183DFA42@cs.purdue.edu> Message-ID: <20071219004406.mnemi5gnc4g4c80g@mail.elegosoft.com> Quoting Tony Hosking : > I have put installation archives for I386_DARWIN and PPC_DARWIN at > ftp://ftp.cs.purdue.edu/pub/hosking/m3. Great. I've shipped all the archives available so far to our web server at http://modula3.elegosoft.com/cm3/. I'm not sure if all the information on the download page is correct, and I'm sure the documentation and instructions provided are rather sparse. If anybody wants to improve that, please don't hesitate to edit cm3/www/download.html; I can then later ship the changes. Now it's time for bed again; thanks for all the help, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Wed Dec 19 01:03:46 2007 From: jayk123 at hotmail.com (Jay) Date: Wed, 19 Dec 2007 00:03:46 +0000 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/ In-Reply-To: <20071219004406.mnemi5gnc4g4c80g@mail.elegosoft.com> References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> <28256359-D312-4D47-9A38-7A245D6AEAE5@cs.purdue.edu> <20071216233259.ukim9ntk6cw8gsgc@mail.elegosoft.com> <723A4C34-1B58-4F26-891C-45F764CAEEB5@cs.purdue.edu> <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> <1430B28B-A256-4B74-877D-9533183DFA42@cs.purdue.edu> <20071219004406.mnemi5gnc4g4c80g@mail.elegosoft.com> Message-ID: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/~checkout~/cm3/www/installation-windows.html?rev=1.2;content-type=text%2Fhtml ?? Perhaps now that 5.5.0 bootstraps are available, the 5.2.6 instructions should be moved out. I'm also aware that the style is rather poor, and that I should have tried harder to integrate it into the existing document, and that I suck, etc..It is not linked to from download.html. Does anyone else think the formating is a little off regarding how the Windows distribution is two files right next to each other? The archives could of course be merged. Current linkers will not put symbols into files, but older ones will.. given their relative large size and small use though, separate symbols like this seems ok. Oh someone beat me to OS X 10.4 PowerPC. Maybe I should try 10.2? :) - Jay > Date: Wed, 19 Dec 2007 00:44:06 +0100> From: wagner at elegosoft.com> To: hosking at cs.purdue.edu; m3devel at elegosoft.com> CC: m3-support at elegosoft.com; admins at elegosoft.com> Subject: Re: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/darwin> > Quoting Tony Hosking :> > > I have put installation archives for I386_DARWIN and PPC_DARWIN at> > ftp://ftp.cs.purdue.edu/pub/hosking/m3.> > Great. I've shipped all the archives available so far to our> web server at http://modula3.elegosoft.com/cm3/.> > I'm not sure if all the information on the download> page is correct, and I'm sure the documentation and instructions> provided are rather sparse. If anybody wants to improve that,> please don't hesitate to edit cm3/www/download.html; I can then> later ship the changes.> > Now it's time for bed again; thanks for all the help,> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. http://www.xbox.com/en-US/hardware/wheretobuy/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Thu Dec 20 04:22:04 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 19 Dec 2007 19:22:04 -0800 Subject: [M3devel] Unix signals and Modula-3... In-Reply-To: Your message of "Tue, 18 Dec 2007 22:30:01 EST." Message-ID: <200712200322.lBK3M4xS055247@camembert.async.caltech.edu> Tony Hosking writes: >The system threads pthread implementation uses a signal and a >semaphore to stop/start threads for GC, Other than that, I don't >believe signals are being used anywhere else in the run-time system. > >Also, I should point out that there may be value in retaining the >current user-level threads implementation for all targets (we still >need to fix some to use setcontext/getcontext instead of setjmp/ >getjmp), in which case the same issue applies. I wonder if it makes >sense to implement a variant of waitpid inside the threads >implementation to do the right thing. We could use a signal there to >catch SIGCHLD appropriately in the ThreadPosix implementation and >leave it alone with ThreadPThread. > >What do you think? Oh, yes I wasn't suggesting dropping the user-level threads. I was just thinking that if most targets can use system threads, maybe it's OK if there's a 0.1 second delay on the others. After all, most people don't seem to have noticed that it's been this way all these years :) (Although it does get more obvious now that computers are faster and compile times aren't getting shorter on those targets.) I also think user-level threads can turn out to be important when system threads perform poorly for whatever reason. I know this was a big problem for some people I knew who were working with threads in Java, that when they used system threads for code that did very little work and lots of threadswitching, user-level threads were an order of magnitude faster. I suppose that ThreadPosix also uses signals to know when to switch contexts? Since it already deals with signals it shouldn't be too difficult to incorporate the waitpid business. But yes, it seems to me that since the implementation of Process.Wait's waiting for the child to exit depends on what kind of threading library is being used, that part of it ought/could conveniently be part of the threading library's interface. Mika From mika at async.caltech.edu Fri Dec 21 05:42:04 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 20 Dec 2007 20:42:04 -0800 Subject: [M3devel] Missing packages? Message-ID: <200712210442.lBL4g4kK011539@camembert.async.caltech.edu> Hi Modula-3 people. I was working on some code the other night and needed a small persistent table data structure, and I seemed to remember that there was a package called "stabletable" that had exactly the features I needed: a simple, persistent implementation of the Modula-3 generic tables. Only problem was ... I couldn't find it anywhere! I remembered it existed, but nowhere to be found. Well, I finally tracked it down on an m3browser running at the University of Tampere (Finland), cut-and-pasted the .ig and .mg and compiled the thing. A few questions: 1. This package is dated 1994. Is this after CM3 split from SRC M3? Is that why it's not in CM3? 2. Should I add it to CM3? 3. Are there other packages of similar status? Mika From jayk123 at hotmail.com Fri Dec 21 07:28:39 2007 From: jayk123 at hotmail.com (Jay) Date: Fri, 21 Dec 2007 06:28:39 +0000 Subject: [M3devel] Missing packages? In-Reply-To: <200712210442.lBL4g4kK011539@camembert.async.caltech.edu> References: <200712210442.lBL4g4kK011539@camembert.async.caltech.edu> Message-ID: DEC SRC M3 3.6 was released circa 1996, maybe 1995. m3-db\stable ?m3-db\stablegen (related) ? C:\dev2\cm3\doc\help\bib.html(578):
  • Allan Heydon,C:\dev2\cm3\doc\help\bib.html(579):Stabletable: An Example Client of the SmallDB Interface,C:\dev2\cm3\doc\help\bib.html(597):gzipped tar archive I think this is it. The links are dead. I have some/all of the 3.6 release archives if needed (a hard drive is in questionable state, but I definitely have boot-linuxelf and m3.tar.bz2, m3cc.tar.bz2 (I "recode" all .gzs as smaller .bz2...)) - Jay > To: m3devel at elegosoft.com> Date: Thu, 20 Dec 2007 20:42:04 -0800> From: mika at async.caltech.edu> Subject: [M3devel] Missing packages?> > Hi Modula-3 people.> > I was working on some code the other night and needed a small> persistent table data structure, and I seemed to remember that there> was a package called "stabletable" that had exactly the features I> needed: a simple, persistent implementation of the Modula-3 generic> tables.> > Only problem was ... I couldn't find it anywhere! I remembered it existed,> but nowhere to be found. Well, I finally tracked it down on an m3browser> running at the University of Tampere (Finland), cut-and-pasted the .ig and> .mg and compiled the thing.> > A few questions:> > 1. This package is dated 1994. Is this after CM3 split from SRC M3? Is> that why it's not in CM3?> 2. Should I add it to CM3?> 3. Are there other packages of similar status?> > Mika _________________________________________________________________ i?m is proud to present Cause Effect, a series about real people making a difference. http://im.live.com/Messenger/IM/MTV/?source=text_Cause_Effect -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Dec 21 09:51:02 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 21 Dec 2007 09:51:02 +0100 Subject: [M3devel] Missing packages? In-Reply-To: <200712210442.lBL4g4kK011539@camembert.async.caltech.edu> References: <200712210442.lBL4g4kK011539@camembert.async.caltech.edu> Message-ID: <20071221095102.0zpsxh3s2s44cs4g@mail.elegosoft.com> Quoting Mika Nystrom : > Hi Modula-3 people. > > I was working on some code the other night and needed a small > persistent table data structure, and I seemed to remember that there > was a package called "stabletable" that had exactly the features I > needed: a simple, persistent implementation of the Modula-3 generic > tables. > > Only problem was ... I couldn't find it anywhere! I remembered it existed, > but nowhere to be found. Well, I finally tracked it down on an m3browser > running at the University of Tampere (Finland), cut-and-pasted the .ig and > .mg and compiled the thing. Well, there is stable and stablegen, as Jay already pointed out. These can be used to generate persistent versions of almost any data structure. > A few questions: > > 1. This package is dated 1994. Is this after CM3 split from SRC M3? Is > that why it's not in CM3? stabletable may have been an predecessor of the more general stable package. I also found the attached documentation, which seems to be missing on our web site. I rather think that Critical Mass people have cleaned up the set of packages a bit. > 2. Should I add it to CM3? If you think it is useful in addition to stable and stablegen, there's no reason why not to add it. Put it into m3-db. If it's more or less code duplication, don't do it. > 3. Are there other packages of similar status? I cannot answer this question. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Fri Dec 21 13:22:40 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 21 Dec 2007 13:22:40 +0100 Subject: [M3devel] endless exception loop on FreeBSD Message-ID: <20071221132240.uu5elpnqwwc4408s@mail.elegosoft.com> I'm trying to add pthread support to the FreeBSD4 platform. My first tentative additions now lead to endless exception loops once any error is encountered until the stack overflows. Does anybody know what's wrong here? I'm not aware that I have changed anything in this area. [...] #9 0x081dfe96 in RTHooks__Raise (M3_AJWxb1_ex=0x8272840, M3_AJWxb1_arg=0x1d, M3_AJWxb1_module=0x8273080, M3_AcxOUs_line=14) at RTHooks.m3:79 #10 0x081e00df in RuntimeError () at RuntimeError.m3:14 #11 0x081ef680 in RTException__DefaultBackstop (M3_Cblw37_a=0xbfbfe1a0, M3_AicXUJ_raises=0 '\0') at RTException.m3:33 #12 0x081ef654 in RTException__InvokeBackstop (M3_Cblw37_a=0xbfbfe1a0, M3_AicXUJ_raises=0 '\0') at RTException.m3:25 #13 0x081f903f in RTException__Raise (M3_Cblw37_act=0xbfbfe1a0) at RTExFrame.m3:29 #14 0x081dfe96 in RTHooks__Raise (M3_AJWxb1_ex=0x8267b00, M3_AJWxb1_arg=0x2839385c, M3_AJWxb1_module=0x8268480, M3_AcxOUs_line=50) at RTHooks.m3:79 #15 0x081b9dbe in OSErrorPosix__Raise0 (M3_AcxOUs_errno=2) ---Type to continue, or q to quit--- at OSErrorPosix.m3:50 #16 0x081bb0c4 in FSPosix__Fail (M3_Bd56fi_p=0x82276c0, M3_DIYzyQ_f=0x82276c8) at FSPosix.m3:356 #17 0x081bade2 in FS__Status (M3_Bd56fi_pn=0x82276c0, M3_CQo0YO__result=0xbfbfe318) at FSPosix.m3:323 #18 0x081aa2e4 in M3File__IsReadable (M3_Bd56fi_path=0x82276c0) at M3File.m3:182 #19 0x08088a3e in MxConfig__TryConfig (M3_Bd56fi_a=0x82276c0, M3_Bd56fi_b=0x0, M3_Bd56fi_c=0x0) at MxConfig.m3:94 #20 0x08088635 in MxConfig__FindConfig () at MxConfig.m3:43 #21 0x0808841b in MxConfig__FindFile () at MxConfig.m3:17 #22 0x0807301d in Main__DoIt () at Main.m3:31 #23 0x080739bc in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:193 #24 0x081ee9a2 in RTLinker__RunMainBody (M3_DjPxE3_m=0x8223860) at RTLinker.m3:399 #25 0x081edecd in RTLinker__AddUnitI (M3_DjPxE3_m=0x8223860) at RTLinker.m3:113 #26 0x081edf54 in RTLinker__AddUnit (M3_DjPxE5_b=0x80739a7) at RTLinker.m3:122 #27 0x08049b99 in main (argc=1, argv=0xbfbfe5f4, envp=0xbfbfe5fc) at _m3main.mc:4 -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Fri Dec 21 17:04:30 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 21 Dec 2007 11:04:30 -0500 Subject: [M3devel] endless exception loop on FreeBSD In-Reply-To: <20071221132240.uu5elpnqwwc4408s@mail.elegosoft.com> References: <20071221132240.uu5elpnqwwc4408s@mail.elegosoft.com> Message-ID: <592A55CF-8680-499A-9911-F461B7562879@cs.purdue.edu> Hmm. It doesn't ring any bells for me. On Dec 21, 2007, at 7:22 AM, Olaf Wagner wrote: > I'm trying to add pthread support to the FreeBSD4 platform. > My first tentative additions now lead to endless exception loops > once any error is encountered until the stack overflows. > > Does anybody know what's wrong here? I'm not aware that I have > changed anything in this area. > > [...] > #9 0x081dfe96 in RTHooks__Raise (M3_AJWxb1_ex=0x8272840, > M3_AJWxb1_arg=0x1d, > M3_AJWxb1_module=0x8273080, M3_AcxOUs_line=14) at RTHooks.m3:79 > #10 0x081e00df in RuntimeError () at RuntimeError.m3:14 > #11 0x081ef680 in RTException__DefaultBackstop > (M3_Cblw37_a=0xbfbfe1a0, > M3_AicXUJ_raises=0 '\0') at RTException.m3:33 > #12 0x081ef654 in RTException__InvokeBackstop (M3_Cblw37_a=0xbfbfe1a0, > M3_AicXUJ_raises=0 '\0') at RTException.m3:25 > #13 0x081f903f in RTException__Raise (M3_Cblw37_act=0xbfbfe1a0) > at RTExFrame.m3:29 > #14 0x081dfe96 in RTHooks__Raise (M3_AJWxb1_ex=0x8267b00, > M3_AJWxb1_arg=0x2839385c, M3_AJWxb1_module=0x8268480, > M3_AcxOUs_line=50) > at RTHooks.m3:79 > #15 0x081b9dbe in OSErrorPosix__Raise0 (M3_AcxOUs_errno=2) > ---Type to continue, or q to quit--- > at OSErrorPosix.m3:50 > #16 0x081bb0c4 in FSPosix__Fail (M3_Bd56fi_p=0x82276c0, > M3_DIYzyQ_f=0x82276c8) > at FSPosix.m3:356 > #17 0x081bade2 in FS__Status (M3_Bd56fi_pn=0x82276c0, > M3_CQo0YO__result=0xbfbfe318) at FSPosix.m3:323 > #18 0x081aa2e4 in M3File__IsReadable (M3_Bd56fi_path=0x82276c0) > at M3File.m3:182 > #19 0x08088a3e in MxConfig__TryConfig (M3_Bd56fi_a=0x82276c0, > M3_Bd56fi_b=0x0, > M3_Bd56fi_c=0x0) at MxConfig.m3:94 > #20 0x08088635 in MxConfig__FindConfig () at MxConfig.m3:43 > #21 0x0808841b in MxConfig__FindFile () at MxConfig.m3:17 > #22 0x0807301d in Main__DoIt () at Main.m3:31 > #23 0x080739bc in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:193 > #24 0x081ee9a2 in RTLinker__RunMainBody (M3_DjPxE3_m=0x8223860) > at RTLinker.m3:399 > #25 0x081edecd in RTLinker__AddUnitI (M3_DjPxE3_m=0x8223860) at > RTLinker.m3:113 > #26 0x081edf54 in RTLinker__AddUnit (M3_DjPxE5_b=0x80739a7) at > RTLinker.m3:122 > #27 0x08049b99 in main (argc=1, argv=0xbfbfe5f4, envp=0xbfbfe5fc) > at _m3main.mc:4 > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From rcoleburn at scires.com Fri Dec 21 18:23:30 2007 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 21 Dec 2007 12:23:30 -0500 Subject: [M3devel] Missing packages? In-Reply-To: <200712210442.lBL4g4kK011539@camembert.async.caltech.edu> References: <200712210442.lBL4g4kK011539@camembert.async.caltech.edu> Message-ID: <476BB045.1E75.00D7.1@scires.com> Mika et al: I believe you are referring to the generic called "Stable". I have the sources for this from the cm3 v4.1 days. Olaf should have them also. I believe they fall under the same copyright/use rules as the rest of cm3. I also wrote something a long time back that may be of interest to you. I've attached the generic interfaces below for your reference. Note that they are in MS-DOS text format, not Unix-style text format. These two generics are very similar, but read the up-front comments to see the differences and decide which may be right for you. If you are interested, I should be able to provide the full sources to you. Let me know. Regards, Randy Coleburn >>> Mika Nystrom 12/20/2007 11:42 PM >>> Hi Modula-3 people. I was working on some code the other night and needed a small persistent table data structure, and I seemed to remember that there was a package called "stabletable" that had exactly the features I needed: a simple, persistent implementation of the Modula-3 generic tables. Only problem was ... I couldn't find it anywhere! I remembered it existed, but nowhere to be found. Well, I finally tracked it down on an m3browser running at the University of Tampere (Finland), cut-and-pasted the .ig and .mg and compiled the thing. A few questions: 1. This package is dated 1994. Is this after CM3 split from SRC M3? Is that why it's not in CM3? 2. Should I add it to CM3? 3. Are there other packages of similar status? Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ObjectDatabase2.ig Type: application/octet-stream Size: 19563 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ObjectDatabase.ig Type: application/octet-stream Size: 20395 bytes Desc: not available URL: From hosking at cs.purdue.edu Sat Dec 22 23:30:29 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 22 Dec 2007 17:30:29 -0500 Subject: [M3devel] endless exception loop on FreeBSD In-Reply-To: <476D6E04.2000503@luthien.in-berlin.de> References: <20071221132240.uu5elpnqwwc4408s@mail.elegosoft.com> <592A55CF-8680-499A-9911-F461B7562879@cs.purdue.edu> <476D6E04.2000503@luthien.in-berlin.de> Message-ID: Any chance that the sigjmp buffers are differently-sized with the new libc? On Dec 22, 2007, at 3:05 PM, Olaf Wagner wrote: > Tony Hosking wrote: > >> Hmm. It doesn't ring any bells for me. >> >> On Dec 21, 2007, at 7:22 AM, Olaf Wagner wrote: >> >>> I'm trying to add pthread support to the FreeBSD4 platform. >>> My first tentative additions now lead to endless exception loops >>> once any error is encountered until the stack overflows. >>> >>> Does anybody know what's wrong here? I'm not aware that I have >>> changed anything in this area. >> > I seems that I have been linking against a non-reentrant libc. I > can now get a little > farther: > > % ./m3-sys/cm3/FreeBSD4/cm3 -help @M3debugthreads > Stopping from act=0x8a93500 > Stopping act=0x8a93b80 > Stopped act=0x8a93b80 > Stopped from act=0x8a93500 > Processing act=0x8a93500 > Processing act=0x8a93b80 > Starting from act=0x8a93500 > Starting act=0x8a93b80 > Started act=0x8a93b80 > Started from act=0x8a93500 > Stopping from act=0x8a93500 > Stopping act=0x8a93b80 > Stopped act=0x8a93b80 > Stopped from act=0x8a93500 > Processing act=0x8a93500 > Processing act=0x8a93b80 > Starting from act=0x8a93500 > Starting act=0x8a93b80 > Started act=0x8a93b80 > Started from act=0x8a93500 > CStatus failed with errno 2 > > > *** > *** runtime error: > *** Unhandled exception: OSError.E > *** file "../src/os/POSIX/OSErrorPosix.m3", line 50 > *** > > Abort trap (core dumped) > > This is the compiler trying to locate cm3.cfg at different locations. > It doesn't find it and an OSError.E is raised, which should get caught > in M3File.IsReadable, but isn't. So it seems exception handling is > broken as soon as I use system threads. Any ideas on this one? > > Olaf From wagner at elegosoft.com Sun Dec 23 16:36:40 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 23 Dec 2007 16:36:40 +0100 Subject: [M3devel] pthreads on FreeBSD, was: endless exception loop on FreeBSD In-Reply-To: <476D6E04.2000503@luthien.in-berlin.de> References: <20071221132240.uu5elpnqwwc4408s@mail.elegosoft.com> <592A55CF-8680-499A-9911-F461B7562879@cs.purdue.edu> <476D6E04.2000503@luthien.in-berlin.de> Message-ID: <20071223163640.3mk3dmc05c0gsgok@mail.elegosoft.com> >> On Dec 21, 2007, at 7:22 AM, Olaf Wagner wrote: >> >>> I'm trying to add pthread support to the FreeBSD4 platform. >>> My first tentative additions now lead to endless exception loops >>> once any error is encountered until the stack overflows. >>> >>> Does anybody know what's wrong here? I'm not aware that I have >>> changed anything in this area. >> > I seems that I have been linking against a non-reentrant libc. I can > now get a little > farther: > > % ./m3-sys/cm3/FreeBSD4/cm3 -help @M3debugthreads > Stopping from act=0x8a93500 > Stopping act=0x8a93b80 > Stopped act=0x8a93b80 > Stopped from act=0x8a93500 > Processing act=0x8a93500 > Processing act=0x8a93b80 > Starting from act=0x8a93500 > Starting act=0x8a93b80 > Started act=0x8a93b80 > Started from act=0x8a93500 > Stopping from act=0x8a93500 > Stopping act=0x8a93b80 > Stopped act=0x8a93b80 > Stopped from act=0x8a93500 > Processing act=0x8a93500 > Processing act=0x8a93b80 > Starting from act=0x8a93500 > Starting act=0x8a93b80 > Started act=0x8a93b80 > Started from act=0x8a93500 > CStatus failed with errno 2 > > > *** > *** runtime error: > *** Unhandled exception: OSError.E > *** file "../src/os/POSIX/OSErrorPosix.m3", line 50 > *** > > Abort trap (core dumped) > > This is the compiler trying to locate cm3.cfg at different locations. > It doesn't find it and an OSError.E is raised, which should get caught > in M3File.IsReadable, but isn't. So it seems exception handling is > broken as soon as I use system threads. Any ideas on this one? Some additional information: It is really only the PTHREAD setting in m3core/src/thread/m3makefile which makes exceptions fail. If I change it and compile everything again, I get this output from cm3: % ./m3-sys/cm3/FreeBSD4/cm3 -help @M3debugthreads DetermineContext: oldSP = 0xbfbfe74c modelSP: 0xbfbfe70c oldSP: 0xbfbfe74c frame size: 64 CStatus failed with errno 2 CStatus failed with errno 2 CStatus failed with errno 2 CStatus failed with errno 2 CStatus failed with errno 2 CStatus failed with errno 2 Critical Mass Modula-3 version d5.5.0 last updated: 2007-12-17 configuration: /usr/local/cm3/bin/cm3.cfg [...] So all OSError.E exceptions for stat failures are caught, and there are no thread switches at the start of the compiler; it only sets up the model frame for userlevel threads. In contrast, system level pthreads show much activity at the start (why?), and the first exception terminates the compiler. I still haven't got a good explanation for this. Unfortunately, the FreeBSD gdb debugger does not really seem to cope well with threaded programs... All interesting information always is unrecoverable. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sun Dec 23 16:57:29 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 23 Dec 2007 10:57:29 -0500 Subject: [M3devel] pthreads on FreeBSD, was: endless exception loop on FreeBSD In-Reply-To: <20071223163640.3mk3dmc05c0gsgok@mail.elegosoft.com> References: <20071221132240.uu5elpnqwwc4408s@mail.elegosoft.com> <592A55CF-8680-499A-9911-F461B7562879@cs.purdue.edu> <476D6E04.2000503@luthien.in-berlin.de> <20071223163640.3mk3dmc05c0gsgok@mail.elegosoft.com> Message-ID: Ah! Lights turning on in my head... It is probably the case that you have neglected to tell the compiler to avoid using global exception information. You need to set Global_handler_stack FALSE in m3middle/src/Target.m3 for the pthreads- based targets. On Dec 23, 2007, at 10:36 AM, Olaf Wagner wrote: >>> On Dec 21, 2007, at 7:22 AM, Olaf Wagner wrote: >>> >>>> I'm trying to add pthread support to the FreeBSD4 platform. >>>> My first tentative additions now lead to endless exception loops >>>> once any error is encountered until the stack overflows. >>>> >>>> Does anybody know what's wrong here? I'm not aware that I have >>>> changed anything in this area. >>> >> I seems that I have been linking against a non-reentrant libc. I can >> now get a little >> farther: >> >> % ./m3-sys/cm3/FreeBSD4/cm3 -help @M3debugthreads >> Stopping from act=0x8a93500 >> Stopping act=0x8a93b80 >> Stopped act=0x8a93b80 >> Stopped from act=0x8a93500 >> Processing act=0x8a93500 >> Processing act=0x8a93b80 >> Starting from act=0x8a93500 >> Starting act=0x8a93b80 >> Started act=0x8a93b80 >> Started from act=0x8a93500 >> Stopping from act=0x8a93500 >> Stopping act=0x8a93b80 >> Stopped act=0x8a93b80 >> Stopped from act=0x8a93500 >> Processing act=0x8a93500 >> Processing act=0x8a93b80 >> Starting from act=0x8a93500 >> Starting act=0x8a93b80 >> Started act=0x8a93b80 >> Started from act=0x8a93500 >> CStatus failed with errno 2 >> >> >> *** >> *** runtime error: >> *** Unhandled exception: OSError.E >> *** file "../src/os/POSIX/OSErrorPosix.m3", line 50 >> *** >> >> Abort trap (core dumped) >> >> This is the compiler trying to locate cm3.cfg at different locations. >> It doesn't find it and an OSError.E is raised, which should get >> caught >> in M3File.IsReadable, but isn't. So it seems exception handling is >> broken as soon as I use system threads. Any ideas on this one? > > Some additional information: > > It is really only the PTHREAD setting in m3core/src/thread/m3makefile > which makes exceptions fail. If I change it and compile everything > again, > I get this output from cm3: > > % ./m3-sys/cm3/FreeBSD4/cm3 -help @M3debugthreads > DetermineContext: oldSP = 0xbfbfe74c > modelSP: 0xbfbfe70c > oldSP: 0xbfbfe74c > frame size: 64 > CStatus failed with errno 2 > CStatus failed with errno 2 > CStatus failed with errno 2 > CStatus failed with errno 2 > CStatus failed with errno 2 > CStatus failed with errno 2 > Critical Mass Modula-3 version d5.5.0 > last updated: 2007-12-17 > configuration: /usr/local/cm3/bin/cm3.cfg > [...] > > So all OSError.E exceptions for stat failures are caught, and there > are no thread switches at the start of the compiler; it only sets > up the model frame for userlevel threads. > In contrast, system level pthreads show much activity at the start > (why?), and the first exception terminates the compiler. > > I still haven't got a good explanation for this. Unfortunately, > the FreeBSD gdb debugger does not really seem to cope well with > threaded > programs... All interesting information always is unrecoverable. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Dec 23 20:48:18 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 23 Dec 2007 20:48:18 +0100 Subject: [M3devel] pthreads on FreeBSD, was: endless exception loop on FreeBSD In-Reply-To: References: <20071221132240.uu5elpnqwwc4408s@mail.elegosoft.com> <592A55CF-8680-499A-9911-F461B7562879@cs.purdue.edu> <476D6E04.2000503@luthien.in-berlin.de> <20071223163640.3mk3dmc05c0gsgok@mail.elegosoft.com> Message-ID: <20071223204818.zqdh8gl77k4k4c0s@mail.elegosoft.com> Quoting Tony Hosking : > Ah! Lights turning on in my head... > > It is probably the case that you have neglected to tell the compiler to > avoid using global exception information. You need to set > Global_handler_stack FALSE in m3middle/src/Target.m3 for the > pthreads-based targets. Great! This seems to have done the trick. I've now been able to recompile the whole system and run mentor with the FreeBSD pthreads library. I'd never have found this setting, because it was nowhere near I expected the problem. Exception handling is one of the areas I was never familiar with in (C)M3. Probably I should learn to understand how the system works in this respect, too. Is there any documentation about the current state of things apart from the source code? Thanks for your help and the great whole pthreads contribution, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sun Dec 23 20:53:58 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 23 Dec 2007 14:53:58 -0500 Subject: [M3devel] pthreads on FreeBSD, was: endless exception loop on FreeBSD In-Reply-To: <20071223204818.zqdh8gl77k4k4c0s@mail.elegosoft.com> References: <20071221132240.uu5elpnqwwc4408s@mail.elegosoft.com> <592A55CF-8680-499A-9911-F461B7562879@cs.purdue.edu> <476D6E04.2000503@luthien.in-berlin.de> <20071223163640.3mk3dmc05c0gsgok@mail.elegosoft.com> <20071223204818.zqdh8gl77k4k4c0s@mail.elegosoft.com> Message-ID: <697B4834-D0F5-4A9E-8B87-76C92EC0BFA8@cs.purdue.edu> On Dec 23, 2007, at 2:48 PM, Olaf Wagner wrote: > Quoting Tony Hosking : > >> Ah! Lights turning on in my head... >> >> It is probably the case that you have neglected to tell the >> compiler to >> avoid using global exception information. You need to set >> Global_handler_stack FALSE in m3middle/src/Target.m3 for the >> pthreads-based targets. > > Great! This seems to have done the trick. I've now been able to > recompile the whole system and run mentor with the FreeBSD pthreads > library. I'd never have found this setting, because it was nowhere > near I expected the problem. Excellent. > Exception handling is one of the areas I was never familiar with > in (C)M3. Probably I should learn to understand how the system > works in this respect, too. Is there any documentation about > the current state of things apart from the source code? I'm afraid I don't think there is much in the way of documentation other than the code. > Thanks for your help and the great whole pthreads contribution, Let me know if you have any other problems. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From jayk123 at hotmail.com Mon Dec 24 14:52:03 2007 From: jayk123 at hotmail.com (Jay) Date: Mon, 24 Dec 2007 13:52:03 +0000 Subject: [M3devel] relocation out of range on PPC_LINUX (5.2.6) Message-ID: (My goodness Linux continues to disappoint...not because of this Modula-3 stuff per se, though cminstall kind of stinks vs. somethhing more autoconf-ish..) Anyway: Using the 5.2.6 distribution on Yellow Dog Linux 4.1 (unpatched, I can't quite figure out how to get patches... one reason Linux disappoints, at the same time I can't patch the Linux system, a Windows system rebooted itself at 3am to take an update, which I also don't like..) [jay at localhost t]$ rm -rf PPC_LINUX [jay at localhost t]$ ls -Rl .: total 4 -rw-rw-r-- 1 jay jay 72 Dec 24 04:45 Hello.m3 [jay at localhost t]$ cat Hello.m3 MODULE Hello EXPORTS Main; IMPORT IO; BEGIN IO.Put("hello"); END Hello. [jay at localhost t]$ cm3 -version Critical Mass Modula-3 version 5.2.6 last updated: 2003-06-27 configuration: /usr/local/cm3/bin/cm3.cfg [jay at localhost t]$ which cm3 /usr/local/cm3/bin/cm3 [jay at localhost t]$ cm3 new source -> compiling Hello.m3 -> linking prog [jay at localhost t]$ PPC_LINUX/prog PPC_LINUX/prog: error while loading shared libraries: /usr/local/cm3/pkg/m3core/PPC_LINUX/libm3core.so.5: R_PPC_REL24 relocation at 0x0fe1220c for symbol `memset' out of range [jay at localhost t]$ ldd PPC_LINUX/prog libm3.so.5 => /usr/local/cm3/pkg/libm3/PPC_LINUX/libm3.so.5 (0x0fe94000) libm3core.so.5 => /usr/local/cm3/pkg/m3core/PPC_LINUX/libm3core.so.5 (0x0fdde000) libm3gcdefs.so.5 => /usr/local/cm3/lib/libm3gcdefs.so.5 (0x0fdbb000) libm.so.6 => /lib/tls/libm.so.6 (0x30015000) libc.so.6 => /lib/tls/libc.so.6 (0x3009b000) /lib/ld.so.1 (0x0ffd0000) I won't likely have a computer on which to investigate this over the next week. (Already bringing two. :) ) Building standalone works..just hack m3_link in cm3.cfg to say shared = "". cm3 is already standalone, but in case other executables are built and used.. So the question then becomes: Anyone know what causes this? How to avoid the binaries I'm going to produce having the same problem, perhaps on another machine and not mine? The error seems almost self explanatory. m3core.so.5 starts at 0x0fdde000 and extends to..? presumably something under 0x0fe1220c. Btw, I put in the request to fix alma mater mail forwarding, waiting for them now. - Jay _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007 From jayk123 at hotmail.com Mon Dec 24 19:12:07 2007 From: jayk123 at hotmail.com (Jay) Date: Mon, 24 Dec 2007 18:12:07 +0000 Subject: [M3devel] relocation out of range on PPC_LINUX (5.2.6) In-Reply-To: References: Message-ID: Lots of segfaults once the new cm3cg is shipped.. pretty much for every file.. next week.. - Jay ---------------------------------------- > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Date: Mon, 24 Dec 2007 13:52:03 +0000 > Subject: [M3devel] relocation out of range on PPC_LINUX (5.2.6) > > > (My goodness Linux continues to disappoint...not because > of this Modula-3 stuff per se, though cminstall kind of stinks > vs. somethhing more autoconf-ish..) > > Anyway: > > Using the 5.2.6 distribution on Yellow Dog Linux 4.1 (unpatched, I can't > quite figure out how to get patches... one reason Linux disappoints, > at the same time I can't patch the Linux system, a Windows system > rebooted itself at 3am to take an update, which I also don't like..) > > [jay at localhost t]$ rm -rf PPC_LINUX > > [jay at localhost t]$ ls -Rl > .: > total 4 > -rw-rw-r-- 1 jay jay 72 Dec 24 04:45 Hello.m3 > > [jay at localhost t]$ cat Hello.m3 > > MODULE Hello EXPORTS Main; > IMPORT IO; > BEGIN > IO.Put("hello"); > END Hello. > > [jay at localhost t]$ cm3 -version > Critical Mass Modula-3 version 5.2.6 > last updated: 2003-06-27 > configuration: /usr/local/cm3/bin/cm3.cfg > > [jay at localhost t]$ which cm3 > /usr/local/cm3/bin/cm3 > > [jay at localhost t]$ cm3 > new source -> compiling Hello.m3 > -> linking prog > > [jay at localhost t]$ PPC_LINUX/prog > PPC_LINUX/prog: error while loading shared libraries: /usr/local/cm3/pkg/m3core/PPC_LINUX/libm3core.so.5: R_PPC_REL24 relocation at 0x0fe1220c for symbol `memset' out of range > [jay at localhost t]$ ldd PPC_LINUX/prog > libm3.so.5 => /usr/local/cm3/pkg/libm3/PPC_LINUX/libm3.so.5 (0x0fe94000) > libm3core.so.5 => /usr/local/cm3/pkg/m3core/PPC_LINUX/libm3core.so.5 (0x0fdde000) > libm3gcdefs.so.5 => /usr/local/cm3/lib/libm3gcdefs.so.5 (0x0fdbb000) > libm.so.6 => /lib/tls/libm.so.6 (0x30015000) > libc.so.6 => /lib/tls/libc.so.6 (0x3009b000) > /lib/ld.so.1 (0x0ffd0000) > > > I won't likely have a computer on which to investigate this over the next week. > (Already bringing two. :) ) > > Building standalone works..just hack m3_link in cm3.cfg to say shared = "". > cm3 is already standalone, but in case other executables are built and used.. > > > So the question then becomes: > Anyone know what causes this? > How to avoid the binaries I'm going to produce having the same problem, > perhaps on another machine and not mine? > > > The error seems almost self explanatory. > m3core.so.5 starts at 0x0fdde000 and extends to..? > presumably something under 0x0fe1220c. > > Btw, I put in the request to fix alma mater mail forwarding, waiting for them now. > > - Jay > > _________________________________________________________________ > Share life as it happens with the new Windows Live. > http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007 _________________________________________________________________ The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. http://www.xbox.com/en-US/hardware/wheretobuy/ From jayk123 at hotmail.com Mon Dec 24 19:42:02 2007 From: jayk123 at hotmail.com (Jay) Date: Mon, 24 Dec 2007 18:42:02 +0000 Subject: [M3devel] relocation out of range on PPC_LINUX (5.2.6) In-Reply-To: References: Message-ID: Wow so I built my own svn and almost the same error: [root at localhost subversion-1.4.6]# svn svn: error while loading shared libraries: /usr/local/lib/libsvn_ra_dav-1.so.0: R_PPC_REL24 relocation at 0x0fdb5594 for symbol `strcmp' out of range maybe time to try 5.2 or OpenSuse or Fedora.. Will research more.. -Jay ---------------------------------------- > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: RE: [M3devel] relocation out of range on PPC_LINUX (5.2.6) > Date: Mon, 24 Dec 2007 18:12:07 +0000 > > > Lots of segfaults once the new cm3cg is shipped.. pretty much for every file.. next week.. > > - Jay > > ---------------------------------------- >> From: jayk123 at hotmail.com >> To: m3devel at elegosoft.com >> Date: Mon, 24 Dec 2007 13:52:03 +0000 >> Subject: [M3devel] relocation out of range on PPC_LINUX (5.2.6) >> >> >> (My goodness Linux continues to disappoint...not because >> of this Modula-3 stuff per se, though cminstall kind of stinks >> vs. somethhing more autoconf-ish..) >> >> Anyway: >> >> Using the 5.2.6 distribution on Yellow Dog Linux 4.1 (unpatched, I can't >> quite figure out how to get patches... one reason Linux disappoints, >> at the same time I can't patch the Linux system, a Windows system >> rebooted itself at 3am to take an update, which I also don't like..) >> >> [jay at localhost t]$ rm -rf PPC_LINUX >> >> [jay at localhost t]$ ls -Rl >> .: >> total 4 >> -rw-rw-r-- 1 jay jay 72 Dec 24 04:45 Hello.m3 >> >> [jay at localhost t]$ cat Hello.m3 >> >> MODULE Hello EXPORTS Main; >> IMPORT IO; >> BEGIN >> IO.Put("hello"); >> END Hello. >> >> [jay at localhost t]$ cm3 -version >> Critical Mass Modula-3 version 5.2.6 >> last updated: 2003-06-27 >> configuration: /usr/local/cm3/bin/cm3.cfg >> >> [jay at localhost t]$ which cm3 >> /usr/local/cm3/bin/cm3 >> >> [jay at localhost t]$ cm3 >> new source -> compiling Hello.m3 >> -> linking prog >> >> [jay at localhost t]$ PPC_LINUX/prog >> PPC_LINUX/prog: error while loading shared libraries: /usr/local/cm3/pkg/m3core/PPC_LINUX/libm3core.so.5: R_PPC_REL24 relocation at 0x0fe1220c for symbol `memset' out of range >> [jay at localhost t]$ ldd PPC_LINUX/prog >> libm3.so.5 => /usr/local/cm3/pkg/libm3/PPC_LINUX/libm3.so.5 (0x0fe94000) >> libm3core.so.5 => /usr/local/cm3/pkg/m3core/PPC_LINUX/libm3core.so.5 (0x0fdde000) >> libm3gcdefs.so.5 => /usr/local/cm3/lib/libm3gcdefs.so.5 (0x0fdbb000) >> libm.so.6 => /lib/tls/libm.so.6 (0x30015000) >> libc.so.6 => /lib/tls/libc.so.6 (0x3009b000) >> /lib/ld.so.1 (0x0ffd0000) >> >> >> I won't likely have a computer on which to investigate this over the next week. >> (Already bringing two. :) ) >> >> Building standalone works..just hack m3_link in cm3.cfg to say shared = "". >> cm3 is already standalone, but in case other executables are built and used.. >> >> >> So the question then becomes: >> Anyone know what causes this? >> How to avoid the binaries I'm going to produce having the same problem, >> perhaps on another machine and not mine? >> >> >> The error seems almost self explanatory. >> m3core.so.5 starts at 0x0fdde000 and extends to..? >> presumably something under 0x0fe1220c. >> >> Btw, I put in the request to fix alma mater mail forwarding, waiting for them now. >> >> - Jay >> >> _________________________________________________________________ >> Share life as it happens with the new Windows Live. >> http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007 > > _________________________________________________________________ > The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. > http://www.xbox.com/en-US/hardware/wheretobuy/ _________________________________________________________________ The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. http://www.xbox.com/en-US/hardware/wheretobuy/ From jayk123 at hotmail.com Mon Dec 24 20:10:19 2007 From: jayk123 at hotmail.com (Jay) Date: Mon, 24 Dec 2007 19:10:19 +0000 Subject: [M3devel] relocation out of range on PPC_LINUX (5.2.6) In-Reply-To: References: Message-ID: "research" -- "search the web" configure --with-pic and/or --disable-multilibs sound promsing *-darwin use --disable-multi on the other hand, the thread is six years old, you'd think it'd just work by now.. next week.. - Jay ---------------------------------------- > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: RE: [M3devel] relocation out of range on PPC_LINUX (5.2.6) > Date: Mon, 24 Dec 2007 18:42:02 +0000 > > > Wow so I built my own svn and almost the same error: > > [root at localhost subversion-1.4.6]# svn > svn: error while loading shared libraries: /usr/local/lib/libsvn_ra_dav-1.so.0: R_PPC_REL24 relocation at 0x0fdb5594 for symbol `strcmp' out of range > > maybe time to try 5.2 or OpenSuse or Fedora.. > > Will research more.. > > -Jay > ---------------------------------------- >> From: jayk123 at hotmail.com >> To: m3devel at elegosoft.com >> Subject: RE: [M3devel] relocation out of range on PPC_LINUX (5.2.6) >> Date: Mon, 24 Dec 2007 18:12:07 +0000 >> >> >> Lots of segfaults once the new cm3cg is shipped.. pretty much for every file.. next week.. >> >> - Jay >> >> ---------------------------------------- >>> From: jayk123 at hotmail.com >>> To: m3devel at elegosoft.com >>> Date: Mon, 24 Dec 2007 13:52:03 +0000 >>> Subject: [M3devel] relocation out of range on PPC_LINUX (5.2.6) >>> >>> >>> (My goodness Linux continues to disappoint...not because >>> of this Modula-3 stuff per se, though cminstall kind of stinks >>> vs. somethhing more autoconf-ish..) >>> >>> Anyway: >>> >>> Using the 5.2.6 distribution on Yellow Dog Linux 4.1 (unpatched, I can't >>> quite figure out how to get patches... one reason Linux disappoints, >>> at the same time I can't patch the Linux system, a Windows system >>> rebooted itself at 3am to take an update, which I also don't like..) >>> >>> [jay at localhost t]$ rm -rf PPC_LINUX >>> >>> [jay at localhost t]$ ls -Rl >>> .: >>> total 4 >>> -rw-rw-r-- 1 jay jay 72 Dec 24 04:45 Hello.m3 >>> >>> [jay at localhost t]$ cat Hello.m3 >>> >>> MODULE Hello EXPORTS Main; >>> IMPORT IO; >>> BEGIN >>> IO.Put("hello"); >>> END Hello. >>> >>> [jay at localhost t]$ cm3 -version >>> Critical Mass Modula-3 version 5.2.6 >>> last updated: 2003-06-27 >>> configuration: /usr/local/cm3/bin/cm3.cfg >>> >>> [jay at localhost t]$ which cm3 >>> /usr/local/cm3/bin/cm3 >>> >>> [jay at localhost t]$ cm3 >>> new source -> compiling Hello.m3 >>> -> linking prog >>> >>> [jay at localhost t]$ PPC_LINUX/prog >>> PPC_LINUX/prog: error while loading shared libraries: /usr/local/cm3/pkg/m3core/PPC_LINUX/libm3core.so.5: R_PPC_REL24 relocation at 0x0fe1220c for symbol `memset' out of range >>> [jay at localhost t]$ ldd PPC_LINUX/prog >>> libm3.so.5 => /usr/local/cm3/pkg/libm3/PPC_LINUX/libm3.so.5 (0x0fe94000) >>> libm3core.so.5 => /usr/local/cm3/pkg/m3core/PPC_LINUX/libm3core.so.5 (0x0fdde000) >>> libm3gcdefs.so.5 => /usr/local/cm3/lib/libm3gcdefs.so.5 (0x0fdbb000) >>> libm.so.6 => /lib/tls/libm.so.6 (0x30015000) >>> libc.so.6 => /lib/tls/libc.so.6 (0x3009b000) >>> /lib/ld.so.1 (0x0ffd0000) >>> >>> >>> I won't likely have a computer on which to investigate this over the next week. >>> (Already bringing two. :) ) >>> >>> Building standalone works..just hack m3_link in cm3.cfg to say shared = "". >>> cm3 is already standalone, but in case other executables are built and used.. >>> >>> >>> So the question then becomes: >>> Anyone know what causes this? >>> How to avoid the binaries I'm going to produce having the same problem, >>> perhaps on another machine and not mine? >>> >>> >>> The error seems almost self explanatory. >>> m3core.so.5 starts at 0x0fdde000 and extends to..? >>> presumably something under 0x0fe1220c. >>> >>> Btw, I put in the request to fix alma mater mail forwarding, waiting for them now. >>> >>> - Jay >>> >>> _________________________________________________________________ >>> Share life as it happens with the new Windows Live. >>> http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007 >> >> _________________________________________________________________ >> The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. >> http://www.xbox.com/en-US/hardware/wheretobuy/ > > _________________________________________________________________ > The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. > http://www.xbox.com/en-US/hardware/wheretobuy/ _________________________________________________________________ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_122007 From jayk123 at hotmail.com Tue Dec 25 13:09:31 2007 From: jayk123 at hotmail.com (Jay) Date: Tue, 25 Dec 2007 12:09:31 +0000 Subject: [M3devel] PPC_DARWIN problems, at least config/5.2.6, maybe all moot Message-ID: PPC_DARWIN also has problems...at least in the config. If you take the 5.2.6 archive, install to /dev2/cm3, accept the defaults, claim all the missing unused libs are in /usr/lib (opengl, postgres, x11) you end up with: jbook:/dev2/j/m3 jay$ cat Hello.m3 MODULE Hello EXPORTS Main; IMPORT IO; BEGIN IO.Put("Hello\n"); END Hello. jbook:/dev2/j/m3 jay$ uname -a Darwin jbook 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc jbook:/dev2/j/m3 jay$ cm3 -version Critical Mass Modula-3 version 5.2.6 last updated: 2003-06-27 configuration: /cm3/bin/cm3.cfg jbook:/dev2/j/m3 jay$ cm3 new source -> compiling Hello.m3 -> linking prog jbook:/dev2/j/m3 jay$ PPC_DARWIN/prog dyld: Library not loaded: /var/tmp/cm3/lib/libm3.5.2.dylib Referenced from: /dev2/j/m3/PPC_DARWIN/prog Reason: image not found Trace/BPT trap jbook:/dev2/j/m3 jay$ otool -L PPC_DARWIN/prog PPC_DARWIN/prog: /var/tmp/cm3/lib/libm3.5.2.dylib (compatibility version 5.0.0, current version 5.2.0) /Users/wagner/local/cm3/lib/libm3core.5.2.dylib (compatibility version 5.0.0, current version 5.2.0) /Users/wagner/local/cm3/lib/libm3gcdefs.5.2.dylib (compatibility version 5.0.0, current version 5.2.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.10) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) jbook:/dev2/j/m3 jay$ ls -l PPC_DARWIN/prog -rwxr-xr-x 1 jay admin 20264 Dec 25 04:43 PPC_DARWIN/prog At the temporary cost of giving up dynamic linking, you can fix this by removing M3_SPLIT_LIBNAMES_IF_SHARED and/or M3_SPLIT_LIBNAMES from cm3.cfg, yielding: jbook:/dev2/j/m3 jay$ otool -L PPC_DARWIN/prog PPC_DARWIN/prog: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.10) jbook:/dev2/j/m3 jay$ ls -l PPC_DARWIN/prog -rwxr-xr-x 1 jay admin 1388380 Dec 25 04:48 PPC_DARWIN/prog jbook:/dev2/j/m3 jay$ PPC_DARWIN/prog Hello I will fix the checked in config file...even though it varies a bunch from the 5.2.6 distributed config, it results in the same. And, um, does everyone understand what I did with Win32 and making cminstall obsolete? Ok to do the same on Mac OS X? You know, it's running things out of the path and/or finding them in their "very standard" locations. In fact, you can hard code full paths and be ok. That is, instead of asking the user where their compiler is, hardcoding any of cc, gcc, /usr/bin/cc, /usr/bin/gcc all work fine. Asking them where ar/ranlib are, similar, though the docs say that libtool replaced those, and ar/ranlib vs. libtool is one way in which the checked in config and the 5.2.6 distribution's config vary. I'll try for libtool. The only thing the user really needs to decide is where to install to, and the cfg file can discover their choice without any editing. INSTALL_ROOT = path() & "/.." BIN_INSTALL = path() % executables In terms of wanting to provide some configurable redirection, well, I think an advanced user can manage.. An indirect SYSTEM_CC = "cc" can be left, I guess. You know, I dare say, that platforms have been reduced and converged enough such that..you can get rid of Quake and move it into cm3. Um.. do any of the Unix platforms support other than gcc? Other than GNU ld? Ok, Apple ld is not GNU ld. (Geez, it is just me or is Apple an incredible hodgepodge mess these days? I mean both in terms of their "system architecture" and their tools. The "system architecture" reveals bunches of similar redundant subsystems. Try reading through man ld, man ranlib, just try to understand which flag goes with which mode, which flags are for compatibility with which OS version, and which of the compatibility flags is either ignored or does something useful... and should I say -lGL or -framework OpenGL??) That I don't haven't adjusted to Modula-3 and don't mind/prefer writing Quake instead. :) Some bootstrap was provided. I should look at it, and its config. Otherwise..I'll look into what it takes to build it all and with dynamic linking. Perhaps the bootstrap is just fine. But the checked in config is not. - Jay _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Dec 25 17:02:59 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 25 Dec 2007 11:02:59 -0500 Subject: [M3devel] PPC_DARWIN problems, at least config/5.2.6, maybe all moot In-Reply-To: References: Message-ID: <5EB28A70-CCEC-4855-B714-F0CE03E6DCC6@cs.purdue.edu> On Dec 25, 2007, at 7:09 AM, Jay wrote: > PPC_DARWIN also has problems...at least in the config. This is the cm3.cfg I use for PPC_DARWIN and it works fine for me. Notice that it installs into /usr/local/cm3. -------------- next part -------------- A non-text attachment was scrubbed... Name: cm3.cfg Type: application/octet-stream Size: 12662 bytes Desc: not available URL: -------------- next part -------------- > > > > If you take the 5.2.6 archive, install to /dev2/cm3, accept the > defaults, > claim all the missing unused libs are in /usr/lib (opengl, > postgres, x11) > > > you end up with: > > > jbook:/dev2/j/m3 jay$ cat Hello.m3 > > > MODULE Hello EXPORTS Main; > IMPORT IO; > BEGIN > IO.Put("Hello\n"); > END Hello. > > > jbook:/dev2/j/m3 jay$ uname -a > Darwin jbook 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 > 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh > powerpc > > > jbook:/dev2/j/m3 jay$ cm3 -version > Critical Mass Modula-3 version 5.2.6 > last updated: 2003-06-27 > configuration: /cm3/bin/cm3.cfg > > > jbook:/dev2/j/m3 jay$ cm3 > new source -> compiling Hello.m3 > -> linking prog > > > jbook:/dev2/j/m3 jay$ PPC_DARWIN/prog > dyld: Library not loaded: /var/tmp/cm3/lib/libm3.5.2.dylib > Referenced from: /dev2/j/m3/PPC_DARWIN/prog > Reason: image not found > Trace/BPT trap > > > jbook:/dev2/j/m3 jay$ otool -L PPC_DARWIN/prog > PPC_DARWIN/prog: > /var/tmp/cm3/lib/libm3.5.2.dylib (compatibility version > 5.0.0, current version 5.2.0) > /Users/wagner/local/cm3/lib/libm3core.5.2.dylib > (compatibility version 5.0.0, current version 5.2.0) > /Users/wagner/local/cm3/lib/libm3gcdefs.5.2.dylib > (compatibility version 5.0.0, current version 5.2.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > current version 88.1.10) > /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, > current version 1.0.0) > > > jbook:/dev2/j/m3 jay$ ls -l PPC_DARWIN/prog > -rwxr-xr-x 1 jay admin 20264 Dec 25 04:43 PPC_DARWIN/prog > > > At the temporary cost of giving up dynamic linking, you can fix > this by removing M3_SPLIT_LIBNAMES_IF_SHARED > and/or M3_SPLIT_LIBNAMES from cm3.cfg, yielding: > Dynamic linking works fine for me. > > jbook:/dev2/j/m3 jay$ otool -L PPC_DARWIN/prog > PPC_DARWIN/prog: > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > current version 88.1.10) > > > jbook:/dev2/j/m3 jay$ ls -l PPC_DARWIN/prog > -rwxr-xr-x 1 jay admin 1388380 Dec 25 04:48 PPC_DARWIN/prog > > > jbook:/dev2/j/m3 jay$ PPC_DARWIN/prog > Hello > > > I will fix the checked in config file...even though it varies a > bunch from the 5.2.6 distributed > config, it results in the same. Not sure how that differs with my config file. > And, um, does everyone understand what I did with Win32 and making > cminstall obsolete? > Ok to do the same on Mac OS X? Please don't. I would prefer to keep the OS X install the same as for other Unix/POSIX platforms, if only because it means less splitting of the code base. > You know, it's running things out of the path and/or finding them > in their "very standard" locations. > In fact, you can hard code full paths and be ok. > That is, instead of asking the user where their compiler is, > hardcoding any of cc, gcc, /usr/bin/cc, /usr/bin/gcc all work fine. Why not just hardcode the cminstall config file so it doesn't ask questions except were absolutely necessary. > Asking them where ar/ranlib are, similar, though the docs say that > libtool replaced those, and ar/ranlib vs. libtool is one way > in which the checked in config and the 5.2.6 distribution's config > vary. I'll try for libtool. Please see my config file. > > > > The only thing the user really needs to decide is where to install > to, and > the cfg file can discover their choice without any editing. Indeed. > > > > INSTALL_ROOT = path() & "/.." > BIN_INSTALL = path() % executables > > > In terms of wanting to provide some configurable redirection, well, > I think an advanced user can manage.. > An indirect SYSTEM_CC = "cc" can be left, I guess. > > > You know, I dare say, that platforms have been reduced and > converged enough such that..you can get rid of > Quake and move it into cm3. I'm not sure what you mean by this. > Um.. do any of the Unix platforms support other than gcc? Other > than GNU ld? > Ok, Apple ld is not GNU ld. (Geez, it is just me or is Apple an > incredible hodgepodge mess these days? > I mean both in terms of their "system architecture" and their > tools. The "system architecture" reveals bunches > of similar redundant subsystems. Try reading through man ld, man > ranlib, just try to understand which > flag goes with which mode, which flags are for compatibility with > which OS version, and which of the > compatibility flags is either ignored or does something useful... > and should I say -lGL or -framework OpenGL??) > > > That I don't haven't adjusted to Modula-3 and don't mind/prefer > writing Quake instead. :) > > > Some bootstrap was provided. I should look at it, and its config. > Otherwise..I'll look into what it takes to build it all and with > dynamic linking. > Perhaps the bootstrap is just fine. But the checked in config is not. I have a PPC_DARWIN bootstrap file at ftp://ftp.cs.purdue.edu/pub/ hosking/m3 and in the PPC_DARWIN subdirectory. > > > > - Jay > > Share life as it happens with the new Windows Live. Share now! From wagner at elegosoft.com Tue Dec 25 17:26:33 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 25 Dec 2007 17:26:33 +0100 Subject: [M3devel] PPC_DARWIN problems, at least config/5.2.6, maybe all moot In-Reply-To: <5EB28A70-CCEC-4855-B714-F0CE03E6DCC6@cs.purdue.edu> References: <5EB28A70-CCEC-4855-B714-F0CE03E6DCC6@cs.purdue.edu> Message-ID: <20071225162633.GA6373@elegosoft.com> On Tue, Dec 25, 2007 at 11:02:59AM -0500, Tony Hosking wrote: > On Dec 25, 2007, at 7:09 AM, Jay wrote: > >jbook:/dev2/j/m3 jay$ otool -L PPC_DARWIN/prog > >PPC_DARWIN/prog: > > /var/tmp/cm3/lib/libm3.5.2.dylib (compatibility version > >5.0.0, current version 5.2.0) > > /Users/wagner/local/cm3/lib/libm3core.5.2.dylib > >(compatibility version 5.0.0, current version 5.2.0) > > /Users/wagner/local/cm3/lib/libm3gcdefs.5.2.dylib > >(compatibility version 5.0.0, current version 5.2.0) > > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > >current version 88.1.10) > > /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, > >current version 1.0.0) > > > >jbook:/dev2/j/m3 jay$ ls -l PPC_DARWIN/prog > >-rwxr-xr-x 1 jay admin 20264 Dec 25 04:43 PPC_DARWIN/prog > > > >At the temporary cost of giving up dynamic linking, you can fix > >this by removing M3_SPLIT_LIBNAMES_IF_SHARED > >and/or M3_SPLIT_LIBNAMES from cm3.cfg, yielding: > > Dynamic linking works fine for me. For me, too. > >And, um, does everyone understand what I did with Win32 and making > >cminstall obsolete? > >Ok to do the same on Mac OS X? > > Please don't. I would prefer to keep the OS X install the same as > for other Unix/POSIX platforms, if only because it means less > splitting of the code base. I'd second this. I'd rather have a more intelligent cminstall, which tries to figure out all the information for itself, and then presents the user with a standard setup and directions how to solve any remaining problems. And this way we don't have to bother with more more scripting languages, too. > Why not just hardcode the cminstall config file so it doesn't ask > questions except were absolutely necessary. This would be another approach to making things simpler. We can try both ways at once, though. > >The only thing the user really needs to decide is where to install > >to, and > >the cfg file can discover their choice without any editing. > > Indeed. I wouldn't like to remove any flexibility there is, as in my experience, it will be needed once it has been removed. Perhaps I'll have a try at making cminstall better during the next weeks. The main problem with installation issues is, that one needs access to all relevant target platforms to check things and test them, and that it takes much time to do this ;-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Dec 25 17:33:09 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 25 Dec 2007 17:33:09 +0100 Subject: [M3devel] m3cg build failure on powerpc/darwin In-Reply-To: <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> Message-ID: <20071225163309.GA7057@elegosoft.com> Just for the records: The solution to the instruction problem below is installing a newer cctools package. Detailed instructions can be found at http://gcc.gnu.org/ml/gcc/2005-03/msg01149.html Olaf On Sun, Dec 16, 2007 at 04:50:38PM -0500, Tony Hosking wrote: > That is a very old Darwin distro. Here is my G4: > > Darwin Kernel Version 8.10.0: Wed May 23 16:50:59 PDT 2007; > root:xnu-792.21.3~1/RELEASE_PPC > > On Dec 16, 2007, at 4:23 PM, Olaf Wagner wrote: > > >Hi, > > > >while trying to build some boot archives build on my PowerBook > >G4, uname -a > > > >Darwin apple.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 > >20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power > >Macintosh powerpc > > > >the compilation died with > > > >/Users/wagner/work/cm3/m3-sys/m3cc/PPC_DARWIN/./gcc/xgcc -B/Users/ > >wagner/work/cm3/m3-sys/m3cc/PPC_DARWIN/./gcc/ -B/usr/local/powerpc- > >apple-darwin7.9.0/bin/ -B/usr/local/powerpc-apple-darwin7.9.0/lib/ - > >isystem /usr/local/powerpc-apple-darwin7.9.0/include -isystem /usr/ > >local/powerpc-apple-darwin7.9.0/sys-include -c -DHAVE_CONFIG_H -O2 - > >O2 -g -I. -I../../../gcc/libiberty/../include -W -Wall -pedantic - > >Wwrite-strings -Wstrict-prototypes ../../../gcc/libiberty/ > >floatformat.c -o floatformat.o > >../../../gcc/libiberty/floatformat.c: In function > >'floatformat_to_double': > >../../../gcc/libiberty/floatformat.c:354: warning: floating > >constant exceeds range of 'float' > >/var/tmp/cccvQbrs.s:508:stfiwx instruction is optional for the > >PowerPC (not allowed without -force_cpusubtype_ALL option) > >/var/tmp/cccvQbrs.s:550:stfiwx instruction is optional for the > >PowerPC (not allowed without -force_cpusubtype_ALL option) > >make[2]: *** [floatformat.o] Error 1 > >make[1]: *** [all-target-libiberty] Error 2 > >make: *** [all] Error 2 > >"/Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile", line 188: > >quake runtime error: exit 512: cd .; make CC="gcc" CFLAGS="-O2 -g" > > > >--procedure-- -line- -file--- > >exec -- > >include_dir 188 /Users/wagner/work/cm3/m3-sys/m3cc/src/ > >m3makefile > > 5 /Users/wagner/work/cm3/m3-sys/m3cc/ > >PPC_DARWIN/m3make.args > > > >Fatal Error: package build failed > > > >Any ideas? -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Tue Dec 25 20:03:21 2007 From: jayk123 at hotmail.com (Jay) Date: Tue, 25 Dec 2007 19:03:21 +0000 Subject: [M3devel] "why cminstall isn't needed" Message-ID: Here is what happens on Mac OSX 10.4 PowerPC. Where would you like the system installed? [/usr/local/cm3] This is the one thing worthwhile, though the default is fine. 1: /usr/bin/emacsclient 2: /usr/bin/emacs 3: /usr/bin/gnuclient 4: /usr/bin/vi 5: /usr/bin/vim What should be the default text editor for new CM3 users? [/usr/bin/emacsclient](1 of 5) I don't believe this is ever used, not until Reactor comes back. Otherwise it's not a terrible thing to ask. 1: /usr/lib Where are the flex/bison libraries? [/usr/lib](1 of 1) I haven't tested this yet, but the default appears correct, and you don't likely need to specify it. "-lfl" probably suffices. Where are the Postgres95 libraries? By default, nowhere. User could edit cm3.cfg file. Perhaps just comment which parts are more or less expected to be user-edited? Where are the OpenGL libraries? Haven't tested this, but again I believe hardcoding is trivial. Like -framework OpenGL or such. (attached) 1: /usr/lib 2: /usr/local/lib Where are the ODBC libraries? [/usr/lib](1 of 2) Untested, but again /usr/lib appears correct and -liodbc -liodbcinst should suffice. Where are the Motif libraries? Nowhere by default. Where are the X11 libraries? Nowhere by default, but probably hardcodeable if installed. 1: /usr/bin/gcc 2: /usr/bin/cc Where is your C compiler? [/usr/bin/gcc](1 of 2) Both options are fine and equivalent, along with "cc, "gcc", "gcc-3.3", "gcc-4.0". 1: /usr/bin/ar Where is your library archiver? [/usr/bin/ar](1 of 1) This is correct, along with "ar", but the docs suggest shouldn't be used. 1: /usr/bin/ranlib Where is your library indexer? [/usr/bin/ranlib](1 of 1) Ditto. 1: /usr/bin/as Where is your assembler? [/usr/bin/as](1 of 1) This is correct, along with "as". Could also be, e.g. /usr/libexec/darwin/pcc/as, but nothing to be gained by using that directly, right? (gcc has similar actual files) See my point? It's all rather worthless. Hardcoded defaults or $PATH search work. Attached is my config file so far but I am having problems.. - Jay _________________________________________________________________ Don't get caught with egg on your face. Play Chicktionary! http://club.live.com/chicktionary.aspx?icid=chick_wlhmtextlink1_dec -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cfg1 Type: application/octet-stream Size: 12614 bytes Desc: not available URL: From jayk123 at hotmail.com Tue Dec 25 21:32:15 2007 From: jayk123 at hotmail.com (Jay) Date: Tue, 25 Dec 2007 20:32:15 +0000 Subject: [M3devel] PPC_DARWIN problems, at least config/5.2.6, maybe all moot Message-ID: 1) The documentation says -fPIC is the default, so I removed it. But it matters. It doesn't matter for gcc building C. It matters for m3cg building Modula-3. It is the difference between, pic: jbook:/dev2/j/m3 jay$ cat Hello.m3 MODULE Hello EXPORTS Main; IMPORT IO; BEGIN IO.Put("Hello\n"); END Hello. jbook:/dev2/j/m3 jay$ cat PPC_DARWIN/Hello.ms ... bl L_IO__Put$stub ... .data .picsymbol_stub L_IO__Put$stub: .indirect_symbol _IO__Put mflr r0 bcl 20,31,L0$_IO__Put L0$_IO__Put: mflr r11 addis r11,r11,ha16(L_IO__Put$lazy_ptr-L0$_IO__Put) mtlr r0 lwz r12,lo16(L_IO__Put$lazy_ptr-L0$_IO__Put)(r11) mtctr r12 addi r11,r11,lo16(L_IO__Put$lazy_ptr-L0$_IO__Put) bctr .data .lazy_symbol_pointer L_IO__Put$lazy_ptr: .indirect_symbol _IO__Put .long dyld_stub_binding_helper vs. non-pic just plain wow only one whole function to make a call :) : jbook:/dev2/j/m3 jay$ cat PPC_DARWIN/Hello.ms ... bl _IO__Put which nets you the likes of: jbook:/dev2/j/m3 jay$ cm3 -> linking prog gcc -dynamic -o prog _m3main.o Hello.mo -L/cm3/pkg/libm3/PPC_DARWIN -lm3 -L/cm3/pkg/m3core/PPC_DARWIN -lm3core -L/cm3/bin/../lib -lm3gcdefs /usr/bin/ld: _m3main.o has external relocation entries in non-writable section (__TEXT,__text) for symbols: _RTProcess__Exit _RTLinker__AddUnit _RTLinker__InitRuntime collect2: ld returned 1 exit status (Windows also only uses one instruction, through a pointer, for dynamic calls, and the compiler often prefetches the pointer. The difference is, perhaps, that Windows aggregates all the pointers together, not sure about the other systems.. one instruction through a pointer is true for x86 and AM64, not so of the former MIPS, PowerPC, Alpha I believe or current IA64, those require fetching/restore the GOT/TOC (same thing? I should know the difference..) 2) Splitting -L and -l off for shared libs matters. ld /foo/bar.a means link to bar.a, which is a static lib, not even a stub lib or import lib like in Windows -L/foo -lbar probes for /foo/bar.dylib /foo/bar.a man ld: -lx This option is an abbreviation for the library name `libx.a', where x is a string. If -dynamic is specified the abbreviation for the library name is first search as `libx.dylib' and then `libx.a' is searched for. ld searches for libraries first in any directories specified with -L options, then in any directo- ries specified in the colon separated set of paths in the envi- ronment variable LD_LIBRARY_PATH, then the standard directories /lib, /usr/lib, and /usr/local/lib. A library is searched when its name is encountered, so the placement of the -l flag is sig- nificant. If string x is of the form x.o, then that file is searched for in the same places, but without prepending `lib' or appending `.a' or `.dylib' to the filename. 3) lastly, setting DYLD_LIBRARY_PATH=/cm3/lib lets the full paths from one machine not matter so much on another machine. I am going to try out: before: local lib_so = format ("lib%s.dylib", lib) local lib_soxx = format ("lib%s.%s.dylib", lib, version) local lib_pn = LIB_INSTALL & "/" & lib_soxx "-install_name", lib_pn, after: local lib_so = format ("lib%s.dylib", lib) local lib_soxx = format ("lib%s.%s.dylib", lib, version) local lib_pn = LIB_INSTALL & "/" & lib_soxx "-install_name", lib_soxx, see if a path is needed or can just use leaf names. - Jay From: jayk123 at hotmail.com To: m3devel at elegosoft.com Subject: PPC_DARWIN problems, at least config/5.2.6, maybe all moot Date: Tue, 25 Dec 2007 12:09:31 +0000 PPC_DARWIN also has problems...at least in the config. If you take the 5.2.6 archive, install to /dev2/cm3, accept the defaults, claim all the missing unused libs are in /usr/lib (opengl, postgres, x11) you end up with: jbook:/dev2/j/m3 jay$ cat Hello.m3 MODULE Hello EXPORTS Main; IMPORT IO; BEGIN IO.Put("Hello\n"); END Hello. jbook:/dev2/j/m3 jay$ uname -a Darwin jbook 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc jbook:/dev2/j/m3 jay$ cm3 -version Critical Mass Modula-3 version 5.2.6 last updated: 2003-06-27 configuration: /cm3/bin/cm3.cfg jbook:/dev2/j/m3 jay$ cm3 new source -> compiling Hello.m3 -> linking prog jbook:/dev2/j/m3 jay$ PPC_DARWIN/prog dyld: Library not loaded: /var/tmp/cm3/lib/libm3.5.2.dylib Referenced from: /dev2/j/m3/PPC_DARWIN/prog Reason: image not found Trace/BPT trap jbook:/dev2/j/m3 jay$ otool -L PPC_DARWIN/prog PPC_DARWIN/prog: /var/tmp/cm3/lib/libm3.5.2.dylib (compatibility version 5.0.0, current version 5.2.0) /Users/wagner/local/cm3/lib/libm3core.5.2.dylib (compatibility version 5.0.0, current version 5.2.0) /Users/wagner/local/cm3/lib/libm3gcdefs.5.2.dylib (compatibility version 5.0.0, current version 5.2.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.10) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) jbook:/dev2/j/m3 jay$ ls -l PPC_DARWIN/prog -rwxr-xr-x 1 jay admin 20264 Dec 25 04:43 PPC_DARWIN/prog At the temporary cost of giving up dynamic linking, you can fix this by removing M3_SPLIT_LIBNAMES_IF_SHARED and/or M3_SPLIT_LIBNAMES from cm3.cfg, yielding: jbook:/dev2/j/m3 jay$ otool -L PPC_DARWIN/prog PPC_DARWIN/prog: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.10) jbook:/dev2/j/m3 jay$ ls -l PPC_DARWIN/prog -rwxr-xr-x 1 jay admin 1388380 Dec 25 04:48 PPC_DARWIN/prog jbook:/dev2/j/m3 jay$ PPC_DARWIN/prog Hello I will fix the checked in config file...even though it varies a bunch from the 5.2.6 distributed config, it results in the same. And, um, does everyone understand what I did with Win32 and making cminstall obsolete? Ok to do the same on Mac OS X? You know, it's running things out of the path and/or finding them in their "very standard" locations. In fact, you can hard code full paths and be ok. That is, instead of asking the user where their compiler is, hardcoding any of cc, gcc, /usr/bin/cc, /usr/bin/gcc all work fine. Asking them where ar/ranlib are, similar, though the docs say that libtool replaced those, and ar/ranlib vs. libtool is one way in which the checked in config and the 5.2.6 distribution's config vary. I'll try for libtool. The only thing the user really needs to decide is where to install to, and the cfg file can discover their choice without any editing. INSTALL_ROOT = path() & "/.." BIN_INSTALL = path() % executables In terms of wanting to provide some configurable redirection, well, I think an advanced user can manage.. An indirect SYSTEM_CC = "cc" can be left, I guess. You know, I dare say, that platforms have been reduced and converged enough such that..you can get rid of Quake and move it into cm3. Um.. do any of the Unix platforms support other than gcc? Other than GNU ld? Ok, Apple ld is not GNU ld. (Geez, it is just me or is Apple an incredible hodgepodge mess these days? I mean both in terms of their "system architecture" and their tools. The "system architecture" reveals bunches of similar redundant subsystems. Try reading through man ld, man ranlib, just try to understand which flag goes with which mode, which flags are for compatibility with which OS version, and which of the compatibility flags is either ignored or does something useful... and should I say -lGL or -framework OpenGL??) That I don't haven't adjusted to Modula-3 and don't mind/prefer writing Quake instead. :) Some bootstrap was provided. I should look at it, and its config. Otherwise..I'll look into what it takes to build it all and with dynamic linking. Perhaps the bootstrap is just fine. But the checked in config is not. - Jay Share life as it happens with the new Windows Live. Share now! _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Tue Dec 25 22:47:03 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 25 Dec 2007 13:47:03 -0800 Subject: [M3devel] PPC_DARWIN problems, at least config/5.2.6, maybe all moot In-Reply-To: Your message of "Tue, 25 Dec 2007 12:09:31 GMT." Message-ID: <200712252147.lBPLl32p030684@camembert.async.caltech.edu> Jay writes: > ... > >You know, I dare say, that platforms have been reduced and converged enough= > such that..you can get rid of >Quake and move it into cm3. Um.. do any of the Unix platforms support other= > than gcc? Other than GNU ld? I take it you don't mean "get rid of Quake" but "get rid of cm3.cfg"? I would certainly agree that cm3.cfg is problematic. I have more than once had apparently unresolvable issues with CM3 that Tony fixed by sending me a new cm3.cfg, which came, seemingly, out of a hat... However I also would think it's a bad idea to reduce configurability. As Olaf said, you'll miss it the moment it's gone. (Someone will.) Non-GNU Solaris and Digital Unix aren't that hard to support with the current code if someone wanted to, for instance. Why make such a hypothetical someone's work harder? (Just an example, I'm sure there are other things.) Mika From jayk123 at hotmail.com Tue Dec 25 23:03:19 2007 From: jayk123 at hotmail.com (Jay) Date: Tue, 25 Dec 2007 22:03:19 +0000 Subject: [M3devel] PPC_DARWIN problems, at least config/5.2.6, maybe all moot In-Reply-To: <200712252147.lBPLl32p030684@camembert.async.caltech.edu> References: Your message of "Tue, 25 Dec 2007 12:09:31 GMT." <200712252147.lBPLl32p030684@camembert.async.caltech.edu> Message-ID: Other platforms should be supportable via cm3 directly eh? I'm just not sure of the value of extension/scripting languages in general, vs. having fewer languages. I very much like not having to compile/link such languages, the tendency toward having garbage collection and builtin collection classes, but I'm not sure which characteristics necessarily go together -- I strongly suspect you can have it all in one language -- static checking, fast compilation to native code, "built in" collection classes or a good library, etc. I don't care that much. You know, everything is configurable, it is a matter of how. What is in the code, what is in data, what is in non compiled code? (code is data and all that..) There does seem to be a line here but it is scientifically (lazily?) hard for me to discern. Regarding the problems with cm3.cfg.. I don't know. Just to backup a sec, I believe one of the "big" pieces of work that Critical Mass did was converting large swaths of Quake code into Modula-3, that code which, I assume, tended to be the same across all machines. Maybe it was just "utilities", maybe it was about perf. So what I wonder then, is if just a bit more shouldn't be done here. Have platforms converged such that less needs to be configurable? Or, then again, the cm3.cfg IS already fairly small. Maybe it is right about where it needs to be. Bigger fish to fry probably -- like, I noticed m3cg and as are run for every single file, maybe there is a gain to batching? (and win32 int64.....) So, back to cm3.cfg. It IS fairly small. Is it down to about what varies per platform? I haven't really surveyed them all.. - Jay > To: jayk123 at hotmail.com > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] PPC_DARWIN problems, at least config/5.2.6, maybe all moot > Date: Tue, 25 Dec 2007 13:47:03 -0800 > From: mika at async.caltech.edu > > Jay writes: > > > ... > > > >You know, I dare say, that platforms have been reduced and converged enough= > > such that..you can get rid of > >Quake and move it into cm3. Um.. do any of the Unix platforms support other= > > than gcc? Other than GNU ld? > > I take it you don't mean "get rid of Quake" but "get rid of cm3.cfg"? > I would certainly agree that cm3.cfg is problematic. I have more > than once had apparently unresolvable issues with CM3 that Tony > fixed by sending me a new cm3.cfg, which came, seemingly, out of a > hat... > > However I also would think it's a bad idea to reduce configurability. > As Olaf said, you'll miss it the moment it's gone. (Someone will.) > Non-GNU Solaris and Digital Unix aren't that hard to support with > the current code if someone wanted to, for instance. Why make such a > hypothetical someone's work harder? (Just an example, I'm sure there > are other things.) > > Mika _________________________________________________________________ Don't get caught with egg on your face. Play Chicktionary! http://club.live.com/chicktionary.aspx?icid=chick_wlhmtextlink1_dec -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Dec 26 05:14:15 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 25 Dec 2007 23:14:15 -0500 Subject: [M3devel] PPC_DARWIN problems, at least config/5.2.6, maybe all moot In-Reply-To: References: Your message of "Tue, 25 Dec 2007 12:09:31 GMT." <200712252147.lBPLl32p030684@camembert.async.caltech.edu> Message-ID: <4A78DF83-6CBF-43AB-AEE0-6E1E25ACDE39@cs.purdue.edu> On Dec 25, 2007, at 5:03 PM, Jay wrote: > Is it down to about what varies per platform? Yes, pretty much... > > I haven't really surveyed them all.. > > - Jay > > > To: jayk123 at hotmail.com > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] PPC_DARWIN problems, at least config/ > 5.2.6, maybe all moot > > Date: Tue, 25 Dec 2007 13:47:03 -0800 > > From: mika at async.caltech.edu > > > > Jay writes: > > > > > ... > > > > > >You know, I dare say, that platforms have been reduced and > converged enough= > > > such that..you can get rid of > > >Quake and move it into cm3. Um.. do any of the Unix platforms > support other= > > > than gcc? Other than GNU ld? > > > > I take it you don't mean "get rid of Quake" but "get rid of > cm3.cfg"? > > I would certainly agree that cm3.cfg is problematic. I have more > > than once had apparently unresolvable issues with CM3 that Tony > > fixed by sending me a new cm3.cfg, which came, seemingly, out of a > > hat... > > > > However I also would think it's a bad idea to reduce > configurability. > > As Olaf said, you'll miss it the moment it's gone. (Someone will.) > > Non-GNU Solaris and Digital Unix aren't that hard to support with > > the current code if someone wanted to, for instance. Why make such a > > hypothetical someone's work harder? (Just an example, I'm sure there > > are other things.) > > > > Mika > > Don't get caught with egg on your face. Play Chicktionary! Check it > out! From hosking at cs.purdue.edu Wed Dec 26 05:17:56 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 25 Dec 2007 23:17:56 -0500 Subject: [M3devel] PPC_DARWIN problems, at least config/5.2.6, maybe all moot In-Reply-To: References: Message-ID: On Dec 25, 2007, at 3:32 PM, Jay wrote: > 1) > > The documentation says -fPIC is the default, so I removed it. > But it matters. It doesn't matter for gcc building C. > It matters for m3cg building Modula-3. Please note that m3cg is based on the GNU release of gcc, *not* the Darwin version. Thus, even though Darwin might have -fPIC as default for Apple's gcc, GNU gcc might not. > It is the difference between, pic: > > jbook:/dev2/j/m3 jay$ cat Hello.m3 > MODULE Hello EXPORTS Main; > > IMPORT IO; > BEGIN > IO.Put("Hello\n"); > END Hello. > > jbook:/dev2/j/m3 jay$ cat PPC_DARWIN/Hello.ms > ... > bl L_IO__Put$stub > ... > .data > .picsymbol_stub > L_IO__Put$stub: > .indirect_symbol _IO__Put > mflr r0 > bcl 20,31,L0$_IO__Put > L0$_IO__Put: > mflr r11 > addis r11,r11,ha16(L_IO__Put$lazy_ptr-L0$_IO__Put) > mtlr r0 > lwz r12,lo16(L_IO__Put$lazy_ptr-L0$_IO__Put)(r11) > mtctr r12 > addi r11,r11,lo16(L_IO__Put$lazy_ptr-L0$_IO__Put) > bctr > .data > .lazy_symbol_pointer > L_IO__Put$lazy_ptr: > .indirect_symbol _IO__Put > .long dyld_stub_binding_helper > > vs. non-pic just plain wow only one whole function to make a call :) : > > jbook:/dev2/j/m3 jay$ cat PPC_DARWIN/Hello.ms > ... > bl _IO__Put > > which nets you the likes of: > > jbook:/dev2/j/m3 jay$ cm3 > -> linking prog > gcc -dynamic -o prog _m3main.o Hello.mo -L/cm3/pkg/libm3/ > PPC_DARWIN -lm3 -L/cm3/pkg/m3core/PPC_DARWIN -lm3core -L/cm3/bin/../ > lib -lm3gcdefs > /usr/bin/ld: _m3main.o has external relocation entries in non- > writable section (__TEXT,__text) for symbols: > _RTProcess__Exit > _RTLinker__AddUnit > _RTLinker__InitRuntime > collect2: ld returned 1 exit status > > > (Windows also only uses one instruction, through a pointer, for > dynamic calls, and the compiler often prefetches the pointer. > The difference is, perhaps, that Windows aggregates all the > pointers together, not sure about the other systems.. one instruction > through a pointer is true for x86 and AM64, not so of the former > MIPS, PowerPC, Alpha I believe or current IA64, those > require fetching/restore the GOT/TOC (same thing? I should know the > difference..) > > 2) > Splitting -L and -l off for shared libs matters. > > ld /foo/bar.a means link to bar.a, which is a static lib, not even > a stub lib or import lib like in Windows > > -L/foo -lbar probes for > /foo/bar.dylib > /foo/bar.a > > man ld: > -lx This option is an abbreviation for the library > name `libx.a', > where x is a string. If -dynamic is specified the > abbreviation > for the library name is first search as > `libx.dylib' and then > `libx.a' is searched for. ld searches for > libraries first in > any directories specified with -L options, then in > any directo- > ries specified in the colon separated set of paths in > the envi- > ronment variable LD_LIBRARY_PATH, then the standard > directories > /lib, /usr/lib, and /usr/local/lib. A library is > searched when > its name is encountered, so the placement of the -l > flag is sig- > nificant. If string x is of the form x.o, then > that file is > searched for in the same places, but without > prepending `lib' or > appending `.a' or `.dylib' to the filename. > > > 3) > lastly, setting DYLD_LIBRARY_PATH=/cm3/lib > lets the full paths from one machine not matter so much on another > machine. > > I am going to try out: > > before: > local lib_so = format ("lib%s.dylib", lib) > local lib_soxx = format ("lib%s.%s.dylib", lib, version) > local lib_pn = LIB_INSTALL & "/" & lib_soxx > > "-install_name", lib_pn, > > after: > > local lib_so = format ("lib%s.dylib", lib) > local lib_soxx = format ("lib%s.%s.dylib", lib, version) > local lib_pn = LIB_INSTALL & "/" & lib_soxx > > "-install_name", lib_soxx, > > see if a path is needed or can just use leaf names. > > - Jay > > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: PPC_DARWIN problems, at least config/5.2.6, maybe all moot > Date: Tue, 25 Dec 2007 12:09:31 +0000 > > PPC_DARWIN also has problems...at least in the config. > > > If you take the 5.2.6 archive, install to /dev2/cm3, accept the > defaults, > claim all the missing unused libs are in /usr/lib (opengl, > postgres, x11) > > > you end up with: > > > jbook:/dev2/j/m3 jay$ cat Hello.m3 > > > MODULE Hello EXPORTS Main; > IMPORT IO; > BEGIN > IO.Put("Hello\n"); > END Hello. > > > jbook:/dev2/j/m3 jay$ uname -a > Darwin jbook 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 > 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh > powerpc > > > jbook:/dev2/j/m3 jay$ cm3 -version > Critical Mass Modula-3 version 5.2.6 > last updated: 2003-06-27 > configuration: /cm3/bin/cm3.cfg > > > jbook:/dev2/j/m3 jay$ cm3 > new source -> compiling Hello.m3 > -> linking prog > > > jbook:/dev2/j/m3 jay$ PPC_DARWIN/prog > dyld: Library not loaded: /var/tmp/cm3/lib/libm3.5.2.dylib > Referenced from: /dev2/j/m3/PPC_DARWIN/prog > Reason: image not found > Trace/BPT trap > > > jbook:/dev2/j/m3 jay$ otool -L PPC_DARWIN/prog > PPC_DARWIN/prog: > /var/tmp/cm3/lib/libm3.5.2.dylib (compatibility version > 5.0.0, current version 5.2.0) > /Users/wagner/local/cm3/lib/libm3core.5.2.dylib > (compatibility version 5.0.0, current version 5.2.0) > /Users/wagner/local/cm3/lib/libm3gcdefs.5.2.dylib > (compatibility version 5.0.0, current version 5.2.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > current version 88.1.10) > /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, > current version 1.0.0) > > > jbook:/dev2/j/m3 jay$ ls -l PPC_DARWIN/prog > -rwxr-xr-x 1 jay admin 20264 Dec 25 04:43 PPC_DARWIN/prog > > > At the temporary cost of giving up dynamic linking, you can fix > this by removing M3_SPLIT_LIBNAMES_IF_SHARED > and/or M3_SPLIT_LIBNAMES from cm3.cfg, yielding: > > > jbook:/dev2/j/m3 jay$ otool -L PPC_DARWIN/prog > PPC_DARWIN/prog: > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > current version 88.1.10) > > > jbook:/dev2/j/m3 jay$ ls -l PPC_DARWIN/prog > -rwxr-xr-x 1 jay admin 1388380 Dec 25 04:48 PPC_DARWIN/prog > > > jbook:/dev2/j/m3 jay$ PPC_DARWIN/prog > Hello > > > I will fix the checked in config file...even though it varies a > bunch from the 5.2.6 distributed > config, it results in the same. > > > And, um, does everyone understand what I did with Win32 and making > cminstall obsolete? > Ok to do the same on Mac OS X? > You know, it's running things out of the path and/or finding them > in their "very standard" locations. > In fact, you can hard code full paths and be ok. > That is, instead of asking the user where their compiler is, > hardcoding any of cc, gcc, /usr/bin/cc, /usr/bin/gcc all work fine. > Asking them where ar/ranlib are, similar, though the docs say that > libtool replaced those, and ar/ranlib vs. libtool is one way > in which the checked in config and the 5.2.6 distribution's config > vary. I'll try for libtool. > > > The only thing the user really needs to decide is where to install > to, and > the cfg file can discover their choice without any editing. > > > INSTALL_ROOT = path() & "/.." > BIN_INSTALL = path() % executables > > > In terms of wanting to provide some configurable redirection, well, > I think an advanced user can manage.. > An indirect SYSTEM_CC = "cc" can be left, I guess. > > > You know, I dare say, that platforms have been reduced and > converged enough such that..you can get rid of > Quake and move it into cm3. Um.. do any of the Unix platforms > support other than gcc? Other than GNU ld? > Ok, Apple ld is not GNU ld. (Geez, it is just me or is Apple an > incredible hodgepodge mess these days? > I mean both in terms of their "system architecture" and their > tools. The "system architecture" reveals bunches > of similar redundant subsystems. Try reading through man ld, man > ranlib, just try to understand which > flag goes with which mode, which flags are for compatibility with > which OS version, and which of the > compatibility flags is either ignored or does something useful... > and should I say -lGL or -framework OpenGL??) > > > That I don't haven't adjusted to Modula-3 and don't mind/prefer > writing Quake instead. :) > > > Some bootstrap was provided. I should look at it, and its config. > Otherwise..I'll look into what it takes to build it all and with > dynamic linking. > Perhaps the bootstrap is just fine. But the checked in config is not. > > > - Jay > > Share life as it happens with the new Windows Live. Share now! > Share life as it happens with the new Windows Live. Share now! From jayk123 at hotmail.com Wed Dec 26 06:51:04 2007 From: jayk123 at hotmail.com (Jay) Date: Wed, 26 Dec 2007 05:51:04 +0000 Subject: [M3devel] PPC_DARWIN problems, at least config/5.2.6, maybe all moot In-Reply-To: References: Message-ID: Oh, very good point. "gcc" is Apple and resembles "man gcc", "m3cg" not.. - Jay > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > Subject: Re: [M3devel] PPC_DARWIN problems, at least config/5.2.6, maybe all moot > Date: Tue, 25 Dec 2007 23:17:56 -0500 > To: jayk123 at hotmail.com > > > On Dec 25, 2007, at 3:32 PM, Jay wrote: > > > 1) > > > > The documentation says -fPIC is the default, so I removed it. > > But it matters. It doesn't matter for gcc building C. > > It matters for m3cg building Modula-3. > > Please note that m3cg is based on the GNU release of gcc, *not* the > Darwin version. Thus, even though Darwin might have -fPIC as default > for Apple's gcc, GNU gcc might not. > > > It is the difference between, pic: > > > > jbook:/dev2/j/m3 jay$ cat Hello.m3 > > MODULE Hello EXPORTS Main; > > > > IMPORT IO; > > BEGIN > > IO.Put("Hello\n"); > > END Hello. > > > > jbook:/dev2/j/m3 jay$ cat PPC_DARWIN/Hello.ms > > ... > > bl L_IO__Put$stub > > ... > > .data > > .picsymbol_stub > > L_IO__Put$stub: > > .indirect_symbol _IO__Put > > mflr r0 > > bcl 20,31,L0$_IO__Put > > L0$_IO__Put: > > mflr r11 > > addis r11,r11,ha16(L_IO__Put$lazy_ptr-L0$_IO__Put) > > mtlr r0 > > lwz r12,lo16(L_IO__Put$lazy_ptr-L0$_IO__Put)(r11) > > mtctr r12 > > addi r11,r11,lo16(L_IO__Put$lazy_ptr-L0$_IO__Put) > > bctr > > .data > > .lazy_symbol_pointer > > L_IO__Put$lazy_ptr: > > .indirect_symbol _IO__Put > > .long dyld_stub_binding_helper > > > > vs. non-pic just plain wow only one whole function to make a call :) : > > > > jbook:/dev2/j/m3 jay$ cat PPC_DARWIN/Hello.ms > > ... > > bl _IO__Put > > > > which nets you the likes of: > > > > jbook:/dev2/j/m3 jay$ cm3 > > -> linking prog > > gcc -dynamic -o prog _m3main.o Hello.mo -L/cm3/pkg/libm3/ > > PPC_DARWIN -lm3 -L/cm3/pkg/m3core/PPC_DARWIN -lm3core -L/cm3/bin/../ > > lib -lm3gcdefs > > /usr/bin/ld: _m3main.o has external relocation entries in non- > > writable section (__TEXT,__text) for symbols: > > _RTProcess__Exit > > _RTLinker__AddUnit > > _RTLinker__InitRuntime > > collect2: ld returned 1 exit status > > > > > > (Windows also only uses one instruction, through a pointer, for > > dynamic calls, and the compiler often prefetches the pointer. > > The difference is, perhaps, that Windows aggregates all the > > pointers together, not sure about the other systems.. one instruction > > through a pointer is true for x86 and AM64, not so of the former > > MIPS, PowerPC, Alpha I believe or current IA64, those > > require fetching/restore the GOT/TOC (same thing? I should know the > > difference..) > > > > 2) > > Splitting -L and -l off for shared libs matters. > > > > ld /foo/bar.a means link to bar.a, which is a static lib, not even > > a stub lib or import lib like in Windows > > > > -L/foo -lbar probes for > > /foo/bar.dylib > > /foo/bar.a > > > > man ld: > > -lx This option is an abbreviation for the library > > name `libx.a', > > where x is a string. If -dynamic is specified the > > abbreviation > > for the library name is first search as > > `libx.dylib' and then > > `libx.a' is searched for. ld searches for > > libraries first in > > any directories specified with -L options, then in > > any directo- > > ries specified in the colon separated set of paths in > > the envi- > > ronment variable LD_LIBRARY_PATH, then the standard > > directories > > /lib, /usr/lib, and /usr/local/lib. A library is > > searched when > > its name is encountered, so the placement of the -l > > flag is sig- > > nificant. If string x is of the form x.o, then > > that file is > > searched for in the same places, but without > > prepending `lib' or > > appending `.a' or `.dylib' to the filename. > > > > > > 3) > > lastly, setting DYLD_LIBRARY_PATH=/cm3/lib > > lets the full paths from one machine not matter so much on another > > machine. > > > > I am going to try out: > > > > before: > > local lib_so = format ("lib%s.dylib", lib) > > local lib_soxx = format ("lib%s.%s.dylib", lib, version) > > local lib_pn = LIB_INSTALL & "/" & lib_soxx > > > > "-install_name", lib_pn, > > > > after: > > > > local lib_so = format ("lib%s.dylib", lib) > > local lib_soxx = format ("lib%s.%s.dylib", lib, version) > > local lib_pn = LIB_INSTALL & "/" & lib_soxx > > > > "-install_name", lib_soxx, > > > > see if a path is needed or can just use leaf names. > > > > - Jay > > > > From: jayk123 at hotmail.com > > To: m3devel at elegosoft.com > > Subject: PPC_DARWIN problems, at least config/5.2.6, maybe all moot > > Date: Tue, 25 Dec 2007 12:09:31 +0000 > > > > PPC_DARWIN also has problems...at least in the config. > > > > > > If you take the 5.2.6 archive, install to /dev2/cm3, accept the > > defaults, > > claim all the missing unused libs are in /usr/lib (opengl, > > postgres, x11) > > > > > > you end up with: > > > > > > jbook:/dev2/j/m3 jay$ cat Hello.m3 > > > > > > MODULE Hello EXPORTS Main; > > IMPORT IO; > > BEGIN > > IO.Put("Hello\n"); > > END Hello. > > > > > > jbook:/dev2/j/m3 jay$ uname -a > > Darwin jbook 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 > > 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh > > powerpc > > > > > > jbook:/dev2/j/m3 jay$ cm3 -version > > Critical Mass Modula-3 version 5.2.6 > > last updated: 2003-06-27 > > configuration: /cm3/bin/cm3.cfg > > > > > > jbook:/dev2/j/m3 jay$ cm3 > > new source -> compiling Hello.m3 > > -> linking prog > > > > > > jbook:/dev2/j/m3 jay$ PPC_DARWIN/prog > > dyld: Library not loaded: /var/tmp/cm3/lib/libm3.5.2.dylib > > Referenced from: /dev2/j/m3/PPC_DARWIN/prog > > Reason: image not found > > Trace/BPT trap > > > > > > jbook:/dev2/j/m3 jay$ otool -L PPC_DARWIN/prog > > PPC_DARWIN/prog: > > /var/tmp/cm3/lib/libm3.5.2.dylib (compatibility version > > 5.0.0, current version 5.2.0) > > /Users/wagner/local/cm3/lib/libm3core.5.2.dylib > > (compatibility version 5.0.0, current version 5.2.0) > > /Users/wagner/local/cm3/lib/libm3gcdefs.5.2.dylib > > (compatibility version 5.0.0, current version 5.2.0) > > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > > current version 88.1.10) > > /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, > > current version 1.0.0) > > > > > > jbook:/dev2/j/m3 jay$ ls -l PPC_DARWIN/prog > > -rwxr-xr-x 1 jay admin 20264 Dec 25 04:43 PPC_DARWIN/prog > > > > > > At the temporary cost of giving up dynamic linking, you can fix > > this by removing M3_SPLIT_LIBNAMES_IF_SHARED > > and/or M3_SPLIT_LIBNAMES from cm3.cfg, yielding: > > > > > > jbook:/dev2/j/m3 jay$ otool -L PPC_DARWIN/prog > > PPC_DARWIN/prog: > > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > > current version 88.1.10) > > > > > > jbook:/dev2/j/m3 jay$ ls -l PPC_DARWIN/prog > > -rwxr-xr-x 1 jay admin 1388380 Dec 25 04:48 PPC_DARWIN/prog > > > > > > jbook:/dev2/j/m3 jay$ PPC_DARWIN/prog > > Hello > > > > > > I will fix the checked in config file...even though it varies a > > bunch from the 5.2.6 distributed > > config, it results in the same. > > > > > > And, um, does everyone understand what I did with Win32 and making > > cminstall obsolete? > > Ok to do the same on Mac OS X? > > You know, it's running things out of the path and/or finding them > > in their "very standard" locations. > > In fact, you can hard code full paths and be ok. > > That is, instead of asking the user where their compiler is, > > hardcoding any of cc, gcc, /usr/bin/cc, /usr/bin/gcc all work fine. > > Asking them where ar/ranlib are, similar, though the docs say that > > libtool replaced those, and ar/ranlib vs. libtool is one way > > in which the checked in config and the 5.2.6 distribution's config > > vary. I'll try for libtool. > > > > > > The only thing the user really needs to decide is where to install > > to, and > > the cfg file can discover their choice without any editing. > > > > > > INSTALL_ROOT = path() & "/.." > > BIN_INSTALL = path() % executables > > > > > > In terms of wanting to provide some configurable redirection, well, > > I think an advanced user can manage.. > > An indirect SYSTEM_CC = "cc" can be left, I guess. > > > > > > You know, I dare say, that platforms have been reduced and > > converged enough such that..you can get rid of > > Quake and move it into cm3. Um.. do any of the Unix platforms > > support other than gcc? Other than GNU ld? > > Ok, Apple ld is not GNU ld. (Geez, it is just me or is Apple an > > incredible hodgepodge mess these days? > > I mean both in terms of their "system architecture" and their > > tools. The "system architecture" reveals bunches > > of similar redundant subsystems. Try reading through man ld, man > > ranlib, just try to understand which > > flag goes with which mode, which flags are for compatibility with > > which OS version, and which of the > > compatibility flags is either ignored or does something useful... > > and should I say -lGL or -framework OpenGL??) > > > > > > That I don't haven't adjusted to Modula-3 and don't mind/prefer > > writing Quake instead. :) > > > > > > Some bootstrap was provided. I should look at it, and its config. > > Otherwise..I'll look into what it takes to build it all and with > > dynamic linking. > > Perhaps the bootstrap is just fine. But the checked in config is not. > > > > > > - Jay > > > > Share life as it happens with the new Windows Live. Share now! > > Share life as it happens with the new Windows Live. Share now! > _________________________________________________________________ The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. http://www.xbox.com/en-US/hardware/wheretobuy/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Dec 26 06:55:22 2007 From: jayk123 at hotmail.com (Jay) Date: Wed, 26 Dec 2007 05:55:22 +0000 Subject: [M3devel] when to change version numbers in .dlls/.sos/.dylibs? In-Reply-To: References: Message-ID: There's a mix of versions in the configurations. Presumably at the moment they should all be 5.5 and derive from one shared statement of the version??? jbook:/dev2/cm3/m3-sys/cminstall/src/config jay$ grep %s.dylib * I386_DARWIN: local lib_so = format ("lib%s.dylib", lib) I386_DARWIN: local lib_sox = format ("lib%s.%s.dylib", lib, vmaj) I386_DARWIN: local lib_soxx = format ("lib%s.%s.dylib", lib, version) I386_DARWIN: local lib_so = format ("lib%s.dylib", lib) I386_DARWIN: local lib_sox = format ("lib%s.%s.dylib", lib, vmaj) I386_DARWIN: local lib_soxx = format ("lib%s.%s.dylib", lib, version) PPC_DARWIN: local lib_so = format ("lib%s.dylib", lib) PPC_DARWIN: local lib_sox = format ("lib%s.%s.dylib", lib, vmaj) PPC_DARWIN: local lib_soxx = format ("lib%s.%s.dylib", lib, version) PPC_DARWIN: local lib_so = format ("lib%s.dylib", lib) PPC_DARWIN: local lib_sox = format ("lib%s.%s.dylib", lib, vmaj) PPC_DARWIN: local lib_soxx = format ("lib%s.%s.dylib", lib, version) jbook:/dev2/cm3/m3-sys/cminstall/src/config jay$ grep so.1 * SPARC: local lib_so = format ("lib%s.so.1.1", lib) SPARC: local lib_so = format ("lib%s.so.1.1", lib) jbook:/dev2/cm3/m3-sys/cminstall/src/config jay$ grep so.4 * LINUXELF: local lib_sox = format ("lib%s.so.4", lib) LINUXELF: local lib_soxx = format ("lib%s.so.4.1", lib) LINUXELF: local lib_sox = format ("lib%s.so.4", lib) LINUXELF: local lib_soxx = format ("lib%s.so.4.1", lib) jbook:/dev2/cm3/m3-sys/cminstall/src/config jay$ grep so.5 * FreeBSD3: local lib_sox = format ("lib%s.so.5", lib) FreeBSD3: local lib_soxx = format ("lib%s.so.5.1", lib) FreeBSD3: local lib_sox = format ("lib%s.so.5", lib) FreeBSD4: local lib_sox = format ("lib%s.so.5", lib) FreeBSD4: local lib_soxx = format ("lib%s.so.5.1", lib) FreeBSD4: local lib_sox = format ("lib%s.so.5", lib) LINUXLIBC6: local lib_sox = format ("lib%s.so.5", lib) LINUXLIBC6: local lib_sox = format ("lib%s.so.5", lib) NT386GNU: local lib_sox = format ("lib%s.so.5", lib) NT386GNU: local lib_sox = format ("lib%s.so.5", lib) NetBSD2_i386: local lib_sox = format ("lib%s.so.5", lib) NetBSD2_i386: local lib_soxx = format ("lib%s.so.5.1", lib) NetBSD2_i386: local lib_sox = format ("lib%s.so.5", lib) NetBSD2_i386: local lib_soxx = format ("lib%s.so.5.1", lib) PPC_LINUX: local lib_sox = format ("lib%s.so.5", lib) PPC_LINUX: local lib_sox = format ("lib%s.so.5", lib) SOLgnu: local lib_sox = format ("lib%s.so.5", lib) SOLgnu: local lib_sox = format ("lib%s.so.5", lib) SOLsun: local lib_sox = format ("lib%s.so.5", lib) SOLsun: local lib_sox = format ("lib%s.so.5", lib) _________________________________________________________________ The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. http://www.xbox.com/en-US/hardware/wheretobuy/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Dec 28 09:25:21 2007 From: jayk123 at hotmail.com (Jay) Date: Fri, 28 Dec 2007 08:25:21 +0000 Subject: [M3devel] wierdness around user overrides vs. uname in sysinfo.sh? Message-ID: I wanted to change upgrade.sh to have the following features: 1) optionally skip building m3cc, since it is the slowest part 2) optionally clean between various steps, as was apparently necessary for me I really cannot hack sh though. Sorry. I've tried several times through the years. I just can't stand these languages where pretty much everything is a string. e.g. sh, Tcl, cmd. I admit hypocrisy in that I can and have hacked cmd. So I started rewriting scripts/* in Python. I'm not going to delete scripts/*.sh or anything THAT obnoxious (and get my access revoked), just add a new scripts/python directory. Tempting to call it scripts/jay. I'm making good progess here. Actually I started with Perl, which I have more experience with, but it was frustrating and... Anyway, so the real point here is, I'm reading scripts/* fairly closely. I'd like to at times bounce my interpretation off folks. In particular, I detect some wierdness. Most variables can be set by the caller. I assume that is mostly meant for the user to override things. I agree that is mostly a good thing. However it seems often data is derived, and then later overrides can kick in. In particular, sysinfo.sh sets, e.g. M3OSTYPE and other data based on uname. And it sets CM3_TARGET. But TARGET is then set via the user override, or CM3_TARGET if no user override. I draw one of two conclusions: If a user sets TARGET, such as for a cross build, then user darn well better set other variables manually to. OR sysinfo.sh ought to check for TARGET being set, and derive data from that. It should check preset TARGET or uname, not both. I'm just going to leave it alone. Presumably mostly the overrides are never set. They are mainly for cross builds and/or bringing up new targets probably. There aren't THAT MANY variables anyway. Many could be removed, such as TAR, GREP, CM3*SEARCHPATH, etc. Some are only for Win32. Maybe after this I'll try rewriting scripts in Quake. :) - Jay _________________________________________________________________ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_122007 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Dec 28 11:19:53 2007 From: jayk123 at hotmail.com (Jay) Date: Fri, 28 Dec 2007 10:19:53 +0000 Subject: [M3devel] wierdness around user overrides vs. uname in sysinfo.sh? In-Reply-To: References: Message-ID: hm. another odd email truncation Let me try again.. I wanted to change upgrade.sh to have the following features: 1) optionally skip building m3cc, since it is the slowest part 2) optionally clean between various steps, as was apparently necessary for me I really cannot hack sh though. Sorry. I've tried several times through the years. I just can't stand these languages where pretty much everything is a string. e.g. sh, Tcl, cmd. I admit hypocrisy in that I can and have hacked cmd. So I started rewriting scripts/* in Python. I'm not going to delete scripts/*.sh or anything THAT obnoxious (and get my access revoked), just add a new scripts/python directory. Tempting to call it scripts/jay. I'm making good progess here. Actually I started with Perl, which I have more experience with, but it was frustrating and... Anyway, so the real point here is, I'm reading scripts/* fairly closely (I can read sh well enough.) I'd like to at times bounce my interpretation off folks. In particular, I detect some wierdness. Most variables can be set by the caller. I assume that is mostly meant for the user to override things. I agree that is mostly a good thing. However it seems often data is derived, and then later overrides can kick in. In particular, sysinfo.sh sets, e.g. M3OSTYPE and other data based on uname. And it sets CM3_TARGET. But TARGET is then set via the user override, or CM3_TARGET if no user override. I draw one of two conclusions: If a user sets TARGET, such as for a cross build, then user darn well better set other variables manually too. OR sysinfo.sh ought to check for TARGET being set, and derive data from that. It should check preset TARGET or uname, not both. I'm just going to leave it alone. Presumably mostly the overrides are never set. They are mainly for cross builds and/or bringing up new targets probably. There aren't THAT MANY variables anyway. Many could be removed, such as TAR, GREP, CM3*SEARCHPATH, etc. Some are only for Win32. Maybe after this I'll try rewriting scripts in Quake. :) - Jay _________________________________________________________________ The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. http://www.xbox.com/en-US/hardware/wheretobuy/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Dec 28 12:13:43 2007 From: jayk123 at hotmail.com (Jay) Date: Fri, 28 Dec 2007 11:13:43 +0000 Subject: [M3devel] wierdness around user overrides vs. uname in sysinfo.sh? In-Reply-To: References: Message-ID: wierd.still shows as truncated for me Trying again with a different browser.. I wanted to change upgrade.sh to have the following features: 1) optionally skip building m3cc, since it is the slowest part 2) optionally clean between various steps, as was apparently necessary for me I really cannot hack sh though. Sorry. I've tried several times through the years. I just can't stand these languages where pretty much everything is a string. e.g. sh, Tcl, cmd. I admit hypocrisy in that I can and have hacked cmd. So I started rewriting scripts/* in Python. I'm not going to delete scripts/*.sh or anything THAT obnoxious (and get my access revoked), just add a new scripts/python directory. Tempting to call it scripts/jay. I'm making good progess here. Actually I started with Perl, which I have more experience with, but it was frustrating and... Anyway, so the real point here is, I'm reading scripts/* fairly closely. I'd like to at times bounce my interpretation off folks. In particular, I detect some massive wierdness. Most variables can be set by the caller. I assume that is mostly meant for the user to override things. I agree that is mostly a good thing. However it seems often data is derived, and then later overrides can kick in. In particular, sysinfo.sh sets, e.g. M3OSTYPE and other data based on uname. And it sets CM3_TARGET. But TARGET is then set via the user override, or CM3_TARGET if no user override. I draw one of two conclusions: If a user sets TARGET, such as for a cross build, then user darn well better set other variables manually to. OR sysinfo.sh ought to check for TARGET being set, and derive data from that. It should check preset TARGET or uname, not both. I'm just going to leave it alone. Presumably mostly the overrides are never set. They are mainly for cross builds and/or bringing up new targets probably. There aren't THAT MANY variables anyway. Many could be removed, such as TAR, GREP, CM3*SEARCHPATH, etc. Some are only for Win32. Maybe after this I'll try rewriting scripts in Quake. :) - Jay _________________________________________________________________ The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. http://www.xbox.com/en-US/hardware/wheretobuy/ From jayk123 at hotmail.com Fri Dec 28 12:13:44 2007 From: jayk123 at hotmail.com (Jay) Date: Fri, 28 Dec 2007 11:13:44 +0000 Subject: [M3devel] wierdness around user overrides vs. uname in sysinfo.sh? In-Reply-To: References: Message-ID: wierd.still shows as truncated for me Trying again with a different browser.. I wanted to change upgrade.sh to have the following features: 1) optionally skip building m3cc, since it is the slowest part 2) optionally clean between various steps, as was apparently necessary for me I really cannot hack sh though. Sorry. I've tried several times through the years. I just can't stand these languages where pretty much everything is a string. e.g. sh, Tcl, cmd. I admit hypocrisy in that I can and have hacked cmd. So I started rewriting scripts/* in Python. I'm not going to delete scripts/*.sh or anything THAT obnoxious (and get my access revoked), just add a new scripts/python directory. Tempting to call it scripts/jay. I'm making good progess here. Actually I started with Perl, which I have more experience with, but it was frustrating and... Anyway, so the real point here is, I'm reading scripts/* fairly closely. I'd like to at times bounce my interpretation off folks. In particular, I detect some massive wierdness. Most variables can be set by the caller. I assume that is mostly meant for the user to override things. I agree that is mostly a good thing. However it seems often data is derived, and then later overrides can kick in. In particular, sysinfo.sh sets, e.g. M3OSTYPE and other data based on uname. And it sets CM3_TARGET. But TARGET is then set via the user override, or CM3_TARGET if no user override. I draw one of two conclusions: If a user sets TARGET, such as for a cross build, then user darn well better set other variables manually to. OR sysinfo.sh ought to check for TARGET being set, and derive data from that. It should check preset TARGET or uname, not both. I'm just going to leave it alone. Presumably mostly the overrides are never set. They are mainly for cross builds and/or bringing up new targets probably. There aren't THAT MANY variables anyway. Many could be removed, such as TAR, GREP, CM3*SEARCHPATH, etc. Some are only for Win32. Maybe after this I'll try rewriting scripts in Quake. :) - Jay _________________________________________________________________ Don't get caught with egg on your face. Play Chicktionary! http://club.live.com/chicktionary.aspx?icid=chick_wlhmtextlink1_dec From jayk123 at hotmail.com Fri Dec 28 12:17:53 2007 From: jayk123 at hotmail.com (Jay) Date: Fri, 28 Dec 2007 11:17:53 +0000 Subject: [M3devel] =?windows-1256?q?_Re=3A__wierdness_around_user_override?= =?windows-1256?q?s_vs=2E_uname_in_sysinfo=2Esh=3F=FE?= In-Reply-To: References: Message-ID: [another tactic attempted...] ---------------------------------------- > From: jayk123 at hotmail.com > To: jayk123 at hotmail.com > Subject: test > Date: Fri, 28 Dec 2007 11:15:58 +0000 > > > I wanted to change upgrade.sh to have the following features: > > 1) optionally skip building m3cc, since it is the slowest part > > 2) optionally clean between various steps, as was apparently necessary for me > > I really cannot hack sh though. Sorry. I've tried several times through the years. > I just can't stand these languages where pretty much everything is a string. > e.g. sh, Tcl, cmd. > I admit hypocrisy in that I can and have hacked cmd. > > So I started rewriting scripts/* in Python. > I'm not going to delete scripts/*.sh or anything THAT obnoxious (and get my > access revoked), just add a new scripts/python directory. > Tempting to call it scripts/jay. > I'm making good progess here. > > Actually I started with Perl, which I have more experience with, but > it was frustrating and... > > Anyway, so the real point here is, I'm reading scripts/* fairly closely. > > I'd like to at times bounce my interpretation off folks. > > In particular, I detect some massive wierdness. > > Most variables can be set by the caller. > I assume that is mostly meant for the user to override things. > I agree that is mostly a good thing. > > However it seems often data is derived, and then later overrides can kick in. > > In particular, sysinfo.sh sets, e.g. M3OSTYPE and other data based on uname. > And it sets CM3_TARGET. > But TARGET is then set via the user override, or CM3_TARGET if no user override. > > I draw one of two conclusions: > > If a user sets TARGET, such as for a cross build, then user darn well better > set other variables manually to. > > OR sysinfo.sh ought to check for TARGET being set, and derive data from that. > It should check preset TARGET or uname, not both. > > I'm just going to leave it alone. > > Presumably mostly the overrides are never set. > They are mainly for cross builds and/or bringing up new targets probably. > > There aren't THAT MANY variables anyway. > Many could be removed, such as TAR, GREP, CM3*SEARCHPATH, etc. > Some are only for Win32. > > Maybe after this I'll try rewriting scripts in Quake. :) > > - Jay > _________________________________________________________________ > Share life as it happens with the new Windows Live. > http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007 _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007 From wagner at elegosoft.com Fri Dec 28 17:35:40 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 28 Dec 2007 17:35:40 +0100 Subject: [M3devel] =?utf-8?q?wierdness_around_user_overrides_vs=2E_uname_i?= =?utf-8?b?biBzeXNpbmZvLnNoP+KAjw==?= In-Reply-To: References: Message-ID: <20071228173540.eesjz81kuso8okg4@mail.elegosoft.com> Quoting Jay : > > [another tactic attempted...] > > ---------------------------------------- >> From: jayk123 at hotmail.com >> To: jayk123 at hotmail.com >> Subject: test >> Date: Fri, 28 Dec 2007 11:15:58 +0000 >> >> >> I wanted to change upgrade.sh to have the following features: >> >> 1) optionally skip building m3cc, since it is the slowest part export OMIT_GCC=yes will do just that for all shell scripts, IIRC. >> 2) optionally clean between various steps, as was apparently >> necessary for me It should not be difficult to add that. Something like . "$ROOT/scripts/do-cm3-core.sh" realclean || exit 1 should do the trick. >> I really cannot hack sh though. Sorry. I've tried several times >> through the years. >> I just can't stand these languages where pretty much everything is a string. >> e.g. sh, Tcl, cmd. >> I admit hypocrisy in that I can and have hacked cmd. >> >> So I started rewriting scripts/* in Python. >> I'm not going to delete scripts/*.sh or anything THAT obnoxious (and get my >> access revoked), just add a new scripts/python directory. >> Tempting to call it scripts/jay. >> I'm making good progess here. No harm in that. You may either put the python scripts beside the shell scripts and simply call them *.py, or put them in a subdirectory python or py. Don't call it Jay. >> Actually I started with Perl, which I have more experience with, but >> it was frustrating and... >> >> Anyway, so the real point here is, I'm reading scripts/* fairly closely. >> >> I'd like to at times bounce my interpretation off folks. >> >> In particular, I detect some massive wierdness. >> >> Most variables can be set by the caller. >> I assume that is mostly meant for the user to override things. >> I agree that is mostly a good thing. >> >> However it seems often data is derived, and then later overrides >> can kick in. These are just some simple and useful scripts for maintenance; there was never an overall system design. >> In particular, sysinfo.sh sets, e.g. M3OSTYPE and other data based on uname. >> And it sets CM3_TARGET. >> But TARGET is then set via the user override, or CM3_TARGET if no >> user override. >> >> I draw one of two conclusions: >> >> If a user sets TARGET, such as for a cross build, then user darn well better >> set other variables manually to. >> >> OR sysinfo.sh ought to check for TARGET being set, and derive data >> from that. >> It should check preset TARGET or uname, not both. >> >> I'm just going to leave it alone. If you find obvious inconsistencies or mistakes, don't hesitate to suggest a correction. >> Presumably mostly the overrides are never set. >> They are mainly for cross builds and/or bringing up new targets probably. Cross building is the usual way of porting the compiler to a new target, so it's done more often than you might assume. I've done it lots of times. >> There aren't THAT MANY variables anyway. >> Many could be removed, such as TAR, GREP, CM3*SEARCHPATH, etc. >> Some are only for Win32. >> >> Maybe after this I'll try rewriting scripts in Quake. :) That would be interesting, too. But don't forget that all these scripts are just more or less simple tools for installation and maintenance; the important asset is in all the M3 code. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Fri Dec 28 17:55:16 2007 From: jayk123 at hotmail.com (Jay) Date: Fri, 28 Dec 2007 16:55:16 +0000 Subject: [M3devel] wierdness around user overrides vs. uname in sysinfo.sh? In-Reply-To: <20071228173540.eesjz81kuso8okg4@mail.elegosoft.com> References: <20071228173540.eesjz81kuso8okg4@mail.elegosoft.com> Message-ID: inline (but aggressively trimmed) > Date: Fri, 28 Dec 2007 17:35:40 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > > Quoting Jay : > > export OMIT_GCC=yes > > will do just that for all shell scripts, IIRC. Ah, thanks, will try that. > >> 2) optionally clean between various steps, as was apparently > >> necessary for me > > It should not be difficult to add that. Something like > > . "$ROOT/scripts/do-cm3-core.sh" realclean || exit 1 > > should do the trick. Yeah, I have that locally, but I wanted to make it an option since perhaps/apparently it isn't always needed, and therefore wastes time. And then I got all bogged down in how the command line parsing is shared and I didn't want to add a parameter to every script, and I couldn't figure out how to check the command line ahead of time and then remove what I recognize. Like, if I could assign empty strings to $1 or $2 or $3, would be nice..but seems not possible..and then it just comes back to my strong suspicion that sh just sucks and isn't worth the effort. > don't forget that all these scripts are just... > ...the important asset is in all the M3 code. I know...but... Modula-3 is really slow to grow on me.. this has actually been a very useful exercise in my long delayed adoption of Python. I got my dynamic linking/pic issues worked out and once I get to porting make-bin-dist I'll have it work like my Win32 version -- just a .tar.bz2 file that you extract in the install root or above the install root (still not sure about the archive's root being cm3 or cm3-version or within that).. really, cminstall seems pretty pointless... Index: upgrade.sh =================================================================== RCS file: /usr/cvs/cm3/scripts/upgrade.sh,v retrieving revision 1.3 diff -c -r1.3 upgrade.sh *** upgrade.sh 16 Dec 2007 17:56:24 -0000 1.3 --- upgrade.sh 28 Dec 2007 16:51:34 -0000 *************** *** 28,34 **** some accidental diff here.. *************** *** 50,61 **** --- 50,72 ---- P="${P} cm3" [ "${M3OSTYPE}" = "WIN32" ] && P="${P} mklib" + echo "$ROOT/scripts/do-pkg.sh" "$@" "realclean ${P}" + . "$ROOT/scripts/do-pkg.sh" "$@" "realclean" ${P} || exit 1 + + exit + echo "$ROOT/scripts/do-pkg.sh" "$@" "buildship ${P}" . "$ROOT/scripts/do-pkg.sh" "$@" "buildship" ${P} || exit 1 echo "$ROOT/scripts/install-cm3-compiler.sh" $OPTIONS upgrade "$ROOT/scripts/install-cm3-compiler.sh" $OPTIONS upgrade || exit 1 + echo "$ROOT/scripts/do-pkg.sh" "$@" "realclean ${P}" + . "$ROOT/scripts/do-pkg.sh" "$@" "realclean" ${P} || exit 1 + + echo "$ROOT/scripts/do-cm3-core.sh" "$@" "realclean" + . "$ROOT/scripts/do-cm3-core.sh" "$@" "realclean" || exit 1 + echo "$ROOT/scripts/do-cm3-core.sh" "$@" "buildship" . "$ROOT/scripts/do-cm3-core.sh" "$@" "buildship" || exit 1 - Jay _________________________________________________________________ i?m is proud to present Cause Effect, a series about real people making a difference. http://im.live.com/Messenger/IM/MTV/?source=text_Cause_Effect -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Dec 31 10:48:26 2007 From: jayk123 at hotmail.com (Jay) Date: Mon, 31 Dec 2007 09:48:26 +0000 Subject: [M3devel] cvs question: how to know what I have changed on my machine? In-Reply-To: <20071230163328.GB5689@elegosoft.com> References: <20071230163328.GB5689@elegosoft.com> Message-ID: I swear I looked for this on the web, several times. :) What is the right/fast way to see what I have changed in cvs? Is it really to go to the top of the tree and say cvs diff? Some source control system I have used, makes "checked in" filesread only, requires you to "check out", and keeps track of whatyou checked out.This model seems quite nice.There is a fallback if the network is needed and not available.It is a little annoying, the inevitable failed save, but it is well worth it. I've been doing cvs diff but it seem terribly inefficient. Same question for Subversion, though I haven't looked.It at least seems to rapidly know what I have changed, on my puny tree,and I know it also saves away all the originals, so diff is a client only operation. Oh another question -- how to view history?Like, what i keep doing is navigating to individual files on the web.It's fairly tedious.It'd be nice if checkins at right about the same time, with the same comment,where packaged up in the ui, like Perforce (well, for it, it is just one change)....I usually look at the diffs after commit, besides before. Thanks, - Jay _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Dec 31 21:29:59 2007 From: jayk123 at hotmail.com (Jay) Date: Mon, 31 Dec 2007 20:29:59 +0000 Subject: [M3devel] C/C++ interop/linking thoughts? Message-ID: C/C++ interop/linking thoughts? What are people's thoughts on interop with and C and C++? In particular, that of static linking C and C++ with Modula-3, in the same .dll/.so/.exe?Or that of loading a Modula-3 .dll/.so into a process that is otherwise just C and C++? I ask for NOT the most important of reasons. The Modula-3 dependency on the C runtime on Windows is pretty light, and it is in fact mostly for the startup code. The startup code doesn't do much. Mainly it runs C++ constructors/destructors. And C code can have initializers/cleanup. I think it might be interesting to drive this dependency to zero, but it depends on expectations of C and C++ statically linked into a Modula-3 .dll/.so/.exe working. I know there is C code in the system already. It is light. It works without the startup code in my experience. I already changed Modula-3 .dlls to build with /noentry..exes take a bit more.It's in the config file. There are comments in the config file about it, including the contrary point of a C generating back end . On a very related note, I almost forgot..on Mac OS X, there is shared or static libgcc. The man pages say roughly this: g++ and gcj (Java) specify shared libgcc by default gcc specifies static libgcc by default C++ and Java favor shared in order to enable throwing/catching exceptions across .dll/.so boundaries. "Pure" Modula-3 code wouldn't care about that. Modula-3 code linking with C++ might. Perhaps in these scenarios, the "build system" and linking will tend to escape cm3 anyway?Make Modula-3 static .libs/.a with cm3 but not link the final file with it? I think the current config file links .dylibs(.dll/.so, but usually .dylib in this context, at least by convention) with static libgcc and executables with shared. I found in groveling over the results that, there were four or six functions imported from shared libgcc, little math helpers for division or such. It seems not worth depending on another file for just a few small functions. Just use static? On a less related note, for anyone who likes to go down such paths, I concluded that calling ld directly on Mac OS X is not a great idea, best stick to calling gcc (or g++/whatever) to do the linking, as the current files do. - Jay _________________________________________________________________ i?m is proud to present Cause Effect, a series about real people making a difference. http://im.live.com/Messenger/IM/MTV/?source=text_Cause_Effect -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Dec 31 12:04:53 2007 From: jayk123 at hotmail.com (Jay) Date: Mon, 31 Dec 2007 11:04:53 +0000 Subject: [M3devel] "where to root archives?" In-Reply-To: <20071230162432.C498A10D4596@birch.elegosoft.com> References: <20071230162432.C498A10D4596@birch.elegosoft.com> Message-ID: "where to root archives?" Maybe this is along the lines of "how to format my code?" Religous and unanswerable and strong proponents of every answer? but: A) *.zip|*.tar.gz|*.tar.bz2 shall be named cm3.* or B) cm3-.* ok, no question here, B is it. And shall contain the structure: 1) more than one file/directory at the root bin/cm3(.exe) pkg/libm3/... or 2) root contains only one directory, and it has a version in its name (and target probably) cm3-/bin/cm3(.exe) cm3-/pkg/libm3/.. or 3) root contains only one directory, with no version in its name cm3/bin/cm3(.exe) cm3/pkg/libm3/.. #1 is what the current cminstall-using distributions use I believe.Since it is wrapped by an installer, doesn't really matter.Note though that the enclosing archive is also formed this way I think, but with fewer than 10 files. It seems clearly the worst, unless you know about the tar -C or unzip -d switches, though tar -C doesn'tcreate the output directory, unzip -d does. #2 is VERY popular and tempting for me #3 is what the Win32 builds use currently (scripts/win/make-dist.cmd) It has the advantage of being more directly useable. cd \ unzip cm3-.zip and it goes into \cm3, a reasonable default, but could be preexisting (unzip does prompt I think) If it went to cm3-version, you'd probably want to either rename it, or create a link to it, Window having varying support for different types of links on different versions, not sure if use is widespread. fsutil hardlink create creates file hard links on XP+ mklink creates hardlinks and symlinks on Vista+ probably only file hardlinks and file or directory symlinks At some point, directory links were avoided because a) not required by Posix? b) allows creating cycles I see cycles now on my default installs and have crashed stuff as a result. :( junction from www.sysinternals.com creates directory linkes on...Win2000+? (This is all NTFS only of course, or over SMB to other file systems; actually stupid fsutil demands a local file system, even though underlying CreateHardLink works over SMB..) #2 seems safer, and user can immediatley rename to #3 after extraction. Oh, and in the Explorer GUI, the default is to extract in a directory with the same name as the basename of the archive.That makes #1 slightly better and the others slightly worse. Inevitably it seems the command line is doomed to always check before extracting anyway.. unzip -l foo.zip | more tar tfz foo.tar.gz | more Besides that, it still impresses and bugs me how much smaller .tar.bz2 is vs. anything else...but the Explorer support or .zip filesis also somewhat compelling...except that you have to use the command line with CM3 anyway.... - Jay _________________________________________________________________ The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. http://www.xbox.com/en-US/hardware/wheretobuy/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Dec 19 04:30:19 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 19 Dec 2007 03:30:19 -0000 Subject: [M3devel] Unix signals and Modula-3... In-Reply-To: <200712182343.lBINhJDL084804@camembert.async.caltech.edu> References: <200712182343.lBINhJDL084804@camembert.async.caltech.edu> Message-ID: The system threads pthread implementation uses a signal and a semaphore to stop/start threads for GC, Other than that, I don't believe signals are being used anywhere else in the run-time system. Also, I should point out that there may be value in retaining the current user-level threads implementation for all targets (we still need to fix some to use setcontext/getcontext instead of setjmp/ getjmp), in which case the same issue applies. I wonder if it makes sense to implement a variant of waitpid inside the threads implementation to do the right thing. We could use a signal there to catch SIGCHLD appropriately in the ThreadPosix implementation and leave it alone with ThreadPThread. What do you think? On Dec 18, 2007, at 6:43 PM, Mika Nystrom wrote: > > Ah yes, you are right. The original issue is that waitpid would > hang the whole runtime and that should not happen with system > threads. If using system threads, waitpid should be called with a > third argument of zero, I believe. Is this already happening? > If not, make the change and if you have a fast machine you may > see a spectacular speedup in your compile times. > > I suppose the easiest solution to this problem is simply to move > all active targets to system threads... > > Still, there are some other areas where Unix signals might be of > interest. I am thinking of things like interfacing with readline > and other C-based libraries that use signals for concurrency. When > I put a readline interface on some Modula-3 programs, I wound up > using an external C program to do readline processing and then > communicating over a pipe or TCP connection, because dealing > with signals seemed like such a hassle. > > Mika > > Tony Hosking writes: >> I'm assuming that waitpid hanging when using system threads is not a >> problem, since the system thread scheduler will schedule other >> threads around the waiting one. The issue is only for the user-level >> threads implementation where a thread blocking on a waitpid call >> would prevent other threads being scheduled. >> >> On Dec 18, 2007, at 7:38 AM, Mika Nystrom wrote: >> >>> Hello everyone, >>> >>> I am in the process of bootstrapping the CVS head of CM3 on an old >>> FreeBSD-4.11 system, and at one point, when I replaced the old cm3 >>> with the new cm3, the compiler got slower. Not a little bit slower, >>> mind you, but about 10x slower. I remember pointing this out to >>> the m3devel list... oh it must have been three or four years ago; >>> one of our grad students at Caltech (Karl Papadantonakis, also >>> author of the caltech-parser) was the first to notice what was going >>> on. >>> >>> It has to do with Process.Wait. (From ProcessPosix.m3.) To repeat >>> what I said a few years ago, the problem lies here: >>> >>> CONST Delay = 0.1D0; >>> BEGIN >>> IF NOT p.waitOk THEN RAISE WaitAlreadyCalled END; >>> p.waitOk := FALSE; >>> (* By rights, the SchedulerPosix interface should have a WaitPID >>> procedure that is integrated with the thread scheduler. *) >>> LOOP >>> result := Uexec.waitpid(p.pid, ADR(statusT), Uexec.WNOHANG); >>> IF result # 0 THEN EXIT END; >>> Thread.Pause(Delay) >>> END; >>> <* ASSERT result > 0 *> >>> >>> In other words: if Process.Wait is called before the child process >>> is done, then the thread pauses 0.1 seconds. >>> >>> In our local version of m3build, we duplicate the Wait code and set >>> the Delay to 0.0. That's OK in a compiler, but it's not OK in >>> general, because you would chew up the CPU on a machine that was >>> doing a lot of long-term waiting. >>> >>> The problem is that the fix that I suggested way back when requires >>> messing with Unix signals (catching SIGC[H]LD instead of using >>> waitpid), which is why I never submitted a fix to the repository, >>> because I am not sure what such a fix might interact with. It seems >>> to me that the correct way of dealing with Unix signals is to have >>> a single thread that talks to the Unix system, registers signal >>> handlers, and takes care, via some object-oriented mechanism, of >>> calling back any M3 threads that are interested in the signals. >>> Would such a thing be possible? Where are signals used in the >>> system today? >>> >>> Mika From jay.krell at cornell.edu Sat Dec 1 03:59:45 2007 From: jay.krell at cornell.edu (Jay) Date: Sat, 1 Dec 2007 02:59:45 +0000 Subject: [M3devel] some more notes on the win32 system In-Reply-To: <4750474F.1E75.00D7.1@scires.com> References: <036701c83256$d553bbf0$7ffb33d0$@com> <4750474F.1E75.00D7.1@scires.com> Message-ID: I don't setup stuff with spaces mostly, but it doesn't matter. In the past, as the install and configuration nudged you, cminstall/cm3.exe/cm3.cfg trafficed in the full paths to cl.exe, link.exe, various .libs, and possibly directories containing .h. In the present, cm3.cfg invokes merely "cl" or "cl.exe", "link" or "link.exe", does not pass any include paths to the compiler, and passes leaf file names of .libs to the linker -- msvcrt.lib, kernel32.lib, etc. If course there must be another side to that. "vcvars32.bat" and such sets %PATH% so that cl and link are on it, sets %INCLUDE% so that the various headers are on it, and %LIB% so that various .libs are on it. My sysinfo.cmd also prepends %ROOT%\lib or whatever to %LIB%, as cm3\m3-win\import-libs makes our own import .libs, since some toolsets, like at least the 7.1 Express Edition and I think 8.0, lack most the usual import .libs -- like they are enough for managed CLR development and "stdio" development, but not native Win32 development. The Platform SDK is also a free download, so I'm not replacing something you can't get for free, but it saves you an extra download and install, perhaps. There are pluses and minuses to this arrangement. I guess you can point cm3.exe at a specific cm3.cfg file? I never do that. Rather than have n different configurations, I have one configuration but vary the environment variables. The downside is that in a "bare" environment, nothing works. Unless you go and foist the vcvars32.bat onto your default environment. There is large general problem around settings, state, install (sometimes called "deployment) that has yet to be solved to most people's satisfaction. This is very much related to that. Environment variables are an ancient crude mechanism, lacking in type, lacking in hierarchy. Their main claims to fame include a) basically the same mechanism on Unix and Win32 b) inheritance through a process tree.) They don't scale well I believe. Anyway, I'm not going to solve this and I doubt any of you will either. Given that the spaces end up buried in %PATH%, %LIB%, and %INCLUDE%, where cmd, cl, link look and can cope, but where cm3 itself doesn't look at, the space problem is solved. I install to \msdev\10 \msdev\15 \msdev\20 \msdev\40 \msdev\41 \msdev\42 \msdev\50 \msdev\60 \msdev\70 \msdev\71 \msdev\80 \mwerks\6 (metrowerks, not that I use it much) \mwerks\7 \mwerks\8 \dm or \dmars (digital mars, no versioning) \cygwin (the default, no versioning) \mingwin (the default, no versioning) etc. I haven't yet settled on a grand unified file system layout for myself, though I do obsess over it, and sometimes give in to the defaults, can't fight every battle, not as often as I resetup machines.. and I haven't figured out what to do about source control and tools. Ideally, you checkin all your tools, but I'm not sure what that implies for copyright, esp. given a hosted source control system I don't control, and it'll bloat up my cheap hosted source control.. I do let the Platform SDK install to its default like \Program Files\Microsoft Platform SDK R2. Bootstrapping current source from the 5.2.6 "min" binary distribution should work. I tested this last night. Should work from the larger "std", "core", etc. whatever there is. I didn't try anything before 5.2.6. There is a question as to which toolsets to support -- which toolset to build the distribution with. The older you pick, the more reach you have to people using older toolsets. However there seems to only be about three of us so I'm barking up a very hypothetical tree.. :( As well a question as to what you can bootstrap with, which Modula-3 tools. I imagine the more you go back, the more contorted things get, and there might be really nothing to gain. Just pick the most recent good enough version and don't care about anything older? Look forward not backward? I haven't seen many problems with %TEMP% and %TMP%. They do often somewhere get changed to short paths. But I did recently have a problem with spaces in them. Realize that "short paths" are NOT predictable. And, btw, they aren't even necessarily "shorter" than the "long" path, though they do lack spaces, etc. Try this: mkdir \1.1.1 dir /x \1* - Jay Date: Fri, 30 Nov 2007 17:24:25 -0500From: rcoleburn at scires.comTo: jay.krell at cornell.edu; m3devel at elegosoft.comSubject: Re: [M3devel] some more notes on the win32 system Jay: Thanks for all your help. Actually, the last time I tried to install cm3, I used the 5.26 tarballs and tried to build, but ran into some compile errors. I'll try it again and report back the actual errors I get (if any). As for Microsoft Visual Studio, yes I'm familiar with setting it up. Are you saying that the cm3install program should no longer be used? I've used this in the past. The big issue I've run into is making sure to give old style 8.3 pathnames without spaces and to edit the cm3.cfg file to find all the libraries and stuff using paths without spaces. I've also set some environment vars, in particular the TEMP and TMP vars, to use paths without spaces. I will try to be very careful to document everything I do in great detail. Perhaps we can use this to give out a better recipe to folks on how to get cm3 working on Windows. Regards, Randy>>> Jay 11/29/2007 8:48 PM >>>some more notes on the win32 system> setup your C++ compiler/linkerYou can/should "play dumb", skip that, and just run upgrade.See what errors you get.I tried to put in the right amount of up front sanity checking.What you need in particular arecl and link on the %PATH%. See, cminstall would have you specify full paths, my configuration uses %PATH%.If using VS2005 (8) or newer, mt on the path.%LIB% is a semicolon delimited list of directories.That is a feature of the Microsoft linker.msvcrt.lib must be in one of them.Any 32 bit version of Visual C++ -- 2.0, 4.0,, 4.1, 4.2, 5.0, 6.0, 7.0, 7.1, 8.0 -- should work.I have tested all of them some and many required small changes in one particular spot, that actually is only used by "maintainers" (C:\dev2\cm3\m3-win\import-libs\src\make-lib-1.cmd).I use 8.0 the most lately.I haven't done much with 9.0. Another thing, fairly redundant: C:\dev2\cm3\m3-win>more vcredist.txtOn computers without Visual C++ 2005 or CLR 2.0 installed, download and run the setup for the Visual C++ runtime -- vcredist_x86.exe -- from either RTM (release to manufacturing): http://www.microsoft.com/downloads/details.aspx?familyid=32BC1BEE-A3F9-4C13-9C99-220B62A191EE or Service Pack 1: http://www.microsoft.com/downloads/details.aspx?FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647You can find those searching the web for vcredist, no real need to recort the URLs. That's about it. - Jay Your smile counts. The more smiles you share, the more we donate. Join in! _________________________________________________________________ Your smile counts. The more smiles you share, the more we donate.? Join in. www.windowslive.com/smile?ocid=TXT_TAGLM_Wave2_oprsmilewlhmtagline -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Dec 1 14:15:47 2007 From: jay.krell at cornell.edu (Jay) Date: Sat, 1 Dec 2007 13:15:47 +0000 Subject: [M3devel] returning record by value vs. by ref? Message-ID: This is a language question based on the x86 code gen.It isn't a code gen question at all, just related to m3 constructs the code gen happens to use. The code gen has a stack of operands, I've said many times. This is partly made up. type loc_t = [ imm, reg, mvar ] (* location: variable in memory, register, immediate/constant *) type reg_t = [ eax, esi, edi, ...] (* register *) type operand_t = record loc : loc_t; reg : reg_t; imm : integer; (* immediate or constant *) (* some data associated with mvar... *) end; The type is a bit bigger than this, and that is relevant. interface stack allows access both to entire operands, or their fields, based on an index into the stack. The stack is not fixed size. I think this becomes important. Pardon my mix of M3, C, C++ and made up syntax. interface and module stack; private s: array of operand; procedure getloc(n: integer) : loc_t = begin return s[n].loc; end getloc; procedure getimm(n: integer) : INTEGER = begin return s[n].imm; end getimm; procedure getreg(n: integer) : reg_t = begin return s[n].reg; end getreg; procedure getop(n: integer) : operand_t = (* get entire operand *) begin return s[n]; end getop; A cursory read of the source code, not yet of the object code, from the point of view of a C/C++ programmersays to me that this last function getop returns a copy of an entire record. Again, the record is a bit largerthan this. I made it still larger, and I started getting warnings about that. What I would really like is for getop to return the operands by pointer. procedure getop(n: integer) : REF operand_t = (* get entire operand *) begin return s[n]; end getop; From my point of view, this is very natural. And far more efficient. But I couldn't get anything to compile along these lines. Now, as I said, the stack does grow sometimes, so the array could get realloced, and outstanding pointers invalidated. I guess that is the point? You can't "safely" get a pointer? I could make it an array of REFs I guess, heap-fragmentation-unfriendly, but given that it grows rarely, probably ok. I guess maybe gcc does a good job with this stuff? Optimzing away the copies, inlining the array access, etc.? Thoughts? One just needs to get over worrying about the perf at this level for one's sanity to survive programming in Modula-3? Safe languages are simply stuck with either a lot of garbage collected separate heap allocations or a lot of copying? Pointers as I think about them exude "danger" all over the place? (Yes, I know that "safely" and "danger" are technical terms and I know what they mean, at least roughly, no dangling pointers to stack, no double frees, no unbounded array access, no unchecked type conversions, the system remains type safe and the rules of the language remain unbroken, however I live and breathe C/C++ so it is hard to adjust my mindset, even if I understand the issues fairly deeply.) The problem one runs into, is that of the pretty darn good C and C++ programmers who, whilenot perfect, are pretty darn good. A "safe" language throws you to quite an extremeof perf compromise to nail the last little bit of guaranteed safety, when you really weren't doing sucha bad job in the first place through brute force of careful coding.. You pay a lot for a little.Lesser programmers, sure, they need the hand holding... I've been experimenting lately, and C just isn't actually all that bad.Ok, actually most recently I'm writing more Perl, also not bad.See, there's another extreme. Traditional and semi-traditional languageand compilation systems like C and Modula-3 and even Java and C# actuallyobsess far more about performance than many many problems need.Perl (Python, Ruby presumably, but Perl is the only one available to me,that has cleared legal/licensing hurdles) is plenty adequate for tons of tasks.If my task requires some i/o, then i/o cost might dominate the overall perf cost... I realize I'm all over the place here, arguing for and against optimizing. I don't like Perl's funny characters, or lack of a standard OO approach,(using hash tables for everything really is bad..) but it's still surprisingly good.I noticed some job descriptions lately for Perl programmers that specificallysaid they were not "scripting" jobs but, like, real industrial strength software engineering.I think those people get it.You get to a certain point of general purposeness and performance and hopefullystatic checking, and a lot things don't matter as much as people think.... Anyway. - Jay _________________________________________________________________ Share life as it happens with the new Windows Live.Download today it's FREE! http://www.windowslive.com/share.html?ocid=TXT_TAGLM_Wave2_sharelife_112007 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Dec 1 17:03:44 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 1 Dec 2007 11:03:44 -0500 Subject: [M3devel] returning record by value vs. by ref? In-Reply-To: References: Message-ID: <1560FF15-8486-4388-ADAE-FADCF71FC5F3@cs.purdue.edu> I am assuming 's' here is an open array (REF ARRAY OF item) in which case it is allocated in the GC'd heap. There is certainly no way of safely getting an interior pointer to items in the stack in Modula-3 -- at least not one that you can upward expose (to callers) via return from a procedure. The difficulty in doing this is that the GC moves objects around and would need to know where your manufactured interior pointer is being held and to which *object* (ie, the open array in this case) it refers so that it can 'fix' the pointer when the array object moves. Modula-3 provides a small concession to obtaining downward exposed interior pointers using the VAR parameter mode. For example you can pass 's[i]' as an actual parameter to a VAR mode formal, effectively passing a pointer to the callee. GC can cope with this in one of two possible ways: 1) "Pin" the array so that it cannot be moved while the interior pointer is held on the stack or registers of any thread (this is the approach that CM3's conservative collector uses for now); or 2) track the creation of such interior pointers and how they are derived from base object references for use during GC. 2) requires much more co-operation from the compiler than the current gcc-based backend (with all of its lovely optimizations and register allocation) is capable of doing. 1) is very cheap and does not impede optimizations and register allocation. On Dec 1, 2007, at 8:15 AM, Jay wrote: > This is a language question based on the x86 code gen. > It isn't a code gen question at all, just related to m3 constructs > the code gen happens to use. > > The code gen has a stack of operands, I've said many times. > > This is partly made up. > > type loc_t = [ imm, reg, mvar ] (* location: variable in memory, > register, immediate/constant *) > type reg_t = [ eax, esi, edi, ...] (* register *) > > type operand_t = record > loc : loc_t; > reg : reg_t; > imm : integer; (* immediate or constant *) > (* some data associated with mvar... *) > end; > > The type is a bit bigger than this, and that is relevant. > > interface stack allows access both to entire operands, or their > fields, based on an index into the stack. > > The stack is not fixed size. I think this becomes important. > > Pardon my mix of M3, C, C++ and made up syntax. > > interface and module stack; > > private s: array of operand; > > procedure getloc(n: integer) : loc_t = > begin > return s[n].loc; > end getloc; > > procedure getimm(n: integer) : INTEGER = > begin > return s[n].imm; > end getimm; > > procedure getreg(n: integer) : reg_t = > begin > return s[n].reg; > end getreg; > > procedure getop(n: integer) : operand_t = (* get entire operand *) > begin > return s[n]; > end getop; > > A cursory read of the source code, not yet of the object code, > from the point of view of a C/C++ programmer > says to me that this last function getop returns a copy of an > entire record. Again, the record is a bit larger > than this. I made it still larger, and I started getting warnings > about that. > > What I would really like is for getop to return the operands by > pointer. > > procedure getop(n: integer) : REF operand_t = (* get entire > operand *) > begin > return s[n]; > end getop; > > From my point of view, this is very natural. And far more efficient. > But I couldn't get anything to compile along these lines. > > Now, as I said, the stack does grow sometimes, so the array could > get realloced, and outstanding > pointers invalidated. I guess that is the point? You can't > "safely" get a pointer? > I could make it an array of REFs I guess, heap-fragmentation- > unfriendly, but given that it grows > rarely, probably ok. > > I guess maybe gcc does a good job with this stuff? Optimzing away > the copies, inlining the array access, etc.? > > Thoughts? > One just needs to get over worrying about the perf at this level > for one's sanity > to survive programming in Modula-3? > > Safe languages are simply stuck with either a lot of garbage > collected separate heap allocations > or a lot of copying? Pointers as I think about them exude "danger" > all over the place? > (Yes, I know that "safely" and "danger" are technical terms and I > know what they mean, > at least roughly, no dangling pointers to stack, no double frees, > no unbounded > array access, no unchecked type conversions, the system remains > type safe and > the rules of the language remain unbroken, however I live and > breathe C/C++ so it > is hard to adjust my mindset, even if I understand the issues > fairly deeply.) > > The problem one runs into, is that of the pretty darn good C and C+ > + programmers who, while > not perfect, are pretty darn good. A "safe" language throws you to > quite an extreme > of perf compromise to nail the last little bit of guaranteed > safety, when you really weren't doing such > a bad job in the first place through brute force of careful > coding.. You pay a lot for a little. > Lesser programmers, sure, they need the hand holding... > > I've been experimenting lately, and C just isn't actually all that > bad. > Ok, actually most recently I'm writing more Perl, also not bad. > See, there's another extreme. Traditional and semi-traditional > language > and compilation systems like C and Modula-3 and even Java and C# > actually > obsess far more about performance than many many problems need. > Perl (Python, Ruby presumably, but Perl is the only one available > to me, > that has cleared legal/licensing hurdles) is plenty adequate for > tons of tasks. > If my task requires some i/o, then i/o cost might dominate the > overall perf cost... > > I realize I'm all over the place here, arguing for and against > optimizing. > > I don't like Perl's funny characters, or lack of a standard OO > approach, > (using hash tables for everything really is bad..) but it's still > surprisingly good. > I noticed some job descriptions lately for Perl programmers that > specifically > said they were not "scripting" jobs but, like, real industrial > strength software engineering. > I think those people get it. > You get to a certain point of general purposeness and performance > and hopefully > static checking, and a lot things don't matter as much as people > think.... > > Anyway. > - Jay > > > Share life as it happens with the new Windows Live. Share now! From rodney.bates at wichita.edu Sat Dec 1 20:31:39 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Sat, 01 Dec 2007 13:31:39 -0600 Subject: [M3devel] returning record by value vs. by ref? In-Reply-To: <1560FF15-8486-4388-ADAE-FADCF71FC5F3@cs.purdue.edu> References: <1560FF15-8486-4388-ADAE-FADCF71FC5F3@cs.purdue.edu> Message-ID: <4751B69B.1090907@wichita.edu> Tony Hosking wrote: > I am assuming 's' here is an open array (REF ARRAY OF item) in which > case it is allocated in the GC'd heap. There is certainly no way of > safely getting an interior pointer to items in the stack in Modula-3 -- > at least not one that you can upward expose (to callers) via return > from a procedure. The difficulty in doing this is that the GC moves > objects around and would need to know where your manufactured interior > pointer is being held and to which *object* (ie, the open array in this > case) it refers so that it can 'fix' the pointer when the array object > moves. Modula-3 provides a small concession to obtaining downward > exposed interior pointers using the VAR parameter mode. For example > you can pass 's[i]' as an actual parameter to a VAR mode formal, > effectively passing a pointer to the callee. GC can cope with this in > one of two possible ways: 1) "Pin" the array so that it cannot be moved > while the interior pointer is held on the stack or registers of any > thread (this is the approach that CM3's conservative collector uses for > now); or 2) track the creation of such interior pointers and how they > are derived from base object references for use during GC. 2) requires > much more co-operation from the compiler than the current gcc-based > backend (with all of its lovely optimizations and register allocation) > is capable of doing. 1) is very cheap and does not impede > optimizations and register allocation. > Presumably, this all also applies WITH-bound identifiers, when they are designators of interior components of heap objects? Are there any other cases? -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From hosking at cs.purdue.edu Sat Dec 1 21:23:19 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 1 Dec 2007 15:23:19 -0500 Subject: [M3devel] returning record by value vs. by ref? In-Reply-To: <4751B69B.1090907@wichita.edu> References: <1560FF15-8486-4388-ADAE-FADCF71FC5F3@cs.purdue.edu> <4751B69B.1090907@wichita.edu> Message-ID: Correct! Anytime you create an l-value pointer. On Dec 1, 2007, at 2:31 PM, Rodney M. Bates wrote: > Tony Hosking wrote: >> I am assuming 's' here is an open array (REF ARRAY OF item) in >> which case it is allocated in the GC'd heap. There is certainly >> no way of safely getting an interior pointer to items in the >> stack in Modula-3 -- at least not one that you can upward expose >> (to callers) via return from a procedure. The difficulty in >> doing this is that the GC moves objects around and would need to >> know where your manufactured interior pointer is being held and >> to which *object* (ie, the open array in this case) it refers so >> that it can 'fix' the pointer when the array object moves. >> Modula-3 provides a small concession to obtaining downward >> exposed interior pointers using the VAR parameter mode. For >> example you can pass 's[i]' as an actual parameter to a VAR mode >> formal, effectively passing a pointer to the callee. GC can cope >> with this in one of two possible ways: 1) "Pin" the array so that >> it cannot be moved while the interior pointer is held on the >> stack or registers of any thread (this is the approach that CM3's >> conservative collector uses for now); or 2) track the creation of >> such interior pointers and how they are derived from base object >> references for use during GC. 2) requires much more co-operation >> from the compiler than the current gcc-based backend (with all of >> its lovely optimizations and register allocation) is capable of >> doing. 1) is very cheap and does not impede optimizations and >> register allocation. > > Presumably, this all also applies WITH-bound identifiers, when they > are > designators of interior components of heap objects? Are there any > other > cases? > > -- > ------------------------------------------------------------- > Rodney M. Bates, retired assistant professor > Dept. of Computer Science, Wichita State University > Wichita, KS 67260-0083 > 316-978-3922 > rodney.bates at wichita.edu From jay.krell at cornell.edu Sat Dec 1 23:14:18 2007 From: jay.krell at cornell.edu (Jay) Date: Sat, 1 Dec 2007 22:14:18 +0000 Subject: [M3devel] returning record by value vs. by ref? In-Reply-To: References: <1560FF15-8486-4388-ADAE-FADCF71FC5F3@cs.purdue.edu> <4751B69B.1090907@wichita.edu> Message-ID: 1) Can pinning not be exposed reasonably in the language? I'll keep my pointer just a short time, in a local. 2) surely it could be done at an outer layer? Make volatile locals for things you don't want enregistered? Even the accessor function approach seems lame, given that I believe the Win32/x86 compiler doesn't inline.. :( (does the gcc m3 inline across modules, or just compiles one at a time?) - Jay > CC: jay.krell at cornell.edu; m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] returning record by value vs. by ref?> Date: Sat, 1 Dec 2007 15:23:19 -0500> To: rodney.bates at wichita.edu> > Correct! Anytime you create an l-value pointer.> > On Dec 1, 2007, at 2:31 PM, Rodney M. Bates wrote:> > > Tony Hosking wrote:> >> I am assuming 's' here is an open array (REF ARRAY OF item) in > >> which case it is allocated in the GC'd heap. There is certainly > >> no way of safely getting an interior pointer to items in the > >> stack in Modula-3 -- at least not one that you can upward expose > >> (to callers) via return from a procedure. The difficulty in > >> doing this is that the GC moves objects around and would need to > >> know where your manufactured interior pointer is being held and > >> to which *object* (ie, the open array in this case) it refers so > >> that it can 'fix' the pointer when the array object moves. > >> Modula-3 provides a small concession to obtaining downward > >> exposed interior pointers using the VAR parameter mode. For > >> example you can pass 's[i]' as an actual parameter to a VAR mode > >> formal, effectively passing a pointer to the callee. GC can cope > >> with this in one of two possible ways: 1) "Pin" the array so that > >> it cannot be moved while the interior pointer is held on the > >> stack or registers of any thread (this is the approach that CM3's > >> conservative collector uses for now); or 2) track the creation of > >> such interior pointers and how they are derived from base object > >> references for use during GC. 2) requires much more co-operation > >> from the compiler than the current gcc-based backend (with all of > >> its lovely optimizations and register allocation) is capable of > >> doing. 1) is very cheap and does not impede optimizations and > >> register allocation.> >> > Presumably, this all also applies WITH-bound identifiers, when they > > are> > designators of interior components of heap objects? Are there any > > other> > cases?> >> > -- > > -------------------------------------------------------------> > Rodney M. Bates, retired assistant professor> > Dept. of Computer Science, Wichita State University> > Wichita, KS 67260-0083> > 316-978-3922> > rodney.bates at wichita.edu> _________________________________________________________________ Your smile counts. The more smiles you share, the more we donate.? Join in. www.windowslive.com/smile?ocid=TXT_TAGLM_Wave2_oprsmilewlhmtagline -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Dec 1 23:19:46 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 1 Dec 2007 17:19:46 -0500 Subject: [M3devel] returning record by value vs. by ref? In-Reply-To: References: <1560FF15-8486-4388-ADAE-FADCF71FC5F3@cs.purdue.edu> <4751B69B.1090907@wichita.edu> Message-ID: On Dec 1, 2007, at 5:14 PM, Jay wrote: > 1) Can pinning not be exposed reasonably in the language? > I'll keep my pointer just a short time, in a local. Yes, that is a *hack* that will work only with the current conservative garbage collector. In general, the compiler might record that the local is a pointer derived from some base reference and if the GC decides to move the base object it can adjust the local derived pointer accordingly. > 2) surely it could be done at an outer layer? > Make volatile locals for things you don't want enregistered? I don't understand what you mean by this. > Even the accessor function approach seems lame, given that I > believe the Win32/x86 compiler doesn't inline.. :( > (does the gcc m3 inline across modules, or just compiles one at a > time?) gcc m3 inlines only within compilation units. > > > - Jay > > > > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] returning record by value vs. by ref? > > Date: Sat, 1 Dec 2007 15:23:19 -0500 > > To: rodney.bates at wichita.edu > > > > Correct! Anytime you create an l-value pointer. > > > > On Dec 1, 2007, at 2:31 PM, Rodney M. Bates wrote: > > > > > Tony Hosking wrote: > > >> I am assuming 's' here is an open array (REF ARRAY OF item) in > > >> which case it is allocated in the GC'd heap. There is certainly > > >> no way of safely getting an interior pointer to items in the > > >> stack in Modula-3 -- at least not one that you can upward expose > > >> (to callers) via return from a procedure. The difficulty in > > >> doing this is that the GC moves objects around and would need to > > >> know where your manufactured interior pointer is being held and > > >> to which *object* (ie, the open array in this case) it refers so > > >> that it can 'fix' the pointer when the array object moves. > > >> Modula-3 provides a small concession to obtaining downward > > >> exposed interior pointers using the VAR parameter mode. For > > >> example you can pass 's[i]' as an actual parameter to a VAR mode > > >> formal, effectively passing a pointer to the callee. GC can cope > > >> with this in one of two possible ways: 1) "Pin" the array so that > > >> it cannot be moved while the interior pointer is held on the > > >> stack or registers of any thread (this is the approach that CM3's > > >> conservative collector uses for now); or 2) track the creation of > > >> such interior pointers and how they are derived from base object > > >> references for use during GC. 2) requires much more co-operation > > >> from the compiler than the current gcc-based backend (with all of > > >> its lovely optimizations and register allocation) is capable of > > >> doing. 1) is very cheap and does not impede optimizations and > > >> register allocation. > > > > > > Presumably, this all also applies WITH-bound identifiers, when > they > > > are > > > designators of interior components of heap objects? Are there any > > > other > > > cases? > > > > > > -- > > > ------------------------------------------------------------- > > > Rodney M. Bates, retired assistant professor > > > Dept. of Computer Science, Wichita State University > > > Wichita, KS 67260-0083 > > > 316-978-3922 > > > rodney.bates at wichita.edu > > > > > Your smile counts. The more smiles you share, the more we donate. > Join in! From jay.krell at cornell.edu Sat Dec 1 23:36:03 2007 From: jay.krell at cornell.edu (Jay) Date: Sat, 1 Dec 2007 22:36:03 +0000 Subject: [M3devel] returning record by value vs. by ref? In-Reply-To: References: <1560FF15-8486-4388-ADAE-FADCF71FC5F3@cs.purdue.edu> <4751B69B.1090907@wichita.edu> Message-ID: > 2, don't understand You said it'd take much cooperation with the compiler, due its optimizations, but optimizations can be defeated as necessary. Interior pointers could be marked, perhaps, volatile, so prevent enregistration. I can see that's a potentially high cost though. like Record_t *Record = GetRecord(); unsigned i; for (i = 0 ; i != Record->j ; ++i) { ... } You'd really like Record->j to not be refetched for every loop iteration, but if Record is volatile so the GC can move what it points to and update outstanding pointers, you'd be stuck with something like that. Besides, if j can't be read in one instruction, more problems, assuming a concurrent GC, that cannot reliably get/set the context of other threads. I think, like, you could reliably get/set context on a uniprocessor system, but not a multiprocessor. You'd have to suspend, wait for the suspend to happen.. I guess that could work, but it seems like you'd want to avoid designs that require suspending threads. ? Hm. No, it's difficult. This being a short lived pointer, gc happening on another thread, you'd have to, like, "register" its location with the gc. Hm. Just how does it work? gc suspends threads and updates variables? I don't think so. Variables that are moved leave some sort of "forwarding address" for holders of the old value? The gc isn't concurrent but is called at function entry/exit? I don't think so. I should check the docs and code.. - Jay > From: hosking at cs.purdue.edu> Date: Sat, 1 Dec 2007 17:19:46 -0500> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] returning record by value vs. by ref?> > > On Dec 1, 2007, at 5:14 PM, Jay wrote:> > > 1) Can pinning not be exposed reasonably in the language?> > I'll keep my pointer just a short time, in a local.> > Yes, that is a *hack* that will work only with the current > conservative garbage collector. In general, the compiler might > record that the local is a pointer derived from some base reference > and if the GC decides to move the base object it can adjust the local > derived pointer accordingly.> > > 2) surely it could be done at an outer layer?> > Make volatile locals for things you don't want enregistered?> > I don't understand what you mean by this.> > > Even the accessor function approach seems lame, given that I > > believe the Win32/x86 compiler doesn't inline.. :(> > (does the gcc m3 inline across modules, or just compiles one at a > > time?)> > gcc m3 inlines only within compilation units.> > >> >> > - Jay> >> >> > > CC: jay.krell at cornell.edu; m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > Subject: Re: [M3devel] returning record by value vs. by ref?> > > Date: Sat, 1 Dec 2007 15:23:19 -0500> > > To: rodney.bates at wichita.edu> > >> > > Correct! Anytime you create an l-value pointer.> > >> > > On Dec 1, 2007, at 2:31 PM, Rodney M. Bates wrote:> > >> > > > Tony Hosking wrote:> > > >> I am assuming 's' here is an open array (REF ARRAY OF item) in> > > >> which case it is allocated in the GC'd heap. There is certainly> > > >> no way of safely getting an interior pointer to items in the> > > >> stack in Modula-3 -- at least not one that you can upward expose> > > >> (to callers) via return from a procedure. The difficulty in> > > >> doing this is that the GC moves objects around and would need to> > > >> know where your manufactured interior pointer is being held and> > > >> to which *object* (ie, the open array in this case) it refers so> > > >> that it can 'fix' the pointer when the array object moves.> > > >> Modula-3 provides a small concession to obtaining downward> > > >> exposed interior pointers using the VAR parameter mode. For> > > >> example you can pass 's[i]' as an actual parameter to a VAR mode> > > >> formal, effectively passing a pointer to the callee. GC can cope> > > >> with this in one of two possible ways: 1) "Pin" the array so that> > > >> it cannot be moved while the interior pointer is held on the> > > >> stack or registers of any thread (this is the approach that CM3's> > > >> conservative collector uses for now); or 2) track the creation of> > > >> such interior pointers and how they are derived from base object> > > >> references for use during GC. 2) requires much more co-operation> > > >> from the compiler than the current gcc-based backend (with all of> > > >> its lovely optimizations and register allocation) is capable of> > > >> doing. 1) is very cheap and does not impede optimizations and> > > >> register allocation.> > > >> > > > Presumably, this all also applies WITH-bound identifiers, when > > they> > > > are> > > > designators of interior components of heap objects? Are there any> > > > other> > > > cases?> > > >> > > > --> > > > -------------------------------------------------------------> > > > Rodney M. Bates, retired assistant professor> > > > Dept. of Computer Science, Wichita State University> > > > Wichita, KS 67260-0083> > > > 316-978-3922> > > > rodney.bates at wichita.edu> > >> >> >> > Your smile counts. The more smiles you share, the more we donate. > > Join in!> _________________________________________________________________ Put your friends on the big screen with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_102007 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Dec 1 23:42:02 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 1 Dec 2007 17:42:02 -0500 Subject: [M3devel] returning record by value vs. by ref? In-Reply-To: References: <1560FF15-8486-4388-ADAE-FADCF71FC5F3@cs.purdue.edu> <4751B69B.1090907@wichita.edu> Message-ID: If this really interests you then you might read this paper: http:// doi.acm.org/10.1145/143095.143140 . On Dec 1, 2007, at 5:36 PM, Jay wrote: > > 2, don't understand > > You said it'd take much cooperation with the compiler, due its > optimizations, but optimizations can be defeated as necessary. > Interior pointers could be marked, perhaps, volatile, so prevent > enregistration. I can see that's a potentially high cost though. > > like > Record_t *Record = GetRecord(); > unsigned i; > for (i = 0 ; i != Record->j ; ++i) > { > ... > } > > You'd really like Record->j to not be refetched for every loop > iteration, but if Record is volatile so the GC can move what it > points to and update outstanding pointers, you'd be stuck with > something like that. Besides, if j can't be read in one > instruction, more problems, assuming a concurrent GC, that cannot > reliably get/set the context of other threads. I think, like, you > could reliably get/set context on a uniprocessor system, but not a > multiprocessor. You'd have to suspend, wait for the suspend to > happen.. I guess that could work, but it seems like you'd want to > avoid designs that require suspending threads. ? > Hm. No, it's difficult. This being a short lived pointer, gc > happening on another thread, you'd have to, like, "register" its > location with the gc. > > Hm. Just how does it work? > > gc suspends threads and updates variables? I don't think so. > > Variables that are moved leave some sort of "forwarding address" > for holders of the old value? > > The gc isn't concurrent but is called at function entry/exit? I > don't think so. > > I should check the docs and code.. > > - Jay > > > > > From: hosking at cs.purdue.edu > > Date: Sat, 1 Dec 2007 17:19:46 -0500 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] returning record by value vs. by ref? > > > > > > On Dec 1, 2007, at 5:14 PM, Jay wrote: > > > > > 1) Can pinning not be exposed reasonably in the language? > > > I'll keep my pointer just a short time, in a local. > > > > Yes, that is a *hack* that will work only with the current > > conservative garbage collector. In general, the compiler might > > record that the local is a pointer derived from some base reference > > and if the GC decides to move the base object it can adjust the > local > > derived pointer accordingly. > > > > > 2) surely it could be done at an outer layer? > > > Make volatile locals for things you don't want enregistered? > > > > I don't understand what you mean by this. > > > > > Even the accessor function approach seems lame, given that I > > > believe the Win32/x86 compiler doesn't inline.. :( > > > (does the gcc m3 inline across modules, or just compiles one at a > > > time?) > > > > gcc m3 inlines only within compilation units. > > > > > > > > > > > - Jay > > > > > > > > > > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > > > > From: hosking at cs.purdue.edu > > > > Subject: Re: [M3devel] returning record by value vs. by ref? > > > > Date: Sat, 1 Dec 2007 15:23:19 -0500 > > > > To: rodney.bates at wichita.edu > > > > > > > > Correct! Anytime you create an l-value pointer. > > > > > > > > On Dec 1, 2007, at 2:31 PM, Rodney M. Bates wrote: > > > > > > > > > Tony Hosking wrote: > > > > >> I am assuming 's' here is an open array (REF ARRAY OF > item) in > > > > >> which case it is allocated in the GC'd heap. There is > certainly > > > > >> no way of safely getting an interior pointer to items in the > > > > >> stack in Modula-3 -- at least not one that you can upward > expose > > > > >> (to callers) via return from a procedure. The difficulty in > > > > >> doing this is that the GC moves objects around and would > need to > > > > >> know where your manufactured interior pointer is being > held and > > > > >> to which *object* (ie, the open array in this case) it > refers so > > > > >> that it can 'fix' the pointer when the array object moves. > > > > >> Modula-3 provides a small concession to obtaining downward > > > > >> exposed interior pointers using the VAR parameter mode. For > > > > >> example you can pass 's[i]' as an actual parameter to a > VAR mode > > > > >> formal, effectively passing a pointer to the callee. GC > can cope > > > > >> with this in one of two possible ways: 1) "Pin" the array > so that > > > > >> it cannot be moved while the interior pointer is held on the > > > > >> stack or registers of any thread (this is the approach > that CM3's > > > > >> conservative collector uses for now); or 2) track the > creation of > > > > >> such interior pointers and how they are derived from base > object > > > > >> references for use during GC. 2) requires much more co- > operation > > > > >> from the compiler than the current gcc-based backend (with > all of > > > > >> its lovely optimizations and register allocation) is > capable of > > > > >> doing. 1) is very cheap and does not impede optimizations and > > > > >> register allocation. > > > > > > > > > > Presumably, this all also applies WITH-bound identifiers, when > > > they > > > > > are > > > > > designators of interior components of heap objects? Are > there any > > > > > other > > > > > cases? > > > > > > > > > > -- > > > > > ------------------------------------------------------------- > > > > > Rodney M. Bates, retired assistant professor > > > > > Dept. of Computer Science, Wichita State University > > > > > Wichita, KS 67260-0083 > > > > > 316-978-3922 > > > > > rodney.bates at wichita.edu > > > > > > > > > > > > > Your smile counts. The more smiles you share, the more we donate. > > > Join in! > > > > > Get the power of Windows + Web with the new Windows Live. Power up! From jay.krell at cornell.edu Sun Dec 2 05:11:04 2007 From: jay.krell at cornell.edu (Jay) Date: Sun, 2 Dec 2007 04:11:04 +0000 Subject: [M3devel] returning record by value vs. by ref? In-Reply-To: References: <1560FF15-8486-4388-ADAE-FADCF71FC5F3@cs.purdue.edu> <4751B69B.1090907@wichita.edu> Message-ID: Thanks! I haven't finished reading it, but it sounds like an optimizing compiler is ok, due to the reliance on "gc points", which I read ahead to find out how they are defined. And I'm GUESSING that CM3 already generates and depends on the sort of data described there. But maybe not. I wonder what the size of the data looks like if you allow a gc point at every instruction. I guess it probably be too large -- figure a byte or two extra for every instruction, but maybe not. Perhaps it could be encoded in bits instead of bytes and given that most instructions don't affect the state (ie: operations on integers, floats, comparisons, branches), maybe just a zero bit for most instructions. So then figure a byte or two for every instruction that moves (load or store) or adds/substracts a pointer. Or more than that. A byte or two could describe enregistration and small adds/subtracts, but not large adds/subtracts or memory offsets. OR perhaps it'd just read the code itself. That's easier with Win32/x86 since it is so constrained as to what it outputs. That should be feasible. I realize I'm changing subjects between the different backends. The Windows AMD64 calling convention relies on something LIKE this. In particular, there is a little encoding associated with every prolog/epilog so that exception handling can undo the prolog's effects. It describes a tiny subset of the instruction set, like register moves. Kind of funny -- once you get into the business of wanting to read the code to know what it does, you then get tempted to define your own code, for runtime and information, and then a possible trick is to adopt the existing machine code as your code, or whatever subset your compiler produces. Hm. The existing machine isn't sufficient. You would need type information to augment it. Which reminds. Another OBVIOUS backend for CM3 for easier portability is to persist the calls to m3cg and then write an interpreter for that in C. - Jay > From: hosking at cs.purdue.edu> Date: Sat, 1 Dec 2007 17:42:02 -0500> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] returning record by value vs. by ref?> > If this really interests you then you might read this paper: http:// > doi.acm.org/10.1145/143095.143140 .> > On Dec 1, 2007, at 5:36 PM, Jay wrote:> > > > 2, don't understand> >> > You said it'd take much cooperation with the compiler, due its > > optimizations, but optimizations can be defeated as necessary.> > Interior pointers could be marked, perhaps, volatile, so prevent > > enregistration. I can see that's a potentially high cost though.> >> > like> > Record_t *Record = GetRecord();> > unsigned i;> > for (i = 0 ; i != Record->j ; ++i)> > {> > ...> > }> >> > You'd really like Record->j to not be refetched for every loop > > iteration, but if Record is volatile so the GC can move what it > > points to and update outstanding pointers, you'd be stuck with > > something like that. Besides, if j can't be read in one > > instruction, more problems, assuming a concurrent GC, that cannot > > reliably get/set the context of other threads. I think, like, you > > could reliably get/set context on a uniprocessor system, but not a > > multiprocessor. You'd have to suspend, wait for the suspend to > > happen.. I guess that could work, but it seems like you'd want to > > avoid designs that require suspending threads. ?> > Hm. No, it's difficult. This being a short lived pointer, gc > > happening on another thread, you'd have to, like, "register" its > > location with the gc.> >> > Hm. Just how does it work?> >> > gc suspends threads and updates variables? I don't think so.> >> > Variables that are moved leave some sort of "forwarding address" > > for holders of the old value?> >> > The gc isn't concurrent but is called at function entry/exit? I > > don't think so.> >> > I should check the docs and code..> >> > - Jay> >> >> >> > > From: hosking at cs.purdue.edu> > > Date: Sat, 1 Dec 2007 17:19:46 -0500> > > To: jay.krell at cornell.edu> > > CC: m3devel at elegosoft.com> > > Subject: Re: [M3devel] returning record by value vs. by ref?> > >> > >> > > On Dec 1, 2007, at 5:14 PM, Jay wrote:> > >> > > > 1) Can pinning not be exposed reasonably in the language?> > > > I'll keep my pointer just a short time, in a local.> > >> > > Yes, that is a *hack* that will work only with the current> > > conservative garbage collector. In general, the compiler might> > > record that the local is a pointer derived from some base reference> > > and if the GC decides to move the base object it can adjust the > > local> > > derived pointer accordingly.> > >> > > > 2) surely it could be done at an outer layer?> > > > Make volatile locals for things you don't want enregistered?> > >> > > I don't understand what you mean by this.> > >> > > > Even the accessor function approach seems lame, given that I> > > > believe the Win32/x86 compiler doesn't inline.. :(> > > > (does the gcc m3 inline across modules, or just compiles one at a> > > > time?)> > >> > > gcc m3 inlines only within compilation units.> > >> > > >> > > >> > > > - Jay> > > >> > > >> > > > > CC: jay.krell at cornell.edu; m3devel at elegosoft.com> > > > > From: hosking at cs.purdue.edu> > > > > Subject: Re: [M3devel] returning record by value vs. by ref?> > > > > Date: Sat, 1 Dec 2007 15:23:19 -0500> > > > > To: rodney.bates at wichita.edu> > > > >> > > > > Correct! Anytime you create an l-value pointer.> > > > >> > > > > On Dec 1, 2007, at 2:31 PM, Rodney M. Bates wrote:> > > > >> > > > > > Tony Hosking wrote:> > > > > >> I am assuming 's' here is an open array (REF ARRAY OF > > item) in> > > > > >> which case it is allocated in the GC'd heap. There is > > certainly> > > > > >> no way of safely getting an interior pointer to items in the> > > > > >> stack in Modula-3 -- at least not one that you can upward > > expose> > > > > >> (to callers) via return from a procedure. The difficulty in> > > > > >> doing this is that the GC moves objects around and would > > need to> > > > > >> know where your manufactured interior pointer is being > > held and> > > > > >> to which *object* (ie, the open array in this case) it > > refers so> > > > > >> that it can 'fix' the pointer when the array object moves.> > > > > >> Modula-3 provides a small concession to obtaining downward> > > > > >> exposed interior pointers using the VAR parameter mode. For> > > > > >> example you can pass 's[i]' as an actual parameter to a > > VAR mode> > > > > >> formal, effectively passing a pointer to the callee. GC > > can cope> > > > > >> with this in one of two possible ways: 1) "Pin" the array > > so that> > > > > >> it cannot be moved while the interior pointer is held on the> > > > > >> stack or registers of any thread (this is the approach > > that CM3's> > > > > >> conservative collector uses for now); or 2) track the > > creation of> > > > > >> such interior pointers and how they are derived from base > > object> > > > > >> references for use during GC. 2) requires much more co- > > operation> > > > > >> from the compiler than the current gcc-based backend (with > > all of> > > > > >> its lovely optimizations and register allocation) is > > capable of> > > > > >> doing. 1) is very cheap and does not impede optimizations and> > > > > >> register allocation.> > > > > >> > > > > > Presumably, this all also applies WITH-bound identifiers, when> > > > they> > > > > > are> > > > > > designators of interior components of heap objects? Are > > there any> > > > > > other> > > > > > cases?> > > > > >> > > > > > --> > > > > > -------------------------------------------------------------> > > > > > Rodney M. Bates, retired assistant professor> > > > > > Dept. of Computer Science, Wichita State University> > > > > > Wichita, KS 67260-0083> > > > > > 316-978-3922> > > > > > rodney.bates at wichita.edu> > > > >> > > >> > > >> > > > Your smile counts. The more smiles you share, the more we donate.> > > > Join in!> > >> >> >> > Get the power of Windows + Web with the new Windows Live. Power up!> _________________________________________________________________ You keep typing, we keep giving. Download Messenger and join the i?m Initiative now. http://im.live.com/messenger/im/home/?source=TAGLM -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 2 06:16:05 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 2 Dec 2007 00:16:05 -0500 Subject: [M3devel] returning record by value vs. by ref? In-Reply-To: References: <1560FF15-8486-4388-ADAE-FADCF71FC5F3@cs.purdue.edu> <4751B69B.1090907@wichita.edu> Message-ID: <2B3B82B5-B989-4AC9-8156-02B3B8AC5B46@cs.purdue.edu> On Dec 1, 2007, at 11:11 PM, Jay wrote: > Thanks! > > I haven't finished reading it, but it sounds like an optimizing > compiler is ok, due > to the reliance on "gc points", which I read ahead to find out how > they are defined. If you want fully accurate (non-ambiguous roots) GC then yes you need gc-points to avoid having to store pointer information for every PC location. > And I'm GUESSING that CM3 already generates and depends on the sort > of data described there. > But maybe not. Umm, no. CM3 uses an ambiguous roots technique for thread stacks/ registers that avoids the need for gc-points. Hence, we can use preemptive system-level thread scheduling. > I wonder what the size of the data looks like if you allow a gc > point at every instruction. > I guess it probably be too large -- figure a byte or two extra for > every instruction, but maybe not. > > Perhaps it could be encoded in bits instead of bytes and given that > most instructions don't affect the state > (ie: operations on integers, floats, comparisons, branches), maybe > just a zero bit for most instructions. > So then figure a byte or two for every instruction that moves (load > or store) or adds/substracts a pointer. > Or more than that. A byte or two could describe enregistration and > small adds/subtracts, but not large adds/subtracts > or memory offsets. > > OR perhaps it'd just read the code itself. That's easier with Win32/ > x86 since it is so constrained > as to what it outputs. That should be feasible. I realize I'm > changing subjects between the different backends. > > The Windows AMD64 calling convention relies on something LIKE this. > In particular, there is a little encoding associated with every > prolog/epilog so that exception handling can undo the prolog's > effects. > It describes a tiny subset of the instruction set, like register > moves. > > Kind of funny -- once you get into the business of wanting to read > the code to know what it does, > you then get tempted to define your own code, for runtime and > information, and then a possible trick > is to adopt the existing machine code as your code, or whatever > subset your compiler produces. > Hm. The existing machine isn't sufficient. You would need type > information to augment it. > > Which reminds. Another OBVIOUS backend for CM3 for easier > portability is to persist the calls to m3cg and then > write an interpreter for that in C. > > - Jay > > > > From: hosking at cs.purdue.edu > > Date: Sat, 1 Dec 2007 17:42:02 -0500 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] returning record by value vs. by ref? > > > > If this really interests you then you might read this paper: http:// > > doi.acm.org/10.1145/143095.143140 . > > > > On Dec 1, 2007, at 5:36 PM, Jay wrote: > > > > > > 2, don't understand > > > > > > You said it'd take much cooperation with the compiler, due its > > > optimizations, but optimizations can be defeated as necessary. > > > Interior pointers could be marked, perhaps, volatile, so prevent > > > enregistration. I can see that's a potentially high cost though. > > > > > > like > > > Record_t *Record = GetRecord(); > > > unsigned i; > > > for (i = 0 ; i != Record->j ; ++i) > > > { > > > ... > > > } > > > > > > You'd really like Record->j to not be refetched for every loop > > > iteration, but if Record is volatile so the GC can move what it > > > points to and update outstanding pointers, you'd be stuck with > > > something like that. Besides, if j can't be read in one > > > instruction, more problems, assuming a concurrent GC, that cannot > > > reliably get/set the context of other threads. I think, like, you > > > could reliably get/set context on a uniprocessor system, but not a > > > multiprocessor. You'd have to suspend, wait for the suspend to > > > happen.. I guess that could work, but it seems like you'd want to > > > avoid designs that require suspending threads. ? > > > Hm. No, it's difficult. This being a short lived pointer, gc > > > happening on another thread, you'd have to, like, "register" its > > > location with the gc. > > > > > > Hm. Just how does it work? > > > > > > gc suspends threads and updates variables? I don't think so. > > > > > > Variables that are moved leave some sort of "forwarding address" > > > for holders of the old value? > > > > > > The gc isn't concurrent but is called at function entry/exit? I > > > don't think so. > > > > > > I should check the docs and code.. > > > > > > - Jay > > > > > > > > > > > > > From: hosking at cs.purdue.edu > > > > Date: Sat, 1 Dec 2007 17:19:46 -0500 > > > > To: jay.krell at cornell.edu > > > > CC: m3devel at elegosoft.com > > > > Subject: Re: [M3devel] returning record by value vs. by ref? > > > > > > > > > > > > On Dec 1, 2007, at 5:14 PM, Jay wrote: > > > > > > > > > 1) Can pinning not be exposed reasonably in the language? > > > > > I'll keep my pointer just a short time, in a local. > > > > > > > > Yes, that is a *hack* that will work only with the current > > > > conservative garbage collector. In general, the compiler might > > > > record that the local is a pointer derived from some base > reference > > > > and if the GC decides to move the base object it can adjust the > > > local > > > > derived pointer accordingly. > > > > > > > > > 2) surely it could be done at an outer layer? > > > > > Make volatile locals for things you don't want enregistered? > > > > > > > > I don't understand what you mean by this. > > > > > > > > > Even the accessor function approach seems lame, given that I > > > > > believe the Win32/x86 compiler doesn't inline.. :( > > > > > (does the gcc m3 inline across modules, or just compiles > one at a > > > > > time?) > > > > > > > > gcc m3 inlines only within compilation units. > > > > > > > > > > > > > > > > > > > - Jay > > > > > > > > > > > > > > > > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > > > > > > From: hosking at cs.purdue.edu > > > > > > Subject: Re: [M3devel] returning record by value vs. by ref? > > > > > > Date: Sat, 1 Dec 2007 15:23:19 -0500 > > > > > > To: rodney.bates at wichita.edu > > > > > > > > > > > > Correct! Anytime you create an l-value pointer. > > > > > > > > > > > > On Dec 1, 2007, at 2:31 PM, Rodney M. Bates wrote: > > > > > > > > > > > > > Tony Hosking wrote: > > > > > > >> I am assuming 's' here is an open array (REF ARRAY OF > > > item) in > > > > > > >> which case it is allocated in the GC'd heap. There is > > > certainly > > > > > > >> no way of safely getting an interior pointer to items > in the > > > > > > >> stack in Modula-3 -- at least not one that you can upward > > > expose > > > > > > >> (to callers) via return from a procedure. The > difficulty in > > > > > > >> doing this is that the GC moves objects around and would > > > need to > > > > > > >> know where your manufactured interior pointer is being > > > held and > > > > > > >> to which *object* (ie, the open array in this case) it > > > refers so > > > > > > >> that it can 'fix' the pointer when the array object > moves. > > > > > > >> Modula-3 provides a small concession to obtaining > downward > > > > > > >> exposed interior pointers using the VAR parameter > mode. For > > > > > > >> example you can pass 's[i]' as an actual parameter to a > > > VAR mode > > > > > > >> formal, effectively passing a pointer to the callee. GC > > > can cope > > > > > > >> with this in one of two possible ways: 1) "Pin" the array > > > so that > > > > > > >> it cannot be moved while the interior pointer is held > on the > > > > > > >> stack or registers of any thread (this is the approach > > > that CM3's > > > > > > >> conservative collector uses for now); or 2) track the > > > creation of > > > > > > >> such interior pointers and how they are derived from base > > > object > > > > > > >> references for use during GC. 2) requires much more co- > > > operation > > > > > > >> from the compiler than the current gcc-based backend > (with > > > all of > > > > > > >> its lovely optimizations and register allocation) is > > > capable of > > > > > > >> doing. 1) is very cheap and does not impede > optimizations and > > > > > > >> register allocation. > > > > > > > > > > > > > > Presumably, this all also applies WITH-bound > identifiers, when > > > > > they > > > > > > > are > > > > > > > designators of interior components of heap objects? Are > > > there any > > > > > > > other > > > > > > > cases? > > > > > > > > > > > > > > -- > > > > > > > > ------------------------------------------------------------- > > > > > > > Rodney M. Bates, retired assistant professor > > > > > > > Dept. of Computer Science, Wichita State University > > > > > > > Wichita, KS 67260-0083 > > > > > > > 316-978-3922 > > > > > > > rodney.bates at wichita.edu > > > > > > > > > > > > > > > > > > > > > Your smile counts. The more smiles you share, the more we > donate. > > > > > Join in! > > > > > > > > > > > > > Get the power of Windows + Web with the new Windows Live. Power > up! > > > > > You keep typing, we keep giving. Download Messenger and join the > i?m Initiative now. Join in! From jay.krell at cornell.edu Sun Dec 2 07:15:18 2007 From: jay.krell at cornell.edu (Jay) Date: Sun, 2 Dec 2007 06:15:18 +0000 Subject: [M3devel] returning record by value vs. by ref? In-Reply-To: <2B3B82B5-B989-4AC9-8156-02B3B8AC5B46@cs.purdue.edu> References: <1560FF15-8486-4388-ADAE-FADCF71FC5F3@cs.purdue.edu> <4751B69B.1090907@wichita.edu> <2B3B82B5-B989-4AC9-8156-02B3B8AC5B46@cs.purdue.edu> Message-ID: My quick understanding was that gc-points and mostly preemptive thread scheduling could be combined. You would have to cooperatively yield at gc-points, but you could be preemptively yielded anywhere. Er, maybe that's the point -- no cooperative yielding at all, no computation of gc-points, maybe none of this data. But you do end up I guess suspending all the threads and reading their registers and guessing as to the contents..the ambiguity you mention. I wonder how that is dealt with, since any integer can be an arbitrarily ffset pointer..I'll have to read more of the code.. - Jay > From: hosking at cs.purdue.edu> Date: Sun, 2 Dec 2007 00:16:05 -0500> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] returning record by value vs. by ref?> > > On Dec 1, 2007, at 11:11 PM, Jay wrote:> > > Thanks!> >> > I haven't finished reading it, but it sounds like an optimizing > > compiler is ok, due> > to the reliance on "gc points", which I read ahead to find out how > > they are defined.> > If you want fully accurate (non-ambiguous roots) GC then yes you need > gc-points to avoid having to store pointer information for every PC > location.> > > And I'm GUESSING that CM3 already generates and depends on the sort > > of data described there.> > But maybe not.> > Umm, no. CM3 uses an ambiguous roots technique for thread stacks/ > registers that avoids the need for gc-points. Hence, we can use > preemptive system-level thread scheduling.> > > I wonder what the size of the data looks like if you allow a gc > > point at every instruction.> > I guess it probably be too large -- figure a byte or two extra for > > every instruction, but maybe not.> >> > Perhaps it could be encoded in bits instead of bytes and given that > > most instructions don't affect the state> > (ie: operations on integers, floats, comparisons, branches), maybe > > just a zero bit for most instructions.> > So then figure a byte or two for every instruction that moves (load > > or store) or adds/substracts a pointer.> > Or more than that. A byte or two could describe enregistration and > > small adds/subtracts, but not large adds/subtracts> > or memory offsets.> >> > OR perhaps it'd just read the code itself. That's easier with Win32/ > > x86 since it is so constrained> > as to what it outputs. That should be feasible. I realize I'm > > changing subjects between the different backends.> >> > The Windows AMD64 calling convention relies on something LIKE this.> > In particular, there is a little encoding associated with every > > prolog/epilog so that exception handling can undo the prolog's > > effects.> > It describes a tiny subset of the instruction set, like register > > moves.> >> > Kind of funny -- once you get into the business of wanting to read > > the code to know what it does,> > you then get tempted to define your own code, for runtime and > > information, and then a possible trick> > is to adopt the existing machine code as your code, or whatever > > subset your compiler produces.> > Hm. The existing machine isn't sufficient. You would need type > > information to augment it.> >> > Which reminds. Another OBVIOUS backend for CM3 for easier > > portability is to persist the calls to m3cg and then> > write an interpreter for that in C.> >> > - Jay> >> >> > > From: hosking at cs.purdue.edu> > > Date: Sat, 1 Dec 2007 17:42:02 -0500> > > To: jay.krell at cornell.edu> > > CC: m3devel at elegosoft.com> > > Subject: Re: [M3devel] returning record by value vs. by ref?> > >> > > If this really interests you then you might read this paper: http://> > > doi.acm.org/10.1145/143095.143140 .> > >> > > On Dec 1, 2007, at 5:36 PM, Jay wrote:> > >> > > > > 2, don't understand> > > >> > > > You said it'd take much cooperation with the compiler, due its> > > > optimizations, but optimizations can be defeated as necessary.> > > > Interior pointers could be marked, perhaps, volatile, so prevent> > > > enregistration. I can see that's a potentially high cost though.> > > >> > > > like> > > > Record_t *Record = GetRecord();> > > > unsigned i;> > > > for (i = 0 ; i != Record->j ; ++i)> > > > {> > > > ...> > > > }> > > >> > > > You'd really like Record->j to not be refetched for every loop> > > > iteration, but if Record is volatile so the GC can move what it> > > > points to and update outstanding pointers, you'd be stuck with> > > > something like that. Besides, if j can't be read in one> > > > instruction, more problems, assuming a concurrent GC, that cannot> > > > reliably get/set the context of other threads. I think, like, you> > > > could reliably get/set context on a uniprocessor system, but not a> > > > multiprocessor. You'd have to suspend, wait for the suspend to> > > > happen.. I guess that could work, but it seems like you'd want to> > > > avoid designs that require suspending threads. ?> > > > Hm. No, it's difficult. This being a short lived pointer, gc> > > > happening on another thread, you'd have to, like, "register" its> > > > location with the gc.> > > >> > > > Hm. Just how does it work?> > > >> > > > gc suspends threads and updates variables? I don't think so.> > > >> > > > Variables that are moved leave some sort of "forwarding address"> > > > for holders of the old value?> > > >> > > > The gc isn't concurrent but is called at function entry/exit? I> > > > don't think so.> > > >> > > > I should check the docs and code..> > > >> > > > - Jay> > > >> > > >> > > >> > > > > From: hosking at cs.purdue.edu> > > > > Date: Sat, 1 Dec 2007 17:19:46 -0500> > > > > To: jay.krell at cornell.edu> > > > > CC: m3devel at elegosoft.com> > > > > Subject: Re: [M3devel] returning record by value vs. by ref?> > > > >> > > > >> > > > > On Dec 1, 2007, at 5:14 PM, Jay wrote:> > > > >> > > > > > 1) Can pinning not be exposed reasonably in the language?> > > > > > I'll keep my pointer just a short time, in a local.> > > > >> > > > > Yes, that is a *hack* that will work only with the current> > > > > conservative garbage collector. In general, the compiler might> > > > > record that the local is a pointer derived from some base > > reference> > > > > and if the GC decides to move the base object it can adjust the> > > > local> > > > > derived pointer accordingly.> > > > >> > > > > > 2) surely it could be done at an outer layer?> > > > > > Make volatile locals for things you don't want enregistered?> > > > >> > > > > I don't understand what you mean by this.> > > > >> > > > > > Even the accessor function approach seems lame, given that I> > > > > > believe the Win32/x86 compiler doesn't inline.. :(> > > > > > (does the gcc m3 inline across modules, or just compiles > > one at a> > > > > > time?)> > > > >> > > > > gcc m3 inlines only within compilation units.> > > > >> > > > > >> > > > > >> > > > > > - Jay> > > > > >> > > > > >> > > > > > > CC: jay.krell at cornell.edu; m3devel at elegosoft.com> > > > > > > From: hosking at cs.purdue.edu> > > > > > > Subject: Re: [M3devel] returning record by value vs. by ref?> > > > > > > Date: Sat, 1 Dec 2007 15:23:19 -0500> > > > > > > To: rodney.bates at wichita.edu> > > > > > >> > > > > > > Correct! Anytime you create an l-value pointer.> > > > > > >> > > > > > > On Dec 1, 2007, at 2:31 PM, Rodney M. Bates wrote:> > > > > > >> > > > > > > > Tony Hosking wrote:> > > > > > > >> I am assuming 's' here is an open array (REF ARRAY OF> > > > item) in> > > > > > > >> which case it is allocated in the GC'd heap. There is> > > > certainly> > > > > > > >> no way of safely getting an interior pointer to items > > in the> > > > > > > >> stack in Modula-3 -- at least not one that you can upward> > > > expose> > > > > > > >> (to callers) via return from a procedure. The > > difficulty in> > > > > > > >> doing this is that the GC moves objects around and would> > > > need to> > > > > > > >> know where your manufactured interior pointer is being> > > > held and> > > > > > > >> to which *object* (ie, the open array in this case) it> > > > refers so> > > > > > > >> that it can 'fix' the pointer when the array object > > moves.> > > > > > > >> Modula-3 provides a small concession to obtaining > > downward> > > > > > > >> exposed interior pointers using the VAR parameter > > mode. For> > > > > > > >> example you can pass 's[i]' as an actual parameter to a> > > > VAR mode> > > > > > > >> formal, effectively passing a pointer to the callee. GC> > > > can cope> > > > > > > >> with this in one of two possible ways: 1) "Pin" the array> > > > so that> > > > > > > >> it cannot be moved while the interior pointer is held > > on the> > > > > > > >> stack or registers of any thread (this is the approach> > > > that CM3's> > > > > > > >> conservative collector uses for now); or 2) track the> > > > creation of> > > > > > > >> such interior pointers and how they are derived from base> > > > object> > > > > > > >> references for use during GC. 2) requires much more co-> > > > operation> > > > > > > >> from the compiler than the current gcc-based backend > > (with> > > > all of> > > > > > > >> its lovely optimizations and register allocation) is> > > > capable of> > > > > > > >> doing. 1) is very cheap and does not impede > > optimizations and> > > > > > > >> register allocation.> > > > > > > >> > > > > > > > Presumably, this all also applies WITH-bound > > identifiers, when> > > > > > they> > > > > > > > are> > > > > > > > designators of interior components of heap objects? Are> > > > there any> > > > > > > > other> > > > > > > > cases?> > > > > > > >> > > > > > > > --> > > > > > > > > > -------------------------------------------------------------> > > > > > > > Rodney M. Bates, retired assistant professor> > > > > > > > Dept. of Computer Science, Wichita State University> > > > > > > > Wichita, KS 67260-0083> > > > > > > > 316-978-3922> > > > > > > > rodney.bates at wichita.edu> > > > > > >> > > > > >> > > > > >> > > > > > Your smile counts. The more smiles you share, the more we > > donate.> > > > > > Join in!> > > > >> > > >> > > >> > > > Get the power of Windows + Web with the new Windows Live. Power > > up!> > >> >> >> > You keep typing, we keep giving. Download Messenger and join the > > i?m Initiative now. Join in!> _________________________________________________________________ Share life as it happens with the new Windows Live.Download today it's FREE! http://www.windowslive.com/share.html?ocid=TXT_TAGLM_Wave2_sharelife_112007 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 2 18:23:29 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 2 Dec 2007 12:23:29 -0500 Subject: [M3devel] returning record by value vs. by ref? In-Reply-To: References: <1560FF15-8486-4388-ADAE-FADCF71FC5F3@cs.purdue.edu> <4751B69B.1090907@wichita.edu> <2B3B82B5-B989-4AC9-8156-02B3B8AC5B46@cs.purdue.edu> Message-ID: <6A62D86F-1AAD-4CBE-9348-C0A0210AA291@cs.purdue.edu> On Dec 2, 2007, at 1:15 AM, Jay wrote: > My quick understanding was that gc-points and mostly preemptive > thread scheduling could be combined. A little but doable: if a thread is preempted and GC occurs then you have a problem, needing to roll the thread forward to a GC point. > You would have to cooperatively yield at gc-points, but you could > be preemptively yielded anywhere. > Er, maybe that's the point -- no cooperative yielding at all, no > computation of gc-points, maybe none of this data. Yes, that's the point about ambiguous roots collection. > But you do end up I guess suspending all the threads and reading > their registers and guessing as to the contents..the ambiguity you > mention. I wonder how that is dealt with, since any integer can be > an arbitrarily ffset pointer.. The current ambiguous roots collector pins objects referred to by ambiguous roots (thread stacks/registers). It moves objects that are not referred to by ambiguous roots. > I'll have to read more of the code.. > > - Jay > > > > From: hosking at cs.purdue.edu > > Date: Sun, 2 Dec 2007 00:16:05 -0500 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] returning record by value vs. by ref? > > > > > > On Dec 1, 2007, at 11:11 PM, Jay wrote: > > > > > Thanks! > > > > > > I haven't finished reading it, but it sounds like an optimizing > > > compiler is ok, due > > > to the reliance on "gc points", which I read ahead to find out how > > > they are defined. > > > > If you want fully accurate (non-ambiguous roots) GC then yes you > need > > gc-points to avoid having to store pointer information for every PC > > location. > > > > > And I'm GUESSING that CM3 already generates and depends on the > sort > > > of data described there. > > > But maybe not. > > > > Umm, no. CM3 uses an ambiguous roots technique for thread stacks/ > > registers that avoids the need for gc-points. Hence, we can use > > preemptive system-level thread scheduling. > > > > > I wonder what the size of the data looks like if you allow a gc > > > point at every instruction. > > > I guess it probably be too large -- figure a byte or two extra for > > > every instruction, but maybe not. > > > > > > Perhaps it could be encoded in bits instead of bytes and given > that > > > most instructions don't affect the state > > > (ie: operations on integers, floats, comparisons, branches), maybe > > > just a zero bit for most instructions. > > > So then figure a byte or two for every instruction that moves > (load > > > or store) or adds/substracts a pointer. > > > Or more than that. A byte or two could describe enregistration and > > > small adds/subtracts, but not large adds/subtracts > > > or memory offsets. > > > > > > OR perhaps it'd just read the code itself. That's easier with > Win32/ > > > x86 since it is so constrained > > > as to what it outputs. That should be feasible. I realize I'm > > > changing subjects between the different backends. > > > > > > The Windows AMD64 calling convention relies on something LIKE > this. > > > In particular, there is a little encoding associated with every > > > prolog/epilog so that exception handling can undo the prolog's > > > effects. > > > It describes a tiny subset of the instruction set, like register > > > moves. > > > > > > Kind of funny -- once you get into the business of wanting to read > > > the code to know what it does, > > > you then get tempted to define your own code, for runtime and > > > information, and then a possible trick > > > is to adopt the existing machine code as your code, or whatever > > > subset your compiler produces. > > > Hm. The existing machine isn't sufficient. You would need type > > > information to augment it. > > > > > > Which reminds. Another OBVIOUS backend for CM3 for easier > > > portability is to persist the calls to m3cg and then > > > write an interpreter for that in C. > > > > > > - Jay > > > > > > > > > > From: hosking at cs.purdue.edu > > > > Date: Sat, 1 Dec 2007 17:42:02 -0500 > > > > To: jay.krell at cornell.edu > > > > CC: m3devel at elegosoft.com > > > > Subject: Re: [M3devel] returning record by value vs. by ref? > > > > > > > > If this really interests you then you might read this paper: > http:// > > > > doi.acm.org/10.1145/143095.143140 . > > > > > > > > On Dec 1, 2007, at 5:36 PM, Jay wrote: > > > > > > > > > > 2, don't understand > > > > > > > > > > You said it'd take much cooperation with the compiler, due its > > > > > optimizations, but optimizations can be defeated as necessary. > > > > > Interior pointers could be marked, perhaps, volatile, so > prevent > > > > > enregistration. I can see that's a potentially high cost > though. > > > > > > > > > > like > > > > > Record_t *Record = GetRecord(); > > > > > unsigned i; > > > > > for (i = 0 ; i != Record->j ; ++i) > > > > > { > > > > > ... > > > > > } > > > > > > > > > > You'd really like Record->j to not be refetched for every loop > > > > > iteration, but if Record is volatile so the GC can move > what it > > > > > points to and update outstanding pointers, you'd be stuck with > > > > > something like that. Besides, if j can't be read in one > > > > > instruction, more problems, assuming a concurrent GC, that > cannot > > > > > reliably get/set the context of other threads. I think, > like, you > > > > > could reliably get/set context on a uniprocessor system, > but not a > > > > > multiprocessor. You'd have to suspend, wait for the suspend to > > > > > happen.. I guess that could work, but it seems like you'd > want to > > > > > avoid designs that require suspending threads. ? > > > > > Hm. No, it's difficult. This being a short lived pointer, gc > > > > > happening on another thread, you'd have to, like, > "register" its > > > > > location with the gc. > > > > > > > > > > Hm. Just how does it work? > > > > > > > > > > gc suspends threads and updates variables? I don't think so. > > > > > > > > > > Variables that are moved leave some sort of "forwarding > address" > > > > > for holders of the old value? > > > > > > > > > > The gc isn't concurrent but is called at function entry/ > exit? I > > > > > don't think so. > > > > > > > > > > I should check the docs and code.. > > > > > > > > > > - Jay > > > > > > > > > > > > > > > > > > > > > From: hosking at cs.purdue.edu > > > > > > Date: Sat, 1 Dec 2007 17:19:46 -0500 > > > > > > To: jay.krell at cornell.edu > > > > > > CC: m3devel at elegosoft.com > > > > > > Subject: Re: [M3devel] returning record by value vs. by ref? > > > > > > > > > > > > > > > > > > On Dec 1, 2007, at 5:14 PM, Jay wrote: > > > > > > > > > > > > > 1) Can pinning not be exposed reasonably in the language? > > > > > > > I'll keep my pointer just a short time, in a local. > > > > > > > > > > > > Yes, that is a *hack* that will work only with the current > > > > > > conservative garbage collector. In general, the compiler > might > > > > > > record that the local is a pointer derived from some base > > > reference > > > > > > and if the GC decides to move the base object it can > adjust the > > > > > local > > > > > > derived pointer accordingly. > > > > > > > > > > > > > 2) surely it could be done at an outer layer? > > > > > > > Make volatile locals for things you don't want > enregistered? > > > > > > > > > > > > I don't understand what you mean by this. > > > > > > > > > > > > > Even the accessor function approach seems lame, given > that I > > > > > > > believe the Win32/x86 compiler doesn't inline.. :( > > > > > > > (does the gcc m3 inline across modules, or just compiles > > > one at a > > > > > > > time?) > > > > > > > > > > > > gcc m3 inlines only within compilation units. > > > > > > > > > > > > > > > > > > > > > > > > > > > - Jay > > > > > > > > > > > > > > > > > > > > > > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > > > > > > > > From: hosking at cs.purdue.edu > > > > > > > > Subject: Re: [M3devel] returning record by value vs. > by ref? > > > > > > > > Date: Sat, 1 Dec 2007 15:23:19 -0500 > > > > > > > > To: rodney.bates at wichita.edu > > > > > > > > > > > > > > > > Correct! Anytime you create an l-value pointer. > > > > > > > > > > > > > > > > On Dec 1, 2007, at 2:31 PM, Rodney M. Bates wrote: > > > > > > > > > > > > > > > > > Tony Hosking wrote: > > > > > > > > >> I am assuming 's' here is an open array (REF ARRAY OF > > > > > item) in > > > > > > > > >> which case it is allocated in the GC'd heap. There is > > > > > certainly > > > > > > > > >> no way of safely getting an interior pointer to items > > > in the > > > > > > > > >> stack in Modula-3 -- at least not one that you can > upward > > > > > expose > > > > > > > > >> (to callers) via return from a procedure. The > > > difficulty in > > > > > > > > >> doing this is that the GC moves objects around and > would > > > > > need to > > > > > > > > >> know where your manufactured interior pointer is > being > > > > > held and > > > > > > > > >> to which *object* (ie, the open array in this > case) it > > > > > refers so > > > > > > > > >> that it can 'fix' the pointer when the array object > > > moves. > > > > > > > > >> Modula-3 provides a small concession to obtaining > > > downward > > > > > > > > >> exposed interior pointers using the VAR parameter > > > mode. For > > > > > > > > >> example you can pass 's[i]' as an actual parameter > to a > > > > > VAR mode > > > > > > > > >> formal, effectively passing a pointer to the > callee. GC > > > > > can cope > > > > > > > > >> with this in one of two possible ways: 1) "Pin" > the array > > > > > so that > > > > > > > > >> it cannot be moved while the interior pointer is held > > > on the > > > > > > > > >> stack or registers of any thread (this is the > approach > > > > > that CM3's > > > > > > > > >> conservative collector uses for now); or 2) track the > > > > > creation of > > > > > > > > >> such interior pointers and how they are derived > from base > > > > > object > > > > > > > > >> references for use during GC. 2) requires much > more co- > > > > > operation > > > > > > > > >> from the compiler than the current gcc-based backend > > > (with > > > > > all of > > > > > > > > >> its lovely optimizations and register allocation) is > > > > > capable of > > > > > > > > >> doing. 1) is very cheap and does not impede > > > optimizations and > > > > > > > > >> register allocation. > > > > > > > > > > > > > > > > > > Presumably, this all also applies WITH-bound > > > identifiers, when > > > > > > > they > > > > > > > > > are > > > > > > > > > designators of interior components of heap objects? > Are > > > > > there any > > > > > > > > > other > > > > > > > > > cases? > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > ------------------------------------------------------------- > > > > > > > > > Rodney M. Bates, retired assistant professor > > > > > > > > > Dept. of Computer Science, Wichita State University > > > > > > > > > Wichita, KS 67260-0083 > > > > > > > > > 316-978-3922 > > > > > > > > > rodney.bates at wichita.edu > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your smile counts. The more smiles you share, the more we > > > donate. > > > > > > > Join in! > > > > > > > > > > > > > > > > > > > > > Get the power of Windows + Web with the new Windows Live. > Power > > > up! > > > > > > > > > > > > > You keep typing, we keep giving. Download Messenger and join the > > > i?m Initiative now. Join in! > > > > > Share life as it happens with the new Windows Live. Share now! From jay.krell at cornell.edu Sun Dec 2 19:54:25 2007 From: jay.krell at cornell.edu (Jay) Date: Sun, 2 Dec 2007 18:54:25 +0000 Subject: [M3devel] returning record by value vs. by ref? In-Reply-To: <6A62D86F-1AAD-4CBE-9348-C0A0210AA291@cs.purdue.edu> References: <1560FF15-8486-4388-ADAE-FADCF71FC5F3@cs.purdue.edu> <4751B69B.1090907@wichita.edu> <2B3B82B5-B989-4AC9-8156-02B3B8AC5B46@cs.purdue.edu> <6A62D86F-1AAD-4CBE-9348-C0A0210AA291@cs.purdue.edu> Message-ID: > roll forward to gc-point Right, the paper says the gc will wait till all threads are at gc-points, and gc-points are defined/inserted enough to make it probably not long -- allocations, calls/returns, loop boundaries, roughly. > ambiguous.. The problem in my mind is "how ambiguous?". Can't almost anything be a pointer in disguise? This example from the paper: Double Indexing: The code A[i] := 1; B[i] := 2; may be optimized to t1 = &A[0] + (i * sizeof(int)); t2 = &B[0] - &A[0]; *tl = 1; *(tl + t2) = 2; which is useful on machines that have addressing modes with two or more index registers, such as the SPARC. More from the paper, emphasis mine: Note that a derived value may bean untidy pointer to the interior of an object (strength reduction example), an untidy pointer that points outside the object to which it refers (virtual array origin example), or even a non-pointer value (double indexing example), and the examples given above may not exhaust the possibilities - Jay > From: hosking at cs.purdue.edu> Date: Sun, 2 Dec 2007 12:23:29 -0500> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] returning record by value vs. by ref?> > > On Dec 2, 2007, at 1:15 AM, Jay wrote:> > > My quick understanding was that gc-points and mostly preemptive > > thread scheduling could be combined.> > A little but doable: if a thread is preempted and GC occurs then you > have a problem, needing to roll the thread forward to a GC point.> > > You would have to cooperatively yield at gc-points, but you could > > be preemptively yielded anywhere.> > Er, maybe that's the point -- no cooperative yielding at all, no > > computation of gc-points, maybe none of this data.> > Yes, that's the point about ambiguous roots collection.> > > But you do end up I guess suspending all the threads and reading > > their registers and guessing as to the contents..the ambiguity you > > mention. I wonder how that is dealt with, since any integer can be > > an arbitrarily ffset pointer..> > The current ambiguous roots collector pins objects referred to by > ambiguous roots (thread stacks/registers). It moves objects that are > not referred to by ambiguous roots.> > > I'll have to read more of the code..> >> > - Jay> >> >> > > From: hosking at cs.purdue.edu> > > Date: Sun, 2 Dec 2007 00:16:05 -0500> > > To: jay.krell at cornell.edu> > > CC: m3devel at elegosoft.com> > > Subject: Re: [M3devel] returning record by value vs. by ref?> > >> > >> > > On Dec 1, 2007, at 11:11 PM, Jay wrote:> > >> > > > Thanks!> > > >> > > > I haven't finished reading it, but it sounds like an optimizing> > > > compiler is ok, due> > > > to the reliance on "gc points", which I read ahead to find out how> > > > they are defined.> > >> > > If you want fully accurate (non-ambiguous roots) GC then yes you > > need> > > gc-points to avoid having to store pointer information for every PC> > > location.> > >> > > > And I'm GUESSING that CM3 already generates and depends on the > > sort> > > > of data described there.> > > > But maybe not.> > >> > > Umm, no. CM3 uses an ambiguous roots technique for thread stacks/> > > registers that avoids the need for gc-points. Hence, we can use> > > preemptive system-level thread scheduling.> > >> > > > I wonder what the size of the data looks like if you allow a gc> > > > point at every instruction.> > > > I guess it probably be too large -- figure a byte or two extra for> > > > every instruction, but maybe not.> > > >> > > > Perhaps it could be encoded in bits instead of bytes and given > > that> > > > most instructions don't affect the state> > > > (ie: operations on integers, floats, comparisons, branches), maybe> > > > just a zero bit for most instructions.> > > > So then figure a byte or two for every instruction that moves > > (load> > > > or store) or adds/substracts a pointer.> > > > Or more than that. A byte or two could describe enregistration and> > > > small adds/subtracts, but not large adds/subtracts> > > > or memory offsets.> > > >> > > > OR perhaps it'd just read the code itself. That's easier with > > Win32/> > > > x86 since it is so constrained> > > > as to what it outputs. That should be feasible. I realize I'm> > > > changing subjects between the different backends.> > > >> > > > The Windows AMD64 calling convention relies on something LIKE > > this.> > > > In particular, there is a little encoding associated with every> > > > prolog/epilog so that exception handling can undo the prolog's> > > > effects.> > > > It describes a tiny subset of the instruction set, like register> > > > moves.> > > >> > > > Kind of funny -- once you get into the business of wanting to read> > > > the code to know what it does,> > > > you then get tempted to define your own code, for runtime and> > > > information, and then a possible trick> > > > is to adopt the existing machine code as your code, or whatever> > > > subset your compiler produces.> > > > Hm. The existing machine isn't sufficient. You would need type> > > > information to augment it.> > > >> > > > Which reminds. Another OBVIOUS backend for CM3 for easier> > > > portability is to persist the calls to m3cg and then> > > > write an interpreter for that in C.> > > >> > > > - Jay> > > >> > > >> > > > > From: hosking at cs.purdue.edu> > > > > Date: Sat, 1 Dec 2007 17:42:02 -0500> > > > > To: jay.krell at cornell.edu> > > > > CC: m3devel at elegosoft.com> > > > > Subject: Re: [M3devel] returning record by value vs. by ref?> > > > >> > > > > If this really interests you then you might read this paper: > > http://> > > > > doi.acm.org/10.1145/143095.143140 .> > > > >> > > > > On Dec 1, 2007, at 5:36 PM, Jay wrote:> > > > >> > > > > > > 2, don't understand> > > > > >> > > > > > You said it'd take much cooperation with the compiler, due its> > > > > > optimizations, but optimizations can be defeated as necessary.> > > > > > Interior pointers could be marked, perhaps, volatile, so > > prevent> > > > > > enregistration. I can see that's a potentially high cost > > though.> > > > > >> > > > > > like> > > > > > Record_t *Record = GetRecord();> > > > > > unsigned i;> > > > > > for (i = 0 ; i != Record->j ; ++i)> > > > > > {> > > > > > ...> > > > > > }> > > > > >> > > > > > You'd really like Record->j to not be refetched for every loop> > > > > > iteration, but if Record is volatile so the GC can move > > what it> > > > > > points to and update outstanding pointers, you'd be stuck with> > > > > > something like that. Besides, if j can't be read in one> > > > > > instruction, more problems, assuming a concurrent GC, that > > cannot> > > > > > reliably get/set the context of other threads. I think, > > like, you> > > > > > could reliably get/set context on a uniprocessor system, > > but not a> > > > > > multiprocessor. You'd have to suspend, wait for the suspend to> > > > > > happen.. I guess that could work, but it seems like you'd > > want to> > > > > > avoid designs that require suspending threads. ?> > > > > > Hm. No, it's difficult. This being a short lived pointer, gc> > > > > > happening on another thread, you'd have to, like, > > "register" its> > > > > > location with the gc.> > > > > >> > > > > > Hm. Just how does it work?> > > > > >> > > > > > gc suspends threads and updates variables? I don't think so.> > > > > >> > > > > > Variables that are moved leave some sort of "forwarding > > address"> > > > > > for holders of the old value?> > > > > >> > > > > > The gc isn't concurrent but is called at function entry/ > > exit? I> > > > > > don't think so.> > > > > >> > > > > > I should check the docs and code..> > > > > >> > > > > > - Jay> > > > > >> > > > > >> > > > > >> > > > > > > From: hosking at cs.purdue.edu> > > > > > > Date: Sat, 1 Dec 2007 17:19:46 -0500> > > > > > > To: jay.krell at cornell.edu> > > > > > > CC: m3devel at elegosoft.com> > > > > > > Subject: Re: [M3devel] returning record by value vs. by ref?> > > > > > >> > > > > > >> > > > > > > On Dec 1, 2007, at 5:14 PM, Jay wrote:> > > > > > >> > > > > > > > 1) Can pinning not be exposed reasonably in the language?> > > > > > > > I'll keep my pointer just a short time, in a local.> > > > > > >> > > > > > > Yes, that is a *hack* that will work only with the current> > > > > > > conservative garbage collector. In general, the compiler > > might> > > > > > > record that the local is a pointer derived from some base> > > > reference> > > > > > > and if the GC decides to move the base object it can > > adjust the> > > > > > local> > > > > > > derived pointer accordingly.> > > > > > >> > > > > > > > 2) surely it could be done at an outer layer?> > > > > > > > Make volatile locals for things you don't want > > enregistered?> > > > > > >> > > > > > > I don't understand what you mean by this.> > > > > > >> > > > > > > > Even the accessor function approach seems lame, given > > that I> > > > > > > > believe the Win32/x86 compiler doesn't inline.. :(> > > > > > > > (does the gcc m3 inline across modules, or just compiles> > > > one at a> > > > > > > > time?)> > > > > > >> > > > > > > gcc m3 inlines only within compilation units.> > > > > > >> > > > > > > >> > > > > > > >> > > > > > > > - Jay> > > > > > > >> > > > > > > >> > > > > > > > > CC: jay.krell at cornell.edu; m3devel at elegosoft.com> > > > > > > > > From: hosking at cs.purdue.edu> > > > > > > > > Subject: Re: [M3devel] returning record by value vs. > > by ref?> > > > > > > > > Date: Sat, 1 Dec 2007 15:23:19 -0500> > > > > > > > > To: rodney.bates at wichita.edu> > > > > > > > >> > > > > > > > > Correct! Anytime you create an l-value pointer.> > > > > > > > >> > > > > > > > > On Dec 1, 2007, at 2:31 PM, Rodney M. Bates wrote:> > > > > > > > >> > > > > > > > > > Tony Hosking wrote:> > > > > > > > > >> I am assuming 's' here is an open array (REF ARRAY OF> > > > > > item) in> > > > > > > > > >> which case it is allocated in the GC'd heap. There is> > > > > > certainly> > > > > > > > > >> no way of safely getting an interior pointer to items> > > > in the> > > > > > > > > >> stack in Modula-3 -- at least not one that you can > > upward> > > > > > expose> > > > > > > > > >> (to callers) via return from a procedure. The> > > > difficulty in> > > > > > > > > >> doing this is that the GC moves objects around and > > would> > > > > > need to> > > > > > > > > >> know where your manufactured interior pointer is > > being> > > > > > held and> > > > > > > > > >> to which *object* (ie, the open array in this > > case) it> > > > > > refers so> > > > > > > > > >> that it can 'fix' the pointer when the array object> > > > moves.> > > > > > > > > >> Modula-3 provides a small concession to obtaining> > > > downward> > > > > > > > > >> exposed interior pointers using the VAR parameter> > > > mode. For> > > > > > > > > >> example you can pass 's[i]' as an actual parameter > > to a> > > > > > VAR mode> > > > > > > > > >> formal, effectively passing a pointer to the > > callee. GC> > > > > > can cope> > > > > > > > > >> with this in one of two possible ways: 1) "Pin" > > the array> > > > > > so that> > > > > > > > > >> it cannot be moved while the interior pointer is held> > > > on the> > > > > > > > > >> stack or registers of any thread (this is the > > approach> > > > > > that CM3's> > > > > > > > > >> conservative collector uses for now); or 2) track the> > > > > > creation of> > > > > > > > > >> such interior pointers and how they are derived > > from base> > > > > > object> > > > > > > > > >> references for use during GC. 2) requires much > > more co-> > > > > > operation> > > > > > > > > >> from the compiler than the current gcc-based backend> > > > (with> > > > > > all of> > > > > > > > > >> its lovely optimizations and register allocation) is> > > > > > capable of> > > > > > > > > >> doing. 1) is very cheap and does not impede> > > > optimizations and> > > > > > > > > >> register allocation.> > > > > > > > > >> > > > > > > > > > Presumably, this all also applies WITH-bound> > > > identifiers, when> > > > > > > > they> > > > > > > > > > are> > > > > > > > > > designators of interior components of heap objects? > > Are> > > > > > there any> > > > > > > > > > other> > > > > > > > > > cases?> > > > > > > > > >> > > > > > > > > > --> > > > > > > > > >> > > > -------------------------------------------------------------> > > > > > > > > > Rodney M. Bates, retired assistant professor> > > > > > > > > > Dept. of Computer Science, Wichita State University> > > > > > > > > > Wichita, KS 67260-0083> > > > > > > > > > 316-978-3922> > > > > > > > > > rodney.bates at wichita.edu> > > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > > Your smile counts. The more smiles you share, the more we> > > > donate.> > > > > > > > Join in!> > > > > > >> > > > > >> > > > > >> > > > > > Get the power of Windows + Web with the new Windows Live. > > Power> > > > up!> > > > >> > > >> > > >> > > > You keep typing, we keep giving. Download Messenger and join the> > > > i?m Initiative now. Join in!> > >> >> >> > Share life as it happens with the new Windows Live. Share now!> _________________________________________________________________ Your smile counts. The more smiles you share, the more we donate.? Join in. www.windowslive.com/smile?ocid=TXT_TAGLM_Wave2_oprsmilewlhmtagline -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 2 20:11:55 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 2 Dec 2007 14:11:55 -0500 Subject: [M3devel] returning record by value vs. by ref? In-Reply-To: References: <1560FF15-8486-4388-ADAE-FADCF71FC5F3@cs.purdue.edu> <4751B69B.1090907@wichita.edu> <2B3B82B5-B989-4AC9-8156-02B3B8AC5B46@cs.purdue.edu> <6A62D86F-1AAD-4CBE-9348-C0A0210AA291@cs.purdue.edu> Message-ID: On Dec 2, 2007, at 1:54 PM, Jay wrote: > > roll forward to gc-point > > Right, the paper says the gc will wait till all threads are at gc- > points, and gc-points are defined/inserted enough to make it > probably not long -- allocations, calls/returns, loop boundaries, > roughly. My problem with this for preemptive scheduling is that roll-forward can take a long time -- too long if one wants short GCs. Currently, GC can occur at almost all preemption points. > > ambiguous.. > > The problem in my mind is "how ambiguous?". > Can't almost anything be a pointer in disguise? Indeed, for CM3 currently any word-aligned, word-length bit string in stacks or registers is treated as a potential ambiguous root. > This example from the paper: > > Double Indexing: The code > A[i] := 1; > B[i] := 2; > may be optimized to > t1 = &A[0] + (i * sizeof(int)); > t2 = &B[0] - &A[0]; > *tl = 1; > *(tl + t2) = 2; > > which is useful on machines that have addressing modes > with two or more index registers, such as the SPARC. > > More from the paper, emphasis mine: > > Note that a derived value > may bean untidy pointer to the interior of an object (strength > reduction example), an untidy pointer that points outside the > object to which it refers (virtual array origin example), or > even a non-pointer value (double indexing example), and > the examples given above may not exhaust the possibilities This all depends on what sorts of optimizations are permitted, as you have already noted. > > > - Jay > > > > From: hosking at cs.purdue.edu > > Date: Sun, 2 Dec 2007 12:23:29 -0500 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] returning record by value vs. by ref? > > > > > > On Dec 2, 2007, at 1:15 AM, Jay wrote: > > > > > My quick understanding was that gc-points and mostly preemptive > > > thread scheduling could be combined. > > > > A little but doable: if a thread is preempted and GC occurs then you > > have a problem, needing to roll the thread forward to a GC point. > > > > > You would have to cooperatively yield at gc-points, but you could > > > be preemptively yielded anywhere. > > > Er, maybe that's the point -- no cooperative yielding at all, no > > > computation of gc-points, maybe none of this data. > > > > Yes, that's the point about ambiguous roots collection. > > > > > But you do end up I guess suspending all the threads and reading > > > their registers and guessing as to the contents..the ambiguity you > > > mention. I wonder how that is dealt with, since any integer can be > > > an arbitrarily ffset pointer.. > > > > The current ambiguous roots collector pins objects referred to by > > ambiguous roots (thread stacks/registers). It moves objects that are > > not referred to by ambiguous roots. > > > > > I'll have to read more of the code.. > > > > > > - Jay > > > > > > > > > > From: hosking at cs.purdue.edu > > > > Date: Sun, 2 Dec 2007 00:16:05 -0500 > > > > To: jay.krell at cornell.edu > > > > CC: m3devel at elegosoft.com > > > > Subject: Re: [M3devel] returning record by value vs. by ref? > > > > > > > > > > > > On Dec 1, 2007, at 11:11 PM, Jay wrote: > > > > > > > > > Thanks! > > > > > > > > > > I haven't finished reading it, but it sounds like an > optimizing > > > > > compiler is ok, due > > > > > to the reliance on "gc points", which I read ahead to find > out how > > > > > they are defined. > > > > > > > > If you want fully accurate (non-ambiguous roots) GC then yes you > > > need > > > > gc-points to avoid having to store pointer information for > every PC > > > > location. > > > > > > > > > And I'm GUESSING that CM3 already generates and depends on the > > > sort > > > > > of data described there. > > > > > But maybe not. > > > > > > > > Umm, no. CM3 uses an ambiguous roots technique for thread > stacks/ > > > > registers that avoids the need for gc-points. Hence, we can use > > > > preemptive system-level thread scheduling. > > > > > > > > > I wonder what the size of the data looks like if you allow > a gc > > > > > point at every instruction. > > > > > I guess it probably be too large -- figure a byte or two > extra for > > > > > every instruction, but maybe not. > > > > > > > > > > Perhaps it could be encoded in bits instead of bytes and given > > > that > > > > > most instructions don't affect the state > > > > > (ie: operations on integers, floats, comparisons, > branches), maybe > > > > > just a zero bit for most instructions. > > > > > So then figure a byte or two for every instruction that moves > > > (load > > > > > or store) or adds/substracts a pointer. > > > > > Or more than that. A byte or two could describe > enregistration and > > > > > small adds/subtracts, but not large adds/subtracts > > > > > or memory offsets. > > > > > > > > > > OR perhaps it'd just read the code itself. That's easier with > > > Win32/ > > > > > x86 since it is so constrained > > > > > as to what it outputs. That should be feasible. I realize I'm > > > > > changing subjects between the different backends. > > > > > > > > > > The Windows AMD64 calling convention relies on something LIKE > > > this. > > > > > In particular, there is a little encoding associated with > every > > > > > prolog/epilog so that exception handling can undo the prolog's > > > > > effects. > > > > > It describes a tiny subset of the instruction set, like > register > > > > > moves. > > > > > > > > > > Kind of funny -- once you get into the business of wanting > to read > > > > > the code to know what it does, > > > > > you then get tempted to define your own code, for runtime and > > > > > information, and then a possible trick > > > > > is to adopt the existing machine code as your code, or > whatever > > > > > subset your compiler produces. > > > > > Hm. The existing machine isn't sufficient. You would need type > > > > > information to augment it. > > > > > > > > > > Which reminds. Another OBVIOUS backend for CM3 for easier > > > > > portability is to persist the calls to m3cg and then > > > > > write an interpreter for that in C. > > > > > > > > > > - Jay > > > > > > > > > > > > > > > > From: hosking at cs.purdue.edu > > > > > > Date: Sat, 1 Dec 2007 17:42:02 -0500 > > > > > > To: jay.krell at cornell.edu > > > > > > CC: m3devel at elegosoft.com > > > > > > Subject: Re: [M3devel] returning record by value vs. by ref? > > > > > > > > > > > > If this really interests you then you might read this paper: > > > http:// > > > > > > doi.acm.org/10.1145/143095.143140 . > > > > > > > > > > > > On Dec 1, 2007, at 5:36 PM, Jay wrote: > > > > > > > > > > > > > > 2, don't understand > > > > > > > > > > > > > > You said it'd take much cooperation with the compiler, > due its > > > > > > > optimizations, but optimizations can be defeated as > necessary. > > > > > > > Interior pointers could be marked, perhaps, volatile, so > > > prevent > > > > > > > enregistration. I can see that's a potentially high cost > > > though. > > > > > > > > > > > > > > like > > > > > > > Record_t *Record = GetRecord(); > > > > > > > unsigned i; > > > > > > > for (i = 0 ; i != Record->j ; ++i) > > > > > > > { > > > > > > > ... > > > > > > > } > > > > > > > > > > > > > > You'd really like Record->j to not be refetched for > every loop > > > > > > > iteration, but if Record is volatile so the GC can move > > > what it > > > > > > > points to and update outstanding pointers, you'd be > stuck with > > > > > > > something like that. Besides, if j can't be read in one > > > > > > > instruction, more problems, assuming a concurrent GC, that > > > cannot > > > > > > > reliably get/set the context of other threads. I think, > > > like, you > > > > > > > could reliably get/set context on a uniprocessor system, > > > but not a > > > > > > > multiprocessor. You'd have to suspend, wait for the > suspend to > > > > > > > happen.. I guess that could work, but it seems like you'd > > > want to > > > > > > > avoid designs that require suspending threads. ? > > > > > > > Hm. No, it's difficult. This being a short lived > pointer, gc > > > > > > > happening on another thread, you'd have to, like, > > > "register" its > > > > > > > location with the gc. > > > > > > > > > > > > > > Hm. Just how does it work? > > > > > > > > > > > > > > gc suspends threads and updates variables? I don't > think so. > > > > > > > > > > > > > > Variables that are moved leave some sort of "forwarding > > > address" > > > > > > > for holders of the old value? > > > > > > > > > > > > > > The gc isn't concurrent but is called at function entry/ > > > exit? I > > > > > > > don't think so. > > > > > > > > > > > > > > I should check the docs and code.. > > > > > > > > > > > > > > - Jay > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: hosking at cs.purdue.edu > > > > > > > > Date: Sat, 1 Dec 2007 17:19:46 -0500 > > > > > > > > To: jay.krell at cornell.edu > > > > > > > > CC: m3devel at elegosoft.com > > > > > > > > Subject: Re: [M3devel] returning record by value vs. > by ref? > > > > > > > > > > > > > > > > > > > > > > > > On Dec 1, 2007, at 5:14 PM, Jay wrote: > > > > > > > > > > > > > > > > > 1) Can pinning not be exposed reasonably in the > language? > > > > > > > > > I'll keep my pointer just a short time, in a local. > > > > > > > > > > > > > > > > Yes, that is a *hack* that will work only with the > current > > > > > > > > conservative garbage collector. In general, the compiler > > > might > > > > > > > > record that the local is a pointer derived from some > base > > > > > reference > > > > > > > > and if the GC decides to move the base object it can > > > adjust the > > > > > > > local > > > > > > > > derived pointer accordingly. > > > > > > > > > > > > > > > > > 2) surely it could be done at an outer layer? > > > > > > > > > Make volatile locals for things you don't want > > > enregistered? > > > > > > > > > > > > > > > > I don't understand what you mean by this. > > > > > > > > > > > > > > > > > Even the accessor function approach seems lame, given > > > that I > > > > > > > > > believe the Win32/x86 compiler doesn't inline.. :( > > > > > > > > > (does the gcc m3 inline across modules, or just > compiles > > > > > one at a > > > > > > > > > time?) > > > > > > > > > > > > > > > > gcc m3 inlines only within compilation units. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - Jay > > > > > > > > > > > > > > > > > > > > > > > > > > > > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > > > > > > > > > > From: hosking at cs.purdue.edu > > > > > > > > > > Subject: Re: [M3devel] returning record by value vs. > > > by ref? > > > > > > > > > > Date: Sat, 1 Dec 2007 15:23:19 -0500 > > > > > > > > > > To: rodney.bates at wichita.edu > > > > > > > > > > > > > > > > > > > > Correct! Anytime you create an l-value pointer. > > > > > > > > > > > > > > > > > > > > On Dec 1, 2007, at 2:31 PM, Rodney M. Bates wrote: > > > > > > > > > > > > > > > > > > > > > Tony Hosking wrote: > > > > > > > > > > >> I am assuming 's' here is an open array (REF > ARRAY OF > > > > > > > item) in > > > > > > > > > > >> which case it is allocated in the GC'd heap. > There is > > > > > > > certainly > > > > > > > > > > >> no way of safely getting an interior pointer > to items > > > > > in the > > > > > > > > > > >> stack in Modula-3 -- at least not one that you > can > > > upward > > > > > > > expose > > > > > > > > > > >> (to callers) via return from a procedure. The > > > > > difficulty in > > > > > > > > > > >> doing this is that the GC moves objects around > and > > > would > > > > > > > need to > > > > > > > > > > >> know where your manufactured interior pointer is > > > being > > > > > > > held and > > > > > > > > > > >> to which *object* (ie, the open array in this > > > case) it > > > > > > > refers so > > > > > > > > > > >> that it can 'fix' the pointer when the array > object > > > > > moves. > > > > > > > > > > >> Modula-3 provides a small concession to obtaining > > > > > downward > > > > > > > > > > >> exposed interior pointers using the VAR parameter > > > > > mode. For > > > > > > > > > > >> example you can pass 's[i]' as an actual > parameter > > > to a > > > > > > > VAR mode > > > > > > > > > > >> formal, effectively passing a pointer to the > > > callee. GC > > > > > > > can cope > > > > > > > > > > >> with this in one of two possible ways: 1) "Pin" > > > the array > > > > > > > so that > > > > > > > > > > >> it cannot be moved while the interior pointer > is held > > > > > on the > > > > > > > > > > >> stack or registers of any thread (this is the > > > approach > > > > > > > that CM3's > > > > > > > > > > >> conservative collector uses for now); or 2) > track the > > > > > > > creation of > > > > > > > > > > >> such interior pointers and how they are derived > > > from base > > > > > > > object > > > > > > > > > > >> references for use during GC. 2) requires much > > > more co- > > > > > > > operation > > > > > > > > > > >> from the compiler than the current gcc-based > backend > > > > > (with > > > > > > > all of > > > > > > > > > > >> its lovely optimizations and register > allocation) is > > > > > > > capable of > > > > > > > > > > >> doing. 1) is very cheap and does not impede > > > > > optimizations and > > > > > > > > > > >> register allocation. > > > > > > > > > > > > > > > > > > > > > > Presumably, this all also applies WITH-bound > > > > > identifiers, when > > > > > > > > > they > > > > > > > > > > > are > > > > > > > > > > > designators of interior components of heap > objects? > > > Are > > > > > > > there any > > > > > > > > > > > other > > > > > > > > > > > cases? > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > ------------------------------------------------------------- > > > > > > > > > > > Rodney M. Bates, retired assistant professor > > > > > > > > > > > Dept. of Computer Science, Wichita State > University > > > > > > > > > > > Wichita, KS 67260-0083 > > > > > > > > > > > 316-978-3922 > > > > > > > > > > > rodney.bates at wichita.edu > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your smile counts. The more smiles you share, the > more we > > > > > donate. > > > > > > > > > Join in! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Get the power of Windows + Web with the new Windows Live. > > > Power > > > > > up! > > > > > > > > > > > > > > > > > > > > > You keep typing, we keep giving. Download Messenger and > join the > > > > > i?m Initiative now. Join in! > > > > > > > > > > > > > Share life as it happens with the new Windows Live. Share now! > > > > > Your smile counts. The more smiles you share, the more we donate. > Join in! From mika at async.caltech.edu Mon Dec 10 12:38:44 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 10 Dec 2007 03:38:44 -0800 Subject: [M3devel] Using REFANYs to store integers? Message-ID: <200712101138.lBABci5I022046@camembert.async.caltech.edu> Hello Modula-3ers... I have a question about garbage collecting, pointers, and dirty tricks that I'm curious if anyone (Tony??) can answer. Here it is. I am considering writing a bytecode interpreter that is to run mixed into a Modula-3 environment, that is, it will be able to deal with bytecodes as well as Modula-3 objects. There is no problem with that of course, as bytecodes are "code" and Modula-3 objects are "objects" and can live on separate stacks. However, as an optimization (not an uncommon one in these types of systems), I'd like a space and time efficient representation for "small integers". A tried-and-true method (it goes back at least to the Smalltalk-80 runtime) is to realize that pointers (in my case REFANYs) always point to word-aligned addresses. We can then use integers that are congruent to 1, 2, and 3 (mod 4) to represent other types of data. What will happen if I LOOPHOLE such integers back and forth to REFANY? Will the garbage collector just ignore them? I wrote a test program that does it and it doesn't crash... except when you hit ctrl-C, it often dies with an assertion failure in RTCollector.m3.. (This both with my ancient PM3 on FreeBSD and a relatively recent update of CM3 on PPC_DARWIN.) If the garbage collector somehow disapproves of these integers, is there any conceivable thing that would be broken by making necessary adjustments to the garbage collector such that it would just ignore them? Or is there a better way of solving my problem? Best regards, Mika From hosking at cs.purdue.edu Mon Dec 10 15:08:39 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 10 Dec 2007 09:08:39 -0500 Subject: [M3devel] Using REFANYs to store integers? In-Reply-To: <200712101138.lBABci5I022046@camembert.async.caltech.edu> References: <200712101138.lBABci5I022046@camembert.async.caltech.edu> Message-ID: <09A27D37-5334-4269-98D0-8592F10D3AF7@cs.purdue.edu> Yikes. The current collector will expect to find an aligned reference in any global variable or heap field declared as a subtype of REFANY. It will break if it does not find one. You cannot reliably use the technique you describe with Modula-3 as it is currently defined, nor for that matter with any safe language. To do what you want in Modula-3 you would need to use ADDRESS and explicitly test for low bits when using ADDRESS values. Of course, then you'd need to write your own GC for your interpreter (probably not a bad idea anyway, given that you are in much more control). On Dec 10, 2007, at 6:38 AM, Mika Nystrom wrote: > Hello Modula-3ers... > > I have a question about garbage collecting, pointers, and dirty > tricks that I'm curious if anyone (Tony??) can answer. > > Here it is. I am considering writing a bytecode interpreter that > is to run mixed into a Modula-3 environment, that is, it will be > able to deal with bytecodes as well as Modula-3 objects. There is > no problem with that of course, as bytecodes are "code" and Modula-3 > objects are "objects" and can live on separate stacks. However, > as an optimization (not an uncommon one in these types of systems), > I'd like a space and time efficient representation for "small > integers". A tried-and-true method (it goes back at least to the > Smalltalk-80 runtime) is to realize that pointers (in my case > REFANYs) always point to word-aligned addresses. We can then use > integers that are congruent to 1, 2, and 3 (mod 4) to represent > other types of data. > > What will happen if I LOOPHOLE such integers back and forth to > REFANY? Will the garbage collector just ignore them? I wrote a > test program that does it and it doesn't crash... except when you > hit ctrl-C, it often dies with an assertion failure in > RTCollector.m3.. (This both with my ancient PM3 on FreeBSD and a > relatively recent update of CM3 on PPC_DARWIN.) If the garbage > collector somehow disapproves of these integers, is there any > conceivable thing that would be broken by making necessary adjustments > to the garbage collector such that it would just ignore them? > Or is there a better way of solving my problem? > > Best regards, > Mika From mika at async.caltech.edu Mon Dec 10 21:21:13 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 10 Dec 2007 12:21:13 -0800 Subject: [M3devel] Using REFANYs to store integers? In-Reply-To: Your message of "Mon, 10 Dec 2007 13:50:57 CST." <475D98A1.5080604@wichita.edu> Message-ID: <200712102021.lBAKLD4C037596@camembert.async.caltech.edu> Hi Rodney, You're reading my mind. What I am thinking of doing is that I want to optimize the handling of small integers (only), exactly the way it's done in Smalltalk, that is, immutable, single-instance objects. And only the interpreter will ever dereference the objects, so it would check the LSBs---if they are set to zero, it will assume that it's a heap object, if anything else, it's a special immutable value of some sort. I'm well aware it's a very dirty trick to attempt! But I was thinking that by doing this sort of thing I could avoid having to code my own garbage collector. I'm not surprised that the current garbage collector has issues with it but I also cannot think of a reason why one couldn't make it ignore unaligned "pointers" unless the trick is already used for some purpose I am not aware of. Mika "Rodney M. Bates" writes: >I presume "pointers" that are not 0 MOD 4 "refer to" some kinds >of immutable, single-instance objects and don't actually point >to heap objects in need of collection, as in Smalltalk? I would >think it would be a simple modification of the existing M3 GC to >just make it ignore words containing misaligned pointers. > >Will only interpreted bytecode ever dereference these pointers? >Or does M3 compiler-generated code also dereference them? Then >the compiler would also have to generate checks and do whatever >with misaligned pointers. > >Mika Nystrom wrote: >> Hello Modula-3ers... >> >> I have a question about garbage collecting, pointers, and dirty >> tricks that I'm curious if anyone (Tony??) can answer. >> >> Here it is. I am considering writing a bytecode interpreter that >> is to run mixed into a Modula-3 environment, that is, it will be >> able to deal with bytecodes as well as Modula-3 objects. There is >> no problem with that of course, as bytecodes are "code" and Modula-3 >> objects are "objects" and can live on separate stacks. However, >> as an optimization (not an uncommon one in these types of systems), >> I'd like a space and time efficient representation for "small >> integers". A tried-and-true method (it goes back at least to the >> Smalltalk-80 runtime) is to realize that pointers (in my case >> REFANYs) always point to word-aligned addresses. We can then use >> integers that are congruent to 1, 2, and 3 (mod 4) to represent >> other types of data. >> >> What will happen if I LOOPHOLE such integers back and forth to >> REFANY? Will the garbage collector just ignore them? I wrote a >> test program that does it and it doesn't crash... except when you >> hit ctrl-C, it often dies with an assertion failure in >> RTCollector.m3.. (This both with my ancient PM3 on FreeBSD and a >> relatively recent update of CM3 on PPC_DARWIN.) If the garbage >> collector somehow disapproves of these integers, is there any >> conceivable thing that would be broken by making necessary adjustments >> to the garbage collector such that it would just ignore them? >> Or is there a better way of solving my problem? >> >> Best regards, >> Mika >> > >-- >------------------------------------------------------------- >Rodney M. Bates, retired assistant professor >Dept. of Computer Science, Wichita State University >Wichita, KS 67260-0083 >316-978-3922 >rodney.bates at wichita.edu From hosking at cs.purdue.edu Mon Dec 10 23:51:29 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 10 Dec 2007 17:51:29 -0500 Subject: [M3devel] Using REFANYs to store integers? In-Reply-To: <200712102021.lBAKLD4C037596@camembert.async.caltech.edu> References: <200712102021.lBAKLD4C037596@camembert.async.caltech.edu> Message-ID: <9520B700-D9EE-4A1B-ACD0-CB1DEA6C6A7C@cs.purdue.edu> The LSB trick is something that one could teach the current implementation to handle, but I note that there is *nothing* in the language definition that would mean this hack could ever be portable. Moreover, there is reason to expect that a particular GC implementation might use this same trick internally, in which case you have a conflict between your hack and that implementation. Basically, you should not assume *any* particular representation for REFANY in Modula-3. For example, an implementation would be free to use a level of indirection (ie, "handles" or an object table) to implement M3 REFANY. In sum, I think what you propose is a nasty hack. Better to implement your own GC anyway, since it is likely to be much better to exploit the semantics of your interpreter/language for best behavior. On Dec 10, 2007, at 3:21 PM, Mika Nystrom wrote: > Hi Rodney, > > You're reading my mind. What I am thinking of doing is that I want > to optimize the handling of small integers (only), exactly the way > it's done in Smalltalk, that is, immutable, single-instance objects. > And only the interpreter will ever dereference the objects, so it > would check the LSBs---if they are set to zero, it will assume that > it's a heap object, if anything else, it's a special immutable value > of some sort. > > I'm well aware it's a very dirty trick to attempt! But I was > thinking that by doing this sort of thing I could avoid having to > code my own garbage collector. I'm not surprised that the current > garbage collector has issues with it but I also cannot think of a > reason why one couldn't make it ignore unaligned "pointers" unless > the trick is already used for some purpose I am not aware of. > > Mika > > "Rodney M. Bates" writes: >> I presume "pointers" that are not 0 MOD 4 "refer to" some kinds >> of immutable, single-instance objects and don't actually point >> to heap objects in need of collection, as in Smalltalk? I would >> think it would be a simple modification of the existing M3 GC to >> just make it ignore words containing misaligned pointers. >> >> Will only interpreted bytecode ever dereference these pointers? >> Or does M3 compiler-generated code also dereference them? Then >> the compiler would also have to generate checks and do whatever >> with misaligned pointers. >> >> Mika Nystrom wrote: >>> Hello Modula-3ers... >>> >>> I have a question about garbage collecting, pointers, and dirty >>> tricks that I'm curious if anyone (Tony??) can answer. >>> >>> Here it is. I am considering writing a bytecode interpreter that >>> is to run mixed into a Modula-3 environment, that is, it will be >>> able to deal with bytecodes as well as Modula-3 objects. There is >>> no problem with that of course, as bytecodes are "code" and Modula-3 >>> objects are "objects" and can live on separate stacks. However, >>> as an optimization (not an uncommon one in these types of systems), >>> I'd like a space and time efficient representation for "small >>> integers". A tried-and-true method (it goes back at least to the >>> Smalltalk-80 runtime) is to realize that pointers (in my case >>> REFANYs) always point to word-aligned addresses. We can then use >>> integers that are congruent to 1, 2, and 3 (mod 4) to represent >>> other types of data. >>> >>> What will happen if I LOOPHOLE such integers back and forth to >>> REFANY? Will the garbage collector just ignore them? I wrote a >>> test program that does it and it doesn't crash... except when you >>> hit ctrl-C, it often dies with an assertion failure in >>> RTCollector.m3.. (This both with my ancient PM3 on FreeBSD and a >>> relatively recent update of CM3 on PPC_DARWIN.) If the garbage >>> collector somehow disapproves of these integers, is there any >>> conceivable thing that would be broken by making necessary >>> adjustments >>> to the garbage collector such that it would just ignore them? >>> Or is there a better way of solving my problem? >>> >>> Best regards, >>> Mika >>> >> >> -- >> ------------------------------------------------------------- >> Rodney M. Bates, retired assistant professor >> Dept. of Computer Science, Wichita State University >> Wichita, KS 67260-0083 >> 316-978-3922 >> rodney.bates at wichita.edu From mika at async.caltech.edu Tue Dec 11 00:33:44 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 10 Dec 2007 15:33:44 -0800 Subject: [M3devel] Using REFANYs to store integers? In-Reply-To: Your message of "Mon, 10 Dec 2007 17:51:29 EST." <9520B700-D9EE-4A1B-ACD0-CB1DEA6C6A7C@cs.purdue.edu> Message-ID: <200712102333.lBANXiAe044857@camembert.async.caltech.edu> Well, come to think of it... I'm not sure I can even do my own GC. The idea is that the interpreter I am working on would have more or less unrestricted access to the M3 environment, anyhow, and that many of the objects on its stacks will be plain old M3 objects, which will be handled as opaque handles by the interpreter. In other words, I'd have to have and worry about two garbage collectors (M3 + interpreter) if I follow your suggestion. I was really hoping to avoid that. I was also hoping to use your excellent garbage collector rather than having to worry about that too, in addition to all the other issues that come up in coding bytecode compilers, interpreters, with all the other runtime support etc etc. Since I clearly have to support versions of M3 that don't appreciate the LSB hack I am just going to have to be able to represent small integers as something along the lines of TYPE SmallInteger = OBJECT v : INTEGER END anyhow. This is not a problem, it's just going to be slow, since I anticipate that most of the work done by the interpreter will be manipulating small integers (array indices, etc.) Tony, don't worry, I'm not going to give you (much of) a hard time if you come up with a beautiful garbage collector that's incompatible with my "nasty hack"! In any case, I am just thinking aloud (awrite?) and you gentlemen have fully satisfied my curiosity with your answers to my questions. Thanks! Mika Tony Hosking writes: >The LSB trick is something that one could teach the current >implementation to handle, but I note that there is *nothing* in the >language definition that would mean this hack could ever be >portable. Moreover, there is reason to expect that a particular GC >implementation might use this same trick internally, in which case >you have a conflict between your hack and that implementation. >Basically, you should not assume *any* particular representation for >REFANY in Modula-3. For example, an implementation would be free to >use a level of indirection (ie, "handles" or an object table) to >implement M3 REFANY. In sum, I think what you propose is a nasty >hack. Better to implement your own GC anyway, since it is likely to >be much better to exploit the semantics of your interpreter/language >for best behavior. > >On Dec 10, 2007, at 3:21 PM, Mika Nystrom wrote: > >> Hi Rodney, >> >> You're reading my mind. What I am thinking of doing is that I want >> to optimize the handling of small integers (only), exactly the way >> it's done in Smalltalk, that is, immutable, single-instance objects. >> And only the interpreter will ever dereference the objects, so it >> would check the LSBs---if they are set to zero, it will assume that >> it's a heap object, if anything else, it's a special immutable value >> of some sort. >> >> I'm well aware it's a very dirty trick to attempt! But I was >> thinking that by doing this sort of thing I could avoid having to >> code my own garbage collector. I'm not surprised that the current >> garbage collector has issues with it but I also cannot think of a >> reason why one couldn't make it ignore unaligned "pointers" unless >> the trick is already used for some purpose I am not aware of. >> >> Mika >> >> "Rodney M. Bates" writes: >>> I presume "pointers" that are not 0 MOD 4 "refer to" some kinds >>> of immutable, single-instance objects and don't actually point >>> to heap objects in need of collection, as in Smalltalk? I would >>> think it would be a simple modification of the existing M3 GC to >>> just make it ignore words containing misaligned pointers. >>> >>> Will only interpreted bytecode ever dereference these pointers? >>> Or does M3 compiler-generated code also dereference them? Then >>> the compiler would also have to generate checks and do whatever >>> with misaligned pointers. >>> >>> Mika Nystrom wrote: >>>> Hello Modula-3ers... >>>> >>>> I have a question about garbage collecting, pointers, and dirty >>>> tricks that I'm curious if anyone (Tony??) can answer. >>>> >>>> Here it is. I am considering writing a bytecode interpreter that >>>> is to run mixed into a Modula-3 environment, that is, it will be >>>> able to deal with bytecodes as well as Modula-3 objects. There is >>>> no problem with that of course, as bytecodes are "code" and Modula-3 >>>> objects are "objects" and can live on separate stacks. However, >>>> as an optimization (not an uncommon one in these types of systems), >>>> I'd like a space and time efficient representation for "small >>>> integers". A tried-and-true method (it goes back at least to the >>>> Smalltalk-80 runtime) is to realize that pointers (in my case >>>> REFANYs) always point to word-aligned addresses. We can then use >>>> integers that are congruent to 1, 2, and 3 (mod 4) to represent >>>> other types of data. >>>> >>>> What will happen if I LOOPHOLE such integers back and forth to >>>> REFANY? Will the garbage collector just ignore them? I wrote a >>>> test program that does it and it doesn't crash... except when you >>>> hit ctrl-C, it often dies with an assertion failure in >>>> RTCollector.m3.. (This both with my ancient PM3 on FreeBSD and a >>>> relatively recent update of CM3 on PPC_DARWIN.) If the garbage >>>> collector somehow disapproves of these integers, is there any >>>> conceivable thing that would be broken by making necessary >>>> adjustments >>>> to the garbage collector such that it would just ignore them? >>>> Or is there a better way of solving my problem? >>>> >>>> Best regards, >>>> Mika >>>> >>> >>> -- >>> ------------------------------------------------------------- >>> Rodney M. Bates, retired assistant professor >>> Dept. of Computer Science, Wichita State University >>> Wichita, KS 67260-0083 >>> 316-978-3922 >>> rodney.bates at wichita.edu From hosking at cs.purdue.edu Tue Dec 11 04:24:45 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 10 Dec 2007 22:24:45 -0500 Subject: [M3devel] Using REFANYs to store integers? In-Reply-To: <200712102333.lBANXiAe044857@camembert.async.caltech.edu> References: <200712102333.lBANXiAe044857@camembert.async.caltech.edu> Message-ID: I didn't mean to disparage your suggestion -- just pointing out some of the pitfalls. Certainly, the current collectors will have problems if you store tagged values in REFANY fields, since it expects to find aligned references there. I can see a couple of options that might work, some of which might use the WeakRef interface to control reachability. I imagine we could come up with some sort of API that would support this. It might even be an interesting result... On Dec 10, 2007, at 6:33 PM, Mika Nystrom wrote: > > Well, come to think of it... I'm not sure I can even do my own GC. > The idea is that the interpreter I am working on would have more > or less unrestricted access to the M3 environment, anyhow, and that > many of the objects on its stacks will be plain old M3 objects, > which will be handled as opaque handles by the interpreter. In > other words, I'd have to have and worry about two garbage collectors > (M3 + interpreter) if I follow your suggestion. I was really hoping > to avoid that. I was also hoping to use your excellent garbage > collector rather than having to worry about that too, in addition > to all the other issues that come up in coding bytecode compilers, > interpreters, with all the other runtime support etc etc. > > Since I clearly have to support versions of M3 that don't appreciate > the LSB hack I am just going to have to be able to represent small > integers as something along the lines of > > TYPE SmallInteger = OBJECT v : INTEGER END > > anyhow. This is not a problem, it's just going to be slow, since > I anticipate that most of the work done by the interpreter will be > manipulating small integers (array indices, etc.) Tony, don't > worry, I'm not going to give you (much of) a hard time if you come > up with a beautiful garbage collector that's incompatible with my > "nasty hack"! > > In any case, I am just thinking aloud (awrite?) and you gentlemen > have fully satisfied my curiosity with your answers to my questions. > Thanks! > > Mika > > Tony Hosking writes: >> The LSB trick is something that one could teach the current >> implementation to handle, but I note that there is *nothing* in the >> language definition that would mean this hack could ever be >> portable. Moreover, there is reason to expect that a particular GC >> implementation might use this same trick internally, in which case >> you have a conflict between your hack and that implementation. >> Basically, you should not assume *any* particular representation for >> REFANY in Modula-3. For example, an implementation would be free to >> use a level of indirection (ie, "handles" or an object table) to >> implement M3 REFANY. In sum, I think what you propose is a nasty >> hack. Better to implement your own GC anyway, since it is likely to >> be much better to exploit the semantics of your interpreter/language >> for best behavior. >> >> On Dec 10, 2007, at 3:21 PM, Mika Nystrom wrote: >> >>> Hi Rodney, >>> >>> You're reading my mind. What I am thinking of doing is that I want >>> to optimize the handling of small integers (only), exactly the way >>> it's done in Smalltalk, that is, immutable, single-instance objects. >>> And only the interpreter will ever dereference the objects, so it >>> would check the LSBs---if they are set to zero, it will assume that >>> it's a heap object, if anything else, it's a special immutable value >>> of some sort. >>> >>> I'm well aware it's a very dirty trick to attempt! But I was >>> thinking that by doing this sort of thing I could avoid having to >>> code my own garbage collector. I'm not surprised that the current >>> garbage collector has issues with it but I also cannot think of a >>> reason why one couldn't make it ignore unaligned "pointers" unless >>> the trick is already used for some purpose I am not aware of. >>> >>> Mika >>> >>> "Rodney M. Bates" writes: >>>> I presume "pointers" that are not 0 MOD 4 "refer to" some kinds >>>> of immutable, single-instance objects and don't actually point >>>> to heap objects in need of collection, as in Smalltalk? I would >>>> think it would be a simple modification of the existing M3 GC to >>>> just make it ignore words containing misaligned pointers. >>>> >>>> Will only interpreted bytecode ever dereference these pointers? >>>> Or does M3 compiler-generated code also dereference them? Then >>>> the compiler would also have to generate checks and do whatever >>>> with misaligned pointers. >>>> >>>> Mika Nystrom wrote: >>>>> Hello Modula-3ers... >>>>> >>>>> I have a question about garbage collecting, pointers, and dirty >>>>> tricks that I'm curious if anyone (Tony??) can answer. >>>>> >>>>> Here it is. I am considering writing a bytecode interpreter that >>>>> is to run mixed into a Modula-3 environment, that is, it will be >>>>> able to deal with bytecodes as well as Modula-3 objects. There is >>>>> no problem with that of course, as bytecodes are "code" and >>>>> Modula-3 >>>>> objects are "objects" and can live on separate stacks. However, >>>>> as an optimization (not an uncommon one in these types of >>>>> systems), >>>>> I'd like a space and time efficient representation for "small >>>>> integers". A tried-and-true method (it goes back at least to the >>>>> Smalltalk-80 runtime) is to realize that pointers (in my case >>>>> REFANYs) always point to word-aligned addresses. We can then use >>>>> integers that are congruent to 1, 2, and 3 (mod 4) to represent >>>>> other types of data. >>>>> >>>>> What will happen if I LOOPHOLE such integers back and forth to >>>>> REFANY? Will the garbage collector just ignore them? I wrote a >>>>> test program that does it and it doesn't crash... except when you >>>>> hit ctrl-C, it often dies with an assertion failure in >>>>> RTCollector.m3.. (This both with my ancient PM3 on FreeBSD and a >>>>> relatively recent update of CM3 on PPC_DARWIN.) If the garbage >>>>> collector somehow disapproves of these integers, is there any >>>>> conceivable thing that would be broken by making necessary >>>>> adjustments >>>>> to the garbage collector such that it would just ignore them? >>>>> Or is there a better way of solving my problem? >>>>> >>>>> Best regards, >>>>> Mika >>>>> >>>> >>>> -- >>>> ------------------------------------------------------------- >>>> Rodney M. Bates, retired assistant professor >>>> Dept. of Computer Science, Wichita State University >>>> Wichita, KS 67260-0083 >>>> 316-978-3922 >>>> rodney.bates at wichita.edu From mika at async.caltech.edu Wed Dec 12 10:47:52 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 12 Dec 2007 01:47:52 -0800 Subject: [M3devel] Using REFANYs to store integers? In-Reply-To: Your message of "Mon, 10 Dec 2007 22:24:45 EST." Message-ID: <200712120947.lBC9lq5d019613@camembert.async.caltech.edu> Tony Hosking writes: >I didn't mean to disparage your suggestion -- just pointing out some >of the pitfalls. Certainly, the current collectors will have >problems if you store tagged values in REFANY fields, since it >expects to find aligned references there. I can see a couple of >options that might work, some of which might use the WeakRef >interface to control reachability. I imagine we could come up with >some sort of API that would support this. It might even be an >interesting result... > Oh I know that. It's clear that even if one does use the hack I have described, it would be criminal to release code that couldn't survive without it. As you point out there are many conceivable M3 implementations that might not support such a nasty hack. I think your idea of an API could be an interesting exercise---you could "squirrel away" data in REFANYs that don't actually refer to anything but are themselves values (ANYs?). Of course there's not much point (is there?) unless the squirreling and un-squirreling is more efficient than an extra memory allocation and dereference. I take it that the API could also tell the hacker when the hack is unavailable, for any of the reasons you have mentioned... Mika >On Dec 10, 2007, at 6:33 PM, Mika Nystrom wrote: > >> >> Well, come to think of it... I'm not sure I can even do my own GC. >> The idea is that the interpreter I am working on would have more >> or less unrestricted access to the M3 environment, anyhow, and that >> many of the objects on its stacks will be plain old M3 objects, >> which will be handled as opaque handles by the interpreter. In >> other words, I'd have to have and worry about two garbage collectors >> (M3 + interpreter) if I follow your suggestion. I was really hoping >> to avoid that. I was also hoping to use your excellent garbage >> collector rather than having to worry about that too, in addition >> to all the other issues that come up in coding bytecode compilers, >> interpreters, with all the other runtime support etc etc. >> >> Since I clearly have to support versions of M3 that don't appreciate >> the LSB hack I am just going to have to be able to represent small >> integers as something along the lines of >> >> TYPE SmallInteger = OBJECT v : INTEGER END >> >> anyhow. This is not a problem, it's just going to be slow, since >> I anticipate that most of the work done by the interpreter will be >> manipulating small integers (array indices, etc.) Tony, don't >> worry, I'm not going to give you (much of) a hard time if you come >> up with a beautiful garbage collector that's incompatible with my >> "nasty hack"! >> >> In any case, I am just thinking aloud (awrite?) and you gentlemen >> have fully satisfied my curiosity with your answers to my questions. >> Thanks! >> >> Mika >> >> Tony Hosking writes: >>> The LSB trick is something that one could teach the current >>> implementation to handle, but I note that there is *nothing* in the >>> language definition that would mean this hack could ever be >>> portable. Moreover, there is reason to expect that a particular GC >>> implementation might use this same trick internally, in which case >>> you have a conflict between your hack and that implementation. >>> Basically, you should not assume *any* particular representation for >>> REFANY in Modula-3. For example, an implementation would be free to >>> use a level of indirection (ie, "handles" or an object table) to >>> implement M3 REFANY. In sum, I think what you propose is a nasty >>> hack. Better to implement your own GC anyway, since it is likely to >>> be much better to exploit the semantics of your interpreter/language >>> for best behavior. >>> >>> On Dec 10, 2007, at 3:21 PM, Mika Nystrom wrote: >>> >>>> Hi Rodney, >>>> >>>> You're reading my mind. What I am thinking of doing is that I want >>>> to optimize the handling of small integers (only), exactly the way >>>> it's done in Smalltalk, that is, immutable, single-instance objects. >>>> And only the interpreter will ever dereference the objects, so it >>>> would check the LSBs---if they are set to zero, it will assume that >>>> it's a heap object, if anything else, it's a special immutable value >>>> of some sort. >>>> >>>> I'm well aware it's a very dirty trick to attempt! But I was >>>> thinking that by doing this sort of thing I could avoid having to >>>> code my own garbage collector. I'm not surprised that the current >>>> garbage collector has issues with it but I also cannot think of a >>>> reason why one couldn't make it ignore unaligned "pointers" unless >>>> the trick is already used for some purpose I am not aware of. >>>> >>>> Mika >>>> >>>> "Rodney M. Bates" writes: >>>>> I presume "pointers" that are not 0 MOD 4 "refer to" some kinds >>>>> of immutable, single-instance objects and don't actually point >>>>> to heap objects in need of collection, as in Smalltalk? I would >>>>> think it would be a simple modification of the existing M3 GC to >>>>> just make it ignore words containing misaligned pointers. >>>>> >>>>> Will only interpreted bytecode ever dereference these pointers? >>>>> Or does M3 compiler-generated code also dereference them? Then >>>>> the compiler would also have to generate checks and do whatever >>>>> with misaligned pointers. >>>>> >>>>> Mika Nystrom wrote: >>>>>> Hello Modula-3ers... >>>>>> >>>>>> I have a question about garbage collecting, pointers, and dirty >>>>>> tricks that I'm curious if anyone (Tony??) can answer. >>>>>> >>>>>> Here it is. I am considering writing a bytecode interpreter that >>>>>> is to run mixed into a Modula-3 environment, that is, it will be >>>>>> able to deal with bytecodes as well as Modula-3 objects. There is >>>>>> no problem with that of course, as bytecodes are "code" and >>>>>> Modula-3 >>>>>> objects are "objects" and can live on separate stacks. However, >>>>>> as an optimization (not an uncommon one in these types of >>>>>> systems), >>>>>> I'd like a space and time efficient representation for "small >>>>>> integers". A tried-and-true method (it goes back at least to the >>>>>> Smalltalk-80 runtime) is to realize that pointers (in my case >>>>>> REFANYs) always point to word-aligned addresses. We can then use >>>>>> integers that are congruent to 1, 2, and 3 (mod 4) to represent >>>>>> other types of data. >>>>>> >>>>>> What will happen if I LOOPHOLE such integers back and forth to >>>>>> REFANY? Will the garbage collector just ignore them? I wrote a >>>>>> test program that does it and it doesn't crash... except when you >>>>>> hit ctrl-C, it often dies with an assertion failure in >>>>>> RTCollector.m3.. (This both with my ancient PM3 on FreeBSD and a >>>>>> relatively recent update of CM3 on PPC_DARWIN.) If the garbage >>>>>> collector somehow disapproves of these integers, is there any >>>>>> conceivable thing that would be broken by making necessary >>>>>> adjustments >>>>>> to the garbage collector such that it would just ignore them? >>>>>> Or is there a better way of solving my problem? >>>>>> >>>>>> Best regards, >>>>>> Mika >>>>>> >>>>> >>>>> -- >>>>> ------------------------------------------------------------- >>>>> Rodney M. Bates, retired assistant professor >>>>> Dept. of Computer Science, Wichita State University >>>>> Wichita, KS 67260-0083 >>>>> 316-978-3922 >>>>> rodney.bates at wichita.edu From wagner at elegosoft.com Sat Dec 15 23:50:51 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 15 Dec 2007 23:50:51 +0100 Subject: [M3devel] Spanish speaking CM3 users? Message-ID: <20071215235051.rhq0fgeabk4k48gk@mail.elegosoft.com> Hi, I found this in our company's contact box. Is there somebody here with better Spanish knowledge than me who'd like to help? Olaf ----- Forwarded message from anietog at unal.edu.co ----- Date: Sat, 15 Dec 2007 17:55:45 +0100 (CET) From: Angela Reply-To: Angela Subject: Anfrage Mailformular To: info at elego.de NAME: Angela EMAIL: anietog at unal.edu.co ADDRESS: Hola, escribo porque tengo un problema al tratar de compilar el compilador de fase 1, esto es lo que me aparece: .... new source -> compiling Text.i3 new source -> compiling RTProcedureSRC.i3 new source -> compiling Fingerprint.i3 new source -> compiling RTProcedure.i3 new source -> compiling RTStack.i3 new source -> compiling RTAllocStats.m3 "../src/runtime/common/RTAllocStats.m3", line 46: undefined runtime symbol !! (RTHooks.AllocateTracedRef) *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x80c5c3c = StartCall + 0x18 in ../src/values/Procedure.m3 *** Aborted (core dumped) *** execution of failed *** Agradezco cualquier colaboraci?n ya que aun no he podido culminar mi instalacion de cm3. ----- End forwarded message ----- -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- NAME: Angela EMAIL: anietog at unal.edu.co ADDRESS: Hola, escribo porque tengo un problema al tratar de compilar el compilador de fase 1, esto es lo que me aparece: .... new source -> compiling Text.i3 new source -> compiling RTProcedureSRC.i3 new source -> compiling Fingerprint.i3 new source -> compiling RTProcedure.i3 new source -> compiling RTStack.i3 new source -> compiling RTAllocStats.m3 "../src/runtime/common/RTAllocStats.m3", line 46: undefined runtime symbol !! (RTHooks.AllocateTracedRef) *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x80c5c3c = StartCall + 0x18 in ../src/values/Procedure.m3 *** Aborted (core dumped) *** execution of failed *** Agradezco cualquier colaboraci?n ya que aun no he podido culminar mi instalacion de cm3. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ndantam at purdue.edu Sun Dec 16 00:42:11 2007 From: ndantam at purdue.edu (Neil T. Dantam) Date: Sat, 15 Dec 2007 18:42:11 -0500 Subject: [M3devel] Spanish speaking CM3 users? In-Reply-To: <20071215235051.rhq0fgeabk4k48gk@mail.elegosoft.com> References: <20071215235051.rhq0fgeabk4k48gk@mail.elegosoft.com> Message-ID: <47646653.4070106@purdue.edu> Olaf, I can at least translate the Spanish for you. Angela, ?Tratar los instrucciones de este mensaje? (Did you try the instructions in this email?) https://mail.elegosoft.com/pipermail/m3devel/2007-June/000227.html Describen como compilar el compilador. (They describe how to bootstrap the compiler.) Olaf Wagner wrote: > ----- Forwarded message from anietog at unal.edu.co ----- > Date: Sat, 15 Dec 2007 17:55:45 +0100 (CET) > From: Angela > Reply-To: Angela > Subject: Anfrage Mailformular > To: info at elego.de > > NAME: Angela > EMAIL: anietog at unal.edu.co > ADDRESS: > Hola, escribo porque tengo un problema al tratar de compilar el > compilador de fase 1, esto es lo que me aparece: Hello, I'm writing because I have a problem regarding compiling phase one of the compiler. This is what I see: > .... > new source -> compiling Text.i3 > new source -> compiling RTProcedureSRC.i3 > new source -> compiling Fingerprint.i3 > new source -> compiling RTProcedure.i3 > new source -> compiling RTStack.i3 > new source -> compiling RTAllocStats.m3 > "../src/runtime/common/RTAllocStats.m3", line 46: undefined runtime > symbol !! (RTHooks.AllocateTracedRef) > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0x80c5c3c = StartCall + 0x18 in ../src/values/Procedure.m3 > *** > > Aborted (core dumped) > *** execution of failed *** > > > Agradezco cualquier colaboraci?n ya que aun no he podido culminar mi > instalacion de cm3. I would appreciate any help, because I could not finish my installation of cm3. > > ----- End forwarded message ----- -- Neil T. Dantam From mika at async.caltech.edu Sun Dec 16 01:18:29 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 15 Dec 2007 16:18:29 -0800 Subject: [M3devel] Ubuntu problems Message-ID: <200712160018.lBG0ITO5026048@camembert.async.caltech.edu> Hello Modula-3 people, I am trying to build things with CM3 on a relatively recent Ubuntu system (don't ask me why...) and I am running into a segfault that I haven't seen mentioned before. I have a feeling it has something to do with stack formats, but I'm not sure what to do next. I downloaded the cm3-5.4.0 binaries and started with that. The compiler in the binary distribution runs, but it appears to produce garbage. I first tried bootstrapping but it crashes the moment it tries to execute something it has compiled itself. So then I tried hello, world, with the same results... Here's the system identification: mika at edwards:~/test/src$ uname -a Linux edwards 2.6.20-16-386 #2 Sun Sep 23 19:47:10 UTC 2007 i686 GNU/Linux I made a "hello, world" program as follows: MODULE Main; IMPORT IO; BEGIN IO.Put("Hello, world!\n") END Main. Compiled with cm3 directly from the distributed cm3-5.4.0 for LINUXLIBC6 and I get a crash in CsetjmpASM.s (as far as I can tell). The last unclobbered stack I seem to be able to get in m3gdb is this: Breakpoint 5, 0xb75e5fb4 in _setjmp () at ../src/C/LINUXLIBC6/CsetjmpASM.s:31 31 in ../src/C/LINUXLIBC6/CsetjmpASM.s (m3gdb) where #0 0xb75e5fb4 in _setjmp () at ../src/C/LINUXLIBC6/CsetjmpASM.s:31 #1 0xb75dbd51 in RTThread__Transfer (from=0xbfe28530, to=0xbfe28530) at ../src/runtime/LINUXLIBC6/RTThreadC.c:14 #2 0xb75dbaed in FlushStackCache () at RTThread.m3:65 #3 0xb75e27c9 in DetermineContext (oldSP=Invalid C/C++ type code 35 in symbol table. ) at ThreadPosix.m3:1101 #4 0xb75e270d in InitTopContext (c=Invalid C/C++ type code 30 in symbol table. ) at ThreadPosix.m3:1076 #5 0xb75e4325 in Init () at ThreadPosix.m3:1498 #6 0xb75c9592 in InitRuntime (p_argc=Invalid C/C++ type code 39 in symbol table. ) at RTLinker.m3:59 #7 0x08048861 in main (argc=1, argv=0xbfe28824, envp=0xbfe2882c) at _m3main.mc:3 (m3gdb) cont Continuing. Program received signal SIGSEGV, Segmentation fault. 0xa8dbaede in ?? () s.sp was lately 16_b75af6b9, if that means anything at all. Oh yes, one more thing: setting LD_POINTER_GUARD to 0 before running the program has no effect on the crash. Any suggestions for how one might make progress on this? Mika From mika at async.caltech.edu Sun Dec 16 02:35:54 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 15 Dec 2007 17:35:54 -0800 Subject: [M3devel] Ubuntu problems In-Reply-To: Your message of "Sat, 15 Dec 2007 16:18:29 PST." <200712160018.lBG0ITO5026048@camembert.async.caltech.edu> Message-ID: <200712160135.lBG1ZsZ2028488@camembert.async.caltech.edu> Sorry, I have now read the mailing list archives a bit better. I am going to try bootstrapping the latest CVS with Tony's cm3 binary, to use pthreads... Mika Mika Nystrom writes: >Hello Modula-3 people, > >I am trying to build things with CM3 on a relatively recent Ubuntu >system (don't ask me why...) and I am running into a segfault that >I haven't seen mentioned before. I have a feeling it has something >to do with stack formats, but I'm not sure what to do next. > >I downloaded the cm3-5.4.0 binaries and started with that. The >compiler in the binary distribution runs, but it appears to produce >garbage. I first tried bootstrapping but it crashes the moment it >tries to execute something it has compiled itself. So then I tried >hello, world, with the same results... > >Here's the system identification: > >mika at edwards:~/test/src$ uname -a >Linux edwards 2.6.20-16-386 #2 Sun Sep 23 19:47:10 UTC 2007 i686 GNU/Linux > >I made a "hello, world" program as follows: > >MODULE Main; >IMPORT IO; > >BEGIN IO.Put("Hello, world!\n") END Main. > >Compiled with cm3 directly from the distributed cm3-5.4.0 for >LINUXLIBC6 and I get a crash in CsetjmpASM.s (as far as I can tell). >The last unclobbered stack I seem to be able to get in m3gdb is >this: > >Breakpoint 5, 0xb75e5fb4 in _setjmp () at ../src/C/LINUXLIBC6/CsetjmpASM.s:31 >31 in ../src/C/LINUXLIBC6/CsetjmpASM.s >(m3gdb) where >#0 0xb75e5fb4 in _setjmp () at ../src/C/LINUXLIBC6/CsetjmpASM.s:31 >#1 0xb75dbd51 in RTThread__Transfer (from=0xbfe28530, to=0xbfe28530) at ../sr >c/runtime/LINUXLIBC6/RTThreadC.c:14 >#2 0xb75dbaed in FlushStackCache () at RTThread.m3:65 >#3 0xb75e27c9 in DetermineContext (oldSP=Invalid C/C++ type code 35 in symbol > table. >) at ThreadPosix.m3:1101 >#4 0xb75e270d in InitTopContext (c=Invalid C/C++ type code 30 in symbol table >. >) at ThreadPosix.m3:1076 >#5 0xb75e4325 in Init () at ThreadPosix.m3:1498 >#6 0xb75c9592 in InitRuntime (p_argc=Invalid C/C++ type code 39 in symbol tab >le. >) at RTLinker.m3:59 >#7 0x08048861 in main (argc=1, argv=0xbfe28824, envp=0xbfe2882c) at _m3main.m >c:3 >(m3gdb) cont >Continuing. > >Program received signal SIGSEGV, Segmentation fault. >0xa8dbaede in ?? () > >s.sp was lately 16_b75af6b9, if that means anything at all. > >Oh yes, one more thing: setting LD_POINTER_GUARD to 0 before running >the program has no effect on the crash. > >Any suggestions for how one might make progress on this? > > Mika From dabenavidesd at yahoo.es Sun Dec 16 02:38:03 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 16 Dec 2007 02:38:03 +0100 (CET) Subject: [M3devel] Ubuntu problems In-Reply-To: <200712160018.lBG0ITO5026048@camembert.async.caltech.edu> Message-ID: <147313.32986.qm@web27106.mail.ukl.yahoo.com> Hi Mika, what are you seeing is the problem of libc setjmp/longjmp issue that we maybe have to advise more to cm3 users, and in general *m3 (dec-src,pm3,ezm3,and cm3 too) users that () user level thread implementation which is part of m3core is not working at this moment, so until community can make a functioning a new implementation, we will use only PTHREAD implementation on most new Linux distributions. Of course this solves the problems you are noticing, so my advise in order to this do not happen any more is write a note on the Download Area and maybe also in (like a note in the Known issues), www.modula3.org (If you allow me, I can do it) The most common case I know a (not very recent) of distribution that works with user level implementation that I use is Ubuntu Dapper 6.06, the libray is 2.3.6 http://packages.ubuntu.com/dapper/libdevel/libc6-dev The next version of Ubuntu breaks when the Juno package is compiling (pkl-fonts program executes), the library libc6 is http://packages.ubuntu.com/edgy/libdevel/libc6-dev. So for 5.4 sources use use the next CM3 variable export CM3="/usr/local/cm3/bin/cm3 -DPTHREAD" This enable the system level thread implementation in a earlier version of it (of cvs), but in the first step bootstrap compiler you will ran in same problems (in Edgy I got breack when running pkl-fonts, but after that break you can re-compile it all well with no problems, after you have build the new m3core). If you can update the sources with the most recent (in a personal opinion, stable version) would be better, but here I would like to know if the script upgrade.sh can do that work, i have not use it. For me the most easy way for me was use the instruction given by Tony for the cvs version, from I take his words and make a relatively simple instructions. Thanks --- Mika Nystrom wrote: > Hello Modula-3 people, > > I am trying to build things with CM3 on a relatively > recent Ubuntu > system (don't ask me why...) and I am running into a > segfault that > I haven't seen mentioned before. I have a feeling > it has something > to do with stack formats, but I'm not sure what to > do next. > > I downloaded the cm3-5.4.0 binaries and started with > that. The > compiler in the binary distribution runs, but it > appears to produce > garbage. I first tried bootstrapping but it crashes > the moment it > tries to execute something it has compiled itself. > So then I tried > hello, world, with the same results... > > Here's the system identification: > > mika at edwards:~/test/src$ uname -a > Linux edwards 2.6.20-16-386 #2 Sun Sep 23 19:47:10 > UTC 2007 i686 GNU/Linux > > I made a "hello, world" program as follows: > > MODULE Main; > IMPORT IO; > > BEGIN IO.Put("Hello, world!\n") END Main. > > Compiled with cm3 directly from the distributed > cm3-5.4.0 for > LINUXLIBC6 and I get a crash in CsetjmpASM.s (as far > as I can tell). > The last unclobbered stack I seem to be able to get > in m3gdb is > this: > > Breakpoint 5, 0xb75e5fb4 in _setjmp () at > ../src/C/LINUXLIBC6/CsetjmpASM.s:31 > 31 in ../src/C/LINUXLIBC6/CsetjmpASM.s > (m3gdb) where > #0 0xb75e5fb4 in _setjmp () at > ../src/C/LINUXLIBC6/CsetjmpASM.s:31 > #1 0xb75dbd51 in RTThread__Transfer > (from=0xbfe28530, to=0xbfe28530) at > ../src/runtime/LINUXLIBC6/RTThreadC.c:14 > #2 0xb75dbaed in FlushStackCache () at > RTThread.m3:65 > #3 0xb75e27c9 in DetermineContext (oldSP=Invalid > C/C++ type code 35 in symbol table. > ) at ThreadPosix.m3:1101 > #4 0xb75e270d in InitTopContext (c=Invalid C/C++ > type code 30 in symbol table. > ) at ThreadPosix.m3:1076 > #5 0xb75e4325 in Init () at ThreadPosix.m3:1498 > #6 0xb75c9592 in InitRuntime (p_argc=Invalid C/C++ > type code 39 in symbol table. > ) at RTLinker.m3:59 > #7 0x08048861 in main (argc=1, argv=0xbfe28824, > envp=0xbfe2882c) at _m3main.mc:3 > (m3gdb) cont > Continuing. > > Program received signal SIGSEGV, Segmentation fault. > 0xa8dbaede in ?? () > > s.sp was lately 16_b75af6b9, if that means anything > at all. > > Oh yes, one more thing: setting LD_POINTER_GUARD to > 0 before running > the program has no effect on the crash. > > Any suggestions for how one might make progress on > this? > > Mika > ______________________________________________ ?Chef por primera vez? S? un mejor Cocinillas. http://es.answers.yahoo.com/info/welcome From jay.krell at cornell.edu Sun Dec 16 03:14:29 2007 From: jay.krell at cornell.edu (Jay) Date: Sun, 16 Dec 2007 02:14:29 +0000 Subject: [M3devel] Ubuntu problems In-Reply-To: <147313.32986.qm@web27106.mail.ukl.yahoo.com> References: <200712160018.lBG0ITO5026048@camembert.async.caltech.edu> <147313.32986.qm@web27106.mail.ukl.yahoo.com> Message-ID: Maybe time to grab a BSD setjmp/longjmp or getcontext/setcontext, rename by prepending with m3_, and be done with it?? e.g.http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/arch/i386/sys/getcontext.S?rev=1.2&content-type=text/x-cvsweb-markuphttp://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/arch/powerpc/sys/getcontext.S?rev=1.3&content-type=text/x-cvsweb-markup My goodness, none of FreeBSD, OpenBSD, NetBSD have web searchable CVS archives.. better links later.. Regarding upgrade.sh, well, on Windows upgrade.cmd works. :) They are all "just" wrappers around cd'ing and building, but perhaps not trivial. - Jay > Date: Sun, 16 Dec 2007 02:38:03 +0100> From: dabenavidesd at yahoo.es> To: mika at async.caltech.edu; m3devel at elegosoft.com> CC: mika at camembert.async.caltech.edu> Subject: Re: [M3devel] Ubuntu problems> > Hi Mika,> what are you seeing is the problem of libc> setjmp/longjmp issue that we maybe have to advise more> to cm3 users, and in general *m3 (dec-src,pm3,ezm3,and> cm3 too) users that () user level thread> implementation which is part of m3core is not working> at this moment, so until community can make a> functioning a new implementation, we will use only> PTHREAD implementation on most new Linux> distributions.> Of course this solves the problems you are noticing,> so my advise in order to this do not happen any more> is write a note on the Download Area and maybe also in> (like a note in the Known issues), www.modula3.org> (If you allow me, I can do it)> > The most common case I know a (not very recent) of > distribution that works with user level implementation> that I use is Ubuntu Dapper 6.06, the libray is 2.3.6> http://packages.ubuntu.com/dapper/libdevel/libc6-dev> The next version of Ubuntu breaks when the Juno> package is compiling (pkl-fonts program executes), the> library libc6 is> http://packages.ubuntu.com/edgy/libdevel/libc6-dev.> > So for 5.4 sources use use the next CM3 variable> export CM3="/usr/local/cm3/bin/cm3 -DPTHREAD"> > This enable the system level thread implementation in> a earlier version of it (of cvs), but in the first> step bootstrap compiler you will ran in same problems> (in Edgy I got breack when running pkl-fonts, but> after that break you can re-compile it all well with> no problems, after you have build the new m3core).> If you can update the sources with the most recent (in> a personal opinion, stable version) would be better,> but here I would like to know if the script upgrade.sh> can do that work, i have not use it.> For me the most easy way for me was use the> instruction given by Tony for the cvs version, from I> take his words and make a relatively simple> instructions.> > Thanks> > > > > > > --- Mika Nystrom wrote:> > > Hello Modula-3 people,> > > > I am trying to build things with CM3 on a relatively> > recent Ubuntu> > system (don't ask me why...) and I am running into a> > segfault that> > I haven't seen mentioned before. I have a feeling> > it has something> > to do with stack formats, but I'm not sure what to> > do next.> > > > I downloaded the cm3-5.4.0 binaries and started with> > that. The > > compiler in the binary distribution runs, but it> > appears to produce> > garbage. I first tried bootstrapping but it crashes> > the moment it> > tries to execute something it has compiled itself. > > So then I tried> > hello, world, with the same results...> > > > Here's the system identification:> > > > mika at edwards:~/test/src$ uname -a> > Linux edwards 2.6.20-16-386 #2 Sun Sep 23 19:47:10> > UTC 2007 i686 GNU/Linux> > > > I made a "hello, world" program as follows:> > > > MODULE Main;> > IMPORT IO;> > > > BEGIN IO.Put("Hello, world!\n") END Main.> > > > Compiled with cm3 directly from the distributed> > cm3-5.4.0 for > > LINUXLIBC6 and I get a crash in CsetjmpASM.s (as far> > as I can tell).> > The last unclobbered stack I seem to be able to get> > in m3gdb is> > this:> > > > Breakpoint 5, 0xb75e5fb4 in _setjmp () at> > ../src/C/LINUXLIBC6/CsetjmpASM.s:31> > 31 in ../src/C/LINUXLIBC6/CsetjmpASM.s> > (m3gdb) where> > #0 0xb75e5fb4 in _setjmp () at> > ../src/C/LINUXLIBC6/CsetjmpASM.s:31> > #1 0xb75dbd51 in RTThread__Transfer> > (from=0xbfe28530, to=0xbfe28530) at> > ../src/runtime/LINUXLIBC6/RTThreadC.c:14> > #2 0xb75dbaed in FlushStackCache () at> > RTThread.m3:65> > #3 0xb75e27c9 in DetermineContext (oldSP=Invalid> > C/C++ type code 35 in symbol table.> > ) at ThreadPosix.m3:1101> > #4 0xb75e270d in InitTopContext (c=Invalid C/C++> > type code 30 in symbol table.> > ) at ThreadPosix.m3:1076> > #5 0xb75e4325 in Init () at ThreadPosix.m3:1498> > #6 0xb75c9592 in InitRuntime (p_argc=Invalid C/C++> > type code 39 in symbol table.> > ) at RTLinker.m3:59> > #7 0x08048861 in main (argc=1, argv=0xbfe28824,> > envp=0xbfe2882c) at _m3main.mc:3> > (m3gdb) cont> > Continuing.> > > > Program received signal SIGSEGV, Segmentation fault.> > 0xa8dbaede in ?? ()> > > > s.sp was lately 16_b75af6b9, if that means anything> > at all.> > > > Oh yes, one more thing: setting LD_POINTER_GUARD to> > 0 before running> > the program has no effect on the crash.> > > > Any suggestions for how one might make progress on> > this?> > > > Mika> > > > > > > ______________________________________________ > ?Chef por primera vez?> S? un mejor Cocinillas. > http://es.answers.yahoo.com/info/welcome _________________________________________________________________ Don't get caught with egg on your face. Play Chicktionary! http://club.live.com/chicktionary.aspx?icid=chick_wlhmtextlink1_dec -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 16 03:40:19 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 15 Dec 2007 21:40:19 -0500 Subject: [M3devel] Ubuntu problems In-Reply-To: References: <200712160018.lBG0ITO5026048@camembert.async.caltech.edu> <147313.32986.qm@web27106.mail.ukl.yahoo.com> Message-ID: It may be slightly trickier than that, since appropriately sized jmpbuf/ucontext needs to be declared. On Dec 15, 2007, at 9:14 PM, Jay wrote: > Maybe time to grab a BSD setjmp/longjmp or getcontext/setcontext, > rename by prepending with m3_, and be done with it?? > e.g. > http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/arch/i386/sys/ > getcontext.S?rev=1.2&content-type=text/x-cvsweb-markup > http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/arch/powerpc/sys/ > getcontext.S?rev=1.3&content-type=text/x-cvsweb-markup > > My goodness, none of FreeBSD, OpenBSD, NetBSD have web searchable > CVS archives.. > better links later.. > > Regarding upgrade.sh, well, on Windows upgrade.cmd works. :) > They are all "just" wrappers around cd'ing and building, but > perhaps not trivial. > > - Jay > > > > Date: Sun, 16 Dec 2007 02:38:03 +0100 > > From: dabenavidesd at yahoo.es > > To: mika at async.caltech.edu; m3devel at elegosoft.com > > CC: mika at camembert.async.caltech.edu > > Subject: Re: [M3devel] Ubuntu problems > > > > Hi Mika, > > what are you seeing is the problem of libc > > setjmp/longjmp issue that we maybe have to advise more > > to cm3 users, and in general *m3 (dec-src,pm3,ezm3,and > > cm3 too) users that () user level thread > > implementation which is part of m3core is not working > > at this moment, so until community can make a > > functioning a new implementation, we will use only > > PTHREAD implementation on most new Linux > > distributions. > > Of course this solves the problems you are noticing, > > so my advise in order to this do not happen any more > > is write a note on the Download Area and maybe also in > > (like a note in the Known issues), www.modula3.org > > (If you allow me, I can do it) > > > > The most common case I know a (not very recent) of > > distribution that works with user level implementation > > that I use is Ubuntu Dapper 6.06, the libray is 2.3.6 > > http://packages.ubuntu.com/dapper/libdevel/libc6-dev > > The next version of Ubuntu breaks when the Juno > > package is compiling (pkl-fonts program executes), the > > library libc6 is > > http://packages.ubuntu.com/edgy/libdevel/libc6-dev. > > > > So for 5.4 sources use use the next CM3 variable > > export CM3="/usr/local/cm3/bin/cm3 -DPTHREAD" > > > > This enable the system level thread implementation in > > a earlier version of it (of cvs), but in the first > > step bootstrap compiler you will ran in same problems > > (in Edgy I got breack when running pkl-fonts, but > > after that break you can re-compile it all well with > > no problems, after you have build the new m3core). > > If you can update the sources with the most recent (in > > a personal opinion, stable version) would be better, > > but here I would like to know if the script upgrade.sh > > can do that work, i have not use it. > > For me the most easy way for me was use the > > instruction given by Tony for the cvs version, from I > > take his words and make a relatively simple > > instructions. > > > > Thanks > > > > > > > > > > > > > > --- Mika Nystrom wrote: > > > > > Hello Modula-3 people, > > > > > > I am trying to build things with CM3 on a relatively > > > recent Ubuntu > > > system (don't ask me why...) and I am running into a > > > segfault that > > > I haven't seen mentioned before. I have a feeling > > > it has something > > > to do with stack formats, but I'm not sure what to > > > do next. > > > > > > I downloaded the cm3-5.4.0 binaries and started with > > > that. The > > > compiler in the binary distribution runs, but it > > > appears to produce > > > garbage. I first tried bootstrapping but it crashes > > > the moment it > > > tries to execute something it has compiled itself. > > > So then I tried > > > hello, world, with the same results... > > > > > > Here's the system identification: > > > > > > mika at edwards:~/test/src$ uname -a > > > Linux edwards 2.6.20-16-386 #2 Sun Sep 23 19:47:10 > > > UTC 2007 i686 GNU/Linux > > > > > > I made a "hello, world" program as follows: > > > > > > MODULE Main; > > > IMPORT IO; > > > > > > BEGIN IO.Put("Hello, world!\n") END Main. > > > > > > Compiled with cm3 directly from the distributed > > > cm3-5.4.0 for > > > LINUXLIBC6 and I get a crash in CsetjmpASM.s (as far > > > as I can tell). > > > The last unclobbered stack I seem to be able to get > > > in m3gdb is > > > this: > > > > > > Breakpoint 5, 0xb75e5fb4 in _setjmp () at > > > ../src/C/LINUXLIBC6/CsetjmpASM.s:31 > > > 31 in ../src/C/LINUXLIBC6/CsetjmpASM.s > > > (m3gdb) where > > > #0 0xb75e5fb4 in _setjmp () at > > > ../src/C/LINUXLIBC6/CsetjmpASM.s:31 > > > #1 0xb75dbd51 in RTThread__Transfer > > > (from=0xbfe28530, to=0xbfe28530) at > > > ../src/runtime/LINUXLIBC6/RTThreadC.c:14 > > > #2 0xb75dbaed in FlushStackCache () at > > > RTThread.m3:65 > > > #3 0xb75e27c9 in DetermineContext (oldSP=Invalid > > > C/C++ type code 35 in symbol table. > > > ) at ThreadPosix.m3:1101 > > > #4 0xb75e270d in InitTopContext (c=Invalid C/C++ > > > type code 30 in symbol table. > > > ) at ThreadPosix.m3:1076 > > > #5 0xb75e4325 in Init () at ThreadPosix.m3:1498 > > > #6 0xb75c9592 in InitRuntime (p_argc=Invalid C/C++ > > > type code 39 in symbol table. > > > ) at RTLinker.m3:59 > > > #7 0x08048861 in main (argc=1, argv=0xbfe28824, > > > envp=0xbfe2882c) at _m3main.mc:3 > > > (m3gdb) cont > > > Continuing. > > > > > > Program received signal SIGSEGV, Segmentation fault. > > > 0xa8dbaede in ?? () > > > > > > s.sp was lately 16_b75af6b9, if that means anything > > > at all. > > > > > > Oh yes, one more thing: setting LD_POINTER_GUARD to > > > 0 before running > > > the program has no effect on the crash. > > > > > > Any suggestions for how one might make progress on > > > this? > > > > > > Mika > > > > > > > > > > > > > ______________________________________________ > > ?Chef por primera vez? > > S? un mejor Cocinillas. > > http://es.answers.yahoo.com/info/welcome > > > Don't get caught with egg on your face. Play Chicktionary! Check it > out! From jay.krell at cornell.edu Sun Dec 16 06:33:20 2007 From: jay.krell at cornell.edu (Jay) Date: Sun, 16 Dec 2007 05:33:20 +0000 Subject: [M3devel] Ubuntu problems In-Reply-To: References: <200712160018.lBG0ITO5026048@camembert.async.caltech.edu> <147313.32986.qm@web27106.mail.ukl.yahoo.com> Message-ID: http://opengrok.netbsd.org/source/search?q=&defs=setjmphttp://opengrok.netbsd.org/source/search?q=&defs=longjmp oh -- hopefully the existing sizes are correct for this code, else an interface break, not that m3 seems to mind binary compatibility breaks and all or stick version numbers in places, though maybe there are runtime checks for binary compat, at least for higher levels. On Windows, setjmp/longjmp optionally interact "correctly" with exception handling -- running __finally blocks and C++ destructors. I wonder if the same is true for gcc? (At some I'd really like to switch NT386 to not use setjmp/longjmp or TlsGetValue/TlsSetValue for this stuff.. after 64bit integer support...) - Jay > From: hosking at cs.purdue.edu> Date: Sat, 15 Dec 2007 21:40:19 -0500> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com; mika at camembert.async.caltech.edu> Subject: Re: [M3devel] Ubuntu problems> > It may be slightly trickier than that, since appropriately sized > jmpbuf/ucontext needs to be declared.> > On Dec 15, 2007, at 9:14 PM, Jay wrote:> > > Maybe time to grab a BSD setjmp/longjmp or getcontext/setcontext, > > rename by prepending with m3_, and be done with it??> > e.g.> > http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/arch/i386/sys/ > > getcontext.S?rev=1.2&content-type=text/x-cvsweb-markup> > http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/arch/powerpc/sys/ > > getcontext.S?rev=1.3&content-type=text/x-cvsweb-markup> >> > My goodness, none of FreeBSD, OpenBSD, NetBSD have web searchable > > CVS archives..> > better links later..> >> > Regarding upgrade.sh, well, on Windows upgrade.cmd works. :)> > They are all "just" wrappers around cd'ing and building, but > > perhaps not trivial.> >> > - Jay> >> >> > > Date: Sun, 16 Dec 2007 02:38:03 +0100> > > From: dabenavidesd at yahoo.es> > > To: mika at async.caltech.edu; m3devel at elegosoft.com> > > CC: mika at camembert.async.caltech.edu> > > Subject: Re: [M3devel] Ubuntu problems> > >> > > Hi Mika,> > > what are you seeing is the problem of libc> > > setjmp/longjmp issue that we maybe have to advise more> > > to cm3 users, and in general *m3 (dec-src,pm3,ezm3,and> > > cm3 too) users that () user level thread> > > implementation which is part of m3core is not working> > > at this moment, so until community can make a> > > functioning a new implementation, we will use only> > > PTHREAD implementation on most new Linux> > > distributions.> > > Of course this solves the problems you are noticing,> > > so my advise in order to this do not happen any more> > > is write a note on the Download Area and maybe also in> > > (like a note in the Known issues), www.modula3.org> > > (If you allow me, I can do it)> > >> > > The most common case I know a (not very recent) of> > > distribution that works with user level implementation> > > that I use is Ubuntu Dapper 6.06, the libray is 2.3.6> > > http://packages.ubuntu.com/dapper/libdevel/libc6-dev> > > The next version of Ubuntu breaks when the Juno> > > package is compiling (pkl-fonts program executes), the> > > library libc6 is> > > http://packages.ubuntu.com/edgy/libdevel/libc6-dev.> > >> > > So for 5.4 sources use use the next CM3 variable> > > export CM3="/usr/local/cm3/bin/cm3 -DPTHREAD"> > >> > > This enable the system level thread implementation in> > > a earlier version of it (of cvs), but in the first> > > step bootstrap compiler you will ran in same problems> > > (in Edgy I got breack when running pkl-fonts, but> > > after that break you can re-compile it all well with> > > no problems, after you have build the new m3core).> > > If you can update the sources with the most recent (in> > > a personal opinion, stable version) would be better,> > > but here I would like to know if the script upgrade.sh> > > can do that work, i have not use it.> > > For me the most easy way for me was use the> > > instruction given by Tony for the cvs version, from I> > > take his words and make a relatively simple> > > instructions.> > >> > > Thanks> > >> > >> > >> > >> > >> > >> > > --- Mika Nystrom wrote:> > >> > > > Hello Modula-3 people,> > > >> > > > I am trying to build things with CM3 on a relatively> > > > recent Ubuntu> > > > system (don't ask me why...) and I am running into a> > > > segfault that> > > > I haven't seen mentioned before. I have a feeling> > > > it has something> > > > to do with stack formats, but I'm not sure what to> > > > do next.> > > >> > > > I downloaded the cm3-5.4.0 binaries and started with> > > > that. The> > > > compiler in the binary distribution runs, but it> > > > appears to produce> > > > garbage. I first tried bootstrapping but it crashes> > > > the moment it> > > > tries to execute something it has compiled itself.> > > > So then I tried> > > > hello, world, with the same results...> > > >> > > > Here's the system identification:> > > >> > > > mika at edwards:~/test/src$ uname -a> > > > Linux edwards 2.6.20-16-386 #2 Sun Sep 23 19:47:10> > > > UTC 2007 i686 GNU/Linux> > > >> > > > I made a "hello, world" program as follows:> > > >> > > > MODULE Main;> > > > IMPORT IO;> > > >> > > > BEGIN IO.Put("Hello, world!\n") END Main.> > > >> > > > Compiled with cm3 directly from the distributed> > > > cm3-5.4.0 for> > > > LINUXLIBC6 and I get a crash in CsetjmpASM.s (as far> > > > as I can tell).> > > > The last unclobbered stack I seem to be able to get> > > > in m3gdb is> > > > this:> > > >> > > > Breakpoint 5, 0xb75e5fb4 in _setjmp () at> > > > ../src/C/LINUXLIBC6/CsetjmpASM.s:31> > > > 31 in ../src/C/LINUXLIBC6/CsetjmpASM.s> > > > (m3gdb) where> > > > #0 0xb75e5fb4 in _setjmp () at> > > > ../src/C/LINUXLIBC6/CsetjmpASM.s:31> > > > #1 0xb75dbd51 in RTThread__Transfer> > > > (from=0xbfe28530, to=0xbfe28530) at> > > > ../src/runtime/LINUXLIBC6/RTThreadC.c:14> > > > #2 0xb75dbaed in FlushStackCache () at> > > > RTThread.m3:65> > > > #3 0xb75e27c9 in DetermineContext (oldSP=Invalid> > > > C/C++ type code 35 in symbol table.> > > > ) at ThreadPosix.m3:1101> > > > #4 0xb75e270d in InitTopContext (c=Invalid C/C++> > > > type code 30 in symbol table.> > > > ) at ThreadPosix.m3:1076> > > > #5 0xb75e4325 in Init () at ThreadPosix.m3:1498> > > > #6 0xb75c9592 in InitRuntime (p_argc=Invalid C/C++> > > > type code 39 in symbol table.> > > > ) at RTLinker.m3:59> > > > #7 0x08048861 in main (argc=1, argv=0xbfe28824,> > > > envp=0xbfe2882c) at _m3main.mc:3> > > > (m3gdb) cont> > > > Continuing.> > > >> > > > Program received signal SIGSEGV, Segmentation fault.> > > > 0xa8dbaede in ?? ()> > > >> > > > s.sp was lately 16_b75af6b9, if that means anything> > > > at all.> > > >> > > > Oh yes, one more thing: setting LD_POINTER_GUARD to> > > > 0 before running> > > > the program has no effect on the crash.> > > >> > > > Any suggestions for how one might make progress on> > > > this?> > > >> > > > Mika> > > >> > >> > >> > >> > >> > > ______________________________________________> > > ?Chef por primera vez?> > > S? un mejor Cocinillas.> > > http://es.answers.yahoo.com/info/welcome> >> >> > Don't get caught with egg on your face. Play Chicktionary! Check it > > out!> _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sun Dec 16 07:56:33 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 15 Dec 2007 22:56:33 -0800 Subject: [M3devel] Ubuntu problems In-Reply-To: Your message of "Sat, 15 Dec 2007 17:35:54 PST." <200712160135.lBG1ZsZ2028488@camembert.async.caltech.edu> Message-ID: <200712160656.lBG6uXRg038351@camembert.async.caltech.edu> All right, thanks for your suggestions. I seem to have made a working compiler. Even mentor works on this Ubuntu 2.6.20. My main observation is that M3/Linux is crying out for a new bootstrap compiler binary. Neither the one from Tony's site nor the 5.4.0 cm3 is actually able to compile the CVS head. The problems come from Long.m3 (instance of GenWord.mg) and Int64.i3. I was able to work around these issues by putting in some garbage in these files and bootstrapping twice---the second time with the proper code in Long.m3 and Int64.i3. It's not that the bootstrapping compiler doesn't know about long (at least one of them does), it just crashes. But no harm done, it all seems to work after fiddling with it. Another issue---and I feel stupid for asking, it seems so basic---is that Linux is really stingy with static archives (.a files), and my cm3.cfg was asking for -lXaw, which didn't work, even though there was a libXaw.so.6 present. I changed the cfg to link explicitly with /usr/lib/libXaw.so.6, but that can't be the right way to do it?? Oh the 5.4.0 cm3.cfg also wraps the "utimes" call. I took this out, as no one was supplying wrap_utimes. I take it this is safe... (a GC-related modification?) Mika Mika Nystrom writes: >Sorry, I have now read the mailing list archives a bit better. > >I am going to try bootstrapping the latest CVS with Tony's cm3 binary, >to use pthreads... > > Mika > > >Mika Nystrom writes: >>Hello Modula-3 people, >> >>I am trying to build things with CM3 on a relatively recent Ubuntu >>system (don't ask me why...) and I am running into a segfault that >>I haven't seen mentioned before. I have a feeling it has something >>to do with stack formats, but I'm not sure what to do next. >> >>I downloaded the cm3-5.4.0 binaries and started with that. The >>compiler in the binary distribution runs, but it appears to produce >>garbage. I first tried bootstrapping but it crashes the moment it >>tries to execute something it has compiled itself. So then I tried >>hello, world, with the same results... >> >>Here's the system identification: >> >>mika at edwards:~/test/src$ uname -a >>Linux edwards 2.6.20-16-386 #2 Sun Sep 23 19:47:10 UTC 2007 i686 GNU/Linux >> >>I made a "hello, world" program as follows: >> >>MODULE Main; >>IMPORT IO; >> >>BEGIN IO.Put("Hello, world!\n") END Main. >> >>Compiled with cm3 directly from the distributed cm3-5.4.0 for >>LINUXLIBC6 and I get a crash in CsetjmpASM.s (as far as I can tell). >>The last unclobbered stack I seem to be able to get in m3gdb is >>this: >> >>Breakpoint 5, 0xb75e5fb4 in _setjmp () at ../src/C/LINUXLIBC6/CsetjmpASM.s:31 >>31 in ../src/C/LINUXLIBC6/CsetjmpASM.s >>(m3gdb) where >>#0 0xb75e5fb4 in _setjmp () at ../src/C/LINUXLIBC6/CsetjmpASM.s:31 >>#1 0xb75dbd51 in RTThread__Transfer (from=0xbfe28530, to=0xbfe28530) at ../s >r >>c/runtime/LINUXLIBC6/RTThreadC.c:14 >>#2 0xb75dbaed in FlushStackCache () at RTThread.m3:65 >>#3 0xb75e27c9 in DetermineContext (oldSP=Invalid C/C++ type code 35 in symbo >l >> table. >>) at ThreadPosix.m3:1101 >>#4 0xb75e270d in InitTopContext (c=Invalid C/C++ type code 30 in symbol tabl >e >>. >>) at ThreadPosix.m3:1076 >>#5 0xb75e4325 in Init () at ThreadPosix.m3:1498 >>#6 0xb75c9592 in InitRuntime (p_argc=Invalid C/C++ type code 39 in symbol ta >b >>le. >>) at RTLinker.m3:59 >>#7 0x08048861 in main (argc=1, argv=0xbfe28824, envp=0xbfe2882c) at _m3main. >m >>c:3 >>(m3gdb) cont >>Continuing. >> >>Program received signal SIGSEGV, Segmentation fault. >>0xa8dbaede in ?? () >> >>s.sp was lately 16_b75af6b9, if that means anything at all. >> >>Oh yes, one more thing: setting LD_POINTER_GUARD to 0 before running >>the program has no effect on the crash. >> >>Any suggestions for how one might make progress on this? >> >> Mika From wagner at elegosoft.com Sun Dec 16 17:31:03 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 16 Dec 2007 17:31:03 +0100 Subject: [M3devel] Spanish speaking CM3 users? In-Reply-To: <47646653.4070106@purdue.edu> References: <20071215235051.rhq0fgeabk4k48gk@mail.elegosoft.com> <47646653.4070106@purdue.edu> Message-ID: <20071216173103.3864tbyzs4so4s8c@mail.elegosoft.com> Quoting "Neil T. Dantam" : > Olaf, > I can at least translate the Spanish for you. Thanks for the translation. > Angela, > ?Tratar los instrucciones de este mensaje? (Did you try the instructions > in this email?) > > https://mail.elegosoft.com/pipermail/m3devel/2007-June/000227.html > > Describen como compilar el compilador. (They describe how to bootstrap > the compiler.) Angela, I have subscribed you to this list and hope that you undestand this. The failure you see is probably due to fundamental changes in the compiler since the last release (addition of 64 bit integers and changes in the garbage collector and threads runtime) which makes a more complex upgrade necessary. Current boot/installation archives for all platforms are overdue; I'm currently trying to build the one for FreeBSD on my home computer. I think we could get something more up-to-date and easier to install for Linux, Solaris, and Darwin within the next week(s). Please stay tuned, Olaf PS: If you send bug reports to the list, you should always add the exact system and environment you are using (uname -a, which archives did you use, what were the exact commands you issed that led to the failure). > Olaf Wagner wrote: >> ----- Forwarded message from anietog at unal.edu.co ----- >> Date: Sat, 15 Dec 2007 17:55:45 +0100 (CET) >> From: Angela >> Reply-To: Angela >> Subject: Anfrage Mailformular >> To: info at elego.de >> >> NAME: Angela >> EMAIL: anietog at unal.edu.co >> ADDRESS: >> Hola, escribo porque tengo un problema al tratar de compilar el >> compilador de fase 1, esto es lo que me aparece: > > Hello, I'm writing because I have a problem regarding compiling phase > one of the compiler. This is what I see: > >> .... >> new source -> compiling Text.i3 >> new source -> compiling RTProcedureSRC.i3 >> new source -> compiling Fingerprint.i3 >> new source -> compiling RTProcedure.i3 >> new source -> compiling RTStack.i3 >> new source -> compiling RTAllocStats.m3 >> "../src/runtime/common/RTAllocStats.m3", line 46: undefined runtime >> symbol !! (RTHooks.AllocateTracedRef) >> >> >> *** >> *** runtime error: >> *** Segmentation violation - possible attempt to dereference NIL >> *** pc = 0x80c5c3c = StartCall + 0x18 in ../src/values/Procedure.m3 >> *** >> >> Aborted (core dumped) >> *** execution of failed *** >> >> >> Agradezco cualquier colaboraci?n ya que aun no he podido culminar mi >> instalacion de cm3. > > I would appreciate any help, because I could not finish my > installation of cm3. > >> >> ----- End forwarded message ----- > > > -- > Neil T. Dantam > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sun Dec 16 17:35:40 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 16 Dec 2007 11:35:40 -0500 Subject: [M3devel] Ubuntu problems In-Reply-To: References: <200712160018.lBG0ITO5026048@camembert.async.caltech.edu> <147313.32986.qm@web27106.mail.ukl.yahoo.com> Message-ID: <324F7DBA-ECF9-4382-A1F1-FA5D4B380247@cs.purdue.edu> There are two places where setjmp/longjmp are used: user-level threading and exception handling. On Windows, they are only used for exception handling since we rely on system threads. On Solaris and Alpha/OSF they are not used for exception handling since those targets have stack unwinding support. Converting user-level threading to use setcontext/getcontext should be relatively straightforward, based on the model already implemented for Solaris which I converted to setcontext/getcontext many years ago. On Dec 16, 2007, at 12:33 AM, Jay wrote: > http://opengrok.netbsd.org/source/search?q=&defs=setjmp > http://opengrok.netbsd.org/source/search?q=&defs=longjmp > > oh -- hopefully the existing sizes are correct for this code, else > an interface break, not that m3 seems to mind binary compatibility > breaks and all or stick version numbers in places, though maybe > there are runtime checks for binary compat, at least for higher > levels. > > On Windows, setjmp/longjmp optionally interact "correctly" with > exception handling -- running __finally blocks and C++ destructors. > I wonder if the same is true for gcc? > (At some I'd really like to switch NT386 to not use setjmp/longjmp > or TlsGetValue/TlsSetValue for this stuff.. after 64bit integer > support...) > > - Jay > > > > From: hosking at cs.purdue.edu > > Date: Sat, 15 Dec 2007 21:40:19 -0500 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com; mika at camembert.async.caltech.edu > > Subject: Re: [M3devel] Ubuntu problems > > > > It may be slightly trickier than that, since appropriately sized > > jmpbuf/ucontext needs to be declared. > > > > On Dec 15, 2007, at 9:14 PM, Jay wrote: > > > > > Maybe time to grab a BSD setjmp/longjmp or getcontext/setcontext, > > > rename by prepending with m3_, and be done with it?? > > > e.g. > > > http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/arch/i386/sys/ > > > getcontext.S?rev=1.2&content-type=text/x-cvsweb-markup > > > http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/arch/powerpc/sys/ > > > getcontext.S?rev=1.3&content-type=text/x-cvsweb-markup > > > > > > My goodness, none of FreeBSD, OpenBSD, NetBSD have web searchable > > > CVS archives.. > > > better links later.. > > > > > > Regarding upgrade.sh, well, on Windows upgrade.cmd works. :) > > > They are all "just" wrappers around cd'ing and building, but > > > perhaps not trivial. > > > > > > - Jay > > > > > > > > > > Date: Sun, 16 Dec 2007 02:38:03 +0100 > > > > From: dabenavidesd at yahoo.es > > > > To: mika at async.caltech.edu; m3devel at elegosoft.com > > > > CC: mika at camembert.async.caltech.edu > > > > Subject: Re: [M3devel] Ubuntu problems > > > > > > > > Hi Mika, > > > > what are you seeing is the problem of libc > > > > setjmp/longjmp issue that we maybe have to advise more > > > > to cm3 users, and in general *m3 (dec-src,pm3,ezm3,and > > > > cm3 too) users that () user level thread > > > > implementation which is part of m3core is not working > > > > at this moment, so until community can make a > > > > functioning a new implementation, we will use only > > > > PTHREAD implementation on most new Linux > > > > distributions. > > > > Of course this solves the problems you are noticing, > > > > so my advise in order to this do not happen any more > > > > is write a note on the Download Area and maybe also in > > > > (like a note in the Known issues), www.modula3.org > > > > (If you allow me, I can do it) > > > > > > > > The most common case I know a (not very recent) of > > > > distribution that works with user level implementation > > > > that I use is Ubuntu Dapper 6.06, the libray is 2.3.6 > > > > http://packages.ubuntu.com/dapper/libdevel/libc6-dev > > > > The next version of Ubuntu breaks when the Juno > > > > package is compiling (pkl-fonts program executes), the > > > > library libc6 is > > > > http://packages.ubuntu.com/edgy/libdevel/libc6-dev. > > > > > > > > So for 5.4 sources use use the next CM3 variable > > > > export CM3="/usr/local/cm3/bin/cm3 -DPTHREAD" > > > > > > > > This enable the system level thread implementation in > > > > a earlier version of it (of cvs), but in the first > > > > step bootstrap compiler you will ran in same problems > > > > (in Edgy I got breack when running pkl-fonts, but > > > > after that break you can re-compile it all well with > > > > no problems, after you have build the new m3core). > > > > If you can update the sources with the most recent (in > > > > a personal opinion, stable version) would be better, > > > > but here I would like to know if the script upgrade.sh > > > > can do that work, i have not use it. > > > > For me the most easy way for me was use the > > > > instruction given by Tony for the cvs version, from I > > > > take his words and make a relatively simple > > > > instructions. > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > > --- Mika Nystrom wrote: > > > > > > > > > Hello Modula-3 people, > > > > > > > > > > I am trying to build things with CM3 on a relatively > > > > > recent Ubuntu > > > > > system (don't ask me why...) and I am running into a > > > > > segfault that > > > > > I haven't seen mentioned before. I have a feeling > > > > > it has something > > > > > to do with stack formats, but I'm not sure what to > > > > > do next. > > > > > > > > > > I downloaded the cm3-5.4.0 binaries and started with > > > > > that. The > > > > > compiler in the binary distribution runs, but it > > > > > appears to produce > > > > > garbage. I first tried bootstrapping but it crashes > > > > > the moment it > > > > > tries to execute something it has compiled itself. > > > > > So then I tried > > > > > hello, world, with the same results... > > > > > > > > > > Here's the system identification: > > > > > > > > > > mika at edwards:~/test/src$ uname -a > > > > > Linux edwards 2.6.20-16-386 #2 Sun Sep 23 19:47:10 > > > > > UTC 2007 i686 GNU/Linux > > > > > > > > > > I made a "hello, world" program as follows: > > > > > > > > > > MODULE Main; > > > > > IMPORT IO; > > > > > > > > > > BEGIN IO.Put("Hello, world!\n") END Main. > > > > > > > > > > Compiled with cm3 directly from the distributed > > > > > cm3-5.4.0 for > > > > > LINUXLIBC6 and I get a crash in CsetjmpASM.s (as far > > > > > as I can tell). > > > > > The last unclobbered stack I seem to be able to get > > > > > in m3gdb is > > > > > this: > > > > > > > > > > Breakpoint 5, 0xb75e5fb4 in _setjmp () at > > > > > ../src/C/LINUXLIBC6/CsetjmpASM.s:31 > > > > > 31 in ../src/C/LINUXLIBC6/CsetjmpASM.s > > > > > (m3gdb) where > > > > > #0 0xb75e5fb4 in _setjmp () at > > > > > ../src/C/LINUXLIBC6/CsetjmpASM.s:31 > > > > > #1 0xb75dbd51 in RTThread__Transfer > > > > > (from=0xbfe28530, to=0xbfe28530) at > > > > > ../src/runtime/LINUXLIBC6/RTThreadC.c:14 > > > > > #2 0xb75dbaed in FlushStackCache () at > > > > > RTThread.m3:65 > > > > > #3 0xb75e27c9 in DetermineContext (oldSP=Invalid > > > > > C/C++ type code 35 in symbol table. > > > > > ) at ThreadPosix.m3:1101 > > > > > #4 0xb75e270d in InitTopContext (c=Invalid C/C++ > > > > > type code 30 in symbol table. > > > > > ) at ThreadPosix.m3:1076 > > > > > #5 0xb75e4325 in Init () at ThreadPosix.m3:1498 > > > > > #6 0xb75c9592 in InitRuntime (p_argc=Invalid C/C++ > > > > > type code 39 in symbol table. > > > > > ) at RTLinker.m3:59 > > > > > #7 0x08048861 in main (argc=1, argv=0xbfe28824, > > > > > envp=0xbfe2882c) at _m3main.mc:3 > > > > > (m3gdb) cont > > > > > Continuing. > > > > > > > > > > Program received signal SIGSEGV, Segmentation fault. > > > > > 0xa8dbaede in ?? () > > > > > > > > > > s.sp was lately 16_b75af6b9, if that means anything > > > > > at all. > > > > > > > > > > Oh yes, one more thing: setting LD_POINTER_GUARD to > > > > > 0 before running > > > > > the program has no effect on the crash. > > > > > > > > > > Any suggestions for how one might make progress on > > > > > this? > > > > > > > > > > Mika > > > > > > > > > > > > > > > > > > > > > > > > > ______________________________________________ > > > > ?Chef por primera vez? > > > > S? un mejor Cocinillas. > > > > http://es.answers.yahoo.com/info/welcome > > > > > > > > > Don't get caught with egg on your face. Play Chicktionary! > Check it > > > out! > > > > > Share life as it happens with the new Windows Live. Share now! From hosking at cs.purdue.edu Sun Dec 16 17:37:35 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 16 Dec 2007 11:37:35 -0500 Subject: [M3devel] Ubuntu problems In-Reply-To: <200712160656.lBG6uXRg038351@camembert.async.caltech.edu> References: <200712160656.lBG6uXRg038351@camembert.async.caltech.edu> Message-ID: On Dec 16, 2007, at 1:56 AM, Mika Nystrom wrote: > > All right, thanks for your suggestions. I seem to have made a > working compiler. Even mentor works on this Ubuntu 2.6.20. > > My main observation is that M3/Linux is crying out for a new bootstrap > compiler binary. Neither the one from Tony's site nor the 5.4.0 > cm3 is actually able to compile the CVS head. The problems come > from Long.m3 (instance of GenWord.mg) and Int64.i3. I was able to > work around these issues by putting in some garbage in these files > and bootstrapping twice---the second time with the proper code in > Long.m3 and Int64.i3. It's not that the bootstrapping compiler > doesn't > know about long (at least one of them does), it just crashes. But > no harm done, it all seems to work after fiddling with it. I need to update my ftp site with a version of the Linux bootstrap compiler that will work for the LONGINT support. > Another issue---and I feel stupid for asking, it seems so basic---is > that Linux is really stingy with static archives (.a files), and > my cm3.cfg was asking for -lXaw, which didn't work, even though > there was a libXaw.so.6 present. I changed the cfg to link explicitly > with /usr/lib/libXaw.so.6, but that can't be the right way to do it?? > Oh the 5.4.0 cm3.cfg also wraps the "utimes" call. I took this out, > as no one was supplying wrap_utimes. I take it this is safe... (a > GC-related modification?) You are working off of a very old cm3.cfg -- try the one from my ftp site. > > Mika > > Mika Nystrom writes: >> Sorry, I have now read the mailing list archives a bit better. >> >> I am going to try bootstrapping the latest CVS with Tony's cm3 >> binary, >> to use pthreads... >> >> Mika >> >> >> Mika Nystrom writes: >>> Hello Modula-3 people, >>> >>> I am trying to build things with CM3 on a relatively recent Ubuntu >>> system (don't ask me why...) and I am running into a segfault that >>> I haven't seen mentioned before. I have a feeling it has something >>> to do with stack formats, but I'm not sure what to do next. >>> >>> I downloaded the cm3-5.4.0 binaries and started with that. The >>> compiler in the binary distribution runs, but it appears to produce >>> garbage. I first tried bootstrapping but it crashes the moment it >>> tries to execute something it has compiled itself. So then I tried >>> hello, world, with the same results... >>> >>> Here's the system identification: >>> >>> mika at edwards:~/test/src$ uname -a >>> Linux edwards 2.6.20-16-386 #2 Sun Sep 23 19:47:10 UTC 2007 i686 >>> GNU/Linux >>> >>> I made a "hello, world" program as follows: >>> >>> MODULE Main; >>> IMPORT IO; >>> >>> BEGIN IO.Put("Hello, world!\n") END Main. >>> >>> Compiled with cm3 directly from the distributed cm3-5.4.0 for >>> LINUXLIBC6 and I get a crash in CsetjmpASM.s (as far as I can tell). >>> The last unclobbered stack I seem to be able to get in m3gdb is >>> this: >>> >>> Breakpoint 5, 0xb75e5fb4 in _setjmp () at ../src/C/LINUXLIBC6/ >>> CsetjmpASM.s:31 >>> 31 in ../src/C/LINUXLIBC6/CsetjmpASM.s >>> (m3gdb) where >>> #0 0xb75e5fb4 in _setjmp () at ../src/C/LINUXLIBC6/CsetjmpASM.s:31 >>> #1 0xb75dbd51 in RTThread__Transfer (from=0xbfe28530, >>> to=0xbfe28530) at ../s >> r >>> c/runtime/LINUXLIBC6/RTThreadC.c:14 >>> #2 0xb75dbaed in FlushStackCache () at RTThread.m3:65 >>> #3 0xb75e27c9 in DetermineContext (oldSP=Invalid C/C++ type code >>> 35 in symbo >> l >>> table. >>> ) at ThreadPosix.m3:1101 >>> #4 0xb75e270d in InitTopContext (c=Invalid C/C++ type code 30 in >>> symbol tabl >> e >>> . >>> ) at ThreadPosix.m3:1076 >>> #5 0xb75e4325 in Init () at ThreadPosix.m3:1498 >>> #6 0xb75c9592 in InitRuntime (p_argc=Invalid C/C++ type code 39 >>> in symbol ta >> b >>> le. >>> ) at RTLinker.m3:59 >>> #7 0x08048861 in main (argc=1, argv=0xbfe28824, envp=0xbfe2882c) >>> at _m3main. >> m >>> c:3 >>> (m3gdb) cont >>> Continuing. >>> >>> Program received signal SIGSEGV, Segmentation fault. >>> 0xa8dbaede in ?? () >>> >>> s.sp was lately 16_b75af6b9, if that means anything at all. >>> >>> Oh yes, one more thing: setting LD_POINTER_GUARD to 0 before running >>> the program has no effect on the crash. >>> >>> Any suggestions for how one might make progress on this? >>> >>> Mika From wagner at elegosoft.com Sun Dec 16 18:10:59 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 16 Dec 2007 18:10:59 +0100 Subject: [M3devel] Info about Jay Krell? Fwd: Uncaught bounce notification Message-ID: <20071216181059.8vpo9jtzijo8k0g8@mail.elegosoft.com> Hi, I wouldn't normally forward this to the list, but since Jay has been such an eager contributor to cm3 on windows: does anybody know why all his mail bounces and how he can be reached? Thanks, Olaf Date: Sun, 16 Dec 2007 11:31:15 -0500 (EST) Subject: Problems delivering your mail From: MAILER-DAEMON at cornell.edu To: m3devel-bounces at elegosoft.com 2.1 unnamed [text/plain] 5.58 KB Download I'm sorry, but we had problems delivering your mail. The errors we encountered appear below. If you have any questions, contact the Cornell Postmaster as . Please include a copy of this message with your correspondence. -------- The following addresses could not be found at all in our Directory. Please make sure you have the correct address. jay.krell at cornell.edu -------- -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Dec 16 22:23:01 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 16 Dec 2007 22:23:01 +0100 Subject: [M3devel] m3cg build failure on powerpc/darwin Message-ID: <20071216212301.GA25212@elegosoft.com> Hi, while trying to build some boot archives build on my PowerBook G4, uname -a Darwin apple.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power Macintosh powerpc the compilation died with /Users/wagner/work/cm3/m3-sys/m3cc/PPC_DARWIN/./gcc/xgcc -B/Users/wagner/work/cm3/m3-sys/m3cc/PPC_DARWIN/./gcc/ -B/usr/local/powerpc-apple-darwin7.9.0/bin/ -B/usr/local/powerpc-apple-darwin7.9.0/lib/ -isystem /usr/local/powerpc-apple-darwin7.9.0/include -isystem /usr/local/powerpc-apple-darwin7.9.0/sys-include -c -DHAVE_CONFIG_H -O2 -O2 -g -I. -I../../../gcc/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../../gcc/libiberty/floatformat.c -o floatformat.o ../../../gcc/libiberty/floatformat.c: In function 'floatformat_to_double': ../../../gcc/libiberty/floatformat.c:354: warning: floating constant exceeds range of 'float' /var/tmp/cccvQbrs.s:508:stfiwx instruction is optional for the PowerPC (not allowed without -force_cpusubtype_ALL option) /var/tmp/cccvQbrs.s:550:stfiwx instruction is optional for the PowerPC (not allowed without -force_cpusubtype_ALL option) make[2]: *** [floatformat.o] Error 1 make[1]: *** [all-target-libiberty] Error 2 make: *** [all] Error 2 "/Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile", line 188: quake runtime error: exit 512: cd .; make CC="gcc" CFLAGS="-O2 -g" --procedure-- -line- -file--- exec -- include_dir 188 /Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile 5 /Users/wagner/work/cm3/m3-sys/m3cc/PPC_DARWIN/m3make.args Fatal Error: package build failed Any ideas? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sun Dec 16 23:02:58 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 16 Dec 2007 23:02:58 +0100 Subject: [M3devel] m3cg build failure on powerpc/darwin In-Reply-To: <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> Message-ID: <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> Quoting Tony Hosking : > That is a very old Darwin distro. Here is my G4: > > Darwin Kernel Version 8.10.0: Wed May 23 16:50:59 PDT 2007; > root:xnu-792.21.3~1/RELEASE_PPC Seems I'm stuck then. Newer versions of the OS won't run on this PowerBook according to specification. So current versions of CM3 aren't possible anymore, too... It seems that it isn't possible anymore to use a computer that is older than two years to run any medium to large-size current software :-( The upgrade script for Linux just died with === package m3-sys/cm3 === +++ cm3 -build -DROOT='/home/wagner/work/cm3' && cm3 -ship -DROOT='/home/wagner/work/cm3' +++ --- building in LINUXLIBC6 --- ignoring ../src/m3overrides -> linking cm3 /usr/local/cm3/pkg/libm3/LINUXLIBC6/libm3.a(FSPosix.mo): In function `FS__SetModificationTime': /home/wagner/work/cm3/m3-libs/libm3/LINUXLIBC6/FSPosix.m3:348: undefined reference to `__wrap_utimes' collect2: ld returned 1 exit status Fatal Error: package build failed on birch.elegosoft.com. So the only thing I've succeeded in today is building a bootstrap for FreeBSD 6.3. Olaf > On Dec 16, 2007, at 4:23 PM, Olaf Wagner wrote: > >> Hi, >> >> while trying to build some boot archives build on my PowerBook >> G4, uname -a >> >> Darwin apple.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 >> 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power >> Macintosh powerpc >> >> the compilation died with >> >> /Users/wagner/work/cm3/m3-sys/m3cc/PPC_DARWIN/./gcc/xgcc >> -B/Users/wagner/work/cm3/m3-sys/m3cc/PPC_DARWIN/./gcc/ >> -B/usr/local/powerpc-apple-darwin7.9.0/bin/ >> -B/usr/local/powerpc-apple-darwin7.9.0/lib/ -isystem >> /usr/local/powerpc-apple-darwin7.9.0/include -isystem >> /usr/local/powerpc-apple-darwin7.9.0/sys-include -c -DHAVE_CONFIG_H >> -O2 -O2 -g -I. -I../../../gcc/libiberty/../include -W -Wall >> -pedantic -Wwrite-strings -Wstrict-prototypes >> ../../../gcc/libiberty/floatformat.c -o floatformat.o >> ../../../gcc/libiberty/floatformat.c: In function 'floatformat_to_double': >> ../../../gcc/libiberty/floatformat.c:354: warning: floating >> constant exceeds range of 'float' >> /var/tmp/cccvQbrs.s:508:stfiwx instruction is optional for the >> PowerPC (not allowed without -force_cpusubtype_ALL option) >> /var/tmp/cccvQbrs.s:550:stfiwx instruction is optional for the >> PowerPC (not allowed without -force_cpusubtype_ALL option) >> make[2]: *** [floatformat.o] Error 1 >> make[1]: *** [all-target-libiberty] Error 2 >> make: *** [all] Error 2 >> "/Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile", line 188: >> quake runtime error: exit 512: cd .; make CC="gcc" CFLAGS="-O2 -g" >> >> --procedure-- -line- -file--- >> exec -- >> include_dir 188 /Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile >> 5 >> /Users/wagner/work/cm3/m3-sys/m3cc/PPC_DARWIN/m3make.args >> >> Fatal Error: package build failed >> >> 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 mika at async.caltech.edu Sun Dec 16 23:14:35 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 16 Dec 2007 14:14:35 -0800 Subject: [M3devel] m3cg build failure on powerpc/darwin In-Reply-To: Your message of "Sun, 16 Dec 2007 23:02:58 +0100." <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> Message-ID: <200712162214.lBGMEagW066782@camembert.async.caltech.edu> Olaf Wagner writes: ... >The upgrade script for Linux just died with > >=== package m3-sys/cm3 === > +++ cm3 -build -DROOT='/home/wagner/work/cm3' && cm3 -ship >-DROOT='/home/wagner/work/cm3' +++ >--- building in LINUXLIBC6 --- > >ignoring ../src/m3overrides > > -> linking cm3 >/usr/local/cm3/pkg/libm3/LINUXLIBC6/libm3.a(FSPosix.mo): In function >`FS__SetModificationTime': >/home/wagner/work/cm3/m3-libs/libm3/LINUXLIBC6/FSPosix.m3:348: >undefined reference to `__wrap_utimes' >collect2: ld returned 1 exit status >Fatal Error: package build failed > >on birch.elegosoft.com. This is the same problem I had on Ubuntu yesterday. You need to remove -wrap,utimes from your cm3.cfg, or use Tony's newer cm3.cfg. > >So the only thing I've succeeded in today is building a bootstrap >for FreeBSD 6.3. Ironically, FreeBSD is extremely good at backward-compatibility of binaries! I think I may still have a FreeBSD 3.x system somewhere with Modula-3 on it... This is just for historical reasons, but we still do use 4.11 systems in production, so it would be nice if there were bootstraps on 4.11. (4.11-generated compilers work fine w/o modification on 5.x.) Mika > >Olaf > >> On Dec 16, 2007, at 4:23 PM, Olaf Wagner wrote: >> >>> Hi, >>> >>> while trying to build some boot archives build on my PowerBook >>> G4, uname -a >>> >>> Darwin apple.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 >>> 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power >>> Macintosh powerpc >>> >>> the compilation died with >>> >>> /Users/wagner/work/cm3/m3-sys/m3cc/PPC_DARWIN/./gcc/xgcc >>> -B/Users/wagner/work/cm3/m3-sys/m3cc/PPC_DARWIN/./gcc/ >>> -B/usr/local/powerpc-apple-darwin7.9.0/bin/ >>> -B/usr/local/powerpc-apple-darwin7.9.0/lib/ -isystem >>> /usr/local/powerpc-apple-darwin7.9.0/include -isystem >>> /usr/local/powerpc-apple-darwin7.9.0/sys-include -c -DHAVE_CONFIG_H >>> -O2 -O2 -g -I. -I../../../gcc/libiberty/../include -W -Wall >>> -pedantic -Wwrite-strings -Wstrict-prototypes >>> ../../../gcc/libiberty/floatformat.c -o floatformat.o >>> ../../../gcc/libiberty/floatformat.c: In function 'floatformat_to_double': >>> ../../../gcc/libiberty/floatformat.c:354: warning: floating >>> constant exceeds range of 'float' >>> /var/tmp/cccvQbrs.s:508:stfiwx instruction is optional for the >>> PowerPC (not allowed without -force_cpusubtype_ALL option) >>> /var/tmp/cccvQbrs.s:550:stfiwx instruction is optional for the >>> PowerPC (not allowed without -force_cpusubtype_ALL option) >>> make[2]: *** [floatformat.o] Error 1 >>> make[1]: *** [all-target-libiberty] Error 2 >>> make: *** [all] Error 2 >>> "/Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile", line 188: >>> quake runtime error: exit 512: cd .; make CC="gcc" CFLAGS="-O2 -g" >>> >>> --procedure-- -line- -file--- >>> exec -- >>> include_dir 188 /Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile >>> 5 >>> /Users/wagner/work/cm3/m3-sys/m3cc/PPC_DARWIN/m3make.args >>> >>> Fatal Error: package build failed >>> >>> 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 mika at async.caltech.edu Sun Dec 16 23:25:43 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 16 Dec 2007 14:25:43 -0800 Subject: [M3devel] m3cg build failure on powerpc/darwin In-Reply-To: Your message of "Sun, 16 Dec 2007 14:14:35 PST." <200712162214.lBGMEagW066782@camembert.async.caltech.edu> Message-ID: <200712162225.lBGMPhm5067188@camembert.async.caltech.edu> Mika Nystrom writes: ... >we still do use 4.11 systems in production, so it would be nice if >there were bootstraps on 4.11. (4.11-generated compilers work fine >w/o modification on 5.x.) I should add, in case it's not clearly understood from the above, that I'd be more than happy to help generating such a bootstrap if it's going to be a release version! From wagner at elegosoft.com Sun Dec 16 23:32:59 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 16 Dec 2007 23:32:59 +0100 Subject: [M3devel] m3cg build failure on powerpc/darwin In-Reply-To: <28256359-D312-4D47-9A38-7A245D6AEAE5@cs.purdue.edu> References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> <28256359-D312-4D47-9A38-7A245D6AEAE5@cs.purdue.edu> Message-ID: <20071216233259.ukim9ntk6cw8gsgc@mail.elegosoft.com> Quoting Tony Hosking : >> Seems I'm stuck then. Newer versions of the OS won't run on this >> PowerBook according to specification. So current versions of CM3 >> aren't possible anymore, too... >> >> It seems that it isn't possible anymore to use a computer that is >> older than two years to run any medium to large-size current >> software :-( > > I can build a bootstrap for PPC_DARWIN if you like. That would be great (and may be the fastest solution). >> The upgrade script for Linux just died with [...] > Looks like you have an old cm3.cfg with the wrapper link commands in > it. Delete those and you should be good. Found that, removed it and redid everything from start after several spurious errors (Mika mentioned it, too). Now I get this: ... /home/wagner/work/cm3/scripts/install-cm3-compiler.sh upgrade cp_if: /usr/local/cm3/bin/cm3 and /usr/local/cm3/bin/cm3-d5.5.0 identical cp_if: /usr/local/cm3/bin/cm3cg and /usr/local/cm3/bin/cm3cg-d5.5.0 identical /home/wagner/work/cm3/scripts/install-cm3-compiler.sh: line 109: /home/wagner/work/cm3/m3-sys/cm3/LINUXLIBC6/cm3: No such file or directory cp /home/wagner/work/cm3/m3-sys/cm3/LINUXLIBC6/cm3 /usr/local/cm3/bin/cm3- cp_if: /home/wagner/work/cm3/m3-sys/m3cc/LINUXLIBC6/cm3cg and /usr/local/cm3/bin/cm3cg- identical cp /usr/local/cm3/bin/cm3- /usr/local/cm3/bin/cm3 cp /usr/local/cm3/bin/cm3cg- /usr/local/cm3/bin/cm3cg /home/wagner/work/cm3/scripts/do-cm3-core.sh buildship CM3C = /home/wagner/work/cm3/scripts/pkgmap.sh -c "cm3 -build -DROOT='/home/wagner/work/cm3' && cm3 -ship -DROOT='/home/wagner/work/cm3' " m3core libm3 patternmatching m3middle m3linker m3front m3quake m3cc cm3 m3scanner m3tools m3cgcat m3cggen m3bundle bitvector digraph parseparams realgeometry set slisp sortedtableextras table-list tempfiles === package m3-libs/m3core === +++ cm3 -build -DROOT='/home/wagner/work/cm3' && cm3 -ship -DROOT='/home/wagner/work/cm3' +++ /bin/sh: /usr/local/cm3/bin/cm3: No such file or directory *** execution of failed *** birch [~/work/cm3] wagner % ls -l /home/wagner/work/cm3/m3-sys/cm3/LINUXLIBC6/cm3 -rwxr-xr-x 1 wagner 5906103 2007-12-16 23:26 /home/wagner/work/cm3/m3-sys/cm3/LINUXLIBC6/cm3* % ldd /home/wagner/work/cm3/m3-sys/cm3/LINUXLIBC6/cm3 /usr/bin/ldd: line 117: /home/wagner/work/cm3/m3-sys/cm3/LINUXLIBC6/cm3: No such file or directory ??? Looks like I need a break 8-/ Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Mon Dec 17 06:24:19 2007 From: jayk123 at hotmail.com (Jay) Date: Mon, 17 Dec 2007 05:24:19 +0000 Subject: [M3devel] Info about Jay Krell? Fwd: Uncaught bounce notification In-Reply-To: <20071216181059.8vpo9jtzijo8k0g8@mail.elegosoft.com> References: <20071216181059.8vpo9jtzijo8k0g8@mail.elegosoft.com> Message-ID: I know what the problem and I will fix shortly, maybe as early as Monday. The details won't interest anyone.. For now..jayk123 at hotmail.com. (not sure why they don't bounce 100%, but problems as of 12/15 were expected and I didn't act to prevent them..a policy changed after 15+ years...) - Jay > Date: Sun, 16 Dec 2007 18:10:59 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] Info about Jay Krell? Fwd: Uncaught bounce notification> > Hi,> > I wouldn't normally forward this to the list, but since Jay has been> such an eager contributor to cm3 on windows: does anybody know why> all his mail bounces and how he can be reached?> > Thanks,> > Olaf> > > Date: Sun, 16 Dec 2007 11:31:15 -0500 (EST)> Subject: Problems delivering your mail> From: MAILER-DAEMON at cornell.edu> To: m3devel-bounces at elegosoft.com> 2.1 unnamed [text/plain] 5.58 KB Download> I'm sorry, but we had problems delivering your mail.> The errors we encountered appear below. If you have any questions,> contact the Cornell Postmaster as .> Please include a copy of this message with your correspondence.> > --------> > The following addresses could not be found at all in our Directory.> Please make sure you have the correct address.> > jay.krell at cornell.edu> > --------> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ i?m is proud to present Cause Effect, a series about real people making a difference. http://im.live.com/Messenger/IM/MTV/?source=text_Cause_Effect -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Dec 17 12:03:31 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 17 Dec 2007 12:03:31 +0100 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/darwin In-Reply-To: <723A4C34-1B58-4F26-891C-45F764CAEEB5@cs.purdue.edu> References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> <28256359-D312-4D47-9A38-7A245D6AEAE5@cs.purdue.edu> <20071216233259.ukim9ntk6cw8gsgc@mail.elegosoft.com> <723A4C34-1B58-4F26-891C-45F764CAEEB5@cs.purdue.edu> Message-ID: <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> Quoting Tony Hosking : > A break is always good. :-) Hi again, after some hours of sleep I can report at least some success on my old Darwin installation. I've put the archives on our web server for public access, and would like to add some more. I still think a Darwin build on a newer system may be a good idea (we can offer both on our web pages), and we definitely need some for Linux (perhaps multiple distros, too, there?) Solaris and Darwin/i386 would be great, too, and NetBSD, and of course Windows. Mika offered to provide an archive for old FreeBSD distributions (4.x). So everybody who is willing to produce some installation archives, please let me know, and I'll make sure they get shipped to our server. Please note that for the scripts/make-bin-dist-min.sh to work, you need a sample configuration file in cm3/m3-sys/cm3/src/config/XXX, as the ones in cminstall/src/config must be processed by the installer first. Jay has removed the samples there a little bit too eagerly, but most where outdated anyway. To upgrade from an older compiler I have successfully used the upgrade.sh script. So the complete sequence to build a bootstrap on your favourite platform would be: 1. Check out the current CVS head 2. Copy your (working) configuration file to cm3/src/config/ 3. Adapt the installer configuration file if necessary in cminstall/src/config/. Make sure that all system libraries get dynamically linked, for instance. 4. scripts/upgrade.sh 5. scripts/make-bin-dist-min.sh Any help will be appreciated. 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 jayk123 at hotmail.com Tue Dec 18 08:56:24 2007 From: jayk123 at hotmail.com (Jay) Date: Tue, 18 Dec 2007 07:56:24 +0000 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc In-Reply-To: <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> <28256359-D312-4D47-9A38-7A245D6AEAE5@cs.purdue.edu> <20071216233259.ukim9ntk6cw8gsgc@mail.elegosoft.com> <723A4C34-1B58-4F26-891C-45F764CAEEB5@cs.purdue.edu> <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> Message-ID: Blech, so much duplication.. oops/sorry.I'll make a new Windows archive and put it in my user directory on m3.elegosoft.com. 64 bit integer support will have to wait. I assume we are in a "release push" here? I COULD if really necessary do about any x86 Linux (maybe x86 Solaris, don't think it is supported) or PowerPC Linux or PowerPC Darwin..in a virtual machine if nothing else.. > for Linux (perhaps multiple distros, too, there?) Oh for just a bit of compatibility... :) > 1. Check out the current CVS head> 2. Copy your (working) configuration file to cm3/src/config/> 3. Adapt the installer configuration file if necessary in> cminstall/src/config/. Make sure that all system libraries> get dynamically linked, for instance.> 4. scripts/upgrade.sh> 5. scripts/make-bin-dist-min.sh Hey! :) 1. Checkout current CVS head. 2. cminstall/src/config/NT386 should work for everyone. 3. ditto 4. scripts/win/upgrade.cmd 5. scripts/win/make-dist.cmd. I'm just being obnoxious. :) Oh btw, anyone want to make an executive decision on a minor detail? .zip or .tar.gz or .tar.bz2 or self expanding .zip in an .exe? make-dist.cmd is setup to make any of these. I don't know how to make a self expanding .tar.gz or .tar.bz2...though should be easy, perhaps not with the following feature: The .exes can either be run, or can be used as direct input to unzip, or renamed to .zip and probably opened with Windows Explorer. It's pretty neat. .tar.bz2 is always the smallest in my experience and that's what I left make-dist.cmd doing. .tar.gz is usually in the middle. .zip usually largest, though more efficient for extracting less than the whole archive -- the files are compressed individually instead of compressing the entire stream at once. Self expanding .zip adds a small fixed constant prefix. I wonder if cminstall can be "better" on Unix, comparable to it being gone on Windows, but I don't care. You know, either make it unnecessary or make it totally automatic. I know it tries to figure out the defaults. I don't know how correct it tends to be. Oh and then a really obvious obnoxious question is if we should be building .debs, .rpms, Mac .pkg/.img/.dmg etc.. Personally I don't mind the lowest tech current approach. Slackware anyone? :) (I used it in the Linux kernel 1.x time, which is when most of my Linux use ever was..) - Jay > Date: Mon, 17 Dec 2007 12:03:31 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> CC: m3-support at elegosoft.com; admins at elegosoft.com> Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/darwin> > Quoting Tony Hosking :> > A break is always good. :-)> > Hi again,> > after some hours of sleep I can report at least some success on> my old Darwin installation. I've put the archives on our web server> for public access, and would like to add some more.> > I still think a Darwin build on a newer system may be a good idea (we> can offer both on our web pages), and we definitely need some> for Linux (perhaps multiple distros, too, there?)> Solaris and Darwin/i386 would be great, too, and NetBSD, and of> course Windows. Mika offered to provide an archive for old FreeBSD> distributions (4.x).> > So everybody who is willing to produce some installation archives,> please let me know, and I'll make sure they get shipped to our> server.> > Please note that for the scripts/make-bin-dist-min.sh to work,> you need a sample configuration file in cm3/m3-sys/cm3/src/config/XXX,> as the ones in cminstall/src/config must be processed by the installer> first. Jay has removed the samples there a little bit too eagerly,> but most where outdated anyway.> > To upgrade from an older compiler I have successfully used the> upgrade.sh script. So the complete sequence to build a bootstrap> on your favourite platform would be:> > 1. Check out the current CVS head> 2. Copy your (working) configuration file to cm3/src/config/> 3. Adapt the installer configuration file if necessary in> cminstall/src/config/. Make sure that all system libraries> get dynamically linked, for instance.> 4. scripts/upgrade.sh> 5. scripts/make-bin-dist-min.sh> > Any help will be appreciated.> > 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> _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Dec 18 09:01:19 2007 From: jayk123 at hotmail.com (Jay) Date: Tue, 18 Dec 2007 08:01:19 +0000 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc In-Reply-To: <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> <28256359-D312-4D47-9A38-7A245D6AEAE5@cs.purdue.edu> <20071216233259.ukim9ntk6cw8gsgc@mail.elegosoft.com> <723A4C34-1B58-4F26-891C-45F764CAEEB5@cs.purdue.edu> <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> Message-ID: Strange that seemed to have gotten truncated.. I wonder if cminstall can be "better" on Unix, comparable to it being gone on Windows, but I don't care.You know, either make it unnecessary or make it totally automatic. I know it tries to figure out the defaults. I don't know how correct it tends to be. Oh and then a really obvious obnoxious question is if we should be building .debs, .rpms, Mac .pkg/.img/.dmg etc..Personally I don't mind the lowest tech current approach. Slackware anyone? :) (I used it in the Linux kernel 1.x time, which is when most of my Linux use ever was..) - Jay From: jayk123 at hotmail.com _________________________________________________________________ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_122007 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Dec 18 10:00:03 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 18 Dec 2007 10:00:03 +0100 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc In-Reply-To: References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> <28256359-D312-4D47-9A38-7A245D6AEAE5@cs.purdue.edu> <20071216233259.ukim9ntk6cw8gsgc@mail.elegosoft.com> <723A4C34-1B58-4F26-891C-45F764CAEEB5@cs.purdue.edu> <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> Message-ID: <20071218100003.12irq679c4o404go@mail.elegosoft.com> Quoting Jay : > 64 bit integer support will have to wait. As long as the binary does compile the current code base, it will be OK, I think. > I assume we are in a "release push" here? No, this is not really a release, I just had the impression that some current snapshots were required. > I COULD if really necessary do about any x86 Linux (maybe x86 > Solaris, don't think it is supported) or PowerPC Linux or PowerPC > Darwin..in a virtual machine if nothing else.. I think PowerPC Linux would be great, if you find the time. I don't know of many people who could build that. >> for Linux (perhaps multiple distros, too, there?) > Oh for just a bit of compatibility... :) I've done a build on Debian now. > Oh btw, anyone want to make an executive decision on a minor detail? > .zip or .tar.gz or .tar.bz2 or self expanding .zip in an .exe? > make-dist.cmd is setup to make any of these. > I don't know how to make a self expanding .tar.gz or > .tar.bz2...though should be easy, perhaps not with the following > feature: > The .exes can either be run, or can be used as direct input to > unzip, or renamed to .zip and probably opened with Windows Explorer. > It's pretty neat. > .tar.bz2 is always the smallest in my experience and that's what > I left make-dist.cmd doing. > .tar.gz is usually in the middle. > .zip usually largest, though more efficient for extracting less > than the whole archive -- the files are compressed individually > instead of compressing the entire stream at once. > Self expanding .zip adds a small fixed constant prefix. I'm fine with any of these. Since Windows does seem to use other approaches and conventions in most aspects anyway, we should just go with what is easiest for beginners. What would you suggest? Self-extracting .exe? > I wonder if cminstall can be "better" on Unix, comparable to it > being gone on Windows, but I don't care. No, it's not really better on Unix, but it's better than nothing for many, and it takes efforts to change or improve it (including all documentation), which nobody seems interested to invest. > You know, either make it unnecessary or make it totally automatic. I > know it tries to figure out the defaults. I don't know how correct > it tends to be. Making such things completely automatic on many different target platform always ends in unmanageable efforts for small teams in my experience. CM3 has no resources for this I'm afraid. > Oh and then a really obvious obnoxious question is if we should be > building .debs, .rpms, Mac .pkg/.img/.dmg etc.. This again is the question who wants to maintain all that stuff. IMO it's OK if we have special support contributed for this or that target, but nobody ever showed real interest in maintaining such support through several release cycles. > Personally I don't mind the lowest tech current approach. Slackware > anyone? :) (I used it in the Linux kernel 1.x time, which is when > most of my Linux use ever was..) I tend to agree that low-tech in the installation area may be appropriate for CM3 ;-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Tue Dec 18 10:21:24 2007 From: jayk123 at hotmail.com (Jay) Date: Tue, 18 Dec 2007 09:21:24 +0000 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc In-Reply-To: <20071218100003.12irq679c4o404go@mail.elegosoft.com> References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> <28256359-D312-4D47-9A38-7A245D6AEAE5@cs.purdue.edu> <20071216233259.ukim9ntk6cw8gsgc@mail.elegosoft.com> <723A4C34-1B58-4F26-891C-45F764CAEEB5@cs.purdue.edu> <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> <20071218100003.12irq679c4o404go@mail.elegosoft.com> Message-ID: > > 64 bit integer support will have to wait. > As long as the binary does compile the current code base, it will be OK, > I think. It does. > I think PowerPC Linux would be great, if you find the time. I don't> know of many people who could build that. Ok. Um..gotta wonder what people use here...Mandrake, OpenSuse, YellowDog, Fedora... actually given my opinion of PowerPC and Linux, I bet none. Maybe just AIX. :) (Haven't used it myself.) > > .zip or .tar.gz or .tar.bz2 or self expanding .zip in an .exe?> > I'm fine with any of these. Since Windows does seem to use other> approaches and conventions in most aspects anyway, we should just> go with what is easiest for beginners. What would you suggest?> Self-extracting .exe? Ah. Good point, know the audience. Well, I think a non self expanding .zip might be "best". The self expanding .exes I have made are console apps. The user must be comfortable with the command line (IDE integration anyone? :)) The .zip can be expanded with the builtin support or with unzip. .zip has that small advantage of "built in" support in the gui. > Making such things completely automatic on many different target platform Sounds like a job for Autoconf, eh? Actually I have experimented with Autoconf-ish sorts of stuff on Windows. If you know the local scripting language and even if that language is like 10% of what it should be, not difficult. (That is, cmd kind of stinks, but it is good enough; and on Windows the right answer is probably VBScript or JScript. They are on pretty much every machine now and are very usable from the command line, not just the browser. Soon "PowerShell"..) Thing is, I don't know Bourne shell scripting. I guess these days you could use Perl. It's everywhere and I know it well enough. Of course you still need to know how to answer the questions in an automated fashion. REALLY I have to say, I've been using Perl so much the past few years, I'm kind of torn on static compilation to native code anyway. You know, this stuff could be in Modula-3 or Quake, but Perl suffices plenty...and then you start to realize that it suffices for a heck of a lot of stuff.. I did start some autoconfish-for-Windows stuff in Quake too. :) See..there's this metapoint, metaquestion that I've been obsessing over for years...some languages really do try to be the only language you need for any task -- Java, C, C++, C#, Modula-3 -- are good examples. And then when you find them too heavyweight and start using "scripts", you start to wonder, and when those "scripts" perf and scale just fine, you start to wonder.. Many "scripting" languages are obviously no good, but some seem perhaps good enough. An example of "bad" is Tcl with its ridiculous string-centricity, how braces might LOOK like a scoping mechanism a la C and C++, but they are really a hacky escaping mechanism... cmd is also too string-centric among other things (cmd is much better than people realize, but also seriously flawed). But Perl and probably Ruby and Python really seem to be on to something in terms of "general purpose" programming languages without a "build" step. Heck, I believe Red Hat/Fedora setup is written in Python.. and there's a book out there on linkers and loaders and .obj/.exe formats where the guy developers a linker in Perl. I think that says something..something positive. - Jay _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Dec 18 12:14:23 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 18 Dec 2007 12:14:23 +0100 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc In-Reply-To: References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> <28256359-D312-4D47-9A38-7A245D6AEAE5@cs.purdue.edu> <20071216233259.ukim9ntk6cw8gsgc@mail.elegosoft.com> <723A4C34-1B58-4F26-891C-45F764CAEEB5@cs.purdue.edu> <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> <20071218100003.12irq679c4o404go@mail.elegosoft.com> Message-ID: <20071218121423.6xkl81jou88g8kc4@mail.elegosoft.com> Quoting Jay : >> > .zip or .tar.gz or .tar.bz2 or self expanding .zip in an .exe?> > >> I'm fine with any of these. Since Windows does seem to use other> >> approaches and conventions in most aspects anyway, we should just> >> go with what is easiest for beginners. What would you suggest?> >> Self-extracting .exe? > Ah. Good point, know the audience. > Well, I think a non self expanding .zip might be "best". > The self expanding .exes I have made are console apps. > The user must be comfortable with the command line (IDE integration > anyone? :)) > The .zip can be expanded with the builtin support or with unzip. > .zip has that small advantage of "built in" support in the gui. > > Making such things completely automatic on many different target platform OK, let it be zip then. > Sounds like a job for Autoconf, eh? > Actually I have experimented with Autoconf-ish sorts of stuff on Windows. > If you know the local scripting language and even if that language > is like 10% of what it should be, not difficult. > (That is, cmd kind of stinks, but it is good enough; and on Windows > the right answer is probably VBScript or JScript. They are on pretty > much every machine now and are very usable from the command line, > not just the browser. Soon "PowerShell"..) > Thing is, I don't know Bourne shell scripting. > I guess these days you could use Perl. It's everywhere and I know it > well enough. > Of course you still need to know how to answer the questions in an > automated fashion. Autoconf needs to be adapted to changes in the platforms, too. I'm not against it, it's just becoming a maintenance problem soon. > REALLY I have to say, I've been using Perl so much the past few > years, I'm kind of torn on static compilation to native code anyway. > You know, this stuff could be in Modula-3 or Quake, but Perl > suffices plenty...and then you start to realize that it suffices for > a heck of a lot of stuff.. > I did start some autoconfish-for-Windows stuff in Quake too. :) I would not want to become Perl or anything else to become another prerequisite for CM3 installation. > See..there's this metapoint, metaquestion that I've been obsessing > over for years...some languages really do try to be the only > language you need for any task -- Java, C, C++, C#, Modula-3 -- are > good examples. And then when you find them too heavyweight and start > using "scripts", you start to wonder, and when those "scripts" perf > and scale just fine, you start to wonder.. Many "scripting" > languages are obviously no good, but some seem perhaps good enough. > An example of "bad" is Tcl with its ridiculous string-centricity, > how braces might LOOK like a scoping mechanism a la C and C++, but > they are really a hacky escaping mechanism... cmd is also too > string-centric among other things (cmd is much better than people > realize, but also seriously flawed). But Perl and probably Ruby and > Python really seem to be on to something in terms of "general > purpose" programming languages without a "build" step. Heck, I > believe Red Hat/Fedora setup is written in Python.. and there's a > book out there on linkers and loaders and .obj/.exe formats where > the guy developers a linker in Perl. I think that says > something..something positive. In my opinion there's no language that suits every need. Modula-3 is great for programming large systems and building reusable abstraction. Perl tends to become difficult to read (Write Once Read Never :). Python is really good for a scripting language (we use it a lot at Elego), but should not be needed as prerequisite for CM3 either. Bourne Shell is POSIX and should exist everywhere (with the exception of Windows, which never had a really working POSIX subsystem, but you can easily install Cygwin there via a GUI). Standard POSIX (or Windows) command line tools would be the level of prerequisites I'd accept. Everything else should be discussed here and well considered before introduced. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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.caltech.edu Tue Dec 18 13:38:21 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 18 Dec 2007 04:38:21 -0800 Subject: [M3devel] Unix signals and Modula-3... Message-ID: <200712181238.lBICcL8s052879@camembert.async.caltech.edu> Hello everyone, I am in the process of bootstrapping the CVS head of CM3 on an old FreeBSD-4.11 system, and at one point, when I replaced the old cm3 with the new cm3, the compiler got slower. Not a little bit slower, mind you, but about 10x slower. I remember pointing this out to the m3devel list... oh it must have been three or four years ago; one of our grad students at Caltech (Karl Papadantonakis, also author of the caltech-parser) was the first to notice what was going on. It has to do with Process.Wait. (From ProcessPosix.m3.) To repeat what I said a few years ago, the problem lies here: CONST Delay = 0.1D0; BEGIN IF NOT p.waitOk THEN RAISE WaitAlreadyCalled END; p.waitOk := FALSE; (* By rights, the SchedulerPosix interface should have a WaitPID procedure that is integrated with the thread scheduler. *) LOOP result := Uexec.waitpid(p.pid, ADR(statusT), Uexec.WNOHANG); IF result # 0 THEN EXIT END; Thread.Pause(Delay) END; <* ASSERT result > 0 *> In other words: if Process.Wait is called before the child process is done, then the thread pauses 0.1 seconds. In our local version of m3build, we duplicate the Wait code and set the Delay to 0.0. That's OK in a compiler, but it's not OK in general, because you would chew up the CPU on a machine that was doing a lot of long-term waiting. The problem is that the fix that I suggested way back when requires messing with Unix signals (catching SIGC[H]LD instead of using waitpid), which is why I never submitted a fix to the repository, because I am not sure what such a fix might interact with. It seems to me that the correct way of dealing with Unix signals is to have a single thread that talks to the Unix system, registers signal handlers, and takes care, via some object-oriented mechanism, of calling back any M3 threads that are interested in the signals. Would such a thing be possible? Where are signals used in the system today? Mika From mika at async.caltech.edu Tue Dec 18 13:55:15 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 18 Dec 2007 04:55:15 -0800 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/darwin In-Reply-To: Your message of "Mon, 17 Dec 2007 12:03:31 +0100." <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> Message-ID: <200712181255.lBICtFbG053659@camembert.async.caltech.edu> Hi Olaf, I'm sorry to say there is a bit of a problem with your bootstrap for FreeBSD. FreeBSD is beautifully *backward*-compatible, but it's not *forward*-compatible (it may be within a major release, but it's not generally forward-compatible across major releases). The distribution you built on 6.3-PRERELEASE will work for sure on 6.x (x>=3), may work on 6.x (x<3), and will almost certainly not work on y.x (y<6). To remedy this I built a bootstrap on 4.11. It is located at http://www.async.caltech.edu/~mika/cm3-min-POSIX-FreeBSD4-d5.5.0.tgz This compiler should work on pretty much any FreeBSD 4.x, 5.x, and possibly also 6.x. I have to say that it was a bit of an ordeal. I had problems from an old cm3.cfg (mine just never seems to get upgraded right), with -g instead of -gstabs+. I also had two sets of problems stemming from LONGINT: first, of course, my old compiler didn't know what LONGINT was so I searched through my email and indeed I found something from Tony referring to building a bootstrap on NT386 from which I could infer what to do: one has to check out a "mixed" repository mixing the "devel_LONGINT_start" tagged sources with the CVS head. The problems with Int64.i3 and Long.m3 that I think we've seen on other platforms reared their ugly heads here too (although these may have been due to my -g issues, i.e., not having an up-to-date back-end?) In short, in order to build a bootstrap from a pre-LONGINT compiler at the moment, you have to be an expert at this, pretty much, you have to remember approximately where in the mailing list archive the answers are, and I would say it's a good chance that 100% of the scripts that purport to be able to do things like bootstrap cm3, well, they don't work at all. I don't even want to think about bootstrapping CM3 with PM3 or SRC M3...(I think there are systems for which some of those are all that's available?) Mika P.S. I checked in a little bugfix (C++ism removal) for m3gdb as part of this. Olaf Wagner writes: >Quoting Tony Hosking : >> A break is always good. :-) > >Hi again, > >after some hours of sleep I can report at least some success on >my old Darwin installation. I've put the archives on our web server >for public access, and would like to add some more. > >I still think a Darwin build on a newer system may be a good idea (we >can offer both on our web pages), and we definitely need some >for Linux (perhaps multiple distros, too, there?) >Solaris and Darwin/i386 would be great, too, and NetBSD, and of >course Windows. Mika offered to provide an archive for old FreeBSD >distributions (4.x). > >So everybody who is willing to produce some installation archives, >please let me know, and I'll make sure they get shipped to our >server. > >Please note that for the scripts/make-bin-dist-min.sh to work, >you need a sample configuration file in cm3/m3-sys/cm3/src/config/XXX, >as the ones in cminstall/src/config must be processed by the installer >first. Jay has removed the samples there a little bit too eagerly, >but most where outdated anyway. > >To upgrade from an older compiler I have successfully used the >upgrade.sh script. So the complete sequence to build a bootstrap >on your favourite platform would be: > > 1. Check out the current CVS head > 2. Copy your (working) configuration file to cm3/src/config/ > 3. Adapt the installer configuration file if necessary in > cminstall/src/config/. Make sure that all system libraries > get dynamically linked, for instance. 4. scripts/upgrade.sh > 5. scripts/make-bin-dist-min.sh > >Any help will be appreciated. > >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 wagner at elegosoft.com Tue Dec 18 14:52:15 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 18 Dec 2007 14:52:15 +0100 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/darwin In-Reply-To: <200712181255.lBICtFbG053659@camembert.async.caltech.edu> References: <200712181255.lBICtFbG053659@camembert.async.caltech.edu> Message-ID: <20071218145215.a9btkok1wkokg04s@mail.elegosoft.com> Quoting Mika Nystrom : > > Hi Olaf, > > I'm sorry to say there is a bit of a problem with your bootstrap for > FreeBSD. FreeBSD is beautifully *backward*-compatible, but it's not > *forward*-compatible (it may be within a major release, but it's not > generally forward-compatible across major releases). The distribution > you built on 6.3-PRERELEASE will work for sure on 6.x (x>=3), may work > on 6.x (x<3), and will almost certainly not work on y.x (y<6). To > remedy this I built a bootstrap on 4.11. It is located at > > http://www.async.caltech.edu/~mika/cm3-min-POSIX-FreeBSD4-d5.5.0.tgz > > This compiler should work on pretty much any FreeBSD 4.x, 5.x, and > possibly also 6.x. I was afraid that there is no forward compatibility. So it's great that we've got a 4.11 build, I'll add it to our site this evening. I don't think anybody will still use any older versions. > I have to say that it was a bit of an ordeal. I had problems from > an old cm3.cfg (mine just never seems to get upgraded right), with > -g instead of -gstabs+. I also had two sets of problems stemming > from LONGINT: first, of course, my old compiler didn't know what > LONGINT was so I searched through my email and indeed I found > something from Tony referring to building a bootstrap on NT386 from > which I could infer what to do: one has to check out a "mixed" > repository mixing the "devel_LONGINT_start" tagged sources with the > CVS head. The problems with Int64.i3 and Long.m3 that I think we've > seen on other platforms reared their ugly heads here too (although > these may have been due to my -g issues, i.e., not having an > up-to-date back-end?) > > In short, in order to build a bootstrap from a pre-LONGINT compiler > at the moment, you have to be an expert at this, pretty much, you > have to remember approximately where in the mailing list archive > the answers are, and I would say it's a good chance that 100% of > the scripts that purport to be able to do things like bootstrap > cm3, well, they don't work at all. I don't even want to think about > bootstrapping CM3 with PM3 or SRC M3...(I think there are systems > for which some of those are all that's available?) I thought that the upgrade.sh script would take care of the pre-LONGINT / LONGINT transition, at least it worked for me on FreeBSD. At least if you start with a 5.4 release CM3. Outdated config files are of course always nasty; FreeBSD itself has complex support in form of the mergemaster utilty for its own upgrades for these problems. I'm afraid we'll not easily reach this level in CM3. The bootstrap scripts for CM3 with PM3 or even SRC M3 are from the beginning of the open source CM3 distribution; they did work at some point in time, but have not been used since. Perhaps they should rather be deleted or moved to an old-stuff directory. Sorry for all the inconveniences, but you seem to have coped well ;-) Thank you very much, Olaf > Mika > > P.S. I checked in a little bugfix (C++ism removal) for m3gdb as part > of this. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Dec 18 15:17:03 2007 From: jay.krell at cornell.edu (Jay) Date: Tue, 18 Dec 2007 14:17:03 +0000 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/ In-Reply-To: <20071218145215.a9btkok1wkokg04s@mail.elegosoft.com> References: <200712181255.lBICtFbG053659@camembert.async.caltech.edu> <20071218145215.a9btkok1wkokg04s@mail.elegosoft.com> Message-ID: new Windows builds in ~jkrell on modula3.elegosoft.com from current CVS (ie: a different checkout than where I have edits): % ls -ltotal 4480-rw------- 1 jkrell jkrell 882018 2007-12-18 15:04 cm3-min-WIN32-NT386-d5.5.0-symbols.zip-rw------- 1 jkrell jkrell 3679897 2007-12-18 15:05 cm3-min-WIN32-NT386-d5.5.0.zip Windows /might/ have it easy with LONGINT, however Windows still has it tricky, and maybe not easy, maybe the same trickiness. In particular, what you do is: get an existing binary release That gives you cm3 and a pkg repository with m3core and libm3. buildship ONLY cm3 and upgrade-compiler, since ship of cm3 doesn't actually do anything perhaps, at least on Windows where the file is in use And then, after having built a new compiler, go and build everything else with it. "Normally" you might build things from the bottom of a dependency graph and on up -- m3core, libm3, cm3. However in this case you must stick with the old m3core and libm3 and only build cm3. The current m3core/libm3 cannot be built with an old compiler, but an old compiler can build a new compiler. upgrade.cmd automates this and I suspect upgrade.sh does as well. I'll be able to do Mac OS X 10.4 builds before Linux PowerPC, but should get to Linux PowerPC in a few days. Perl can written in a readable maintainable fashion, really. The bigger "problem" is regular expressions -- with great power/density comes great responsibility.. There is the /x flag to make them able to take comments, but it is badly flawed in that comments confuse the parser. It's a case of regexps being overly woven into the syntax. my $re = RegExp->new("..") sould have sufficed without messing up the syntax. - Jay > Date: Tue, 18 Dec 2007 14:52:15 +0100> From: wagner at elegosoft.com> To: mika at async.caltech.edu> CC: m3devel at elegosoft.com; mika at camembert.async.caltech.edu> Subject: Re: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/darwin> > Quoting Mika Nystrom :> > >> > Hi Olaf,> >> > I'm sorry to say there is a bit of a problem with your bootstrap for> > FreeBSD. FreeBSD is beautifully *backward*-compatible, but it's not> > *forward*-compatible (it may be within a major release, but it's not> > generally forward-compatible across major releases). The distribution> > you built on 6.3-PRERELEASE will work for sure on 6.x (x>=3), may work> > on 6.x (x<3), and will almost certainly not work on y.x (y<6). To> > remedy this I built a bootstrap on 4.11. It is located at> >> > http://www.async.caltech.edu/~mika/cm3-min-POSIX-FreeBSD4-d5.5.0.tgz> >> > This compiler should work on pretty much any FreeBSD 4.x, 5.x, and> > possibly also 6.x.> > I was afraid that there is no forward compatibility. So it's> great that we've got a 4.11 build, I'll add it to our site this evening.> I don't think anybody will still use any older versions.> > > I have to say that it was a bit of an ordeal. I had problems from> > an old cm3.cfg (mine just never seems to get upgraded right), with> > -g instead of -gstabs+. I also had two sets of problems stemming> > from LONGINT: first, of course, my old compiler didn't know what> > LONGINT was so I searched through my email and indeed I found> > something from Tony referring to building a bootstrap on NT386 from> > which I could infer what to do: one has to check out a "mixed"> > repository mixing the "devel_LONGINT_start" tagged sources with the> > CVS head. The problems with Int64.i3 and Long.m3 that I think we've> > seen on other platforms reared their ugly heads here too (although> > these may have been due to my -g issues, i.e., not having an> > up-to-date back-end?)> >> > In short, in order to build a bootstrap from a pre-LONGINT compiler> > at the moment, you have to be an expert at this, pretty much, you> > have to remember approximately where in the mailing list archive> > the answers are, and I would say it's a good chance that 100% of> > the scripts that purport to be able to do things like bootstrap> > cm3, well, they don't work at all. I don't even want to think about> > bootstrapping CM3 with PM3 or SRC M3...(I think there are systems> > for which some of those are all that's available?)> > I thought that the upgrade.sh script would take care of the> pre-LONGINT / LONGINT transition, at least it worked for me> on FreeBSD. At least if you start with a 5.4 release CM3.> > Outdated config files are of course always nasty; FreeBSD itself> has complex support in form of the mergemaster utilty for its> own upgrades for these problems. I'm afraid we'll not easily reach> this level in CM3.> > The bootstrap scripts for CM3 with PM3 or even SRC M3 are from the> beginning of the open source CM3 distribution; they did work at> some point in time, but have not been used since. Perhaps they should> rather be deleted or moved to an old-stuff directory.> > Sorry for all the inconveniences, but you seem to have coped well ;-)> > Thank you very much,> > Olaf> > Mika> >> > P.S. I checked in a little bugfix (C++ism removal) for m3gdb as part> > of this.> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. http://www.xbox.com/en-US/hardware/wheretobuy/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Dec 18 15:20:17 2007 From: jayk123 at hotmail.com (Jay) Date: Tue, 18 Dec 2007 14:20:17 +0000 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/ In-Reply-To: References: <200712181255.lBICtFbG053659@camembert.async.caltech.edu> <20071218145215.a9btkok1wkokg04s@mail.elegosoft.com> Message-ID: ps: speaking of pre-reqs..m3-win/import-libs/m3makefile has a special hack to find my Visual C++ 2.0 toolset. In this way the distribution can support any Visual C++ toolset, probably. However this is not right in terms of letting anyone build a distribution. There remains an open question as to which toolsets to support, er, which Microsoft ones to support. I built this with 8.0. 9.0 has been released now. - Jay From: jay.krell at cornell.eduTo: wagner at elegosoft.com; mika at async.caltech.eduDate: Tue, 18 Dec 2007 14:17:03 +0000CC: m3devel at elegosoft.com; mika at camembert.async.caltech.eduSubject: Re: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/ new Windows builds in ~jkrell on modula3.elegosoft.com from current CVS (ie: a different checkout than where I have edits):% ls -ltotal 4480-rw------- 1 jkrell jkrell 882018 2007-12-18 15:04 cm3-min-WIN32-NT386-d5.5.0-symbols.zip-rw------- 1 jkrell jkrell 3679897 2007-12-18 15:05 cm3-min-WIN32-NT386-d5.5.0.zipWindows /might/ have it easy with LONGINT, however Windows still has it tricky, and maybe not easy, maybe the same trickiness. In particular, what you do is: get an existing binary release That gives you cm3 and a pkg repository with m3core and libm3. buildship ONLY cm3 and upgrade-compiler, since ship of cm3 doesn't actually do anything perhaps, at least on Windows where the file is in use And then, after having built a new compiler, go and build everything else with it. "Normally" you might build things from the bottom of a dependency graph and on up -- m3core, libm3, cm3.However in this case you must stick with the old m3core and libm3 and only build cm3.The current m3core/libm3 cannot be built with an old compiler, but an old compiler can build a new compiler. upgrade.cmd automates this and I suspect upgrade.sh does as well. I'll be able to do Mac OS X 10.4 builds before Linux PowerPC, but should get to Linux PowerPC in a few days. Perl can written in a readable maintainable fashion, really.The bigger "problem" is regular expressions -- with great power/density comes great responsibility..There is the /x flag to make them able to take comments, but it is badly flawed in that commentsconfuse the parser. It's a case of regexps being overly woven into the syntax.my $re = RegExp->new("..") sould have sufficed without messing up the syntax. - Jay > Date: Tue, 18 Dec 2007 14:52:15 +0100> From: wagner at elegosoft.com> To: mika at async.caltech.edu> CC: m3devel at elegosoft.com; mika at camembert.async.caltech.edu> Subject: Re: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/darwin> > Quoting Mika Nystrom :> > >> > Hi Olaf,> >> > I'm sorry to say there is a bit of a problem with your bootstrap for> > FreeBSD. FreeBSD is beautifully *backward*-compatible, but it's not> > *forward*-compatible (it may be within a major release, but it's not> > generally forward-compatible across major releases). The distribution> > you built on 6.3-PRERELEASE will work for sure on 6.x (x>=3), may work> > on 6.x (x<3), and will almost certainly not work on y.x (y<6). To> > remedy this I built a bootstrap on 4.11. It is located at> >> > http://www.async.caltech.edu/~mika/cm3-min-POSIX-FreeBSD4-d5.5.0.tgz> >> > This compiler should work on pretty much any FreeBSD 4.x, 5.x, and> > possibly also 6.x.> > I was afraid that there is no forward compatibility. So it's> great that we've got a 4.11 build, I'll add it to our site this evening.> I don't think anybody will still use any older versions.> > > I have to say that it was a bit of an ordeal. I had problems from> > an old cm3.cfg (mine just never seems to get upgraded right), with> > -g instead of -gstabs+. I also had two sets of problems stemming> > from LONGINT: first, of course, my old compiler didn't know what> > LONGINT was so I searched through my email and indeed I found> > something from Tony referring to building a bootstrap on NT386 from> > which I could infer what to do: one has to check out a "mixed"> > repository mixing the "devel_LONGINT_start" tagged sources with the> > CVS head. The problems with Int64.i3 and Long.m3 that I think we've> > seen on other platforms reared their ugly heads here too (although> > these may have been due to my -g issues, i.e., not having an> > up-to-date back-end?)> >> > In short, in order to build a bootstrap from a pre-LONGINT compiler> > at the moment, you have to be an expert at this, pretty much, you> > have to remember approximately where in the mailing list archive> > the answers are, and I would say it's a good chance that 100% of> > the scripts that purport to be able to do things like bootstrap> > cm3, well, they don't work at all. I don't even want to think about> > bootstrapping CM3 with PM3 or SRC M3...(I think there are systems> > for which some of those are all that's available?)> > I thought that the upgrade.sh script would take care of the> pre-LONGINT / LONGINT transition, at least it worked for me> on FreeBSD. At least if you start with a 5.4 release CM3.> > Outdated config files are of course always nasty; FreeBSD itself> has complex support in form of the mergemaster utilty for its> own upgrades for these problems. I'm afraid we'll not easily reach> this level in CM3.> > The bootstrap scripts for CM3 with PM3 or even SRC M3 are from the> beginning of the open source CM3 distribution; they did work at> some point in time, but have not been used since. Perhaps they should> rather be deleted or moved to an old-stuff directory.> > Sorry for all the inconveniences, but you seem to have coped well ;-)> > Thank you very much,> > Olaf> > Mika> >> > P.S. I checked in a little bugfix (C++ism removal) for m3gdb as part> > of this.> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. Get it now! _________________________________________________________________ The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. http://www.xbox.com/en-US/hardware/wheretobuy/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Dec 18 17:27:03 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 18 Dec 2007 11:27:03 -0500 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/darwin In-Reply-To: <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> <28256359-D312-4D47-9A38-7A245D6AEAE5@cs.purdue.edu> <20071216233259.ukim9ntk6cw8gsgc@mail.elegosoft.com> <723A4C34-1B58-4F26-891C-45F764CAEEB5@cs.purdue.edu> <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> Message-ID: I can provide a 32-bit x86-64(AMD64) build too. It is based on the existing 32-bit LINUXLIBC6, but needs a special cm3.cfg. On Dec 17, 2007, at 6:03 AM, Olaf Wagner wrote: > Quoting Tony Hosking : >> A break is always good. :-) > > Hi again, > > after some hours of sleep I can report at least some success on > my old Darwin installation. I've put the archives on our web server > for public access, and would like to add some more. > > I still think a Darwin build on a newer system may be a good idea (we > can offer both on our web pages), and we definitely need some > for Linux (perhaps multiple distros, too, there?) > Solaris and Darwin/i386 would be great, too, and NetBSD, and of > course Windows. Mika offered to provide an archive for old FreeBSD > distributions (4.x). > > So everybody who is willing to produce some installation archives, > please let me know, and I'll make sure they get shipped to our > server. > > Please note that for the scripts/make-bin-dist-min.sh to work, > you need a sample configuration file in cm3/m3-sys/cm3/src/config/XXX, > as the ones in cminstall/src/config must be processed by the installer > first. Jay has removed the samples there a little bit too eagerly, > but most where outdated anyway. > > To upgrade from an older compiler I have successfully used the > upgrade.sh script. So the complete sequence to build a bootstrap > on your favourite platform would be: > > 1. Check out the current CVS head > 2. Copy your (working) configuration file to cm3/src/config/ > 3. Adapt the installer configuration file if necessary in > cminstall/src/config/. Make sure that all system libraries > get dynamically linked, for instance. > 4. scripts/upgrade.sh > 5. scripts/make-bin-dist-min.sh > > Any help will be appreciated. > > 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 hosking at cs.purdue.edu Tue Dec 18 17:27:49 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 18 Dec 2007 11:27:49 -0500 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/darwin In-Reply-To: <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> <28256359-D312-4D47-9A38-7A245D6AEAE5@cs.purdue.edu> <20071216233259.ukim9ntk6cw8gsgc@mail.elegosoft.com> <723A4C34-1B58-4F26-891C-45F764CAEEB5@cs.purdue.edu> <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> Message-ID: <31F9814D-0409-4B57-BADD-C61DB4C4B14D@cs.purdue.edu> What does an installation archive consist of? I've not used an install archive for several years, since I just bootstrap from my existing installs. On Dec 17, 2007, at 6:03 AM, Olaf Wagner wrote: > Quoting Tony Hosking : >> A break is always good. :-) > > Hi again, > > after some hours of sleep I can report at least some success on > my old Darwin installation. I've put the archives on our web server > for public access, and would like to add some more. > > I still think a Darwin build on a newer system may be a good idea (we > can offer both on our web pages), and we definitely need some > for Linux (perhaps multiple distros, too, there?) > Solaris and Darwin/i386 would be great, too, and NetBSD, and of > course Windows. Mika offered to provide an archive for old FreeBSD > distributions (4.x). > > So everybody who is willing to produce some installation archives, > please let me know, and I'll make sure they get shipped to our > server. > > Please note that for the scripts/make-bin-dist-min.sh to work, > you need a sample configuration file in cm3/m3-sys/cm3/src/config/XXX, > as the ones in cminstall/src/config must be processed by the installer > first. Jay has removed the samples there a little bit too eagerly, > but most where outdated anyway. > > To upgrade from an older compiler I have successfully used the > upgrade.sh script. So the complete sequence to build a bootstrap > on your favourite platform would be: > > 1. Check out the current CVS head > 2. Copy your (working) configuration file to cm3/src/config/ > 3. Adapt the installer configuration file if necessary in > cminstall/src/config/. Make sure that all system libraries > get dynamically linked, for instance. > 4. scripts/upgrade.sh > 5. scripts/make-bin-dist-min.sh > > Any help will be appreciated. > > 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 hosking at cs.purdue.edu Tue Dec 18 17:33:52 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 18 Dec 2007 11:33:52 -0500 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc In-Reply-To: <20071218100003.12irq679c4o404go@mail.elegosoft.com> References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> <28256359-D312-4D47-9A38-7A245D6AEAE5@cs.purdue.edu> <20071216233259.ukim9ntk6cw8gsgc@mail.elegosoft.com> <723A4C34-1B58-4F26-891C-45F764CAEEB5@cs.purdue.edu> <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> <20071218100003.12irq679c4o404go@mail.elegosoft.com> Message-ID: On Dec 18, 2007, at 4:00 AM, Olaf Wagner wrote: > Quoting Jay : > >> 64 bit integer support will have to wait. > As long as the binary does compile the current code base, it will > be OK, > I think. Yes, currently INTEGER=LONGINT on Win32 platforms using the integrated backend. > >> I assume we are in a "release push" here? > No, this is not really a release, I just had the impression that > some current snapshots were required. > >> I COULD if really necessary do about any x86 Linux (maybe x86 >> Solaris, don't think it is supported) or PowerPC Linux or PowerPC >> Darwin..in a virtual machine if nothing else.. > > I think PowerPC Linux would be great, if you find the time. I don't > know of many people who could build that. > >>> for Linux (perhaps multiple distros, too, there?) >> Oh for just a bit of compatibility... :) > I've done a build on Debian now. > >> Oh btw, anyone want to make an executive decision on a minor detail? >> .zip or .tar.gz or .tar.bz2 or self expanding .zip in an .exe? >> make-dist.cmd is setup to make any of these. >> I don't know how to make a self expanding .tar.gz >> or .tar.bz2...though should be easy, perhaps not with the >> following feature: >> The .exes can either be run, or can be used as direct input to >> unzip, or renamed to .zip and probably opened with Windows Explorer. >> It's pretty neat. >> .tar.bz2 is always the smallest in my experience and that's >> what I left make-dist.cmd doing. >> .tar.gz is usually in the middle. >> .zip usually largest, though more efficient for extracting less >> than the whole archive -- the files are compressed individually >> instead of compressing the entire stream at once. >> Self expanding .zip adds a small fixed constant prefix. > > I'm fine with any of these. Since Windows does seem to use other > approaches and conventions in most aspects anyway, we should just > go with what is easiest for beginners. What would you suggest? > Self-extracting .exe? > >> I wonder if cminstall can be "better" on Unix, comparable to it >> being gone on Windows, but I don't care. > No, it's not really better on Unix, but it's better than nothing > for many, and it takes efforts to change or improve it (including all > documentation), which nobody seems interested to invest. > >> You know, either make it unnecessary or make it totally automatic. >> I know it tries to figure out the defaults. I don't know how >> correct it tends to be. > Making such things completely automatic on many different target > platform > always ends in unmanageable efforts for small teams in my experience. > CM3 has no resources for this I'm afraid. > >> Oh and then a really obvious obnoxious question is if we should >> be building .debs, .rpms, Mac .pkg/.img/.dmg etc.. > This again is the question who wants to maintain all that stuff. > IMO it's OK if we have special support contributed for this or that > target, but nobody ever showed real interest in maintaining such > support through several release cycles. > >> Personally I don't mind the lowest tech current approach. >> Slackware anyone? :) (I used it in the Linux kernel 1.x time, >> which is when most of my Linux use ever was..) > I tend to agree that low-tech in the installation area may be > appropriate for CM3 ;-) > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From wagner at elegosoft.com Tue Dec 18 20:05:01 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 18 Dec 2007 20:05:01 +0100 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/darwin In-Reply-To: <31F9814D-0409-4B57-BADD-C61DB4C4B14D@cs.purdue.edu> References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> <28256359-D312-4D47-9A38-7A245D6AEAE5@cs.purdue.edu> <20071216233259.ukim9ntk6cw8gsgc@mail.elegosoft.com> <723A4C34-1B58-4F26-891C-45F764CAEEB5@cs.purdue.edu> <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> <31F9814D-0409-4B57-BADD-C61DB4C4B14D@cs.purdue.edu> Message-ID: <20071218200501.3xmb0yuyha80g8gs@mail.elegosoft.com> Quoting Tony Hosking : > What does an installation archive consist of? I've not used an install > archive for several years, since I just bootstrap from my existing > installs. See far below. They are easily built by the script make-bin-dist-bin.sh within a standard CM3 workspace (step 5). >> 1. Check out the current CVS head >> 2. Copy your (working) configuration file to cm3/src/config/ >> 3. Adapt the installer configuration file if necessary in >> cminstall/src/config/. Make sure that all system libraries >> get dynamically linked, for instance. >> 4. scripts/upgrade.sh >> 5. scripts/make-bin-dist-min.sh This is the exact installation procedure invented by Critical Mass and implemented in cminstall (except for the registration key). These are the contents of a sample: % tar tzf cm3-min-POSIX-FreeBSD6-d5.5.0.tgz cminstall COPYRIGHT-CMASS system.tgz birch [~/cm3-dist] wagner % tar tzf system.tgz ./ ./bin/ ./doc/ ./elisp/ ./examples/ ./lib/ ./man/ ./pkg/ ./pkg/m3core/ ./pkg/libm3/ ./pkg/libm3/FreeBSD4/ ./pkg/libm3/src/ ./pkg/libm3/src/text/ ./pkg/libm3/src/os/ ./pkg/libm3/src/random/ ./pkg/libm3/src/uid/ ./pkg/libm3/src/rw/ ./pkg/libm3/src/fmtlex/ ./pkg/libm3/src/list/ ./pkg/libm3/src/sx/ ./pkg/libm3/src/types/ ./pkg/libm3/src/arith/ ./pkg/libm3/src/geometry/ ./pkg/libm3/src/statistics/ ./pkg/libm3/src/formatter/ ./pkg/libm3/src/params/ ./pkg/libm3/src/property/ ./pkg/libm3/src/table/ ./pkg/libm3/src/atom/ ./pkg/libm3/src/sortedtable/ ./pkg/libm3/src/sort/ ./pkg/libm3/src/sequence/ ./pkg/libm3/src/etimer/ ./pkg/libm3/src/bundleintf/ ./pkg/libm3/src/perftool/ ./pkg/libm3/src/pqueue/ ./pkg/libm3/src/sqrt/ ./pkg/libm3/src/pickle/ ./pkg/libm3/src/pickle/ver1/ ./pkg/libm3/src/pickle/ver2/ ./pkg/libm3/src/pickle/ver2/PklTipeMap.i3 ./pkg/libm3/src/pickle/ver2/PklTipeMap.m3 ./pkg/libm3/src/pickle/ver2/ConvertPacking.i3 ./pkg/libm3/src/pickle/ver2/ConvertPacking.m3 ./pkg/libm3/src/pickle/ver2/PklAction.i3 ./pkg/libm3/src/pickle/ver2/PickleRd.i3 ./pkg/libm3/src/pickle/ver2/PackingTypeCode.m3 ./pkg/libm3/src/pickle/ver2/PackingTypeCode.i3 ./pkg/libm3/src/pickle/ver2/BuiltinSpecials2.m3 ./pkg/libm3/src/pickle/ver2/BuiltinSpecials2.i3 ./pkg/libm3/src/pickle/ver2/Pickle2.i3 ./pkg/libm3/src/pickle/ver2/Pickle2.m3 ./pkg/libm3/src/pickle/ver2/PickleStubs.i3 ./pkg/libm3/src/pickle/ver2/PickleStubs.m3 ./pkg/libm3/src/pickle/ver1/Pickle.m3 ./pkg/libm3/src/pickle/ver1/Pickle.i3 ./pkg/libm3/src/pickle/ver1/BuiltinSpecials.m3 ./pkg/libm3/src/pickle/ver1/BuiltinSpecials.i3 ./pkg/libm3/src/sqrt/FloatExtras.mg ./pkg/libm3/src/sqrt/FloatExtras.ig ./pkg/libm3/src/sqrt/Sqrt.mg ./pkg/libm3/src/sqrt/Sqrt.ig ./pkg/libm3/src/pqueue/pqueue.tmpl ./pkg/libm3/src/pqueue/PQueue.ig ./pkg/libm3/src/pqueue/PQueue.mg ./pkg/libm3/src/pqueue/PQueueRep.ig ./pkg/libm3/src/perftool/Common/ ./pkg/libm3/src/perftool/POSIX/ ./pkg/libm3/src/perftool/POSIX/LowPerfTool.m3 ./pkg/libm3/src/perftool/Common/PerfTool.m3 ./pkg/libm3/src/perftool/Common/PerfTool.i3 ./pkg/libm3/src/perftool/Common/LowPerfTool.i3 ./pkg/libm3/src/perftool/Common/PerfComm.ig ./pkg/libm3/src/perftool/Common/PerfComm.mg ./pkg/libm3/src/bundleintf/bundle.tmpl ./pkg/libm3/src/bundleintf/Bundle.i3 ./pkg/libm3/src/bundleintf/Bundle.m3 ./pkg/libm3/src/bundleintf/BundleRep.i3 ./pkg/libm3/src/etimer/ETimer.i3 ./pkg/libm3/src/etimer/ETimer.m3 ./pkg/libm3/src/sequence/sequence.tmpl ./pkg/libm3/src/sequence/Sequence.mg ./pkg/libm3/src/sequence/Sequence.ig ./pkg/libm3/src/sequence/SequenceRep.ig ./pkg/libm3/src/sort/ArraySort.ig ./pkg/libm3/src/sort/ArraySort.mg ./pkg/libm3/src/sort/arraysort.tmpl ./pkg/libm3/src/sortedtable/sortedtable.tmpl ./pkg/libm3/src/sortedtable/SortedTable.mg ./pkg/libm3/src/sortedtable/SortedTable.ig ./pkg/libm3/src/atom/Atom.i3 ./pkg/libm3/src/atom/Atom.m3 ./pkg/libm3/src/table/table.tmpl ./pkg/libm3/src/table/Table.ig ./pkg/libm3/src/table/Table.mg ./pkg/libm3/src/property/Property.i3 ./pkg/libm3/src/property/Property.m3 ./pkg/libm3/src/property/PropertyV.i3 ./pkg/libm3/src/property/PropertyV.m3 ./pkg/libm3/src/property/MProperty.m3 ./pkg/libm3/src/property/MProperty.i3 ./pkg/libm3/src/property/PropertyF.i3 ./pkg/libm3/src/property/MPropertyF.i3 ./pkg/libm3/src/params/Env.m3 ./pkg/libm3/src/params/Env.i3 ./pkg/libm3/src/params/Params.m3 ./pkg/libm3/src/params/Params.i3 ./pkg/libm3/src/formatter/Formatter.m3 ./pkg/libm3/src/formatter/Formatter.i3 ./pkg/libm3/src/statistics/Stat.m3 ./pkg/libm3/src/statistics/Stat.i3 ./pkg/libm3/src/geometry/Axis.i3 ./pkg/libm3/src/geometry/Axis.m3 ./pkg/libm3/src/geometry/Interval.i3 ./pkg/libm3/src/geometry/Interval.m3 ./pkg/libm3/src/geometry/Point.m3 ./pkg/libm3/src/geometry/Point.i3 ./pkg/libm3/src/geometry/Rect.i3 ./pkg/libm3/src/geometry/Rect.m3 ./pkg/libm3/src/geometry/Transform.i3 ./pkg/libm3/src/geometry/Transform.m3 ./pkg/libm3/src/geometry/Path.m3 ./pkg/libm3/src/geometry/Path.i3 ./pkg/libm3/src/geometry/Region.i3 ./pkg/libm3/src/geometry/Region.m3 ./pkg/libm3/src/geometry/PolyRegion.i3 ./pkg/libm3/src/geometry/PolyRegion.m3 ./pkg/libm3/src/geometry/Trapezoid.i3 ./pkg/libm3/src/geometry/Trapezoid.m3 ./pkg/libm3/src/geometry/RegionRep.i3 ./pkg/libm3/src/geometry/PathPrivate.i3 ./pkg/libm3/src/arith/POSIX/ ./pkg/libm3/src/arith/POSIX/Math.i3 ./pkg/libm3/src/types/Integer.m3 ./pkg/libm3/src/types/Integer.i3 ./pkg/libm3/src/types/Refany.i3 ./pkg/libm3/src/types/Refany.m3 ./pkg/libm3/src/types/Boolean.i3 ./pkg/libm3/src/types/Boolean.m3 ./pkg/libm3/src/types/Char.m3 ./pkg/libm3/src/types/Char.i3 ./pkg/libm3/src/types/Int32.i3 ./pkg/libm3/src/types/Int32.m3 ./pkg/libm3/src/types/Int64.i3 ./pkg/libm3/src/types/Int64.m3 ./pkg/libm3/src/types/Longint.i3 ./pkg/libm3/src/types/Longint.m3 ./pkg/libm3/src/types/ASCII.i3 ./pkg/libm3/src/types/ASCII.m3 ./pkg/libm3/src/types/RealType.i3 ./pkg/libm3/src/types/RealType.m3 ./pkg/libm3/src/types/LongrealType.i3 ./pkg/libm3/src/types/LongrealType.m3 ./pkg/libm3/src/types/WideChar.i3 ./pkg/libm3/src/types/WideChar.m3 ./pkg/libm3/src/types/Unicode.m3 ./pkg/libm3/src/types/Unicode.i3 ./pkg/libm3/src/sx/Sx.m3 ./pkg/libm3/src/sx/Sx.i3 ./pkg/libm3/src/list/list.tmpl ./pkg/libm3/src/list/List.mg ./pkg/libm3/src/list/List.ig ./pkg/libm3/src/list/ListSort.mg ./pkg/libm3/src/list/ListSort.ig ./pkg/libm3/src/fmtlex/Fmt.m3 ./pkg/libm3/src/fmtlex/Fmt.i3 ./pkg/libm3/src/fmtlex/Lex.m3 ./pkg/libm3/src/fmtlex/Lex.i3 ./pkg/libm3/src/fmtlex/Scan.i3 ./pkg/libm3/src/fmtlex/Scan.m3 ./pkg/libm3/src/fmtlex/FmtBuf.m3 ./pkg/libm3/src/fmtlex/FmtBuf.i3 ./pkg/libm3/src/fmtlex/FmtBufF.i3 ./pkg/libm3/src/fmtlex/FmtBufTest.i3 ./pkg/libm3/src/rw/Rd.i3 ./pkg/libm3/src/rw/Rd.m3 ./pkg/libm3/src/rw/RdClass.i3 ./pkg/libm3/src/rw/UnsafeRd.i3 ./pkg/libm3/src/rw/Wr.i3 ./pkg/libm3/src/rw/Wr.m3 ./pkg/libm3/src/rw/WrClass.i3 ./pkg/libm3/src/rw/UnsafeWr.i3 ./pkg/libm3/src/rw/NullRd.m3 ./pkg/libm3/src/rw/NullRd.i3 ./pkg/libm3/src/rw/NullWr.m3 ./pkg/libm3/src/rw/NullWr.i3 ./pkg/libm3/src/rw/RdCopy.i3 ./pkg/libm3/src/rw/RdCopy.m3 ./pkg/libm3/src/rw/TextRd.i3 ./pkg/libm3/src/rw/TextRd.m3 ./pkg/libm3/src/rw/TextWr.m3 ./pkg/libm3/src/rw/TextWr.i3 ./pkg/libm3/src/rw/FileRd.i3 ./pkg/libm3/src/rw/FileRd.m3 ./pkg/libm3/src/rw/FileWr.i3 ./pkg/libm3/src/rw/FileWr.m3 ./pkg/libm3/src/rw/IO.m3 ./pkg/libm3/src/rw/IO.i3 ./pkg/libm3/src/rw/AutoFlushWr.m3 ./pkg/libm3/src/rw/AutoFlushWr.i3 ./pkg/libm3/src/rw/Stdio.m3 ./pkg/libm3/src/rw/Stdio.i3 ./pkg/libm3/src/rw/RdUtils.m3 ./pkg/libm3/src/rw/RdUtils.i3 ./pkg/libm3/src/rw/RdExtras.m3 ./pkg/libm3/src/rw/RdExtras.i3 ./pkg/libm3/src/rw/MsgRd.i3 ./pkg/libm3/src/rw/MsgWr.i3 ./pkg/libm3/src/uid/Common/ ./pkg/libm3/src/uid/POSIX/ ./pkg/libm3/src/uid/POSIX/MachineIDPosixC.i3 ./pkg/libm3/src/uid/POSIX/MachineIDPosixC.c ./pkg/libm3/src/uid/POSIX/MachineIDPosix.m3 ./pkg/libm3/src/uid/Common/TimeStamp.i3 ./pkg/libm3/src/uid/Common/TimeStamp.m3 ./pkg/libm3/src/uid/Common/Capability.i3 ./pkg/libm3/src/uid/Common/Capability.m3 ./pkg/libm3/src/uid/Common/Swap.i3 ./pkg/libm3/src/uid/Common/Swap.m3 ./pkg/libm3/src/uid/Common/MachineID.i3 ./pkg/libm3/src/uid/Common/TimeStampRep.i3 ./pkg/libm3/src/random/Common/ ./pkg/libm3/src/random/IEEE/ ./pkg/libm3/src/random/IEEE/RandomReal.m3 ./pkg/libm3/src/random/Common/Random.m3 ./pkg/libm3/src/random/Common/Random.i3 ./pkg/libm3/src/random/Common/RandomPerm.i3 ./pkg/libm3/src/random/Common/RandomPerm.m3 ./pkg/libm3/src/random/Common/RandomReal.i3 ./pkg/libm3/src/os/Common/ ./pkg/libm3/src/os/POSIX/ ./pkg/libm3/src/os/POSIX/OSConfig.i3 ./pkg/libm3/src/os/POSIX/OSErrorPosix.i3 ./pkg/libm3/src/os/POSIX/OSErrorPosix.m3 ./pkg/libm3/src/os/POSIX/FilePosix.i3 ./pkg/libm3/src/os/POSIX/FilePosix.m3 ./pkg/libm3/src/os/POSIX/FSPosix.m3 ./pkg/libm3/src/os/POSIX/PipePosix.m3 ./pkg/libm3/src/os/POSIX/PathnamePosix.m3 ./pkg/libm3/src/os/POSIX/ProcessPosix.m3 ./pkg/libm3/src/os/POSIX/SocketPosix.m3 ./pkg/libm3/src/os/POSIX/OSConfigPosix.m3 ./pkg/libm3/src/os/Common/OSError.i3 ./pkg/libm3/src/os/Common/File.i3 ./pkg/libm3/src/os/Common/RegularFile.m3 ./pkg/libm3/src/os/Common/RegularFile.i3 ./pkg/libm3/src/os/Common/Pipe.i3 ./pkg/libm3/src/os/Common/Pipe.m3 ./pkg/libm3/src/os/Common/Pathname.i3 ./pkg/libm3/src/os/Common/FS.i3 ./pkg/libm3/src/os/Common/FS.m3 ./pkg/libm3/src/os/Common/Process.i3 ./pkg/libm3/src/os/Common/Socket.m3 ./pkg/libm3/src/os/Common/Socket.i3 ./pkg/libm3/src/os/Common/Terminal.m3 ./pkg/libm3/src/os/Common/Terminal.i3 ./pkg/libm3/src/text/TextExtras.m3 ./pkg/libm3/src/text/TextExtras.i3 ./pkg/libm3/FreeBSD4/.M3EXPORTS ./pkg/libm3/FreeBSD4/libm3.so.5 ./pkg/libm3/FreeBSD4/libm3.so ./pkg/libm3/FreeBSD4/libm3.a ./pkg/libm3/FreeBSD4/libm3.m3x ./pkg/libm3/FreeBSD4/.M3WEB ./pkg/libm3/FreeBSD4/AtomList.m3 ./pkg/libm3/FreeBSD4/AtomList.i3 ./pkg/libm3/FreeBSD4/IntList.i3 ./pkg/libm3/FreeBSD4/IntList.m3 ./pkg/libm3/FreeBSD4/RefList.m3 ./pkg/libm3/FreeBSD4/RefList.i3 ./pkg/libm3/FreeBSD4/TextList.i3 ./pkg/libm3/FreeBSD4/TextList.m3 ./pkg/libm3/FreeBSD4/AtomListSort.i3 ./pkg/libm3/FreeBSD4/AtomListSort.m3 ./pkg/libm3/FreeBSD4/IntListSort.m3 ./pkg/libm3/FreeBSD4/IntListSort.i3 ./pkg/libm3/FreeBSD4/RefListSort.i3 ./pkg/libm3/FreeBSD4/RefListSort.m3 ./pkg/libm3/FreeBSD4/TextListSort.m3 ./pkg/libm3/FreeBSD4/TextListSort.i3 ./pkg/libm3/FreeBSD4/AtomAtomTbl.m3 ./pkg/libm3/FreeBSD4/AtomAtomTbl.i3 ./pkg/libm3/FreeBSD4/AtomIntTbl.i3 ./pkg/libm3/FreeBSD4/AtomIntTbl.m3 ./pkg/libm3/FreeBSD4/AtomRefTbl.m3 ./pkg/libm3/FreeBSD4/AtomRefTbl.i3 ./pkg/libm3/FreeBSD4/AtomTextTbl.i3 ./pkg/libm3/FreeBSD4/AtomTextTbl.m3 ./pkg/libm3/FreeBSD4/IntAtomTbl.i3 ./pkg/libm3/FreeBSD4/IntAtomTbl.m3 ./pkg/libm3/FreeBSD4/IntIntTbl.i3 ./pkg/libm3/FreeBSD4/IntIntTbl.m3 ./pkg/libm3/FreeBSD4/IntRefTbl.i3 ./pkg/libm3/FreeBSD4/IntRefTbl.m3 ./pkg/libm3/FreeBSD4/IntTextTbl.i3 ./pkg/libm3/FreeBSD4/IntTextTbl.m3 ./pkg/libm3/FreeBSD4/RefAtomTbl.m3 ./pkg/libm3/FreeBSD4/RefAtomTbl.i3 ./pkg/libm3/FreeBSD4/RefIntTbl.i3 ./pkg/libm3/FreeBSD4/RefIntTbl.m3 ./pkg/libm3/FreeBSD4/RefRefTbl.i3 ./pkg/libm3/FreeBSD4/RefRefTbl.m3 ./pkg/libm3/FreeBSD4/RefTextTbl.i3 ./pkg/libm3/FreeBSD4/RefTextTbl.m3 ./pkg/libm3/FreeBSD4/TextAtomTbl.m3 ./pkg/libm3/FreeBSD4/TextAtomTbl.i3 ./pkg/libm3/FreeBSD4/TextIntTbl.i3 ./pkg/libm3/FreeBSD4/TextIntTbl.m3 ./pkg/libm3/FreeBSD4/TextRefTbl.i3 ./pkg/libm3/FreeBSD4/TextRefTbl.m3 ./pkg/libm3/FreeBSD4/TextTextTbl.i3 ./pkg/libm3/FreeBSD4/TextTextTbl.m3 ./pkg/libm3/FreeBSD4/SortedAtomAtomTbl.m3 ./pkg/libm3/FreeBSD4/SortedAtomAtomTbl.i3 ./pkg/libm3/FreeBSD4/SortedAtomIntTbl.i3 ./pkg/libm3/FreeBSD4/SortedAtomIntTbl.m3 ./pkg/libm3/FreeBSD4/SortedAtomRefTbl.i3 ./pkg/libm3/FreeBSD4/SortedAtomRefTbl.m3 ./pkg/libm3/FreeBSD4/SortedAtomTextTbl.i3 ./pkg/libm3/FreeBSD4/SortedAtomTextTbl.m3 ./pkg/libm3/FreeBSD4/SortedIntAtomTbl.m3 ./pkg/libm3/FreeBSD4/SortedIntAtomTbl.i3 ./pkg/libm3/FreeBSD4/SortedIntIntTbl.i3 ./pkg/libm3/FreeBSD4/SortedIntIntTbl.m3 ./pkg/libm3/FreeBSD4/SortedIntRefTbl.m3 ./pkg/libm3/FreeBSD4/SortedIntRefTbl.i3 ./pkg/libm3/FreeBSD4/SortedIntTextTbl.i3 ./pkg/libm3/FreeBSD4/SortedIntTextTbl.m3 ./pkg/libm3/FreeBSD4/SortedRefAtomTbl.i3 ./pkg/libm3/FreeBSD4/SortedRefAtomTbl.m3 ./pkg/libm3/FreeBSD4/SortedRefIntTbl.i3 ./pkg/libm3/FreeBSD4/SortedRefIntTbl.m3 ./pkg/libm3/FreeBSD4/SortedRefRefTbl.m3 ./pkg/libm3/FreeBSD4/SortedRefRefTbl.i3 ./pkg/libm3/FreeBSD4/SortedRefTextTbl.i3 ./pkg/libm3/FreeBSD4/SortedRefTextTbl.m3 ./pkg/libm3/FreeBSD4/SortedTextAtomTbl.m3 ./pkg/libm3/FreeBSD4/SortedTextAtomTbl.i3 ./pkg/libm3/FreeBSD4/SortedTextIntTbl.m3 ./pkg/libm3/FreeBSD4/SortedTextIntTbl.i3 ./pkg/libm3/FreeBSD4/SortedTextRefTbl.i3 ./pkg/libm3/FreeBSD4/SortedTextRefTbl.m3 ./pkg/libm3/FreeBSD4/SortedTextTextTbl.m3 ./pkg/libm3/FreeBSD4/SortedTextTextTbl.i3 ./pkg/libm3/FreeBSD4/IntArraySort.i3 ./pkg/libm3/FreeBSD4/IntArraySort.m3 ./pkg/libm3/FreeBSD4/TextArraySort.i3 ./pkg/libm3/FreeBSD4/TextArraySort.m3 ./pkg/libm3/FreeBSD4/AtomSeq.i3 ./pkg/libm3/FreeBSD4/AtomSeq.m3 ./pkg/libm3/FreeBSD4/AtomSeqRep.i3 ./pkg/libm3/FreeBSD4/IntSeq.m3 ./pkg/libm3/FreeBSD4/IntSeq.i3 ./pkg/libm3/FreeBSD4/IntSeqRep.i3 ./pkg/libm3/FreeBSD4/RefSeq.i3 ./pkg/libm3/FreeBSD4/RefSeq.m3 ./pkg/libm3/FreeBSD4/RefSeqRep.i3 ./pkg/libm3/FreeBSD4/TextSeq.m3 ./pkg/libm3/FreeBSD4/TextSeq.i3 ./pkg/libm3/FreeBSD4/TextSeqRep.i3 ./pkg/libm3/FreeBSD4/AtomPQ.i3 ./pkg/libm3/FreeBSD4/AtomPQ.m3 ./pkg/libm3/FreeBSD4/AtomPQRep.i3 ./pkg/libm3/FreeBSD4/IntPQ.m3 ./pkg/libm3/FreeBSD4/IntPQ.i3 ./pkg/libm3/FreeBSD4/IntPQRep.i3 ./pkg/libm3/FreeBSD4/RefPQ.i3 ./pkg/libm3/FreeBSD4/RefPQ.m3 ./pkg/libm3/FreeBSD4/RefPQRep.i3 ./pkg/libm3/FreeBSD4/TextPQ.i3 ./pkg/libm3/FreeBSD4/TextPQ.m3 ./pkg/libm3/FreeBSD4/TextPQRep.i3 ./pkg/libm3/FreeBSD4/RealFloatExtras.m3 ./pkg/libm3/FreeBSD4/RealFloatExtras.i3 ./pkg/libm3/FreeBSD4/LongFloatExtras.i3 ./pkg/libm3/FreeBSD4/LongFloatExtras.m3 ./pkg/libm3/FreeBSD4/RealSqrt.i3 ./pkg/libm3/FreeBSD4/RealSqrt.m3 ./pkg/libm3/FreeBSD4/LongSqrt.i3 ./pkg/libm3/FreeBSD4/LongSqrt.m3 ./pkg/libm3/FreeBSD4/M3Config.i3 ./pkg/libm3/FreeBSD4/PklActionSeq.m3 ./pkg/libm3/FreeBSD4/PklActionSeq.i3 ./pkg/libm3/FreeBSD4/PklActionSeqRep.i3 ./pkg/libm3/FreeBSD4/PackingTbl.i3 ./pkg/libm3/FreeBSD4/PackingTbl.m3 ./pkg/m3core/FreeBSD4/ ./pkg/m3core/src/ ./pkg/m3core/src/Csupport/ ./pkg/m3core/src/runtime/ ./pkg/m3core/src/thread/ ./pkg/m3core/src/unix/ ./pkg/m3core/src/C/ ./pkg/m3core/src/float/ ./pkg/m3core/src/time/ ./pkg/m3core/src/convert/ ./pkg/m3core/src/text/ ./pkg/m3core/src/fingerprint/ ./pkg/m3core/src/main/ ./pkg/m3core/src/weakref/ ./pkg/m3core/src/word/ ./pkg/m3core/src/word/GenWord.ig ./pkg/m3core/src/word/GenWord.mg ./pkg/m3core/src/word/WordRep.i3 ./pkg/m3core/src/word/Word.m3 ./pkg/m3core/src/word/Word.i3 ./pkg/m3core/src/word/LongRep.i3 ./pkg/m3core/src/word/Long.i3 ./pkg/m3core/src/word/Long.m3 ./pkg/m3core/src/weakref/WeakRef.i3 ./pkg/m3core/src/weakref/WeakRef.m3 ./pkg/m3core/src/main/Main.i3 ./pkg/m3core/src/fingerprint/Fingerprint.i3 ./pkg/m3core/src/fingerprint/Fingerprint.m3 ./pkg/m3core/src/fingerprint/Poly.i3 ./pkg/m3core/src/fingerprint/Poly.m3 ./pkg/m3core/src/fingerprint/PolyBasis.m3 ./pkg/m3core/src/fingerprint/PolyBasis.i3 ./pkg/m3core/src/text/String8.i3 ./pkg/m3core/src/text/String8.m3 ./pkg/m3core/src/text/String16.m3 ./pkg/m3core/src/text/String16.i3 ./pkg/m3core/src/text/Text.i3 ./pkg/m3core/src/text/Text.m3 ./pkg/m3core/src/text/TextClass.i3 ./pkg/m3core/src/text/TextClass.m3 ./pkg/m3core/src/text/TextLiteral.m3 ./pkg/m3core/src/text/TextLiteral.i3 ./pkg/m3core/src/text/Text8.i3 ./pkg/m3core/src/text/Text8.m3 ./pkg/m3core/src/text/Text8Short.i3 ./pkg/m3core/src/text/Text8Short.m3 ./pkg/m3core/src/text/Text8CString.i3 ./pkg/m3core/src/text/Text8CString.m3 ./pkg/m3core/src/text/Text16.m3 ./pkg/m3core/src/text/Text16.i3 ./pkg/m3core/src/text/Text16Short.i3 ./pkg/m3core/src/text/Text16Short.m3 ./pkg/m3core/src/text/TextSub.i3 ./pkg/m3core/src/text/TextSub.m3 ./pkg/m3core/src/text/TextCat.m3 ./pkg/m3core/src/text/TextCat.i3 ./pkg/m3core/src/text/TextConv.i3 ./pkg/m3core/src/text/TextConv.m3 ./pkg/m3core/src/convert/CConvert.i3 ./pkg/m3core/src/convert/CConvert.m3 ./pkg/m3core/src/convert/Convert.i3 ./pkg/m3core/src/convert/Convert.m3 ./pkg/m3core/src/time/Common/ ./pkg/m3core/src/time/Portable/ ./pkg/m3core/src/time/POSIX/ ./pkg/m3core/src/time/POSIX/DateBsd.m3 ./pkg/m3core/src/time/POSIX/TimePosix.m3 ./pkg/m3core/src/time/POSIX/TimePosix.i3 ./pkg/m3core/src/time/Portable/TickPortable.m3 ./pkg/m3core/src/time/Common/Time.i3 ./pkg/m3core/src/time/Common/Tick.i3 ./pkg/m3core/src/time/Common/Date.i3 ./pkg/m3core/src/time/Common/FmtTime.i3 ./pkg/m3core/src/time/Common/FmtTime.m3 ./pkg/m3core/src/float/Common/ ./pkg/m3core/src/float/IEEE/ ./pkg/m3core/src/float/IEEE-le/ ./pkg/m3core/src/float/IEEE-default/ ./pkg/m3core/src/float/IEEE-default/FPU.i3 ./pkg/m3core/src/float/IEEE-default/FPU.m3 ./pkg/m3core/src/float/IEEE-default/FloatMode.i3 ./pkg/m3core/src/float/IEEE-default/FloatMode.m3 ./pkg/m3core/src/float/IEEE-le/RealRep.i3 ./pkg/m3core/src/float/IEEE-le/LongRealRep.i3 ./pkg/m3core/src/float/IEEE/RealFloat.m3 ./pkg/m3core/src/float/IEEE/LongFloat.m3 ./pkg/m3core/src/float/IEEE/ExtendedFloat.m3 ./pkg/m3core/src/float/IEEE/Real.i3 ./pkg/m3core/src/float/IEEE/LongReal.i3 ./pkg/m3core/src/float/IEEE/Extended.i3 ./pkg/m3core/src/float/Common/Float.ig ./pkg/m3core/src/float/Common/RealFloat.i3 ./pkg/m3core/src/float/Common/LongFloat.i3 ./pkg/m3core/src/float/Common/ExtendedFloat.i3 ./pkg/m3core/src/float/Common/IEEESpecial.m3 ./pkg/m3core/src/float/Common/IEEESpecial.i3 ./pkg/m3core/src/float/Common/Real.m3 ./pkg/m3core/src/float/Common/LongReal.m3 ./pkg/m3core/src/float/Common/Extended.m3 ./pkg/m3core/src/float/Common/DragonInt.i3 ./pkg/m3core/src/float/Common/DragonInt.m3 ./pkg/m3core/src/float/Common/DragonT.m3 ./pkg/m3core/src/float/Common/DragonT.i3 ./pkg/m3core/src/C/Common/ ./pkg/m3core/src/C/FreeBSD4/ ./pkg/m3core/src/C/32BITS/ ./pkg/m3core/src/C/32BITS/BasicCtypes.i3 ./pkg/m3core/src/C/FreeBSD4/Csetjmp.i3 ./pkg/m3core/src/C/FreeBSD4/Csignal.i3 ./pkg/m3core/src/C/FreeBSD4/Cstring.i3 ./pkg/m3core/src/C/FreeBSD4/Cstdio.i3 ./pkg/m3core/src/C/FreeBSD4/Cstdio.m3 ./pkg/m3core/src/C/FreeBSD4/CstdioC.c ./pkg/m3core/src/C/Common/Cerrno.i3 ./pkg/m3core/src/C/Common/Cstddef.i3 ./pkg/m3core/src/C/Common/Cstdlib.i3 ./pkg/m3core/src/C/Common/Ctypes.i3 ./pkg/m3core/src/C/Common/M3toC.i3 ./pkg/m3core/src/C/Common/M3toC.m3 ./pkg/m3core/src/C/Common/Cstdarg.m3 ./pkg/m3core/src/C/Common/Cstdarg.i3 ./pkg/m3core/src/C/Common/CerrnoC.c ./pkg/m3core/src/unix/freebsd-4/ ./pkg/m3core/src/unix/freebsd-4/Udir.i3 ./pkg/m3core/src/unix/freebsd-4/Uerror.i3 ./pkg/m3core/src/unix/freebsd-4/Uexec.i3 ./pkg/m3core/src/unix/freebsd-4/Ugrp.i3 ./pkg/m3core/src/unix/freebsd-4/Uin.i3 ./pkg/m3core/src/unix/freebsd-4/Uin.m3 ./pkg/m3core/src/unix/freebsd-4/Uipc.i3 ./pkg/m3core/src/unix/freebsd-4/Umman.i3 ./pkg/m3core/src/unix/freebsd-4/Umsg.m3 ./pkg/m3core/src/unix/freebsd-4/Umsg.i3 ./pkg/m3core/src/unix/freebsd-4/Unetdb.i3 ./pkg/m3core/src/unix/freebsd-4/Unetdb.m3 ./pkg/m3core/src/unix/freebsd-4/Unix.i3 ./pkg/m3core/src/unix/freebsd-4/Uprocess.i3 ./pkg/m3core/src/unix/freebsd-4/Upwd.i3 ./pkg/m3core/src/unix/freebsd-4/Uresource.i3 ./pkg/m3core/src/unix/freebsd-4/Usem.i3 ./pkg/m3core/src/unix/freebsd-4/Ushm.i3 ./pkg/m3core/src/unix/freebsd-4/Usignal.i3 ./pkg/m3core/src/unix/freebsd-4/Usignal.m3 ./pkg/m3core/src/unix/freebsd-4/Ustat.i3 ./pkg/m3core/src/unix/freebsd-4/Usocket.i3 ./pkg/m3core/src/unix/freebsd-4/Usyslog.i3 ./pkg/m3core/src/unix/freebsd-4/Utime.i3 ./pkg/m3core/src/unix/freebsd-4/Utypes.i3 ./pkg/m3core/src/unix/freebsd-4/Utypes.m3 ./pkg/m3core/src/unix/freebsd-4/Uugid.i3 ./pkg/m3core/src/unix/freebsd-4/Uuio.i3 ./pkg/m3core/src/unix/freebsd-4/Uutmp.i3 ./pkg/m3core/src/unix/freebsd-4/Uutsname.i3 ./pkg/m3core/src/thread/Common/ ./pkg/m3core/src/thread/POSIX/ ./pkg/m3core/src/thread/POSIX/SchedulerPosix.i3 ./pkg/m3core/src/thread/POSIX/ThreadF.i3 ./pkg/m3core/src/thread/POSIX/ThreadPosix.m3 ./pkg/m3core/src/thread/Common/Thread.i3 ./pkg/m3core/src/thread/Common/Scheduler.i3 ./pkg/m3core/src/thread/Common/MutexRep.i3 ./pkg/m3core/src/thread/Common/ThreadEvent.i3 ./pkg/m3core/src/runtime/common/ ./pkg/m3core/src/runtime/POSIX/ ./pkg/m3core/src/runtime/FreeBSD4/ ./pkg/m3core/src/runtime/ex_frame/ ./pkg/m3core/src/runtime/ex_frame/RTExFrame.i3 ./pkg/m3core/src/runtime/ex_frame/RTExFrame.m3 ./pkg/m3core/src/runtime/ex_frame/RTStackC.c ./pkg/m3core/src/runtime/FreeBSD4/RTSignal.m3 ./pkg/m3core/src/runtime/FreeBSD4/RTThread.m3 ./pkg/m3core/src/runtime/FreeBSD4/RTMachine.i3 ./pkg/m3core/src/runtime/FreeBSD4/RTThreadC.c ./pkg/m3core/src/runtime/FreeBSD4/_fpsetjmp.s ./pkg/m3core/src/runtime/POSIX/RTArgs.m3 ./pkg/m3core/src/runtime/POSIX/RTOS.m3 ./pkg/m3core/src/runtime/POSIX/RTPerfTool.m3 ./pkg/m3core/src/runtime/POSIX/RTPerfTool.i3 ./pkg/m3core/src/runtime/POSIX/RTProcessPosix.m3 ./pkg/m3core/src/runtime/POSIX/RTThread.i3 ./pkg/m3core/src/runtime/POSIX/RTThreadStk.m3 ./pkg/m3core/src/runtime/common/RTHooks.i3 ./pkg/m3core/src/runtime/common/RTHooks.m3 ./pkg/m3core/src/runtime/common/RT0.m3 ./pkg/m3core/src/runtime/common/RT0.i3 ./pkg/m3core/src/runtime/common/RuntimeError.i3 ./pkg/m3core/src/runtime/common/RuntimeError.m3 ./pkg/m3core/src/runtime/common/Compiler.m3 ./pkg/m3core/src/runtime/common/RTAllocator.i3 ./pkg/m3core/src/runtime/common/RTAllocator.m3 ./pkg/m3core/src/runtime/common/RTAllocCnts.i3 ./pkg/m3core/src/runtime/common/RTAllocStats.i3 ./pkg/m3core/src/runtime/common/RTAllocStats.m3 ./pkg/m3core/src/runtime/common/RTHeap.i3 ./pkg/m3core/src/runtime/common/RTHeap.m3 ./pkg/m3core/src/runtime/common/RTHeapInfo.i3 ./pkg/m3core/src/runtime/common/RTHeapInfo.m3 ./pkg/m3core/src/runtime/common/RTHeapMap.m3 ./pkg/m3core/src/runtime/common/RTHeapMap.i3 ./pkg/m3core/src/runtime/common/RTHeapRep.i3 ./pkg/m3core/src/runtime/common/RTHeapRep.m3 ./pkg/m3core/src/runtime/common/RTHeapStats.i3 ./pkg/m3core/src/runtime/common/RTIO.i3 ./pkg/m3core/src/runtime/common/RTHeapStats.m3 ./pkg/m3core/src/runtime/common/RTCollector.m3 ./pkg/m3core/src/runtime/common/RTCollector.i3 ./pkg/m3core/src/runtime/common/RTCollectorSRC.i3 ./pkg/m3core/src/runtime/common/RTWeakRef.i3 ./pkg/m3core/src/runtime/common/RTIO.m3 ./pkg/m3core/src/runtime/common/RTLinkerX.i3 ./pkg/m3core/src/runtime/common/RTLinker.m3 ./pkg/m3core/src/runtime/common/RTLinker.i3 ./pkg/m3core/src/runtime/common/RTDebug.i3 ./pkg/m3core/src/runtime/common/RTDebug.m3 ./pkg/m3core/src/runtime/common/RTError.i3 ./pkg/m3core/src/runtime/common/RTError.m3 ./pkg/m3core/src/runtime/common/RTException.m3 ./pkg/m3core/src/runtime/common/RTException.i3 ./pkg/m3core/src/runtime/common/RTMapOp.i3 ./pkg/m3core/src/runtime/common/RTMapOp.m3 ./pkg/m3core/src/runtime/common/RTMisc.i3 ./pkg/m3core/src/runtime/common/RTMisc.m3 ./pkg/m3core/src/runtime/common/RTModule.i3 ./pkg/m3core/src/runtime/common/RTPacking.m3 ./pkg/m3core/src/runtime/common/RTPacking.i3 ./pkg/m3core/src/runtime/common/RTParams.i3 ./pkg/m3core/src/runtime/common/RTParams.m3 ./pkg/m3core/src/runtime/common/RTProcedure.i3 ./pkg/m3core/src/runtime/common/RTProcedure.m3 ./pkg/m3core/src/runtime/common/RTProcess.i3 ./pkg/m3core/src/runtime/common/RTProcess.m3 ./pkg/m3core/src/runtime/common/RTTipe.m3 ./pkg/m3core/src/runtime/common/RTTipe.i3 ./pkg/m3core/src/runtime/common/RTType.i3 ./pkg/m3core/src/runtime/common/RTType.m3 ./pkg/m3core/src/runtime/common/RTTypeFP.i3 ./pkg/m3core/src/runtime/common/RTTypeFP.m3 ./pkg/m3core/src/runtime/common/RTTypeMap.i3 ./pkg/m3core/src/runtime/common/RTTypeMap.m3 ./pkg/m3core/src/runtime/common/RTutils.m3 ./pkg/m3core/src/runtime/common/RTutils.i3 ./pkg/m3core/src/runtime/common/RTHeapDebug.i3 ./pkg/m3core/src/runtime/common/RTHeapDebug.m3 ./pkg/m3core/src/runtime/common/RTArgs.i3 ./pkg/m3core/src/runtime/common/RTHeapEvent.i3 ./pkg/m3core/src/runtime/common/RTProcedureSRC.i3 ./pkg/m3core/src/runtime/common/RTSignal.i3 ./pkg/m3core/src/runtime/common/RTStack.i3 ./pkg/m3core/src/runtime/common/RTTypeSRC.i3 ./pkg/m3core/src/runtime/common/RTOS.i3 ./pkg/m3core/src/Csupport/Common/ ./pkg/m3core/src/Csupport/FreeBSD4/ ./pkg/m3core/src/Csupport/FreeBSD4/dtoa.c ./pkg/m3core/src/Csupport/Common/dtoa.h ./pkg/m3core/src/Csupport/Common/hand.c ./pkg/m3core/FreeBSD4/.M3EXPORTS ./pkg/m3core/FreeBSD4/libm3core.so.5 ./pkg/m3core/FreeBSD4/libm3core.so ./pkg/m3core/FreeBSD4/libm3core.a ./pkg/m3core/FreeBSD4/libm3core.m3x ./pkg/m3core/FreeBSD4/.M3WEB ./pkg/m3core/FreeBSD4/Compiler.i3 ./lib/libm3core.so.5 ./lib/libm3core.so ./lib/libm3.so.5 ./lib/libm3.so ./bin/cm3 ./bin/cm3cg ./bin/cm3.cfg ./bin/cm3.cfg--default -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Dec 18 23:51:45 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 18 Dec 2007 17:51:45 -0500 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/darwin In-Reply-To: <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> <28256359-D312-4D47-9A38-7A245D6AEAE5@cs.purdue.edu> <20071216233259.ukim9ntk6cw8gsgc@mail.elegosoft.com> <723A4C34-1B58-4F26-891C-45F764CAEEB5@cs.purdue.edu> <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> Message-ID: <1430B28B-A256-4B74-877D-9533183DFA42@cs.purdue.edu> I have put installation archives for I386_DARWIN and PPC_DARWIN at ftp://ftp.cs.purdue.edu/pub/hosking/m3. On Dec 17, 2007, at 6:03 AM, Olaf Wagner wrote: > Quoting Tony Hosking : >> A break is always good. :-) > > Hi again, > > after some hours of sleep I can report at least some success on > my old Darwin installation. I've put the archives on our web server > for public access, and would like to add some more. > > I still think a Darwin build on a newer system may be a good idea (we > can offer both on our web pages), and we definitely need some > for Linux (perhaps multiple distros, too, there?) > Solaris and Darwin/i386 would be great, too, and NetBSD, and of > course Windows. Mika offered to provide an archive for old FreeBSD > distributions (4.x). > > So everybody who is willing to produce some installation archives, > please let me know, and I'll make sure they get shipped to our > server. > > Please note that for the scripts/make-bin-dist-min.sh to work, > you need a sample configuration file in cm3/m3-sys/cm3/src/config/XXX, > as the ones in cminstall/src/config must be processed by the installer > first. Jay has removed the samples there a little bit too eagerly, > but most where outdated anyway. > > To upgrade from an older compiler I have successfully used the > upgrade.sh script. So the complete sequence to build a bootstrap > on your favourite platform would be: > > 1. Check out the current CVS head > 2. Copy your (working) configuration file to cm3/src/config/ > 3. Adapt the installer configuration file if necessary in > cminstall/src/config/. Make sure that all system libraries > get dynamically linked, for instance. > 4. scripts/upgrade.sh > 5. scripts/make-bin-dist-min.sh > > Any help will be appreciated. > > 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 hosking at cs.purdue.edu Wed Dec 19 00:23:49 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 18 Dec 2007 18:23:49 -0500 Subject: [M3devel] Unix signals and Modula-3... In-Reply-To: <200712181238.lBICcL8s052879@camembert.async.caltech.edu> References: <200712181238.lBICcL8s052879@camembert.async.caltech.edu> Message-ID: <92B67E8E-DB72-4436-A096-564DFF214D4D@cs.purdue.edu> I'm assuming that waitpid hanging when using system threads is not a problem, since the system thread scheduler will schedule other threads around the waiting one. The issue is only for the user-level threads implementation where a thread blocking on a waitpid call would prevent other threads being scheduled. On Dec 18, 2007, at 7:38 AM, Mika Nystrom wrote: > Hello everyone, > > I am in the process of bootstrapping the CVS head of CM3 on an old > FreeBSD-4.11 system, and at one point, when I replaced the old cm3 > with the new cm3, the compiler got slower. Not a little bit slower, > mind you, but about 10x slower. I remember pointing this out to > the m3devel list... oh it must have been three or four years ago; > one of our grad students at Caltech (Karl Papadantonakis, also > author of the caltech-parser) was the first to notice what was going > on. > > It has to do with Process.Wait. (From ProcessPosix.m3.) To repeat > what I said a few years ago, the problem lies here: > > CONST Delay = 0.1D0; > BEGIN > IF NOT p.waitOk THEN RAISE WaitAlreadyCalled END; > p.waitOk := FALSE; > (* By rights, the SchedulerPosix interface should have a WaitPID > procedure that is integrated with the thread scheduler. *) > LOOP > result := Uexec.waitpid(p.pid, ADR(statusT), Uexec.WNOHANG); > IF result # 0 THEN EXIT END; > Thread.Pause(Delay) > END; > <* ASSERT result > 0 *> > > In other words: if Process.Wait is called before the child process > is done, then the thread pauses 0.1 seconds. > > In our local version of m3build, we duplicate the Wait code and set > the Delay to 0.0. That's OK in a compiler, but it's not OK in > general, because you would chew up the CPU on a machine that was > doing a lot of long-term waiting. > > The problem is that the fix that I suggested way back when requires > messing with Unix signals (catching SIGC[H]LD instead of using > waitpid), which is why I never submitted a fix to the repository, > because I am not sure what such a fix might interact with. It seems > to me that the correct way of dealing with Unix signals is to have > a single thread that talks to the Unix system, registers signal > handlers, and takes care, via some object-oriented mechanism, of > calling back any M3 threads that are interested in the signals. > Would such a thing be possible? Where are signals used in the > system today? > > Mika From mika at async.caltech.edu Wed Dec 19 00:43:19 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 18 Dec 2007 15:43:19 -0800 Subject: [M3devel] Unix signals and Modula-3... In-Reply-To: Your message of "Tue, 18 Dec 2007 18:23:49 EST." <92B67E8E-DB72-4436-A096-564DFF214D4D@cs.purdue.edu> Message-ID: <200712182343.lBINhJDL084804@camembert.async.caltech.edu> Ah yes, you are right. The original issue is that waitpid would hang the whole runtime and that should not happen with system threads. If using system threads, waitpid should be called with a third argument of zero, I believe. Is this already happening? If not, make the change and if you have a fast machine you may see a spectacular speedup in your compile times. I suppose the easiest solution to this problem is simply to move all active targets to system threads... Still, there are some other areas where Unix signals might be of interest. I am thinking of things like interfacing with readline and other C-based libraries that use signals for concurrency. When I put a readline interface on some Modula-3 programs, I wound up using an external C program to do readline processing and then communicating over a pipe or TCP connection, because dealing with signals seemed like such a hassle. Mika Tony Hosking writes: >I'm assuming that waitpid hanging when using system threads is not a >problem, since the system thread scheduler will schedule other >threads around the waiting one. The issue is only for the user-level >threads implementation where a thread blocking on a waitpid call >would prevent other threads being scheduled. > >On Dec 18, 2007, at 7:38 AM, Mika Nystrom wrote: > >> Hello everyone, >> >> I am in the process of bootstrapping the CVS head of CM3 on an old >> FreeBSD-4.11 system, and at one point, when I replaced the old cm3 >> with the new cm3, the compiler got slower. Not a little bit slower, >> mind you, but about 10x slower. I remember pointing this out to >> the m3devel list... oh it must have been three or four years ago; >> one of our grad students at Caltech (Karl Papadantonakis, also >> author of the caltech-parser) was the first to notice what was going >> on. >> >> It has to do with Process.Wait. (From ProcessPosix.m3.) To repeat >> what I said a few years ago, the problem lies here: >> >> CONST Delay = 0.1D0; >> BEGIN >> IF NOT p.waitOk THEN RAISE WaitAlreadyCalled END; >> p.waitOk := FALSE; >> (* By rights, the SchedulerPosix interface should have a WaitPID >> procedure that is integrated with the thread scheduler. *) >> LOOP >> result := Uexec.waitpid(p.pid, ADR(statusT), Uexec.WNOHANG); >> IF result # 0 THEN EXIT END; >> Thread.Pause(Delay) >> END; >> <* ASSERT result > 0 *> >> >> In other words: if Process.Wait is called before the child process >> is done, then the thread pauses 0.1 seconds. >> >> In our local version of m3build, we duplicate the Wait code and set >> the Delay to 0.0. That's OK in a compiler, but it's not OK in >> general, because you would chew up the CPU on a machine that was >> doing a lot of long-term waiting. >> >> The problem is that the fix that I suggested way back when requires >> messing with Unix signals (catching SIGC[H]LD instead of using >> waitpid), which is why I never submitted a fix to the repository, >> because I am not sure what such a fix might interact with. It seems >> to me that the correct way of dealing with Unix signals is to have >> a single thread that talks to the Unix system, registers signal >> handlers, and takes care, via some object-oriented mechanism, of >> calling back any M3 threads that are interested in the signals. >> Would such a thing be possible? Where are signals used in the >> system today? >> >> Mika From wagner at elegosoft.com Wed Dec 19 00:44:06 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 19 Dec 2007 00:44:06 +0100 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/darwin In-Reply-To: <1430B28B-A256-4B74-877D-9533183DFA42@cs.purdue.edu> References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> <28256359-D312-4D47-9A38-7A245D6AEAE5@cs.purdue.edu> <20071216233259.ukim9ntk6cw8gsgc@mail.elegosoft.com> <723A4C34-1B58-4F26-891C-45F764CAEEB5@cs.purdue.edu> <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> <1430B28B-A256-4B74-877D-9533183DFA42@cs.purdue.edu> Message-ID: <20071219004406.mnemi5gnc4g4c80g@mail.elegosoft.com> Quoting Tony Hosking : > I have put installation archives for I386_DARWIN and PPC_DARWIN at > ftp://ftp.cs.purdue.edu/pub/hosking/m3. Great. I've shipped all the archives available so far to our web server at http://modula3.elegosoft.com/cm3/. I'm not sure if all the information on the download page is correct, and I'm sure the documentation and instructions provided are rather sparse. If anybody wants to improve that, please don't hesitate to edit cm3/www/download.html; I can then later ship the changes. Now it's time for bed again; thanks for all the help, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Wed Dec 19 01:03:46 2007 From: jayk123 at hotmail.com (Jay) Date: Wed, 19 Dec 2007 00:03:46 +0000 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/ In-Reply-To: <20071219004406.mnemi5gnc4g4c80g@mail.elegosoft.com> References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> <28256359-D312-4D47-9A38-7A245D6AEAE5@cs.purdue.edu> <20071216233259.ukim9ntk6cw8gsgc@mail.elegosoft.com> <723A4C34-1B58-4F26-891C-45F764CAEEB5@cs.purdue.edu> <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> <1430B28B-A256-4B74-877D-9533183DFA42@cs.purdue.edu> <20071219004406.mnemi5gnc4g4c80g@mail.elegosoft.com> Message-ID: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/~checkout~/cm3/www/installation-windows.html?rev=1.2;content-type=text%2Fhtml ?? Perhaps now that 5.5.0 bootstraps are available, the 5.2.6 instructions should be moved out. I'm also aware that the style is rather poor, and that I should have tried harder to integrate it into the existing document, and that I suck, etc..It is not linked to from download.html. Does anyone else think the formating is a little off regarding how the Windows distribution is two files right next to each other? The archives could of course be merged. Current linkers will not put symbols into files, but older ones will.. given their relative large size and small use though, separate symbols like this seems ok. Oh someone beat me to OS X 10.4 PowerPC. Maybe I should try 10.2? :) - Jay > Date: Wed, 19 Dec 2007 00:44:06 +0100> From: wagner at elegosoft.com> To: hosking at cs.purdue.edu; m3devel at elegosoft.com> CC: m3-support at elegosoft.com; admins at elegosoft.com> Subject: Re: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/darwin> > Quoting Tony Hosking :> > > I have put installation archives for I386_DARWIN and PPC_DARWIN at> > ftp://ftp.cs.purdue.edu/pub/hosking/m3.> > Great. I've shipped all the archives available so far to our> web server at http://modula3.elegosoft.com/cm3/.> > I'm not sure if all the information on the download> page is correct, and I'm sure the documentation and instructions> provided are rather sparse. If anybody wants to improve that,> please don't hesitate to edit cm3/www/download.html; I can then> later ship the changes.> > Now it's time for bed again; thanks for all the help,> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. http://www.xbox.com/en-US/hardware/wheretobuy/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Thu Dec 20 04:22:04 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 19 Dec 2007 19:22:04 -0800 Subject: [M3devel] Unix signals and Modula-3... In-Reply-To: Your message of "Tue, 18 Dec 2007 22:30:01 EST." Message-ID: <200712200322.lBK3M4xS055247@camembert.async.caltech.edu> Tony Hosking writes: >The system threads pthread implementation uses a signal and a >semaphore to stop/start threads for GC, Other than that, I don't >believe signals are being used anywhere else in the run-time system. > >Also, I should point out that there may be value in retaining the >current user-level threads implementation for all targets (we still >need to fix some to use setcontext/getcontext instead of setjmp/ >getjmp), in which case the same issue applies. I wonder if it makes >sense to implement a variant of waitpid inside the threads >implementation to do the right thing. We could use a signal there to >catch SIGCHLD appropriately in the ThreadPosix implementation and >leave it alone with ThreadPThread. > >What do you think? Oh, yes I wasn't suggesting dropping the user-level threads. I was just thinking that if most targets can use system threads, maybe it's OK if there's a 0.1 second delay on the others. After all, most people don't seem to have noticed that it's been this way all these years :) (Although it does get more obvious now that computers are faster and compile times aren't getting shorter on those targets.) I also think user-level threads can turn out to be important when system threads perform poorly for whatever reason. I know this was a big problem for some people I knew who were working with threads in Java, that when they used system threads for code that did very little work and lots of threadswitching, user-level threads were an order of magnitude faster. I suppose that ThreadPosix also uses signals to know when to switch contexts? Since it already deals with signals it shouldn't be too difficult to incorporate the waitpid business. But yes, it seems to me that since the implementation of Process.Wait's waiting for the child to exit depends on what kind of threading library is being used, that part of it ought/could conveniently be part of the threading library's interface. Mika From mika at async.caltech.edu Fri Dec 21 05:42:04 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 20 Dec 2007 20:42:04 -0800 Subject: [M3devel] Missing packages? Message-ID: <200712210442.lBL4g4kK011539@camembert.async.caltech.edu> Hi Modula-3 people. I was working on some code the other night and needed a small persistent table data structure, and I seemed to remember that there was a package called "stabletable" that had exactly the features I needed: a simple, persistent implementation of the Modula-3 generic tables. Only problem was ... I couldn't find it anywhere! I remembered it existed, but nowhere to be found. Well, I finally tracked it down on an m3browser running at the University of Tampere (Finland), cut-and-pasted the .ig and .mg and compiled the thing. A few questions: 1. This package is dated 1994. Is this after CM3 split from SRC M3? Is that why it's not in CM3? 2. Should I add it to CM3? 3. Are there other packages of similar status? Mika From jayk123 at hotmail.com Fri Dec 21 07:28:39 2007 From: jayk123 at hotmail.com (Jay) Date: Fri, 21 Dec 2007 06:28:39 +0000 Subject: [M3devel] Missing packages? In-Reply-To: <200712210442.lBL4g4kK011539@camembert.async.caltech.edu> References: <200712210442.lBL4g4kK011539@camembert.async.caltech.edu> Message-ID: DEC SRC M3 3.6 was released circa 1996, maybe 1995. m3-db\stable ?m3-db\stablegen (related) ? C:\dev2\cm3\doc\help\bib.html(578):
  • Allan Heydon,C:\dev2\cm3\doc\help\bib.html(579):Stabletable: An Example Client of the SmallDB Interface,C:\dev2\cm3\doc\help\bib.html(597):gzipped tar archive I think this is it. The links are dead. I have some/all of the 3.6 release archives if needed (a hard drive is in questionable state, but I definitely have boot-linuxelf and m3.tar.bz2, m3cc.tar.bz2 (I "recode" all .gzs as smaller .bz2...)) - Jay > To: m3devel at elegosoft.com> Date: Thu, 20 Dec 2007 20:42:04 -0800> From: mika at async.caltech.edu> Subject: [M3devel] Missing packages?> > Hi Modula-3 people.> > I was working on some code the other night and needed a small> persistent table data structure, and I seemed to remember that there> was a package called "stabletable" that had exactly the features I> needed: a simple, persistent implementation of the Modula-3 generic> tables.> > Only problem was ... I couldn't find it anywhere! I remembered it existed,> but nowhere to be found. Well, I finally tracked it down on an m3browser> running at the University of Tampere (Finland), cut-and-pasted the .ig and> .mg and compiled the thing.> > A few questions:> > 1. This package is dated 1994. Is this after CM3 split from SRC M3? Is> that why it's not in CM3?> 2. Should I add it to CM3?> 3. Are there other packages of similar status?> > Mika _________________________________________________________________ i?m is proud to present Cause Effect, a series about real people making a difference. http://im.live.com/Messenger/IM/MTV/?source=text_Cause_Effect -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Dec 21 09:51:02 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 21 Dec 2007 09:51:02 +0100 Subject: [M3devel] Missing packages? In-Reply-To: <200712210442.lBL4g4kK011539@camembert.async.caltech.edu> References: <200712210442.lBL4g4kK011539@camembert.async.caltech.edu> Message-ID: <20071221095102.0zpsxh3s2s44cs4g@mail.elegosoft.com> Quoting Mika Nystrom : > Hi Modula-3 people. > > I was working on some code the other night and needed a small > persistent table data structure, and I seemed to remember that there > was a package called "stabletable" that had exactly the features I > needed: a simple, persistent implementation of the Modula-3 generic > tables. > > Only problem was ... I couldn't find it anywhere! I remembered it existed, > but nowhere to be found. Well, I finally tracked it down on an m3browser > running at the University of Tampere (Finland), cut-and-pasted the .ig and > .mg and compiled the thing. Well, there is stable and stablegen, as Jay already pointed out. These can be used to generate persistent versions of almost any data structure. > A few questions: > > 1. This package is dated 1994. Is this after CM3 split from SRC M3? Is > that why it's not in CM3? stabletable may have been an predecessor of the more general stable package. I also found the attached documentation, which seems to be missing on our web site. I rather think that Critical Mass people have cleaned up the set of packages a bit. > 2. Should I add it to CM3? If you think it is useful in addition to stable and stablegen, there's no reason why not to add it. Put it into m3-db. If it's more or less code duplication, don't do it. > 3. Are there other packages of similar status? I cannot answer this question. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Fri Dec 21 13:22:40 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 21 Dec 2007 13:22:40 +0100 Subject: [M3devel] endless exception loop on FreeBSD Message-ID: <20071221132240.uu5elpnqwwc4408s@mail.elegosoft.com> I'm trying to add pthread support to the FreeBSD4 platform. My first tentative additions now lead to endless exception loops once any error is encountered until the stack overflows. Does anybody know what's wrong here? I'm not aware that I have changed anything in this area. [...] #9 0x081dfe96 in RTHooks__Raise (M3_AJWxb1_ex=0x8272840, M3_AJWxb1_arg=0x1d, M3_AJWxb1_module=0x8273080, M3_AcxOUs_line=14) at RTHooks.m3:79 #10 0x081e00df in RuntimeError () at RuntimeError.m3:14 #11 0x081ef680 in RTException__DefaultBackstop (M3_Cblw37_a=0xbfbfe1a0, M3_AicXUJ_raises=0 '\0') at RTException.m3:33 #12 0x081ef654 in RTException__InvokeBackstop (M3_Cblw37_a=0xbfbfe1a0, M3_AicXUJ_raises=0 '\0') at RTException.m3:25 #13 0x081f903f in RTException__Raise (M3_Cblw37_act=0xbfbfe1a0) at RTExFrame.m3:29 #14 0x081dfe96 in RTHooks__Raise (M3_AJWxb1_ex=0x8267b00, M3_AJWxb1_arg=0x2839385c, M3_AJWxb1_module=0x8268480, M3_AcxOUs_line=50) at RTHooks.m3:79 #15 0x081b9dbe in OSErrorPosix__Raise0 (M3_AcxOUs_errno=2) ---Type to continue, or q to quit--- at OSErrorPosix.m3:50 #16 0x081bb0c4 in FSPosix__Fail (M3_Bd56fi_p=0x82276c0, M3_DIYzyQ_f=0x82276c8) at FSPosix.m3:356 #17 0x081bade2 in FS__Status (M3_Bd56fi_pn=0x82276c0, M3_CQo0YO__result=0xbfbfe318) at FSPosix.m3:323 #18 0x081aa2e4 in M3File__IsReadable (M3_Bd56fi_path=0x82276c0) at M3File.m3:182 #19 0x08088a3e in MxConfig__TryConfig (M3_Bd56fi_a=0x82276c0, M3_Bd56fi_b=0x0, M3_Bd56fi_c=0x0) at MxConfig.m3:94 #20 0x08088635 in MxConfig__FindConfig () at MxConfig.m3:43 #21 0x0808841b in MxConfig__FindFile () at MxConfig.m3:17 #22 0x0807301d in Main__DoIt () at Main.m3:31 #23 0x080739bc in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:193 #24 0x081ee9a2 in RTLinker__RunMainBody (M3_DjPxE3_m=0x8223860) at RTLinker.m3:399 #25 0x081edecd in RTLinker__AddUnitI (M3_DjPxE3_m=0x8223860) at RTLinker.m3:113 #26 0x081edf54 in RTLinker__AddUnit (M3_DjPxE5_b=0x80739a7) at RTLinker.m3:122 #27 0x08049b99 in main (argc=1, argv=0xbfbfe5f4, envp=0xbfbfe5fc) at _m3main.mc:4 -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Fri Dec 21 17:04:30 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 21 Dec 2007 11:04:30 -0500 Subject: [M3devel] endless exception loop on FreeBSD In-Reply-To: <20071221132240.uu5elpnqwwc4408s@mail.elegosoft.com> References: <20071221132240.uu5elpnqwwc4408s@mail.elegosoft.com> Message-ID: <592A55CF-8680-499A-9911-F461B7562879@cs.purdue.edu> Hmm. It doesn't ring any bells for me. On Dec 21, 2007, at 7:22 AM, Olaf Wagner wrote: > I'm trying to add pthread support to the FreeBSD4 platform. > My first tentative additions now lead to endless exception loops > once any error is encountered until the stack overflows. > > Does anybody know what's wrong here? I'm not aware that I have > changed anything in this area. > > [...] > #9 0x081dfe96 in RTHooks__Raise (M3_AJWxb1_ex=0x8272840, > M3_AJWxb1_arg=0x1d, > M3_AJWxb1_module=0x8273080, M3_AcxOUs_line=14) at RTHooks.m3:79 > #10 0x081e00df in RuntimeError () at RuntimeError.m3:14 > #11 0x081ef680 in RTException__DefaultBackstop > (M3_Cblw37_a=0xbfbfe1a0, > M3_AicXUJ_raises=0 '\0') at RTException.m3:33 > #12 0x081ef654 in RTException__InvokeBackstop (M3_Cblw37_a=0xbfbfe1a0, > M3_AicXUJ_raises=0 '\0') at RTException.m3:25 > #13 0x081f903f in RTException__Raise (M3_Cblw37_act=0xbfbfe1a0) > at RTExFrame.m3:29 > #14 0x081dfe96 in RTHooks__Raise (M3_AJWxb1_ex=0x8267b00, > M3_AJWxb1_arg=0x2839385c, M3_AJWxb1_module=0x8268480, > M3_AcxOUs_line=50) > at RTHooks.m3:79 > #15 0x081b9dbe in OSErrorPosix__Raise0 (M3_AcxOUs_errno=2) > ---Type to continue, or q to quit--- > at OSErrorPosix.m3:50 > #16 0x081bb0c4 in FSPosix__Fail (M3_Bd56fi_p=0x82276c0, > M3_DIYzyQ_f=0x82276c8) > at FSPosix.m3:356 > #17 0x081bade2 in FS__Status (M3_Bd56fi_pn=0x82276c0, > M3_CQo0YO__result=0xbfbfe318) at FSPosix.m3:323 > #18 0x081aa2e4 in M3File__IsReadable (M3_Bd56fi_path=0x82276c0) > at M3File.m3:182 > #19 0x08088a3e in MxConfig__TryConfig (M3_Bd56fi_a=0x82276c0, > M3_Bd56fi_b=0x0, > M3_Bd56fi_c=0x0) at MxConfig.m3:94 > #20 0x08088635 in MxConfig__FindConfig () at MxConfig.m3:43 > #21 0x0808841b in MxConfig__FindFile () at MxConfig.m3:17 > #22 0x0807301d in Main__DoIt () at Main.m3:31 > #23 0x080739bc in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:193 > #24 0x081ee9a2 in RTLinker__RunMainBody (M3_DjPxE3_m=0x8223860) > at RTLinker.m3:399 > #25 0x081edecd in RTLinker__AddUnitI (M3_DjPxE3_m=0x8223860) at > RTLinker.m3:113 > #26 0x081edf54 in RTLinker__AddUnit (M3_DjPxE5_b=0x80739a7) at > RTLinker.m3:122 > #27 0x08049b99 in main (argc=1, argv=0xbfbfe5f4, envp=0xbfbfe5fc) > at _m3main.mc:4 > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From rcoleburn at scires.com Fri Dec 21 18:23:30 2007 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 21 Dec 2007 12:23:30 -0500 Subject: [M3devel] Missing packages? In-Reply-To: <200712210442.lBL4g4kK011539@camembert.async.caltech.edu> References: <200712210442.lBL4g4kK011539@camembert.async.caltech.edu> Message-ID: <476BB045.1E75.00D7.1@scires.com> Mika et al: I believe you are referring to the generic called "Stable". I have the sources for this from the cm3 v4.1 days. Olaf should have them also. I believe they fall under the same copyright/use rules as the rest of cm3. I also wrote something a long time back that may be of interest to you. I've attached the generic interfaces below for your reference. Note that they are in MS-DOS text format, not Unix-style text format. These two generics are very similar, but read the up-front comments to see the differences and decide which may be right for you. If you are interested, I should be able to provide the full sources to you. Let me know. Regards, Randy Coleburn >>> Mika Nystrom 12/20/2007 11:42 PM >>> Hi Modula-3 people. I was working on some code the other night and needed a small persistent table data structure, and I seemed to remember that there was a package called "stabletable" that had exactly the features I needed: a simple, persistent implementation of the Modula-3 generic tables. Only problem was ... I couldn't find it anywhere! I remembered it existed, but nowhere to be found. Well, I finally tracked it down on an m3browser running at the University of Tampere (Finland), cut-and-pasted the .ig and .mg and compiled the thing. A few questions: 1. This package is dated 1994. Is this after CM3 split from SRC M3? Is that why it's not in CM3? 2. Should I add it to CM3? 3. Are there other packages of similar status? Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ObjectDatabase2.ig Type: application/octet-stream Size: 19563 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ObjectDatabase.ig Type: application/octet-stream Size: 20395 bytes Desc: not available URL: From hosking at cs.purdue.edu Sat Dec 22 23:30:29 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 22 Dec 2007 17:30:29 -0500 Subject: [M3devel] endless exception loop on FreeBSD In-Reply-To: <476D6E04.2000503@luthien.in-berlin.de> References: <20071221132240.uu5elpnqwwc4408s@mail.elegosoft.com> <592A55CF-8680-499A-9911-F461B7562879@cs.purdue.edu> <476D6E04.2000503@luthien.in-berlin.de> Message-ID: Any chance that the sigjmp buffers are differently-sized with the new libc? On Dec 22, 2007, at 3:05 PM, Olaf Wagner wrote: > Tony Hosking wrote: > >> Hmm. It doesn't ring any bells for me. >> >> On Dec 21, 2007, at 7:22 AM, Olaf Wagner wrote: >> >>> I'm trying to add pthread support to the FreeBSD4 platform. >>> My first tentative additions now lead to endless exception loops >>> once any error is encountered until the stack overflows. >>> >>> Does anybody know what's wrong here? I'm not aware that I have >>> changed anything in this area. >> > I seems that I have been linking against a non-reentrant libc. I > can now get a little > farther: > > % ./m3-sys/cm3/FreeBSD4/cm3 -help @M3debugthreads > Stopping from act=0x8a93500 > Stopping act=0x8a93b80 > Stopped act=0x8a93b80 > Stopped from act=0x8a93500 > Processing act=0x8a93500 > Processing act=0x8a93b80 > Starting from act=0x8a93500 > Starting act=0x8a93b80 > Started act=0x8a93b80 > Started from act=0x8a93500 > Stopping from act=0x8a93500 > Stopping act=0x8a93b80 > Stopped act=0x8a93b80 > Stopped from act=0x8a93500 > Processing act=0x8a93500 > Processing act=0x8a93b80 > Starting from act=0x8a93500 > Starting act=0x8a93b80 > Started act=0x8a93b80 > Started from act=0x8a93500 > CStatus failed with errno 2 > > > *** > *** runtime error: > *** Unhandled exception: OSError.E > *** file "../src/os/POSIX/OSErrorPosix.m3", line 50 > *** > > Abort trap (core dumped) > > This is the compiler trying to locate cm3.cfg at different locations. > It doesn't find it and an OSError.E is raised, which should get caught > in M3File.IsReadable, but isn't. So it seems exception handling is > broken as soon as I use system threads. Any ideas on this one? > > Olaf From wagner at elegosoft.com Sun Dec 23 16:36:40 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 23 Dec 2007 16:36:40 +0100 Subject: [M3devel] pthreads on FreeBSD, was: endless exception loop on FreeBSD In-Reply-To: <476D6E04.2000503@luthien.in-berlin.de> References: <20071221132240.uu5elpnqwwc4408s@mail.elegosoft.com> <592A55CF-8680-499A-9911-F461B7562879@cs.purdue.edu> <476D6E04.2000503@luthien.in-berlin.de> Message-ID: <20071223163640.3mk3dmc05c0gsgok@mail.elegosoft.com> >> On Dec 21, 2007, at 7:22 AM, Olaf Wagner wrote: >> >>> I'm trying to add pthread support to the FreeBSD4 platform. >>> My first tentative additions now lead to endless exception loops >>> once any error is encountered until the stack overflows. >>> >>> Does anybody know what's wrong here? I'm not aware that I have >>> changed anything in this area. >> > I seems that I have been linking against a non-reentrant libc. I can > now get a little > farther: > > % ./m3-sys/cm3/FreeBSD4/cm3 -help @M3debugthreads > Stopping from act=0x8a93500 > Stopping act=0x8a93b80 > Stopped act=0x8a93b80 > Stopped from act=0x8a93500 > Processing act=0x8a93500 > Processing act=0x8a93b80 > Starting from act=0x8a93500 > Starting act=0x8a93b80 > Started act=0x8a93b80 > Started from act=0x8a93500 > Stopping from act=0x8a93500 > Stopping act=0x8a93b80 > Stopped act=0x8a93b80 > Stopped from act=0x8a93500 > Processing act=0x8a93500 > Processing act=0x8a93b80 > Starting from act=0x8a93500 > Starting act=0x8a93b80 > Started act=0x8a93b80 > Started from act=0x8a93500 > CStatus failed with errno 2 > > > *** > *** runtime error: > *** Unhandled exception: OSError.E > *** file "../src/os/POSIX/OSErrorPosix.m3", line 50 > *** > > Abort trap (core dumped) > > This is the compiler trying to locate cm3.cfg at different locations. > It doesn't find it and an OSError.E is raised, which should get caught > in M3File.IsReadable, but isn't. So it seems exception handling is > broken as soon as I use system threads. Any ideas on this one? Some additional information: It is really only the PTHREAD setting in m3core/src/thread/m3makefile which makes exceptions fail. If I change it and compile everything again, I get this output from cm3: % ./m3-sys/cm3/FreeBSD4/cm3 -help @M3debugthreads DetermineContext: oldSP = 0xbfbfe74c modelSP: 0xbfbfe70c oldSP: 0xbfbfe74c frame size: 64 CStatus failed with errno 2 CStatus failed with errno 2 CStatus failed with errno 2 CStatus failed with errno 2 CStatus failed with errno 2 CStatus failed with errno 2 Critical Mass Modula-3 version d5.5.0 last updated: 2007-12-17 configuration: /usr/local/cm3/bin/cm3.cfg [...] So all OSError.E exceptions for stat failures are caught, and there are no thread switches at the start of the compiler; it only sets up the model frame for userlevel threads. In contrast, system level pthreads show much activity at the start (why?), and the first exception terminates the compiler. I still haven't got a good explanation for this. Unfortunately, the FreeBSD gdb debugger does not really seem to cope well with threaded programs... All interesting information always is unrecoverable. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sun Dec 23 16:57:29 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 23 Dec 2007 10:57:29 -0500 Subject: [M3devel] pthreads on FreeBSD, was: endless exception loop on FreeBSD In-Reply-To: <20071223163640.3mk3dmc05c0gsgok@mail.elegosoft.com> References: <20071221132240.uu5elpnqwwc4408s@mail.elegosoft.com> <592A55CF-8680-499A-9911-F461B7562879@cs.purdue.edu> <476D6E04.2000503@luthien.in-berlin.de> <20071223163640.3mk3dmc05c0gsgok@mail.elegosoft.com> Message-ID: Ah! Lights turning on in my head... It is probably the case that you have neglected to tell the compiler to avoid using global exception information. You need to set Global_handler_stack FALSE in m3middle/src/Target.m3 for the pthreads- based targets. On Dec 23, 2007, at 10:36 AM, Olaf Wagner wrote: >>> On Dec 21, 2007, at 7:22 AM, Olaf Wagner wrote: >>> >>>> I'm trying to add pthread support to the FreeBSD4 platform. >>>> My first tentative additions now lead to endless exception loops >>>> once any error is encountered until the stack overflows. >>>> >>>> Does anybody know what's wrong here? I'm not aware that I have >>>> changed anything in this area. >>> >> I seems that I have been linking against a non-reentrant libc. I can >> now get a little >> farther: >> >> % ./m3-sys/cm3/FreeBSD4/cm3 -help @M3debugthreads >> Stopping from act=0x8a93500 >> Stopping act=0x8a93b80 >> Stopped act=0x8a93b80 >> Stopped from act=0x8a93500 >> Processing act=0x8a93500 >> Processing act=0x8a93b80 >> Starting from act=0x8a93500 >> Starting act=0x8a93b80 >> Started act=0x8a93b80 >> Started from act=0x8a93500 >> Stopping from act=0x8a93500 >> Stopping act=0x8a93b80 >> Stopped act=0x8a93b80 >> Stopped from act=0x8a93500 >> Processing act=0x8a93500 >> Processing act=0x8a93b80 >> Starting from act=0x8a93500 >> Starting act=0x8a93b80 >> Started act=0x8a93b80 >> Started from act=0x8a93500 >> CStatus failed with errno 2 >> >> >> *** >> *** runtime error: >> *** Unhandled exception: OSError.E >> *** file "../src/os/POSIX/OSErrorPosix.m3", line 50 >> *** >> >> Abort trap (core dumped) >> >> This is the compiler trying to locate cm3.cfg at different locations. >> It doesn't find it and an OSError.E is raised, which should get >> caught >> in M3File.IsReadable, but isn't. So it seems exception handling is >> broken as soon as I use system threads. Any ideas on this one? > > Some additional information: > > It is really only the PTHREAD setting in m3core/src/thread/m3makefile > which makes exceptions fail. If I change it and compile everything > again, > I get this output from cm3: > > % ./m3-sys/cm3/FreeBSD4/cm3 -help @M3debugthreads > DetermineContext: oldSP = 0xbfbfe74c > modelSP: 0xbfbfe70c > oldSP: 0xbfbfe74c > frame size: 64 > CStatus failed with errno 2 > CStatus failed with errno 2 > CStatus failed with errno 2 > CStatus failed with errno 2 > CStatus failed with errno 2 > CStatus failed with errno 2 > Critical Mass Modula-3 version d5.5.0 > last updated: 2007-12-17 > configuration: /usr/local/cm3/bin/cm3.cfg > [...] > > So all OSError.E exceptions for stat failures are caught, and there > are no thread switches at the start of the compiler; it only sets > up the model frame for userlevel threads. > In contrast, system level pthreads show much activity at the start > (why?), and the first exception terminates the compiler. > > I still haven't got a good explanation for this. Unfortunately, > the FreeBSD gdb debugger does not really seem to cope well with > threaded > programs... All interesting information always is unrecoverable. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Dec 23 20:48:18 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 23 Dec 2007 20:48:18 +0100 Subject: [M3devel] pthreads on FreeBSD, was: endless exception loop on FreeBSD In-Reply-To: References: <20071221132240.uu5elpnqwwc4408s@mail.elegosoft.com> <592A55CF-8680-499A-9911-F461B7562879@cs.purdue.edu> <476D6E04.2000503@luthien.in-berlin.de> <20071223163640.3mk3dmc05c0gsgok@mail.elegosoft.com> Message-ID: <20071223204818.zqdh8gl77k4k4c0s@mail.elegosoft.com> Quoting Tony Hosking : > Ah! Lights turning on in my head... > > It is probably the case that you have neglected to tell the compiler to > avoid using global exception information. You need to set > Global_handler_stack FALSE in m3middle/src/Target.m3 for the > pthreads-based targets. Great! This seems to have done the trick. I've now been able to recompile the whole system and run mentor with the FreeBSD pthreads library. I'd never have found this setting, because it was nowhere near I expected the problem. Exception handling is one of the areas I was never familiar with in (C)M3. Probably I should learn to understand how the system works in this respect, too. Is there any documentation about the current state of things apart from the source code? Thanks for your help and the great whole pthreads contribution, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sun Dec 23 20:53:58 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 23 Dec 2007 14:53:58 -0500 Subject: [M3devel] pthreads on FreeBSD, was: endless exception loop on FreeBSD In-Reply-To: <20071223204818.zqdh8gl77k4k4c0s@mail.elegosoft.com> References: <20071221132240.uu5elpnqwwc4408s@mail.elegosoft.com> <592A55CF-8680-499A-9911-F461B7562879@cs.purdue.edu> <476D6E04.2000503@luthien.in-berlin.de> <20071223163640.3mk3dmc05c0gsgok@mail.elegosoft.com> <20071223204818.zqdh8gl77k4k4c0s@mail.elegosoft.com> Message-ID: <697B4834-D0F5-4A9E-8B87-76C92EC0BFA8@cs.purdue.edu> On Dec 23, 2007, at 2:48 PM, Olaf Wagner wrote: > Quoting Tony Hosking : > >> Ah! Lights turning on in my head... >> >> It is probably the case that you have neglected to tell the >> compiler to >> avoid using global exception information. You need to set >> Global_handler_stack FALSE in m3middle/src/Target.m3 for the >> pthreads-based targets. > > Great! This seems to have done the trick. I've now been able to > recompile the whole system and run mentor with the FreeBSD pthreads > library. I'd never have found this setting, because it was nowhere > near I expected the problem. Excellent. > Exception handling is one of the areas I was never familiar with > in (C)M3. Probably I should learn to understand how the system > works in this respect, too. Is there any documentation about > the current state of things apart from the source code? I'm afraid I don't think there is much in the way of documentation other than the code. > Thanks for your help and the great whole pthreads contribution, Let me know if you have any other problems. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From jayk123 at hotmail.com Mon Dec 24 14:52:03 2007 From: jayk123 at hotmail.com (Jay) Date: Mon, 24 Dec 2007 13:52:03 +0000 Subject: [M3devel] relocation out of range on PPC_LINUX (5.2.6) Message-ID: (My goodness Linux continues to disappoint...not because of this Modula-3 stuff per se, though cminstall kind of stinks vs. somethhing more autoconf-ish..) Anyway: Using the 5.2.6 distribution on Yellow Dog Linux 4.1 (unpatched, I can't quite figure out how to get patches... one reason Linux disappoints, at the same time I can't patch the Linux system, a Windows system rebooted itself at 3am to take an update, which I also don't like..) [jay at localhost t]$ rm -rf PPC_LINUX [jay at localhost t]$ ls -Rl .: total 4 -rw-rw-r-- 1 jay jay 72 Dec 24 04:45 Hello.m3 [jay at localhost t]$ cat Hello.m3 MODULE Hello EXPORTS Main; IMPORT IO; BEGIN IO.Put("hello"); END Hello. [jay at localhost t]$ cm3 -version Critical Mass Modula-3 version 5.2.6 last updated: 2003-06-27 configuration: /usr/local/cm3/bin/cm3.cfg [jay at localhost t]$ which cm3 /usr/local/cm3/bin/cm3 [jay at localhost t]$ cm3 new source -> compiling Hello.m3 -> linking prog [jay at localhost t]$ PPC_LINUX/prog PPC_LINUX/prog: error while loading shared libraries: /usr/local/cm3/pkg/m3core/PPC_LINUX/libm3core.so.5: R_PPC_REL24 relocation at 0x0fe1220c for symbol `memset' out of range [jay at localhost t]$ ldd PPC_LINUX/prog libm3.so.5 => /usr/local/cm3/pkg/libm3/PPC_LINUX/libm3.so.5 (0x0fe94000) libm3core.so.5 => /usr/local/cm3/pkg/m3core/PPC_LINUX/libm3core.so.5 (0x0fdde000) libm3gcdefs.so.5 => /usr/local/cm3/lib/libm3gcdefs.so.5 (0x0fdbb000) libm.so.6 => /lib/tls/libm.so.6 (0x30015000) libc.so.6 => /lib/tls/libc.so.6 (0x3009b000) /lib/ld.so.1 (0x0ffd0000) I won't likely have a computer on which to investigate this over the next week. (Already bringing two. :) ) Building standalone works..just hack m3_link in cm3.cfg to say shared = "". cm3 is already standalone, but in case other executables are built and used.. So the question then becomes: Anyone know what causes this? How to avoid the binaries I'm going to produce having the same problem, perhaps on another machine and not mine? The error seems almost self explanatory. m3core.so.5 starts at 0x0fdde000 and extends to..? presumably something under 0x0fe1220c. Btw, I put in the request to fix alma mater mail forwarding, waiting for them now. - Jay _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007 From jayk123 at hotmail.com Mon Dec 24 19:12:07 2007 From: jayk123 at hotmail.com (Jay) Date: Mon, 24 Dec 2007 18:12:07 +0000 Subject: [M3devel] relocation out of range on PPC_LINUX (5.2.6) In-Reply-To: References: Message-ID: Lots of segfaults once the new cm3cg is shipped.. pretty much for every file.. next week.. - Jay ---------------------------------------- > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Date: Mon, 24 Dec 2007 13:52:03 +0000 > Subject: [M3devel] relocation out of range on PPC_LINUX (5.2.6) > > > (My goodness Linux continues to disappoint...not because > of this Modula-3 stuff per se, though cminstall kind of stinks > vs. somethhing more autoconf-ish..) > > Anyway: > > Using the 5.2.6 distribution on Yellow Dog Linux 4.1 (unpatched, I can't > quite figure out how to get patches... one reason Linux disappoints, > at the same time I can't patch the Linux system, a Windows system > rebooted itself at 3am to take an update, which I also don't like..) > > [jay at localhost t]$ rm -rf PPC_LINUX > > [jay at localhost t]$ ls -Rl > .: > total 4 > -rw-rw-r-- 1 jay jay 72 Dec 24 04:45 Hello.m3 > > [jay at localhost t]$ cat Hello.m3 > > MODULE Hello EXPORTS Main; > IMPORT IO; > BEGIN > IO.Put("hello"); > END Hello. > > [jay at localhost t]$ cm3 -version > Critical Mass Modula-3 version 5.2.6 > last updated: 2003-06-27 > configuration: /usr/local/cm3/bin/cm3.cfg > > [jay at localhost t]$ which cm3 > /usr/local/cm3/bin/cm3 > > [jay at localhost t]$ cm3 > new source -> compiling Hello.m3 > -> linking prog > > [jay at localhost t]$ PPC_LINUX/prog > PPC_LINUX/prog: error while loading shared libraries: /usr/local/cm3/pkg/m3core/PPC_LINUX/libm3core.so.5: R_PPC_REL24 relocation at 0x0fe1220c for symbol `memset' out of range > [jay at localhost t]$ ldd PPC_LINUX/prog > libm3.so.5 => /usr/local/cm3/pkg/libm3/PPC_LINUX/libm3.so.5 (0x0fe94000) > libm3core.so.5 => /usr/local/cm3/pkg/m3core/PPC_LINUX/libm3core.so.5 (0x0fdde000) > libm3gcdefs.so.5 => /usr/local/cm3/lib/libm3gcdefs.so.5 (0x0fdbb000) > libm.so.6 => /lib/tls/libm.so.6 (0x30015000) > libc.so.6 => /lib/tls/libc.so.6 (0x3009b000) > /lib/ld.so.1 (0x0ffd0000) > > > I won't likely have a computer on which to investigate this over the next week. > (Already bringing two. :) ) > > Building standalone works..just hack m3_link in cm3.cfg to say shared = "". > cm3 is already standalone, but in case other executables are built and used.. > > > So the question then becomes: > Anyone know what causes this? > How to avoid the binaries I'm going to produce having the same problem, > perhaps on another machine and not mine? > > > The error seems almost self explanatory. > m3core.so.5 starts at 0x0fdde000 and extends to..? > presumably something under 0x0fe1220c. > > Btw, I put in the request to fix alma mater mail forwarding, waiting for them now. > > - Jay > > _________________________________________________________________ > Share life as it happens with the new Windows Live. > http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007 _________________________________________________________________ The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. http://www.xbox.com/en-US/hardware/wheretobuy/ From jayk123 at hotmail.com Mon Dec 24 19:42:02 2007 From: jayk123 at hotmail.com (Jay) Date: Mon, 24 Dec 2007 18:42:02 +0000 Subject: [M3devel] relocation out of range on PPC_LINUX (5.2.6) In-Reply-To: References: Message-ID: Wow so I built my own svn and almost the same error: [root at localhost subversion-1.4.6]# svn svn: error while loading shared libraries: /usr/local/lib/libsvn_ra_dav-1.so.0: R_PPC_REL24 relocation at 0x0fdb5594 for symbol `strcmp' out of range maybe time to try 5.2 or OpenSuse or Fedora.. Will research more.. -Jay ---------------------------------------- > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: RE: [M3devel] relocation out of range on PPC_LINUX (5.2.6) > Date: Mon, 24 Dec 2007 18:12:07 +0000 > > > Lots of segfaults once the new cm3cg is shipped.. pretty much for every file.. next week.. > > - Jay > > ---------------------------------------- >> From: jayk123 at hotmail.com >> To: m3devel at elegosoft.com >> Date: Mon, 24 Dec 2007 13:52:03 +0000 >> Subject: [M3devel] relocation out of range on PPC_LINUX (5.2.6) >> >> >> (My goodness Linux continues to disappoint...not because >> of this Modula-3 stuff per se, though cminstall kind of stinks >> vs. somethhing more autoconf-ish..) >> >> Anyway: >> >> Using the 5.2.6 distribution on Yellow Dog Linux 4.1 (unpatched, I can't >> quite figure out how to get patches... one reason Linux disappoints, >> at the same time I can't patch the Linux system, a Windows system >> rebooted itself at 3am to take an update, which I also don't like..) >> >> [jay at localhost t]$ rm -rf PPC_LINUX >> >> [jay at localhost t]$ ls -Rl >> .: >> total 4 >> -rw-rw-r-- 1 jay jay 72 Dec 24 04:45 Hello.m3 >> >> [jay at localhost t]$ cat Hello.m3 >> >> MODULE Hello EXPORTS Main; >> IMPORT IO; >> BEGIN >> IO.Put("hello"); >> END Hello. >> >> [jay at localhost t]$ cm3 -version >> Critical Mass Modula-3 version 5.2.6 >> last updated: 2003-06-27 >> configuration: /usr/local/cm3/bin/cm3.cfg >> >> [jay at localhost t]$ which cm3 >> /usr/local/cm3/bin/cm3 >> >> [jay at localhost t]$ cm3 >> new source -> compiling Hello.m3 >> -> linking prog >> >> [jay at localhost t]$ PPC_LINUX/prog >> PPC_LINUX/prog: error while loading shared libraries: /usr/local/cm3/pkg/m3core/PPC_LINUX/libm3core.so.5: R_PPC_REL24 relocation at 0x0fe1220c for symbol `memset' out of range >> [jay at localhost t]$ ldd PPC_LINUX/prog >> libm3.so.5 => /usr/local/cm3/pkg/libm3/PPC_LINUX/libm3.so.5 (0x0fe94000) >> libm3core.so.5 => /usr/local/cm3/pkg/m3core/PPC_LINUX/libm3core.so.5 (0x0fdde000) >> libm3gcdefs.so.5 => /usr/local/cm3/lib/libm3gcdefs.so.5 (0x0fdbb000) >> libm.so.6 => /lib/tls/libm.so.6 (0x30015000) >> libc.so.6 => /lib/tls/libc.so.6 (0x3009b000) >> /lib/ld.so.1 (0x0ffd0000) >> >> >> I won't likely have a computer on which to investigate this over the next week. >> (Already bringing two. :) ) >> >> Building standalone works..just hack m3_link in cm3.cfg to say shared = "". >> cm3 is already standalone, but in case other executables are built and used.. >> >> >> So the question then becomes: >> Anyone know what causes this? >> How to avoid the binaries I'm going to produce having the same problem, >> perhaps on another machine and not mine? >> >> >> The error seems almost self explanatory. >> m3core.so.5 starts at 0x0fdde000 and extends to..? >> presumably something under 0x0fe1220c. >> >> Btw, I put in the request to fix alma mater mail forwarding, waiting for them now. >> >> - Jay >> >> _________________________________________________________________ >> Share life as it happens with the new Windows Live. >> http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007 > > _________________________________________________________________ > The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. > http://www.xbox.com/en-US/hardware/wheretobuy/ _________________________________________________________________ The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. http://www.xbox.com/en-US/hardware/wheretobuy/ From jayk123 at hotmail.com Mon Dec 24 20:10:19 2007 From: jayk123 at hotmail.com (Jay) Date: Mon, 24 Dec 2007 19:10:19 +0000 Subject: [M3devel] relocation out of range on PPC_LINUX (5.2.6) In-Reply-To: References: Message-ID: "research" -- "search the web" configure --with-pic and/or --disable-multilibs sound promsing *-darwin use --disable-multi on the other hand, the thread is six years old, you'd think it'd just work by now.. next week.. - Jay ---------------------------------------- > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: RE: [M3devel] relocation out of range on PPC_LINUX (5.2.6) > Date: Mon, 24 Dec 2007 18:42:02 +0000 > > > Wow so I built my own svn and almost the same error: > > [root at localhost subversion-1.4.6]# svn > svn: error while loading shared libraries: /usr/local/lib/libsvn_ra_dav-1.so.0: R_PPC_REL24 relocation at 0x0fdb5594 for symbol `strcmp' out of range > > maybe time to try 5.2 or OpenSuse or Fedora.. > > Will research more.. > > -Jay > ---------------------------------------- >> From: jayk123 at hotmail.com >> To: m3devel at elegosoft.com >> Subject: RE: [M3devel] relocation out of range on PPC_LINUX (5.2.6) >> Date: Mon, 24 Dec 2007 18:12:07 +0000 >> >> >> Lots of segfaults once the new cm3cg is shipped.. pretty much for every file.. next week.. >> >> - Jay >> >> ---------------------------------------- >>> From: jayk123 at hotmail.com >>> To: m3devel at elegosoft.com >>> Date: Mon, 24 Dec 2007 13:52:03 +0000 >>> Subject: [M3devel] relocation out of range on PPC_LINUX (5.2.6) >>> >>> >>> (My goodness Linux continues to disappoint...not because >>> of this Modula-3 stuff per se, though cminstall kind of stinks >>> vs. somethhing more autoconf-ish..) >>> >>> Anyway: >>> >>> Using the 5.2.6 distribution on Yellow Dog Linux 4.1 (unpatched, I can't >>> quite figure out how to get patches... one reason Linux disappoints, >>> at the same time I can't patch the Linux system, a Windows system >>> rebooted itself at 3am to take an update, which I also don't like..) >>> >>> [jay at localhost t]$ rm -rf PPC_LINUX >>> >>> [jay at localhost t]$ ls -Rl >>> .: >>> total 4 >>> -rw-rw-r-- 1 jay jay 72 Dec 24 04:45 Hello.m3 >>> >>> [jay at localhost t]$ cat Hello.m3 >>> >>> MODULE Hello EXPORTS Main; >>> IMPORT IO; >>> BEGIN >>> IO.Put("hello"); >>> END Hello. >>> >>> [jay at localhost t]$ cm3 -version >>> Critical Mass Modula-3 version 5.2.6 >>> last updated: 2003-06-27 >>> configuration: /usr/local/cm3/bin/cm3.cfg >>> >>> [jay at localhost t]$ which cm3 >>> /usr/local/cm3/bin/cm3 >>> >>> [jay at localhost t]$ cm3 >>> new source -> compiling Hello.m3 >>> -> linking prog >>> >>> [jay at localhost t]$ PPC_LINUX/prog >>> PPC_LINUX/prog: error while loading shared libraries: /usr/local/cm3/pkg/m3core/PPC_LINUX/libm3core.so.5: R_PPC_REL24 relocation at 0x0fe1220c for symbol `memset' out of range >>> [jay at localhost t]$ ldd PPC_LINUX/prog >>> libm3.so.5 => /usr/local/cm3/pkg/libm3/PPC_LINUX/libm3.so.5 (0x0fe94000) >>> libm3core.so.5 => /usr/local/cm3/pkg/m3core/PPC_LINUX/libm3core.so.5 (0x0fdde000) >>> libm3gcdefs.so.5 => /usr/local/cm3/lib/libm3gcdefs.so.5 (0x0fdbb000) >>> libm.so.6 => /lib/tls/libm.so.6 (0x30015000) >>> libc.so.6 => /lib/tls/libc.so.6 (0x3009b000) >>> /lib/ld.so.1 (0x0ffd0000) >>> >>> >>> I won't likely have a computer on which to investigate this over the next week. >>> (Already bringing two. :) ) >>> >>> Building standalone works..just hack m3_link in cm3.cfg to say shared = "". >>> cm3 is already standalone, but in case other executables are built and used.. >>> >>> >>> So the question then becomes: >>> Anyone know what causes this? >>> How to avoid the binaries I'm going to produce having the same problem, >>> perhaps on another machine and not mine? >>> >>> >>> The error seems almost self explanatory. >>> m3core.so.5 starts at 0x0fdde000 and extends to..? >>> presumably something under 0x0fe1220c. >>> >>> Btw, I put in the request to fix alma mater mail forwarding, waiting for them now. >>> >>> - Jay >>> >>> _________________________________________________________________ >>> Share life as it happens with the new Windows Live. >>> http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007 >> >> _________________________________________________________________ >> The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. >> http://www.xbox.com/en-US/hardware/wheretobuy/ > > _________________________________________________________________ > The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. > http://www.xbox.com/en-US/hardware/wheretobuy/ _________________________________________________________________ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_122007 From jayk123 at hotmail.com Tue Dec 25 13:09:31 2007 From: jayk123 at hotmail.com (Jay) Date: Tue, 25 Dec 2007 12:09:31 +0000 Subject: [M3devel] PPC_DARWIN problems, at least config/5.2.6, maybe all moot Message-ID: PPC_DARWIN also has problems...at least in the config. If you take the 5.2.6 archive, install to /dev2/cm3, accept the defaults, claim all the missing unused libs are in /usr/lib (opengl, postgres, x11) you end up with: jbook:/dev2/j/m3 jay$ cat Hello.m3 MODULE Hello EXPORTS Main; IMPORT IO; BEGIN IO.Put("Hello\n"); END Hello. jbook:/dev2/j/m3 jay$ uname -a Darwin jbook 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc jbook:/dev2/j/m3 jay$ cm3 -version Critical Mass Modula-3 version 5.2.6 last updated: 2003-06-27 configuration: /cm3/bin/cm3.cfg jbook:/dev2/j/m3 jay$ cm3 new source -> compiling Hello.m3 -> linking prog jbook:/dev2/j/m3 jay$ PPC_DARWIN/prog dyld: Library not loaded: /var/tmp/cm3/lib/libm3.5.2.dylib Referenced from: /dev2/j/m3/PPC_DARWIN/prog Reason: image not found Trace/BPT trap jbook:/dev2/j/m3 jay$ otool -L PPC_DARWIN/prog PPC_DARWIN/prog: /var/tmp/cm3/lib/libm3.5.2.dylib (compatibility version 5.0.0, current version 5.2.0) /Users/wagner/local/cm3/lib/libm3core.5.2.dylib (compatibility version 5.0.0, current version 5.2.0) /Users/wagner/local/cm3/lib/libm3gcdefs.5.2.dylib (compatibility version 5.0.0, current version 5.2.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.10) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) jbook:/dev2/j/m3 jay$ ls -l PPC_DARWIN/prog -rwxr-xr-x 1 jay admin 20264 Dec 25 04:43 PPC_DARWIN/prog At the temporary cost of giving up dynamic linking, you can fix this by removing M3_SPLIT_LIBNAMES_IF_SHARED and/or M3_SPLIT_LIBNAMES from cm3.cfg, yielding: jbook:/dev2/j/m3 jay$ otool -L PPC_DARWIN/prog PPC_DARWIN/prog: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.10) jbook:/dev2/j/m3 jay$ ls -l PPC_DARWIN/prog -rwxr-xr-x 1 jay admin 1388380 Dec 25 04:48 PPC_DARWIN/prog jbook:/dev2/j/m3 jay$ PPC_DARWIN/prog Hello I will fix the checked in config file...even though it varies a bunch from the 5.2.6 distributed config, it results in the same. And, um, does everyone understand what I did with Win32 and making cminstall obsolete? Ok to do the same on Mac OS X? You know, it's running things out of the path and/or finding them in their "very standard" locations. In fact, you can hard code full paths and be ok. That is, instead of asking the user where their compiler is, hardcoding any of cc, gcc, /usr/bin/cc, /usr/bin/gcc all work fine. Asking them where ar/ranlib are, similar, though the docs say that libtool replaced those, and ar/ranlib vs. libtool is one way in which the checked in config and the 5.2.6 distribution's config vary. I'll try for libtool. The only thing the user really needs to decide is where to install to, and the cfg file can discover their choice without any editing. INSTALL_ROOT = path() & "/.." BIN_INSTALL = path() % executables In terms of wanting to provide some configurable redirection, well, I think an advanced user can manage.. An indirect SYSTEM_CC = "cc" can be left, I guess. You know, I dare say, that platforms have been reduced and converged enough such that..you can get rid of Quake and move it into cm3. Um.. do any of the Unix platforms support other than gcc? Other than GNU ld? Ok, Apple ld is not GNU ld. (Geez, it is just me or is Apple an incredible hodgepodge mess these days? I mean both in terms of their "system architecture" and their tools. The "system architecture" reveals bunches of similar redundant subsystems. Try reading through man ld, man ranlib, just try to understand which flag goes with which mode, which flags are for compatibility with which OS version, and which of the compatibility flags is either ignored or does something useful... and should I say -lGL or -framework OpenGL??) That I don't haven't adjusted to Modula-3 and don't mind/prefer writing Quake instead. :) Some bootstrap was provided. I should look at it, and its config. Otherwise..I'll look into what it takes to build it all and with dynamic linking. Perhaps the bootstrap is just fine. But the checked in config is not. - Jay _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Dec 25 17:02:59 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 25 Dec 2007 11:02:59 -0500 Subject: [M3devel] PPC_DARWIN problems, at least config/5.2.6, maybe all moot In-Reply-To: References: Message-ID: <5EB28A70-CCEC-4855-B714-F0CE03E6DCC6@cs.purdue.edu> On Dec 25, 2007, at 7:09 AM, Jay wrote: > PPC_DARWIN also has problems...at least in the config. This is the cm3.cfg I use for PPC_DARWIN and it works fine for me. Notice that it installs into /usr/local/cm3. -------------- next part -------------- A non-text attachment was scrubbed... Name: cm3.cfg Type: application/octet-stream Size: 12662 bytes Desc: not available URL: -------------- next part -------------- > > > > If you take the 5.2.6 archive, install to /dev2/cm3, accept the > defaults, > claim all the missing unused libs are in /usr/lib (opengl, > postgres, x11) > > > you end up with: > > > jbook:/dev2/j/m3 jay$ cat Hello.m3 > > > MODULE Hello EXPORTS Main; > IMPORT IO; > BEGIN > IO.Put("Hello\n"); > END Hello. > > > jbook:/dev2/j/m3 jay$ uname -a > Darwin jbook 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 > 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh > powerpc > > > jbook:/dev2/j/m3 jay$ cm3 -version > Critical Mass Modula-3 version 5.2.6 > last updated: 2003-06-27 > configuration: /cm3/bin/cm3.cfg > > > jbook:/dev2/j/m3 jay$ cm3 > new source -> compiling Hello.m3 > -> linking prog > > > jbook:/dev2/j/m3 jay$ PPC_DARWIN/prog > dyld: Library not loaded: /var/tmp/cm3/lib/libm3.5.2.dylib > Referenced from: /dev2/j/m3/PPC_DARWIN/prog > Reason: image not found > Trace/BPT trap > > > jbook:/dev2/j/m3 jay$ otool -L PPC_DARWIN/prog > PPC_DARWIN/prog: > /var/tmp/cm3/lib/libm3.5.2.dylib (compatibility version > 5.0.0, current version 5.2.0) > /Users/wagner/local/cm3/lib/libm3core.5.2.dylib > (compatibility version 5.0.0, current version 5.2.0) > /Users/wagner/local/cm3/lib/libm3gcdefs.5.2.dylib > (compatibility version 5.0.0, current version 5.2.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > current version 88.1.10) > /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, > current version 1.0.0) > > > jbook:/dev2/j/m3 jay$ ls -l PPC_DARWIN/prog > -rwxr-xr-x 1 jay admin 20264 Dec 25 04:43 PPC_DARWIN/prog > > > At the temporary cost of giving up dynamic linking, you can fix > this by removing M3_SPLIT_LIBNAMES_IF_SHARED > and/or M3_SPLIT_LIBNAMES from cm3.cfg, yielding: > Dynamic linking works fine for me. > > jbook:/dev2/j/m3 jay$ otool -L PPC_DARWIN/prog > PPC_DARWIN/prog: > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > current version 88.1.10) > > > jbook:/dev2/j/m3 jay$ ls -l PPC_DARWIN/prog > -rwxr-xr-x 1 jay admin 1388380 Dec 25 04:48 PPC_DARWIN/prog > > > jbook:/dev2/j/m3 jay$ PPC_DARWIN/prog > Hello > > > I will fix the checked in config file...even though it varies a > bunch from the 5.2.6 distributed > config, it results in the same. Not sure how that differs with my config file. > And, um, does everyone understand what I did with Win32 and making > cminstall obsolete? > Ok to do the same on Mac OS X? Please don't. I would prefer to keep the OS X install the same as for other Unix/POSIX platforms, if only because it means less splitting of the code base. > You know, it's running things out of the path and/or finding them > in their "very standard" locations. > In fact, you can hard code full paths and be ok. > That is, instead of asking the user where their compiler is, > hardcoding any of cc, gcc, /usr/bin/cc, /usr/bin/gcc all work fine. Why not just hardcode the cminstall config file so it doesn't ask questions except were absolutely necessary. > Asking them where ar/ranlib are, similar, though the docs say that > libtool replaced those, and ar/ranlib vs. libtool is one way > in which the checked in config and the 5.2.6 distribution's config > vary. I'll try for libtool. Please see my config file. > > > > The only thing the user really needs to decide is where to install > to, and > the cfg file can discover their choice without any editing. Indeed. > > > > INSTALL_ROOT = path() & "/.." > BIN_INSTALL = path() % executables > > > In terms of wanting to provide some configurable redirection, well, > I think an advanced user can manage.. > An indirect SYSTEM_CC = "cc" can be left, I guess. > > > You know, I dare say, that platforms have been reduced and > converged enough such that..you can get rid of > Quake and move it into cm3. I'm not sure what you mean by this. > Um.. do any of the Unix platforms support other than gcc? Other > than GNU ld? > Ok, Apple ld is not GNU ld. (Geez, it is just me or is Apple an > incredible hodgepodge mess these days? > I mean both in terms of their "system architecture" and their > tools. The "system architecture" reveals bunches > of similar redundant subsystems. Try reading through man ld, man > ranlib, just try to understand which > flag goes with which mode, which flags are for compatibility with > which OS version, and which of the > compatibility flags is either ignored or does something useful... > and should I say -lGL or -framework OpenGL??) > > > That I don't haven't adjusted to Modula-3 and don't mind/prefer > writing Quake instead. :) > > > Some bootstrap was provided. I should look at it, and its config. > Otherwise..I'll look into what it takes to build it all and with > dynamic linking. > Perhaps the bootstrap is just fine. But the checked in config is not. I have a PPC_DARWIN bootstrap file at ftp://ftp.cs.purdue.edu/pub/ hosking/m3 and in the PPC_DARWIN subdirectory. > > > > - Jay > > Share life as it happens with the new Windows Live. Share now! From wagner at elegosoft.com Tue Dec 25 17:26:33 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 25 Dec 2007 17:26:33 +0100 Subject: [M3devel] PPC_DARWIN problems, at least config/5.2.6, maybe all moot In-Reply-To: <5EB28A70-CCEC-4855-B714-F0CE03E6DCC6@cs.purdue.edu> References: <5EB28A70-CCEC-4855-B714-F0CE03E6DCC6@cs.purdue.edu> Message-ID: <20071225162633.GA6373@elegosoft.com> On Tue, Dec 25, 2007 at 11:02:59AM -0500, Tony Hosking wrote: > On Dec 25, 2007, at 7:09 AM, Jay wrote: > >jbook:/dev2/j/m3 jay$ otool -L PPC_DARWIN/prog > >PPC_DARWIN/prog: > > /var/tmp/cm3/lib/libm3.5.2.dylib (compatibility version > >5.0.0, current version 5.2.0) > > /Users/wagner/local/cm3/lib/libm3core.5.2.dylib > >(compatibility version 5.0.0, current version 5.2.0) > > /Users/wagner/local/cm3/lib/libm3gcdefs.5.2.dylib > >(compatibility version 5.0.0, current version 5.2.0) > > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > >current version 88.1.10) > > /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, > >current version 1.0.0) > > > >jbook:/dev2/j/m3 jay$ ls -l PPC_DARWIN/prog > >-rwxr-xr-x 1 jay admin 20264 Dec 25 04:43 PPC_DARWIN/prog > > > >At the temporary cost of giving up dynamic linking, you can fix > >this by removing M3_SPLIT_LIBNAMES_IF_SHARED > >and/or M3_SPLIT_LIBNAMES from cm3.cfg, yielding: > > Dynamic linking works fine for me. For me, too. > >And, um, does everyone understand what I did with Win32 and making > >cminstall obsolete? > >Ok to do the same on Mac OS X? > > Please don't. I would prefer to keep the OS X install the same as > for other Unix/POSIX platforms, if only because it means less > splitting of the code base. I'd second this. I'd rather have a more intelligent cminstall, which tries to figure out all the information for itself, and then presents the user with a standard setup and directions how to solve any remaining problems. And this way we don't have to bother with more more scripting languages, too. > Why not just hardcode the cminstall config file so it doesn't ask > questions except were absolutely necessary. This would be another approach to making things simpler. We can try both ways at once, though. > >The only thing the user really needs to decide is where to install > >to, and > >the cfg file can discover their choice without any editing. > > Indeed. I wouldn't like to remove any flexibility there is, as in my experience, it will be needed once it has been removed. Perhaps I'll have a try at making cminstall better during the next weeks. The main problem with installation issues is, that one needs access to all relevant target platforms to check things and test them, and that it takes much time to do this ;-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Dec 25 17:33:09 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 25 Dec 2007 17:33:09 +0100 Subject: [M3devel] m3cg build failure on powerpc/darwin In-Reply-To: <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> Message-ID: <20071225163309.GA7057@elegosoft.com> Just for the records: The solution to the instruction problem below is installing a newer cctools package. Detailed instructions can be found at http://gcc.gnu.org/ml/gcc/2005-03/msg01149.html Olaf On Sun, Dec 16, 2007 at 04:50:38PM -0500, Tony Hosking wrote: > That is a very old Darwin distro. Here is my G4: > > Darwin Kernel Version 8.10.0: Wed May 23 16:50:59 PDT 2007; > root:xnu-792.21.3~1/RELEASE_PPC > > On Dec 16, 2007, at 4:23 PM, Olaf Wagner wrote: > > >Hi, > > > >while trying to build some boot archives build on my PowerBook > >G4, uname -a > > > >Darwin apple.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 > >20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power > >Macintosh powerpc > > > >the compilation died with > > > >/Users/wagner/work/cm3/m3-sys/m3cc/PPC_DARWIN/./gcc/xgcc -B/Users/ > >wagner/work/cm3/m3-sys/m3cc/PPC_DARWIN/./gcc/ -B/usr/local/powerpc- > >apple-darwin7.9.0/bin/ -B/usr/local/powerpc-apple-darwin7.9.0/lib/ - > >isystem /usr/local/powerpc-apple-darwin7.9.0/include -isystem /usr/ > >local/powerpc-apple-darwin7.9.0/sys-include -c -DHAVE_CONFIG_H -O2 - > >O2 -g -I. -I../../../gcc/libiberty/../include -W -Wall -pedantic - > >Wwrite-strings -Wstrict-prototypes ../../../gcc/libiberty/ > >floatformat.c -o floatformat.o > >../../../gcc/libiberty/floatformat.c: In function > >'floatformat_to_double': > >../../../gcc/libiberty/floatformat.c:354: warning: floating > >constant exceeds range of 'float' > >/var/tmp/cccvQbrs.s:508:stfiwx instruction is optional for the > >PowerPC (not allowed without -force_cpusubtype_ALL option) > >/var/tmp/cccvQbrs.s:550:stfiwx instruction is optional for the > >PowerPC (not allowed without -force_cpusubtype_ALL option) > >make[2]: *** [floatformat.o] Error 1 > >make[1]: *** [all-target-libiberty] Error 2 > >make: *** [all] Error 2 > >"/Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile", line 188: > >quake runtime error: exit 512: cd .; make CC="gcc" CFLAGS="-O2 -g" > > > >--procedure-- -line- -file--- > >exec -- > >include_dir 188 /Users/wagner/work/cm3/m3-sys/m3cc/src/ > >m3makefile > > 5 /Users/wagner/work/cm3/m3-sys/m3cc/ > >PPC_DARWIN/m3make.args > > > >Fatal Error: package build failed > > > >Any ideas? -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Tue Dec 25 20:03:21 2007 From: jayk123 at hotmail.com (Jay) Date: Tue, 25 Dec 2007 19:03:21 +0000 Subject: [M3devel] "why cminstall isn't needed" Message-ID: Here is what happens on Mac OSX 10.4 PowerPC. Where would you like the system installed? [/usr/local/cm3] This is the one thing worthwhile, though the default is fine. 1: /usr/bin/emacsclient 2: /usr/bin/emacs 3: /usr/bin/gnuclient 4: /usr/bin/vi 5: /usr/bin/vim What should be the default text editor for new CM3 users? [/usr/bin/emacsclient](1 of 5) I don't believe this is ever used, not until Reactor comes back. Otherwise it's not a terrible thing to ask. 1: /usr/lib Where are the flex/bison libraries? [/usr/lib](1 of 1) I haven't tested this yet, but the default appears correct, and you don't likely need to specify it. "-lfl" probably suffices. Where are the Postgres95 libraries? By default, nowhere. User could edit cm3.cfg file. Perhaps just comment which parts are more or less expected to be user-edited? Where are the OpenGL libraries? Haven't tested this, but again I believe hardcoding is trivial. Like -framework OpenGL or such. (attached) 1: /usr/lib 2: /usr/local/lib Where are the ODBC libraries? [/usr/lib](1 of 2) Untested, but again /usr/lib appears correct and -liodbc -liodbcinst should suffice. Where are the Motif libraries? Nowhere by default. Where are the X11 libraries? Nowhere by default, but probably hardcodeable if installed. 1: /usr/bin/gcc 2: /usr/bin/cc Where is your C compiler? [/usr/bin/gcc](1 of 2) Both options are fine and equivalent, along with "cc, "gcc", "gcc-3.3", "gcc-4.0". 1: /usr/bin/ar Where is your library archiver? [/usr/bin/ar](1 of 1) This is correct, along with "ar", but the docs suggest shouldn't be used. 1: /usr/bin/ranlib Where is your library indexer? [/usr/bin/ranlib](1 of 1) Ditto. 1: /usr/bin/as Where is your assembler? [/usr/bin/as](1 of 1) This is correct, along with "as". Could also be, e.g. /usr/libexec/darwin/pcc/as, but nothing to be gained by using that directly, right? (gcc has similar actual files) See my point? It's all rather worthless. Hardcoded defaults or $PATH search work. Attached is my config file so far but I am having problems.. - Jay _________________________________________________________________ Don't get caught with egg on your face. Play Chicktionary! http://club.live.com/chicktionary.aspx?icid=chick_wlhmtextlink1_dec -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cfg1 Type: application/octet-stream Size: 12614 bytes Desc: not available URL: From jayk123 at hotmail.com Tue Dec 25 21:32:15 2007 From: jayk123 at hotmail.com (Jay) Date: Tue, 25 Dec 2007 20:32:15 +0000 Subject: [M3devel] PPC_DARWIN problems, at least config/5.2.6, maybe all moot Message-ID: 1) The documentation says -fPIC is the default, so I removed it. But it matters. It doesn't matter for gcc building C. It matters for m3cg building Modula-3. It is the difference between, pic: jbook:/dev2/j/m3 jay$ cat Hello.m3 MODULE Hello EXPORTS Main; IMPORT IO; BEGIN IO.Put("Hello\n"); END Hello. jbook:/dev2/j/m3 jay$ cat PPC_DARWIN/Hello.ms ... bl L_IO__Put$stub ... .data .picsymbol_stub L_IO__Put$stub: .indirect_symbol _IO__Put mflr r0 bcl 20,31,L0$_IO__Put L0$_IO__Put: mflr r11 addis r11,r11,ha16(L_IO__Put$lazy_ptr-L0$_IO__Put) mtlr r0 lwz r12,lo16(L_IO__Put$lazy_ptr-L0$_IO__Put)(r11) mtctr r12 addi r11,r11,lo16(L_IO__Put$lazy_ptr-L0$_IO__Put) bctr .data .lazy_symbol_pointer L_IO__Put$lazy_ptr: .indirect_symbol _IO__Put .long dyld_stub_binding_helper vs. non-pic just plain wow only one whole function to make a call :) : jbook:/dev2/j/m3 jay$ cat PPC_DARWIN/Hello.ms ... bl _IO__Put which nets you the likes of: jbook:/dev2/j/m3 jay$ cm3 -> linking prog gcc -dynamic -o prog _m3main.o Hello.mo -L/cm3/pkg/libm3/PPC_DARWIN -lm3 -L/cm3/pkg/m3core/PPC_DARWIN -lm3core -L/cm3/bin/../lib -lm3gcdefs /usr/bin/ld: _m3main.o has external relocation entries in non-writable section (__TEXT,__text) for symbols: _RTProcess__Exit _RTLinker__AddUnit _RTLinker__InitRuntime collect2: ld returned 1 exit status (Windows also only uses one instruction, through a pointer, for dynamic calls, and the compiler often prefetches the pointer. The difference is, perhaps, that Windows aggregates all the pointers together, not sure about the other systems.. one instruction through a pointer is true for x86 and AM64, not so of the former MIPS, PowerPC, Alpha I believe or current IA64, those require fetching/restore the GOT/TOC (same thing? I should know the difference..) 2) Splitting -L and -l off for shared libs matters. ld /foo/bar.a means link to bar.a, which is a static lib, not even a stub lib or import lib like in Windows -L/foo -lbar probes for /foo/bar.dylib /foo/bar.a man ld: -lx This option is an abbreviation for the library name `libx.a', where x is a string. If -dynamic is specified the abbreviation for the library name is first search as `libx.dylib' and then `libx.a' is searched for. ld searches for libraries first in any directories specified with -L options, then in any directo- ries specified in the colon separated set of paths in the envi- ronment variable LD_LIBRARY_PATH, then the standard directories /lib, /usr/lib, and /usr/local/lib. A library is searched when its name is encountered, so the placement of the -l flag is sig- nificant. If string x is of the form x.o, then that file is searched for in the same places, but without prepending `lib' or appending `.a' or `.dylib' to the filename. 3) lastly, setting DYLD_LIBRARY_PATH=/cm3/lib lets the full paths from one machine not matter so much on another machine. I am going to try out: before: local lib_so = format ("lib%s.dylib", lib) local lib_soxx = format ("lib%s.%s.dylib", lib, version) local lib_pn = LIB_INSTALL & "/" & lib_soxx "-install_name", lib_pn, after: local lib_so = format ("lib%s.dylib", lib) local lib_soxx = format ("lib%s.%s.dylib", lib, version) local lib_pn = LIB_INSTALL & "/" & lib_soxx "-install_name", lib_soxx, see if a path is needed or can just use leaf names. - Jay From: jayk123 at hotmail.com To: m3devel at elegosoft.com Subject: PPC_DARWIN problems, at least config/5.2.6, maybe all moot Date: Tue, 25 Dec 2007 12:09:31 +0000 PPC_DARWIN also has problems...at least in the config. If you take the 5.2.6 archive, install to /dev2/cm3, accept the defaults, claim all the missing unused libs are in /usr/lib (opengl, postgres, x11) you end up with: jbook:/dev2/j/m3 jay$ cat Hello.m3 MODULE Hello EXPORTS Main; IMPORT IO; BEGIN IO.Put("Hello\n"); END Hello. jbook:/dev2/j/m3 jay$ uname -a Darwin jbook 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc jbook:/dev2/j/m3 jay$ cm3 -version Critical Mass Modula-3 version 5.2.6 last updated: 2003-06-27 configuration: /cm3/bin/cm3.cfg jbook:/dev2/j/m3 jay$ cm3 new source -> compiling Hello.m3 -> linking prog jbook:/dev2/j/m3 jay$ PPC_DARWIN/prog dyld: Library not loaded: /var/tmp/cm3/lib/libm3.5.2.dylib Referenced from: /dev2/j/m3/PPC_DARWIN/prog Reason: image not found Trace/BPT trap jbook:/dev2/j/m3 jay$ otool -L PPC_DARWIN/prog PPC_DARWIN/prog: /var/tmp/cm3/lib/libm3.5.2.dylib (compatibility version 5.0.0, current version 5.2.0) /Users/wagner/local/cm3/lib/libm3core.5.2.dylib (compatibility version 5.0.0, current version 5.2.0) /Users/wagner/local/cm3/lib/libm3gcdefs.5.2.dylib (compatibility version 5.0.0, current version 5.2.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.10) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) jbook:/dev2/j/m3 jay$ ls -l PPC_DARWIN/prog -rwxr-xr-x 1 jay admin 20264 Dec 25 04:43 PPC_DARWIN/prog At the temporary cost of giving up dynamic linking, you can fix this by removing M3_SPLIT_LIBNAMES_IF_SHARED and/or M3_SPLIT_LIBNAMES from cm3.cfg, yielding: jbook:/dev2/j/m3 jay$ otool -L PPC_DARWIN/prog PPC_DARWIN/prog: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.10) jbook:/dev2/j/m3 jay$ ls -l PPC_DARWIN/prog -rwxr-xr-x 1 jay admin 1388380 Dec 25 04:48 PPC_DARWIN/prog jbook:/dev2/j/m3 jay$ PPC_DARWIN/prog Hello I will fix the checked in config file...even though it varies a bunch from the 5.2.6 distributed config, it results in the same. And, um, does everyone understand what I did with Win32 and making cminstall obsolete? Ok to do the same on Mac OS X? You know, it's running things out of the path and/or finding them in their "very standard" locations. In fact, you can hard code full paths and be ok. That is, instead of asking the user where their compiler is, hardcoding any of cc, gcc, /usr/bin/cc, /usr/bin/gcc all work fine. Asking them where ar/ranlib are, similar, though the docs say that libtool replaced those, and ar/ranlib vs. libtool is one way in which the checked in config and the 5.2.6 distribution's config vary. I'll try for libtool. The only thing the user really needs to decide is where to install to, and the cfg file can discover their choice without any editing. INSTALL_ROOT = path() & "/.." BIN_INSTALL = path() % executables In terms of wanting to provide some configurable redirection, well, I think an advanced user can manage.. An indirect SYSTEM_CC = "cc" can be left, I guess. You know, I dare say, that platforms have been reduced and converged enough such that..you can get rid of Quake and move it into cm3. Um.. do any of the Unix platforms support other than gcc? Other than GNU ld? Ok, Apple ld is not GNU ld. (Geez, it is just me or is Apple an incredible hodgepodge mess these days? I mean both in terms of their "system architecture" and their tools. The "system architecture" reveals bunches of similar redundant subsystems. Try reading through man ld, man ranlib, just try to understand which flag goes with which mode, which flags are for compatibility with which OS version, and which of the compatibility flags is either ignored or does something useful... and should I say -lGL or -framework OpenGL??) That I don't haven't adjusted to Modula-3 and don't mind/prefer writing Quake instead. :) Some bootstrap was provided. I should look at it, and its config. Otherwise..I'll look into what it takes to build it all and with dynamic linking. Perhaps the bootstrap is just fine. But the checked in config is not. - Jay Share life as it happens with the new Windows Live. Share now! _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Tue Dec 25 22:47:03 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 25 Dec 2007 13:47:03 -0800 Subject: [M3devel] PPC_DARWIN problems, at least config/5.2.6, maybe all moot In-Reply-To: Your message of "Tue, 25 Dec 2007 12:09:31 GMT." Message-ID: <200712252147.lBPLl32p030684@camembert.async.caltech.edu> Jay writes: > ... > >You know, I dare say, that platforms have been reduced and converged enough= > such that..you can get rid of >Quake and move it into cm3. Um.. do any of the Unix platforms support other= > than gcc? Other than GNU ld? I take it you don't mean "get rid of Quake" but "get rid of cm3.cfg"? I would certainly agree that cm3.cfg is problematic. I have more than once had apparently unresolvable issues with CM3 that Tony fixed by sending me a new cm3.cfg, which came, seemingly, out of a hat... However I also would think it's a bad idea to reduce configurability. As Olaf said, you'll miss it the moment it's gone. (Someone will.) Non-GNU Solaris and Digital Unix aren't that hard to support with the current code if someone wanted to, for instance. Why make such a hypothetical someone's work harder? (Just an example, I'm sure there are other things.) Mika From jayk123 at hotmail.com Tue Dec 25 23:03:19 2007 From: jayk123 at hotmail.com (Jay) Date: Tue, 25 Dec 2007 22:03:19 +0000 Subject: [M3devel] PPC_DARWIN problems, at least config/5.2.6, maybe all moot In-Reply-To: <200712252147.lBPLl32p030684@camembert.async.caltech.edu> References: Your message of "Tue, 25 Dec 2007 12:09:31 GMT." <200712252147.lBPLl32p030684@camembert.async.caltech.edu> Message-ID: Other platforms should be supportable via cm3 directly eh? I'm just not sure of the value of extension/scripting languages in general, vs. having fewer languages. I very much like not having to compile/link such languages, the tendency toward having garbage collection and builtin collection classes, but I'm not sure which characteristics necessarily go together -- I strongly suspect you can have it all in one language -- static checking, fast compilation to native code, "built in" collection classes or a good library, etc. I don't care that much. You know, everything is configurable, it is a matter of how. What is in the code, what is in data, what is in non compiled code? (code is data and all that..) There does seem to be a line here but it is scientifically (lazily?) hard for me to discern. Regarding the problems with cm3.cfg.. I don't know. Just to backup a sec, I believe one of the "big" pieces of work that Critical Mass did was converting large swaths of Quake code into Modula-3, that code which, I assume, tended to be the same across all machines. Maybe it was just "utilities", maybe it was about perf. So what I wonder then, is if just a bit more shouldn't be done here. Have platforms converged such that less needs to be configurable? Or, then again, the cm3.cfg IS already fairly small. Maybe it is right about where it needs to be. Bigger fish to fry probably -- like, I noticed m3cg and as are run for every single file, maybe there is a gain to batching? (and win32 int64.....) So, back to cm3.cfg. It IS fairly small. Is it down to about what varies per platform? I haven't really surveyed them all.. - Jay > To: jayk123 at hotmail.com > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] PPC_DARWIN problems, at least config/5.2.6, maybe all moot > Date: Tue, 25 Dec 2007 13:47:03 -0800 > From: mika at async.caltech.edu > > Jay writes: > > > ... > > > >You know, I dare say, that platforms have been reduced and converged enough= > > such that..you can get rid of > >Quake and move it into cm3. Um.. do any of the Unix platforms support other= > > than gcc? Other than GNU ld? > > I take it you don't mean "get rid of Quake" but "get rid of cm3.cfg"? > I would certainly agree that cm3.cfg is problematic. I have more > than once had apparently unresolvable issues with CM3 that Tony > fixed by sending me a new cm3.cfg, which came, seemingly, out of a > hat... > > However I also would think it's a bad idea to reduce configurability. > As Olaf said, you'll miss it the moment it's gone. (Someone will.) > Non-GNU Solaris and Digital Unix aren't that hard to support with > the current code if someone wanted to, for instance. Why make such a > hypothetical someone's work harder? (Just an example, I'm sure there > are other things.) > > Mika _________________________________________________________________ Don't get caught with egg on your face. Play Chicktionary! http://club.live.com/chicktionary.aspx?icid=chick_wlhmtextlink1_dec -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Dec 26 05:14:15 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 25 Dec 2007 23:14:15 -0500 Subject: [M3devel] PPC_DARWIN problems, at least config/5.2.6, maybe all moot In-Reply-To: References: Your message of "Tue, 25 Dec 2007 12:09:31 GMT." <200712252147.lBPLl32p030684@camembert.async.caltech.edu> Message-ID: <4A78DF83-6CBF-43AB-AEE0-6E1E25ACDE39@cs.purdue.edu> On Dec 25, 2007, at 5:03 PM, Jay wrote: > Is it down to about what varies per platform? Yes, pretty much... > > I haven't really surveyed them all.. > > - Jay > > > To: jayk123 at hotmail.com > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] PPC_DARWIN problems, at least config/ > 5.2.6, maybe all moot > > Date: Tue, 25 Dec 2007 13:47:03 -0800 > > From: mika at async.caltech.edu > > > > Jay writes: > > > > > ... > > > > > >You know, I dare say, that platforms have been reduced and > converged enough= > > > such that..you can get rid of > > >Quake and move it into cm3. Um.. do any of the Unix platforms > support other= > > > than gcc? Other than GNU ld? > > > > I take it you don't mean "get rid of Quake" but "get rid of > cm3.cfg"? > > I would certainly agree that cm3.cfg is problematic. I have more > > than once had apparently unresolvable issues with CM3 that Tony > > fixed by sending me a new cm3.cfg, which came, seemingly, out of a > > hat... > > > > However I also would think it's a bad idea to reduce > configurability. > > As Olaf said, you'll miss it the moment it's gone. (Someone will.) > > Non-GNU Solaris and Digital Unix aren't that hard to support with > > the current code if someone wanted to, for instance. Why make such a > > hypothetical someone's work harder? (Just an example, I'm sure there > > are other things.) > > > > Mika > > Don't get caught with egg on your face. Play Chicktionary! Check it > out! From hosking at cs.purdue.edu Wed Dec 26 05:17:56 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 25 Dec 2007 23:17:56 -0500 Subject: [M3devel] PPC_DARWIN problems, at least config/5.2.6, maybe all moot In-Reply-To: References: Message-ID: On Dec 25, 2007, at 3:32 PM, Jay wrote: > 1) > > The documentation says -fPIC is the default, so I removed it. > But it matters. It doesn't matter for gcc building C. > It matters for m3cg building Modula-3. Please note that m3cg is based on the GNU release of gcc, *not* the Darwin version. Thus, even though Darwin might have -fPIC as default for Apple's gcc, GNU gcc might not. > It is the difference between, pic: > > jbook:/dev2/j/m3 jay$ cat Hello.m3 > MODULE Hello EXPORTS Main; > > IMPORT IO; > BEGIN > IO.Put("Hello\n"); > END Hello. > > jbook:/dev2/j/m3 jay$ cat PPC_DARWIN/Hello.ms > ... > bl L_IO__Put$stub > ... > .data > .picsymbol_stub > L_IO__Put$stub: > .indirect_symbol _IO__Put > mflr r0 > bcl 20,31,L0$_IO__Put > L0$_IO__Put: > mflr r11 > addis r11,r11,ha16(L_IO__Put$lazy_ptr-L0$_IO__Put) > mtlr r0 > lwz r12,lo16(L_IO__Put$lazy_ptr-L0$_IO__Put)(r11) > mtctr r12 > addi r11,r11,lo16(L_IO__Put$lazy_ptr-L0$_IO__Put) > bctr > .data > .lazy_symbol_pointer > L_IO__Put$lazy_ptr: > .indirect_symbol _IO__Put > .long dyld_stub_binding_helper > > vs. non-pic just plain wow only one whole function to make a call :) : > > jbook:/dev2/j/m3 jay$ cat PPC_DARWIN/Hello.ms > ... > bl _IO__Put > > which nets you the likes of: > > jbook:/dev2/j/m3 jay$ cm3 > -> linking prog > gcc -dynamic -o prog _m3main.o Hello.mo -L/cm3/pkg/libm3/ > PPC_DARWIN -lm3 -L/cm3/pkg/m3core/PPC_DARWIN -lm3core -L/cm3/bin/../ > lib -lm3gcdefs > /usr/bin/ld: _m3main.o has external relocation entries in non- > writable section (__TEXT,__text) for symbols: > _RTProcess__Exit > _RTLinker__AddUnit > _RTLinker__InitRuntime > collect2: ld returned 1 exit status > > > (Windows also only uses one instruction, through a pointer, for > dynamic calls, and the compiler often prefetches the pointer. > The difference is, perhaps, that Windows aggregates all the > pointers together, not sure about the other systems.. one instruction > through a pointer is true for x86 and AM64, not so of the former > MIPS, PowerPC, Alpha I believe or current IA64, those > require fetching/restore the GOT/TOC (same thing? I should know the > difference..) > > 2) > Splitting -L and -l off for shared libs matters. > > ld /foo/bar.a means link to bar.a, which is a static lib, not even > a stub lib or import lib like in Windows > > -L/foo -lbar probes for > /foo/bar.dylib > /foo/bar.a > > man ld: > -lx This option is an abbreviation for the library > name `libx.a', > where x is a string. If -dynamic is specified the > abbreviation > for the library name is first search as > `libx.dylib' and then > `libx.a' is searched for. ld searches for > libraries first in > any directories specified with -L options, then in > any directo- > ries specified in the colon separated set of paths in > the envi- > ronment variable LD_LIBRARY_PATH, then the standard > directories > /lib, /usr/lib, and /usr/local/lib. A library is > searched when > its name is encountered, so the placement of the -l > flag is sig- > nificant. If string x is of the form x.o, then > that file is > searched for in the same places, but without > prepending `lib' or > appending `.a' or `.dylib' to the filename. > > > 3) > lastly, setting DYLD_LIBRARY_PATH=/cm3/lib > lets the full paths from one machine not matter so much on another > machine. > > I am going to try out: > > before: > local lib_so = format ("lib%s.dylib", lib) > local lib_soxx = format ("lib%s.%s.dylib", lib, version) > local lib_pn = LIB_INSTALL & "/" & lib_soxx > > "-install_name", lib_pn, > > after: > > local lib_so = format ("lib%s.dylib", lib) > local lib_soxx = format ("lib%s.%s.dylib", lib, version) > local lib_pn = LIB_INSTALL & "/" & lib_soxx > > "-install_name", lib_soxx, > > see if a path is needed or can just use leaf names. > > - Jay > > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: PPC_DARWIN problems, at least config/5.2.6, maybe all moot > Date: Tue, 25 Dec 2007 12:09:31 +0000 > > PPC_DARWIN also has problems...at least in the config. > > > If you take the 5.2.6 archive, install to /dev2/cm3, accept the > defaults, > claim all the missing unused libs are in /usr/lib (opengl, > postgres, x11) > > > you end up with: > > > jbook:/dev2/j/m3 jay$ cat Hello.m3 > > > MODULE Hello EXPORTS Main; > IMPORT IO; > BEGIN > IO.Put("Hello\n"); > END Hello. > > > jbook:/dev2/j/m3 jay$ uname -a > Darwin jbook 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 > 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh > powerpc > > > jbook:/dev2/j/m3 jay$ cm3 -version > Critical Mass Modula-3 version 5.2.6 > last updated: 2003-06-27 > configuration: /cm3/bin/cm3.cfg > > > jbook:/dev2/j/m3 jay$ cm3 > new source -> compiling Hello.m3 > -> linking prog > > > jbook:/dev2/j/m3 jay$ PPC_DARWIN/prog > dyld: Library not loaded: /var/tmp/cm3/lib/libm3.5.2.dylib > Referenced from: /dev2/j/m3/PPC_DARWIN/prog > Reason: image not found > Trace/BPT trap > > > jbook:/dev2/j/m3 jay$ otool -L PPC_DARWIN/prog > PPC_DARWIN/prog: > /var/tmp/cm3/lib/libm3.5.2.dylib (compatibility version > 5.0.0, current version 5.2.0) > /Users/wagner/local/cm3/lib/libm3core.5.2.dylib > (compatibility version 5.0.0, current version 5.2.0) > /Users/wagner/local/cm3/lib/libm3gcdefs.5.2.dylib > (compatibility version 5.0.0, current version 5.2.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > current version 88.1.10) > /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, > current version 1.0.0) > > > jbook:/dev2/j/m3 jay$ ls -l PPC_DARWIN/prog > -rwxr-xr-x 1 jay admin 20264 Dec 25 04:43 PPC_DARWIN/prog > > > At the temporary cost of giving up dynamic linking, you can fix > this by removing M3_SPLIT_LIBNAMES_IF_SHARED > and/or M3_SPLIT_LIBNAMES from cm3.cfg, yielding: > > > jbook:/dev2/j/m3 jay$ otool -L PPC_DARWIN/prog > PPC_DARWIN/prog: > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > current version 88.1.10) > > > jbook:/dev2/j/m3 jay$ ls -l PPC_DARWIN/prog > -rwxr-xr-x 1 jay admin 1388380 Dec 25 04:48 PPC_DARWIN/prog > > > jbook:/dev2/j/m3 jay$ PPC_DARWIN/prog > Hello > > > I will fix the checked in config file...even though it varies a > bunch from the 5.2.6 distributed > config, it results in the same. > > > And, um, does everyone understand what I did with Win32 and making > cminstall obsolete? > Ok to do the same on Mac OS X? > You know, it's running things out of the path and/or finding them > in their "very standard" locations. > In fact, you can hard code full paths and be ok. > That is, instead of asking the user where their compiler is, > hardcoding any of cc, gcc, /usr/bin/cc, /usr/bin/gcc all work fine. > Asking them where ar/ranlib are, similar, though the docs say that > libtool replaced those, and ar/ranlib vs. libtool is one way > in which the checked in config and the 5.2.6 distribution's config > vary. I'll try for libtool. > > > The only thing the user really needs to decide is where to install > to, and > the cfg file can discover their choice without any editing. > > > INSTALL_ROOT = path() & "/.." > BIN_INSTALL = path() % executables > > > In terms of wanting to provide some configurable redirection, well, > I think an advanced user can manage.. > An indirect SYSTEM_CC = "cc" can be left, I guess. > > > You know, I dare say, that platforms have been reduced and > converged enough such that..you can get rid of > Quake and move it into cm3. Um.. do any of the Unix platforms > support other than gcc? Other than GNU ld? > Ok, Apple ld is not GNU ld. (Geez, it is just me or is Apple an > incredible hodgepodge mess these days? > I mean both in terms of their "system architecture" and their > tools. The "system architecture" reveals bunches > of similar redundant subsystems. Try reading through man ld, man > ranlib, just try to understand which > flag goes with which mode, which flags are for compatibility with > which OS version, and which of the > compatibility flags is either ignored or does something useful... > and should I say -lGL or -framework OpenGL??) > > > That I don't haven't adjusted to Modula-3 and don't mind/prefer > writing Quake instead. :) > > > Some bootstrap was provided. I should look at it, and its config. > Otherwise..I'll look into what it takes to build it all and with > dynamic linking. > Perhaps the bootstrap is just fine. But the checked in config is not. > > > - Jay > > Share life as it happens with the new Windows Live. Share now! > Share life as it happens with the new Windows Live. Share now! From jayk123 at hotmail.com Wed Dec 26 06:51:04 2007 From: jayk123 at hotmail.com (Jay) Date: Wed, 26 Dec 2007 05:51:04 +0000 Subject: [M3devel] PPC_DARWIN problems, at least config/5.2.6, maybe all moot In-Reply-To: References: Message-ID: Oh, very good point. "gcc" is Apple and resembles "man gcc", "m3cg" not.. - Jay > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > Subject: Re: [M3devel] PPC_DARWIN problems, at least config/5.2.6, maybe all moot > Date: Tue, 25 Dec 2007 23:17:56 -0500 > To: jayk123 at hotmail.com > > > On Dec 25, 2007, at 3:32 PM, Jay wrote: > > > 1) > > > > The documentation says -fPIC is the default, so I removed it. > > But it matters. It doesn't matter for gcc building C. > > It matters for m3cg building Modula-3. > > Please note that m3cg is based on the GNU release of gcc, *not* the > Darwin version. Thus, even though Darwin might have -fPIC as default > for Apple's gcc, GNU gcc might not. > > > It is the difference between, pic: > > > > jbook:/dev2/j/m3 jay$ cat Hello.m3 > > MODULE Hello EXPORTS Main; > > > > IMPORT IO; > > BEGIN > > IO.Put("Hello\n"); > > END Hello. > > > > jbook:/dev2/j/m3 jay$ cat PPC_DARWIN/Hello.ms > > ... > > bl L_IO__Put$stub > > ... > > .data > > .picsymbol_stub > > L_IO__Put$stub: > > .indirect_symbol _IO__Put > > mflr r0 > > bcl 20,31,L0$_IO__Put > > L0$_IO__Put: > > mflr r11 > > addis r11,r11,ha16(L_IO__Put$lazy_ptr-L0$_IO__Put) > > mtlr r0 > > lwz r12,lo16(L_IO__Put$lazy_ptr-L0$_IO__Put)(r11) > > mtctr r12 > > addi r11,r11,lo16(L_IO__Put$lazy_ptr-L0$_IO__Put) > > bctr > > .data > > .lazy_symbol_pointer > > L_IO__Put$lazy_ptr: > > .indirect_symbol _IO__Put > > .long dyld_stub_binding_helper > > > > vs. non-pic just plain wow only one whole function to make a call :) : > > > > jbook:/dev2/j/m3 jay$ cat PPC_DARWIN/Hello.ms > > ... > > bl _IO__Put > > > > which nets you the likes of: > > > > jbook:/dev2/j/m3 jay$ cm3 > > -> linking prog > > gcc -dynamic -o prog _m3main.o Hello.mo -L/cm3/pkg/libm3/ > > PPC_DARWIN -lm3 -L/cm3/pkg/m3core/PPC_DARWIN -lm3core -L/cm3/bin/../ > > lib -lm3gcdefs > > /usr/bin/ld: _m3main.o has external relocation entries in non- > > writable section (__TEXT,__text) for symbols: > > _RTProcess__Exit > > _RTLinker__AddUnit > > _RTLinker__InitRuntime > > collect2: ld returned 1 exit status > > > > > > (Windows also only uses one instruction, through a pointer, for > > dynamic calls, and the compiler often prefetches the pointer. > > The difference is, perhaps, that Windows aggregates all the > > pointers together, not sure about the other systems.. one instruction > > through a pointer is true for x86 and AM64, not so of the former > > MIPS, PowerPC, Alpha I believe or current IA64, those > > require fetching/restore the GOT/TOC (same thing? I should know the > > difference..) > > > > 2) > > Splitting -L and -l off for shared libs matters. > > > > ld /foo/bar.a means link to bar.a, which is a static lib, not even > > a stub lib or import lib like in Windows > > > > -L/foo -lbar probes for > > /foo/bar.dylib > > /foo/bar.a > > > > man ld: > > -lx This option is an abbreviation for the library > > name `libx.a', > > where x is a string. If -dynamic is specified the > > abbreviation > > for the library name is first search as > > `libx.dylib' and then > > `libx.a' is searched for. ld searches for > > libraries first in > > any directories specified with -L options, then in > > any directo- > > ries specified in the colon separated set of paths in > > the envi- > > ronment variable LD_LIBRARY_PATH, then the standard > > directories > > /lib, /usr/lib, and /usr/local/lib. A library is > > searched when > > its name is encountered, so the placement of the -l > > flag is sig- > > nificant. If string x is of the form x.o, then > > that file is > > searched for in the same places, but without > > prepending `lib' or > > appending `.a' or `.dylib' to the filename. > > > > > > 3) > > lastly, setting DYLD_LIBRARY_PATH=/cm3/lib > > lets the full paths from one machine not matter so much on another > > machine. > > > > I am going to try out: > > > > before: > > local lib_so = format ("lib%s.dylib", lib) > > local lib_soxx = format ("lib%s.%s.dylib", lib, version) > > local lib_pn = LIB_INSTALL & "/" & lib_soxx > > > > "-install_name", lib_pn, > > > > after: > > > > local lib_so = format ("lib%s.dylib", lib) > > local lib_soxx = format ("lib%s.%s.dylib", lib, version) > > local lib_pn = LIB_INSTALL & "/" & lib_soxx > > > > "-install_name", lib_soxx, > > > > see if a path is needed or can just use leaf names. > > > > - Jay > > > > From: jayk123 at hotmail.com > > To: m3devel at elegosoft.com > > Subject: PPC_DARWIN problems, at least config/5.2.6, maybe all moot > > Date: Tue, 25 Dec 2007 12:09:31 +0000 > > > > PPC_DARWIN also has problems...at least in the config. > > > > > > If you take the 5.2.6 archive, install to /dev2/cm3, accept the > > defaults, > > claim all the missing unused libs are in /usr/lib (opengl, > > postgres, x11) > > > > > > you end up with: > > > > > > jbook:/dev2/j/m3 jay$ cat Hello.m3 > > > > > > MODULE Hello EXPORTS Main; > > IMPORT IO; > > BEGIN > > IO.Put("Hello\n"); > > END Hello. > > > > > > jbook:/dev2/j/m3 jay$ uname -a > > Darwin jbook 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 > > 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh > > powerpc > > > > > > jbook:/dev2/j/m3 jay$ cm3 -version > > Critical Mass Modula-3 version 5.2.6 > > last updated: 2003-06-27 > > configuration: /cm3/bin/cm3.cfg > > > > > > jbook:/dev2/j/m3 jay$ cm3 > > new source -> compiling Hello.m3 > > -> linking prog > > > > > > jbook:/dev2/j/m3 jay$ PPC_DARWIN/prog > > dyld: Library not loaded: /var/tmp/cm3/lib/libm3.5.2.dylib > > Referenced from: /dev2/j/m3/PPC_DARWIN/prog > > Reason: image not found > > Trace/BPT trap > > > > > > jbook:/dev2/j/m3 jay$ otool -L PPC_DARWIN/prog > > PPC_DARWIN/prog: > > /var/tmp/cm3/lib/libm3.5.2.dylib (compatibility version > > 5.0.0, current version 5.2.0) > > /Users/wagner/local/cm3/lib/libm3core.5.2.dylib > > (compatibility version 5.0.0, current version 5.2.0) > > /Users/wagner/local/cm3/lib/libm3gcdefs.5.2.dylib > > (compatibility version 5.0.0, current version 5.2.0) > > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > > current version 88.1.10) > > /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, > > current version 1.0.0) > > > > > > jbook:/dev2/j/m3 jay$ ls -l PPC_DARWIN/prog > > -rwxr-xr-x 1 jay admin 20264 Dec 25 04:43 PPC_DARWIN/prog > > > > > > At the temporary cost of giving up dynamic linking, you can fix > > this by removing M3_SPLIT_LIBNAMES_IF_SHARED > > and/or M3_SPLIT_LIBNAMES from cm3.cfg, yielding: > > > > > > jbook:/dev2/j/m3 jay$ otool -L PPC_DARWIN/prog > > PPC_DARWIN/prog: > > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > > current version 88.1.10) > > > > > > jbook:/dev2/j/m3 jay$ ls -l PPC_DARWIN/prog > > -rwxr-xr-x 1 jay admin 1388380 Dec 25 04:48 PPC_DARWIN/prog > > > > > > jbook:/dev2/j/m3 jay$ PPC_DARWIN/prog > > Hello > > > > > > I will fix the checked in config file...even though it varies a > > bunch from the 5.2.6 distributed > > config, it results in the same. > > > > > > And, um, does everyone understand what I did with Win32 and making > > cminstall obsolete? > > Ok to do the same on Mac OS X? > > You know, it's running things out of the path and/or finding them > > in their "very standard" locations. > > In fact, you can hard code full paths and be ok. > > That is, instead of asking the user where their compiler is, > > hardcoding any of cc, gcc, /usr/bin/cc, /usr/bin/gcc all work fine. > > Asking them where ar/ranlib are, similar, though the docs say that > > libtool replaced those, and ar/ranlib vs. libtool is one way > > in which the checked in config and the 5.2.6 distribution's config > > vary. I'll try for libtool. > > > > > > The only thing the user really needs to decide is where to install > > to, and > > the cfg file can discover their choice without any editing. > > > > > > INSTALL_ROOT = path() & "/.." > > BIN_INSTALL = path() % executables > > > > > > In terms of wanting to provide some configurable redirection, well, > > I think an advanced user can manage.. > > An indirect SYSTEM_CC = "cc" can be left, I guess. > > > > > > You know, I dare say, that platforms have been reduced and > > converged enough such that..you can get rid of > > Quake and move it into cm3. Um.. do any of the Unix platforms > > support other than gcc? Other than GNU ld? > > Ok, Apple ld is not GNU ld. (Geez, it is just me or is Apple an > > incredible hodgepodge mess these days? > > I mean both in terms of their "system architecture" and their > > tools. The "system architecture" reveals bunches > > of similar redundant subsystems. Try reading through man ld, man > > ranlib, just try to understand which > > flag goes with which mode, which flags are for compatibility with > > which OS version, and which of the > > compatibility flags is either ignored or does something useful... > > and should I say -lGL or -framework OpenGL??) > > > > > > That I don't haven't adjusted to Modula-3 and don't mind/prefer > > writing Quake instead. :) > > > > > > Some bootstrap was provided. I should look at it, and its config. > > Otherwise..I'll look into what it takes to build it all and with > > dynamic linking. > > Perhaps the bootstrap is just fine. But the checked in config is not. > > > > > > - Jay > > > > Share life as it happens with the new Windows Live. Share now! > > Share life as it happens with the new Windows Live. Share now! > _________________________________________________________________ The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. http://www.xbox.com/en-US/hardware/wheretobuy/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Dec 26 06:55:22 2007 From: jayk123 at hotmail.com (Jay) Date: Wed, 26 Dec 2007 05:55:22 +0000 Subject: [M3devel] when to change version numbers in .dlls/.sos/.dylibs? In-Reply-To: References: Message-ID: There's a mix of versions in the configurations. Presumably at the moment they should all be 5.5 and derive from one shared statement of the version??? jbook:/dev2/cm3/m3-sys/cminstall/src/config jay$ grep %s.dylib * I386_DARWIN: local lib_so = format ("lib%s.dylib", lib) I386_DARWIN: local lib_sox = format ("lib%s.%s.dylib", lib, vmaj) I386_DARWIN: local lib_soxx = format ("lib%s.%s.dylib", lib, version) I386_DARWIN: local lib_so = format ("lib%s.dylib", lib) I386_DARWIN: local lib_sox = format ("lib%s.%s.dylib", lib, vmaj) I386_DARWIN: local lib_soxx = format ("lib%s.%s.dylib", lib, version) PPC_DARWIN: local lib_so = format ("lib%s.dylib", lib) PPC_DARWIN: local lib_sox = format ("lib%s.%s.dylib", lib, vmaj) PPC_DARWIN: local lib_soxx = format ("lib%s.%s.dylib", lib, version) PPC_DARWIN: local lib_so = format ("lib%s.dylib", lib) PPC_DARWIN: local lib_sox = format ("lib%s.%s.dylib", lib, vmaj) PPC_DARWIN: local lib_soxx = format ("lib%s.%s.dylib", lib, version) jbook:/dev2/cm3/m3-sys/cminstall/src/config jay$ grep so.1 * SPARC: local lib_so = format ("lib%s.so.1.1", lib) SPARC: local lib_so = format ("lib%s.so.1.1", lib) jbook:/dev2/cm3/m3-sys/cminstall/src/config jay$ grep so.4 * LINUXELF: local lib_sox = format ("lib%s.so.4", lib) LINUXELF: local lib_soxx = format ("lib%s.so.4.1", lib) LINUXELF: local lib_sox = format ("lib%s.so.4", lib) LINUXELF: local lib_soxx = format ("lib%s.so.4.1", lib) jbook:/dev2/cm3/m3-sys/cminstall/src/config jay$ grep so.5 * FreeBSD3: local lib_sox = format ("lib%s.so.5", lib) FreeBSD3: local lib_soxx = format ("lib%s.so.5.1", lib) FreeBSD3: local lib_sox = format ("lib%s.so.5", lib) FreeBSD4: local lib_sox = format ("lib%s.so.5", lib) FreeBSD4: local lib_soxx = format ("lib%s.so.5.1", lib) FreeBSD4: local lib_sox = format ("lib%s.so.5", lib) LINUXLIBC6: local lib_sox = format ("lib%s.so.5", lib) LINUXLIBC6: local lib_sox = format ("lib%s.so.5", lib) NT386GNU: local lib_sox = format ("lib%s.so.5", lib) NT386GNU: local lib_sox = format ("lib%s.so.5", lib) NetBSD2_i386: local lib_sox = format ("lib%s.so.5", lib) NetBSD2_i386: local lib_soxx = format ("lib%s.so.5.1", lib) NetBSD2_i386: local lib_sox = format ("lib%s.so.5", lib) NetBSD2_i386: local lib_soxx = format ("lib%s.so.5.1", lib) PPC_LINUX: local lib_sox = format ("lib%s.so.5", lib) PPC_LINUX: local lib_sox = format ("lib%s.so.5", lib) SOLgnu: local lib_sox = format ("lib%s.so.5", lib) SOLgnu: local lib_sox = format ("lib%s.so.5", lib) SOLsun: local lib_sox = format ("lib%s.so.5", lib) SOLsun: local lib_sox = format ("lib%s.so.5", lib) _________________________________________________________________ The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. http://www.xbox.com/en-US/hardware/wheretobuy/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Dec 28 09:25:21 2007 From: jayk123 at hotmail.com (Jay) Date: Fri, 28 Dec 2007 08:25:21 +0000 Subject: [M3devel] wierdness around user overrides vs. uname in sysinfo.sh? Message-ID: I wanted to change upgrade.sh to have the following features: 1) optionally skip building m3cc, since it is the slowest part 2) optionally clean between various steps, as was apparently necessary for me I really cannot hack sh though. Sorry. I've tried several times through the years. I just can't stand these languages where pretty much everything is a string. e.g. sh, Tcl, cmd. I admit hypocrisy in that I can and have hacked cmd. So I started rewriting scripts/* in Python. I'm not going to delete scripts/*.sh or anything THAT obnoxious (and get my access revoked), just add a new scripts/python directory. Tempting to call it scripts/jay. I'm making good progess here. Actually I started with Perl, which I have more experience with, but it was frustrating and... Anyway, so the real point here is, I'm reading scripts/* fairly closely. I'd like to at times bounce my interpretation off folks. In particular, I detect some wierdness. Most variables can be set by the caller. I assume that is mostly meant for the user to override things. I agree that is mostly a good thing. However it seems often data is derived, and then later overrides can kick in. In particular, sysinfo.sh sets, e.g. M3OSTYPE and other data based on uname. And it sets CM3_TARGET. But TARGET is then set via the user override, or CM3_TARGET if no user override. I draw one of two conclusions: If a user sets TARGET, such as for a cross build, then user darn well better set other variables manually to. OR sysinfo.sh ought to check for TARGET being set, and derive data from that. It should check preset TARGET or uname, not both. I'm just going to leave it alone. Presumably mostly the overrides are never set. They are mainly for cross builds and/or bringing up new targets probably. There aren't THAT MANY variables anyway. Many could be removed, such as TAR, GREP, CM3*SEARCHPATH, etc. Some are only for Win32. Maybe after this I'll try rewriting scripts in Quake. :) - Jay _________________________________________________________________ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_122007 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Dec 28 11:19:53 2007 From: jayk123 at hotmail.com (Jay) Date: Fri, 28 Dec 2007 10:19:53 +0000 Subject: [M3devel] wierdness around user overrides vs. uname in sysinfo.sh? In-Reply-To: References: Message-ID: hm. another odd email truncation Let me try again.. I wanted to change upgrade.sh to have the following features: 1) optionally skip building m3cc, since it is the slowest part 2) optionally clean between various steps, as was apparently necessary for me I really cannot hack sh though. Sorry. I've tried several times through the years. I just can't stand these languages where pretty much everything is a string. e.g. sh, Tcl, cmd. I admit hypocrisy in that I can and have hacked cmd. So I started rewriting scripts/* in Python. I'm not going to delete scripts/*.sh or anything THAT obnoxious (and get my access revoked), just add a new scripts/python directory. Tempting to call it scripts/jay. I'm making good progess here. Actually I started with Perl, which I have more experience with, but it was frustrating and... Anyway, so the real point here is, I'm reading scripts/* fairly closely (I can read sh well enough.) I'd like to at times bounce my interpretation off folks. In particular, I detect some wierdness. Most variables can be set by the caller. I assume that is mostly meant for the user to override things. I agree that is mostly a good thing. However it seems often data is derived, and then later overrides can kick in. In particular, sysinfo.sh sets, e.g. M3OSTYPE and other data based on uname. And it sets CM3_TARGET. But TARGET is then set via the user override, or CM3_TARGET if no user override. I draw one of two conclusions: If a user sets TARGET, such as for a cross build, then user darn well better set other variables manually too. OR sysinfo.sh ought to check for TARGET being set, and derive data from that. It should check preset TARGET or uname, not both. I'm just going to leave it alone. Presumably mostly the overrides are never set. They are mainly for cross builds and/or bringing up new targets probably. There aren't THAT MANY variables anyway. Many could be removed, such as TAR, GREP, CM3*SEARCHPATH, etc. Some are only for Win32. Maybe after this I'll try rewriting scripts in Quake. :) - Jay _________________________________________________________________ The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. http://www.xbox.com/en-US/hardware/wheretobuy/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Dec 28 12:13:43 2007 From: jayk123 at hotmail.com (Jay) Date: Fri, 28 Dec 2007 11:13:43 +0000 Subject: [M3devel] wierdness around user overrides vs. uname in sysinfo.sh? In-Reply-To: References: Message-ID: wierd.still shows as truncated for me Trying again with a different browser.. I wanted to change upgrade.sh to have the following features: 1) optionally skip building m3cc, since it is the slowest part 2) optionally clean between various steps, as was apparently necessary for me I really cannot hack sh though. Sorry. I've tried several times through the years. I just can't stand these languages where pretty much everything is a string. e.g. sh, Tcl, cmd. I admit hypocrisy in that I can and have hacked cmd. So I started rewriting scripts/* in Python. I'm not going to delete scripts/*.sh or anything THAT obnoxious (and get my access revoked), just add a new scripts/python directory. Tempting to call it scripts/jay. I'm making good progess here. Actually I started with Perl, which I have more experience with, but it was frustrating and... Anyway, so the real point here is, I'm reading scripts/* fairly closely. I'd like to at times bounce my interpretation off folks. In particular, I detect some massive wierdness. Most variables can be set by the caller. I assume that is mostly meant for the user to override things. I agree that is mostly a good thing. However it seems often data is derived, and then later overrides can kick in. In particular, sysinfo.sh sets, e.g. M3OSTYPE and other data based on uname. And it sets CM3_TARGET. But TARGET is then set via the user override, or CM3_TARGET if no user override. I draw one of two conclusions: If a user sets TARGET, such as for a cross build, then user darn well better set other variables manually to. OR sysinfo.sh ought to check for TARGET being set, and derive data from that. It should check preset TARGET or uname, not both. I'm just going to leave it alone. Presumably mostly the overrides are never set. They are mainly for cross builds and/or bringing up new targets probably. There aren't THAT MANY variables anyway. Many could be removed, such as TAR, GREP, CM3*SEARCHPATH, etc. Some are only for Win32. Maybe after this I'll try rewriting scripts in Quake. :) - Jay _________________________________________________________________ The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. http://www.xbox.com/en-US/hardware/wheretobuy/ From jayk123 at hotmail.com Fri Dec 28 12:13:44 2007 From: jayk123 at hotmail.com (Jay) Date: Fri, 28 Dec 2007 11:13:44 +0000 Subject: [M3devel] wierdness around user overrides vs. uname in sysinfo.sh? In-Reply-To: References: Message-ID: wierd.still shows as truncated for me Trying again with a different browser.. I wanted to change upgrade.sh to have the following features: 1) optionally skip building m3cc, since it is the slowest part 2) optionally clean between various steps, as was apparently necessary for me I really cannot hack sh though. Sorry. I've tried several times through the years. I just can't stand these languages where pretty much everything is a string. e.g. sh, Tcl, cmd. I admit hypocrisy in that I can and have hacked cmd. So I started rewriting scripts/* in Python. I'm not going to delete scripts/*.sh or anything THAT obnoxious (and get my access revoked), just add a new scripts/python directory. Tempting to call it scripts/jay. I'm making good progess here. Actually I started with Perl, which I have more experience with, but it was frustrating and... Anyway, so the real point here is, I'm reading scripts/* fairly closely. I'd like to at times bounce my interpretation off folks. In particular, I detect some massive wierdness. Most variables can be set by the caller. I assume that is mostly meant for the user to override things. I agree that is mostly a good thing. However it seems often data is derived, and then later overrides can kick in. In particular, sysinfo.sh sets, e.g. M3OSTYPE and other data based on uname. And it sets CM3_TARGET. But TARGET is then set via the user override, or CM3_TARGET if no user override. I draw one of two conclusions: If a user sets TARGET, such as for a cross build, then user darn well better set other variables manually to. OR sysinfo.sh ought to check for TARGET being set, and derive data from that. It should check preset TARGET or uname, not both. I'm just going to leave it alone. Presumably mostly the overrides are never set. They are mainly for cross builds and/or bringing up new targets probably. There aren't THAT MANY variables anyway. Many could be removed, such as TAR, GREP, CM3*SEARCHPATH, etc. Some are only for Win32. Maybe after this I'll try rewriting scripts in Quake. :) - Jay _________________________________________________________________ Don't get caught with egg on your face. Play Chicktionary! http://club.live.com/chicktionary.aspx?icid=chick_wlhmtextlink1_dec From jayk123 at hotmail.com Fri Dec 28 12:17:53 2007 From: jayk123 at hotmail.com (Jay) Date: Fri, 28 Dec 2007 11:17:53 +0000 Subject: [M3devel] =?windows-1256?q?_Re=3A__wierdness_around_user_override?= =?windows-1256?q?s_vs=2E_uname_in_sysinfo=2Esh=3F=FE?= In-Reply-To: References: Message-ID: [another tactic attempted...] ---------------------------------------- > From: jayk123 at hotmail.com > To: jayk123 at hotmail.com > Subject: test > Date: Fri, 28 Dec 2007 11:15:58 +0000 > > > I wanted to change upgrade.sh to have the following features: > > 1) optionally skip building m3cc, since it is the slowest part > > 2) optionally clean between various steps, as was apparently necessary for me > > I really cannot hack sh though. Sorry. I've tried several times through the years. > I just can't stand these languages where pretty much everything is a string. > e.g. sh, Tcl, cmd. > I admit hypocrisy in that I can and have hacked cmd. > > So I started rewriting scripts/* in Python. > I'm not going to delete scripts/*.sh or anything THAT obnoxious (and get my > access revoked), just add a new scripts/python directory. > Tempting to call it scripts/jay. > I'm making good progess here. > > Actually I started with Perl, which I have more experience with, but > it was frustrating and... > > Anyway, so the real point here is, I'm reading scripts/* fairly closely. > > I'd like to at times bounce my interpretation off folks. > > In particular, I detect some massive wierdness. > > Most variables can be set by the caller. > I assume that is mostly meant for the user to override things. > I agree that is mostly a good thing. > > However it seems often data is derived, and then later overrides can kick in. > > In particular, sysinfo.sh sets, e.g. M3OSTYPE and other data based on uname. > And it sets CM3_TARGET. > But TARGET is then set via the user override, or CM3_TARGET if no user override. > > I draw one of two conclusions: > > If a user sets TARGET, such as for a cross build, then user darn well better > set other variables manually to. > > OR sysinfo.sh ought to check for TARGET being set, and derive data from that. > It should check preset TARGET or uname, not both. > > I'm just going to leave it alone. > > Presumably mostly the overrides are never set. > They are mainly for cross builds and/or bringing up new targets probably. > > There aren't THAT MANY variables anyway. > Many could be removed, such as TAR, GREP, CM3*SEARCHPATH, etc. > Some are only for Win32. > > Maybe after this I'll try rewriting scripts in Quake. :) > > - Jay > _________________________________________________________________ > Share life as it happens with the new Windows Live. > http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007 _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007 From wagner at elegosoft.com Fri Dec 28 17:35:40 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 28 Dec 2007 17:35:40 +0100 Subject: [M3devel] =?utf-8?q?wierdness_around_user_overrides_vs=2E_uname_i?= =?utf-8?b?biBzeXNpbmZvLnNoP+KAjw==?= In-Reply-To: References: Message-ID: <20071228173540.eesjz81kuso8okg4@mail.elegosoft.com> Quoting Jay : > > [another tactic attempted...] > > ---------------------------------------- >> From: jayk123 at hotmail.com >> To: jayk123 at hotmail.com >> Subject: test >> Date: Fri, 28 Dec 2007 11:15:58 +0000 >> >> >> I wanted to change upgrade.sh to have the following features: >> >> 1) optionally skip building m3cc, since it is the slowest part export OMIT_GCC=yes will do just that for all shell scripts, IIRC. >> 2) optionally clean between various steps, as was apparently >> necessary for me It should not be difficult to add that. Something like . "$ROOT/scripts/do-cm3-core.sh" realclean || exit 1 should do the trick. >> I really cannot hack sh though. Sorry. I've tried several times >> through the years. >> I just can't stand these languages where pretty much everything is a string. >> e.g. sh, Tcl, cmd. >> I admit hypocrisy in that I can and have hacked cmd. >> >> So I started rewriting scripts/* in Python. >> I'm not going to delete scripts/*.sh or anything THAT obnoxious (and get my >> access revoked), just add a new scripts/python directory. >> Tempting to call it scripts/jay. >> I'm making good progess here. No harm in that. You may either put the python scripts beside the shell scripts and simply call them *.py, or put them in a subdirectory python or py. Don't call it Jay. >> Actually I started with Perl, which I have more experience with, but >> it was frustrating and... >> >> Anyway, so the real point here is, I'm reading scripts/* fairly closely. >> >> I'd like to at times bounce my interpretation off folks. >> >> In particular, I detect some massive wierdness. >> >> Most variables can be set by the caller. >> I assume that is mostly meant for the user to override things. >> I agree that is mostly a good thing. >> >> However it seems often data is derived, and then later overrides >> can kick in. These are just some simple and useful scripts for maintenance; there was never an overall system design. >> In particular, sysinfo.sh sets, e.g. M3OSTYPE and other data based on uname. >> And it sets CM3_TARGET. >> But TARGET is then set via the user override, or CM3_TARGET if no >> user override. >> >> I draw one of two conclusions: >> >> If a user sets TARGET, such as for a cross build, then user darn well better >> set other variables manually to. >> >> OR sysinfo.sh ought to check for TARGET being set, and derive data >> from that. >> It should check preset TARGET or uname, not both. >> >> I'm just going to leave it alone. If you find obvious inconsistencies or mistakes, don't hesitate to suggest a correction. >> Presumably mostly the overrides are never set. >> They are mainly for cross builds and/or bringing up new targets probably. Cross building is the usual way of porting the compiler to a new target, so it's done more often than you might assume. I've done it lots of times. >> There aren't THAT MANY variables anyway. >> Many could be removed, such as TAR, GREP, CM3*SEARCHPATH, etc. >> Some are only for Win32. >> >> Maybe after this I'll try rewriting scripts in Quake. :) That would be interesting, too. But don't forget that all these scripts are just more or less simple tools for installation and maintenance; the important asset is in all the M3 code. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Fri Dec 28 17:55:16 2007 From: jayk123 at hotmail.com (Jay) Date: Fri, 28 Dec 2007 16:55:16 +0000 Subject: [M3devel] wierdness around user overrides vs. uname in sysinfo.sh? In-Reply-To: <20071228173540.eesjz81kuso8okg4@mail.elegosoft.com> References: <20071228173540.eesjz81kuso8okg4@mail.elegosoft.com> Message-ID: inline (but aggressively trimmed) > Date: Fri, 28 Dec 2007 17:35:40 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > > Quoting Jay : > > export OMIT_GCC=yes > > will do just that for all shell scripts, IIRC. Ah, thanks, will try that. > >> 2) optionally clean between various steps, as was apparently > >> necessary for me > > It should not be difficult to add that. Something like > > . "$ROOT/scripts/do-cm3-core.sh" realclean || exit 1 > > should do the trick. Yeah, I have that locally, but I wanted to make it an option since perhaps/apparently it isn't always needed, and therefore wastes time. And then I got all bogged down in how the command line parsing is shared and I didn't want to add a parameter to every script, and I couldn't figure out how to check the command line ahead of time and then remove what I recognize. Like, if I could assign empty strings to $1 or $2 or $3, would be nice..but seems not possible..and then it just comes back to my strong suspicion that sh just sucks and isn't worth the effort. > don't forget that all these scripts are just... > ...the important asset is in all the M3 code. I know...but... Modula-3 is really slow to grow on me.. this has actually been a very useful exercise in my long delayed adoption of Python. I got my dynamic linking/pic issues worked out and once I get to porting make-bin-dist I'll have it work like my Win32 version -- just a .tar.bz2 file that you extract in the install root or above the install root (still not sure about the archive's root being cm3 or cm3-version or within that).. really, cminstall seems pretty pointless... Index: upgrade.sh =================================================================== RCS file: /usr/cvs/cm3/scripts/upgrade.sh,v retrieving revision 1.3 diff -c -r1.3 upgrade.sh *** upgrade.sh 16 Dec 2007 17:56:24 -0000 1.3 --- upgrade.sh 28 Dec 2007 16:51:34 -0000 *************** *** 28,34 **** some accidental diff here.. *************** *** 50,61 **** --- 50,72 ---- P="${P} cm3" [ "${M3OSTYPE}" = "WIN32" ] && P="${P} mklib" + echo "$ROOT/scripts/do-pkg.sh" "$@" "realclean ${P}" + . "$ROOT/scripts/do-pkg.sh" "$@" "realclean" ${P} || exit 1 + + exit + echo "$ROOT/scripts/do-pkg.sh" "$@" "buildship ${P}" . "$ROOT/scripts/do-pkg.sh" "$@" "buildship" ${P} || exit 1 echo "$ROOT/scripts/install-cm3-compiler.sh" $OPTIONS upgrade "$ROOT/scripts/install-cm3-compiler.sh" $OPTIONS upgrade || exit 1 + echo "$ROOT/scripts/do-pkg.sh" "$@" "realclean ${P}" + . "$ROOT/scripts/do-pkg.sh" "$@" "realclean" ${P} || exit 1 + + echo "$ROOT/scripts/do-cm3-core.sh" "$@" "realclean" + . "$ROOT/scripts/do-cm3-core.sh" "$@" "realclean" || exit 1 + echo "$ROOT/scripts/do-cm3-core.sh" "$@" "buildship" . "$ROOT/scripts/do-cm3-core.sh" "$@" "buildship" || exit 1 - Jay _________________________________________________________________ i?m is proud to present Cause Effect, a series about real people making a difference. http://im.live.com/Messenger/IM/MTV/?source=text_Cause_Effect -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Dec 31 10:48:26 2007 From: jayk123 at hotmail.com (Jay) Date: Mon, 31 Dec 2007 09:48:26 +0000 Subject: [M3devel] cvs question: how to know what I have changed on my machine? In-Reply-To: <20071230163328.GB5689@elegosoft.com> References: <20071230163328.GB5689@elegosoft.com> Message-ID: I swear I looked for this on the web, several times. :) What is the right/fast way to see what I have changed in cvs? Is it really to go to the top of the tree and say cvs diff? Some source control system I have used, makes "checked in" filesread only, requires you to "check out", and keeps track of whatyou checked out.This model seems quite nice.There is a fallback if the network is needed and not available.It is a little annoying, the inevitable failed save, but it is well worth it. I've been doing cvs diff but it seem terribly inefficient. Same question for Subversion, though I haven't looked.It at least seems to rapidly know what I have changed, on my puny tree,and I know it also saves away all the originals, so diff is a client only operation. Oh another question -- how to view history?Like, what i keep doing is navigating to individual files on the web.It's fairly tedious.It'd be nice if checkins at right about the same time, with the same comment,where packaged up in the ui, like Perforce (well, for it, it is just one change)....I usually look at the diffs after commit, besides before. Thanks, - Jay _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Dec 31 21:29:59 2007 From: jayk123 at hotmail.com (Jay) Date: Mon, 31 Dec 2007 20:29:59 +0000 Subject: [M3devel] C/C++ interop/linking thoughts? Message-ID: C/C++ interop/linking thoughts? What are people's thoughts on interop with and C and C++? In particular, that of static linking C and C++ with Modula-3, in the same .dll/.so/.exe?Or that of loading a Modula-3 .dll/.so into a process that is otherwise just C and C++? I ask for NOT the most important of reasons. The Modula-3 dependency on the C runtime on Windows is pretty light, and it is in fact mostly for the startup code. The startup code doesn't do much. Mainly it runs C++ constructors/destructors. And C code can have initializers/cleanup. I think it might be interesting to drive this dependency to zero, but it depends on expectations of C and C++ statically linked into a Modula-3 .dll/.so/.exe working. I know there is C code in the system already. It is light. It works without the startup code in my experience. I already changed Modula-3 .dlls to build with /noentry..exes take a bit more.It's in the config file. There are comments in the config file about it, including the contrary point of a C generating back end . On a very related note, I almost forgot..on Mac OS X, there is shared or static libgcc. The man pages say roughly this: g++ and gcj (Java) specify shared libgcc by default gcc specifies static libgcc by default C++ and Java favor shared in order to enable throwing/catching exceptions across .dll/.so boundaries. "Pure" Modula-3 code wouldn't care about that. Modula-3 code linking with C++ might. Perhaps in these scenarios, the "build system" and linking will tend to escape cm3 anyway?Make Modula-3 static .libs/.a with cm3 but not link the final file with it? I think the current config file links .dylibs(.dll/.so, but usually .dylib in this context, at least by convention) with static libgcc and executables with shared. I found in groveling over the results that, there were four or six functions imported from shared libgcc, little math helpers for division or such. It seems not worth depending on another file for just a few small functions. Just use static? On a less related note, for anyone who likes to go down such paths, I concluded that calling ld directly on Mac OS X is not a great idea, best stick to calling gcc (or g++/whatever) to do the linking, as the current files do. - Jay _________________________________________________________________ i?m is proud to present Cause Effect, a series about real people making a difference. http://im.live.com/Messenger/IM/MTV/?source=text_Cause_Effect -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Dec 31 12:04:53 2007 From: jayk123 at hotmail.com (Jay) Date: Mon, 31 Dec 2007 11:04:53 +0000 Subject: [M3devel] "where to root archives?" In-Reply-To: <20071230162432.C498A10D4596@birch.elegosoft.com> References: <20071230162432.C498A10D4596@birch.elegosoft.com> Message-ID: "where to root archives?" Maybe this is along the lines of "how to format my code?" Religous and unanswerable and strong proponents of every answer? but: A) *.zip|*.tar.gz|*.tar.bz2 shall be named cm3.* or B) cm3-.* ok, no question here, B is it. And shall contain the structure: 1) more than one file/directory at the root bin/cm3(.exe) pkg/libm3/... or 2) root contains only one directory, and it has a version in its name (and target probably) cm3-/bin/cm3(.exe) cm3-/pkg/libm3/.. or 3) root contains only one directory, with no version in its name cm3/bin/cm3(.exe) cm3/pkg/libm3/.. #1 is what the current cminstall-using distributions use I believe.Since it is wrapped by an installer, doesn't really matter.Note though that the enclosing archive is also formed this way I think, but with fewer than 10 files. It seems clearly the worst, unless you know about the tar -C or unzip -d switches, though tar -C doesn'tcreate the output directory, unzip -d does. #2 is VERY popular and tempting for me #3 is what the Win32 builds use currently (scripts/win/make-dist.cmd) It has the advantage of being more directly useable. cd \ unzip cm3-.zip and it goes into \cm3, a reasonable default, but could be preexisting (unzip does prompt I think) If it went to cm3-version, you'd probably want to either rename it, or create a link to it, Window having varying support for different types of links on different versions, not sure if use is widespread. fsutil hardlink create creates file hard links on XP+ mklink creates hardlinks and symlinks on Vista+ probably only file hardlinks and file or directory symlinks At some point, directory links were avoided because a) not required by Posix? b) allows creating cycles I see cycles now on my default installs and have crashed stuff as a result. :( junction from www.sysinternals.com creates directory linkes on...Win2000+? (This is all NTFS only of course, or over SMB to other file systems; actually stupid fsutil demands a local file system, even though underlying CreateHardLink works over SMB..) #2 seems safer, and user can immediatley rename to #3 after extraction. Oh, and in the Explorer GUI, the default is to extract in a directory with the same name as the basename of the archive.That makes #1 slightly better and the others slightly worse. Inevitably it seems the command line is doomed to always check before extracting anyway.. unzip -l foo.zip | more tar tfz foo.tar.gz | more Besides that, it still impresses and bugs me how much smaller .tar.bz2 is vs. anything else...but the Explorer support or .zip filesis also somewhat compelling...except that you have to use the command line with CM3 anyway.... - Jay _________________________________________________________________ The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. http://www.xbox.com/en-US/hardware/wheretobuy/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Dec 19 04:30:19 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 19 Dec 2007 03:30:19 -0000 Subject: [M3devel] Unix signals and Modula-3... In-Reply-To: <200712182343.lBINhJDL084804@camembert.async.caltech.edu> References: <200712182343.lBINhJDL084804@camembert.async.caltech.edu> Message-ID: The system threads pthread implementation uses a signal and a semaphore to stop/start threads for GC, Other than that, I don't believe signals are being used anywhere else in the run-time system. Also, I should point out that there may be value in retaining the current user-level threads implementation for all targets (we still need to fix some to use setcontext/getcontext instead of setjmp/ getjmp), in which case the same issue applies. I wonder if it makes sense to implement a variant of waitpid inside the threads implementation to do the right thing. We could use a signal there to catch SIGCHLD appropriately in the ThreadPosix implementation and leave it alone with ThreadPThread. What do you think? On Dec 18, 2007, at 6:43 PM, Mika Nystrom wrote: > > Ah yes, you are right. The original issue is that waitpid would > hang the whole runtime and that should not happen with system > threads. If using system threads, waitpid should be called with a > third argument of zero, I believe. Is this already happening? > If not, make the change and if you have a fast machine you may > see a spectacular speedup in your compile times. > > I suppose the easiest solution to this problem is simply to move > all active targets to system threads... > > Still, there are some other areas where Unix signals might be of > interest. I am thinking of things like interfacing with readline > and other C-based libraries that use signals for concurrency. When > I put a readline interface on some Modula-3 programs, I wound up > using an external C program to do readline processing and then > communicating over a pipe or TCP connection, because dealing > with signals seemed like such a hassle. > > Mika > > Tony Hosking writes: >> I'm assuming that waitpid hanging when using system threads is not a >> problem, since the system thread scheduler will schedule other >> threads around the waiting one. The issue is only for the user-level >> threads implementation where a thread blocking on a waitpid call >> would prevent other threads being scheduled. >> >> On Dec 18, 2007, at 7:38 AM, Mika Nystrom wrote: >> >>> Hello everyone, >>> >>> I am in the process of bootstrapping the CVS head of CM3 on an old >>> FreeBSD-4.11 system, and at one point, when I replaced the old cm3 >>> with the new cm3, the compiler got slower. Not a little bit slower, >>> mind you, but about 10x slower. I remember pointing this out to >>> the m3devel list... oh it must have been three or four years ago; >>> one of our grad students at Caltech (Karl Papadantonakis, also >>> author of the caltech-parser) was the first to notice what was going >>> on. >>> >>> It has to do with Process.Wait. (From ProcessPosix.m3.) To repeat >>> what I said a few years ago, the problem lies here: >>> >>> CONST Delay = 0.1D0; >>> BEGIN >>> IF NOT p.waitOk THEN RAISE WaitAlreadyCalled END; >>> p.waitOk := FALSE; >>> (* By rights, the SchedulerPosix interface should have a WaitPID >>> procedure that is integrated with the thread scheduler. *) >>> LOOP >>> result := Uexec.waitpid(p.pid, ADR(statusT), Uexec.WNOHANG); >>> IF result # 0 THEN EXIT END; >>> Thread.Pause(Delay) >>> END; >>> <* ASSERT result > 0 *> >>> >>> In other words: if Process.Wait is called before the child process >>> is done, then the thread pauses 0.1 seconds. >>> >>> In our local version of m3build, we duplicate the Wait code and set >>> the Delay to 0.0. That's OK in a compiler, but it's not OK in >>> general, because you would chew up the CPU on a machine that was >>> doing a lot of long-term waiting. >>> >>> The problem is that the fix that I suggested way back when requires >>> messing with Unix signals (catching SIGC[H]LD instead of using >>> waitpid), which is why I never submitted a fix to the repository, >>> because I am not sure what such a fix might interact with. It seems >>> to me that the correct way of dealing with Unix signals is to have >>> a single thread that talks to the Unix system, registers signal >>> handlers, and takes care, via some object-oriented mechanism, of >>> calling back any M3 threads that are interested in the signals. >>> Would such a thing be possible? Where are signals used in the >>> system today? >>> >>> Mika From jay.krell at cornell.edu Sat Dec 1 03:59:45 2007 From: jay.krell at cornell.edu (Jay) Date: Sat, 1 Dec 2007 02:59:45 +0000 Subject: [M3devel] some more notes on the win32 system In-Reply-To: <4750474F.1E75.00D7.1@scires.com> References: <036701c83256$d553bbf0$7ffb33d0$@com> <4750474F.1E75.00D7.1@scires.com> Message-ID: I don't setup stuff with spaces mostly, but it doesn't matter. In the past, as the install and configuration nudged you, cminstall/cm3.exe/cm3.cfg trafficed in the full paths to cl.exe, link.exe, various .libs, and possibly directories containing .h. In the present, cm3.cfg invokes merely "cl" or "cl.exe", "link" or "link.exe", does not pass any include paths to the compiler, and passes leaf file names of .libs to the linker -- msvcrt.lib, kernel32.lib, etc. If course there must be another side to that. "vcvars32.bat" and such sets %PATH% so that cl and link are on it, sets %INCLUDE% so that the various headers are on it, and %LIB% so that various .libs are on it. My sysinfo.cmd also prepends %ROOT%\lib or whatever to %LIB%, as cm3\m3-win\import-libs makes our own import .libs, since some toolsets, like at least the 7.1 Express Edition and I think 8.0, lack most the usual import .libs -- like they are enough for managed CLR development and "stdio" development, but not native Win32 development. The Platform SDK is also a free download, so I'm not replacing something you can't get for free, but it saves you an extra download and install, perhaps. There are pluses and minuses to this arrangement. I guess you can point cm3.exe at a specific cm3.cfg file? I never do that. Rather than have n different configurations, I have one configuration but vary the environment variables. The downside is that in a "bare" environment, nothing works. Unless you go and foist the vcvars32.bat onto your default environment. There is large general problem around settings, state, install (sometimes called "deployment) that has yet to be solved to most people's satisfaction. This is very much related to that. Environment variables are an ancient crude mechanism, lacking in type, lacking in hierarchy. Their main claims to fame include a) basically the same mechanism on Unix and Win32 b) inheritance through a process tree.) They don't scale well I believe. Anyway, I'm not going to solve this and I doubt any of you will either. Given that the spaces end up buried in %PATH%, %LIB%, and %INCLUDE%, where cmd, cl, link look and can cope, but where cm3 itself doesn't look at, the space problem is solved. I install to \msdev\10 \msdev\15 \msdev\20 \msdev\40 \msdev\41 \msdev\42 \msdev\50 \msdev\60 \msdev\70 \msdev\71 \msdev\80 \mwerks\6 (metrowerks, not that I use it much) \mwerks\7 \mwerks\8 \dm or \dmars (digital mars, no versioning) \cygwin (the default, no versioning) \mingwin (the default, no versioning) etc. I haven't yet settled on a grand unified file system layout for myself, though I do obsess over it, and sometimes give in to the defaults, can't fight every battle, not as often as I resetup machines.. and I haven't figured out what to do about source control and tools. Ideally, you checkin all your tools, but I'm not sure what that implies for copyright, esp. given a hosted source control system I don't control, and it'll bloat up my cheap hosted source control.. I do let the Platform SDK install to its default like \Program Files\Microsoft Platform SDK R2. Bootstrapping current source from the 5.2.6 "min" binary distribution should work. I tested this last night. Should work from the larger "std", "core", etc. whatever there is. I didn't try anything before 5.2.6. There is a question as to which toolsets to support -- which toolset to build the distribution with. The older you pick, the more reach you have to people using older toolsets. However there seems to only be about three of us so I'm barking up a very hypothetical tree.. :( As well a question as to what you can bootstrap with, which Modula-3 tools. I imagine the more you go back, the more contorted things get, and there might be really nothing to gain. Just pick the most recent good enough version and don't care about anything older? Look forward not backward? I haven't seen many problems with %TEMP% and %TMP%. They do often somewhere get changed to short paths. But I did recently have a problem with spaces in them. Realize that "short paths" are NOT predictable. And, btw, they aren't even necessarily "shorter" than the "long" path, though they do lack spaces, etc. Try this: mkdir \1.1.1 dir /x \1* - Jay Date: Fri, 30 Nov 2007 17:24:25 -0500From: rcoleburn at scires.comTo: jay.krell at cornell.edu; m3devel at elegosoft.comSubject: Re: [M3devel] some more notes on the win32 system Jay: Thanks for all your help. Actually, the last time I tried to install cm3, I used the 5.26 tarballs and tried to build, but ran into some compile errors. I'll try it again and report back the actual errors I get (if any). As for Microsoft Visual Studio, yes I'm familiar with setting it up. Are you saying that the cm3install program should no longer be used? I've used this in the past. The big issue I've run into is making sure to give old style 8.3 pathnames without spaces and to edit the cm3.cfg file to find all the libraries and stuff using paths without spaces. I've also set some environment vars, in particular the TEMP and TMP vars, to use paths without spaces. I will try to be very careful to document everything I do in great detail. Perhaps we can use this to give out a better recipe to folks on how to get cm3 working on Windows. Regards, Randy>>> Jay 11/29/2007 8:48 PM >>>some more notes on the win32 system> setup your C++ compiler/linkerYou can/should "play dumb", skip that, and just run upgrade.See what errors you get.I tried to put in the right amount of up front sanity checking.What you need in particular arecl and link on the %PATH%. See, cminstall would have you specify full paths, my configuration uses %PATH%.If using VS2005 (8) or newer, mt on the path.%LIB% is a semicolon delimited list of directories.That is a feature of the Microsoft linker.msvcrt.lib must be in one of them.Any 32 bit version of Visual C++ -- 2.0, 4.0,, 4.1, 4.2, 5.0, 6.0, 7.0, 7.1, 8.0 -- should work.I have tested all of them some and many required small changes in one particular spot, that actually is only used by "maintainers" (C:\dev2\cm3\m3-win\import-libs\src\make-lib-1.cmd).I use 8.0 the most lately.I haven't done much with 9.0. Another thing, fairly redundant: C:\dev2\cm3\m3-win>more vcredist.txtOn computers without Visual C++ 2005 or CLR 2.0 installed, download and run the setup for the Visual C++ runtime -- vcredist_x86.exe -- from either RTM (release to manufacturing): http://www.microsoft.com/downloads/details.aspx?familyid=32BC1BEE-A3F9-4C13-9C99-220B62A191EE or Service Pack 1: http://www.microsoft.com/downloads/details.aspx?FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647You can find those searching the web for vcredist, no real need to recort the URLs. That's about it. - Jay Your smile counts. The more smiles you share, the more we donate. Join in! _________________________________________________________________ Your smile counts. The more smiles you share, the more we donate.? Join in. www.windowslive.com/smile?ocid=TXT_TAGLM_Wave2_oprsmilewlhmtagline -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Dec 1 14:15:47 2007 From: jay.krell at cornell.edu (Jay) Date: Sat, 1 Dec 2007 13:15:47 +0000 Subject: [M3devel] returning record by value vs. by ref? Message-ID: This is a language question based on the x86 code gen.It isn't a code gen question at all, just related to m3 constructs the code gen happens to use. The code gen has a stack of operands, I've said many times. This is partly made up. type loc_t = [ imm, reg, mvar ] (* location: variable in memory, register, immediate/constant *) type reg_t = [ eax, esi, edi, ...] (* register *) type operand_t = record loc : loc_t; reg : reg_t; imm : integer; (* immediate or constant *) (* some data associated with mvar... *) end; The type is a bit bigger than this, and that is relevant. interface stack allows access both to entire operands, or their fields, based on an index into the stack. The stack is not fixed size. I think this becomes important. Pardon my mix of M3, C, C++ and made up syntax. interface and module stack; private s: array of operand; procedure getloc(n: integer) : loc_t = begin return s[n].loc; end getloc; procedure getimm(n: integer) : INTEGER = begin return s[n].imm; end getimm; procedure getreg(n: integer) : reg_t = begin return s[n].reg; end getreg; procedure getop(n: integer) : operand_t = (* get entire operand *) begin return s[n]; end getop; A cursory read of the source code, not yet of the object code, from the point of view of a C/C++ programmersays to me that this last function getop returns a copy of an entire record. Again, the record is a bit largerthan this. I made it still larger, and I started getting warnings about that. What I would really like is for getop to return the operands by pointer. procedure getop(n: integer) : REF operand_t = (* get entire operand *) begin return s[n]; end getop; From my point of view, this is very natural. And far more efficient. But I couldn't get anything to compile along these lines. Now, as I said, the stack does grow sometimes, so the array could get realloced, and outstanding pointers invalidated. I guess that is the point? You can't "safely" get a pointer? I could make it an array of REFs I guess, heap-fragmentation-unfriendly, but given that it grows rarely, probably ok. I guess maybe gcc does a good job with this stuff? Optimzing away the copies, inlining the array access, etc.? Thoughts? One just needs to get over worrying about the perf at this level for one's sanity to survive programming in Modula-3? Safe languages are simply stuck with either a lot of garbage collected separate heap allocations or a lot of copying? Pointers as I think about them exude "danger" all over the place? (Yes, I know that "safely" and "danger" are technical terms and I know what they mean, at least roughly, no dangling pointers to stack, no double frees, no unbounded array access, no unchecked type conversions, the system remains type safe and the rules of the language remain unbroken, however I live and breathe C/C++ so it is hard to adjust my mindset, even if I understand the issues fairly deeply.) The problem one runs into, is that of the pretty darn good C and C++ programmers who, whilenot perfect, are pretty darn good. A "safe" language throws you to quite an extremeof perf compromise to nail the last little bit of guaranteed safety, when you really weren't doing sucha bad job in the first place through brute force of careful coding.. You pay a lot for a little.Lesser programmers, sure, they need the hand holding... I've been experimenting lately, and C just isn't actually all that bad.Ok, actually most recently I'm writing more Perl, also not bad.See, there's another extreme. Traditional and semi-traditional languageand compilation systems like C and Modula-3 and even Java and C# actuallyobsess far more about performance than many many problems need.Perl (Python, Ruby presumably, but Perl is the only one available to me,that has cleared legal/licensing hurdles) is plenty adequate for tons of tasks.If my task requires some i/o, then i/o cost might dominate the overall perf cost... I realize I'm all over the place here, arguing for and against optimizing. I don't like Perl's funny characters, or lack of a standard OO approach,(using hash tables for everything really is bad..) but it's still surprisingly good.I noticed some job descriptions lately for Perl programmers that specificallysaid they were not "scripting" jobs but, like, real industrial strength software engineering.I think those people get it.You get to a certain point of general purposeness and performance and hopefullystatic checking, and a lot things don't matter as much as people think.... Anyway. - Jay _________________________________________________________________ Share life as it happens with the new Windows Live.Download today it's FREE! http://www.windowslive.com/share.html?ocid=TXT_TAGLM_Wave2_sharelife_112007 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Dec 1 17:03:44 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 1 Dec 2007 11:03:44 -0500 Subject: [M3devel] returning record by value vs. by ref? In-Reply-To: References: Message-ID: <1560FF15-8486-4388-ADAE-FADCF71FC5F3@cs.purdue.edu> I am assuming 's' here is an open array (REF ARRAY OF item) in which case it is allocated in the GC'd heap. There is certainly no way of safely getting an interior pointer to items in the stack in Modula-3 -- at least not one that you can upward expose (to callers) via return from a procedure. The difficulty in doing this is that the GC moves objects around and would need to know where your manufactured interior pointer is being held and to which *object* (ie, the open array in this case) it refers so that it can 'fix' the pointer when the array object moves. Modula-3 provides a small concession to obtaining downward exposed interior pointers using the VAR parameter mode. For example you can pass 's[i]' as an actual parameter to a VAR mode formal, effectively passing a pointer to the callee. GC can cope with this in one of two possible ways: 1) "Pin" the array so that it cannot be moved while the interior pointer is held on the stack or registers of any thread (this is the approach that CM3's conservative collector uses for now); or 2) track the creation of such interior pointers and how they are derived from base object references for use during GC. 2) requires much more co-operation from the compiler than the current gcc-based backend (with all of its lovely optimizations and register allocation) is capable of doing. 1) is very cheap and does not impede optimizations and register allocation. On Dec 1, 2007, at 8:15 AM, Jay wrote: > This is a language question based on the x86 code gen. > It isn't a code gen question at all, just related to m3 constructs > the code gen happens to use. > > The code gen has a stack of operands, I've said many times. > > This is partly made up. > > type loc_t = [ imm, reg, mvar ] (* location: variable in memory, > register, immediate/constant *) > type reg_t = [ eax, esi, edi, ...] (* register *) > > type operand_t = record > loc : loc_t; > reg : reg_t; > imm : integer; (* immediate or constant *) > (* some data associated with mvar... *) > end; > > The type is a bit bigger than this, and that is relevant. > > interface stack allows access both to entire operands, or their > fields, based on an index into the stack. > > The stack is not fixed size. I think this becomes important. > > Pardon my mix of M3, C, C++ and made up syntax. > > interface and module stack; > > private s: array of operand; > > procedure getloc(n: integer) : loc_t = > begin > return s[n].loc; > end getloc; > > procedure getimm(n: integer) : INTEGER = > begin > return s[n].imm; > end getimm; > > procedure getreg(n: integer) : reg_t = > begin > return s[n].reg; > end getreg; > > procedure getop(n: integer) : operand_t = (* get entire operand *) > begin > return s[n]; > end getop; > > A cursory read of the source code, not yet of the object code, > from the point of view of a C/C++ programmer > says to me that this last function getop returns a copy of an > entire record. Again, the record is a bit larger > than this. I made it still larger, and I started getting warnings > about that. > > What I would really like is for getop to return the operands by > pointer. > > procedure getop(n: integer) : REF operand_t = (* get entire > operand *) > begin > return s[n]; > end getop; > > From my point of view, this is very natural. And far more efficient. > But I couldn't get anything to compile along these lines. > > Now, as I said, the stack does grow sometimes, so the array could > get realloced, and outstanding > pointers invalidated. I guess that is the point? You can't > "safely" get a pointer? > I could make it an array of REFs I guess, heap-fragmentation- > unfriendly, but given that it grows > rarely, probably ok. > > I guess maybe gcc does a good job with this stuff? Optimzing away > the copies, inlining the array access, etc.? > > Thoughts? > One just needs to get over worrying about the perf at this level > for one's sanity > to survive programming in Modula-3? > > Safe languages are simply stuck with either a lot of garbage > collected separate heap allocations > or a lot of copying? Pointers as I think about them exude "danger" > all over the place? > (Yes, I know that "safely" and "danger" are technical terms and I > know what they mean, > at least roughly, no dangling pointers to stack, no double frees, > no unbounded > array access, no unchecked type conversions, the system remains > type safe and > the rules of the language remain unbroken, however I live and > breathe C/C++ so it > is hard to adjust my mindset, even if I understand the issues > fairly deeply.) > > The problem one runs into, is that of the pretty darn good C and C+ > + programmers who, while > not perfect, are pretty darn good. A "safe" language throws you to > quite an extreme > of perf compromise to nail the last little bit of guaranteed > safety, when you really weren't doing such > a bad job in the first place through brute force of careful > coding.. You pay a lot for a little. > Lesser programmers, sure, they need the hand holding... > > I've been experimenting lately, and C just isn't actually all that > bad. > Ok, actually most recently I'm writing more Perl, also not bad. > See, there's another extreme. Traditional and semi-traditional > language > and compilation systems like C and Modula-3 and even Java and C# > actually > obsess far more about performance than many many problems need. > Perl (Python, Ruby presumably, but Perl is the only one available > to me, > that has cleared legal/licensing hurdles) is plenty adequate for > tons of tasks. > If my task requires some i/o, then i/o cost might dominate the > overall perf cost... > > I realize I'm all over the place here, arguing for and against > optimizing. > > I don't like Perl's funny characters, or lack of a standard OO > approach, > (using hash tables for everything really is bad..) but it's still > surprisingly good. > I noticed some job descriptions lately for Perl programmers that > specifically > said they were not "scripting" jobs but, like, real industrial > strength software engineering. > I think those people get it. > You get to a certain point of general purposeness and performance > and hopefully > static checking, and a lot things don't matter as much as people > think.... > > Anyway. > - Jay > > > Share life as it happens with the new Windows Live. Share now! From rodney.bates at wichita.edu Sat Dec 1 20:31:39 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Sat, 01 Dec 2007 13:31:39 -0600 Subject: [M3devel] returning record by value vs. by ref? In-Reply-To: <1560FF15-8486-4388-ADAE-FADCF71FC5F3@cs.purdue.edu> References: <1560FF15-8486-4388-ADAE-FADCF71FC5F3@cs.purdue.edu> Message-ID: <4751B69B.1090907@wichita.edu> Tony Hosking wrote: > I am assuming 's' here is an open array (REF ARRAY OF item) in which > case it is allocated in the GC'd heap. There is certainly no way of > safely getting an interior pointer to items in the stack in Modula-3 -- > at least not one that you can upward expose (to callers) via return > from a procedure. The difficulty in doing this is that the GC moves > objects around and would need to know where your manufactured interior > pointer is being held and to which *object* (ie, the open array in this > case) it refers so that it can 'fix' the pointer when the array object > moves. Modula-3 provides a small concession to obtaining downward > exposed interior pointers using the VAR parameter mode. For example > you can pass 's[i]' as an actual parameter to a VAR mode formal, > effectively passing a pointer to the callee. GC can cope with this in > one of two possible ways: 1) "Pin" the array so that it cannot be moved > while the interior pointer is held on the stack or registers of any > thread (this is the approach that CM3's conservative collector uses for > now); or 2) track the creation of such interior pointers and how they > are derived from base object references for use during GC. 2) requires > much more co-operation from the compiler than the current gcc-based > backend (with all of its lovely optimizations and register allocation) > is capable of doing. 1) is very cheap and does not impede > optimizations and register allocation. > Presumably, this all also applies WITH-bound identifiers, when they are designators of interior components of heap objects? Are there any other cases? -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From hosking at cs.purdue.edu Sat Dec 1 21:23:19 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 1 Dec 2007 15:23:19 -0500 Subject: [M3devel] returning record by value vs. by ref? In-Reply-To: <4751B69B.1090907@wichita.edu> References: <1560FF15-8486-4388-ADAE-FADCF71FC5F3@cs.purdue.edu> <4751B69B.1090907@wichita.edu> Message-ID: Correct! Anytime you create an l-value pointer. On Dec 1, 2007, at 2:31 PM, Rodney M. Bates wrote: > Tony Hosking wrote: >> I am assuming 's' here is an open array (REF ARRAY OF item) in >> which case it is allocated in the GC'd heap. There is certainly >> no way of safely getting an interior pointer to items in the >> stack in Modula-3 -- at least not one that you can upward expose >> (to callers) via return from a procedure. The difficulty in >> doing this is that the GC moves objects around and would need to >> know where your manufactured interior pointer is being held and >> to which *object* (ie, the open array in this case) it refers so >> that it can 'fix' the pointer when the array object moves. >> Modula-3 provides a small concession to obtaining downward >> exposed interior pointers using the VAR parameter mode. For >> example you can pass 's[i]' as an actual parameter to a VAR mode >> formal, effectively passing a pointer to the callee. GC can cope >> with this in one of two possible ways: 1) "Pin" the array so that >> it cannot be moved while the interior pointer is held on the >> stack or registers of any thread (this is the approach that CM3's >> conservative collector uses for now); or 2) track the creation of >> such interior pointers and how they are derived from base object >> references for use during GC. 2) requires much more co-operation >> from the compiler than the current gcc-based backend (with all of >> its lovely optimizations and register allocation) is capable of >> doing. 1) is very cheap and does not impede optimizations and >> register allocation. > > Presumably, this all also applies WITH-bound identifiers, when they > are > designators of interior components of heap objects? Are there any > other > cases? > > -- > ------------------------------------------------------------- > Rodney M. Bates, retired assistant professor > Dept. of Computer Science, Wichita State University > Wichita, KS 67260-0083 > 316-978-3922 > rodney.bates at wichita.edu From jay.krell at cornell.edu Sat Dec 1 23:14:18 2007 From: jay.krell at cornell.edu (Jay) Date: Sat, 1 Dec 2007 22:14:18 +0000 Subject: [M3devel] returning record by value vs. by ref? In-Reply-To: References: <1560FF15-8486-4388-ADAE-FADCF71FC5F3@cs.purdue.edu> <4751B69B.1090907@wichita.edu> Message-ID: 1) Can pinning not be exposed reasonably in the language? I'll keep my pointer just a short time, in a local. 2) surely it could be done at an outer layer? Make volatile locals for things you don't want enregistered? Even the accessor function approach seems lame, given that I believe the Win32/x86 compiler doesn't inline.. :( (does the gcc m3 inline across modules, or just compiles one at a time?) - Jay > CC: jay.krell at cornell.edu; m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] returning record by value vs. by ref?> Date: Sat, 1 Dec 2007 15:23:19 -0500> To: rodney.bates at wichita.edu> > Correct! Anytime you create an l-value pointer.> > On Dec 1, 2007, at 2:31 PM, Rodney M. Bates wrote:> > > Tony Hosking wrote:> >> I am assuming 's' here is an open array (REF ARRAY OF item) in > >> which case it is allocated in the GC'd heap. There is certainly > >> no way of safely getting an interior pointer to items in the > >> stack in Modula-3 -- at least not one that you can upward expose > >> (to callers) via return from a procedure. The difficulty in > >> doing this is that the GC moves objects around and would need to > >> know where your manufactured interior pointer is being held and > >> to which *object* (ie, the open array in this case) it refers so > >> that it can 'fix' the pointer when the array object moves. > >> Modula-3 provides a small concession to obtaining downward > >> exposed interior pointers using the VAR parameter mode. For > >> example you can pass 's[i]' as an actual parameter to a VAR mode > >> formal, effectively passing a pointer to the callee. GC can cope > >> with this in one of two possible ways: 1) "Pin" the array so that > >> it cannot be moved while the interior pointer is held on the > >> stack or registers of any thread (this is the approach that CM3's > >> conservative collector uses for now); or 2) track the creation of > >> such interior pointers and how they are derived from base object > >> references for use during GC. 2) requires much more co-operation > >> from the compiler than the current gcc-based backend (with all of > >> its lovely optimizations and register allocation) is capable of > >> doing. 1) is very cheap and does not impede optimizations and > >> register allocation.> >> > Presumably, this all also applies WITH-bound identifiers, when they > > are> > designators of interior components of heap objects? Are there any > > other> > cases?> >> > -- > > -------------------------------------------------------------> > Rodney M. Bates, retired assistant professor> > Dept. of Computer Science, Wichita State University> > Wichita, KS 67260-0083> > 316-978-3922> > rodney.bates at wichita.edu> _________________________________________________________________ Your smile counts. The more smiles you share, the more we donate.? Join in. www.windowslive.com/smile?ocid=TXT_TAGLM_Wave2_oprsmilewlhmtagline -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Dec 1 23:19:46 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 1 Dec 2007 17:19:46 -0500 Subject: [M3devel] returning record by value vs. by ref? In-Reply-To: References: <1560FF15-8486-4388-ADAE-FADCF71FC5F3@cs.purdue.edu> <4751B69B.1090907@wichita.edu> Message-ID: On Dec 1, 2007, at 5:14 PM, Jay wrote: > 1) Can pinning not be exposed reasonably in the language? > I'll keep my pointer just a short time, in a local. Yes, that is a *hack* that will work only with the current conservative garbage collector. In general, the compiler might record that the local is a pointer derived from some base reference and if the GC decides to move the base object it can adjust the local derived pointer accordingly. > 2) surely it could be done at an outer layer? > Make volatile locals for things you don't want enregistered? I don't understand what you mean by this. > Even the accessor function approach seems lame, given that I > believe the Win32/x86 compiler doesn't inline.. :( > (does the gcc m3 inline across modules, or just compiles one at a > time?) gcc m3 inlines only within compilation units. > > > - Jay > > > > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: [M3devel] returning record by value vs. by ref? > > Date: Sat, 1 Dec 2007 15:23:19 -0500 > > To: rodney.bates at wichita.edu > > > > Correct! Anytime you create an l-value pointer. > > > > On Dec 1, 2007, at 2:31 PM, Rodney M. Bates wrote: > > > > > Tony Hosking wrote: > > >> I am assuming 's' here is an open array (REF ARRAY OF item) in > > >> which case it is allocated in the GC'd heap. There is certainly > > >> no way of safely getting an interior pointer to items in the > > >> stack in Modula-3 -- at least not one that you can upward expose > > >> (to callers) via return from a procedure. The difficulty in > > >> doing this is that the GC moves objects around and would need to > > >> know where your manufactured interior pointer is being held and > > >> to which *object* (ie, the open array in this case) it refers so > > >> that it can 'fix' the pointer when the array object moves. > > >> Modula-3 provides a small concession to obtaining downward > > >> exposed interior pointers using the VAR parameter mode. For > > >> example you can pass 's[i]' as an actual parameter to a VAR mode > > >> formal, effectively passing a pointer to the callee. GC can cope > > >> with this in one of two possible ways: 1) "Pin" the array so that > > >> it cannot be moved while the interior pointer is held on the > > >> stack or registers of any thread (this is the approach that CM3's > > >> conservative collector uses for now); or 2) track the creation of > > >> such interior pointers and how they are derived from base object > > >> references for use during GC. 2) requires much more co-operation > > >> from the compiler than the current gcc-based backend (with all of > > >> its lovely optimizations and register allocation) is capable of > > >> doing. 1) is very cheap and does not impede optimizations and > > >> register allocation. > > > > > > Presumably, this all also applies WITH-bound identifiers, when > they > > > are > > > designators of interior components of heap objects? Are there any > > > other > > > cases? > > > > > > -- > > > ------------------------------------------------------------- > > > Rodney M. Bates, retired assistant professor > > > Dept. of Computer Science, Wichita State University > > > Wichita, KS 67260-0083 > > > 316-978-3922 > > > rodney.bates at wichita.edu > > > > > Your smile counts. The more smiles you share, the more we donate. > Join in! From jay.krell at cornell.edu Sat Dec 1 23:36:03 2007 From: jay.krell at cornell.edu (Jay) Date: Sat, 1 Dec 2007 22:36:03 +0000 Subject: [M3devel] returning record by value vs. by ref? In-Reply-To: References: <1560FF15-8486-4388-ADAE-FADCF71FC5F3@cs.purdue.edu> <4751B69B.1090907@wichita.edu> Message-ID: > 2, don't understand You said it'd take much cooperation with the compiler, due its optimizations, but optimizations can be defeated as necessary. Interior pointers could be marked, perhaps, volatile, so prevent enregistration. I can see that's a potentially high cost though. like Record_t *Record = GetRecord(); unsigned i; for (i = 0 ; i != Record->j ; ++i) { ... } You'd really like Record->j to not be refetched for every loop iteration, but if Record is volatile so the GC can move what it points to and update outstanding pointers, you'd be stuck with something like that. Besides, if j can't be read in one instruction, more problems, assuming a concurrent GC, that cannot reliably get/set the context of other threads. I think, like, you could reliably get/set context on a uniprocessor system, but not a multiprocessor. You'd have to suspend, wait for the suspend to happen.. I guess that could work, but it seems like you'd want to avoid designs that require suspending threads. ? Hm. No, it's difficult. This being a short lived pointer, gc happening on another thread, you'd have to, like, "register" its location with the gc. Hm. Just how does it work? gc suspends threads and updates variables? I don't think so. Variables that are moved leave some sort of "forwarding address" for holders of the old value? The gc isn't concurrent but is called at function entry/exit? I don't think so. I should check the docs and code.. - Jay > From: hosking at cs.purdue.edu> Date: Sat, 1 Dec 2007 17:19:46 -0500> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] returning record by value vs. by ref?> > > On Dec 1, 2007, at 5:14 PM, Jay wrote:> > > 1) Can pinning not be exposed reasonably in the language?> > I'll keep my pointer just a short time, in a local.> > Yes, that is a *hack* that will work only with the current > conservative garbage collector. In general, the compiler might > record that the local is a pointer derived from some base reference > and if the GC decides to move the base object it can adjust the local > derived pointer accordingly.> > > 2) surely it could be done at an outer layer?> > Make volatile locals for things you don't want enregistered?> > I don't understand what you mean by this.> > > Even the accessor function approach seems lame, given that I > > believe the Win32/x86 compiler doesn't inline.. :(> > (does the gcc m3 inline across modules, or just compiles one at a > > time?)> > gcc m3 inlines only within compilation units.> > >> >> > - Jay> >> >> > > CC: jay.krell at cornell.edu; m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > Subject: Re: [M3devel] returning record by value vs. by ref?> > > Date: Sat, 1 Dec 2007 15:23:19 -0500> > > To: rodney.bates at wichita.edu> > >> > > Correct! Anytime you create an l-value pointer.> > >> > > On Dec 1, 2007, at 2:31 PM, Rodney M. Bates wrote:> > >> > > > Tony Hosking wrote:> > > >> I am assuming 's' here is an open array (REF ARRAY OF item) in> > > >> which case it is allocated in the GC'd heap. There is certainly> > > >> no way of safely getting an interior pointer to items in the> > > >> stack in Modula-3 -- at least not one that you can upward expose> > > >> (to callers) via return from a procedure. The difficulty in> > > >> doing this is that the GC moves objects around and would need to> > > >> know where your manufactured interior pointer is being held and> > > >> to which *object* (ie, the open array in this case) it refers so> > > >> that it can 'fix' the pointer when the array object moves.> > > >> Modula-3 provides a small concession to obtaining downward> > > >> exposed interior pointers using the VAR parameter mode. For> > > >> example you can pass 's[i]' as an actual parameter to a VAR mode> > > >> formal, effectively passing a pointer to the callee. GC can cope> > > >> with this in one of two possible ways: 1) "Pin" the array so that> > > >> it cannot be moved while the interior pointer is held on the> > > >> stack or registers of any thread (this is the approach that CM3's> > > >> conservative collector uses for now); or 2) track the creation of> > > >> such interior pointers and how they are derived from base object> > > >> references for use during GC. 2) requires much more co-operation> > > >> from the compiler than the current gcc-based backend (with all of> > > >> its lovely optimizations and register allocation) is capable of> > > >> doing. 1) is very cheap and does not impede optimizations and> > > >> register allocation.> > > >> > > > Presumably, this all also applies WITH-bound identifiers, when > > they> > > > are> > > > designators of interior components of heap objects? Are there any> > > > other> > > > cases?> > > >> > > > --> > > > -------------------------------------------------------------> > > > Rodney M. Bates, retired assistant professor> > > > Dept. of Computer Science, Wichita State University> > > > Wichita, KS 67260-0083> > > > 316-978-3922> > > > rodney.bates at wichita.edu> > >> >> >> > Your smile counts. The more smiles you share, the more we donate. > > Join in!> _________________________________________________________________ Put your friends on the big screen with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_102007 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Dec 1 23:42:02 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 1 Dec 2007 17:42:02 -0500 Subject: [M3devel] returning record by value vs. by ref? In-Reply-To: References: <1560FF15-8486-4388-ADAE-FADCF71FC5F3@cs.purdue.edu> <4751B69B.1090907@wichita.edu> Message-ID: If this really interests you then you might read this paper: http:// doi.acm.org/10.1145/143095.143140 . On Dec 1, 2007, at 5:36 PM, Jay wrote: > > 2, don't understand > > You said it'd take much cooperation with the compiler, due its > optimizations, but optimizations can be defeated as necessary. > Interior pointers could be marked, perhaps, volatile, so prevent > enregistration. I can see that's a potentially high cost though. > > like > Record_t *Record = GetRecord(); > unsigned i; > for (i = 0 ; i != Record->j ; ++i) > { > ... > } > > You'd really like Record->j to not be refetched for every loop > iteration, but if Record is volatile so the GC can move what it > points to and update outstanding pointers, you'd be stuck with > something like that. Besides, if j can't be read in one > instruction, more problems, assuming a concurrent GC, that cannot > reliably get/set the context of other threads. I think, like, you > could reliably get/set context on a uniprocessor system, but not a > multiprocessor. You'd have to suspend, wait for the suspend to > happen.. I guess that could work, but it seems like you'd want to > avoid designs that require suspending threads. ? > Hm. No, it's difficult. This being a short lived pointer, gc > happening on another thread, you'd have to, like, "register" its > location with the gc. > > Hm. Just how does it work? > > gc suspends threads and updates variables? I don't think so. > > Variables that are moved leave some sort of "forwarding address" > for holders of the old value? > > The gc isn't concurrent but is called at function entry/exit? I > don't think so. > > I should check the docs and code.. > > - Jay > > > > > From: hosking at cs.purdue.edu > > Date: Sat, 1 Dec 2007 17:19:46 -0500 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] returning record by value vs. by ref? > > > > > > On Dec 1, 2007, at 5:14 PM, Jay wrote: > > > > > 1) Can pinning not be exposed reasonably in the language? > > > I'll keep my pointer just a short time, in a local. > > > > Yes, that is a *hack* that will work only with the current > > conservative garbage collector. In general, the compiler might > > record that the local is a pointer derived from some base reference > > and if the GC decides to move the base object it can adjust the > local > > derived pointer accordingly. > > > > > 2) surely it could be done at an outer layer? > > > Make volatile locals for things you don't want enregistered? > > > > I don't understand what you mean by this. > > > > > Even the accessor function approach seems lame, given that I > > > believe the Win32/x86 compiler doesn't inline.. :( > > > (does the gcc m3 inline across modules, or just compiles one at a > > > time?) > > > > gcc m3 inlines only within compilation units. > > > > > > > > > > > - Jay > > > > > > > > > > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > > > > From: hosking at cs.purdue.edu > > > > Subject: Re: [M3devel] returning record by value vs. by ref? > > > > Date: Sat, 1 Dec 2007 15:23:19 -0500 > > > > To: rodney.bates at wichita.edu > > > > > > > > Correct! Anytime you create an l-value pointer. > > > > > > > > On Dec 1, 2007, at 2:31 PM, Rodney M. Bates wrote: > > > > > > > > > Tony Hosking wrote: > > > > >> I am assuming 's' here is an open array (REF ARRAY OF > item) in > > > > >> which case it is allocated in the GC'd heap. There is > certainly > > > > >> no way of safely getting an interior pointer to items in the > > > > >> stack in Modula-3 -- at least not one that you can upward > expose > > > > >> (to callers) via return from a procedure. The difficulty in > > > > >> doing this is that the GC moves objects around and would > need to > > > > >> know where your manufactured interior pointer is being > held and > > > > >> to which *object* (ie, the open array in this case) it > refers so > > > > >> that it can 'fix' the pointer when the array object moves. > > > > >> Modula-3 provides a small concession to obtaining downward > > > > >> exposed interior pointers using the VAR parameter mode. For > > > > >> example you can pass 's[i]' as an actual parameter to a > VAR mode > > > > >> formal, effectively passing a pointer to the callee. GC > can cope > > > > >> with this in one of two possible ways: 1) "Pin" the array > so that > > > > >> it cannot be moved while the interior pointer is held on the > > > > >> stack or registers of any thread (this is the approach > that CM3's > > > > >> conservative collector uses for now); or 2) track the > creation of > > > > >> such interior pointers and how they are derived from base > object > > > > >> references for use during GC. 2) requires much more co- > operation > > > > >> from the compiler than the current gcc-based backend (with > all of > > > > >> its lovely optimizations and register allocation) is > capable of > > > > >> doing. 1) is very cheap and does not impede optimizations and > > > > >> register allocation. > > > > > > > > > > Presumably, this all also applies WITH-bound identifiers, when > > > they > > > > > are > > > > > designators of interior components of heap objects? Are > there any > > > > > other > > > > > cases? > > > > > > > > > > -- > > > > > ------------------------------------------------------------- > > > > > Rodney M. Bates, retired assistant professor > > > > > Dept. of Computer Science, Wichita State University > > > > > Wichita, KS 67260-0083 > > > > > 316-978-3922 > > > > > rodney.bates at wichita.edu > > > > > > > > > > > > > Your smile counts. The more smiles you share, the more we donate. > > > Join in! > > > > > Get the power of Windows + Web with the new Windows Live. Power up! From jay.krell at cornell.edu Sun Dec 2 05:11:04 2007 From: jay.krell at cornell.edu (Jay) Date: Sun, 2 Dec 2007 04:11:04 +0000 Subject: [M3devel] returning record by value vs. by ref? In-Reply-To: References: <1560FF15-8486-4388-ADAE-FADCF71FC5F3@cs.purdue.edu> <4751B69B.1090907@wichita.edu> Message-ID: Thanks! I haven't finished reading it, but it sounds like an optimizing compiler is ok, due to the reliance on "gc points", which I read ahead to find out how they are defined. And I'm GUESSING that CM3 already generates and depends on the sort of data described there. But maybe not. I wonder what the size of the data looks like if you allow a gc point at every instruction. I guess it probably be too large -- figure a byte or two extra for every instruction, but maybe not. Perhaps it could be encoded in bits instead of bytes and given that most instructions don't affect the state (ie: operations on integers, floats, comparisons, branches), maybe just a zero bit for most instructions. So then figure a byte or two for every instruction that moves (load or store) or adds/substracts a pointer. Or more than that. A byte or two could describe enregistration and small adds/subtracts, but not large adds/subtracts or memory offsets. OR perhaps it'd just read the code itself. That's easier with Win32/x86 since it is so constrained as to what it outputs. That should be feasible. I realize I'm changing subjects between the different backends. The Windows AMD64 calling convention relies on something LIKE this. In particular, there is a little encoding associated with every prolog/epilog so that exception handling can undo the prolog's effects. It describes a tiny subset of the instruction set, like register moves. Kind of funny -- once you get into the business of wanting to read the code to know what it does, you then get tempted to define your own code, for runtime and information, and then a possible trick is to adopt the existing machine code as your code, or whatever subset your compiler produces. Hm. The existing machine isn't sufficient. You would need type information to augment it. Which reminds. Another OBVIOUS backend for CM3 for easier portability is to persist the calls to m3cg and then write an interpreter for that in C. - Jay > From: hosking at cs.purdue.edu> Date: Sat, 1 Dec 2007 17:42:02 -0500> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] returning record by value vs. by ref?> > If this really interests you then you might read this paper: http:// > doi.acm.org/10.1145/143095.143140 .> > On Dec 1, 2007, at 5:36 PM, Jay wrote:> > > > 2, don't understand> >> > You said it'd take much cooperation with the compiler, due its > > optimizations, but optimizations can be defeated as necessary.> > Interior pointers could be marked, perhaps, volatile, so prevent > > enregistration. I can see that's a potentially high cost though.> >> > like> > Record_t *Record = GetRecord();> > unsigned i;> > for (i = 0 ; i != Record->j ; ++i)> > {> > ...> > }> >> > You'd really like Record->j to not be refetched for every loop > > iteration, but if Record is volatile so the GC can move what it > > points to and update outstanding pointers, you'd be stuck with > > something like that. Besides, if j can't be read in one > > instruction, more problems, assuming a concurrent GC, that cannot > > reliably get/set the context of other threads. I think, like, you > > could reliably get/set context on a uniprocessor system, but not a > > multiprocessor. You'd have to suspend, wait for the suspend to > > happen.. I guess that could work, but it seems like you'd want to > > avoid designs that require suspending threads. ?> > Hm. No, it's difficult. This being a short lived pointer, gc > > happening on another thread, you'd have to, like, "register" its > > location with the gc.> >> > Hm. Just how does it work?> >> > gc suspends threads and updates variables? I don't think so.> >> > Variables that are moved leave some sort of "forwarding address" > > for holders of the old value?> >> > The gc isn't concurrent but is called at function entry/exit? I > > don't think so.> >> > I should check the docs and code..> >> > - Jay> >> >> >> > > From: hosking at cs.purdue.edu> > > Date: Sat, 1 Dec 2007 17:19:46 -0500> > > To: jay.krell at cornell.edu> > > CC: m3devel at elegosoft.com> > > Subject: Re: [M3devel] returning record by value vs. by ref?> > >> > >> > > On Dec 1, 2007, at 5:14 PM, Jay wrote:> > >> > > > 1) Can pinning not be exposed reasonably in the language?> > > > I'll keep my pointer just a short time, in a local.> > >> > > Yes, that is a *hack* that will work only with the current> > > conservative garbage collector. In general, the compiler might> > > record that the local is a pointer derived from some base reference> > > and if the GC decides to move the base object it can adjust the > > local> > > derived pointer accordingly.> > >> > > > 2) surely it could be done at an outer layer?> > > > Make volatile locals for things you don't want enregistered?> > >> > > I don't understand what you mean by this.> > >> > > > Even the accessor function approach seems lame, given that I> > > > believe the Win32/x86 compiler doesn't inline.. :(> > > > (does the gcc m3 inline across modules, or just compiles one at a> > > > time?)> > >> > > gcc m3 inlines only within compilation units.> > >> > > >> > > >> > > > - Jay> > > >> > > >> > > > > CC: jay.krell at cornell.edu; m3devel at elegosoft.com> > > > > From: hosking at cs.purdue.edu> > > > > Subject: Re: [M3devel] returning record by value vs. by ref?> > > > > Date: Sat, 1 Dec 2007 15:23:19 -0500> > > > > To: rodney.bates at wichita.edu> > > > >> > > > > Correct! Anytime you create an l-value pointer.> > > > >> > > > > On Dec 1, 2007, at 2:31 PM, Rodney M. Bates wrote:> > > > >> > > > > > Tony Hosking wrote:> > > > > >> I am assuming 's' here is an open array (REF ARRAY OF > > item) in> > > > > >> which case it is allocated in the GC'd heap. There is > > certainly> > > > > >> no way of safely getting an interior pointer to items in the> > > > > >> stack in Modula-3 -- at least not one that you can upward > > expose> > > > > >> (to callers) via return from a procedure. The difficulty in> > > > > >> doing this is that the GC moves objects around and would > > need to> > > > > >> know where your manufactured interior pointer is being > > held and> > > > > >> to which *object* (ie, the open array in this case) it > > refers so> > > > > >> that it can 'fix' the pointer when the array object moves.> > > > > >> Modula-3 provides a small concession to obtaining downward> > > > > >> exposed interior pointers using the VAR parameter mode. For> > > > > >> example you can pass 's[i]' as an actual parameter to a > > VAR mode> > > > > >> formal, effectively passing a pointer to the callee. GC > > can cope> > > > > >> with this in one of two possible ways: 1) "Pin" the array > > so that> > > > > >> it cannot be moved while the interior pointer is held on the> > > > > >> stack or registers of any thread (this is the approach > > that CM3's> > > > > >> conservative collector uses for now); or 2) track the > > creation of> > > > > >> such interior pointers and how they are derived from base > > object> > > > > >> references for use during GC. 2) requires much more co- > > operation> > > > > >> from the compiler than the current gcc-based backend (with > > all of> > > > > >> its lovely optimizations and register allocation) is > > capable of> > > > > >> doing. 1) is very cheap and does not impede optimizations and> > > > > >> register allocation.> > > > > >> > > > > > Presumably, this all also applies WITH-bound identifiers, when> > > > they> > > > > > are> > > > > > designators of interior components of heap objects? Are > > there any> > > > > > other> > > > > > cases?> > > > > >> > > > > > --> > > > > > -------------------------------------------------------------> > > > > > Rodney M. Bates, retired assistant professor> > > > > > Dept. of Computer Science, Wichita State University> > > > > > Wichita, KS 67260-0083> > > > > > 316-978-3922> > > > > > rodney.bates at wichita.edu> > > > >> > > >> > > >> > > > Your smile counts. The more smiles you share, the more we donate.> > > > Join in!> > >> >> >> > Get the power of Windows + Web with the new Windows Live. Power up!> _________________________________________________________________ You keep typing, we keep giving. Download Messenger and join the i?m Initiative now. http://im.live.com/messenger/im/home/?source=TAGLM -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 2 06:16:05 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 2 Dec 2007 00:16:05 -0500 Subject: [M3devel] returning record by value vs. by ref? In-Reply-To: References: <1560FF15-8486-4388-ADAE-FADCF71FC5F3@cs.purdue.edu> <4751B69B.1090907@wichita.edu> Message-ID: <2B3B82B5-B989-4AC9-8156-02B3B8AC5B46@cs.purdue.edu> On Dec 1, 2007, at 11:11 PM, Jay wrote: > Thanks! > > I haven't finished reading it, but it sounds like an optimizing > compiler is ok, due > to the reliance on "gc points", which I read ahead to find out how > they are defined. If you want fully accurate (non-ambiguous roots) GC then yes you need gc-points to avoid having to store pointer information for every PC location. > And I'm GUESSING that CM3 already generates and depends on the sort > of data described there. > But maybe not. Umm, no. CM3 uses an ambiguous roots technique for thread stacks/ registers that avoids the need for gc-points. Hence, we can use preemptive system-level thread scheduling. > I wonder what the size of the data looks like if you allow a gc > point at every instruction. > I guess it probably be too large -- figure a byte or two extra for > every instruction, but maybe not. > > Perhaps it could be encoded in bits instead of bytes and given that > most instructions don't affect the state > (ie: operations on integers, floats, comparisons, branches), maybe > just a zero bit for most instructions. > So then figure a byte or two for every instruction that moves (load > or store) or adds/substracts a pointer. > Or more than that. A byte or two could describe enregistration and > small adds/subtracts, but not large adds/subtracts > or memory offsets. > > OR perhaps it'd just read the code itself. That's easier with Win32/ > x86 since it is so constrained > as to what it outputs. That should be feasible. I realize I'm > changing subjects between the different backends. > > The Windows AMD64 calling convention relies on something LIKE this. > In particular, there is a little encoding associated with every > prolog/epilog so that exception handling can undo the prolog's > effects. > It describes a tiny subset of the instruction set, like register > moves. > > Kind of funny -- once you get into the business of wanting to read > the code to know what it does, > you then get tempted to define your own code, for runtime and > information, and then a possible trick > is to adopt the existing machine code as your code, or whatever > subset your compiler produces. > Hm. The existing machine isn't sufficient. You would need type > information to augment it. > > Which reminds. Another OBVIOUS backend for CM3 for easier > portability is to persist the calls to m3cg and then > write an interpreter for that in C. > > - Jay > > > > From: hosking at cs.purdue.edu > > Date: Sat, 1 Dec 2007 17:42:02 -0500 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] returning record by value vs. by ref? > > > > If this really interests you then you might read this paper: http:// > > doi.acm.org/10.1145/143095.143140 . > > > > On Dec 1, 2007, at 5:36 PM, Jay wrote: > > > > > > 2, don't understand > > > > > > You said it'd take much cooperation with the compiler, due its > > > optimizations, but optimizations can be defeated as necessary. > > > Interior pointers could be marked, perhaps, volatile, so prevent > > > enregistration. I can see that's a potentially high cost though. > > > > > > like > > > Record_t *Record = GetRecord(); > > > unsigned i; > > > for (i = 0 ; i != Record->j ; ++i) > > > { > > > ... > > > } > > > > > > You'd really like Record->j to not be refetched for every loop > > > iteration, but if Record is volatile so the GC can move what it > > > points to and update outstanding pointers, you'd be stuck with > > > something like that. Besides, if j can't be read in one > > > instruction, more problems, assuming a concurrent GC, that cannot > > > reliably get/set the context of other threads. I think, like, you > > > could reliably get/set context on a uniprocessor system, but not a > > > multiprocessor. You'd have to suspend, wait for the suspend to > > > happen.. I guess that could work, but it seems like you'd want to > > > avoid designs that require suspending threads. ? > > > Hm. No, it's difficult. This being a short lived pointer, gc > > > happening on another thread, you'd have to, like, "register" its > > > location with the gc. > > > > > > Hm. Just how does it work? > > > > > > gc suspends threads and updates variables? I don't think so. > > > > > > Variables that are moved leave some sort of "forwarding address" > > > for holders of the old value? > > > > > > The gc isn't concurrent but is called at function entry/exit? I > > > don't think so. > > > > > > I should check the docs and code.. > > > > > > - Jay > > > > > > > > > > > > > From: hosking at cs.purdue.edu > > > > Date: Sat, 1 Dec 2007 17:19:46 -0500 > > > > To: jay.krell at cornell.edu > > > > CC: m3devel at elegosoft.com > > > > Subject: Re: [M3devel] returning record by value vs. by ref? > > > > > > > > > > > > On Dec 1, 2007, at 5:14 PM, Jay wrote: > > > > > > > > > 1) Can pinning not be exposed reasonably in the language? > > > > > I'll keep my pointer just a short time, in a local. > > > > > > > > Yes, that is a *hack* that will work only with the current > > > > conservative garbage collector. In general, the compiler might > > > > record that the local is a pointer derived from some base > reference > > > > and if the GC decides to move the base object it can adjust the > > > local > > > > derived pointer accordingly. > > > > > > > > > 2) surely it could be done at an outer layer? > > > > > Make volatile locals for things you don't want enregistered? > > > > > > > > I don't understand what you mean by this. > > > > > > > > > Even the accessor function approach seems lame, given that I > > > > > believe the Win32/x86 compiler doesn't inline.. :( > > > > > (does the gcc m3 inline across modules, or just compiles > one at a > > > > > time?) > > > > > > > > gcc m3 inlines only within compilation units. > > > > > > > > > > > > > > > > > > > - Jay > > > > > > > > > > > > > > > > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > > > > > > From: hosking at cs.purdue.edu > > > > > > Subject: Re: [M3devel] returning record by value vs. by ref? > > > > > > Date: Sat, 1 Dec 2007 15:23:19 -0500 > > > > > > To: rodney.bates at wichita.edu > > > > > > > > > > > > Correct! Anytime you create an l-value pointer. > > > > > > > > > > > > On Dec 1, 2007, at 2:31 PM, Rodney M. Bates wrote: > > > > > > > > > > > > > Tony Hosking wrote: > > > > > > >> I am assuming 's' here is an open array (REF ARRAY OF > > > item) in > > > > > > >> which case it is allocated in the GC'd heap. There is > > > certainly > > > > > > >> no way of safely getting an interior pointer to items > in the > > > > > > >> stack in Modula-3 -- at least not one that you can upward > > > expose > > > > > > >> (to callers) via return from a procedure. The > difficulty in > > > > > > >> doing this is that the GC moves objects around and would > > > need to > > > > > > >> know where your manufactured interior pointer is being > > > held and > > > > > > >> to which *object* (ie, the open array in this case) it > > > refers so > > > > > > >> that it can 'fix' the pointer when the array object > moves. > > > > > > >> Modula-3 provides a small concession to obtaining > downward > > > > > > >> exposed interior pointers using the VAR parameter > mode. For > > > > > > >> example you can pass 's[i]' as an actual parameter to a > > > VAR mode > > > > > > >> formal, effectively passing a pointer to the callee. GC > > > can cope > > > > > > >> with this in one of two possible ways: 1) "Pin" the array > > > so that > > > > > > >> it cannot be moved while the interior pointer is held > on the > > > > > > >> stack or registers of any thread (this is the approach > > > that CM3's > > > > > > >> conservative collector uses for now); or 2) track the > > > creation of > > > > > > >> such interior pointers and how they are derived from base > > > object > > > > > > >> references for use during GC. 2) requires much more co- > > > operation > > > > > > >> from the compiler than the current gcc-based backend > (with > > > all of > > > > > > >> its lovely optimizations and register allocation) is > > > capable of > > > > > > >> doing. 1) is very cheap and does not impede > optimizations and > > > > > > >> register allocation. > > > > > > > > > > > > > > Presumably, this all also applies WITH-bound > identifiers, when > > > > > they > > > > > > > are > > > > > > > designators of interior components of heap objects? Are > > > there any > > > > > > > other > > > > > > > cases? > > > > > > > > > > > > > > -- > > > > > > > > ------------------------------------------------------------- > > > > > > > Rodney M. Bates, retired assistant professor > > > > > > > Dept. of Computer Science, Wichita State University > > > > > > > Wichita, KS 67260-0083 > > > > > > > 316-978-3922 > > > > > > > rodney.bates at wichita.edu > > > > > > > > > > > > > > > > > > > > > Your smile counts. The more smiles you share, the more we > donate. > > > > > Join in! > > > > > > > > > > > > > Get the power of Windows + Web with the new Windows Live. Power > up! > > > > > You keep typing, we keep giving. Download Messenger and join the > i?m Initiative now. Join in! From jay.krell at cornell.edu Sun Dec 2 07:15:18 2007 From: jay.krell at cornell.edu (Jay) Date: Sun, 2 Dec 2007 06:15:18 +0000 Subject: [M3devel] returning record by value vs. by ref? In-Reply-To: <2B3B82B5-B989-4AC9-8156-02B3B8AC5B46@cs.purdue.edu> References: <1560FF15-8486-4388-ADAE-FADCF71FC5F3@cs.purdue.edu> <4751B69B.1090907@wichita.edu> <2B3B82B5-B989-4AC9-8156-02B3B8AC5B46@cs.purdue.edu> Message-ID: My quick understanding was that gc-points and mostly preemptive thread scheduling could be combined. You would have to cooperatively yield at gc-points, but you could be preemptively yielded anywhere. Er, maybe that's the point -- no cooperative yielding at all, no computation of gc-points, maybe none of this data. But you do end up I guess suspending all the threads and reading their registers and guessing as to the contents..the ambiguity you mention. I wonder how that is dealt with, since any integer can be an arbitrarily ffset pointer..I'll have to read more of the code.. - Jay > From: hosking at cs.purdue.edu> Date: Sun, 2 Dec 2007 00:16:05 -0500> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] returning record by value vs. by ref?> > > On Dec 1, 2007, at 11:11 PM, Jay wrote:> > > Thanks!> >> > I haven't finished reading it, but it sounds like an optimizing > > compiler is ok, due> > to the reliance on "gc points", which I read ahead to find out how > > they are defined.> > If you want fully accurate (non-ambiguous roots) GC then yes you need > gc-points to avoid having to store pointer information for every PC > location.> > > And I'm GUESSING that CM3 already generates and depends on the sort > > of data described there.> > But maybe not.> > Umm, no. CM3 uses an ambiguous roots technique for thread stacks/ > registers that avoids the need for gc-points. Hence, we can use > preemptive system-level thread scheduling.> > > I wonder what the size of the data looks like if you allow a gc > > point at every instruction.> > I guess it probably be too large -- figure a byte or two extra for > > every instruction, but maybe not.> >> > Perhaps it could be encoded in bits instead of bytes and given that > > most instructions don't affect the state> > (ie: operations on integers, floats, comparisons, branches), maybe > > just a zero bit for most instructions.> > So then figure a byte or two for every instruction that moves (load > > or store) or adds/substracts a pointer.> > Or more than that. A byte or two could describe enregistration and > > small adds/subtracts, but not large adds/subtracts> > or memory offsets.> >> > OR perhaps it'd just read the code itself. That's easier with Win32/ > > x86 since it is so constrained> > as to what it outputs. That should be feasible. I realize I'm > > changing subjects between the different backends.> >> > The Windows AMD64 calling convention relies on something LIKE this.> > In particular, there is a little encoding associated with every > > prolog/epilog so that exception handling can undo the prolog's > > effects.> > It describes a tiny subset of the instruction set, like register > > moves.> >> > Kind of funny -- once you get into the business of wanting to read > > the code to know what it does,> > you then get tempted to define your own code, for runtime and > > information, and then a possible trick> > is to adopt the existing machine code as your code, or whatever > > subset your compiler produces.> > Hm. The existing machine isn't sufficient. You would need type > > information to augment it.> >> > Which reminds. Another OBVIOUS backend for CM3 for easier > > portability is to persist the calls to m3cg and then> > write an interpreter for that in C.> >> > - Jay> >> >> > > From: hosking at cs.purdue.edu> > > Date: Sat, 1 Dec 2007 17:42:02 -0500> > > To: jay.krell at cornell.edu> > > CC: m3devel at elegosoft.com> > > Subject: Re: [M3devel] returning record by value vs. by ref?> > >> > > If this really interests you then you might read this paper: http://> > > doi.acm.org/10.1145/143095.143140 .> > >> > > On Dec 1, 2007, at 5:36 PM, Jay wrote:> > >> > > > > 2, don't understand> > > >> > > > You said it'd take much cooperation with the compiler, due its> > > > optimizations, but optimizations can be defeated as necessary.> > > > Interior pointers could be marked, perhaps, volatile, so prevent> > > > enregistration. I can see that's a potentially high cost though.> > > >> > > > like> > > > Record_t *Record = GetRecord();> > > > unsigned i;> > > > for (i = 0 ; i != Record->j ; ++i)> > > > {> > > > ...> > > > }> > > >> > > > You'd really like Record->j to not be refetched for every loop> > > > iteration, but if Record is volatile so the GC can move what it> > > > points to and update outstanding pointers, you'd be stuck with> > > > something like that. Besides, if j can't be read in one> > > > instruction, more problems, assuming a concurrent GC, that cannot> > > > reliably get/set the context of other threads. I think, like, you> > > > could reliably get/set context on a uniprocessor system, but not a> > > > multiprocessor. You'd have to suspend, wait for the suspend to> > > > happen.. I guess that could work, but it seems like you'd want to> > > > avoid designs that require suspending threads. ?> > > > Hm. No, it's difficult. This being a short lived pointer, gc> > > > happening on another thread, you'd have to, like, "register" its> > > > location with the gc.> > > >> > > > Hm. Just how does it work?> > > >> > > > gc suspends threads and updates variables? I don't think so.> > > >> > > > Variables that are moved leave some sort of "forwarding address"> > > > for holders of the old value?> > > >> > > > The gc isn't concurrent but is called at function entry/exit? I> > > > don't think so.> > > >> > > > I should check the docs and code..> > > >> > > > - Jay> > > >> > > >> > > >> > > > > From: hosking at cs.purdue.edu> > > > > Date: Sat, 1 Dec 2007 17:19:46 -0500> > > > > To: jay.krell at cornell.edu> > > > > CC: m3devel at elegosoft.com> > > > > Subject: Re: [M3devel] returning record by value vs. by ref?> > > > >> > > > >> > > > > On Dec 1, 2007, at 5:14 PM, Jay wrote:> > > > >> > > > > > 1) Can pinning not be exposed reasonably in the language?> > > > > > I'll keep my pointer just a short time, in a local.> > > > >> > > > > Yes, that is a *hack* that will work only with the current> > > > > conservative garbage collector. In general, the compiler might> > > > > record that the local is a pointer derived from some base > > reference> > > > > and if the GC decides to move the base object it can adjust the> > > > local> > > > > derived pointer accordingly.> > > > >> > > > > > 2) surely it could be done at an outer layer?> > > > > > Make volatile locals for things you don't want enregistered?> > > > >> > > > > I don't understand what you mean by this.> > > > >> > > > > > Even the accessor function approach seems lame, given that I> > > > > > believe the Win32/x86 compiler doesn't inline.. :(> > > > > > (does the gcc m3 inline across modules, or just compiles > > one at a> > > > > > time?)> > > > >> > > > > gcc m3 inlines only within compilation units.> > > > >> > > > > >> > > > > >> > > > > > - Jay> > > > > >> > > > > >> > > > > > > CC: jay.krell at cornell.edu; m3devel at elegosoft.com> > > > > > > From: hosking at cs.purdue.edu> > > > > > > Subject: Re: [M3devel] returning record by value vs. by ref?> > > > > > > Date: Sat, 1 Dec 2007 15:23:19 -0500> > > > > > > To: rodney.bates at wichita.edu> > > > > > >> > > > > > > Correct! Anytime you create an l-value pointer.> > > > > > >> > > > > > > On Dec 1, 2007, at 2:31 PM, Rodney M. Bates wrote:> > > > > > >> > > > > > > > Tony Hosking wrote:> > > > > > > >> I am assuming 's' here is an open array (REF ARRAY OF> > > > item) in> > > > > > > >> which case it is allocated in the GC'd heap. There is> > > > certainly> > > > > > > >> no way of safely getting an interior pointer to items > > in the> > > > > > > >> stack in Modula-3 -- at least not one that you can upward> > > > expose> > > > > > > >> (to callers) via return from a procedure. The > > difficulty in> > > > > > > >> doing this is that the GC moves objects around and would> > > > need to> > > > > > > >> know where your manufactured interior pointer is being> > > > held and> > > > > > > >> to which *object* (ie, the open array in this case) it> > > > refers so> > > > > > > >> that it can 'fix' the pointer when the array object > > moves.> > > > > > > >> Modula-3 provides a small concession to obtaining > > downward> > > > > > > >> exposed interior pointers using the VAR parameter > > mode. For> > > > > > > >> example you can pass 's[i]' as an actual parameter to a> > > > VAR mode> > > > > > > >> formal, effectively passing a pointer to the callee. GC> > > > can cope> > > > > > > >> with this in one of two possible ways: 1) "Pin" the array> > > > so that> > > > > > > >> it cannot be moved while the interior pointer is held > > on the> > > > > > > >> stack or registers of any thread (this is the approach> > > > that CM3's> > > > > > > >> conservative collector uses for now); or 2) track the> > > > creation of> > > > > > > >> such interior pointers and how they are derived from base> > > > object> > > > > > > >> references for use during GC. 2) requires much more co-> > > > operation> > > > > > > >> from the compiler than the current gcc-based backend > > (with> > > > all of> > > > > > > >> its lovely optimizations and register allocation) is> > > > capable of> > > > > > > >> doing. 1) is very cheap and does not impede > > optimizations and> > > > > > > >> register allocation.> > > > > > > >> > > > > > > > Presumably, this all also applies WITH-bound > > identifiers, when> > > > > > they> > > > > > > > are> > > > > > > > designators of interior components of heap objects? Are> > > > there any> > > > > > > > other> > > > > > > > cases?> > > > > > > >> > > > > > > > --> > > > > > > > > > -------------------------------------------------------------> > > > > > > > Rodney M. Bates, retired assistant professor> > > > > > > > Dept. of Computer Science, Wichita State University> > > > > > > > Wichita, KS 67260-0083> > > > > > > > 316-978-3922> > > > > > > > rodney.bates at wichita.edu> > > > > > >> > > > > >> > > > > >> > > > > > Your smile counts. The more smiles you share, the more we > > donate.> > > > > > Join in!> > > > >> > > >> > > >> > > > Get the power of Windows + Web with the new Windows Live. Power > > up!> > >> >> >> > You keep typing, we keep giving. Download Messenger and join the > > i?m Initiative now. Join in!> _________________________________________________________________ Share life as it happens with the new Windows Live.Download today it's FREE! http://www.windowslive.com/share.html?ocid=TXT_TAGLM_Wave2_sharelife_112007 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 2 18:23:29 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 2 Dec 2007 12:23:29 -0500 Subject: [M3devel] returning record by value vs. by ref? In-Reply-To: References: <1560FF15-8486-4388-ADAE-FADCF71FC5F3@cs.purdue.edu> <4751B69B.1090907@wichita.edu> <2B3B82B5-B989-4AC9-8156-02B3B8AC5B46@cs.purdue.edu> Message-ID: <6A62D86F-1AAD-4CBE-9348-C0A0210AA291@cs.purdue.edu> On Dec 2, 2007, at 1:15 AM, Jay wrote: > My quick understanding was that gc-points and mostly preemptive > thread scheduling could be combined. A little but doable: if a thread is preempted and GC occurs then you have a problem, needing to roll the thread forward to a GC point. > You would have to cooperatively yield at gc-points, but you could > be preemptively yielded anywhere. > Er, maybe that's the point -- no cooperative yielding at all, no > computation of gc-points, maybe none of this data. Yes, that's the point about ambiguous roots collection. > But you do end up I guess suspending all the threads and reading > their registers and guessing as to the contents..the ambiguity you > mention. I wonder how that is dealt with, since any integer can be > an arbitrarily ffset pointer.. The current ambiguous roots collector pins objects referred to by ambiguous roots (thread stacks/registers). It moves objects that are not referred to by ambiguous roots. > I'll have to read more of the code.. > > - Jay > > > > From: hosking at cs.purdue.edu > > Date: Sun, 2 Dec 2007 00:16:05 -0500 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] returning record by value vs. by ref? > > > > > > On Dec 1, 2007, at 11:11 PM, Jay wrote: > > > > > Thanks! > > > > > > I haven't finished reading it, but it sounds like an optimizing > > > compiler is ok, due > > > to the reliance on "gc points", which I read ahead to find out how > > > they are defined. > > > > If you want fully accurate (non-ambiguous roots) GC then yes you > need > > gc-points to avoid having to store pointer information for every PC > > location. > > > > > And I'm GUESSING that CM3 already generates and depends on the > sort > > > of data described there. > > > But maybe not. > > > > Umm, no. CM3 uses an ambiguous roots technique for thread stacks/ > > registers that avoids the need for gc-points. Hence, we can use > > preemptive system-level thread scheduling. > > > > > I wonder what the size of the data looks like if you allow a gc > > > point at every instruction. > > > I guess it probably be too large -- figure a byte or two extra for > > > every instruction, but maybe not. > > > > > > Perhaps it could be encoded in bits instead of bytes and given > that > > > most instructions don't affect the state > > > (ie: operations on integers, floats, comparisons, branches), maybe > > > just a zero bit for most instructions. > > > So then figure a byte or two for every instruction that moves > (load > > > or store) or adds/substracts a pointer. > > > Or more than that. A byte or two could describe enregistration and > > > small adds/subtracts, but not large adds/subtracts > > > or memory offsets. > > > > > > OR perhaps it'd just read the code itself. That's easier with > Win32/ > > > x86 since it is so constrained > > > as to what it outputs. That should be feasible. I realize I'm > > > changing subjects between the different backends. > > > > > > The Windows AMD64 calling convention relies on something LIKE > this. > > > In particular, there is a little encoding associated with every > > > prolog/epilog so that exception handling can undo the prolog's > > > effects. > > > It describes a tiny subset of the instruction set, like register > > > moves. > > > > > > Kind of funny -- once you get into the business of wanting to read > > > the code to know what it does, > > > you then get tempted to define your own code, for runtime and > > > information, and then a possible trick > > > is to adopt the existing machine code as your code, or whatever > > > subset your compiler produces. > > > Hm. The existing machine isn't sufficient. You would need type > > > information to augment it. > > > > > > Which reminds. Another OBVIOUS backend for CM3 for easier > > > portability is to persist the calls to m3cg and then > > > write an interpreter for that in C. > > > > > > - Jay > > > > > > > > > > From: hosking at cs.purdue.edu > > > > Date: Sat, 1 Dec 2007 17:42:02 -0500 > > > > To: jay.krell at cornell.edu > > > > CC: m3devel at elegosoft.com > > > > Subject: Re: [M3devel] returning record by value vs. by ref? > > > > > > > > If this really interests you then you might read this paper: > http:// > > > > doi.acm.org/10.1145/143095.143140 . > > > > > > > > On Dec 1, 2007, at 5:36 PM, Jay wrote: > > > > > > > > > > 2, don't understand > > > > > > > > > > You said it'd take much cooperation with the compiler, due its > > > > > optimizations, but optimizations can be defeated as necessary. > > > > > Interior pointers could be marked, perhaps, volatile, so > prevent > > > > > enregistration. I can see that's a potentially high cost > though. > > > > > > > > > > like > > > > > Record_t *Record = GetRecord(); > > > > > unsigned i; > > > > > for (i = 0 ; i != Record->j ; ++i) > > > > > { > > > > > ... > > > > > } > > > > > > > > > > You'd really like Record->j to not be refetched for every loop > > > > > iteration, but if Record is volatile so the GC can move > what it > > > > > points to and update outstanding pointers, you'd be stuck with > > > > > something like that. Besides, if j can't be read in one > > > > > instruction, more problems, assuming a concurrent GC, that > cannot > > > > > reliably get/set the context of other threads. I think, > like, you > > > > > could reliably get/set context on a uniprocessor system, > but not a > > > > > multiprocessor. You'd have to suspend, wait for the suspend to > > > > > happen.. I guess that could work, but it seems like you'd > want to > > > > > avoid designs that require suspending threads. ? > > > > > Hm. No, it's difficult. This being a short lived pointer, gc > > > > > happening on another thread, you'd have to, like, > "register" its > > > > > location with the gc. > > > > > > > > > > Hm. Just how does it work? > > > > > > > > > > gc suspends threads and updates variables? I don't think so. > > > > > > > > > > Variables that are moved leave some sort of "forwarding > address" > > > > > for holders of the old value? > > > > > > > > > > The gc isn't concurrent but is called at function entry/ > exit? I > > > > > don't think so. > > > > > > > > > > I should check the docs and code.. > > > > > > > > > > - Jay > > > > > > > > > > > > > > > > > > > > > From: hosking at cs.purdue.edu > > > > > > Date: Sat, 1 Dec 2007 17:19:46 -0500 > > > > > > To: jay.krell at cornell.edu > > > > > > CC: m3devel at elegosoft.com > > > > > > Subject: Re: [M3devel] returning record by value vs. by ref? > > > > > > > > > > > > > > > > > > On Dec 1, 2007, at 5:14 PM, Jay wrote: > > > > > > > > > > > > > 1) Can pinning not be exposed reasonably in the language? > > > > > > > I'll keep my pointer just a short time, in a local. > > > > > > > > > > > > Yes, that is a *hack* that will work only with the current > > > > > > conservative garbage collector. In general, the compiler > might > > > > > > record that the local is a pointer derived from some base > > > reference > > > > > > and if the GC decides to move the base object it can > adjust the > > > > > local > > > > > > derived pointer accordingly. > > > > > > > > > > > > > 2) surely it could be done at an outer layer? > > > > > > > Make volatile locals for things you don't want > enregistered? > > > > > > > > > > > > I don't understand what you mean by this. > > > > > > > > > > > > > Even the accessor function approach seems lame, given > that I > > > > > > > believe the Win32/x86 compiler doesn't inline.. :( > > > > > > > (does the gcc m3 inline across modules, or just compiles > > > one at a > > > > > > > time?) > > > > > > > > > > > > gcc m3 inlines only within compilation units. > > > > > > > > > > > > > > > > > > > > > > > > > > > - Jay > > > > > > > > > > > > > > > > > > > > > > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > > > > > > > > From: hosking at cs.purdue.edu > > > > > > > > Subject: Re: [M3devel] returning record by value vs. > by ref? > > > > > > > > Date: Sat, 1 Dec 2007 15:23:19 -0500 > > > > > > > > To: rodney.bates at wichita.edu > > > > > > > > > > > > > > > > Correct! Anytime you create an l-value pointer. > > > > > > > > > > > > > > > > On Dec 1, 2007, at 2:31 PM, Rodney M. Bates wrote: > > > > > > > > > > > > > > > > > Tony Hosking wrote: > > > > > > > > >> I am assuming 's' here is an open array (REF ARRAY OF > > > > > item) in > > > > > > > > >> which case it is allocated in the GC'd heap. There is > > > > > certainly > > > > > > > > >> no way of safely getting an interior pointer to items > > > in the > > > > > > > > >> stack in Modula-3 -- at least not one that you can > upward > > > > > expose > > > > > > > > >> (to callers) via return from a procedure. The > > > difficulty in > > > > > > > > >> doing this is that the GC moves objects around and > would > > > > > need to > > > > > > > > >> know where your manufactured interior pointer is > being > > > > > held and > > > > > > > > >> to which *object* (ie, the open array in this > case) it > > > > > refers so > > > > > > > > >> that it can 'fix' the pointer when the array object > > > moves. > > > > > > > > >> Modula-3 provides a small concession to obtaining > > > downward > > > > > > > > >> exposed interior pointers using the VAR parameter > > > mode. For > > > > > > > > >> example you can pass 's[i]' as an actual parameter > to a > > > > > VAR mode > > > > > > > > >> formal, effectively passing a pointer to the > callee. GC > > > > > can cope > > > > > > > > >> with this in one of two possible ways: 1) "Pin" > the array > > > > > so that > > > > > > > > >> it cannot be moved while the interior pointer is held > > > on the > > > > > > > > >> stack or registers of any thread (this is the > approach > > > > > that CM3's > > > > > > > > >> conservative collector uses for now); or 2) track the > > > > > creation of > > > > > > > > >> such interior pointers and how they are derived > from base > > > > > object > > > > > > > > >> references for use during GC. 2) requires much > more co- > > > > > operation > > > > > > > > >> from the compiler than the current gcc-based backend > > > (with > > > > > all of > > > > > > > > >> its lovely optimizations and register allocation) is > > > > > capable of > > > > > > > > >> doing. 1) is very cheap and does not impede > > > optimizations and > > > > > > > > >> register allocation. > > > > > > > > > > > > > > > > > > Presumably, this all also applies WITH-bound > > > identifiers, when > > > > > > > they > > > > > > > > > are > > > > > > > > > designators of interior components of heap objects? > Are > > > > > there any > > > > > > > > > other > > > > > > > > > cases? > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > ------------------------------------------------------------- > > > > > > > > > Rodney M. Bates, retired assistant professor > > > > > > > > > Dept. of Computer Science, Wichita State University > > > > > > > > > Wichita, KS 67260-0083 > > > > > > > > > 316-978-3922 > > > > > > > > > rodney.bates at wichita.edu > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your smile counts. The more smiles you share, the more we > > > donate. > > > > > > > Join in! > > > > > > > > > > > > > > > > > > > > > Get the power of Windows + Web with the new Windows Live. > Power > > > up! > > > > > > > > > > > > > You keep typing, we keep giving. Download Messenger and join the > > > i?m Initiative now. Join in! > > > > > Share life as it happens with the new Windows Live. Share now! From jay.krell at cornell.edu Sun Dec 2 19:54:25 2007 From: jay.krell at cornell.edu (Jay) Date: Sun, 2 Dec 2007 18:54:25 +0000 Subject: [M3devel] returning record by value vs. by ref? In-Reply-To: <6A62D86F-1AAD-4CBE-9348-C0A0210AA291@cs.purdue.edu> References: <1560FF15-8486-4388-ADAE-FADCF71FC5F3@cs.purdue.edu> <4751B69B.1090907@wichita.edu> <2B3B82B5-B989-4AC9-8156-02B3B8AC5B46@cs.purdue.edu> <6A62D86F-1AAD-4CBE-9348-C0A0210AA291@cs.purdue.edu> Message-ID: > roll forward to gc-point Right, the paper says the gc will wait till all threads are at gc-points, and gc-points are defined/inserted enough to make it probably not long -- allocations, calls/returns, loop boundaries, roughly. > ambiguous.. The problem in my mind is "how ambiguous?". Can't almost anything be a pointer in disguise? This example from the paper: Double Indexing: The code A[i] := 1; B[i] := 2; may be optimized to t1 = &A[0] + (i * sizeof(int)); t2 = &B[0] - &A[0]; *tl = 1; *(tl + t2) = 2; which is useful on machines that have addressing modes with two or more index registers, such as the SPARC. More from the paper, emphasis mine: Note that a derived value may bean untidy pointer to the interior of an object (strength reduction example), an untidy pointer that points outside the object to which it refers (virtual array origin example), or even a non-pointer value (double indexing example), and the examples given above may not exhaust the possibilities - Jay > From: hosking at cs.purdue.edu> Date: Sun, 2 Dec 2007 12:23:29 -0500> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] returning record by value vs. by ref?> > > On Dec 2, 2007, at 1:15 AM, Jay wrote:> > > My quick understanding was that gc-points and mostly preemptive > > thread scheduling could be combined.> > A little but doable: if a thread is preempted and GC occurs then you > have a problem, needing to roll the thread forward to a GC point.> > > You would have to cooperatively yield at gc-points, but you could > > be preemptively yielded anywhere.> > Er, maybe that's the point -- no cooperative yielding at all, no > > computation of gc-points, maybe none of this data.> > Yes, that's the point about ambiguous roots collection.> > > But you do end up I guess suspending all the threads and reading > > their registers and guessing as to the contents..the ambiguity you > > mention. I wonder how that is dealt with, since any integer can be > > an arbitrarily ffset pointer..> > The current ambiguous roots collector pins objects referred to by > ambiguous roots (thread stacks/registers). It moves objects that are > not referred to by ambiguous roots.> > > I'll have to read more of the code..> >> > - Jay> >> >> > > From: hosking at cs.purdue.edu> > > Date: Sun, 2 Dec 2007 00:16:05 -0500> > > To: jay.krell at cornell.edu> > > CC: m3devel at elegosoft.com> > > Subject: Re: [M3devel] returning record by value vs. by ref?> > >> > >> > > On Dec 1, 2007, at 11:11 PM, Jay wrote:> > >> > > > Thanks!> > > >> > > > I haven't finished reading it, but it sounds like an optimizing> > > > compiler is ok, due> > > > to the reliance on "gc points", which I read ahead to find out how> > > > they are defined.> > >> > > If you want fully accurate (non-ambiguous roots) GC then yes you > > need> > > gc-points to avoid having to store pointer information for every PC> > > location.> > >> > > > And I'm GUESSING that CM3 already generates and depends on the > > sort> > > > of data described there.> > > > But maybe not.> > >> > > Umm, no. CM3 uses an ambiguous roots technique for thread stacks/> > > registers that avoids the need for gc-points. Hence, we can use> > > preemptive system-level thread scheduling.> > >> > > > I wonder what the size of the data looks like if you allow a gc> > > > point at every instruction.> > > > I guess it probably be too large -- figure a byte or two extra for> > > > every instruction, but maybe not.> > > >> > > > Perhaps it could be encoded in bits instead of bytes and given > > that> > > > most instructions don't affect the state> > > > (ie: operations on integers, floats, comparisons, branches), maybe> > > > just a zero bit for most instructions.> > > > So then figure a byte or two for every instruction that moves > > (load> > > > or store) or adds/substracts a pointer.> > > > Or more than that. A byte or two could describe enregistration and> > > > small adds/subtracts, but not large adds/subtracts> > > > or memory offsets.> > > >> > > > OR perhaps it'd just read the code itself. That's easier with > > Win32/> > > > x86 since it is so constrained> > > > as to what it outputs. That should be feasible. I realize I'm> > > > changing subjects between the different backends.> > > >> > > > The Windows AMD64 calling convention relies on something LIKE > > this.> > > > In particular, there is a little encoding associated with every> > > > prolog/epilog so that exception handling can undo the prolog's> > > > effects.> > > > It describes a tiny subset of the instruction set, like register> > > > moves.> > > >> > > > Kind of funny -- once you get into the business of wanting to read> > > > the code to know what it does,> > > > you then get tempted to define your own code, for runtime and> > > > information, and then a possible trick> > > > is to adopt the existing machine code as your code, or whatever> > > > subset your compiler produces.> > > > Hm. The existing machine isn't sufficient. You would need type> > > > information to augment it.> > > >> > > > Which reminds. Another OBVIOUS backend for CM3 for easier> > > > portability is to persist the calls to m3cg and then> > > > write an interpreter for that in C.> > > >> > > > - Jay> > > >> > > >> > > > > From: hosking at cs.purdue.edu> > > > > Date: Sat, 1 Dec 2007 17:42:02 -0500> > > > > To: jay.krell at cornell.edu> > > > > CC: m3devel at elegosoft.com> > > > > Subject: Re: [M3devel] returning record by value vs. by ref?> > > > >> > > > > If this really interests you then you might read this paper: > > http://> > > > > doi.acm.org/10.1145/143095.143140 .> > > > >> > > > > On Dec 1, 2007, at 5:36 PM, Jay wrote:> > > > >> > > > > > > 2, don't understand> > > > > >> > > > > > You said it'd take much cooperation with the compiler, due its> > > > > > optimizations, but optimizations can be defeated as necessary.> > > > > > Interior pointers could be marked, perhaps, volatile, so > > prevent> > > > > > enregistration. I can see that's a potentially high cost > > though.> > > > > >> > > > > > like> > > > > > Record_t *Record = GetRecord();> > > > > > unsigned i;> > > > > > for (i = 0 ; i != Record->j ; ++i)> > > > > > {> > > > > > ...> > > > > > }> > > > > >> > > > > > You'd really like Record->j to not be refetched for every loop> > > > > > iteration, but if Record is volatile so the GC can move > > what it> > > > > > points to and update outstanding pointers, you'd be stuck with> > > > > > something like that. Besides, if j can't be read in one> > > > > > instruction, more problems, assuming a concurrent GC, that > > cannot> > > > > > reliably get/set the context of other threads. I think, > > like, you> > > > > > could reliably get/set context on a uniprocessor system, > > but not a> > > > > > multiprocessor. You'd have to suspend, wait for the suspend to> > > > > > happen.. I guess that could work, but it seems like you'd > > want to> > > > > > avoid designs that require suspending threads. ?> > > > > > Hm. No, it's difficult. This being a short lived pointer, gc> > > > > > happening on another thread, you'd have to, like, > > "register" its> > > > > > location with the gc.> > > > > >> > > > > > Hm. Just how does it work?> > > > > >> > > > > > gc suspends threads and updates variables? I don't think so.> > > > > >> > > > > > Variables that are moved leave some sort of "forwarding > > address"> > > > > > for holders of the old value?> > > > > >> > > > > > The gc isn't concurrent but is called at function entry/ > > exit? I> > > > > > don't think so.> > > > > >> > > > > > I should check the docs and code..> > > > > >> > > > > > - Jay> > > > > >> > > > > >> > > > > >> > > > > > > From: hosking at cs.purdue.edu> > > > > > > Date: Sat, 1 Dec 2007 17:19:46 -0500> > > > > > > To: jay.krell at cornell.edu> > > > > > > CC: m3devel at elegosoft.com> > > > > > > Subject: Re: [M3devel] returning record by value vs. by ref?> > > > > > >> > > > > > >> > > > > > > On Dec 1, 2007, at 5:14 PM, Jay wrote:> > > > > > >> > > > > > > > 1) Can pinning not be exposed reasonably in the language?> > > > > > > > I'll keep my pointer just a short time, in a local.> > > > > > >> > > > > > > Yes, that is a *hack* that will work only with the current> > > > > > > conservative garbage collector. In general, the compiler > > might> > > > > > > record that the local is a pointer derived from some base> > > > reference> > > > > > > and if the GC decides to move the base object it can > > adjust the> > > > > > local> > > > > > > derived pointer accordingly.> > > > > > >> > > > > > > > 2) surely it could be done at an outer layer?> > > > > > > > Make volatile locals for things you don't want > > enregistered?> > > > > > >> > > > > > > I don't understand what you mean by this.> > > > > > >> > > > > > > > Even the accessor function approach seems lame, given > > that I> > > > > > > > believe the Win32/x86 compiler doesn't inline.. :(> > > > > > > > (does the gcc m3 inline across modules, or just compiles> > > > one at a> > > > > > > > time?)> > > > > > >> > > > > > > gcc m3 inlines only within compilation units.> > > > > > >> > > > > > > >> > > > > > > >> > > > > > > > - Jay> > > > > > > >> > > > > > > >> > > > > > > > > CC: jay.krell at cornell.edu; m3devel at elegosoft.com> > > > > > > > > From: hosking at cs.purdue.edu> > > > > > > > > Subject: Re: [M3devel] returning record by value vs. > > by ref?> > > > > > > > > Date: Sat, 1 Dec 2007 15:23:19 -0500> > > > > > > > > To: rodney.bates at wichita.edu> > > > > > > > >> > > > > > > > > Correct! Anytime you create an l-value pointer.> > > > > > > > >> > > > > > > > > On Dec 1, 2007, at 2:31 PM, Rodney M. Bates wrote:> > > > > > > > >> > > > > > > > > > Tony Hosking wrote:> > > > > > > > > >> I am assuming 's' here is an open array (REF ARRAY OF> > > > > > item) in> > > > > > > > > >> which case it is allocated in the GC'd heap. There is> > > > > > certainly> > > > > > > > > >> no way of safely getting an interior pointer to items> > > > in the> > > > > > > > > >> stack in Modula-3 -- at least not one that you can > > upward> > > > > > expose> > > > > > > > > >> (to callers) via return from a procedure. The> > > > difficulty in> > > > > > > > > >> doing this is that the GC moves objects around and > > would> > > > > > need to> > > > > > > > > >> know where your manufactured interior pointer is > > being> > > > > > held and> > > > > > > > > >> to which *object* (ie, the open array in this > > case) it> > > > > > refers so> > > > > > > > > >> that it can 'fix' the pointer when the array object> > > > moves.> > > > > > > > > >> Modula-3 provides a small concession to obtaining> > > > downward> > > > > > > > > >> exposed interior pointers using the VAR parameter> > > > mode. For> > > > > > > > > >> example you can pass 's[i]' as an actual parameter > > to a> > > > > > VAR mode> > > > > > > > > >> formal, effectively passing a pointer to the > > callee. GC> > > > > > can cope> > > > > > > > > >> with this in one of two possible ways: 1) "Pin" > > the array> > > > > > so that> > > > > > > > > >> it cannot be moved while the interior pointer is held> > > > on the> > > > > > > > > >> stack or registers of any thread (this is the > > approach> > > > > > that CM3's> > > > > > > > > >> conservative collector uses for now); or 2) track the> > > > > > creation of> > > > > > > > > >> such interior pointers and how they are derived > > from base> > > > > > object> > > > > > > > > >> references for use during GC. 2) requires much > > more co-> > > > > > operation> > > > > > > > > >> from the compiler than the current gcc-based backend> > > > (with> > > > > > all of> > > > > > > > > >> its lovely optimizations and register allocation) is> > > > > > capable of> > > > > > > > > >> doing. 1) is very cheap and does not impede> > > > optimizations and> > > > > > > > > >> register allocation.> > > > > > > > > >> > > > > > > > > > Presumably, this all also applies WITH-bound> > > > identifiers, when> > > > > > > > they> > > > > > > > > > are> > > > > > > > > > designators of interior components of heap objects? > > Are> > > > > > there any> > > > > > > > > > other> > > > > > > > > > cases?> > > > > > > > > >> > > > > > > > > > --> > > > > > > > > >> > > > -------------------------------------------------------------> > > > > > > > > > Rodney M. Bates, retired assistant professor> > > > > > > > > > Dept. of Computer Science, Wichita State University> > > > > > > > > > Wichita, KS 67260-0083> > > > > > > > > > 316-978-3922> > > > > > > > > > rodney.bates at wichita.edu> > > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > > Your smile counts. The more smiles you share, the more we> > > > donate.> > > > > > > > Join in!> > > > > > >> > > > > >> > > > > >> > > > > > Get the power of Windows + Web with the new Windows Live. > > Power> > > > up!> > > > >> > > >> > > >> > > > You keep typing, we keep giving. Download Messenger and join the> > > > i?m Initiative now. Join in!> > >> >> >> > Share life as it happens with the new Windows Live. Share now!> _________________________________________________________________ Your smile counts. The more smiles you share, the more we donate.? Join in. www.windowslive.com/smile?ocid=TXT_TAGLM_Wave2_oprsmilewlhmtagline -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 2 20:11:55 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 2 Dec 2007 14:11:55 -0500 Subject: [M3devel] returning record by value vs. by ref? In-Reply-To: References: <1560FF15-8486-4388-ADAE-FADCF71FC5F3@cs.purdue.edu> <4751B69B.1090907@wichita.edu> <2B3B82B5-B989-4AC9-8156-02B3B8AC5B46@cs.purdue.edu> <6A62D86F-1AAD-4CBE-9348-C0A0210AA291@cs.purdue.edu> Message-ID: On Dec 2, 2007, at 1:54 PM, Jay wrote: > > roll forward to gc-point > > Right, the paper says the gc will wait till all threads are at gc- > points, and gc-points are defined/inserted enough to make it > probably not long -- allocations, calls/returns, loop boundaries, > roughly. My problem with this for preemptive scheduling is that roll-forward can take a long time -- too long if one wants short GCs. Currently, GC can occur at almost all preemption points. > > ambiguous.. > > The problem in my mind is "how ambiguous?". > Can't almost anything be a pointer in disguise? Indeed, for CM3 currently any word-aligned, word-length bit string in stacks or registers is treated as a potential ambiguous root. > This example from the paper: > > Double Indexing: The code > A[i] := 1; > B[i] := 2; > may be optimized to > t1 = &A[0] + (i * sizeof(int)); > t2 = &B[0] - &A[0]; > *tl = 1; > *(tl + t2) = 2; > > which is useful on machines that have addressing modes > with two or more index registers, such as the SPARC. > > More from the paper, emphasis mine: > > Note that a derived value > may bean untidy pointer to the interior of an object (strength > reduction example), an untidy pointer that points outside the > object to which it refers (virtual array origin example), or > even a non-pointer value (double indexing example), and > the examples given above may not exhaust the possibilities This all depends on what sorts of optimizations are permitted, as you have already noted. > > > - Jay > > > > From: hosking at cs.purdue.edu > > Date: Sun, 2 Dec 2007 12:23:29 -0500 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] returning record by value vs. by ref? > > > > > > On Dec 2, 2007, at 1:15 AM, Jay wrote: > > > > > My quick understanding was that gc-points and mostly preemptive > > > thread scheduling could be combined. > > > > A little but doable: if a thread is preempted and GC occurs then you > > have a problem, needing to roll the thread forward to a GC point. > > > > > You would have to cooperatively yield at gc-points, but you could > > > be preemptively yielded anywhere. > > > Er, maybe that's the point -- no cooperative yielding at all, no > > > computation of gc-points, maybe none of this data. > > > > Yes, that's the point about ambiguous roots collection. > > > > > But you do end up I guess suspending all the threads and reading > > > their registers and guessing as to the contents..the ambiguity you > > > mention. I wonder how that is dealt with, since any integer can be > > > an arbitrarily ffset pointer.. > > > > The current ambiguous roots collector pins objects referred to by > > ambiguous roots (thread stacks/registers). It moves objects that are > > not referred to by ambiguous roots. > > > > > I'll have to read more of the code.. > > > > > > - Jay > > > > > > > > > > From: hosking at cs.purdue.edu > > > > Date: Sun, 2 Dec 2007 00:16:05 -0500 > > > > To: jay.krell at cornell.edu > > > > CC: m3devel at elegosoft.com > > > > Subject: Re: [M3devel] returning record by value vs. by ref? > > > > > > > > > > > > On Dec 1, 2007, at 11:11 PM, Jay wrote: > > > > > > > > > Thanks! > > > > > > > > > > I haven't finished reading it, but it sounds like an > optimizing > > > > > compiler is ok, due > > > > > to the reliance on "gc points", which I read ahead to find > out how > > > > > they are defined. > > > > > > > > If you want fully accurate (non-ambiguous roots) GC then yes you > > > need > > > > gc-points to avoid having to store pointer information for > every PC > > > > location. > > > > > > > > > And I'm GUESSING that CM3 already generates and depends on the > > > sort > > > > > of data described there. > > > > > But maybe not. > > > > > > > > Umm, no. CM3 uses an ambiguous roots technique for thread > stacks/ > > > > registers that avoids the need for gc-points. Hence, we can use > > > > preemptive system-level thread scheduling. > > > > > > > > > I wonder what the size of the data looks like if you allow > a gc > > > > > point at every instruction. > > > > > I guess it probably be too large -- figure a byte or two > extra for > > > > > every instruction, but maybe not. > > > > > > > > > > Perhaps it could be encoded in bits instead of bytes and given > > > that > > > > > most instructions don't affect the state > > > > > (ie: operations on integers, floats, comparisons, > branches), maybe > > > > > just a zero bit for most instructions. > > > > > So then figure a byte or two for every instruction that moves > > > (load > > > > > or store) or adds/substracts a pointer. > > > > > Or more than that. A byte or two could describe > enregistration and > > > > > small adds/subtracts, but not large adds/subtracts > > > > > or memory offsets. > > > > > > > > > > OR perhaps it'd just read the code itself. That's easier with > > > Win32/ > > > > > x86 since it is so constrained > > > > > as to what it outputs. That should be feasible. I realize I'm > > > > > changing subjects between the different backends. > > > > > > > > > > The Windows AMD64 calling convention relies on something LIKE > > > this. > > > > > In particular, there is a little encoding associated with > every > > > > > prolog/epilog so that exception handling can undo the prolog's > > > > > effects. > > > > > It describes a tiny subset of the instruction set, like > register > > > > > moves. > > > > > > > > > > Kind of funny -- once you get into the business of wanting > to read > > > > > the code to know what it does, > > > > > you then get tempted to define your own code, for runtime and > > > > > information, and then a possible trick > > > > > is to adopt the existing machine code as your code, or > whatever > > > > > subset your compiler produces. > > > > > Hm. The existing machine isn't sufficient. You would need type > > > > > information to augment it. > > > > > > > > > > Which reminds. Another OBVIOUS backend for CM3 for easier > > > > > portability is to persist the calls to m3cg and then > > > > > write an interpreter for that in C. > > > > > > > > > > - Jay > > > > > > > > > > > > > > > > From: hosking at cs.purdue.edu > > > > > > Date: Sat, 1 Dec 2007 17:42:02 -0500 > > > > > > To: jay.krell at cornell.edu > > > > > > CC: m3devel at elegosoft.com > > > > > > Subject: Re: [M3devel] returning record by value vs. by ref? > > > > > > > > > > > > If this really interests you then you might read this paper: > > > http:// > > > > > > doi.acm.org/10.1145/143095.143140 . > > > > > > > > > > > > On Dec 1, 2007, at 5:36 PM, Jay wrote: > > > > > > > > > > > > > > 2, don't understand > > > > > > > > > > > > > > You said it'd take much cooperation with the compiler, > due its > > > > > > > optimizations, but optimizations can be defeated as > necessary. > > > > > > > Interior pointers could be marked, perhaps, volatile, so > > > prevent > > > > > > > enregistration. I can see that's a potentially high cost > > > though. > > > > > > > > > > > > > > like > > > > > > > Record_t *Record = GetRecord(); > > > > > > > unsigned i; > > > > > > > for (i = 0 ; i != Record->j ; ++i) > > > > > > > { > > > > > > > ... > > > > > > > } > > > > > > > > > > > > > > You'd really like Record->j to not be refetched for > every loop > > > > > > > iteration, but if Record is volatile so the GC can move > > > what it > > > > > > > points to and update outstanding pointers, you'd be > stuck with > > > > > > > something like that. Besides, if j can't be read in one > > > > > > > instruction, more problems, assuming a concurrent GC, that > > > cannot > > > > > > > reliably get/set the context of other threads. I think, > > > like, you > > > > > > > could reliably get/set context on a uniprocessor system, > > > but not a > > > > > > > multiprocessor. You'd have to suspend, wait for the > suspend to > > > > > > > happen.. I guess that could work, but it seems like you'd > > > want to > > > > > > > avoid designs that require suspending threads. ? > > > > > > > Hm. No, it's difficult. This being a short lived > pointer, gc > > > > > > > happening on another thread, you'd have to, like, > > > "register" its > > > > > > > location with the gc. > > > > > > > > > > > > > > Hm. Just how does it work? > > > > > > > > > > > > > > gc suspends threads and updates variables? I don't > think so. > > > > > > > > > > > > > > Variables that are moved leave some sort of "forwarding > > > address" > > > > > > > for holders of the old value? > > > > > > > > > > > > > > The gc isn't concurrent but is called at function entry/ > > > exit? I > > > > > > > don't think so. > > > > > > > > > > > > > > I should check the docs and code.. > > > > > > > > > > > > > > - Jay > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: hosking at cs.purdue.edu > > > > > > > > Date: Sat, 1 Dec 2007 17:19:46 -0500 > > > > > > > > To: jay.krell at cornell.edu > > > > > > > > CC: m3devel at elegosoft.com > > > > > > > > Subject: Re: [M3devel] returning record by value vs. > by ref? > > > > > > > > > > > > > > > > > > > > > > > > On Dec 1, 2007, at 5:14 PM, Jay wrote: > > > > > > > > > > > > > > > > > 1) Can pinning not be exposed reasonably in the > language? > > > > > > > > > I'll keep my pointer just a short time, in a local. > > > > > > > > > > > > > > > > Yes, that is a *hack* that will work only with the > current > > > > > > > > conservative garbage collector. In general, the compiler > > > might > > > > > > > > record that the local is a pointer derived from some > base > > > > > reference > > > > > > > > and if the GC decides to move the base object it can > > > adjust the > > > > > > > local > > > > > > > > derived pointer accordingly. > > > > > > > > > > > > > > > > > 2) surely it could be done at an outer layer? > > > > > > > > > Make volatile locals for things you don't want > > > enregistered? > > > > > > > > > > > > > > > > I don't understand what you mean by this. > > > > > > > > > > > > > > > > > Even the accessor function approach seems lame, given > > > that I > > > > > > > > > believe the Win32/x86 compiler doesn't inline.. :( > > > > > > > > > (does the gcc m3 inline across modules, or just > compiles > > > > > one at a > > > > > > > > > time?) > > > > > > > > > > > > > > > > gcc m3 inlines only within compilation units. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - Jay > > > > > > > > > > > > > > > > > > > > > > > > > > > > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > > > > > > > > > > From: hosking at cs.purdue.edu > > > > > > > > > > Subject: Re: [M3devel] returning record by value vs. > > > by ref? > > > > > > > > > > Date: Sat, 1 Dec 2007 15:23:19 -0500 > > > > > > > > > > To: rodney.bates at wichita.edu > > > > > > > > > > > > > > > > > > > > Correct! Anytime you create an l-value pointer. > > > > > > > > > > > > > > > > > > > > On Dec 1, 2007, at 2:31 PM, Rodney M. Bates wrote: > > > > > > > > > > > > > > > > > > > > > Tony Hosking wrote: > > > > > > > > > > >> I am assuming 's' here is an open array (REF > ARRAY OF > > > > > > > item) in > > > > > > > > > > >> which case it is allocated in the GC'd heap. > There is > > > > > > > certainly > > > > > > > > > > >> no way of safely getting an interior pointer > to items > > > > > in the > > > > > > > > > > >> stack in Modula-3 -- at least not one that you > can > > > upward > > > > > > > expose > > > > > > > > > > >> (to callers) via return from a procedure. The > > > > > difficulty in > > > > > > > > > > >> doing this is that the GC moves objects around > and > > > would > > > > > > > need to > > > > > > > > > > >> know where your manufactured interior pointer is > > > being > > > > > > > held and > > > > > > > > > > >> to which *object* (ie, the open array in this > > > case) it > > > > > > > refers so > > > > > > > > > > >> that it can 'fix' the pointer when the array > object > > > > > moves. > > > > > > > > > > >> Modula-3 provides a small concession to obtaining > > > > > downward > > > > > > > > > > >> exposed interior pointers using the VAR parameter > > > > > mode. For > > > > > > > > > > >> example you can pass 's[i]' as an actual > parameter > > > to a > > > > > > > VAR mode > > > > > > > > > > >> formal, effectively passing a pointer to the > > > callee. GC > > > > > > > can cope > > > > > > > > > > >> with this in one of two possible ways: 1) "Pin" > > > the array > > > > > > > so that > > > > > > > > > > >> it cannot be moved while the interior pointer > is held > > > > > on the > > > > > > > > > > >> stack or registers of any thread (this is the > > > approach > > > > > > > that CM3's > > > > > > > > > > >> conservative collector uses for now); or 2) > track the > > > > > > > creation of > > > > > > > > > > >> such interior pointers and how they are derived > > > from base > > > > > > > object > > > > > > > > > > >> references for use during GC. 2) requires much > > > more co- > > > > > > > operation > > > > > > > > > > >> from the compiler than the current gcc-based > backend > > > > > (with > > > > > > > all of > > > > > > > > > > >> its lovely optimizations and register > allocation) is > > > > > > > capable of > > > > > > > > > > >> doing. 1) is very cheap and does not impede > > > > > optimizations and > > > > > > > > > > >> register allocation. > > > > > > > > > > > > > > > > > > > > > > Presumably, this all also applies WITH-bound > > > > > identifiers, when > > > > > > > > > they > > > > > > > > > > > are > > > > > > > > > > > designators of interior components of heap > objects? > > > Are > > > > > > > there any > > > > > > > > > > > other > > > > > > > > > > > cases? > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > ------------------------------------------------------------- > > > > > > > > > > > Rodney M. Bates, retired assistant professor > > > > > > > > > > > Dept. of Computer Science, Wichita State > University > > > > > > > > > > > Wichita, KS 67260-0083 > > > > > > > > > > > 316-978-3922 > > > > > > > > > > > rodney.bates at wichita.edu > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your smile counts. The more smiles you share, the > more we > > > > > donate. > > > > > > > > > Join in! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Get the power of Windows + Web with the new Windows Live. > > > Power > > > > > up! > > > > > > > > > > > > > > > > > > > > > You keep typing, we keep giving. Download Messenger and > join the > > > > > i?m Initiative now. Join in! > > > > > > > > > > > > > Share life as it happens with the new Windows Live. Share now! > > > > > Your smile counts. The more smiles you share, the more we donate. > Join in! From mika at async.caltech.edu Mon Dec 10 12:38:44 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 10 Dec 2007 03:38:44 -0800 Subject: [M3devel] Using REFANYs to store integers? Message-ID: <200712101138.lBABci5I022046@camembert.async.caltech.edu> Hello Modula-3ers... I have a question about garbage collecting, pointers, and dirty tricks that I'm curious if anyone (Tony??) can answer. Here it is. I am considering writing a bytecode interpreter that is to run mixed into a Modula-3 environment, that is, it will be able to deal with bytecodes as well as Modula-3 objects. There is no problem with that of course, as bytecodes are "code" and Modula-3 objects are "objects" and can live on separate stacks. However, as an optimization (not an uncommon one in these types of systems), I'd like a space and time efficient representation for "small integers". A tried-and-true method (it goes back at least to the Smalltalk-80 runtime) is to realize that pointers (in my case REFANYs) always point to word-aligned addresses. We can then use integers that are congruent to 1, 2, and 3 (mod 4) to represent other types of data. What will happen if I LOOPHOLE such integers back and forth to REFANY? Will the garbage collector just ignore them? I wrote a test program that does it and it doesn't crash... except when you hit ctrl-C, it often dies with an assertion failure in RTCollector.m3.. (This both with my ancient PM3 on FreeBSD and a relatively recent update of CM3 on PPC_DARWIN.) If the garbage collector somehow disapproves of these integers, is there any conceivable thing that would be broken by making necessary adjustments to the garbage collector such that it would just ignore them? Or is there a better way of solving my problem? Best regards, Mika From hosking at cs.purdue.edu Mon Dec 10 15:08:39 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 10 Dec 2007 09:08:39 -0500 Subject: [M3devel] Using REFANYs to store integers? In-Reply-To: <200712101138.lBABci5I022046@camembert.async.caltech.edu> References: <200712101138.lBABci5I022046@camembert.async.caltech.edu> Message-ID: <09A27D37-5334-4269-98D0-8592F10D3AF7@cs.purdue.edu> Yikes. The current collector will expect to find an aligned reference in any global variable or heap field declared as a subtype of REFANY. It will break if it does not find one. You cannot reliably use the technique you describe with Modula-3 as it is currently defined, nor for that matter with any safe language. To do what you want in Modula-3 you would need to use ADDRESS and explicitly test for low bits when using ADDRESS values. Of course, then you'd need to write your own GC for your interpreter (probably not a bad idea anyway, given that you are in much more control). On Dec 10, 2007, at 6:38 AM, Mika Nystrom wrote: > Hello Modula-3ers... > > I have a question about garbage collecting, pointers, and dirty > tricks that I'm curious if anyone (Tony??) can answer. > > Here it is. I am considering writing a bytecode interpreter that > is to run mixed into a Modula-3 environment, that is, it will be > able to deal with bytecodes as well as Modula-3 objects. There is > no problem with that of course, as bytecodes are "code" and Modula-3 > objects are "objects" and can live on separate stacks. However, > as an optimization (not an uncommon one in these types of systems), > I'd like a space and time efficient representation for "small > integers". A tried-and-true method (it goes back at least to the > Smalltalk-80 runtime) is to realize that pointers (in my case > REFANYs) always point to word-aligned addresses. We can then use > integers that are congruent to 1, 2, and 3 (mod 4) to represent > other types of data. > > What will happen if I LOOPHOLE such integers back and forth to > REFANY? Will the garbage collector just ignore them? I wrote a > test program that does it and it doesn't crash... except when you > hit ctrl-C, it often dies with an assertion failure in > RTCollector.m3.. (This both with my ancient PM3 on FreeBSD and a > relatively recent update of CM3 on PPC_DARWIN.) If the garbage > collector somehow disapproves of these integers, is there any > conceivable thing that would be broken by making necessary adjustments > to the garbage collector such that it would just ignore them? > Or is there a better way of solving my problem? > > Best regards, > Mika From mika at async.caltech.edu Mon Dec 10 21:21:13 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 10 Dec 2007 12:21:13 -0800 Subject: [M3devel] Using REFANYs to store integers? In-Reply-To: Your message of "Mon, 10 Dec 2007 13:50:57 CST." <475D98A1.5080604@wichita.edu> Message-ID: <200712102021.lBAKLD4C037596@camembert.async.caltech.edu> Hi Rodney, You're reading my mind. What I am thinking of doing is that I want to optimize the handling of small integers (only), exactly the way it's done in Smalltalk, that is, immutable, single-instance objects. And only the interpreter will ever dereference the objects, so it would check the LSBs---if they are set to zero, it will assume that it's a heap object, if anything else, it's a special immutable value of some sort. I'm well aware it's a very dirty trick to attempt! But I was thinking that by doing this sort of thing I could avoid having to code my own garbage collector. I'm not surprised that the current garbage collector has issues with it but I also cannot think of a reason why one couldn't make it ignore unaligned "pointers" unless the trick is already used for some purpose I am not aware of. Mika "Rodney M. Bates" writes: >I presume "pointers" that are not 0 MOD 4 "refer to" some kinds >of immutable, single-instance objects and don't actually point >to heap objects in need of collection, as in Smalltalk? I would >think it would be a simple modification of the existing M3 GC to >just make it ignore words containing misaligned pointers. > >Will only interpreted bytecode ever dereference these pointers? >Or does M3 compiler-generated code also dereference them? Then >the compiler would also have to generate checks and do whatever >with misaligned pointers. > >Mika Nystrom wrote: >> Hello Modula-3ers... >> >> I have a question about garbage collecting, pointers, and dirty >> tricks that I'm curious if anyone (Tony??) can answer. >> >> Here it is. I am considering writing a bytecode interpreter that >> is to run mixed into a Modula-3 environment, that is, it will be >> able to deal with bytecodes as well as Modula-3 objects. There is >> no problem with that of course, as bytecodes are "code" and Modula-3 >> objects are "objects" and can live on separate stacks. However, >> as an optimization (not an uncommon one in these types of systems), >> I'd like a space and time efficient representation for "small >> integers". A tried-and-true method (it goes back at least to the >> Smalltalk-80 runtime) is to realize that pointers (in my case >> REFANYs) always point to word-aligned addresses. We can then use >> integers that are congruent to 1, 2, and 3 (mod 4) to represent >> other types of data. >> >> What will happen if I LOOPHOLE such integers back and forth to >> REFANY? Will the garbage collector just ignore them? I wrote a >> test program that does it and it doesn't crash... except when you >> hit ctrl-C, it often dies with an assertion failure in >> RTCollector.m3.. (This both with my ancient PM3 on FreeBSD and a >> relatively recent update of CM3 on PPC_DARWIN.) If the garbage >> collector somehow disapproves of these integers, is there any >> conceivable thing that would be broken by making necessary adjustments >> to the garbage collector such that it would just ignore them? >> Or is there a better way of solving my problem? >> >> Best regards, >> Mika >> > >-- >------------------------------------------------------------- >Rodney M. Bates, retired assistant professor >Dept. of Computer Science, Wichita State University >Wichita, KS 67260-0083 >316-978-3922 >rodney.bates at wichita.edu From hosking at cs.purdue.edu Mon Dec 10 23:51:29 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 10 Dec 2007 17:51:29 -0500 Subject: [M3devel] Using REFANYs to store integers? In-Reply-To: <200712102021.lBAKLD4C037596@camembert.async.caltech.edu> References: <200712102021.lBAKLD4C037596@camembert.async.caltech.edu> Message-ID: <9520B700-D9EE-4A1B-ACD0-CB1DEA6C6A7C@cs.purdue.edu> The LSB trick is something that one could teach the current implementation to handle, but I note that there is *nothing* in the language definition that would mean this hack could ever be portable. Moreover, there is reason to expect that a particular GC implementation might use this same trick internally, in which case you have a conflict between your hack and that implementation. Basically, you should not assume *any* particular representation for REFANY in Modula-3. For example, an implementation would be free to use a level of indirection (ie, "handles" or an object table) to implement M3 REFANY. In sum, I think what you propose is a nasty hack. Better to implement your own GC anyway, since it is likely to be much better to exploit the semantics of your interpreter/language for best behavior. On Dec 10, 2007, at 3:21 PM, Mika Nystrom wrote: > Hi Rodney, > > You're reading my mind. What I am thinking of doing is that I want > to optimize the handling of small integers (only), exactly the way > it's done in Smalltalk, that is, immutable, single-instance objects. > And only the interpreter will ever dereference the objects, so it > would check the LSBs---if they are set to zero, it will assume that > it's a heap object, if anything else, it's a special immutable value > of some sort. > > I'm well aware it's a very dirty trick to attempt! But I was > thinking that by doing this sort of thing I could avoid having to > code my own garbage collector. I'm not surprised that the current > garbage collector has issues with it but I also cannot think of a > reason why one couldn't make it ignore unaligned "pointers" unless > the trick is already used for some purpose I am not aware of. > > Mika > > "Rodney M. Bates" writes: >> I presume "pointers" that are not 0 MOD 4 "refer to" some kinds >> of immutable, single-instance objects and don't actually point >> to heap objects in need of collection, as in Smalltalk? I would >> think it would be a simple modification of the existing M3 GC to >> just make it ignore words containing misaligned pointers. >> >> Will only interpreted bytecode ever dereference these pointers? >> Or does M3 compiler-generated code also dereference them? Then >> the compiler would also have to generate checks and do whatever >> with misaligned pointers. >> >> Mika Nystrom wrote: >>> Hello Modula-3ers... >>> >>> I have a question about garbage collecting, pointers, and dirty >>> tricks that I'm curious if anyone (Tony??) can answer. >>> >>> Here it is. I am considering writing a bytecode interpreter that >>> is to run mixed into a Modula-3 environment, that is, it will be >>> able to deal with bytecodes as well as Modula-3 objects. There is >>> no problem with that of course, as bytecodes are "code" and Modula-3 >>> objects are "objects" and can live on separate stacks. However, >>> as an optimization (not an uncommon one in these types of systems), >>> I'd like a space and time efficient representation for "small >>> integers". A tried-and-true method (it goes back at least to the >>> Smalltalk-80 runtime) is to realize that pointers (in my case >>> REFANYs) always point to word-aligned addresses. We can then use >>> integers that are congruent to 1, 2, and 3 (mod 4) to represent >>> other types of data. >>> >>> What will happen if I LOOPHOLE such integers back and forth to >>> REFANY? Will the garbage collector just ignore them? I wrote a >>> test program that does it and it doesn't crash... except when you >>> hit ctrl-C, it often dies with an assertion failure in >>> RTCollector.m3.. (This both with my ancient PM3 on FreeBSD and a >>> relatively recent update of CM3 on PPC_DARWIN.) If the garbage >>> collector somehow disapproves of these integers, is there any >>> conceivable thing that would be broken by making necessary >>> adjustments >>> to the garbage collector such that it would just ignore them? >>> Or is there a better way of solving my problem? >>> >>> Best regards, >>> Mika >>> >> >> -- >> ------------------------------------------------------------- >> Rodney M. Bates, retired assistant professor >> Dept. of Computer Science, Wichita State University >> Wichita, KS 67260-0083 >> 316-978-3922 >> rodney.bates at wichita.edu From mika at async.caltech.edu Tue Dec 11 00:33:44 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 10 Dec 2007 15:33:44 -0800 Subject: [M3devel] Using REFANYs to store integers? In-Reply-To: Your message of "Mon, 10 Dec 2007 17:51:29 EST." <9520B700-D9EE-4A1B-ACD0-CB1DEA6C6A7C@cs.purdue.edu> Message-ID: <200712102333.lBANXiAe044857@camembert.async.caltech.edu> Well, come to think of it... I'm not sure I can even do my own GC. The idea is that the interpreter I am working on would have more or less unrestricted access to the M3 environment, anyhow, and that many of the objects on its stacks will be plain old M3 objects, which will be handled as opaque handles by the interpreter. In other words, I'd have to have and worry about two garbage collectors (M3 + interpreter) if I follow your suggestion. I was really hoping to avoid that. I was also hoping to use your excellent garbage collector rather than having to worry about that too, in addition to all the other issues that come up in coding bytecode compilers, interpreters, with all the other runtime support etc etc. Since I clearly have to support versions of M3 that don't appreciate the LSB hack I am just going to have to be able to represent small integers as something along the lines of TYPE SmallInteger = OBJECT v : INTEGER END anyhow. This is not a problem, it's just going to be slow, since I anticipate that most of the work done by the interpreter will be manipulating small integers (array indices, etc.) Tony, don't worry, I'm not going to give you (much of) a hard time if you come up with a beautiful garbage collector that's incompatible with my "nasty hack"! In any case, I am just thinking aloud (awrite?) and you gentlemen have fully satisfied my curiosity with your answers to my questions. Thanks! Mika Tony Hosking writes: >The LSB trick is something that one could teach the current >implementation to handle, but I note that there is *nothing* in the >language definition that would mean this hack could ever be >portable. Moreover, there is reason to expect that a particular GC >implementation might use this same trick internally, in which case >you have a conflict between your hack and that implementation. >Basically, you should not assume *any* particular representation for >REFANY in Modula-3. For example, an implementation would be free to >use a level of indirection (ie, "handles" or an object table) to >implement M3 REFANY. In sum, I think what you propose is a nasty >hack. Better to implement your own GC anyway, since it is likely to >be much better to exploit the semantics of your interpreter/language >for best behavior. > >On Dec 10, 2007, at 3:21 PM, Mika Nystrom wrote: > >> Hi Rodney, >> >> You're reading my mind. What I am thinking of doing is that I want >> to optimize the handling of small integers (only), exactly the way >> it's done in Smalltalk, that is, immutable, single-instance objects. >> And only the interpreter will ever dereference the objects, so it >> would check the LSBs---if they are set to zero, it will assume that >> it's a heap object, if anything else, it's a special immutable value >> of some sort. >> >> I'm well aware it's a very dirty trick to attempt! But I was >> thinking that by doing this sort of thing I could avoid having to >> code my own garbage collector. I'm not surprised that the current >> garbage collector has issues with it but I also cannot think of a >> reason why one couldn't make it ignore unaligned "pointers" unless >> the trick is already used for some purpose I am not aware of. >> >> Mika >> >> "Rodney M. Bates" writes: >>> I presume "pointers" that are not 0 MOD 4 "refer to" some kinds >>> of immutable, single-instance objects and don't actually point >>> to heap objects in need of collection, as in Smalltalk? I would >>> think it would be a simple modification of the existing M3 GC to >>> just make it ignore words containing misaligned pointers. >>> >>> Will only interpreted bytecode ever dereference these pointers? >>> Or does M3 compiler-generated code also dereference them? Then >>> the compiler would also have to generate checks and do whatever >>> with misaligned pointers. >>> >>> Mika Nystrom wrote: >>>> Hello Modula-3ers... >>>> >>>> I have a question about garbage collecting, pointers, and dirty >>>> tricks that I'm curious if anyone (Tony??) can answer. >>>> >>>> Here it is. I am considering writing a bytecode interpreter that >>>> is to run mixed into a Modula-3 environment, that is, it will be >>>> able to deal with bytecodes as well as Modula-3 objects. There is >>>> no problem with that of course, as bytecodes are "code" and Modula-3 >>>> objects are "objects" and can live on separate stacks. However, >>>> as an optimization (not an uncommon one in these types of systems), >>>> I'd like a space and time efficient representation for "small >>>> integers". A tried-and-true method (it goes back at least to the >>>> Smalltalk-80 runtime) is to realize that pointers (in my case >>>> REFANYs) always point to word-aligned addresses. We can then use >>>> integers that are congruent to 1, 2, and 3 (mod 4) to represent >>>> other types of data. >>>> >>>> What will happen if I LOOPHOLE such integers back and forth to >>>> REFANY? Will the garbage collector just ignore them? I wrote a >>>> test program that does it and it doesn't crash... except when you >>>> hit ctrl-C, it often dies with an assertion failure in >>>> RTCollector.m3.. (This both with my ancient PM3 on FreeBSD and a >>>> relatively recent update of CM3 on PPC_DARWIN.) If the garbage >>>> collector somehow disapproves of these integers, is there any >>>> conceivable thing that would be broken by making necessary >>>> adjustments >>>> to the garbage collector such that it would just ignore them? >>>> Or is there a better way of solving my problem? >>>> >>>> Best regards, >>>> Mika >>>> >>> >>> -- >>> ------------------------------------------------------------- >>> Rodney M. Bates, retired assistant professor >>> Dept. of Computer Science, Wichita State University >>> Wichita, KS 67260-0083 >>> 316-978-3922 >>> rodney.bates at wichita.edu From hosking at cs.purdue.edu Tue Dec 11 04:24:45 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 10 Dec 2007 22:24:45 -0500 Subject: [M3devel] Using REFANYs to store integers? In-Reply-To: <200712102333.lBANXiAe044857@camembert.async.caltech.edu> References: <200712102333.lBANXiAe044857@camembert.async.caltech.edu> Message-ID: I didn't mean to disparage your suggestion -- just pointing out some of the pitfalls. Certainly, the current collectors will have problems if you store tagged values in REFANY fields, since it expects to find aligned references there. I can see a couple of options that might work, some of which might use the WeakRef interface to control reachability. I imagine we could come up with some sort of API that would support this. It might even be an interesting result... On Dec 10, 2007, at 6:33 PM, Mika Nystrom wrote: > > Well, come to think of it... I'm not sure I can even do my own GC. > The idea is that the interpreter I am working on would have more > or less unrestricted access to the M3 environment, anyhow, and that > many of the objects on its stacks will be plain old M3 objects, > which will be handled as opaque handles by the interpreter. In > other words, I'd have to have and worry about two garbage collectors > (M3 + interpreter) if I follow your suggestion. I was really hoping > to avoid that. I was also hoping to use your excellent garbage > collector rather than having to worry about that too, in addition > to all the other issues that come up in coding bytecode compilers, > interpreters, with all the other runtime support etc etc. > > Since I clearly have to support versions of M3 that don't appreciate > the LSB hack I am just going to have to be able to represent small > integers as something along the lines of > > TYPE SmallInteger = OBJECT v : INTEGER END > > anyhow. This is not a problem, it's just going to be slow, since > I anticipate that most of the work done by the interpreter will be > manipulating small integers (array indices, etc.) Tony, don't > worry, I'm not going to give you (much of) a hard time if you come > up with a beautiful garbage collector that's incompatible with my > "nasty hack"! > > In any case, I am just thinking aloud (awrite?) and you gentlemen > have fully satisfied my curiosity with your answers to my questions. > Thanks! > > Mika > > Tony Hosking writes: >> The LSB trick is something that one could teach the current >> implementation to handle, but I note that there is *nothing* in the >> language definition that would mean this hack could ever be >> portable. Moreover, there is reason to expect that a particular GC >> implementation might use this same trick internally, in which case >> you have a conflict between your hack and that implementation. >> Basically, you should not assume *any* particular representation for >> REFANY in Modula-3. For example, an implementation would be free to >> use a level of indirection (ie, "handles" or an object table) to >> implement M3 REFANY. In sum, I think what you propose is a nasty >> hack. Better to implement your own GC anyway, since it is likely to >> be much better to exploit the semantics of your interpreter/language >> for best behavior. >> >> On Dec 10, 2007, at 3:21 PM, Mika Nystrom wrote: >> >>> Hi Rodney, >>> >>> You're reading my mind. What I am thinking of doing is that I want >>> to optimize the handling of small integers (only), exactly the way >>> it's done in Smalltalk, that is, immutable, single-instance objects. >>> And only the interpreter will ever dereference the objects, so it >>> would check the LSBs---if they are set to zero, it will assume that >>> it's a heap object, if anything else, it's a special immutable value >>> of some sort. >>> >>> I'm well aware it's a very dirty trick to attempt! But I was >>> thinking that by doing this sort of thing I could avoid having to >>> code my own garbage collector. I'm not surprised that the current >>> garbage collector has issues with it but I also cannot think of a >>> reason why one couldn't make it ignore unaligned "pointers" unless >>> the trick is already used for some purpose I am not aware of. >>> >>> Mika >>> >>> "Rodney M. Bates" writes: >>>> I presume "pointers" that are not 0 MOD 4 "refer to" some kinds >>>> of immutable, single-instance objects and don't actually point >>>> to heap objects in need of collection, as in Smalltalk? I would >>>> think it would be a simple modification of the existing M3 GC to >>>> just make it ignore words containing misaligned pointers. >>>> >>>> Will only interpreted bytecode ever dereference these pointers? >>>> Or does M3 compiler-generated code also dereference them? Then >>>> the compiler would also have to generate checks and do whatever >>>> with misaligned pointers. >>>> >>>> Mika Nystrom wrote: >>>>> Hello Modula-3ers... >>>>> >>>>> I have a question about garbage collecting, pointers, and dirty >>>>> tricks that I'm curious if anyone (Tony??) can answer. >>>>> >>>>> Here it is. I am considering writing a bytecode interpreter that >>>>> is to run mixed into a Modula-3 environment, that is, it will be >>>>> able to deal with bytecodes as well as Modula-3 objects. There is >>>>> no problem with that of course, as bytecodes are "code" and >>>>> Modula-3 >>>>> objects are "objects" and can live on separate stacks. However, >>>>> as an optimization (not an uncommon one in these types of >>>>> systems), >>>>> I'd like a space and time efficient representation for "small >>>>> integers". A tried-and-true method (it goes back at least to the >>>>> Smalltalk-80 runtime) is to realize that pointers (in my case >>>>> REFANYs) always point to word-aligned addresses. We can then use >>>>> integers that are congruent to 1, 2, and 3 (mod 4) to represent >>>>> other types of data. >>>>> >>>>> What will happen if I LOOPHOLE such integers back and forth to >>>>> REFANY? Will the garbage collector just ignore them? I wrote a >>>>> test program that does it and it doesn't crash... except when you >>>>> hit ctrl-C, it often dies with an assertion failure in >>>>> RTCollector.m3.. (This both with my ancient PM3 on FreeBSD and a >>>>> relatively recent update of CM3 on PPC_DARWIN.) If the garbage >>>>> collector somehow disapproves of these integers, is there any >>>>> conceivable thing that would be broken by making necessary >>>>> adjustments >>>>> to the garbage collector such that it would just ignore them? >>>>> Or is there a better way of solving my problem? >>>>> >>>>> Best regards, >>>>> Mika >>>>> >>>> >>>> -- >>>> ------------------------------------------------------------- >>>> Rodney M. Bates, retired assistant professor >>>> Dept. of Computer Science, Wichita State University >>>> Wichita, KS 67260-0083 >>>> 316-978-3922 >>>> rodney.bates at wichita.edu From mika at async.caltech.edu Wed Dec 12 10:47:52 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 12 Dec 2007 01:47:52 -0800 Subject: [M3devel] Using REFANYs to store integers? In-Reply-To: Your message of "Mon, 10 Dec 2007 22:24:45 EST." Message-ID: <200712120947.lBC9lq5d019613@camembert.async.caltech.edu> Tony Hosking writes: >I didn't mean to disparage your suggestion -- just pointing out some >of the pitfalls. Certainly, the current collectors will have >problems if you store tagged values in REFANY fields, since it >expects to find aligned references there. I can see a couple of >options that might work, some of which might use the WeakRef >interface to control reachability. I imagine we could come up with >some sort of API that would support this. It might even be an >interesting result... > Oh I know that. It's clear that even if one does use the hack I have described, it would be criminal to release code that couldn't survive without it. As you point out there are many conceivable M3 implementations that might not support such a nasty hack. I think your idea of an API could be an interesting exercise---you could "squirrel away" data in REFANYs that don't actually refer to anything but are themselves values (ANYs?). Of course there's not much point (is there?) unless the squirreling and un-squirreling is more efficient than an extra memory allocation and dereference. I take it that the API could also tell the hacker when the hack is unavailable, for any of the reasons you have mentioned... Mika >On Dec 10, 2007, at 6:33 PM, Mika Nystrom wrote: > >> >> Well, come to think of it... I'm not sure I can even do my own GC. >> The idea is that the interpreter I am working on would have more >> or less unrestricted access to the M3 environment, anyhow, and that >> many of the objects on its stacks will be plain old M3 objects, >> which will be handled as opaque handles by the interpreter. In >> other words, I'd have to have and worry about two garbage collectors >> (M3 + interpreter) if I follow your suggestion. I was really hoping >> to avoid that. I was also hoping to use your excellent garbage >> collector rather than having to worry about that too, in addition >> to all the other issues that come up in coding bytecode compilers, >> interpreters, with all the other runtime support etc etc. >> >> Since I clearly have to support versions of M3 that don't appreciate >> the LSB hack I am just going to have to be able to represent small >> integers as something along the lines of >> >> TYPE SmallInteger = OBJECT v : INTEGER END >> >> anyhow. This is not a problem, it's just going to be slow, since >> I anticipate that most of the work done by the interpreter will be >> manipulating small integers (array indices, etc.) Tony, don't >> worry, I'm not going to give you (much of) a hard time if you come >> up with a beautiful garbage collector that's incompatible with my >> "nasty hack"! >> >> In any case, I am just thinking aloud (awrite?) and you gentlemen >> have fully satisfied my curiosity with your answers to my questions. >> Thanks! >> >> Mika >> >> Tony Hosking writes: >>> The LSB trick is something that one could teach the current >>> implementation to handle, but I note that there is *nothing* in the >>> language definition that would mean this hack could ever be >>> portable. Moreover, there is reason to expect that a particular GC >>> implementation might use this same trick internally, in which case >>> you have a conflict between your hack and that implementation. >>> Basically, you should not assume *any* particular representation for >>> REFANY in Modula-3. For example, an implementation would be free to >>> use a level of indirection (ie, "handles" or an object table) to >>> implement M3 REFANY. In sum, I think what you propose is a nasty >>> hack. Better to implement your own GC anyway, since it is likely to >>> be much better to exploit the semantics of your interpreter/language >>> for best behavior. >>> >>> On Dec 10, 2007, at 3:21 PM, Mika Nystrom wrote: >>> >>>> Hi Rodney, >>>> >>>> You're reading my mind. What I am thinking of doing is that I want >>>> to optimize the handling of small integers (only), exactly the way >>>> it's done in Smalltalk, that is, immutable, single-instance objects. >>>> And only the interpreter will ever dereference the objects, so it >>>> would check the LSBs---if they are set to zero, it will assume that >>>> it's a heap object, if anything else, it's a special immutable value >>>> of some sort. >>>> >>>> I'm well aware it's a very dirty trick to attempt! But I was >>>> thinking that by doing this sort of thing I could avoid having to >>>> code my own garbage collector. I'm not surprised that the current >>>> garbage collector has issues with it but I also cannot think of a >>>> reason why one couldn't make it ignore unaligned "pointers" unless >>>> the trick is already used for some purpose I am not aware of. >>>> >>>> Mika >>>> >>>> "Rodney M. Bates" writes: >>>>> I presume "pointers" that are not 0 MOD 4 "refer to" some kinds >>>>> of immutable, single-instance objects and don't actually point >>>>> to heap objects in need of collection, as in Smalltalk? I would >>>>> think it would be a simple modification of the existing M3 GC to >>>>> just make it ignore words containing misaligned pointers. >>>>> >>>>> Will only interpreted bytecode ever dereference these pointers? >>>>> Or does M3 compiler-generated code also dereference them? Then >>>>> the compiler would also have to generate checks and do whatever >>>>> with misaligned pointers. >>>>> >>>>> Mika Nystrom wrote: >>>>>> Hello Modula-3ers... >>>>>> >>>>>> I have a question about garbage collecting, pointers, and dirty >>>>>> tricks that I'm curious if anyone (Tony??) can answer. >>>>>> >>>>>> Here it is. I am considering writing a bytecode interpreter that >>>>>> is to run mixed into a Modula-3 environment, that is, it will be >>>>>> able to deal with bytecodes as well as Modula-3 objects. There is >>>>>> no problem with that of course, as bytecodes are "code" and >>>>>> Modula-3 >>>>>> objects are "objects" and can live on separate stacks. However, >>>>>> as an optimization (not an uncommon one in these types of >>>>>> systems), >>>>>> I'd like a space and time efficient representation for "small >>>>>> integers". A tried-and-true method (it goes back at least to the >>>>>> Smalltalk-80 runtime) is to realize that pointers (in my case >>>>>> REFANYs) always point to word-aligned addresses. We can then use >>>>>> integers that are congruent to 1, 2, and 3 (mod 4) to represent >>>>>> other types of data. >>>>>> >>>>>> What will happen if I LOOPHOLE such integers back and forth to >>>>>> REFANY? Will the garbage collector just ignore them? I wrote a >>>>>> test program that does it and it doesn't crash... except when you >>>>>> hit ctrl-C, it often dies with an assertion failure in >>>>>> RTCollector.m3.. (This both with my ancient PM3 on FreeBSD and a >>>>>> relatively recent update of CM3 on PPC_DARWIN.) If the garbage >>>>>> collector somehow disapproves of these integers, is there any >>>>>> conceivable thing that would be broken by making necessary >>>>>> adjustments >>>>>> to the garbage collector such that it would just ignore them? >>>>>> Or is there a better way of solving my problem? >>>>>> >>>>>> Best regards, >>>>>> Mika >>>>>> >>>>> >>>>> -- >>>>> ------------------------------------------------------------- >>>>> Rodney M. Bates, retired assistant professor >>>>> Dept. of Computer Science, Wichita State University >>>>> Wichita, KS 67260-0083 >>>>> 316-978-3922 >>>>> rodney.bates at wichita.edu From wagner at elegosoft.com Sat Dec 15 23:50:51 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 15 Dec 2007 23:50:51 +0100 Subject: [M3devel] Spanish speaking CM3 users? Message-ID: <20071215235051.rhq0fgeabk4k48gk@mail.elegosoft.com> Hi, I found this in our company's contact box. Is there somebody here with better Spanish knowledge than me who'd like to help? Olaf ----- Forwarded message from anietog at unal.edu.co ----- Date: Sat, 15 Dec 2007 17:55:45 +0100 (CET) From: Angela Reply-To: Angela Subject: Anfrage Mailformular To: info at elego.de NAME: Angela EMAIL: anietog at unal.edu.co ADDRESS: Hola, escribo porque tengo un problema al tratar de compilar el compilador de fase 1, esto es lo que me aparece: .... new source -> compiling Text.i3 new source -> compiling RTProcedureSRC.i3 new source -> compiling Fingerprint.i3 new source -> compiling RTProcedure.i3 new source -> compiling RTStack.i3 new source -> compiling RTAllocStats.m3 "../src/runtime/common/RTAllocStats.m3", line 46: undefined runtime symbol !! (RTHooks.AllocateTracedRef) *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x80c5c3c = StartCall + 0x18 in ../src/values/Procedure.m3 *** Aborted (core dumped) *** execution of failed *** Agradezco cualquier colaboraci?n ya que aun no he podido culminar mi instalacion de cm3. ----- End forwarded message ----- -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- NAME: Angela EMAIL: anietog at unal.edu.co ADDRESS: Hola, escribo porque tengo un problema al tratar de compilar el compilador de fase 1, esto es lo que me aparece: .... new source -> compiling Text.i3 new source -> compiling RTProcedureSRC.i3 new source -> compiling Fingerprint.i3 new source -> compiling RTProcedure.i3 new source -> compiling RTStack.i3 new source -> compiling RTAllocStats.m3 "../src/runtime/common/RTAllocStats.m3", line 46: undefined runtime symbol !! (RTHooks.AllocateTracedRef) *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL *** pc = 0x80c5c3c = StartCall + 0x18 in ../src/values/Procedure.m3 *** Aborted (core dumped) *** execution of failed *** Agradezco cualquier colaboraci?n ya que aun no he podido culminar mi instalacion de cm3. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ndantam at purdue.edu Sun Dec 16 00:42:11 2007 From: ndantam at purdue.edu (Neil T. Dantam) Date: Sat, 15 Dec 2007 18:42:11 -0500 Subject: [M3devel] Spanish speaking CM3 users? In-Reply-To: <20071215235051.rhq0fgeabk4k48gk@mail.elegosoft.com> References: <20071215235051.rhq0fgeabk4k48gk@mail.elegosoft.com> Message-ID: <47646653.4070106@purdue.edu> Olaf, I can at least translate the Spanish for you. Angela, ?Tratar los instrucciones de este mensaje? (Did you try the instructions in this email?) https://mail.elegosoft.com/pipermail/m3devel/2007-June/000227.html Describen como compilar el compilador. (They describe how to bootstrap the compiler.) Olaf Wagner wrote: > ----- Forwarded message from anietog at unal.edu.co ----- > Date: Sat, 15 Dec 2007 17:55:45 +0100 (CET) > From: Angela > Reply-To: Angela > Subject: Anfrage Mailformular > To: info at elego.de > > NAME: Angela > EMAIL: anietog at unal.edu.co > ADDRESS: > Hola, escribo porque tengo un problema al tratar de compilar el > compilador de fase 1, esto es lo que me aparece: Hello, I'm writing because I have a problem regarding compiling phase one of the compiler. This is what I see: > .... > new source -> compiling Text.i3 > new source -> compiling RTProcedureSRC.i3 > new source -> compiling Fingerprint.i3 > new source -> compiling RTProcedure.i3 > new source -> compiling RTStack.i3 > new source -> compiling RTAllocStats.m3 > "../src/runtime/common/RTAllocStats.m3", line 46: undefined runtime > symbol !! (RTHooks.AllocateTracedRef) > > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0x80c5c3c = StartCall + 0x18 in ../src/values/Procedure.m3 > *** > > Aborted (core dumped) > *** execution of failed *** > > > Agradezco cualquier colaboraci?n ya que aun no he podido culminar mi > instalacion de cm3. I would appreciate any help, because I could not finish my installation of cm3. > > ----- End forwarded message ----- -- Neil T. Dantam From mika at async.caltech.edu Sun Dec 16 01:18:29 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 15 Dec 2007 16:18:29 -0800 Subject: [M3devel] Ubuntu problems Message-ID: <200712160018.lBG0ITO5026048@camembert.async.caltech.edu> Hello Modula-3 people, I am trying to build things with CM3 on a relatively recent Ubuntu system (don't ask me why...) and I am running into a segfault that I haven't seen mentioned before. I have a feeling it has something to do with stack formats, but I'm not sure what to do next. I downloaded the cm3-5.4.0 binaries and started with that. The compiler in the binary distribution runs, but it appears to produce garbage. I first tried bootstrapping but it crashes the moment it tries to execute something it has compiled itself. So then I tried hello, world, with the same results... Here's the system identification: mika at edwards:~/test/src$ uname -a Linux edwards 2.6.20-16-386 #2 Sun Sep 23 19:47:10 UTC 2007 i686 GNU/Linux I made a "hello, world" program as follows: MODULE Main; IMPORT IO; BEGIN IO.Put("Hello, world!\n") END Main. Compiled with cm3 directly from the distributed cm3-5.4.0 for LINUXLIBC6 and I get a crash in CsetjmpASM.s (as far as I can tell). The last unclobbered stack I seem to be able to get in m3gdb is this: Breakpoint 5, 0xb75e5fb4 in _setjmp () at ../src/C/LINUXLIBC6/CsetjmpASM.s:31 31 in ../src/C/LINUXLIBC6/CsetjmpASM.s (m3gdb) where #0 0xb75e5fb4 in _setjmp () at ../src/C/LINUXLIBC6/CsetjmpASM.s:31 #1 0xb75dbd51 in RTThread__Transfer (from=0xbfe28530, to=0xbfe28530) at ../src/runtime/LINUXLIBC6/RTThreadC.c:14 #2 0xb75dbaed in FlushStackCache () at RTThread.m3:65 #3 0xb75e27c9 in DetermineContext (oldSP=Invalid C/C++ type code 35 in symbol table. ) at ThreadPosix.m3:1101 #4 0xb75e270d in InitTopContext (c=Invalid C/C++ type code 30 in symbol table. ) at ThreadPosix.m3:1076 #5 0xb75e4325 in Init () at ThreadPosix.m3:1498 #6 0xb75c9592 in InitRuntime (p_argc=Invalid C/C++ type code 39 in symbol table. ) at RTLinker.m3:59 #7 0x08048861 in main (argc=1, argv=0xbfe28824, envp=0xbfe2882c) at _m3main.mc:3 (m3gdb) cont Continuing. Program received signal SIGSEGV, Segmentation fault. 0xa8dbaede in ?? () s.sp was lately 16_b75af6b9, if that means anything at all. Oh yes, one more thing: setting LD_POINTER_GUARD to 0 before running the program has no effect on the crash. Any suggestions for how one might make progress on this? Mika From mika at async.caltech.edu Sun Dec 16 02:35:54 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 15 Dec 2007 17:35:54 -0800 Subject: [M3devel] Ubuntu problems In-Reply-To: Your message of "Sat, 15 Dec 2007 16:18:29 PST." <200712160018.lBG0ITO5026048@camembert.async.caltech.edu> Message-ID: <200712160135.lBG1ZsZ2028488@camembert.async.caltech.edu> Sorry, I have now read the mailing list archives a bit better. I am going to try bootstrapping the latest CVS with Tony's cm3 binary, to use pthreads... Mika Mika Nystrom writes: >Hello Modula-3 people, > >I am trying to build things with CM3 on a relatively recent Ubuntu >system (don't ask me why...) and I am running into a segfault that >I haven't seen mentioned before. I have a feeling it has something >to do with stack formats, but I'm not sure what to do next. > >I downloaded the cm3-5.4.0 binaries and started with that. The >compiler in the binary distribution runs, but it appears to produce >garbage. I first tried bootstrapping but it crashes the moment it >tries to execute something it has compiled itself. So then I tried >hello, world, with the same results... > >Here's the system identification: > >mika at edwards:~/test/src$ uname -a >Linux edwards 2.6.20-16-386 #2 Sun Sep 23 19:47:10 UTC 2007 i686 GNU/Linux > >I made a "hello, world" program as follows: > >MODULE Main; >IMPORT IO; > >BEGIN IO.Put("Hello, world!\n") END Main. > >Compiled with cm3 directly from the distributed cm3-5.4.0 for >LINUXLIBC6 and I get a crash in CsetjmpASM.s (as far as I can tell). >The last unclobbered stack I seem to be able to get in m3gdb is >this: > >Breakpoint 5, 0xb75e5fb4 in _setjmp () at ../src/C/LINUXLIBC6/CsetjmpASM.s:31 >31 in ../src/C/LINUXLIBC6/CsetjmpASM.s >(m3gdb) where >#0 0xb75e5fb4 in _setjmp () at ../src/C/LINUXLIBC6/CsetjmpASM.s:31 >#1 0xb75dbd51 in RTThread__Transfer (from=0xbfe28530, to=0xbfe28530) at ../sr >c/runtime/LINUXLIBC6/RTThreadC.c:14 >#2 0xb75dbaed in FlushStackCache () at RTThread.m3:65 >#3 0xb75e27c9 in DetermineContext (oldSP=Invalid C/C++ type code 35 in symbol > table. >) at ThreadPosix.m3:1101 >#4 0xb75e270d in InitTopContext (c=Invalid C/C++ type code 30 in symbol table >. >) at ThreadPosix.m3:1076 >#5 0xb75e4325 in Init () at ThreadPosix.m3:1498 >#6 0xb75c9592 in InitRuntime (p_argc=Invalid C/C++ type code 39 in symbol tab >le. >) at RTLinker.m3:59 >#7 0x08048861 in main (argc=1, argv=0xbfe28824, envp=0xbfe2882c) at _m3main.m >c:3 >(m3gdb) cont >Continuing. > >Program received signal SIGSEGV, Segmentation fault. >0xa8dbaede in ?? () > >s.sp was lately 16_b75af6b9, if that means anything at all. > >Oh yes, one more thing: setting LD_POINTER_GUARD to 0 before running >the program has no effect on the crash. > >Any suggestions for how one might make progress on this? > > Mika From dabenavidesd at yahoo.es Sun Dec 16 02:38:03 2007 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sun, 16 Dec 2007 02:38:03 +0100 (CET) Subject: [M3devel] Ubuntu problems In-Reply-To: <200712160018.lBG0ITO5026048@camembert.async.caltech.edu> Message-ID: <147313.32986.qm@web27106.mail.ukl.yahoo.com> Hi Mika, what are you seeing is the problem of libc setjmp/longjmp issue that we maybe have to advise more to cm3 users, and in general *m3 (dec-src,pm3,ezm3,and cm3 too) users that () user level thread implementation which is part of m3core is not working at this moment, so until community can make a functioning a new implementation, we will use only PTHREAD implementation on most new Linux distributions. Of course this solves the problems you are noticing, so my advise in order to this do not happen any more is write a note on the Download Area and maybe also in (like a note in the Known issues), www.modula3.org (If you allow me, I can do it) The most common case I know a (not very recent) of distribution that works with user level implementation that I use is Ubuntu Dapper 6.06, the libray is 2.3.6 http://packages.ubuntu.com/dapper/libdevel/libc6-dev The next version of Ubuntu breaks when the Juno package is compiling (pkl-fonts program executes), the library libc6 is http://packages.ubuntu.com/edgy/libdevel/libc6-dev. So for 5.4 sources use use the next CM3 variable export CM3="/usr/local/cm3/bin/cm3 -DPTHREAD" This enable the system level thread implementation in a earlier version of it (of cvs), but in the first step bootstrap compiler you will ran in same problems (in Edgy I got breack when running pkl-fonts, but after that break you can re-compile it all well with no problems, after you have build the new m3core). If you can update the sources with the most recent (in a personal opinion, stable version) would be better, but here I would like to know if the script upgrade.sh can do that work, i have not use it. For me the most easy way for me was use the instruction given by Tony for the cvs version, from I take his words and make a relatively simple instructions. Thanks --- Mika Nystrom wrote: > Hello Modula-3 people, > > I am trying to build things with CM3 on a relatively > recent Ubuntu > system (don't ask me why...) and I am running into a > segfault that > I haven't seen mentioned before. I have a feeling > it has something > to do with stack formats, but I'm not sure what to > do next. > > I downloaded the cm3-5.4.0 binaries and started with > that. The > compiler in the binary distribution runs, but it > appears to produce > garbage. I first tried bootstrapping but it crashes > the moment it > tries to execute something it has compiled itself. > So then I tried > hello, world, with the same results... > > Here's the system identification: > > mika at edwards:~/test/src$ uname -a > Linux edwards 2.6.20-16-386 #2 Sun Sep 23 19:47:10 > UTC 2007 i686 GNU/Linux > > I made a "hello, world" program as follows: > > MODULE Main; > IMPORT IO; > > BEGIN IO.Put("Hello, world!\n") END Main. > > Compiled with cm3 directly from the distributed > cm3-5.4.0 for > LINUXLIBC6 and I get a crash in CsetjmpASM.s (as far > as I can tell). > The last unclobbered stack I seem to be able to get > in m3gdb is > this: > > Breakpoint 5, 0xb75e5fb4 in _setjmp () at > ../src/C/LINUXLIBC6/CsetjmpASM.s:31 > 31 in ../src/C/LINUXLIBC6/CsetjmpASM.s > (m3gdb) where > #0 0xb75e5fb4 in _setjmp () at > ../src/C/LINUXLIBC6/CsetjmpASM.s:31 > #1 0xb75dbd51 in RTThread__Transfer > (from=0xbfe28530, to=0xbfe28530) at > ../src/runtime/LINUXLIBC6/RTThreadC.c:14 > #2 0xb75dbaed in FlushStackCache () at > RTThread.m3:65 > #3 0xb75e27c9 in DetermineContext (oldSP=Invalid > C/C++ type code 35 in symbol table. > ) at ThreadPosix.m3:1101 > #4 0xb75e270d in InitTopContext (c=Invalid C/C++ > type code 30 in symbol table. > ) at ThreadPosix.m3:1076 > #5 0xb75e4325 in Init () at ThreadPosix.m3:1498 > #6 0xb75c9592 in InitRuntime (p_argc=Invalid C/C++ > type code 39 in symbol table. > ) at RTLinker.m3:59 > #7 0x08048861 in main (argc=1, argv=0xbfe28824, > envp=0xbfe2882c) at _m3main.mc:3 > (m3gdb) cont > Continuing. > > Program received signal SIGSEGV, Segmentation fault. > 0xa8dbaede in ?? () > > s.sp was lately 16_b75af6b9, if that means anything > at all. > > Oh yes, one more thing: setting LD_POINTER_GUARD to > 0 before running > the program has no effect on the crash. > > Any suggestions for how one might make progress on > this? > > Mika > ______________________________________________ ?Chef por primera vez? S? un mejor Cocinillas. http://es.answers.yahoo.com/info/welcome From jay.krell at cornell.edu Sun Dec 16 03:14:29 2007 From: jay.krell at cornell.edu (Jay) Date: Sun, 16 Dec 2007 02:14:29 +0000 Subject: [M3devel] Ubuntu problems In-Reply-To: <147313.32986.qm@web27106.mail.ukl.yahoo.com> References: <200712160018.lBG0ITO5026048@camembert.async.caltech.edu> <147313.32986.qm@web27106.mail.ukl.yahoo.com> Message-ID: Maybe time to grab a BSD setjmp/longjmp or getcontext/setcontext, rename by prepending with m3_, and be done with it?? e.g.http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/arch/i386/sys/getcontext.S?rev=1.2&content-type=text/x-cvsweb-markuphttp://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/arch/powerpc/sys/getcontext.S?rev=1.3&content-type=text/x-cvsweb-markup My goodness, none of FreeBSD, OpenBSD, NetBSD have web searchable CVS archives.. better links later.. Regarding upgrade.sh, well, on Windows upgrade.cmd works. :) They are all "just" wrappers around cd'ing and building, but perhaps not trivial. - Jay > Date: Sun, 16 Dec 2007 02:38:03 +0100> From: dabenavidesd at yahoo.es> To: mika at async.caltech.edu; m3devel at elegosoft.com> CC: mika at camembert.async.caltech.edu> Subject: Re: [M3devel] Ubuntu problems> > Hi Mika,> what are you seeing is the problem of libc> setjmp/longjmp issue that we maybe have to advise more> to cm3 users, and in general *m3 (dec-src,pm3,ezm3,and> cm3 too) users that () user level thread> implementation which is part of m3core is not working> at this moment, so until community can make a> functioning a new implementation, we will use only> PTHREAD implementation on most new Linux> distributions.> Of course this solves the problems you are noticing,> so my advise in order to this do not happen any more> is write a note on the Download Area and maybe also in> (like a note in the Known issues), www.modula3.org> (If you allow me, I can do it)> > The most common case I know a (not very recent) of > distribution that works with user level implementation> that I use is Ubuntu Dapper 6.06, the libray is 2.3.6> http://packages.ubuntu.com/dapper/libdevel/libc6-dev> The next version of Ubuntu breaks when the Juno> package is compiling (pkl-fonts program executes), the> library libc6 is> http://packages.ubuntu.com/edgy/libdevel/libc6-dev.> > So for 5.4 sources use use the next CM3 variable> export CM3="/usr/local/cm3/bin/cm3 -DPTHREAD"> > This enable the system level thread implementation in> a earlier version of it (of cvs), but in the first> step bootstrap compiler you will ran in same problems> (in Edgy I got breack when running pkl-fonts, but> after that break you can re-compile it all well with> no problems, after you have build the new m3core).> If you can update the sources with the most recent (in> a personal opinion, stable version) would be better,> but here I would like to know if the script upgrade.sh> can do that work, i have not use it.> For me the most easy way for me was use the> instruction given by Tony for the cvs version, from I> take his words and make a relatively simple> instructions.> > Thanks> > > > > > > --- Mika Nystrom wrote:> > > Hello Modula-3 people,> > > > I am trying to build things with CM3 on a relatively> > recent Ubuntu> > system (don't ask me why...) and I am running into a> > segfault that> > I haven't seen mentioned before. I have a feeling> > it has something> > to do with stack formats, but I'm not sure what to> > do next.> > > > I downloaded the cm3-5.4.0 binaries and started with> > that. The > > compiler in the binary distribution runs, but it> > appears to produce> > garbage. I first tried bootstrapping but it crashes> > the moment it> > tries to execute something it has compiled itself. > > So then I tried> > hello, world, with the same results...> > > > Here's the system identification:> > > > mika at edwards:~/test/src$ uname -a> > Linux edwards 2.6.20-16-386 #2 Sun Sep 23 19:47:10> > UTC 2007 i686 GNU/Linux> > > > I made a "hello, world" program as follows:> > > > MODULE Main;> > IMPORT IO;> > > > BEGIN IO.Put("Hello, world!\n") END Main.> > > > Compiled with cm3 directly from the distributed> > cm3-5.4.0 for > > LINUXLIBC6 and I get a crash in CsetjmpASM.s (as far> > as I can tell).> > The last unclobbered stack I seem to be able to get> > in m3gdb is> > this:> > > > Breakpoint 5, 0xb75e5fb4 in _setjmp () at> > ../src/C/LINUXLIBC6/CsetjmpASM.s:31> > 31 in ../src/C/LINUXLIBC6/CsetjmpASM.s> > (m3gdb) where> > #0 0xb75e5fb4 in _setjmp () at> > ../src/C/LINUXLIBC6/CsetjmpASM.s:31> > #1 0xb75dbd51 in RTThread__Transfer> > (from=0xbfe28530, to=0xbfe28530) at> > ../src/runtime/LINUXLIBC6/RTThreadC.c:14> > #2 0xb75dbaed in FlushStackCache () at> > RTThread.m3:65> > #3 0xb75e27c9 in DetermineContext (oldSP=Invalid> > C/C++ type code 35 in symbol table.> > ) at ThreadPosix.m3:1101> > #4 0xb75e270d in InitTopContext (c=Invalid C/C++> > type code 30 in symbol table.> > ) at ThreadPosix.m3:1076> > #5 0xb75e4325 in Init () at ThreadPosix.m3:1498> > #6 0xb75c9592 in InitRuntime (p_argc=Invalid C/C++> > type code 39 in symbol table.> > ) at RTLinker.m3:59> > #7 0x08048861 in main (argc=1, argv=0xbfe28824,> > envp=0xbfe2882c) at _m3main.mc:3> > (m3gdb) cont> > Continuing.> > > > Program received signal SIGSEGV, Segmentation fault.> > 0xa8dbaede in ?? ()> > > > s.sp was lately 16_b75af6b9, if that means anything> > at all.> > > > Oh yes, one more thing: setting LD_POINTER_GUARD to> > 0 before running> > the program has no effect on the crash.> > > > Any suggestions for how one might make progress on> > this?> > > > Mika> > > > > > > ______________________________________________ > ?Chef por primera vez?> S? un mejor Cocinillas. > http://es.answers.yahoo.com/info/welcome _________________________________________________________________ Don't get caught with egg on your face. Play Chicktionary! http://club.live.com/chicktionary.aspx?icid=chick_wlhmtextlink1_dec -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 16 03:40:19 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 15 Dec 2007 21:40:19 -0500 Subject: [M3devel] Ubuntu problems In-Reply-To: References: <200712160018.lBG0ITO5026048@camembert.async.caltech.edu> <147313.32986.qm@web27106.mail.ukl.yahoo.com> Message-ID: It may be slightly trickier than that, since appropriately sized jmpbuf/ucontext needs to be declared. On Dec 15, 2007, at 9:14 PM, Jay wrote: > Maybe time to grab a BSD setjmp/longjmp or getcontext/setcontext, > rename by prepending with m3_, and be done with it?? > e.g. > http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/arch/i386/sys/ > getcontext.S?rev=1.2&content-type=text/x-cvsweb-markup > http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/arch/powerpc/sys/ > getcontext.S?rev=1.3&content-type=text/x-cvsweb-markup > > My goodness, none of FreeBSD, OpenBSD, NetBSD have web searchable > CVS archives.. > better links later.. > > Regarding upgrade.sh, well, on Windows upgrade.cmd works. :) > They are all "just" wrappers around cd'ing and building, but > perhaps not trivial. > > - Jay > > > > Date: Sun, 16 Dec 2007 02:38:03 +0100 > > From: dabenavidesd at yahoo.es > > To: mika at async.caltech.edu; m3devel at elegosoft.com > > CC: mika at camembert.async.caltech.edu > > Subject: Re: [M3devel] Ubuntu problems > > > > Hi Mika, > > what are you seeing is the problem of libc > > setjmp/longjmp issue that we maybe have to advise more > > to cm3 users, and in general *m3 (dec-src,pm3,ezm3,and > > cm3 too) users that () user level thread > > implementation which is part of m3core is not working > > at this moment, so until community can make a > > functioning a new implementation, we will use only > > PTHREAD implementation on most new Linux > > distributions. > > Of course this solves the problems you are noticing, > > so my advise in order to this do not happen any more > > is write a note on the Download Area and maybe also in > > (like a note in the Known issues), www.modula3.org > > (If you allow me, I can do it) > > > > The most common case I know a (not very recent) of > > distribution that works with user level implementation > > that I use is Ubuntu Dapper 6.06, the libray is 2.3.6 > > http://packages.ubuntu.com/dapper/libdevel/libc6-dev > > The next version of Ubuntu breaks when the Juno > > package is compiling (pkl-fonts program executes), the > > library libc6 is > > http://packages.ubuntu.com/edgy/libdevel/libc6-dev. > > > > So for 5.4 sources use use the next CM3 variable > > export CM3="/usr/local/cm3/bin/cm3 -DPTHREAD" > > > > This enable the system level thread implementation in > > a earlier version of it (of cvs), but in the first > > step bootstrap compiler you will ran in same problems > > (in Edgy I got breack when running pkl-fonts, but > > after that break you can re-compile it all well with > > no problems, after you have build the new m3core). > > If you can update the sources with the most recent (in > > a personal opinion, stable version) would be better, > > but here I would like to know if the script upgrade.sh > > can do that work, i have not use it. > > For me the most easy way for me was use the > > instruction given by Tony for the cvs version, from I > > take his words and make a relatively simple > > instructions. > > > > Thanks > > > > > > > > > > > > > > --- Mika Nystrom wrote: > > > > > Hello Modula-3 people, > > > > > > I am trying to build things with CM3 on a relatively > > > recent Ubuntu > > > system (don't ask me why...) and I am running into a > > > segfault that > > > I haven't seen mentioned before. I have a feeling > > > it has something > > > to do with stack formats, but I'm not sure what to > > > do next. > > > > > > I downloaded the cm3-5.4.0 binaries and started with > > > that. The > > > compiler in the binary distribution runs, but it > > > appears to produce > > > garbage. I first tried bootstrapping but it crashes > > > the moment it > > > tries to execute something it has compiled itself. > > > So then I tried > > > hello, world, with the same results... > > > > > > Here's the system identification: > > > > > > mika at edwards:~/test/src$ uname -a > > > Linux edwards 2.6.20-16-386 #2 Sun Sep 23 19:47:10 > > > UTC 2007 i686 GNU/Linux > > > > > > I made a "hello, world" program as follows: > > > > > > MODULE Main; > > > IMPORT IO; > > > > > > BEGIN IO.Put("Hello, world!\n") END Main. > > > > > > Compiled with cm3 directly from the distributed > > > cm3-5.4.0 for > > > LINUXLIBC6 and I get a crash in CsetjmpASM.s (as far > > > as I can tell). > > > The last unclobbered stack I seem to be able to get > > > in m3gdb is > > > this: > > > > > > Breakpoint 5, 0xb75e5fb4 in _setjmp () at > > > ../src/C/LINUXLIBC6/CsetjmpASM.s:31 > > > 31 in ../src/C/LINUXLIBC6/CsetjmpASM.s > > > (m3gdb) where > > > #0 0xb75e5fb4 in _setjmp () at > > > ../src/C/LINUXLIBC6/CsetjmpASM.s:31 > > > #1 0xb75dbd51 in RTThread__Transfer > > > (from=0xbfe28530, to=0xbfe28530) at > > > ../src/runtime/LINUXLIBC6/RTThreadC.c:14 > > > #2 0xb75dbaed in FlushStackCache () at > > > RTThread.m3:65 > > > #3 0xb75e27c9 in DetermineContext (oldSP=Invalid > > > C/C++ type code 35 in symbol table. > > > ) at ThreadPosix.m3:1101 > > > #4 0xb75e270d in InitTopContext (c=Invalid C/C++ > > > type code 30 in symbol table. > > > ) at ThreadPosix.m3:1076 > > > #5 0xb75e4325 in Init () at ThreadPosix.m3:1498 > > > #6 0xb75c9592 in InitRuntime (p_argc=Invalid C/C++ > > > type code 39 in symbol table. > > > ) at RTLinker.m3:59 > > > #7 0x08048861 in main (argc=1, argv=0xbfe28824, > > > envp=0xbfe2882c) at _m3main.mc:3 > > > (m3gdb) cont > > > Continuing. > > > > > > Program received signal SIGSEGV, Segmentation fault. > > > 0xa8dbaede in ?? () > > > > > > s.sp was lately 16_b75af6b9, if that means anything > > > at all. > > > > > > Oh yes, one more thing: setting LD_POINTER_GUARD to > > > 0 before running > > > the program has no effect on the crash. > > > > > > Any suggestions for how one might make progress on > > > this? > > > > > > Mika > > > > > > > > > > > > > ______________________________________________ > > ?Chef por primera vez? > > S? un mejor Cocinillas. > > http://es.answers.yahoo.com/info/welcome > > > Don't get caught with egg on your face. Play Chicktionary! Check it > out! From jay.krell at cornell.edu Sun Dec 16 06:33:20 2007 From: jay.krell at cornell.edu (Jay) Date: Sun, 16 Dec 2007 05:33:20 +0000 Subject: [M3devel] Ubuntu problems In-Reply-To: References: <200712160018.lBG0ITO5026048@camembert.async.caltech.edu> <147313.32986.qm@web27106.mail.ukl.yahoo.com> Message-ID: http://opengrok.netbsd.org/source/search?q=&defs=setjmphttp://opengrok.netbsd.org/source/search?q=&defs=longjmp oh -- hopefully the existing sizes are correct for this code, else an interface break, not that m3 seems to mind binary compatibility breaks and all or stick version numbers in places, though maybe there are runtime checks for binary compat, at least for higher levels. On Windows, setjmp/longjmp optionally interact "correctly" with exception handling -- running __finally blocks and C++ destructors. I wonder if the same is true for gcc? (At some I'd really like to switch NT386 to not use setjmp/longjmp or TlsGetValue/TlsSetValue for this stuff.. after 64bit integer support...) - Jay > From: hosking at cs.purdue.edu> Date: Sat, 15 Dec 2007 21:40:19 -0500> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com; mika at camembert.async.caltech.edu> Subject: Re: [M3devel] Ubuntu problems> > It may be slightly trickier than that, since appropriately sized > jmpbuf/ucontext needs to be declared.> > On Dec 15, 2007, at 9:14 PM, Jay wrote:> > > Maybe time to grab a BSD setjmp/longjmp or getcontext/setcontext, > > rename by prepending with m3_, and be done with it??> > e.g.> > http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/arch/i386/sys/ > > getcontext.S?rev=1.2&content-type=text/x-cvsweb-markup> > http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/arch/powerpc/sys/ > > getcontext.S?rev=1.3&content-type=text/x-cvsweb-markup> >> > My goodness, none of FreeBSD, OpenBSD, NetBSD have web searchable > > CVS archives..> > better links later..> >> > Regarding upgrade.sh, well, on Windows upgrade.cmd works. :)> > They are all "just" wrappers around cd'ing and building, but > > perhaps not trivial.> >> > - Jay> >> >> > > Date: Sun, 16 Dec 2007 02:38:03 +0100> > > From: dabenavidesd at yahoo.es> > > To: mika at async.caltech.edu; m3devel at elegosoft.com> > > CC: mika at camembert.async.caltech.edu> > > Subject: Re: [M3devel] Ubuntu problems> > >> > > Hi Mika,> > > what are you seeing is the problem of libc> > > setjmp/longjmp issue that we maybe have to advise more> > > to cm3 users, and in general *m3 (dec-src,pm3,ezm3,and> > > cm3 too) users that () user level thread> > > implementation which is part of m3core is not working> > > at this moment, so until community can make a> > > functioning a new implementation, we will use only> > > PTHREAD implementation on most new Linux> > > distributions.> > > Of course this solves the problems you are noticing,> > > so my advise in order to this do not happen any more> > > is write a note on the Download Area and maybe also in> > > (like a note in the Known issues), www.modula3.org> > > (If you allow me, I can do it)> > >> > > The most common case I know a (not very recent) of> > > distribution that works with user level implementation> > > that I use is Ubuntu Dapper 6.06, the libray is 2.3.6> > > http://packages.ubuntu.com/dapper/libdevel/libc6-dev> > > The next version of Ubuntu breaks when the Juno> > > package is compiling (pkl-fonts program executes), the> > > library libc6 is> > > http://packages.ubuntu.com/edgy/libdevel/libc6-dev.> > >> > > So for 5.4 sources use use the next CM3 variable> > > export CM3="/usr/local/cm3/bin/cm3 -DPTHREAD"> > >> > > This enable the system level thread implementation in> > > a earlier version of it (of cvs), but in the first> > > step bootstrap compiler you will ran in same problems> > > (in Edgy I got breack when running pkl-fonts, but> > > after that break you can re-compile it all well with> > > no problems, after you have build the new m3core).> > > If you can update the sources with the most recent (in> > > a personal opinion, stable version) would be better,> > > but here I would like to know if the script upgrade.sh> > > can do that work, i have not use it.> > > For me the most easy way for me was use the> > > instruction given by Tony for the cvs version, from I> > > take his words and make a relatively simple> > > instructions.> > >> > > Thanks> > >> > >> > >> > >> > >> > >> > > --- Mika Nystrom wrote:> > >> > > > Hello Modula-3 people,> > > >> > > > I am trying to build things with CM3 on a relatively> > > > recent Ubuntu> > > > system (don't ask me why...) and I am running into a> > > > segfault that> > > > I haven't seen mentioned before. I have a feeling> > > > it has something> > > > to do with stack formats, but I'm not sure what to> > > > do next.> > > >> > > > I downloaded the cm3-5.4.0 binaries and started with> > > > that. The> > > > compiler in the binary distribution runs, but it> > > > appears to produce> > > > garbage. I first tried bootstrapping but it crashes> > > > the moment it> > > > tries to execute something it has compiled itself.> > > > So then I tried> > > > hello, world, with the same results...> > > >> > > > Here's the system identification:> > > >> > > > mika at edwards:~/test/src$ uname -a> > > > Linux edwards 2.6.20-16-386 #2 Sun Sep 23 19:47:10> > > > UTC 2007 i686 GNU/Linux> > > >> > > > I made a "hello, world" program as follows:> > > >> > > > MODULE Main;> > > > IMPORT IO;> > > >> > > > BEGIN IO.Put("Hello, world!\n") END Main.> > > >> > > > Compiled with cm3 directly from the distributed> > > > cm3-5.4.0 for> > > > LINUXLIBC6 and I get a crash in CsetjmpASM.s (as far> > > > as I can tell).> > > > The last unclobbered stack I seem to be able to get> > > > in m3gdb is> > > > this:> > > >> > > > Breakpoint 5, 0xb75e5fb4 in _setjmp () at> > > > ../src/C/LINUXLIBC6/CsetjmpASM.s:31> > > > 31 in ../src/C/LINUXLIBC6/CsetjmpASM.s> > > > (m3gdb) where> > > > #0 0xb75e5fb4 in _setjmp () at> > > > ../src/C/LINUXLIBC6/CsetjmpASM.s:31> > > > #1 0xb75dbd51 in RTThread__Transfer> > > > (from=0xbfe28530, to=0xbfe28530) at> > > > ../src/runtime/LINUXLIBC6/RTThreadC.c:14> > > > #2 0xb75dbaed in FlushStackCache () at> > > > RTThread.m3:65> > > > #3 0xb75e27c9 in DetermineContext (oldSP=Invalid> > > > C/C++ type code 35 in symbol table.> > > > ) at ThreadPosix.m3:1101> > > > #4 0xb75e270d in InitTopContext (c=Invalid C/C++> > > > type code 30 in symbol table.> > > > ) at ThreadPosix.m3:1076> > > > #5 0xb75e4325 in Init () at ThreadPosix.m3:1498> > > > #6 0xb75c9592 in InitRuntime (p_argc=Invalid C/C++> > > > type code 39 in symbol table.> > > > ) at RTLinker.m3:59> > > > #7 0x08048861 in main (argc=1, argv=0xbfe28824,> > > > envp=0xbfe2882c) at _m3main.mc:3> > > > (m3gdb) cont> > > > Continuing.> > > >> > > > Program received signal SIGSEGV, Segmentation fault.> > > > 0xa8dbaede in ?? ()> > > >> > > > s.sp was lately 16_b75af6b9, if that means anything> > > > at all.> > > >> > > > Oh yes, one more thing: setting LD_POINTER_GUARD to> > > > 0 before running> > > > the program has no effect on the crash.> > > >> > > > Any suggestions for how one might make progress on> > > > this?> > > >> > > > Mika> > > >> > >> > >> > >> > >> > > ______________________________________________> > > ?Chef por primera vez?> > > S? un mejor Cocinillas.> > > http://es.answers.yahoo.com/info/welcome> >> >> > Don't get caught with egg on your face. Play Chicktionary! Check it > > out!> _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sun Dec 16 07:56:33 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 15 Dec 2007 22:56:33 -0800 Subject: [M3devel] Ubuntu problems In-Reply-To: Your message of "Sat, 15 Dec 2007 17:35:54 PST." <200712160135.lBG1ZsZ2028488@camembert.async.caltech.edu> Message-ID: <200712160656.lBG6uXRg038351@camembert.async.caltech.edu> All right, thanks for your suggestions. I seem to have made a working compiler. Even mentor works on this Ubuntu 2.6.20. My main observation is that M3/Linux is crying out for a new bootstrap compiler binary. Neither the one from Tony's site nor the 5.4.0 cm3 is actually able to compile the CVS head. The problems come from Long.m3 (instance of GenWord.mg) and Int64.i3. I was able to work around these issues by putting in some garbage in these files and bootstrapping twice---the second time with the proper code in Long.m3 and Int64.i3. It's not that the bootstrapping compiler doesn't know about long (at least one of them does), it just crashes. But no harm done, it all seems to work after fiddling with it. Another issue---and I feel stupid for asking, it seems so basic---is that Linux is really stingy with static archives (.a files), and my cm3.cfg was asking for -lXaw, which didn't work, even though there was a libXaw.so.6 present. I changed the cfg to link explicitly with /usr/lib/libXaw.so.6, but that can't be the right way to do it?? Oh the 5.4.0 cm3.cfg also wraps the "utimes" call. I took this out, as no one was supplying wrap_utimes. I take it this is safe... (a GC-related modification?) Mika Mika Nystrom writes: >Sorry, I have now read the mailing list archives a bit better. > >I am going to try bootstrapping the latest CVS with Tony's cm3 binary, >to use pthreads... > > Mika > > >Mika Nystrom writes: >>Hello Modula-3 people, >> >>I am trying to build things with CM3 on a relatively recent Ubuntu >>system (don't ask me why...) and I am running into a segfault that >>I haven't seen mentioned before. I have a feeling it has something >>to do with stack formats, but I'm not sure what to do next. >> >>I downloaded the cm3-5.4.0 binaries and started with that. The >>compiler in the binary distribution runs, but it appears to produce >>garbage. I first tried bootstrapping but it crashes the moment it >>tries to execute something it has compiled itself. So then I tried >>hello, world, with the same results... >> >>Here's the system identification: >> >>mika at edwards:~/test/src$ uname -a >>Linux edwards 2.6.20-16-386 #2 Sun Sep 23 19:47:10 UTC 2007 i686 GNU/Linux >> >>I made a "hello, world" program as follows: >> >>MODULE Main; >>IMPORT IO; >> >>BEGIN IO.Put("Hello, world!\n") END Main. >> >>Compiled with cm3 directly from the distributed cm3-5.4.0 for >>LINUXLIBC6 and I get a crash in CsetjmpASM.s (as far as I can tell). >>The last unclobbered stack I seem to be able to get in m3gdb is >>this: >> >>Breakpoint 5, 0xb75e5fb4 in _setjmp () at ../src/C/LINUXLIBC6/CsetjmpASM.s:31 >>31 in ../src/C/LINUXLIBC6/CsetjmpASM.s >>(m3gdb) where >>#0 0xb75e5fb4 in _setjmp () at ../src/C/LINUXLIBC6/CsetjmpASM.s:31 >>#1 0xb75dbd51 in RTThread__Transfer (from=0xbfe28530, to=0xbfe28530) at ../s >r >>c/runtime/LINUXLIBC6/RTThreadC.c:14 >>#2 0xb75dbaed in FlushStackCache () at RTThread.m3:65 >>#3 0xb75e27c9 in DetermineContext (oldSP=Invalid C/C++ type code 35 in symbo >l >> table. >>) at ThreadPosix.m3:1101 >>#4 0xb75e270d in InitTopContext (c=Invalid C/C++ type code 30 in symbol tabl >e >>. >>) at ThreadPosix.m3:1076 >>#5 0xb75e4325 in Init () at ThreadPosix.m3:1498 >>#6 0xb75c9592 in InitRuntime (p_argc=Invalid C/C++ type code 39 in symbol ta >b >>le. >>) at RTLinker.m3:59 >>#7 0x08048861 in main (argc=1, argv=0xbfe28824, envp=0xbfe2882c) at _m3main. >m >>c:3 >>(m3gdb) cont >>Continuing. >> >>Program received signal SIGSEGV, Segmentation fault. >>0xa8dbaede in ?? () >> >>s.sp was lately 16_b75af6b9, if that means anything at all. >> >>Oh yes, one more thing: setting LD_POINTER_GUARD to 0 before running >>the program has no effect on the crash. >> >>Any suggestions for how one might make progress on this? >> >> Mika From wagner at elegosoft.com Sun Dec 16 17:31:03 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 16 Dec 2007 17:31:03 +0100 Subject: [M3devel] Spanish speaking CM3 users? In-Reply-To: <47646653.4070106@purdue.edu> References: <20071215235051.rhq0fgeabk4k48gk@mail.elegosoft.com> <47646653.4070106@purdue.edu> Message-ID: <20071216173103.3864tbyzs4so4s8c@mail.elegosoft.com> Quoting "Neil T. Dantam" : > Olaf, > I can at least translate the Spanish for you. Thanks for the translation. > Angela, > ?Tratar los instrucciones de este mensaje? (Did you try the instructions > in this email?) > > https://mail.elegosoft.com/pipermail/m3devel/2007-June/000227.html > > Describen como compilar el compilador. (They describe how to bootstrap > the compiler.) Angela, I have subscribed you to this list and hope that you undestand this. The failure you see is probably due to fundamental changes in the compiler since the last release (addition of 64 bit integers and changes in the garbage collector and threads runtime) which makes a more complex upgrade necessary. Current boot/installation archives for all platforms are overdue; I'm currently trying to build the one for FreeBSD on my home computer. I think we could get something more up-to-date and easier to install for Linux, Solaris, and Darwin within the next week(s). Please stay tuned, Olaf PS: If you send bug reports to the list, you should always add the exact system and environment you are using (uname -a, which archives did you use, what were the exact commands you issed that led to the failure). > Olaf Wagner wrote: >> ----- Forwarded message from anietog at unal.edu.co ----- >> Date: Sat, 15 Dec 2007 17:55:45 +0100 (CET) >> From: Angela >> Reply-To: Angela >> Subject: Anfrage Mailformular >> To: info at elego.de >> >> NAME: Angela >> EMAIL: anietog at unal.edu.co >> ADDRESS: >> Hola, escribo porque tengo un problema al tratar de compilar el >> compilador de fase 1, esto es lo que me aparece: > > Hello, I'm writing because I have a problem regarding compiling phase > one of the compiler. This is what I see: > >> .... >> new source -> compiling Text.i3 >> new source -> compiling RTProcedureSRC.i3 >> new source -> compiling Fingerprint.i3 >> new source -> compiling RTProcedure.i3 >> new source -> compiling RTStack.i3 >> new source -> compiling RTAllocStats.m3 >> "../src/runtime/common/RTAllocStats.m3", line 46: undefined runtime >> symbol !! (RTHooks.AllocateTracedRef) >> >> >> *** >> *** runtime error: >> *** Segmentation violation - possible attempt to dereference NIL >> *** pc = 0x80c5c3c = StartCall + 0x18 in ../src/values/Procedure.m3 >> *** >> >> Aborted (core dumped) >> *** execution of failed *** >> >> >> Agradezco cualquier colaboraci?n ya que aun no he podido culminar mi >> instalacion de cm3. > > I would appreciate any help, because I could not finish my > installation of cm3. > >> >> ----- End forwarded message ----- > > > -- > Neil T. Dantam > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sun Dec 16 17:35:40 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 16 Dec 2007 11:35:40 -0500 Subject: [M3devel] Ubuntu problems In-Reply-To: References: <200712160018.lBG0ITO5026048@camembert.async.caltech.edu> <147313.32986.qm@web27106.mail.ukl.yahoo.com> Message-ID: <324F7DBA-ECF9-4382-A1F1-FA5D4B380247@cs.purdue.edu> There are two places where setjmp/longjmp are used: user-level threading and exception handling. On Windows, they are only used for exception handling since we rely on system threads. On Solaris and Alpha/OSF they are not used for exception handling since those targets have stack unwinding support. Converting user-level threading to use setcontext/getcontext should be relatively straightforward, based on the model already implemented for Solaris which I converted to setcontext/getcontext many years ago. On Dec 16, 2007, at 12:33 AM, Jay wrote: > http://opengrok.netbsd.org/source/search?q=&defs=setjmp > http://opengrok.netbsd.org/source/search?q=&defs=longjmp > > oh -- hopefully the existing sizes are correct for this code, else > an interface break, not that m3 seems to mind binary compatibility > breaks and all or stick version numbers in places, though maybe > there are runtime checks for binary compat, at least for higher > levels. > > On Windows, setjmp/longjmp optionally interact "correctly" with > exception handling -- running __finally blocks and C++ destructors. > I wonder if the same is true for gcc? > (At some I'd really like to switch NT386 to not use setjmp/longjmp > or TlsGetValue/TlsSetValue for this stuff.. after 64bit integer > support...) > > - Jay > > > > From: hosking at cs.purdue.edu > > Date: Sat, 15 Dec 2007 21:40:19 -0500 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com; mika at camembert.async.caltech.edu > > Subject: Re: [M3devel] Ubuntu problems > > > > It may be slightly trickier than that, since appropriately sized > > jmpbuf/ucontext needs to be declared. > > > > On Dec 15, 2007, at 9:14 PM, Jay wrote: > > > > > Maybe time to grab a BSD setjmp/longjmp or getcontext/setcontext, > > > rename by prepending with m3_, and be done with it?? > > > e.g. > > > http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/arch/i386/sys/ > > > getcontext.S?rev=1.2&content-type=text/x-cvsweb-markup > > > http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/arch/powerpc/sys/ > > > getcontext.S?rev=1.3&content-type=text/x-cvsweb-markup > > > > > > My goodness, none of FreeBSD, OpenBSD, NetBSD have web searchable > > > CVS archives.. > > > better links later.. > > > > > > Regarding upgrade.sh, well, on Windows upgrade.cmd works. :) > > > They are all "just" wrappers around cd'ing and building, but > > > perhaps not trivial. > > > > > > - Jay > > > > > > > > > > Date: Sun, 16 Dec 2007 02:38:03 +0100 > > > > From: dabenavidesd at yahoo.es > > > > To: mika at async.caltech.edu; m3devel at elegosoft.com > > > > CC: mika at camembert.async.caltech.edu > > > > Subject: Re: [M3devel] Ubuntu problems > > > > > > > > Hi Mika, > > > > what are you seeing is the problem of libc > > > > setjmp/longjmp issue that we maybe have to advise more > > > > to cm3 users, and in general *m3 (dec-src,pm3,ezm3,and > > > > cm3 too) users that () user level thread > > > > implementation which is part of m3core is not working > > > > at this moment, so until community can make a > > > > functioning a new implementation, we will use only > > > > PTHREAD implementation on most new Linux > > > > distributions. > > > > Of course this solves the problems you are noticing, > > > > so my advise in order to this do not happen any more > > > > is write a note on the Download Area and maybe also in > > > > (like a note in the Known issues), www.modula3.org > > > > (If you allow me, I can do it) > > > > > > > > The most common case I know a (not very recent) of > > > > distribution that works with user level implementation > > > > that I use is Ubuntu Dapper 6.06, the libray is 2.3.6 > > > > http://packages.ubuntu.com/dapper/libdevel/libc6-dev > > > > The next version of Ubuntu breaks when the Juno > > > > package is compiling (pkl-fonts program executes), the > > > > library libc6 is > > > > http://packages.ubuntu.com/edgy/libdevel/libc6-dev. > > > > > > > > So for 5.4 sources use use the next CM3 variable > > > > export CM3="/usr/local/cm3/bin/cm3 -DPTHREAD" > > > > > > > > This enable the system level thread implementation in > > > > a earlier version of it (of cvs), but in the first > > > > step bootstrap compiler you will ran in same problems > > > > (in Edgy I got breack when running pkl-fonts, but > > > > after that break you can re-compile it all well with > > > > no problems, after you have build the new m3core). > > > > If you can update the sources with the most recent (in > > > > a personal opinion, stable version) would be better, > > > > but here I would like to know if the script upgrade.sh > > > > can do that work, i have not use it. > > > > For me the most easy way for me was use the > > > > instruction given by Tony for the cvs version, from I > > > > take his words and make a relatively simple > > > > instructions. > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > > --- Mika Nystrom wrote: > > > > > > > > > Hello Modula-3 people, > > > > > > > > > > I am trying to build things with CM3 on a relatively > > > > > recent Ubuntu > > > > > system (don't ask me why...) and I am running into a > > > > > segfault that > > > > > I haven't seen mentioned before. I have a feeling > > > > > it has something > > > > > to do with stack formats, but I'm not sure what to > > > > > do next. > > > > > > > > > > I downloaded the cm3-5.4.0 binaries and started with > > > > > that. The > > > > > compiler in the binary distribution runs, but it > > > > > appears to produce > > > > > garbage. I first tried bootstrapping but it crashes > > > > > the moment it > > > > > tries to execute something it has compiled itself. > > > > > So then I tried > > > > > hello, world, with the same results... > > > > > > > > > > Here's the system identification: > > > > > > > > > > mika at edwards:~/test/src$ uname -a > > > > > Linux edwards 2.6.20-16-386 #2 Sun Sep 23 19:47:10 > > > > > UTC 2007 i686 GNU/Linux > > > > > > > > > > I made a "hello, world" program as follows: > > > > > > > > > > MODULE Main; > > > > > IMPORT IO; > > > > > > > > > > BEGIN IO.Put("Hello, world!\n") END Main. > > > > > > > > > > Compiled with cm3 directly from the distributed > > > > > cm3-5.4.0 for > > > > > LINUXLIBC6 and I get a crash in CsetjmpASM.s (as far > > > > > as I can tell). > > > > > The last unclobbered stack I seem to be able to get > > > > > in m3gdb is > > > > > this: > > > > > > > > > > Breakpoint 5, 0xb75e5fb4 in _setjmp () at > > > > > ../src/C/LINUXLIBC6/CsetjmpASM.s:31 > > > > > 31 in ../src/C/LINUXLIBC6/CsetjmpASM.s > > > > > (m3gdb) where > > > > > #0 0xb75e5fb4 in _setjmp () at > > > > > ../src/C/LINUXLIBC6/CsetjmpASM.s:31 > > > > > #1 0xb75dbd51 in RTThread__Transfer > > > > > (from=0xbfe28530, to=0xbfe28530) at > > > > > ../src/runtime/LINUXLIBC6/RTThreadC.c:14 > > > > > #2 0xb75dbaed in FlushStackCache () at > > > > > RTThread.m3:65 > > > > > #3 0xb75e27c9 in DetermineContext (oldSP=Invalid > > > > > C/C++ type code 35 in symbol table. > > > > > ) at ThreadPosix.m3:1101 > > > > > #4 0xb75e270d in InitTopContext (c=Invalid C/C++ > > > > > type code 30 in symbol table. > > > > > ) at ThreadPosix.m3:1076 > > > > > #5 0xb75e4325 in Init () at ThreadPosix.m3:1498 > > > > > #6 0xb75c9592 in InitRuntime (p_argc=Invalid C/C++ > > > > > type code 39 in symbol table. > > > > > ) at RTLinker.m3:59 > > > > > #7 0x08048861 in main (argc=1, argv=0xbfe28824, > > > > > envp=0xbfe2882c) at _m3main.mc:3 > > > > > (m3gdb) cont > > > > > Continuing. > > > > > > > > > > Program received signal SIGSEGV, Segmentation fault. > > > > > 0xa8dbaede in ?? () > > > > > > > > > > s.sp was lately 16_b75af6b9, if that means anything > > > > > at all. > > > > > > > > > > Oh yes, one more thing: setting LD_POINTER_GUARD to > > > > > 0 before running > > > > > the program has no effect on the crash. > > > > > > > > > > Any suggestions for how one might make progress on > > > > > this? > > > > > > > > > > Mika > > > > > > > > > > > > > > > > > > > > > > > > > ______________________________________________ > > > > ?Chef por primera vez? > > > > S? un mejor Cocinillas. > > > > http://es.answers.yahoo.com/info/welcome > > > > > > > > > Don't get caught with egg on your face. Play Chicktionary! > Check it > > > out! > > > > > Share life as it happens with the new Windows Live. Share now! From hosking at cs.purdue.edu Sun Dec 16 17:37:35 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 16 Dec 2007 11:37:35 -0500 Subject: [M3devel] Ubuntu problems In-Reply-To: <200712160656.lBG6uXRg038351@camembert.async.caltech.edu> References: <200712160656.lBG6uXRg038351@camembert.async.caltech.edu> Message-ID: On Dec 16, 2007, at 1:56 AM, Mika Nystrom wrote: > > All right, thanks for your suggestions. I seem to have made a > working compiler. Even mentor works on this Ubuntu 2.6.20. > > My main observation is that M3/Linux is crying out for a new bootstrap > compiler binary. Neither the one from Tony's site nor the 5.4.0 > cm3 is actually able to compile the CVS head. The problems come > from Long.m3 (instance of GenWord.mg) and Int64.i3. I was able to > work around these issues by putting in some garbage in these files > and bootstrapping twice---the second time with the proper code in > Long.m3 and Int64.i3. It's not that the bootstrapping compiler > doesn't > know about long (at least one of them does), it just crashes. But > no harm done, it all seems to work after fiddling with it. I need to update my ftp site with a version of the Linux bootstrap compiler that will work for the LONGINT support. > Another issue---and I feel stupid for asking, it seems so basic---is > that Linux is really stingy with static archives (.a files), and > my cm3.cfg was asking for -lXaw, which didn't work, even though > there was a libXaw.so.6 present. I changed the cfg to link explicitly > with /usr/lib/libXaw.so.6, but that can't be the right way to do it?? > Oh the 5.4.0 cm3.cfg also wraps the "utimes" call. I took this out, > as no one was supplying wrap_utimes. I take it this is safe... (a > GC-related modification?) You are working off of a very old cm3.cfg -- try the one from my ftp site. > > Mika > > Mika Nystrom writes: >> Sorry, I have now read the mailing list archives a bit better. >> >> I am going to try bootstrapping the latest CVS with Tony's cm3 >> binary, >> to use pthreads... >> >> Mika >> >> >> Mika Nystrom writes: >>> Hello Modula-3 people, >>> >>> I am trying to build things with CM3 on a relatively recent Ubuntu >>> system (don't ask me why...) and I am running into a segfault that >>> I haven't seen mentioned before. I have a feeling it has something >>> to do with stack formats, but I'm not sure what to do next. >>> >>> I downloaded the cm3-5.4.0 binaries and started with that. The >>> compiler in the binary distribution runs, but it appears to produce >>> garbage. I first tried bootstrapping but it crashes the moment it >>> tries to execute something it has compiled itself. So then I tried >>> hello, world, with the same results... >>> >>> Here's the system identification: >>> >>> mika at edwards:~/test/src$ uname -a >>> Linux edwards 2.6.20-16-386 #2 Sun Sep 23 19:47:10 UTC 2007 i686 >>> GNU/Linux >>> >>> I made a "hello, world" program as follows: >>> >>> MODULE Main; >>> IMPORT IO; >>> >>> BEGIN IO.Put("Hello, world!\n") END Main. >>> >>> Compiled with cm3 directly from the distributed cm3-5.4.0 for >>> LINUXLIBC6 and I get a crash in CsetjmpASM.s (as far as I can tell). >>> The last unclobbered stack I seem to be able to get in m3gdb is >>> this: >>> >>> Breakpoint 5, 0xb75e5fb4 in _setjmp () at ../src/C/LINUXLIBC6/ >>> CsetjmpASM.s:31 >>> 31 in ../src/C/LINUXLIBC6/CsetjmpASM.s >>> (m3gdb) where >>> #0 0xb75e5fb4 in _setjmp () at ../src/C/LINUXLIBC6/CsetjmpASM.s:31 >>> #1 0xb75dbd51 in RTThread__Transfer (from=0xbfe28530, >>> to=0xbfe28530) at ../s >> r >>> c/runtime/LINUXLIBC6/RTThreadC.c:14 >>> #2 0xb75dbaed in FlushStackCache () at RTThread.m3:65 >>> #3 0xb75e27c9 in DetermineContext (oldSP=Invalid C/C++ type code >>> 35 in symbo >> l >>> table. >>> ) at ThreadPosix.m3:1101 >>> #4 0xb75e270d in InitTopContext (c=Invalid C/C++ type code 30 in >>> symbol tabl >> e >>> . >>> ) at ThreadPosix.m3:1076 >>> #5 0xb75e4325 in Init () at ThreadPosix.m3:1498 >>> #6 0xb75c9592 in InitRuntime (p_argc=Invalid C/C++ type code 39 >>> in symbol ta >> b >>> le. >>> ) at RTLinker.m3:59 >>> #7 0x08048861 in main (argc=1, argv=0xbfe28824, envp=0xbfe2882c) >>> at _m3main. >> m >>> c:3 >>> (m3gdb) cont >>> Continuing. >>> >>> Program received signal SIGSEGV, Segmentation fault. >>> 0xa8dbaede in ?? () >>> >>> s.sp was lately 16_b75af6b9, if that means anything at all. >>> >>> Oh yes, one more thing: setting LD_POINTER_GUARD to 0 before running >>> the program has no effect on the crash. >>> >>> Any suggestions for how one might make progress on this? >>> >>> Mika From wagner at elegosoft.com Sun Dec 16 18:10:59 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 16 Dec 2007 18:10:59 +0100 Subject: [M3devel] Info about Jay Krell? Fwd: Uncaught bounce notification Message-ID: <20071216181059.8vpo9jtzijo8k0g8@mail.elegosoft.com> Hi, I wouldn't normally forward this to the list, but since Jay has been such an eager contributor to cm3 on windows: does anybody know why all his mail bounces and how he can be reached? Thanks, Olaf Date: Sun, 16 Dec 2007 11:31:15 -0500 (EST) Subject: Problems delivering your mail From: MAILER-DAEMON at cornell.edu To: m3devel-bounces at elegosoft.com 2.1 unnamed [text/plain] 5.58 KB Download I'm sorry, but we had problems delivering your mail. The errors we encountered appear below. If you have any questions, contact the Cornell Postmaster as . Please include a copy of this message with your correspondence. -------- The following addresses could not be found at all in our Directory. Please make sure you have the correct address. jay.krell at cornell.edu -------- -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Dec 16 22:23:01 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 16 Dec 2007 22:23:01 +0100 Subject: [M3devel] m3cg build failure on powerpc/darwin Message-ID: <20071216212301.GA25212@elegosoft.com> Hi, while trying to build some boot archives build on my PowerBook G4, uname -a Darwin apple.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power Macintosh powerpc the compilation died with /Users/wagner/work/cm3/m3-sys/m3cc/PPC_DARWIN/./gcc/xgcc -B/Users/wagner/work/cm3/m3-sys/m3cc/PPC_DARWIN/./gcc/ -B/usr/local/powerpc-apple-darwin7.9.0/bin/ -B/usr/local/powerpc-apple-darwin7.9.0/lib/ -isystem /usr/local/powerpc-apple-darwin7.9.0/include -isystem /usr/local/powerpc-apple-darwin7.9.0/sys-include -c -DHAVE_CONFIG_H -O2 -O2 -g -I. -I../../../gcc/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../../gcc/libiberty/floatformat.c -o floatformat.o ../../../gcc/libiberty/floatformat.c: In function 'floatformat_to_double': ../../../gcc/libiberty/floatformat.c:354: warning: floating constant exceeds range of 'float' /var/tmp/cccvQbrs.s:508:stfiwx instruction is optional for the PowerPC (not allowed without -force_cpusubtype_ALL option) /var/tmp/cccvQbrs.s:550:stfiwx instruction is optional for the PowerPC (not allowed without -force_cpusubtype_ALL option) make[2]: *** [floatformat.o] Error 1 make[1]: *** [all-target-libiberty] Error 2 make: *** [all] Error 2 "/Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile", line 188: quake runtime error: exit 512: cd .; make CC="gcc" CFLAGS="-O2 -g" --procedure-- -line- -file--- exec -- include_dir 188 /Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile 5 /Users/wagner/work/cm3/m3-sys/m3cc/PPC_DARWIN/m3make.args Fatal Error: package build failed Any ideas? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Sun Dec 16 23:02:58 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 16 Dec 2007 23:02:58 +0100 Subject: [M3devel] m3cg build failure on powerpc/darwin In-Reply-To: <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> Message-ID: <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> Quoting Tony Hosking : > That is a very old Darwin distro. Here is my G4: > > Darwin Kernel Version 8.10.0: Wed May 23 16:50:59 PDT 2007; > root:xnu-792.21.3~1/RELEASE_PPC Seems I'm stuck then. Newer versions of the OS won't run on this PowerBook according to specification. So current versions of CM3 aren't possible anymore, too... It seems that it isn't possible anymore to use a computer that is older than two years to run any medium to large-size current software :-( The upgrade script for Linux just died with === package m3-sys/cm3 === +++ cm3 -build -DROOT='/home/wagner/work/cm3' && cm3 -ship -DROOT='/home/wagner/work/cm3' +++ --- building in LINUXLIBC6 --- ignoring ../src/m3overrides -> linking cm3 /usr/local/cm3/pkg/libm3/LINUXLIBC6/libm3.a(FSPosix.mo): In function `FS__SetModificationTime': /home/wagner/work/cm3/m3-libs/libm3/LINUXLIBC6/FSPosix.m3:348: undefined reference to `__wrap_utimes' collect2: ld returned 1 exit status Fatal Error: package build failed on birch.elegosoft.com. So the only thing I've succeeded in today is building a bootstrap for FreeBSD 6.3. Olaf > On Dec 16, 2007, at 4:23 PM, Olaf Wagner wrote: > >> Hi, >> >> while trying to build some boot archives build on my PowerBook >> G4, uname -a >> >> Darwin apple.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 >> 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power >> Macintosh powerpc >> >> the compilation died with >> >> /Users/wagner/work/cm3/m3-sys/m3cc/PPC_DARWIN/./gcc/xgcc >> -B/Users/wagner/work/cm3/m3-sys/m3cc/PPC_DARWIN/./gcc/ >> -B/usr/local/powerpc-apple-darwin7.9.0/bin/ >> -B/usr/local/powerpc-apple-darwin7.9.0/lib/ -isystem >> /usr/local/powerpc-apple-darwin7.9.0/include -isystem >> /usr/local/powerpc-apple-darwin7.9.0/sys-include -c -DHAVE_CONFIG_H >> -O2 -O2 -g -I. -I../../../gcc/libiberty/../include -W -Wall >> -pedantic -Wwrite-strings -Wstrict-prototypes >> ../../../gcc/libiberty/floatformat.c -o floatformat.o >> ../../../gcc/libiberty/floatformat.c: In function 'floatformat_to_double': >> ../../../gcc/libiberty/floatformat.c:354: warning: floating >> constant exceeds range of 'float' >> /var/tmp/cccvQbrs.s:508:stfiwx instruction is optional for the >> PowerPC (not allowed without -force_cpusubtype_ALL option) >> /var/tmp/cccvQbrs.s:550:stfiwx instruction is optional for the >> PowerPC (not allowed without -force_cpusubtype_ALL option) >> make[2]: *** [floatformat.o] Error 1 >> make[1]: *** [all-target-libiberty] Error 2 >> make: *** [all] Error 2 >> "/Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile", line 188: >> quake runtime error: exit 512: cd .; make CC="gcc" CFLAGS="-O2 -g" >> >> --procedure-- -line- -file--- >> exec -- >> include_dir 188 /Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile >> 5 >> /Users/wagner/work/cm3/m3-sys/m3cc/PPC_DARWIN/m3make.args >> >> Fatal Error: package build failed >> >> 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 mika at async.caltech.edu Sun Dec 16 23:14:35 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 16 Dec 2007 14:14:35 -0800 Subject: [M3devel] m3cg build failure on powerpc/darwin In-Reply-To: Your message of "Sun, 16 Dec 2007 23:02:58 +0100." <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> Message-ID: <200712162214.lBGMEagW066782@camembert.async.caltech.edu> Olaf Wagner writes: ... >The upgrade script for Linux just died with > >=== package m3-sys/cm3 === > +++ cm3 -build -DROOT='/home/wagner/work/cm3' && cm3 -ship >-DROOT='/home/wagner/work/cm3' +++ >--- building in LINUXLIBC6 --- > >ignoring ../src/m3overrides > > -> linking cm3 >/usr/local/cm3/pkg/libm3/LINUXLIBC6/libm3.a(FSPosix.mo): In function >`FS__SetModificationTime': >/home/wagner/work/cm3/m3-libs/libm3/LINUXLIBC6/FSPosix.m3:348: >undefined reference to `__wrap_utimes' >collect2: ld returned 1 exit status >Fatal Error: package build failed > >on birch.elegosoft.com. This is the same problem I had on Ubuntu yesterday. You need to remove -wrap,utimes from your cm3.cfg, or use Tony's newer cm3.cfg. > >So the only thing I've succeeded in today is building a bootstrap >for FreeBSD 6.3. Ironically, FreeBSD is extremely good at backward-compatibility of binaries! I think I may still have a FreeBSD 3.x system somewhere with Modula-3 on it... This is just for historical reasons, but we still do use 4.11 systems in production, so it would be nice if there were bootstraps on 4.11. (4.11-generated compilers work fine w/o modification on 5.x.) Mika > >Olaf > >> On Dec 16, 2007, at 4:23 PM, Olaf Wagner wrote: >> >>> Hi, >>> >>> while trying to build some boot archives build on my PowerBook >>> G4, uname -a >>> >>> Darwin apple.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 >>> 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power >>> Macintosh powerpc >>> >>> the compilation died with >>> >>> /Users/wagner/work/cm3/m3-sys/m3cc/PPC_DARWIN/./gcc/xgcc >>> -B/Users/wagner/work/cm3/m3-sys/m3cc/PPC_DARWIN/./gcc/ >>> -B/usr/local/powerpc-apple-darwin7.9.0/bin/ >>> -B/usr/local/powerpc-apple-darwin7.9.0/lib/ -isystem >>> /usr/local/powerpc-apple-darwin7.9.0/include -isystem >>> /usr/local/powerpc-apple-darwin7.9.0/sys-include -c -DHAVE_CONFIG_H >>> -O2 -O2 -g -I. -I../../../gcc/libiberty/../include -W -Wall >>> -pedantic -Wwrite-strings -Wstrict-prototypes >>> ../../../gcc/libiberty/floatformat.c -o floatformat.o >>> ../../../gcc/libiberty/floatformat.c: In function 'floatformat_to_double': >>> ../../../gcc/libiberty/floatformat.c:354: warning: floating >>> constant exceeds range of 'float' >>> /var/tmp/cccvQbrs.s:508:stfiwx instruction is optional for the >>> PowerPC (not allowed without -force_cpusubtype_ALL option) >>> /var/tmp/cccvQbrs.s:550:stfiwx instruction is optional for the >>> PowerPC (not allowed without -force_cpusubtype_ALL option) >>> make[2]: *** [floatformat.o] Error 1 >>> make[1]: *** [all-target-libiberty] Error 2 >>> make: *** [all] Error 2 >>> "/Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile", line 188: >>> quake runtime error: exit 512: cd .; make CC="gcc" CFLAGS="-O2 -g" >>> >>> --procedure-- -line- -file--- >>> exec -- >>> include_dir 188 /Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile >>> 5 >>> /Users/wagner/work/cm3/m3-sys/m3cc/PPC_DARWIN/m3make.args >>> >>> Fatal Error: package build failed >>> >>> 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 mika at async.caltech.edu Sun Dec 16 23:25:43 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 16 Dec 2007 14:25:43 -0800 Subject: [M3devel] m3cg build failure on powerpc/darwin In-Reply-To: Your message of "Sun, 16 Dec 2007 14:14:35 PST." <200712162214.lBGMEagW066782@camembert.async.caltech.edu> Message-ID: <200712162225.lBGMPhm5067188@camembert.async.caltech.edu> Mika Nystrom writes: ... >we still do use 4.11 systems in production, so it would be nice if >there were bootstraps on 4.11. (4.11-generated compilers work fine >w/o modification on 5.x.) I should add, in case it's not clearly understood from the above, that I'd be more than happy to help generating such a bootstrap if it's going to be a release version! From wagner at elegosoft.com Sun Dec 16 23:32:59 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 16 Dec 2007 23:32:59 +0100 Subject: [M3devel] m3cg build failure on powerpc/darwin In-Reply-To: <28256359-D312-4D47-9A38-7A245D6AEAE5@cs.purdue.edu> References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> <28256359-D312-4D47-9A38-7A245D6AEAE5@cs.purdue.edu> Message-ID: <20071216233259.ukim9ntk6cw8gsgc@mail.elegosoft.com> Quoting Tony Hosking : >> Seems I'm stuck then. Newer versions of the OS won't run on this >> PowerBook according to specification. So current versions of CM3 >> aren't possible anymore, too... >> >> It seems that it isn't possible anymore to use a computer that is >> older than two years to run any medium to large-size current >> software :-( > > I can build a bootstrap for PPC_DARWIN if you like. That would be great (and may be the fastest solution). >> The upgrade script for Linux just died with [...] > Looks like you have an old cm3.cfg with the wrapper link commands in > it. Delete those and you should be good. Found that, removed it and redid everything from start after several spurious errors (Mika mentioned it, too). Now I get this: ... /home/wagner/work/cm3/scripts/install-cm3-compiler.sh upgrade cp_if: /usr/local/cm3/bin/cm3 and /usr/local/cm3/bin/cm3-d5.5.0 identical cp_if: /usr/local/cm3/bin/cm3cg and /usr/local/cm3/bin/cm3cg-d5.5.0 identical /home/wagner/work/cm3/scripts/install-cm3-compiler.sh: line 109: /home/wagner/work/cm3/m3-sys/cm3/LINUXLIBC6/cm3: No such file or directory cp /home/wagner/work/cm3/m3-sys/cm3/LINUXLIBC6/cm3 /usr/local/cm3/bin/cm3- cp_if: /home/wagner/work/cm3/m3-sys/m3cc/LINUXLIBC6/cm3cg and /usr/local/cm3/bin/cm3cg- identical cp /usr/local/cm3/bin/cm3- /usr/local/cm3/bin/cm3 cp /usr/local/cm3/bin/cm3cg- /usr/local/cm3/bin/cm3cg /home/wagner/work/cm3/scripts/do-cm3-core.sh buildship CM3C = /home/wagner/work/cm3/scripts/pkgmap.sh -c "cm3 -build -DROOT='/home/wagner/work/cm3' && cm3 -ship -DROOT='/home/wagner/work/cm3' " m3core libm3 patternmatching m3middle m3linker m3front m3quake m3cc cm3 m3scanner m3tools m3cgcat m3cggen m3bundle bitvector digraph parseparams realgeometry set slisp sortedtableextras table-list tempfiles === package m3-libs/m3core === +++ cm3 -build -DROOT='/home/wagner/work/cm3' && cm3 -ship -DROOT='/home/wagner/work/cm3' +++ /bin/sh: /usr/local/cm3/bin/cm3: No such file or directory *** execution of failed *** birch [~/work/cm3] wagner % ls -l /home/wagner/work/cm3/m3-sys/cm3/LINUXLIBC6/cm3 -rwxr-xr-x 1 wagner 5906103 2007-12-16 23:26 /home/wagner/work/cm3/m3-sys/cm3/LINUXLIBC6/cm3* % ldd /home/wagner/work/cm3/m3-sys/cm3/LINUXLIBC6/cm3 /usr/bin/ldd: line 117: /home/wagner/work/cm3/m3-sys/cm3/LINUXLIBC6/cm3: No such file or directory ??? Looks like I need a break 8-/ Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Mon Dec 17 06:24:19 2007 From: jayk123 at hotmail.com (Jay) Date: Mon, 17 Dec 2007 05:24:19 +0000 Subject: [M3devel] Info about Jay Krell? Fwd: Uncaught bounce notification In-Reply-To: <20071216181059.8vpo9jtzijo8k0g8@mail.elegosoft.com> References: <20071216181059.8vpo9jtzijo8k0g8@mail.elegosoft.com> Message-ID: I know what the problem and I will fix shortly, maybe as early as Monday. The details won't interest anyone.. For now..jayk123 at hotmail.com. (not sure why they don't bounce 100%, but problems as of 12/15 were expected and I didn't act to prevent them..a policy changed after 15+ years...) - Jay > Date: Sun, 16 Dec 2007 18:10:59 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: [M3devel] Info about Jay Krell? Fwd: Uncaught bounce notification> > Hi,> > I wouldn't normally forward this to the list, but since Jay has been> such an eager contributor to cm3 on windows: does anybody know why> all his mail bounces and how he can be reached?> > Thanks,> > Olaf> > > Date: Sun, 16 Dec 2007 11:31:15 -0500 (EST)> Subject: Problems delivering your mail> From: MAILER-DAEMON at cornell.edu> To: m3devel-bounces at elegosoft.com> 2.1 unnamed [text/plain] 5.58 KB Download> I'm sorry, but we had problems delivering your mail.> The errors we encountered appear below. If you have any questions,> contact the Cornell Postmaster as .> Please include a copy of this message with your correspondence.> > --------> > The following addresses could not be found at all in our Directory.> Please make sure you have the correct address.> > jay.krell at cornell.edu> > --------> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ i?m is proud to present Cause Effect, a series about real people making a difference. http://im.live.com/Messenger/IM/MTV/?source=text_Cause_Effect -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Dec 17 12:03:31 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 17 Dec 2007 12:03:31 +0100 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/darwin In-Reply-To: <723A4C34-1B58-4F26-891C-45F764CAEEB5@cs.purdue.edu> References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> <28256359-D312-4D47-9A38-7A245D6AEAE5@cs.purdue.edu> <20071216233259.ukim9ntk6cw8gsgc@mail.elegosoft.com> <723A4C34-1B58-4F26-891C-45F764CAEEB5@cs.purdue.edu> Message-ID: <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> Quoting Tony Hosking : > A break is always good. :-) Hi again, after some hours of sleep I can report at least some success on my old Darwin installation. I've put the archives on our web server for public access, and would like to add some more. I still think a Darwin build on a newer system may be a good idea (we can offer both on our web pages), and we definitely need some for Linux (perhaps multiple distros, too, there?) Solaris and Darwin/i386 would be great, too, and NetBSD, and of course Windows. Mika offered to provide an archive for old FreeBSD distributions (4.x). So everybody who is willing to produce some installation archives, please let me know, and I'll make sure they get shipped to our server. Please note that for the scripts/make-bin-dist-min.sh to work, you need a sample configuration file in cm3/m3-sys/cm3/src/config/XXX, as the ones in cminstall/src/config must be processed by the installer first. Jay has removed the samples there a little bit too eagerly, but most where outdated anyway. To upgrade from an older compiler I have successfully used the upgrade.sh script. So the complete sequence to build a bootstrap on your favourite platform would be: 1. Check out the current CVS head 2. Copy your (working) configuration file to cm3/src/config/ 3. Adapt the installer configuration file if necessary in cminstall/src/config/. Make sure that all system libraries get dynamically linked, for instance. 4. scripts/upgrade.sh 5. scripts/make-bin-dist-min.sh Any help will be appreciated. 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 jayk123 at hotmail.com Tue Dec 18 08:56:24 2007 From: jayk123 at hotmail.com (Jay) Date: Tue, 18 Dec 2007 07:56:24 +0000 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc In-Reply-To: <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> <28256359-D312-4D47-9A38-7A245D6AEAE5@cs.purdue.edu> <20071216233259.ukim9ntk6cw8gsgc@mail.elegosoft.com> <723A4C34-1B58-4F26-891C-45F764CAEEB5@cs.purdue.edu> <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> Message-ID: Blech, so much duplication.. oops/sorry.I'll make a new Windows archive and put it in my user directory on m3.elegosoft.com. 64 bit integer support will have to wait. I assume we are in a "release push" here? I COULD if really necessary do about any x86 Linux (maybe x86 Solaris, don't think it is supported) or PowerPC Linux or PowerPC Darwin..in a virtual machine if nothing else.. > for Linux (perhaps multiple distros, too, there?) Oh for just a bit of compatibility... :) > 1. Check out the current CVS head> 2. Copy your (working) configuration file to cm3/src/config/> 3. Adapt the installer configuration file if necessary in> cminstall/src/config/. Make sure that all system libraries> get dynamically linked, for instance.> 4. scripts/upgrade.sh> 5. scripts/make-bin-dist-min.sh Hey! :) 1. Checkout current CVS head. 2. cminstall/src/config/NT386 should work for everyone. 3. ditto 4. scripts/win/upgrade.cmd 5. scripts/win/make-dist.cmd. I'm just being obnoxious. :) Oh btw, anyone want to make an executive decision on a minor detail? .zip or .tar.gz or .tar.bz2 or self expanding .zip in an .exe? make-dist.cmd is setup to make any of these. I don't know how to make a self expanding .tar.gz or .tar.bz2...though should be easy, perhaps not with the following feature: The .exes can either be run, or can be used as direct input to unzip, or renamed to .zip and probably opened with Windows Explorer. It's pretty neat. .tar.bz2 is always the smallest in my experience and that's what I left make-dist.cmd doing. .tar.gz is usually in the middle. .zip usually largest, though more efficient for extracting less than the whole archive -- the files are compressed individually instead of compressing the entire stream at once. Self expanding .zip adds a small fixed constant prefix. I wonder if cminstall can be "better" on Unix, comparable to it being gone on Windows, but I don't care. You know, either make it unnecessary or make it totally automatic. I know it tries to figure out the defaults. I don't know how correct it tends to be. Oh and then a really obvious obnoxious question is if we should be building .debs, .rpms, Mac .pkg/.img/.dmg etc.. Personally I don't mind the lowest tech current approach. Slackware anyone? :) (I used it in the Linux kernel 1.x time, which is when most of my Linux use ever was..) - Jay > Date: Mon, 17 Dec 2007 12:03:31 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> CC: m3-support at elegosoft.com; admins at elegosoft.com> Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/darwin> > Quoting Tony Hosking :> > A break is always good. :-)> > Hi again,> > after some hours of sleep I can report at least some success on> my old Darwin installation. I've put the archives on our web server> for public access, and would like to add some more.> > I still think a Darwin build on a newer system may be a good idea (we> can offer both on our web pages), and we definitely need some> for Linux (perhaps multiple distros, too, there?)> Solaris and Darwin/i386 would be great, too, and NetBSD, and of> course Windows. Mika offered to provide an archive for old FreeBSD> distributions (4.x).> > So everybody who is willing to produce some installation archives,> please let me know, and I'll make sure they get shipped to our> server.> > Please note that for the scripts/make-bin-dist-min.sh to work,> you need a sample configuration file in cm3/m3-sys/cm3/src/config/XXX,> as the ones in cminstall/src/config must be processed by the installer> first. Jay has removed the samples there a little bit too eagerly,> but most where outdated anyway.> > To upgrade from an older compiler I have successfully used the> upgrade.sh script. So the complete sequence to build a bootstrap> on your favourite platform would be:> > 1. Check out the current CVS head> 2. Copy your (working) configuration file to cm3/src/config/> 3. Adapt the installer configuration file if necessary in> cminstall/src/config/. Make sure that all system libraries> get dynamically linked, for instance.> 4. scripts/upgrade.sh> 5. scripts/make-bin-dist-min.sh> > Any help will be appreciated.> > 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> _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Dec 18 09:01:19 2007 From: jayk123 at hotmail.com (Jay) Date: Tue, 18 Dec 2007 08:01:19 +0000 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc In-Reply-To: <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> <28256359-D312-4D47-9A38-7A245D6AEAE5@cs.purdue.edu> <20071216233259.ukim9ntk6cw8gsgc@mail.elegosoft.com> <723A4C34-1B58-4F26-891C-45F764CAEEB5@cs.purdue.edu> <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> Message-ID: Strange that seemed to have gotten truncated.. I wonder if cminstall can be "better" on Unix, comparable to it being gone on Windows, but I don't care.You know, either make it unnecessary or make it totally automatic. I know it tries to figure out the defaults. I don't know how correct it tends to be. Oh and then a really obvious obnoxious question is if we should be building .debs, .rpms, Mac .pkg/.img/.dmg etc..Personally I don't mind the lowest tech current approach. Slackware anyone? :) (I used it in the Linux kernel 1.x time, which is when most of my Linux use ever was..) - Jay From: jayk123 at hotmail.com _________________________________________________________________ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_122007 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Dec 18 10:00:03 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 18 Dec 2007 10:00:03 +0100 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc In-Reply-To: References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> <28256359-D312-4D47-9A38-7A245D6AEAE5@cs.purdue.edu> <20071216233259.ukim9ntk6cw8gsgc@mail.elegosoft.com> <723A4C34-1B58-4F26-891C-45F764CAEEB5@cs.purdue.edu> <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> Message-ID: <20071218100003.12irq679c4o404go@mail.elegosoft.com> Quoting Jay : > 64 bit integer support will have to wait. As long as the binary does compile the current code base, it will be OK, I think. > I assume we are in a "release push" here? No, this is not really a release, I just had the impression that some current snapshots were required. > I COULD if really necessary do about any x86 Linux (maybe x86 > Solaris, don't think it is supported) or PowerPC Linux or PowerPC > Darwin..in a virtual machine if nothing else.. I think PowerPC Linux would be great, if you find the time. I don't know of many people who could build that. >> for Linux (perhaps multiple distros, too, there?) > Oh for just a bit of compatibility... :) I've done a build on Debian now. > Oh btw, anyone want to make an executive decision on a minor detail? > .zip or .tar.gz or .tar.bz2 or self expanding .zip in an .exe? > make-dist.cmd is setup to make any of these. > I don't know how to make a self expanding .tar.gz or > .tar.bz2...though should be easy, perhaps not with the following > feature: > The .exes can either be run, or can be used as direct input to > unzip, or renamed to .zip and probably opened with Windows Explorer. > It's pretty neat. > .tar.bz2 is always the smallest in my experience and that's what > I left make-dist.cmd doing. > .tar.gz is usually in the middle. > .zip usually largest, though more efficient for extracting less > than the whole archive -- the files are compressed individually > instead of compressing the entire stream at once. > Self expanding .zip adds a small fixed constant prefix. I'm fine with any of these. Since Windows does seem to use other approaches and conventions in most aspects anyway, we should just go with what is easiest for beginners. What would you suggest? Self-extracting .exe? > I wonder if cminstall can be "better" on Unix, comparable to it > being gone on Windows, but I don't care. No, it's not really better on Unix, but it's better than nothing for many, and it takes efforts to change or improve it (including all documentation), which nobody seems interested to invest. > You know, either make it unnecessary or make it totally automatic. I > know it tries to figure out the defaults. I don't know how correct > it tends to be. Making such things completely automatic on many different target platform always ends in unmanageable efforts for small teams in my experience. CM3 has no resources for this I'm afraid. > Oh and then a really obvious obnoxious question is if we should be > building .debs, .rpms, Mac .pkg/.img/.dmg etc.. This again is the question who wants to maintain all that stuff. IMO it's OK if we have special support contributed for this or that target, but nobody ever showed real interest in maintaining such support through several release cycles. > Personally I don't mind the lowest tech current approach. Slackware > anyone? :) (I used it in the Linux kernel 1.x time, which is when > most of my Linux use ever was..) I tend to agree that low-tech in the installation area may be appropriate for CM3 ;-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Tue Dec 18 10:21:24 2007 From: jayk123 at hotmail.com (Jay) Date: Tue, 18 Dec 2007 09:21:24 +0000 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc In-Reply-To: <20071218100003.12irq679c4o404go@mail.elegosoft.com> References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> <28256359-D312-4D47-9A38-7A245D6AEAE5@cs.purdue.edu> <20071216233259.ukim9ntk6cw8gsgc@mail.elegosoft.com> <723A4C34-1B58-4F26-891C-45F764CAEEB5@cs.purdue.edu> <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> <20071218100003.12irq679c4o404go@mail.elegosoft.com> Message-ID: > > 64 bit integer support will have to wait. > As long as the binary does compile the current code base, it will be OK, > I think. It does. > I think PowerPC Linux would be great, if you find the time. I don't> know of many people who could build that. Ok. Um..gotta wonder what people use here...Mandrake, OpenSuse, YellowDog, Fedora... actually given my opinion of PowerPC and Linux, I bet none. Maybe just AIX. :) (Haven't used it myself.) > > .zip or .tar.gz or .tar.bz2 or self expanding .zip in an .exe?> > I'm fine with any of these. Since Windows does seem to use other> approaches and conventions in most aspects anyway, we should just> go with what is easiest for beginners. What would you suggest?> Self-extracting .exe? Ah. Good point, know the audience. Well, I think a non self expanding .zip might be "best". The self expanding .exes I have made are console apps. The user must be comfortable with the command line (IDE integration anyone? :)) The .zip can be expanded with the builtin support or with unzip. .zip has that small advantage of "built in" support in the gui. > Making such things completely automatic on many different target platform Sounds like a job for Autoconf, eh? Actually I have experimented with Autoconf-ish sorts of stuff on Windows. If you know the local scripting language and even if that language is like 10% of what it should be, not difficult. (That is, cmd kind of stinks, but it is good enough; and on Windows the right answer is probably VBScript or JScript. They are on pretty much every machine now and are very usable from the command line, not just the browser. Soon "PowerShell"..) Thing is, I don't know Bourne shell scripting. I guess these days you could use Perl. It's everywhere and I know it well enough. Of course you still need to know how to answer the questions in an automated fashion. REALLY I have to say, I've been using Perl so much the past few years, I'm kind of torn on static compilation to native code anyway. You know, this stuff could be in Modula-3 or Quake, but Perl suffices plenty...and then you start to realize that it suffices for a heck of a lot of stuff.. I did start some autoconfish-for-Windows stuff in Quake too. :) See..there's this metapoint, metaquestion that I've been obsessing over for years...some languages really do try to be the only language you need for any task -- Java, C, C++, C#, Modula-3 -- are good examples. And then when you find them too heavyweight and start using "scripts", you start to wonder, and when those "scripts" perf and scale just fine, you start to wonder.. Many "scripting" languages are obviously no good, but some seem perhaps good enough. An example of "bad" is Tcl with its ridiculous string-centricity, how braces might LOOK like a scoping mechanism a la C and C++, but they are really a hacky escaping mechanism... cmd is also too string-centric among other things (cmd is much better than people realize, but also seriously flawed). But Perl and probably Ruby and Python really seem to be on to something in terms of "general purpose" programming languages without a "build" step. Heck, I believe Red Hat/Fedora setup is written in Python.. and there's a book out there on linkers and loaders and .obj/.exe formats where the guy developers a linker in Perl. I think that says something..something positive. - Jay _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Dec 18 12:14:23 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 18 Dec 2007 12:14:23 +0100 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc In-Reply-To: References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> <28256359-D312-4D47-9A38-7A245D6AEAE5@cs.purdue.edu> <20071216233259.ukim9ntk6cw8gsgc@mail.elegosoft.com> <723A4C34-1B58-4F26-891C-45F764CAEEB5@cs.purdue.edu> <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> <20071218100003.12irq679c4o404go@mail.elegosoft.com> Message-ID: <20071218121423.6xkl81jou88g8kc4@mail.elegosoft.com> Quoting Jay : >> > .zip or .tar.gz or .tar.bz2 or self expanding .zip in an .exe?> > >> I'm fine with any of these. Since Windows does seem to use other> >> approaches and conventions in most aspects anyway, we should just> >> go with what is easiest for beginners. What would you suggest?> >> Self-extracting .exe? > Ah. Good point, know the audience. > Well, I think a non self expanding .zip might be "best". > The self expanding .exes I have made are console apps. > The user must be comfortable with the command line (IDE integration > anyone? :)) > The .zip can be expanded with the builtin support or with unzip. > .zip has that small advantage of "built in" support in the gui. > > Making such things completely automatic on many different target platform OK, let it be zip then. > Sounds like a job for Autoconf, eh? > Actually I have experimented with Autoconf-ish sorts of stuff on Windows. > If you know the local scripting language and even if that language > is like 10% of what it should be, not difficult. > (That is, cmd kind of stinks, but it is good enough; and on Windows > the right answer is probably VBScript or JScript. They are on pretty > much every machine now and are very usable from the command line, > not just the browser. Soon "PowerShell"..) > Thing is, I don't know Bourne shell scripting. > I guess these days you could use Perl. It's everywhere and I know it > well enough. > Of course you still need to know how to answer the questions in an > automated fashion. Autoconf needs to be adapted to changes in the platforms, too. I'm not against it, it's just becoming a maintenance problem soon. > REALLY I have to say, I've been using Perl so much the past few > years, I'm kind of torn on static compilation to native code anyway. > You know, this stuff could be in Modula-3 or Quake, but Perl > suffices plenty...and then you start to realize that it suffices for > a heck of a lot of stuff.. > I did start some autoconfish-for-Windows stuff in Quake too. :) I would not want to become Perl or anything else to become another prerequisite for CM3 installation. > See..there's this metapoint, metaquestion that I've been obsessing > over for years...some languages really do try to be the only > language you need for any task -- Java, C, C++, C#, Modula-3 -- are > good examples. And then when you find them too heavyweight and start > using "scripts", you start to wonder, and when those "scripts" perf > and scale just fine, you start to wonder.. Many "scripting" > languages are obviously no good, but some seem perhaps good enough. > An example of "bad" is Tcl with its ridiculous string-centricity, > how braces might LOOK like a scoping mechanism a la C and C++, but > they are really a hacky escaping mechanism... cmd is also too > string-centric among other things (cmd is much better than people > realize, but also seriously flawed). But Perl and probably Ruby and > Python really seem to be on to something in terms of "general > purpose" programming languages without a "build" step. Heck, I > believe Red Hat/Fedora setup is written in Python.. and there's a > book out there on linkers and loaders and .obj/.exe formats where > the guy developers a linker in Perl. I think that says > something..something positive. In my opinion there's no language that suits every need. Modula-3 is great for programming large systems and building reusable abstraction. Perl tends to become difficult to read (Write Once Read Never :). Python is really good for a scripting language (we use it a lot at Elego), but should not be needed as prerequisite for CM3 either. Bourne Shell is POSIX and should exist everywhere (with the exception of Windows, which never had a really working POSIX subsystem, but you can easily install Cygwin there via a GUI). Standard POSIX (or Windows) command line tools would be the level of prerequisites I'd accept. Everything else should be discussed here and well considered before introduced. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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.caltech.edu Tue Dec 18 13:38:21 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 18 Dec 2007 04:38:21 -0800 Subject: [M3devel] Unix signals and Modula-3... Message-ID: <200712181238.lBICcL8s052879@camembert.async.caltech.edu> Hello everyone, I am in the process of bootstrapping the CVS head of CM3 on an old FreeBSD-4.11 system, and at one point, when I replaced the old cm3 with the new cm3, the compiler got slower. Not a little bit slower, mind you, but about 10x slower. I remember pointing this out to the m3devel list... oh it must have been three or four years ago; one of our grad students at Caltech (Karl Papadantonakis, also author of the caltech-parser) was the first to notice what was going on. It has to do with Process.Wait. (From ProcessPosix.m3.) To repeat what I said a few years ago, the problem lies here: CONST Delay = 0.1D0; BEGIN IF NOT p.waitOk THEN RAISE WaitAlreadyCalled END; p.waitOk := FALSE; (* By rights, the SchedulerPosix interface should have a WaitPID procedure that is integrated with the thread scheduler. *) LOOP result := Uexec.waitpid(p.pid, ADR(statusT), Uexec.WNOHANG); IF result # 0 THEN EXIT END; Thread.Pause(Delay) END; <* ASSERT result > 0 *> In other words: if Process.Wait is called before the child process is done, then the thread pauses 0.1 seconds. In our local version of m3build, we duplicate the Wait code and set the Delay to 0.0. That's OK in a compiler, but it's not OK in general, because you would chew up the CPU on a machine that was doing a lot of long-term waiting. The problem is that the fix that I suggested way back when requires messing with Unix signals (catching SIGC[H]LD instead of using waitpid), which is why I never submitted a fix to the repository, because I am not sure what such a fix might interact with. It seems to me that the correct way of dealing with Unix signals is to have a single thread that talks to the Unix system, registers signal handlers, and takes care, via some object-oriented mechanism, of calling back any M3 threads that are interested in the signals. Would such a thing be possible? Where are signals used in the system today? Mika From mika at async.caltech.edu Tue Dec 18 13:55:15 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 18 Dec 2007 04:55:15 -0800 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/darwin In-Reply-To: Your message of "Mon, 17 Dec 2007 12:03:31 +0100." <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> Message-ID: <200712181255.lBICtFbG053659@camembert.async.caltech.edu> Hi Olaf, I'm sorry to say there is a bit of a problem with your bootstrap for FreeBSD. FreeBSD is beautifully *backward*-compatible, but it's not *forward*-compatible (it may be within a major release, but it's not generally forward-compatible across major releases). The distribution you built on 6.3-PRERELEASE will work for sure on 6.x (x>=3), may work on 6.x (x<3), and will almost certainly not work on y.x (y<6). To remedy this I built a bootstrap on 4.11. It is located at http://www.async.caltech.edu/~mika/cm3-min-POSIX-FreeBSD4-d5.5.0.tgz This compiler should work on pretty much any FreeBSD 4.x, 5.x, and possibly also 6.x. I have to say that it was a bit of an ordeal. I had problems from an old cm3.cfg (mine just never seems to get upgraded right), with -g instead of -gstabs+. I also had two sets of problems stemming from LONGINT: first, of course, my old compiler didn't know what LONGINT was so I searched through my email and indeed I found something from Tony referring to building a bootstrap on NT386 from which I could infer what to do: one has to check out a "mixed" repository mixing the "devel_LONGINT_start" tagged sources with the CVS head. The problems with Int64.i3 and Long.m3 that I think we've seen on other platforms reared their ugly heads here too (although these may have been due to my -g issues, i.e., not having an up-to-date back-end?) In short, in order to build a bootstrap from a pre-LONGINT compiler at the moment, you have to be an expert at this, pretty much, you have to remember approximately where in the mailing list archive the answers are, and I would say it's a good chance that 100% of the scripts that purport to be able to do things like bootstrap cm3, well, they don't work at all. I don't even want to think about bootstrapping CM3 with PM3 or SRC M3...(I think there are systems for which some of those are all that's available?) Mika P.S. I checked in a little bugfix (C++ism removal) for m3gdb as part of this. Olaf Wagner writes: >Quoting Tony Hosking : >> A break is always good. :-) > >Hi again, > >after some hours of sleep I can report at least some success on >my old Darwin installation. I've put the archives on our web server >for public access, and would like to add some more. > >I still think a Darwin build on a newer system may be a good idea (we >can offer both on our web pages), and we definitely need some >for Linux (perhaps multiple distros, too, there?) >Solaris and Darwin/i386 would be great, too, and NetBSD, and of >course Windows. Mika offered to provide an archive for old FreeBSD >distributions (4.x). > >So everybody who is willing to produce some installation archives, >please let me know, and I'll make sure they get shipped to our >server. > >Please note that for the scripts/make-bin-dist-min.sh to work, >you need a sample configuration file in cm3/m3-sys/cm3/src/config/XXX, >as the ones in cminstall/src/config must be processed by the installer >first. Jay has removed the samples there a little bit too eagerly, >but most where outdated anyway. > >To upgrade from an older compiler I have successfully used the >upgrade.sh script. So the complete sequence to build a bootstrap >on your favourite platform would be: > > 1. Check out the current CVS head > 2. Copy your (working) configuration file to cm3/src/config/ > 3. Adapt the installer configuration file if necessary in > cminstall/src/config/. Make sure that all system libraries > get dynamically linked, for instance. 4. scripts/upgrade.sh > 5. scripts/make-bin-dist-min.sh > >Any help will be appreciated. > >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 wagner at elegosoft.com Tue Dec 18 14:52:15 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 18 Dec 2007 14:52:15 +0100 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/darwin In-Reply-To: <200712181255.lBICtFbG053659@camembert.async.caltech.edu> References: <200712181255.lBICtFbG053659@camembert.async.caltech.edu> Message-ID: <20071218145215.a9btkok1wkokg04s@mail.elegosoft.com> Quoting Mika Nystrom : > > Hi Olaf, > > I'm sorry to say there is a bit of a problem with your bootstrap for > FreeBSD. FreeBSD is beautifully *backward*-compatible, but it's not > *forward*-compatible (it may be within a major release, but it's not > generally forward-compatible across major releases). The distribution > you built on 6.3-PRERELEASE will work for sure on 6.x (x>=3), may work > on 6.x (x<3), and will almost certainly not work on y.x (y<6). To > remedy this I built a bootstrap on 4.11. It is located at > > http://www.async.caltech.edu/~mika/cm3-min-POSIX-FreeBSD4-d5.5.0.tgz > > This compiler should work on pretty much any FreeBSD 4.x, 5.x, and > possibly also 6.x. I was afraid that there is no forward compatibility. So it's great that we've got a 4.11 build, I'll add it to our site this evening. I don't think anybody will still use any older versions. > I have to say that it was a bit of an ordeal. I had problems from > an old cm3.cfg (mine just never seems to get upgraded right), with > -g instead of -gstabs+. I also had two sets of problems stemming > from LONGINT: first, of course, my old compiler didn't know what > LONGINT was so I searched through my email and indeed I found > something from Tony referring to building a bootstrap on NT386 from > which I could infer what to do: one has to check out a "mixed" > repository mixing the "devel_LONGINT_start" tagged sources with the > CVS head. The problems with Int64.i3 and Long.m3 that I think we've > seen on other platforms reared their ugly heads here too (although > these may have been due to my -g issues, i.e., not having an > up-to-date back-end?) > > In short, in order to build a bootstrap from a pre-LONGINT compiler > at the moment, you have to be an expert at this, pretty much, you > have to remember approximately where in the mailing list archive > the answers are, and I would say it's a good chance that 100% of > the scripts that purport to be able to do things like bootstrap > cm3, well, they don't work at all. I don't even want to think about > bootstrapping CM3 with PM3 or SRC M3...(I think there are systems > for which some of those are all that's available?) I thought that the upgrade.sh script would take care of the pre-LONGINT / LONGINT transition, at least it worked for me on FreeBSD. At least if you start with a 5.4 release CM3. Outdated config files are of course always nasty; FreeBSD itself has complex support in form of the mergemaster utilty for its own upgrades for these problems. I'm afraid we'll not easily reach this level in CM3. The bootstrap scripts for CM3 with PM3 or even SRC M3 are from the beginning of the open source CM3 distribution; they did work at some point in time, but have not been used since. Perhaps they should rather be deleted or moved to an old-stuff directory. Sorry for all the inconveniences, but you seem to have coped well ;-) Thank you very much, Olaf > Mika > > P.S. I checked in a little bugfix (C++ism removal) for m3gdb as part > of this. -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Dec 18 15:17:03 2007 From: jay.krell at cornell.edu (Jay) Date: Tue, 18 Dec 2007 14:17:03 +0000 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/ In-Reply-To: <20071218145215.a9btkok1wkokg04s@mail.elegosoft.com> References: <200712181255.lBICtFbG053659@camembert.async.caltech.edu> <20071218145215.a9btkok1wkokg04s@mail.elegosoft.com> Message-ID: new Windows builds in ~jkrell on modula3.elegosoft.com from current CVS (ie: a different checkout than where I have edits): % ls -ltotal 4480-rw------- 1 jkrell jkrell 882018 2007-12-18 15:04 cm3-min-WIN32-NT386-d5.5.0-symbols.zip-rw------- 1 jkrell jkrell 3679897 2007-12-18 15:05 cm3-min-WIN32-NT386-d5.5.0.zip Windows /might/ have it easy with LONGINT, however Windows still has it tricky, and maybe not easy, maybe the same trickiness. In particular, what you do is: get an existing binary release That gives you cm3 and a pkg repository with m3core and libm3. buildship ONLY cm3 and upgrade-compiler, since ship of cm3 doesn't actually do anything perhaps, at least on Windows where the file is in use And then, after having built a new compiler, go and build everything else with it. "Normally" you might build things from the bottom of a dependency graph and on up -- m3core, libm3, cm3. However in this case you must stick with the old m3core and libm3 and only build cm3. The current m3core/libm3 cannot be built with an old compiler, but an old compiler can build a new compiler. upgrade.cmd automates this and I suspect upgrade.sh does as well. I'll be able to do Mac OS X 10.4 builds before Linux PowerPC, but should get to Linux PowerPC in a few days. Perl can written in a readable maintainable fashion, really. The bigger "problem" is regular expressions -- with great power/density comes great responsibility.. There is the /x flag to make them able to take comments, but it is badly flawed in that comments confuse the parser. It's a case of regexps being overly woven into the syntax. my $re = RegExp->new("..") sould have sufficed without messing up the syntax. - Jay > Date: Tue, 18 Dec 2007 14:52:15 +0100> From: wagner at elegosoft.com> To: mika at async.caltech.edu> CC: m3devel at elegosoft.com; mika at camembert.async.caltech.edu> Subject: Re: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/darwin> > Quoting Mika Nystrom :> > >> > Hi Olaf,> >> > I'm sorry to say there is a bit of a problem with your bootstrap for> > FreeBSD. FreeBSD is beautifully *backward*-compatible, but it's not> > *forward*-compatible (it may be within a major release, but it's not> > generally forward-compatible across major releases). The distribution> > you built on 6.3-PRERELEASE will work for sure on 6.x (x>=3), may work> > on 6.x (x<3), and will almost certainly not work on y.x (y<6). To> > remedy this I built a bootstrap on 4.11. It is located at> >> > http://www.async.caltech.edu/~mika/cm3-min-POSIX-FreeBSD4-d5.5.0.tgz> >> > This compiler should work on pretty much any FreeBSD 4.x, 5.x, and> > possibly also 6.x.> > I was afraid that there is no forward compatibility. So it's> great that we've got a 4.11 build, I'll add it to our site this evening.> I don't think anybody will still use any older versions.> > > I have to say that it was a bit of an ordeal. I had problems from> > an old cm3.cfg (mine just never seems to get upgraded right), with> > -g instead of -gstabs+. I also had two sets of problems stemming> > from LONGINT: first, of course, my old compiler didn't know what> > LONGINT was so I searched through my email and indeed I found> > something from Tony referring to building a bootstrap on NT386 from> > which I could infer what to do: one has to check out a "mixed"> > repository mixing the "devel_LONGINT_start" tagged sources with the> > CVS head. The problems with Int64.i3 and Long.m3 that I think we've> > seen on other platforms reared their ugly heads here too (although> > these may have been due to my -g issues, i.e., not having an> > up-to-date back-end?)> >> > In short, in order to build a bootstrap from a pre-LONGINT compiler> > at the moment, you have to be an expert at this, pretty much, you> > have to remember approximately where in the mailing list archive> > the answers are, and I would say it's a good chance that 100% of> > the scripts that purport to be able to do things like bootstrap> > cm3, well, they don't work at all. I don't even want to think about> > bootstrapping CM3 with PM3 or SRC M3...(I think there are systems> > for which some of those are all that's available?)> > I thought that the upgrade.sh script would take care of the> pre-LONGINT / LONGINT transition, at least it worked for me> on FreeBSD. At least if you start with a 5.4 release CM3.> > Outdated config files are of course always nasty; FreeBSD itself> has complex support in form of the mergemaster utilty for its> own upgrades for these problems. I'm afraid we'll not easily reach> this level in CM3.> > The bootstrap scripts for CM3 with PM3 or even SRC M3 are from the> beginning of the open source CM3 distribution; they did work at> some point in time, but have not been used since. Perhaps they should> rather be deleted or moved to an old-stuff directory.> > Sorry for all the inconveniences, but you seem to have coped well ;-)> > Thank you very much,> > Olaf> > Mika> >> > P.S. I checked in a little bugfix (C++ism removal) for m3gdb as part> > of this.> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. http://www.xbox.com/en-US/hardware/wheretobuy/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Tue Dec 18 15:20:17 2007 From: jayk123 at hotmail.com (Jay) Date: Tue, 18 Dec 2007 14:20:17 +0000 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/ In-Reply-To: References: <200712181255.lBICtFbG053659@camembert.async.caltech.edu> <20071218145215.a9btkok1wkokg04s@mail.elegosoft.com> Message-ID: ps: speaking of pre-reqs..m3-win/import-libs/m3makefile has a special hack to find my Visual C++ 2.0 toolset. In this way the distribution can support any Visual C++ toolset, probably. However this is not right in terms of letting anyone build a distribution. There remains an open question as to which toolsets to support, er, which Microsoft ones to support. I built this with 8.0. 9.0 has been released now. - Jay From: jay.krell at cornell.eduTo: wagner at elegosoft.com; mika at async.caltech.eduDate: Tue, 18 Dec 2007 14:17:03 +0000CC: m3devel at elegosoft.com; mika at camembert.async.caltech.eduSubject: Re: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/ new Windows builds in ~jkrell on modula3.elegosoft.com from current CVS (ie: a different checkout than where I have edits):% ls -ltotal 4480-rw------- 1 jkrell jkrell 882018 2007-12-18 15:04 cm3-min-WIN32-NT386-d5.5.0-symbols.zip-rw------- 1 jkrell jkrell 3679897 2007-12-18 15:05 cm3-min-WIN32-NT386-d5.5.0.zipWindows /might/ have it easy with LONGINT, however Windows still has it tricky, and maybe not easy, maybe the same trickiness. In particular, what you do is: get an existing binary release That gives you cm3 and a pkg repository with m3core and libm3. buildship ONLY cm3 and upgrade-compiler, since ship of cm3 doesn't actually do anything perhaps, at least on Windows where the file is in use And then, after having built a new compiler, go and build everything else with it. "Normally" you might build things from the bottom of a dependency graph and on up -- m3core, libm3, cm3.However in this case you must stick with the old m3core and libm3 and only build cm3.The current m3core/libm3 cannot be built with an old compiler, but an old compiler can build a new compiler. upgrade.cmd automates this and I suspect upgrade.sh does as well. I'll be able to do Mac OS X 10.4 builds before Linux PowerPC, but should get to Linux PowerPC in a few days. Perl can written in a readable maintainable fashion, really.The bigger "problem" is regular expressions -- with great power/density comes great responsibility..There is the /x flag to make them able to take comments, but it is badly flawed in that commentsconfuse the parser. It's a case of regexps being overly woven into the syntax.my $re = RegExp->new("..") sould have sufficed without messing up the syntax. - Jay > Date: Tue, 18 Dec 2007 14:52:15 +0100> From: wagner at elegosoft.com> To: mika at async.caltech.edu> CC: m3devel at elegosoft.com; mika at camembert.async.caltech.edu> Subject: Re: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/darwin> > Quoting Mika Nystrom :> > >> > Hi Olaf,> >> > I'm sorry to say there is a bit of a problem with your bootstrap for> > FreeBSD. FreeBSD is beautifully *backward*-compatible, but it's not> > *forward*-compatible (it may be within a major release, but it's not> > generally forward-compatible across major releases). The distribution> > you built on 6.3-PRERELEASE will work for sure on 6.x (x>=3), may work> > on 6.x (x<3), and will almost certainly not work on y.x (y<6). To> > remedy this I built a bootstrap on 4.11. It is located at> >> > http://www.async.caltech.edu/~mika/cm3-min-POSIX-FreeBSD4-d5.5.0.tgz> >> > This compiler should work on pretty much any FreeBSD 4.x, 5.x, and> > possibly also 6.x.> > I was afraid that there is no forward compatibility. So it's> great that we've got a 4.11 build, I'll add it to our site this evening.> I don't think anybody will still use any older versions.> > > I have to say that it was a bit of an ordeal. I had problems from> > an old cm3.cfg (mine just never seems to get upgraded right), with> > -g instead of -gstabs+. I also had two sets of problems stemming> > from LONGINT: first, of course, my old compiler didn't know what> > LONGINT was so I searched through my email and indeed I found> > something from Tony referring to building a bootstrap on NT386 from> > which I could infer what to do: one has to check out a "mixed"> > repository mixing the "devel_LONGINT_start" tagged sources with the> > CVS head. The problems with Int64.i3 and Long.m3 that I think we've> > seen on other platforms reared their ugly heads here too (although> > these may have been due to my -g issues, i.e., not having an> > up-to-date back-end?)> >> > In short, in order to build a bootstrap from a pre-LONGINT compiler> > at the moment, you have to be an expert at this, pretty much, you> > have to remember approximately where in the mailing list archive> > the answers are, and I would say it's a good chance that 100% of> > the scripts that purport to be able to do things like bootstrap> > cm3, well, they don't work at all. I don't even want to think about> > bootstrapping CM3 with PM3 or SRC M3...(I think there are systems> > for which some of those are all that's available?)> > I thought that the upgrade.sh script would take care of the> pre-LONGINT / LONGINT transition, at least it worked for me> on FreeBSD. At least if you start with a 5.4 release CM3.> > Outdated config files are of course always nasty; FreeBSD itself> has complex support in form of the mergemaster utilty for its> own upgrades for these problems. I'm afraid we'll not easily reach> this level in CM3.> > The bootstrap scripts for CM3 with PM3 or even SRC M3 are from the> beginning of the open source CM3 distribution; they did work at> some point in time, but have not been used since. Perhaps they should> rather be deleted or moved to an old-stuff directory.> > Sorry for all the inconveniences, but you seem to have coped well ;-)> > Thank you very much,> > Olaf> > Mika> >> > P.S. I checked in a little bugfix (C++ism removal) for m3gdb as part> > of this.> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. Get it now! _________________________________________________________________ The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. http://www.xbox.com/en-US/hardware/wheretobuy/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Dec 18 17:27:03 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 18 Dec 2007 11:27:03 -0500 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/darwin In-Reply-To: <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> <28256359-D312-4D47-9A38-7A245D6AEAE5@cs.purdue.edu> <20071216233259.ukim9ntk6cw8gsgc@mail.elegosoft.com> <723A4C34-1B58-4F26-891C-45F764CAEEB5@cs.purdue.edu> <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> Message-ID: I can provide a 32-bit x86-64(AMD64) build too. It is based on the existing 32-bit LINUXLIBC6, but needs a special cm3.cfg. On Dec 17, 2007, at 6:03 AM, Olaf Wagner wrote: > Quoting Tony Hosking : >> A break is always good. :-) > > Hi again, > > after some hours of sleep I can report at least some success on > my old Darwin installation. I've put the archives on our web server > for public access, and would like to add some more. > > I still think a Darwin build on a newer system may be a good idea (we > can offer both on our web pages), and we definitely need some > for Linux (perhaps multiple distros, too, there?) > Solaris and Darwin/i386 would be great, too, and NetBSD, and of > course Windows. Mika offered to provide an archive for old FreeBSD > distributions (4.x). > > So everybody who is willing to produce some installation archives, > please let me know, and I'll make sure they get shipped to our > server. > > Please note that for the scripts/make-bin-dist-min.sh to work, > you need a sample configuration file in cm3/m3-sys/cm3/src/config/XXX, > as the ones in cminstall/src/config must be processed by the installer > first. Jay has removed the samples there a little bit too eagerly, > but most where outdated anyway. > > To upgrade from an older compiler I have successfully used the > upgrade.sh script. So the complete sequence to build a bootstrap > on your favourite platform would be: > > 1. Check out the current CVS head > 2. Copy your (working) configuration file to cm3/src/config/ > 3. Adapt the installer configuration file if necessary in > cminstall/src/config/. Make sure that all system libraries > get dynamically linked, for instance. > 4. scripts/upgrade.sh > 5. scripts/make-bin-dist-min.sh > > Any help will be appreciated. > > 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 hosking at cs.purdue.edu Tue Dec 18 17:27:49 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 18 Dec 2007 11:27:49 -0500 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/darwin In-Reply-To: <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> <28256359-D312-4D47-9A38-7A245D6AEAE5@cs.purdue.edu> <20071216233259.ukim9ntk6cw8gsgc@mail.elegosoft.com> <723A4C34-1B58-4F26-891C-45F764CAEEB5@cs.purdue.edu> <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> Message-ID: <31F9814D-0409-4B57-BADD-C61DB4C4B14D@cs.purdue.edu> What does an installation archive consist of? I've not used an install archive for several years, since I just bootstrap from my existing installs. On Dec 17, 2007, at 6:03 AM, Olaf Wagner wrote: > Quoting Tony Hosking : >> A break is always good. :-) > > Hi again, > > after some hours of sleep I can report at least some success on > my old Darwin installation. I've put the archives on our web server > for public access, and would like to add some more. > > I still think a Darwin build on a newer system may be a good idea (we > can offer both on our web pages), and we definitely need some > for Linux (perhaps multiple distros, too, there?) > Solaris and Darwin/i386 would be great, too, and NetBSD, and of > course Windows. Mika offered to provide an archive for old FreeBSD > distributions (4.x). > > So everybody who is willing to produce some installation archives, > please let me know, and I'll make sure they get shipped to our > server. > > Please note that for the scripts/make-bin-dist-min.sh to work, > you need a sample configuration file in cm3/m3-sys/cm3/src/config/XXX, > as the ones in cminstall/src/config must be processed by the installer > first. Jay has removed the samples there a little bit too eagerly, > but most where outdated anyway. > > To upgrade from an older compiler I have successfully used the > upgrade.sh script. So the complete sequence to build a bootstrap > on your favourite platform would be: > > 1. Check out the current CVS head > 2. Copy your (working) configuration file to cm3/src/config/ > 3. Adapt the installer configuration file if necessary in > cminstall/src/config/. Make sure that all system libraries > get dynamically linked, for instance. > 4. scripts/upgrade.sh > 5. scripts/make-bin-dist-min.sh > > Any help will be appreciated. > > 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 hosking at cs.purdue.edu Tue Dec 18 17:33:52 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 18 Dec 2007 11:33:52 -0500 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc In-Reply-To: <20071218100003.12irq679c4o404go@mail.elegosoft.com> References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> <28256359-D312-4D47-9A38-7A245D6AEAE5@cs.purdue.edu> <20071216233259.ukim9ntk6cw8gsgc@mail.elegosoft.com> <723A4C34-1B58-4F26-891C-45F764CAEEB5@cs.purdue.edu> <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> <20071218100003.12irq679c4o404go@mail.elegosoft.com> Message-ID: On Dec 18, 2007, at 4:00 AM, Olaf Wagner wrote: > Quoting Jay : > >> 64 bit integer support will have to wait. > As long as the binary does compile the current code base, it will > be OK, > I think. Yes, currently INTEGER=LONGINT on Win32 platforms using the integrated backend. > >> I assume we are in a "release push" here? > No, this is not really a release, I just had the impression that > some current snapshots were required. > >> I COULD if really necessary do about any x86 Linux (maybe x86 >> Solaris, don't think it is supported) or PowerPC Linux or PowerPC >> Darwin..in a virtual machine if nothing else.. > > I think PowerPC Linux would be great, if you find the time. I don't > know of many people who could build that. > >>> for Linux (perhaps multiple distros, too, there?) >> Oh for just a bit of compatibility... :) > I've done a build on Debian now. > >> Oh btw, anyone want to make an executive decision on a minor detail? >> .zip or .tar.gz or .tar.bz2 or self expanding .zip in an .exe? >> make-dist.cmd is setup to make any of these. >> I don't know how to make a self expanding .tar.gz >> or .tar.bz2...though should be easy, perhaps not with the >> following feature: >> The .exes can either be run, or can be used as direct input to >> unzip, or renamed to .zip and probably opened with Windows Explorer. >> It's pretty neat. >> .tar.bz2 is always the smallest in my experience and that's >> what I left make-dist.cmd doing. >> .tar.gz is usually in the middle. >> .zip usually largest, though more efficient for extracting less >> than the whole archive -- the files are compressed individually >> instead of compressing the entire stream at once. >> Self expanding .zip adds a small fixed constant prefix. > > I'm fine with any of these. Since Windows does seem to use other > approaches and conventions in most aspects anyway, we should just > go with what is easiest for beginners. What would you suggest? > Self-extracting .exe? > >> I wonder if cminstall can be "better" on Unix, comparable to it >> being gone on Windows, but I don't care. > No, it's not really better on Unix, but it's better than nothing > for many, and it takes efforts to change or improve it (including all > documentation), which nobody seems interested to invest. > >> You know, either make it unnecessary or make it totally automatic. >> I know it tries to figure out the defaults. I don't know how >> correct it tends to be. > Making such things completely automatic on many different target > platform > always ends in unmanageable efforts for small teams in my experience. > CM3 has no resources for this I'm afraid. > >> Oh and then a really obvious obnoxious question is if we should >> be building .debs, .rpms, Mac .pkg/.img/.dmg etc.. > This again is the question who wants to maintain all that stuff. > IMO it's OK if we have special support contributed for this or that > target, but nobody ever showed real interest in maintaining such > support through several release cycles. > >> Personally I don't mind the lowest tech current approach. >> Slackware anyone? :) (I used it in the Linux kernel 1.x time, >> which is when most of my Linux use ever was..) > I tend to agree that low-tech in the installation area may be > appropriate for CM3 ;-) > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From wagner at elegosoft.com Tue Dec 18 20:05:01 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 18 Dec 2007 20:05:01 +0100 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/darwin In-Reply-To: <31F9814D-0409-4B57-BADD-C61DB4C4B14D@cs.purdue.edu> References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> <28256359-D312-4D47-9A38-7A245D6AEAE5@cs.purdue.edu> <20071216233259.ukim9ntk6cw8gsgc@mail.elegosoft.com> <723A4C34-1B58-4F26-891C-45F764CAEEB5@cs.purdue.edu> <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> <31F9814D-0409-4B57-BADD-C61DB4C4B14D@cs.purdue.edu> Message-ID: <20071218200501.3xmb0yuyha80g8gs@mail.elegosoft.com> Quoting Tony Hosking : > What does an installation archive consist of? I've not used an install > archive for several years, since I just bootstrap from my existing > installs. See far below. They are easily built by the script make-bin-dist-bin.sh within a standard CM3 workspace (step 5). >> 1. Check out the current CVS head >> 2. Copy your (working) configuration file to cm3/src/config/ >> 3. Adapt the installer configuration file if necessary in >> cminstall/src/config/. Make sure that all system libraries >> get dynamically linked, for instance. >> 4. scripts/upgrade.sh >> 5. scripts/make-bin-dist-min.sh This is the exact installation procedure invented by Critical Mass and implemented in cminstall (except for the registration key). These are the contents of a sample: % tar tzf cm3-min-POSIX-FreeBSD6-d5.5.0.tgz cminstall COPYRIGHT-CMASS system.tgz birch [~/cm3-dist] wagner % tar tzf system.tgz ./ ./bin/ ./doc/ ./elisp/ ./examples/ ./lib/ ./man/ ./pkg/ ./pkg/m3core/ ./pkg/libm3/ ./pkg/libm3/FreeBSD4/ ./pkg/libm3/src/ ./pkg/libm3/src/text/ ./pkg/libm3/src/os/ ./pkg/libm3/src/random/ ./pkg/libm3/src/uid/ ./pkg/libm3/src/rw/ ./pkg/libm3/src/fmtlex/ ./pkg/libm3/src/list/ ./pkg/libm3/src/sx/ ./pkg/libm3/src/types/ ./pkg/libm3/src/arith/ ./pkg/libm3/src/geometry/ ./pkg/libm3/src/statistics/ ./pkg/libm3/src/formatter/ ./pkg/libm3/src/params/ ./pkg/libm3/src/property/ ./pkg/libm3/src/table/ ./pkg/libm3/src/atom/ ./pkg/libm3/src/sortedtable/ ./pkg/libm3/src/sort/ ./pkg/libm3/src/sequence/ ./pkg/libm3/src/etimer/ ./pkg/libm3/src/bundleintf/ ./pkg/libm3/src/perftool/ ./pkg/libm3/src/pqueue/ ./pkg/libm3/src/sqrt/ ./pkg/libm3/src/pickle/ ./pkg/libm3/src/pickle/ver1/ ./pkg/libm3/src/pickle/ver2/ ./pkg/libm3/src/pickle/ver2/PklTipeMap.i3 ./pkg/libm3/src/pickle/ver2/PklTipeMap.m3 ./pkg/libm3/src/pickle/ver2/ConvertPacking.i3 ./pkg/libm3/src/pickle/ver2/ConvertPacking.m3 ./pkg/libm3/src/pickle/ver2/PklAction.i3 ./pkg/libm3/src/pickle/ver2/PickleRd.i3 ./pkg/libm3/src/pickle/ver2/PackingTypeCode.m3 ./pkg/libm3/src/pickle/ver2/PackingTypeCode.i3 ./pkg/libm3/src/pickle/ver2/BuiltinSpecials2.m3 ./pkg/libm3/src/pickle/ver2/BuiltinSpecials2.i3 ./pkg/libm3/src/pickle/ver2/Pickle2.i3 ./pkg/libm3/src/pickle/ver2/Pickle2.m3 ./pkg/libm3/src/pickle/ver2/PickleStubs.i3 ./pkg/libm3/src/pickle/ver2/PickleStubs.m3 ./pkg/libm3/src/pickle/ver1/Pickle.m3 ./pkg/libm3/src/pickle/ver1/Pickle.i3 ./pkg/libm3/src/pickle/ver1/BuiltinSpecials.m3 ./pkg/libm3/src/pickle/ver1/BuiltinSpecials.i3 ./pkg/libm3/src/sqrt/FloatExtras.mg ./pkg/libm3/src/sqrt/FloatExtras.ig ./pkg/libm3/src/sqrt/Sqrt.mg ./pkg/libm3/src/sqrt/Sqrt.ig ./pkg/libm3/src/pqueue/pqueue.tmpl ./pkg/libm3/src/pqueue/PQueue.ig ./pkg/libm3/src/pqueue/PQueue.mg ./pkg/libm3/src/pqueue/PQueueRep.ig ./pkg/libm3/src/perftool/Common/ ./pkg/libm3/src/perftool/POSIX/ ./pkg/libm3/src/perftool/POSIX/LowPerfTool.m3 ./pkg/libm3/src/perftool/Common/PerfTool.m3 ./pkg/libm3/src/perftool/Common/PerfTool.i3 ./pkg/libm3/src/perftool/Common/LowPerfTool.i3 ./pkg/libm3/src/perftool/Common/PerfComm.ig ./pkg/libm3/src/perftool/Common/PerfComm.mg ./pkg/libm3/src/bundleintf/bundle.tmpl ./pkg/libm3/src/bundleintf/Bundle.i3 ./pkg/libm3/src/bundleintf/Bundle.m3 ./pkg/libm3/src/bundleintf/BundleRep.i3 ./pkg/libm3/src/etimer/ETimer.i3 ./pkg/libm3/src/etimer/ETimer.m3 ./pkg/libm3/src/sequence/sequence.tmpl ./pkg/libm3/src/sequence/Sequence.mg ./pkg/libm3/src/sequence/Sequence.ig ./pkg/libm3/src/sequence/SequenceRep.ig ./pkg/libm3/src/sort/ArraySort.ig ./pkg/libm3/src/sort/ArraySort.mg ./pkg/libm3/src/sort/arraysort.tmpl ./pkg/libm3/src/sortedtable/sortedtable.tmpl ./pkg/libm3/src/sortedtable/SortedTable.mg ./pkg/libm3/src/sortedtable/SortedTable.ig ./pkg/libm3/src/atom/Atom.i3 ./pkg/libm3/src/atom/Atom.m3 ./pkg/libm3/src/table/table.tmpl ./pkg/libm3/src/table/Table.ig ./pkg/libm3/src/table/Table.mg ./pkg/libm3/src/property/Property.i3 ./pkg/libm3/src/property/Property.m3 ./pkg/libm3/src/property/PropertyV.i3 ./pkg/libm3/src/property/PropertyV.m3 ./pkg/libm3/src/property/MProperty.m3 ./pkg/libm3/src/property/MProperty.i3 ./pkg/libm3/src/property/PropertyF.i3 ./pkg/libm3/src/property/MPropertyF.i3 ./pkg/libm3/src/params/Env.m3 ./pkg/libm3/src/params/Env.i3 ./pkg/libm3/src/params/Params.m3 ./pkg/libm3/src/params/Params.i3 ./pkg/libm3/src/formatter/Formatter.m3 ./pkg/libm3/src/formatter/Formatter.i3 ./pkg/libm3/src/statistics/Stat.m3 ./pkg/libm3/src/statistics/Stat.i3 ./pkg/libm3/src/geometry/Axis.i3 ./pkg/libm3/src/geometry/Axis.m3 ./pkg/libm3/src/geometry/Interval.i3 ./pkg/libm3/src/geometry/Interval.m3 ./pkg/libm3/src/geometry/Point.m3 ./pkg/libm3/src/geometry/Point.i3 ./pkg/libm3/src/geometry/Rect.i3 ./pkg/libm3/src/geometry/Rect.m3 ./pkg/libm3/src/geometry/Transform.i3 ./pkg/libm3/src/geometry/Transform.m3 ./pkg/libm3/src/geometry/Path.m3 ./pkg/libm3/src/geometry/Path.i3 ./pkg/libm3/src/geometry/Region.i3 ./pkg/libm3/src/geometry/Region.m3 ./pkg/libm3/src/geometry/PolyRegion.i3 ./pkg/libm3/src/geometry/PolyRegion.m3 ./pkg/libm3/src/geometry/Trapezoid.i3 ./pkg/libm3/src/geometry/Trapezoid.m3 ./pkg/libm3/src/geometry/RegionRep.i3 ./pkg/libm3/src/geometry/PathPrivate.i3 ./pkg/libm3/src/arith/POSIX/ ./pkg/libm3/src/arith/POSIX/Math.i3 ./pkg/libm3/src/types/Integer.m3 ./pkg/libm3/src/types/Integer.i3 ./pkg/libm3/src/types/Refany.i3 ./pkg/libm3/src/types/Refany.m3 ./pkg/libm3/src/types/Boolean.i3 ./pkg/libm3/src/types/Boolean.m3 ./pkg/libm3/src/types/Char.m3 ./pkg/libm3/src/types/Char.i3 ./pkg/libm3/src/types/Int32.i3 ./pkg/libm3/src/types/Int32.m3 ./pkg/libm3/src/types/Int64.i3 ./pkg/libm3/src/types/Int64.m3 ./pkg/libm3/src/types/Longint.i3 ./pkg/libm3/src/types/Longint.m3 ./pkg/libm3/src/types/ASCII.i3 ./pkg/libm3/src/types/ASCII.m3 ./pkg/libm3/src/types/RealType.i3 ./pkg/libm3/src/types/RealType.m3 ./pkg/libm3/src/types/LongrealType.i3 ./pkg/libm3/src/types/LongrealType.m3 ./pkg/libm3/src/types/WideChar.i3 ./pkg/libm3/src/types/WideChar.m3 ./pkg/libm3/src/types/Unicode.m3 ./pkg/libm3/src/types/Unicode.i3 ./pkg/libm3/src/sx/Sx.m3 ./pkg/libm3/src/sx/Sx.i3 ./pkg/libm3/src/list/list.tmpl ./pkg/libm3/src/list/List.mg ./pkg/libm3/src/list/List.ig ./pkg/libm3/src/list/ListSort.mg ./pkg/libm3/src/list/ListSort.ig ./pkg/libm3/src/fmtlex/Fmt.m3 ./pkg/libm3/src/fmtlex/Fmt.i3 ./pkg/libm3/src/fmtlex/Lex.m3 ./pkg/libm3/src/fmtlex/Lex.i3 ./pkg/libm3/src/fmtlex/Scan.i3 ./pkg/libm3/src/fmtlex/Scan.m3 ./pkg/libm3/src/fmtlex/FmtBuf.m3 ./pkg/libm3/src/fmtlex/FmtBuf.i3 ./pkg/libm3/src/fmtlex/FmtBufF.i3 ./pkg/libm3/src/fmtlex/FmtBufTest.i3 ./pkg/libm3/src/rw/Rd.i3 ./pkg/libm3/src/rw/Rd.m3 ./pkg/libm3/src/rw/RdClass.i3 ./pkg/libm3/src/rw/UnsafeRd.i3 ./pkg/libm3/src/rw/Wr.i3 ./pkg/libm3/src/rw/Wr.m3 ./pkg/libm3/src/rw/WrClass.i3 ./pkg/libm3/src/rw/UnsafeWr.i3 ./pkg/libm3/src/rw/NullRd.m3 ./pkg/libm3/src/rw/NullRd.i3 ./pkg/libm3/src/rw/NullWr.m3 ./pkg/libm3/src/rw/NullWr.i3 ./pkg/libm3/src/rw/RdCopy.i3 ./pkg/libm3/src/rw/RdCopy.m3 ./pkg/libm3/src/rw/TextRd.i3 ./pkg/libm3/src/rw/TextRd.m3 ./pkg/libm3/src/rw/TextWr.m3 ./pkg/libm3/src/rw/TextWr.i3 ./pkg/libm3/src/rw/FileRd.i3 ./pkg/libm3/src/rw/FileRd.m3 ./pkg/libm3/src/rw/FileWr.i3 ./pkg/libm3/src/rw/FileWr.m3 ./pkg/libm3/src/rw/IO.m3 ./pkg/libm3/src/rw/IO.i3 ./pkg/libm3/src/rw/AutoFlushWr.m3 ./pkg/libm3/src/rw/AutoFlushWr.i3 ./pkg/libm3/src/rw/Stdio.m3 ./pkg/libm3/src/rw/Stdio.i3 ./pkg/libm3/src/rw/RdUtils.m3 ./pkg/libm3/src/rw/RdUtils.i3 ./pkg/libm3/src/rw/RdExtras.m3 ./pkg/libm3/src/rw/RdExtras.i3 ./pkg/libm3/src/rw/MsgRd.i3 ./pkg/libm3/src/rw/MsgWr.i3 ./pkg/libm3/src/uid/Common/ ./pkg/libm3/src/uid/POSIX/ ./pkg/libm3/src/uid/POSIX/MachineIDPosixC.i3 ./pkg/libm3/src/uid/POSIX/MachineIDPosixC.c ./pkg/libm3/src/uid/POSIX/MachineIDPosix.m3 ./pkg/libm3/src/uid/Common/TimeStamp.i3 ./pkg/libm3/src/uid/Common/TimeStamp.m3 ./pkg/libm3/src/uid/Common/Capability.i3 ./pkg/libm3/src/uid/Common/Capability.m3 ./pkg/libm3/src/uid/Common/Swap.i3 ./pkg/libm3/src/uid/Common/Swap.m3 ./pkg/libm3/src/uid/Common/MachineID.i3 ./pkg/libm3/src/uid/Common/TimeStampRep.i3 ./pkg/libm3/src/random/Common/ ./pkg/libm3/src/random/IEEE/ ./pkg/libm3/src/random/IEEE/RandomReal.m3 ./pkg/libm3/src/random/Common/Random.m3 ./pkg/libm3/src/random/Common/Random.i3 ./pkg/libm3/src/random/Common/RandomPerm.i3 ./pkg/libm3/src/random/Common/RandomPerm.m3 ./pkg/libm3/src/random/Common/RandomReal.i3 ./pkg/libm3/src/os/Common/ ./pkg/libm3/src/os/POSIX/ ./pkg/libm3/src/os/POSIX/OSConfig.i3 ./pkg/libm3/src/os/POSIX/OSErrorPosix.i3 ./pkg/libm3/src/os/POSIX/OSErrorPosix.m3 ./pkg/libm3/src/os/POSIX/FilePosix.i3 ./pkg/libm3/src/os/POSIX/FilePosix.m3 ./pkg/libm3/src/os/POSIX/FSPosix.m3 ./pkg/libm3/src/os/POSIX/PipePosix.m3 ./pkg/libm3/src/os/POSIX/PathnamePosix.m3 ./pkg/libm3/src/os/POSIX/ProcessPosix.m3 ./pkg/libm3/src/os/POSIX/SocketPosix.m3 ./pkg/libm3/src/os/POSIX/OSConfigPosix.m3 ./pkg/libm3/src/os/Common/OSError.i3 ./pkg/libm3/src/os/Common/File.i3 ./pkg/libm3/src/os/Common/RegularFile.m3 ./pkg/libm3/src/os/Common/RegularFile.i3 ./pkg/libm3/src/os/Common/Pipe.i3 ./pkg/libm3/src/os/Common/Pipe.m3 ./pkg/libm3/src/os/Common/Pathname.i3 ./pkg/libm3/src/os/Common/FS.i3 ./pkg/libm3/src/os/Common/FS.m3 ./pkg/libm3/src/os/Common/Process.i3 ./pkg/libm3/src/os/Common/Socket.m3 ./pkg/libm3/src/os/Common/Socket.i3 ./pkg/libm3/src/os/Common/Terminal.m3 ./pkg/libm3/src/os/Common/Terminal.i3 ./pkg/libm3/src/text/TextExtras.m3 ./pkg/libm3/src/text/TextExtras.i3 ./pkg/libm3/FreeBSD4/.M3EXPORTS ./pkg/libm3/FreeBSD4/libm3.so.5 ./pkg/libm3/FreeBSD4/libm3.so ./pkg/libm3/FreeBSD4/libm3.a ./pkg/libm3/FreeBSD4/libm3.m3x ./pkg/libm3/FreeBSD4/.M3WEB ./pkg/libm3/FreeBSD4/AtomList.m3 ./pkg/libm3/FreeBSD4/AtomList.i3 ./pkg/libm3/FreeBSD4/IntList.i3 ./pkg/libm3/FreeBSD4/IntList.m3 ./pkg/libm3/FreeBSD4/RefList.m3 ./pkg/libm3/FreeBSD4/RefList.i3 ./pkg/libm3/FreeBSD4/TextList.i3 ./pkg/libm3/FreeBSD4/TextList.m3 ./pkg/libm3/FreeBSD4/AtomListSort.i3 ./pkg/libm3/FreeBSD4/AtomListSort.m3 ./pkg/libm3/FreeBSD4/IntListSort.m3 ./pkg/libm3/FreeBSD4/IntListSort.i3 ./pkg/libm3/FreeBSD4/RefListSort.i3 ./pkg/libm3/FreeBSD4/RefListSort.m3 ./pkg/libm3/FreeBSD4/TextListSort.m3 ./pkg/libm3/FreeBSD4/TextListSort.i3 ./pkg/libm3/FreeBSD4/AtomAtomTbl.m3 ./pkg/libm3/FreeBSD4/AtomAtomTbl.i3 ./pkg/libm3/FreeBSD4/AtomIntTbl.i3 ./pkg/libm3/FreeBSD4/AtomIntTbl.m3 ./pkg/libm3/FreeBSD4/AtomRefTbl.m3 ./pkg/libm3/FreeBSD4/AtomRefTbl.i3 ./pkg/libm3/FreeBSD4/AtomTextTbl.i3 ./pkg/libm3/FreeBSD4/AtomTextTbl.m3 ./pkg/libm3/FreeBSD4/IntAtomTbl.i3 ./pkg/libm3/FreeBSD4/IntAtomTbl.m3 ./pkg/libm3/FreeBSD4/IntIntTbl.i3 ./pkg/libm3/FreeBSD4/IntIntTbl.m3 ./pkg/libm3/FreeBSD4/IntRefTbl.i3 ./pkg/libm3/FreeBSD4/IntRefTbl.m3 ./pkg/libm3/FreeBSD4/IntTextTbl.i3 ./pkg/libm3/FreeBSD4/IntTextTbl.m3 ./pkg/libm3/FreeBSD4/RefAtomTbl.m3 ./pkg/libm3/FreeBSD4/RefAtomTbl.i3 ./pkg/libm3/FreeBSD4/RefIntTbl.i3 ./pkg/libm3/FreeBSD4/RefIntTbl.m3 ./pkg/libm3/FreeBSD4/RefRefTbl.i3 ./pkg/libm3/FreeBSD4/RefRefTbl.m3 ./pkg/libm3/FreeBSD4/RefTextTbl.i3 ./pkg/libm3/FreeBSD4/RefTextTbl.m3 ./pkg/libm3/FreeBSD4/TextAtomTbl.m3 ./pkg/libm3/FreeBSD4/TextAtomTbl.i3 ./pkg/libm3/FreeBSD4/TextIntTbl.i3 ./pkg/libm3/FreeBSD4/TextIntTbl.m3 ./pkg/libm3/FreeBSD4/TextRefTbl.i3 ./pkg/libm3/FreeBSD4/TextRefTbl.m3 ./pkg/libm3/FreeBSD4/TextTextTbl.i3 ./pkg/libm3/FreeBSD4/TextTextTbl.m3 ./pkg/libm3/FreeBSD4/SortedAtomAtomTbl.m3 ./pkg/libm3/FreeBSD4/SortedAtomAtomTbl.i3 ./pkg/libm3/FreeBSD4/SortedAtomIntTbl.i3 ./pkg/libm3/FreeBSD4/SortedAtomIntTbl.m3 ./pkg/libm3/FreeBSD4/SortedAtomRefTbl.i3 ./pkg/libm3/FreeBSD4/SortedAtomRefTbl.m3 ./pkg/libm3/FreeBSD4/SortedAtomTextTbl.i3 ./pkg/libm3/FreeBSD4/SortedAtomTextTbl.m3 ./pkg/libm3/FreeBSD4/SortedIntAtomTbl.m3 ./pkg/libm3/FreeBSD4/SortedIntAtomTbl.i3 ./pkg/libm3/FreeBSD4/SortedIntIntTbl.i3 ./pkg/libm3/FreeBSD4/SortedIntIntTbl.m3 ./pkg/libm3/FreeBSD4/SortedIntRefTbl.m3 ./pkg/libm3/FreeBSD4/SortedIntRefTbl.i3 ./pkg/libm3/FreeBSD4/SortedIntTextTbl.i3 ./pkg/libm3/FreeBSD4/SortedIntTextTbl.m3 ./pkg/libm3/FreeBSD4/SortedRefAtomTbl.i3 ./pkg/libm3/FreeBSD4/SortedRefAtomTbl.m3 ./pkg/libm3/FreeBSD4/SortedRefIntTbl.i3 ./pkg/libm3/FreeBSD4/SortedRefIntTbl.m3 ./pkg/libm3/FreeBSD4/SortedRefRefTbl.m3 ./pkg/libm3/FreeBSD4/SortedRefRefTbl.i3 ./pkg/libm3/FreeBSD4/SortedRefTextTbl.i3 ./pkg/libm3/FreeBSD4/SortedRefTextTbl.m3 ./pkg/libm3/FreeBSD4/SortedTextAtomTbl.m3 ./pkg/libm3/FreeBSD4/SortedTextAtomTbl.i3 ./pkg/libm3/FreeBSD4/SortedTextIntTbl.m3 ./pkg/libm3/FreeBSD4/SortedTextIntTbl.i3 ./pkg/libm3/FreeBSD4/SortedTextRefTbl.i3 ./pkg/libm3/FreeBSD4/SortedTextRefTbl.m3 ./pkg/libm3/FreeBSD4/SortedTextTextTbl.m3 ./pkg/libm3/FreeBSD4/SortedTextTextTbl.i3 ./pkg/libm3/FreeBSD4/IntArraySort.i3 ./pkg/libm3/FreeBSD4/IntArraySort.m3 ./pkg/libm3/FreeBSD4/TextArraySort.i3 ./pkg/libm3/FreeBSD4/TextArraySort.m3 ./pkg/libm3/FreeBSD4/AtomSeq.i3 ./pkg/libm3/FreeBSD4/AtomSeq.m3 ./pkg/libm3/FreeBSD4/AtomSeqRep.i3 ./pkg/libm3/FreeBSD4/IntSeq.m3 ./pkg/libm3/FreeBSD4/IntSeq.i3 ./pkg/libm3/FreeBSD4/IntSeqRep.i3 ./pkg/libm3/FreeBSD4/RefSeq.i3 ./pkg/libm3/FreeBSD4/RefSeq.m3 ./pkg/libm3/FreeBSD4/RefSeqRep.i3 ./pkg/libm3/FreeBSD4/TextSeq.m3 ./pkg/libm3/FreeBSD4/TextSeq.i3 ./pkg/libm3/FreeBSD4/TextSeqRep.i3 ./pkg/libm3/FreeBSD4/AtomPQ.i3 ./pkg/libm3/FreeBSD4/AtomPQ.m3 ./pkg/libm3/FreeBSD4/AtomPQRep.i3 ./pkg/libm3/FreeBSD4/IntPQ.m3 ./pkg/libm3/FreeBSD4/IntPQ.i3 ./pkg/libm3/FreeBSD4/IntPQRep.i3 ./pkg/libm3/FreeBSD4/RefPQ.i3 ./pkg/libm3/FreeBSD4/RefPQ.m3 ./pkg/libm3/FreeBSD4/RefPQRep.i3 ./pkg/libm3/FreeBSD4/TextPQ.i3 ./pkg/libm3/FreeBSD4/TextPQ.m3 ./pkg/libm3/FreeBSD4/TextPQRep.i3 ./pkg/libm3/FreeBSD4/RealFloatExtras.m3 ./pkg/libm3/FreeBSD4/RealFloatExtras.i3 ./pkg/libm3/FreeBSD4/LongFloatExtras.i3 ./pkg/libm3/FreeBSD4/LongFloatExtras.m3 ./pkg/libm3/FreeBSD4/RealSqrt.i3 ./pkg/libm3/FreeBSD4/RealSqrt.m3 ./pkg/libm3/FreeBSD4/LongSqrt.i3 ./pkg/libm3/FreeBSD4/LongSqrt.m3 ./pkg/libm3/FreeBSD4/M3Config.i3 ./pkg/libm3/FreeBSD4/PklActionSeq.m3 ./pkg/libm3/FreeBSD4/PklActionSeq.i3 ./pkg/libm3/FreeBSD4/PklActionSeqRep.i3 ./pkg/libm3/FreeBSD4/PackingTbl.i3 ./pkg/libm3/FreeBSD4/PackingTbl.m3 ./pkg/m3core/FreeBSD4/ ./pkg/m3core/src/ ./pkg/m3core/src/Csupport/ ./pkg/m3core/src/runtime/ ./pkg/m3core/src/thread/ ./pkg/m3core/src/unix/ ./pkg/m3core/src/C/ ./pkg/m3core/src/float/ ./pkg/m3core/src/time/ ./pkg/m3core/src/convert/ ./pkg/m3core/src/text/ ./pkg/m3core/src/fingerprint/ ./pkg/m3core/src/main/ ./pkg/m3core/src/weakref/ ./pkg/m3core/src/word/ ./pkg/m3core/src/word/GenWord.ig ./pkg/m3core/src/word/GenWord.mg ./pkg/m3core/src/word/WordRep.i3 ./pkg/m3core/src/word/Word.m3 ./pkg/m3core/src/word/Word.i3 ./pkg/m3core/src/word/LongRep.i3 ./pkg/m3core/src/word/Long.i3 ./pkg/m3core/src/word/Long.m3 ./pkg/m3core/src/weakref/WeakRef.i3 ./pkg/m3core/src/weakref/WeakRef.m3 ./pkg/m3core/src/main/Main.i3 ./pkg/m3core/src/fingerprint/Fingerprint.i3 ./pkg/m3core/src/fingerprint/Fingerprint.m3 ./pkg/m3core/src/fingerprint/Poly.i3 ./pkg/m3core/src/fingerprint/Poly.m3 ./pkg/m3core/src/fingerprint/PolyBasis.m3 ./pkg/m3core/src/fingerprint/PolyBasis.i3 ./pkg/m3core/src/text/String8.i3 ./pkg/m3core/src/text/String8.m3 ./pkg/m3core/src/text/String16.m3 ./pkg/m3core/src/text/String16.i3 ./pkg/m3core/src/text/Text.i3 ./pkg/m3core/src/text/Text.m3 ./pkg/m3core/src/text/TextClass.i3 ./pkg/m3core/src/text/TextClass.m3 ./pkg/m3core/src/text/TextLiteral.m3 ./pkg/m3core/src/text/TextLiteral.i3 ./pkg/m3core/src/text/Text8.i3 ./pkg/m3core/src/text/Text8.m3 ./pkg/m3core/src/text/Text8Short.i3 ./pkg/m3core/src/text/Text8Short.m3 ./pkg/m3core/src/text/Text8CString.i3 ./pkg/m3core/src/text/Text8CString.m3 ./pkg/m3core/src/text/Text16.m3 ./pkg/m3core/src/text/Text16.i3 ./pkg/m3core/src/text/Text16Short.i3 ./pkg/m3core/src/text/Text16Short.m3 ./pkg/m3core/src/text/TextSub.i3 ./pkg/m3core/src/text/TextSub.m3 ./pkg/m3core/src/text/TextCat.m3 ./pkg/m3core/src/text/TextCat.i3 ./pkg/m3core/src/text/TextConv.i3 ./pkg/m3core/src/text/TextConv.m3 ./pkg/m3core/src/convert/CConvert.i3 ./pkg/m3core/src/convert/CConvert.m3 ./pkg/m3core/src/convert/Convert.i3 ./pkg/m3core/src/convert/Convert.m3 ./pkg/m3core/src/time/Common/ ./pkg/m3core/src/time/Portable/ ./pkg/m3core/src/time/POSIX/ ./pkg/m3core/src/time/POSIX/DateBsd.m3 ./pkg/m3core/src/time/POSIX/TimePosix.m3 ./pkg/m3core/src/time/POSIX/TimePosix.i3 ./pkg/m3core/src/time/Portable/TickPortable.m3 ./pkg/m3core/src/time/Common/Time.i3 ./pkg/m3core/src/time/Common/Tick.i3 ./pkg/m3core/src/time/Common/Date.i3 ./pkg/m3core/src/time/Common/FmtTime.i3 ./pkg/m3core/src/time/Common/FmtTime.m3 ./pkg/m3core/src/float/Common/ ./pkg/m3core/src/float/IEEE/ ./pkg/m3core/src/float/IEEE-le/ ./pkg/m3core/src/float/IEEE-default/ ./pkg/m3core/src/float/IEEE-default/FPU.i3 ./pkg/m3core/src/float/IEEE-default/FPU.m3 ./pkg/m3core/src/float/IEEE-default/FloatMode.i3 ./pkg/m3core/src/float/IEEE-default/FloatMode.m3 ./pkg/m3core/src/float/IEEE-le/RealRep.i3 ./pkg/m3core/src/float/IEEE-le/LongRealRep.i3 ./pkg/m3core/src/float/IEEE/RealFloat.m3 ./pkg/m3core/src/float/IEEE/LongFloat.m3 ./pkg/m3core/src/float/IEEE/ExtendedFloat.m3 ./pkg/m3core/src/float/IEEE/Real.i3 ./pkg/m3core/src/float/IEEE/LongReal.i3 ./pkg/m3core/src/float/IEEE/Extended.i3 ./pkg/m3core/src/float/Common/Float.ig ./pkg/m3core/src/float/Common/RealFloat.i3 ./pkg/m3core/src/float/Common/LongFloat.i3 ./pkg/m3core/src/float/Common/ExtendedFloat.i3 ./pkg/m3core/src/float/Common/IEEESpecial.m3 ./pkg/m3core/src/float/Common/IEEESpecial.i3 ./pkg/m3core/src/float/Common/Real.m3 ./pkg/m3core/src/float/Common/LongReal.m3 ./pkg/m3core/src/float/Common/Extended.m3 ./pkg/m3core/src/float/Common/DragonInt.i3 ./pkg/m3core/src/float/Common/DragonInt.m3 ./pkg/m3core/src/float/Common/DragonT.m3 ./pkg/m3core/src/float/Common/DragonT.i3 ./pkg/m3core/src/C/Common/ ./pkg/m3core/src/C/FreeBSD4/ ./pkg/m3core/src/C/32BITS/ ./pkg/m3core/src/C/32BITS/BasicCtypes.i3 ./pkg/m3core/src/C/FreeBSD4/Csetjmp.i3 ./pkg/m3core/src/C/FreeBSD4/Csignal.i3 ./pkg/m3core/src/C/FreeBSD4/Cstring.i3 ./pkg/m3core/src/C/FreeBSD4/Cstdio.i3 ./pkg/m3core/src/C/FreeBSD4/Cstdio.m3 ./pkg/m3core/src/C/FreeBSD4/CstdioC.c ./pkg/m3core/src/C/Common/Cerrno.i3 ./pkg/m3core/src/C/Common/Cstddef.i3 ./pkg/m3core/src/C/Common/Cstdlib.i3 ./pkg/m3core/src/C/Common/Ctypes.i3 ./pkg/m3core/src/C/Common/M3toC.i3 ./pkg/m3core/src/C/Common/M3toC.m3 ./pkg/m3core/src/C/Common/Cstdarg.m3 ./pkg/m3core/src/C/Common/Cstdarg.i3 ./pkg/m3core/src/C/Common/CerrnoC.c ./pkg/m3core/src/unix/freebsd-4/ ./pkg/m3core/src/unix/freebsd-4/Udir.i3 ./pkg/m3core/src/unix/freebsd-4/Uerror.i3 ./pkg/m3core/src/unix/freebsd-4/Uexec.i3 ./pkg/m3core/src/unix/freebsd-4/Ugrp.i3 ./pkg/m3core/src/unix/freebsd-4/Uin.i3 ./pkg/m3core/src/unix/freebsd-4/Uin.m3 ./pkg/m3core/src/unix/freebsd-4/Uipc.i3 ./pkg/m3core/src/unix/freebsd-4/Umman.i3 ./pkg/m3core/src/unix/freebsd-4/Umsg.m3 ./pkg/m3core/src/unix/freebsd-4/Umsg.i3 ./pkg/m3core/src/unix/freebsd-4/Unetdb.i3 ./pkg/m3core/src/unix/freebsd-4/Unetdb.m3 ./pkg/m3core/src/unix/freebsd-4/Unix.i3 ./pkg/m3core/src/unix/freebsd-4/Uprocess.i3 ./pkg/m3core/src/unix/freebsd-4/Upwd.i3 ./pkg/m3core/src/unix/freebsd-4/Uresource.i3 ./pkg/m3core/src/unix/freebsd-4/Usem.i3 ./pkg/m3core/src/unix/freebsd-4/Ushm.i3 ./pkg/m3core/src/unix/freebsd-4/Usignal.i3 ./pkg/m3core/src/unix/freebsd-4/Usignal.m3 ./pkg/m3core/src/unix/freebsd-4/Ustat.i3 ./pkg/m3core/src/unix/freebsd-4/Usocket.i3 ./pkg/m3core/src/unix/freebsd-4/Usyslog.i3 ./pkg/m3core/src/unix/freebsd-4/Utime.i3 ./pkg/m3core/src/unix/freebsd-4/Utypes.i3 ./pkg/m3core/src/unix/freebsd-4/Utypes.m3 ./pkg/m3core/src/unix/freebsd-4/Uugid.i3 ./pkg/m3core/src/unix/freebsd-4/Uuio.i3 ./pkg/m3core/src/unix/freebsd-4/Uutmp.i3 ./pkg/m3core/src/unix/freebsd-4/Uutsname.i3 ./pkg/m3core/src/thread/Common/ ./pkg/m3core/src/thread/POSIX/ ./pkg/m3core/src/thread/POSIX/SchedulerPosix.i3 ./pkg/m3core/src/thread/POSIX/ThreadF.i3 ./pkg/m3core/src/thread/POSIX/ThreadPosix.m3 ./pkg/m3core/src/thread/Common/Thread.i3 ./pkg/m3core/src/thread/Common/Scheduler.i3 ./pkg/m3core/src/thread/Common/MutexRep.i3 ./pkg/m3core/src/thread/Common/ThreadEvent.i3 ./pkg/m3core/src/runtime/common/ ./pkg/m3core/src/runtime/POSIX/ ./pkg/m3core/src/runtime/FreeBSD4/ ./pkg/m3core/src/runtime/ex_frame/ ./pkg/m3core/src/runtime/ex_frame/RTExFrame.i3 ./pkg/m3core/src/runtime/ex_frame/RTExFrame.m3 ./pkg/m3core/src/runtime/ex_frame/RTStackC.c ./pkg/m3core/src/runtime/FreeBSD4/RTSignal.m3 ./pkg/m3core/src/runtime/FreeBSD4/RTThread.m3 ./pkg/m3core/src/runtime/FreeBSD4/RTMachine.i3 ./pkg/m3core/src/runtime/FreeBSD4/RTThreadC.c ./pkg/m3core/src/runtime/FreeBSD4/_fpsetjmp.s ./pkg/m3core/src/runtime/POSIX/RTArgs.m3 ./pkg/m3core/src/runtime/POSIX/RTOS.m3 ./pkg/m3core/src/runtime/POSIX/RTPerfTool.m3 ./pkg/m3core/src/runtime/POSIX/RTPerfTool.i3 ./pkg/m3core/src/runtime/POSIX/RTProcessPosix.m3 ./pkg/m3core/src/runtime/POSIX/RTThread.i3 ./pkg/m3core/src/runtime/POSIX/RTThreadStk.m3 ./pkg/m3core/src/runtime/common/RTHooks.i3 ./pkg/m3core/src/runtime/common/RTHooks.m3 ./pkg/m3core/src/runtime/common/RT0.m3 ./pkg/m3core/src/runtime/common/RT0.i3 ./pkg/m3core/src/runtime/common/RuntimeError.i3 ./pkg/m3core/src/runtime/common/RuntimeError.m3 ./pkg/m3core/src/runtime/common/Compiler.m3 ./pkg/m3core/src/runtime/common/RTAllocator.i3 ./pkg/m3core/src/runtime/common/RTAllocator.m3 ./pkg/m3core/src/runtime/common/RTAllocCnts.i3 ./pkg/m3core/src/runtime/common/RTAllocStats.i3 ./pkg/m3core/src/runtime/common/RTAllocStats.m3 ./pkg/m3core/src/runtime/common/RTHeap.i3 ./pkg/m3core/src/runtime/common/RTHeap.m3 ./pkg/m3core/src/runtime/common/RTHeapInfo.i3 ./pkg/m3core/src/runtime/common/RTHeapInfo.m3 ./pkg/m3core/src/runtime/common/RTHeapMap.m3 ./pkg/m3core/src/runtime/common/RTHeapMap.i3 ./pkg/m3core/src/runtime/common/RTHeapRep.i3 ./pkg/m3core/src/runtime/common/RTHeapRep.m3 ./pkg/m3core/src/runtime/common/RTHeapStats.i3 ./pkg/m3core/src/runtime/common/RTIO.i3 ./pkg/m3core/src/runtime/common/RTHeapStats.m3 ./pkg/m3core/src/runtime/common/RTCollector.m3 ./pkg/m3core/src/runtime/common/RTCollector.i3 ./pkg/m3core/src/runtime/common/RTCollectorSRC.i3 ./pkg/m3core/src/runtime/common/RTWeakRef.i3 ./pkg/m3core/src/runtime/common/RTIO.m3 ./pkg/m3core/src/runtime/common/RTLinkerX.i3 ./pkg/m3core/src/runtime/common/RTLinker.m3 ./pkg/m3core/src/runtime/common/RTLinker.i3 ./pkg/m3core/src/runtime/common/RTDebug.i3 ./pkg/m3core/src/runtime/common/RTDebug.m3 ./pkg/m3core/src/runtime/common/RTError.i3 ./pkg/m3core/src/runtime/common/RTError.m3 ./pkg/m3core/src/runtime/common/RTException.m3 ./pkg/m3core/src/runtime/common/RTException.i3 ./pkg/m3core/src/runtime/common/RTMapOp.i3 ./pkg/m3core/src/runtime/common/RTMapOp.m3 ./pkg/m3core/src/runtime/common/RTMisc.i3 ./pkg/m3core/src/runtime/common/RTMisc.m3 ./pkg/m3core/src/runtime/common/RTModule.i3 ./pkg/m3core/src/runtime/common/RTPacking.m3 ./pkg/m3core/src/runtime/common/RTPacking.i3 ./pkg/m3core/src/runtime/common/RTParams.i3 ./pkg/m3core/src/runtime/common/RTParams.m3 ./pkg/m3core/src/runtime/common/RTProcedure.i3 ./pkg/m3core/src/runtime/common/RTProcedure.m3 ./pkg/m3core/src/runtime/common/RTProcess.i3 ./pkg/m3core/src/runtime/common/RTProcess.m3 ./pkg/m3core/src/runtime/common/RTTipe.m3 ./pkg/m3core/src/runtime/common/RTTipe.i3 ./pkg/m3core/src/runtime/common/RTType.i3 ./pkg/m3core/src/runtime/common/RTType.m3 ./pkg/m3core/src/runtime/common/RTTypeFP.i3 ./pkg/m3core/src/runtime/common/RTTypeFP.m3 ./pkg/m3core/src/runtime/common/RTTypeMap.i3 ./pkg/m3core/src/runtime/common/RTTypeMap.m3 ./pkg/m3core/src/runtime/common/RTutils.m3 ./pkg/m3core/src/runtime/common/RTutils.i3 ./pkg/m3core/src/runtime/common/RTHeapDebug.i3 ./pkg/m3core/src/runtime/common/RTHeapDebug.m3 ./pkg/m3core/src/runtime/common/RTArgs.i3 ./pkg/m3core/src/runtime/common/RTHeapEvent.i3 ./pkg/m3core/src/runtime/common/RTProcedureSRC.i3 ./pkg/m3core/src/runtime/common/RTSignal.i3 ./pkg/m3core/src/runtime/common/RTStack.i3 ./pkg/m3core/src/runtime/common/RTTypeSRC.i3 ./pkg/m3core/src/runtime/common/RTOS.i3 ./pkg/m3core/src/Csupport/Common/ ./pkg/m3core/src/Csupport/FreeBSD4/ ./pkg/m3core/src/Csupport/FreeBSD4/dtoa.c ./pkg/m3core/src/Csupport/Common/dtoa.h ./pkg/m3core/src/Csupport/Common/hand.c ./pkg/m3core/FreeBSD4/.M3EXPORTS ./pkg/m3core/FreeBSD4/libm3core.so.5 ./pkg/m3core/FreeBSD4/libm3core.so ./pkg/m3core/FreeBSD4/libm3core.a ./pkg/m3core/FreeBSD4/libm3core.m3x ./pkg/m3core/FreeBSD4/.M3WEB ./pkg/m3core/FreeBSD4/Compiler.i3 ./lib/libm3core.so.5 ./lib/libm3core.so ./lib/libm3.so.5 ./lib/libm3.so ./bin/cm3 ./bin/cm3cg ./bin/cm3.cfg ./bin/cm3.cfg--default -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Dec 18 23:51:45 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 18 Dec 2007 17:51:45 -0500 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/darwin In-Reply-To: <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> <28256359-D312-4D47-9A38-7A245D6AEAE5@cs.purdue.edu> <20071216233259.ukim9ntk6cw8gsgc@mail.elegosoft.com> <723A4C34-1B58-4F26-891C-45F764CAEEB5@cs.purdue.edu> <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> Message-ID: <1430B28B-A256-4B74-877D-9533183DFA42@cs.purdue.edu> I have put installation archives for I386_DARWIN and PPC_DARWIN at ftp://ftp.cs.purdue.edu/pub/hosking/m3. On Dec 17, 2007, at 6:03 AM, Olaf Wagner wrote: > Quoting Tony Hosking : >> A break is always good. :-) > > Hi again, > > after some hours of sleep I can report at least some success on > my old Darwin installation. I've put the archives on our web server > for public access, and would like to add some more. > > I still think a Darwin build on a newer system may be a good idea (we > can offer both on our web pages), and we definitely need some > for Linux (perhaps multiple distros, too, there?) > Solaris and Darwin/i386 would be great, too, and NetBSD, and of > course Windows. Mika offered to provide an archive for old FreeBSD > distributions (4.x). > > So everybody who is willing to produce some installation archives, > please let me know, and I'll make sure they get shipped to our > server. > > Please note that for the scripts/make-bin-dist-min.sh to work, > you need a sample configuration file in cm3/m3-sys/cm3/src/config/XXX, > as the ones in cminstall/src/config must be processed by the installer > first. Jay has removed the samples there a little bit too eagerly, > but most where outdated anyway. > > To upgrade from an older compiler I have successfully used the > upgrade.sh script. So the complete sequence to build a bootstrap > on your favourite platform would be: > > 1. Check out the current CVS head > 2. Copy your (working) configuration file to cm3/src/config/ > 3. Adapt the installer configuration file if necessary in > cminstall/src/config/. Make sure that all system libraries > get dynamically linked, for instance. > 4. scripts/upgrade.sh > 5. scripts/make-bin-dist-min.sh > > Any help will be appreciated. > > 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 hosking at cs.purdue.edu Wed Dec 19 00:23:49 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 18 Dec 2007 18:23:49 -0500 Subject: [M3devel] Unix signals and Modula-3... In-Reply-To: <200712181238.lBICcL8s052879@camembert.async.caltech.edu> References: <200712181238.lBICcL8s052879@camembert.async.caltech.edu> Message-ID: <92B67E8E-DB72-4436-A096-564DFF214D4D@cs.purdue.edu> I'm assuming that waitpid hanging when using system threads is not a problem, since the system thread scheduler will schedule other threads around the waiting one. The issue is only for the user-level threads implementation where a thread blocking on a waitpid call would prevent other threads being scheduled. On Dec 18, 2007, at 7:38 AM, Mika Nystrom wrote: > Hello everyone, > > I am in the process of bootstrapping the CVS head of CM3 on an old > FreeBSD-4.11 system, and at one point, when I replaced the old cm3 > with the new cm3, the compiler got slower. Not a little bit slower, > mind you, but about 10x slower. I remember pointing this out to > the m3devel list... oh it must have been three or four years ago; > one of our grad students at Caltech (Karl Papadantonakis, also > author of the caltech-parser) was the first to notice what was going > on. > > It has to do with Process.Wait. (From ProcessPosix.m3.) To repeat > what I said a few years ago, the problem lies here: > > CONST Delay = 0.1D0; > BEGIN > IF NOT p.waitOk THEN RAISE WaitAlreadyCalled END; > p.waitOk := FALSE; > (* By rights, the SchedulerPosix interface should have a WaitPID > procedure that is integrated with the thread scheduler. *) > LOOP > result := Uexec.waitpid(p.pid, ADR(statusT), Uexec.WNOHANG); > IF result # 0 THEN EXIT END; > Thread.Pause(Delay) > END; > <* ASSERT result > 0 *> > > In other words: if Process.Wait is called before the child process > is done, then the thread pauses 0.1 seconds. > > In our local version of m3build, we duplicate the Wait code and set > the Delay to 0.0. That's OK in a compiler, but it's not OK in > general, because you would chew up the CPU on a machine that was > doing a lot of long-term waiting. > > The problem is that the fix that I suggested way back when requires > messing with Unix signals (catching SIGC[H]LD instead of using > waitpid), which is why I never submitted a fix to the repository, > because I am not sure what such a fix might interact with. It seems > to me that the correct way of dealing with Unix signals is to have > a single thread that talks to the Unix system, registers signal > handlers, and takes care, via some object-oriented mechanism, of > calling back any M3 threads that are interested in the signals. > Would such a thing be possible? Where are signals used in the > system today? > > Mika From mika at async.caltech.edu Wed Dec 19 00:43:19 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 18 Dec 2007 15:43:19 -0800 Subject: [M3devel] Unix signals and Modula-3... In-Reply-To: Your message of "Tue, 18 Dec 2007 18:23:49 EST." <92B67E8E-DB72-4436-A096-564DFF214D4D@cs.purdue.edu> Message-ID: <200712182343.lBINhJDL084804@camembert.async.caltech.edu> Ah yes, you are right. The original issue is that waitpid would hang the whole runtime and that should not happen with system threads. If using system threads, waitpid should be called with a third argument of zero, I believe. Is this already happening? If not, make the change and if you have a fast machine you may see a spectacular speedup in your compile times. I suppose the easiest solution to this problem is simply to move all active targets to system threads... Still, there are some other areas where Unix signals might be of interest. I am thinking of things like interfacing with readline and other C-based libraries that use signals for concurrency. When I put a readline interface on some Modula-3 programs, I wound up using an external C program to do readline processing and then communicating over a pipe or TCP connection, because dealing with signals seemed like such a hassle. Mika Tony Hosking writes: >I'm assuming that waitpid hanging when using system threads is not a >problem, since the system thread scheduler will schedule other >threads around the waiting one. The issue is only for the user-level >threads implementation where a thread blocking on a waitpid call >would prevent other threads being scheduled. > >On Dec 18, 2007, at 7:38 AM, Mika Nystrom wrote: > >> Hello everyone, >> >> I am in the process of bootstrapping the CVS head of CM3 on an old >> FreeBSD-4.11 system, and at one point, when I replaced the old cm3 >> with the new cm3, the compiler got slower. Not a little bit slower, >> mind you, but about 10x slower. I remember pointing this out to >> the m3devel list... oh it must have been three or four years ago; >> one of our grad students at Caltech (Karl Papadantonakis, also >> author of the caltech-parser) was the first to notice what was going >> on. >> >> It has to do with Process.Wait. (From ProcessPosix.m3.) To repeat >> what I said a few years ago, the problem lies here: >> >> CONST Delay = 0.1D0; >> BEGIN >> IF NOT p.waitOk THEN RAISE WaitAlreadyCalled END; >> p.waitOk := FALSE; >> (* By rights, the SchedulerPosix interface should have a WaitPID >> procedure that is integrated with the thread scheduler. *) >> LOOP >> result := Uexec.waitpid(p.pid, ADR(statusT), Uexec.WNOHANG); >> IF result # 0 THEN EXIT END; >> Thread.Pause(Delay) >> END; >> <* ASSERT result > 0 *> >> >> In other words: if Process.Wait is called before the child process >> is done, then the thread pauses 0.1 seconds. >> >> In our local version of m3build, we duplicate the Wait code and set >> the Delay to 0.0. That's OK in a compiler, but it's not OK in >> general, because you would chew up the CPU on a machine that was >> doing a lot of long-term waiting. >> >> The problem is that the fix that I suggested way back when requires >> messing with Unix signals (catching SIGC[H]LD instead of using >> waitpid), which is why I never submitted a fix to the repository, >> because I am not sure what such a fix might interact with. It seems >> to me that the correct way of dealing with Unix signals is to have >> a single thread that talks to the Unix system, registers signal >> handlers, and takes care, via some object-oriented mechanism, of >> calling back any M3 threads that are interested in the signals. >> Would such a thing be possible? Where are signals used in the >> system today? >> >> Mika From wagner at elegosoft.com Wed Dec 19 00:44:06 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 19 Dec 2007 00:44:06 +0100 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/darwin In-Reply-To: <1430B28B-A256-4B74-877D-9533183DFA42@cs.purdue.edu> References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> <28256359-D312-4D47-9A38-7A245D6AEAE5@cs.purdue.edu> <20071216233259.ukim9ntk6cw8gsgc@mail.elegosoft.com> <723A4C34-1B58-4F26-891C-45F764CAEEB5@cs.purdue.edu> <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> <1430B28B-A256-4B74-877D-9533183DFA42@cs.purdue.edu> Message-ID: <20071219004406.mnemi5gnc4g4c80g@mail.elegosoft.com> Quoting Tony Hosking : > I have put installation archives for I386_DARWIN and PPC_DARWIN at > ftp://ftp.cs.purdue.edu/pub/hosking/m3. Great. I've shipped all the archives available so far to our web server at http://modula3.elegosoft.com/cm3/. I'm not sure if all the information on the download page is correct, and I'm sure the documentation and instructions provided are rather sparse. If anybody wants to improve that, please don't hesitate to edit cm3/www/download.html; I can then later ship the changes. Now it's time for bed again; thanks for all the help, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Wed Dec 19 01:03:46 2007 From: jayk123 at hotmail.com (Jay) Date: Wed, 19 Dec 2007 00:03:46 +0000 Subject: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/ In-Reply-To: <20071219004406.mnemi5gnc4g4c80g@mail.elegosoft.com> References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> <20071216230258.r62lii3kw08o0c8g@mail.elegosoft.com> <28256359-D312-4D47-9A38-7A245D6AEAE5@cs.purdue.edu> <20071216233259.ukim9ntk6cw8gsgc@mail.elegosoft.com> <723A4C34-1B58-4F26-891C-45F764CAEEB5@cs.purdue.edu> <20071217120331.z0ft9l0en4gw4888@mail.elegosoft.com> <1430B28B-A256-4B74-877D-9533183DFA42@cs.purdue.edu> <20071219004406.mnemi5gnc4g4c80g@mail.elegosoft.com> Message-ID: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/~checkout~/cm3/www/installation-windows.html?rev=1.2;content-type=text%2Fhtml ?? Perhaps now that 5.5.0 bootstraps are available, the 5.2.6 instructions should be moved out. I'm also aware that the style is rather poor, and that I should have tried harder to integrate it into the existing document, and that I suck, etc..It is not linked to from download.html. Does anyone else think the formating is a little off regarding how the Windows distribution is two files right next to each other? The archives could of course be merged. Current linkers will not put symbols into files, but older ones will.. given their relative large size and small use though, separate symbols like this seems ok. Oh someone beat me to OS X 10.4 PowerPC. Maybe I should try 10.2? :) - Jay > Date: Wed, 19 Dec 2007 00:44:06 +0100> From: wagner at elegosoft.com> To: hosking at cs.purdue.edu; m3devel at elegosoft.com> CC: m3-support at elegosoft.com; admins at elegosoft.com> Subject: Re: [M3devel] Providing some current CM3 bootstrap archives, was: Re: m3cg build failure on powerpc/darwin> > Quoting Tony Hosking :> > > I have put installation archives for I386_DARWIN and PPC_DARWIN at> > ftp://ftp.cs.purdue.edu/pub/hosking/m3.> > Great. I've shipped all the archives available so far to our> web server at http://modula3.elegosoft.com/cm3/.> > I'm not sure if all the information on the download> page is correct, and I'm sure the documentation and instructions> provided are rather sparse. If anybody wants to improve that,> please don't hesitate to edit cm3/www/download.html; I can then> later ship the changes.> > Now it's time for bed again; thanks for all the help,> > Olaf> -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> _________________________________________________________________ The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. http://www.xbox.com/en-US/hardware/wheretobuy/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Thu Dec 20 04:22:04 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Wed, 19 Dec 2007 19:22:04 -0800 Subject: [M3devel] Unix signals and Modula-3... In-Reply-To: Your message of "Tue, 18 Dec 2007 22:30:01 EST." Message-ID: <200712200322.lBK3M4xS055247@camembert.async.caltech.edu> Tony Hosking writes: >The system threads pthread implementation uses a signal and a >semaphore to stop/start threads for GC, Other than that, I don't >believe signals are being used anywhere else in the run-time system. > >Also, I should point out that there may be value in retaining the >current user-level threads implementation for all targets (we still >need to fix some to use setcontext/getcontext instead of setjmp/ >getjmp), in which case the same issue applies. I wonder if it makes >sense to implement a variant of waitpid inside the threads >implementation to do the right thing. We could use a signal there to >catch SIGCHLD appropriately in the ThreadPosix implementation and >leave it alone with ThreadPThread. > >What do you think? Oh, yes I wasn't suggesting dropping the user-level threads. I was just thinking that if most targets can use system threads, maybe it's OK if there's a 0.1 second delay on the others. After all, most people don't seem to have noticed that it's been this way all these years :) (Although it does get more obvious now that computers are faster and compile times aren't getting shorter on those targets.) I also think user-level threads can turn out to be important when system threads perform poorly for whatever reason. I know this was a big problem for some people I knew who were working with threads in Java, that when they used system threads for code that did very little work and lots of threadswitching, user-level threads were an order of magnitude faster. I suppose that ThreadPosix also uses signals to know when to switch contexts? Since it already deals with signals it shouldn't be too difficult to incorporate the waitpid business. But yes, it seems to me that since the implementation of Process.Wait's waiting for the child to exit depends on what kind of threading library is being used, that part of it ought/could conveniently be part of the threading library's interface. Mika From mika at async.caltech.edu Fri Dec 21 05:42:04 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 20 Dec 2007 20:42:04 -0800 Subject: [M3devel] Missing packages? Message-ID: <200712210442.lBL4g4kK011539@camembert.async.caltech.edu> Hi Modula-3 people. I was working on some code the other night and needed a small persistent table data structure, and I seemed to remember that there was a package called "stabletable" that had exactly the features I needed: a simple, persistent implementation of the Modula-3 generic tables. Only problem was ... I couldn't find it anywhere! I remembered it existed, but nowhere to be found. Well, I finally tracked it down on an m3browser running at the University of Tampere (Finland), cut-and-pasted the .ig and .mg and compiled the thing. A few questions: 1. This package is dated 1994. Is this after CM3 split from SRC M3? Is that why it's not in CM3? 2. Should I add it to CM3? 3. Are there other packages of similar status? Mika From jayk123 at hotmail.com Fri Dec 21 07:28:39 2007 From: jayk123 at hotmail.com (Jay) Date: Fri, 21 Dec 2007 06:28:39 +0000 Subject: [M3devel] Missing packages? In-Reply-To: <200712210442.lBL4g4kK011539@camembert.async.caltech.edu> References: <200712210442.lBL4g4kK011539@camembert.async.caltech.edu> Message-ID: DEC SRC M3 3.6 was released circa 1996, maybe 1995. m3-db\stable ?m3-db\stablegen (related) ? C:\dev2\cm3\doc\help\bib.html(578):
  • Allan Heydon,C:\dev2\cm3\doc\help\bib.html(579):Stabletable: An Example Client of the SmallDB Interface,C:\dev2\cm3\doc\help\bib.html(597):gzipped tar archive I think this is it. The links are dead. I have some/all of the 3.6 release archives if needed (a hard drive is in questionable state, but I definitely have boot-linuxelf and m3.tar.bz2, m3cc.tar.bz2 (I "recode" all .gzs as smaller .bz2...)) - Jay > To: m3devel at elegosoft.com> Date: Thu, 20 Dec 2007 20:42:04 -0800> From: mika at async.caltech.edu> Subject: [M3devel] Missing packages?> > Hi Modula-3 people.> > I was working on some code the other night and needed a small> persistent table data structure, and I seemed to remember that there> was a package called "stabletable" that had exactly the features I> needed: a simple, persistent implementation of the Modula-3 generic> tables.> > Only problem was ... I couldn't find it anywhere! I remembered it existed,> but nowhere to be found. Well, I finally tracked it down on an m3browser> running at the University of Tampere (Finland), cut-and-pasted the .ig and> .mg and compiled the thing.> > A few questions:> > 1. This package is dated 1994. Is this after CM3 split from SRC M3? Is> that why it's not in CM3?> 2. Should I add it to CM3?> 3. Are there other packages of similar status?> > Mika _________________________________________________________________ i?m is proud to present Cause Effect, a series about real people making a difference. http://im.live.com/Messenger/IM/MTV/?source=text_Cause_Effect -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Dec 21 09:51:02 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 21 Dec 2007 09:51:02 +0100 Subject: [M3devel] Missing packages? In-Reply-To: <200712210442.lBL4g4kK011539@camembert.async.caltech.edu> References: <200712210442.lBL4g4kK011539@camembert.async.caltech.edu> Message-ID: <20071221095102.0zpsxh3s2s44cs4g@mail.elegosoft.com> Quoting Mika Nystrom : > Hi Modula-3 people. > > I was working on some code the other night and needed a small > persistent table data structure, and I seemed to remember that there > was a package called "stabletable" that had exactly the features I > needed: a simple, persistent implementation of the Modula-3 generic > tables. > > Only problem was ... I couldn't find it anywhere! I remembered it existed, > but nowhere to be found. Well, I finally tracked it down on an m3browser > running at the University of Tampere (Finland), cut-and-pasted the .ig and > .mg and compiled the thing. Well, there is stable and stablegen, as Jay already pointed out. These can be used to generate persistent versions of almost any data structure. > A few questions: > > 1. This package is dated 1994. Is this after CM3 split from SRC M3? Is > that why it's not in CM3? stabletable may have been an predecessor of the more general stable package. I also found the attached documentation, which seems to be missing on our web site. I rather think that Critical Mass people have cleaned up the set of packages a bit. > 2. Should I add it to CM3? If you think it is useful in addition to stable and stablegen, there's no reason why not to add it. Put it into m3-db. If it's more or less code duplication, don't do it. > 3. Are there other packages of similar status? I cannot answer this question. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 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 Fri Dec 21 13:22:40 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 21 Dec 2007 13:22:40 +0100 Subject: [M3devel] endless exception loop on FreeBSD Message-ID: <20071221132240.uu5elpnqwwc4408s@mail.elegosoft.com> I'm trying to add pthread support to the FreeBSD4 platform. My first tentative additions now lead to endless exception loops once any error is encountered until the stack overflows. Does anybody know what's wrong here? I'm not aware that I have changed anything in this area. [...] #9 0x081dfe96 in RTHooks__Raise (M3_AJWxb1_ex=0x8272840, M3_AJWxb1_arg=0x1d, M3_AJWxb1_module=0x8273080, M3_AcxOUs_line=14) at RTHooks.m3:79 #10 0x081e00df in RuntimeError () at RuntimeError.m3:14 #11 0x081ef680 in RTException__DefaultBackstop (M3_Cblw37_a=0xbfbfe1a0, M3_AicXUJ_raises=0 '\0') at RTException.m3:33 #12 0x081ef654 in RTException__InvokeBackstop (M3_Cblw37_a=0xbfbfe1a0, M3_AicXUJ_raises=0 '\0') at RTException.m3:25 #13 0x081f903f in RTException__Raise (M3_Cblw37_act=0xbfbfe1a0) at RTExFrame.m3:29 #14 0x081dfe96 in RTHooks__Raise (M3_AJWxb1_ex=0x8267b00, M3_AJWxb1_arg=0x2839385c, M3_AJWxb1_module=0x8268480, M3_AcxOUs_line=50) at RTHooks.m3:79 #15 0x081b9dbe in OSErrorPosix__Raise0 (M3_AcxOUs_errno=2) ---Type to continue, or q to quit--- at OSErrorPosix.m3:50 #16 0x081bb0c4 in FSPosix__Fail (M3_Bd56fi_p=0x82276c0, M3_DIYzyQ_f=0x82276c8) at FSPosix.m3:356 #17 0x081bade2 in FS__Status (M3_Bd56fi_pn=0x82276c0, M3_CQo0YO__result=0xbfbfe318) at FSPosix.m3:323 #18 0x081aa2e4 in M3File__IsReadable (M3_Bd56fi_path=0x82276c0) at M3File.m3:182 #19 0x08088a3e in MxConfig__TryConfig (M3_Bd56fi_a=0x82276c0, M3_Bd56fi_b=0x0, M3_Bd56fi_c=0x0) at MxConfig.m3:94 #20 0x08088635 in MxConfig__FindConfig () at MxConfig.m3:43 #21 0x0808841b in MxConfig__FindFile () at MxConfig.m3:17 #22 0x0807301d in Main__DoIt () at Main.m3:31 #23 0x080739bc in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:193 #24 0x081ee9a2 in RTLinker__RunMainBody (M3_DjPxE3_m=0x8223860) at RTLinker.m3:399 #25 0x081edecd in RTLinker__AddUnitI (M3_DjPxE3_m=0x8223860) at RTLinker.m3:113 #26 0x081edf54 in RTLinker__AddUnit (M3_DjPxE5_b=0x80739a7) at RTLinker.m3:122 #27 0x08049b99 in main (argc=1, argv=0xbfbfe5f4, envp=0xbfbfe5fc) at _m3main.mc:4 -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Fri Dec 21 17:04:30 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 21 Dec 2007 11:04:30 -0500 Subject: [M3devel] endless exception loop on FreeBSD In-Reply-To: <20071221132240.uu5elpnqwwc4408s@mail.elegosoft.com> References: <20071221132240.uu5elpnqwwc4408s@mail.elegosoft.com> Message-ID: <592A55CF-8680-499A-9911-F461B7562879@cs.purdue.edu> Hmm. It doesn't ring any bells for me. On Dec 21, 2007, at 7:22 AM, Olaf Wagner wrote: > I'm trying to add pthread support to the FreeBSD4 platform. > My first tentative additions now lead to endless exception loops > once any error is encountered until the stack overflows. > > Does anybody know what's wrong here? I'm not aware that I have > changed anything in this area. > > [...] > #9 0x081dfe96 in RTHooks__Raise (M3_AJWxb1_ex=0x8272840, > M3_AJWxb1_arg=0x1d, > M3_AJWxb1_module=0x8273080, M3_AcxOUs_line=14) at RTHooks.m3:79 > #10 0x081e00df in RuntimeError () at RuntimeError.m3:14 > #11 0x081ef680 in RTException__DefaultBackstop > (M3_Cblw37_a=0xbfbfe1a0, > M3_AicXUJ_raises=0 '\0') at RTException.m3:33 > #12 0x081ef654 in RTException__InvokeBackstop (M3_Cblw37_a=0xbfbfe1a0, > M3_AicXUJ_raises=0 '\0') at RTException.m3:25 > #13 0x081f903f in RTException__Raise (M3_Cblw37_act=0xbfbfe1a0) > at RTExFrame.m3:29 > #14 0x081dfe96 in RTHooks__Raise (M3_AJWxb1_ex=0x8267b00, > M3_AJWxb1_arg=0x2839385c, M3_AJWxb1_module=0x8268480, > M3_AcxOUs_line=50) > at RTHooks.m3:79 > #15 0x081b9dbe in OSErrorPosix__Raise0 (M3_AcxOUs_errno=2) > ---Type to continue, or q to quit--- > at OSErrorPosix.m3:50 > #16 0x081bb0c4 in FSPosix__Fail (M3_Bd56fi_p=0x82276c0, > M3_DIYzyQ_f=0x82276c8) > at FSPosix.m3:356 > #17 0x081bade2 in FS__Status (M3_Bd56fi_pn=0x82276c0, > M3_CQo0YO__result=0xbfbfe318) at FSPosix.m3:323 > #18 0x081aa2e4 in M3File__IsReadable (M3_Bd56fi_path=0x82276c0) > at M3File.m3:182 > #19 0x08088a3e in MxConfig__TryConfig (M3_Bd56fi_a=0x82276c0, > M3_Bd56fi_b=0x0, > M3_Bd56fi_c=0x0) at MxConfig.m3:94 > #20 0x08088635 in MxConfig__FindConfig () at MxConfig.m3:43 > #21 0x0808841b in MxConfig__FindFile () at MxConfig.m3:17 > #22 0x0807301d in Main__DoIt () at Main.m3:31 > #23 0x080739bc in Main_M3 (M3_AcxOUs_mode=1) at Main.m3:193 > #24 0x081ee9a2 in RTLinker__RunMainBody (M3_DjPxE3_m=0x8223860) > at RTLinker.m3:399 > #25 0x081edecd in RTLinker__AddUnitI (M3_DjPxE3_m=0x8223860) at > RTLinker.m3:113 > #26 0x081edf54 in RTLinker__AddUnit (M3_DjPxE5_b=0x80739a7) at > RTLinker.m3:122 > #27 0x08049b99 in main (argc=1, argv=0xbfbfe5f4, envp=0xbfbfe5fc) > at _m3main.mc:4 > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From rcoleburn at scires.com Fri Dec 21 18:23:30 2007 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 21 Dec 2007 12:23:30 -0500 Subject: [M3devel] Missing packages? In-Reply-To: <200712210442.lBL4g4kK011539@camembert.async.caltech.edu> References: <200712210442.lBL4g4kK011539@camembert.async.caltech.edu> Message-ID: <476BB045.1E75.00D7.1@scires.com> Mika et al: I believe you are referring to the generic called "Stable". I have the sources for this from the cm3 v4.1 days. Olaf should have them also. I believe they fall under the same copyright/use rules as the rest of cm3. I also wrote something a long time back that may be of interest to you. I've attached the generic interfaces below for your reference. Note that they are in MS-DOS text format, not Unix-style text format. These two generics are very similar, but read the up-front comments to see the differences and decide which may be right for you. If you are interested, I should be able to provide the full sources to you. Let me know. Regards, Randy Coleburn >>> Mika Nystrom 12/20/2007 11:42 PM >>> Hi Modula-3 people. I was working on some code the other night and needed a small persistent table data structure, and I seemed to remember that there was a package called "stabletable" that had exactly the features I needed: a simple, persistent implementation of the Modula-3 generic tables. Only problem was ... I couldn't find it anywhere! I remembered it existed, but nowhere to be found. Well, I finally tracked it down on an m3browser running at the University of Tampere (Finland), cut-and-pasted the .ig and .mg and compiled the thing. A few questions: 1. This package is dated 1994. Is this after CM3 split from SRC M3? Is that why it's not in CM3? 2. Should I add it to CM3? 3. Are there other packages of similar status? Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ObjectDatabase2.ig Type: application/octet-stream Size: 19563 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ObjectDatabase.ig Type: application/octet-stream Size: 20395 bytes Desc: not available URL: From hosking at cs.purdue.edu Sat Dec 22 23:30:29 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 22 Dec 2007 17:30:29 -0500 Subject: [M3devel] endless exception loop on FreeBSD In-Reply-To: <476D6E04.2000503@luthien.in-berlin.de> References: <20071221132240.uu5elpnqwwc4408s@mail.elegosoft.com> <592A55CF-8680-499A-9911-F461B7562879@cs.purdue.edu> <476D6E04.2000503@luthien.in-berlin.de> Message-ID: Any chance that the sigjmp buffers are differently-sized with the new libc? On Dec 22, 2007, at 3:05 PM, Olaf Wagner wrote: > Tony Hosking wrote: > >> Hmm. It doesn't ring any bells for me. >> >> On Dec 21, 2007, at 7:22 AM, Olaf Wagner wrote: >> >>> I'm trying to add pthread support to the FreeBSD4 platform. >>> My first tentative additions now lead to endless exception loops >>> once any error is encountered until the stack overflows. >>> >>> Does anybody know what's wrong here? I'm not aware that I have >>> changed anything in this area. >> > I seems that I have been linking against a non-reentrant libc. I > can now get a little > farther: > > % ./m3-sys/cm3/FreeBSD4/cm3 -help @M3debugthreads > Stopping from act=0x8a93500 > Stopping act=0x8a93b80 > Stopped act=0x8a93b80 > Stopped from act=0x8a93500 > Processing act=0x8a93500 > Processing act=0x8a93b80 > Starting from act=0x8a93500 > Starting act=0x8a93b80 > Started act=0x8a93b80 > Started from act=0x8a93500 > Stopping from act=0x8a93500 > Stopping act=0x8a93b80 > Stopped act=0x8a93b80 > Stopped from act=0x8a93500 > Processing act=0x8a93500 > Processing act=0x8a93b80 > Starting from act=0x8a93500 > Starting act=0x8a93b80 > Started act=0x8a93b80 > Started from act=0x8a93500 > CStatus failed with errno 2 > > > *** > *** runtime error: > *** Unhandled exception: OSError.E > *** file "../src/os/POSIX/OSErrorPosix.m3", line 50 > *** > > Abort trap (core dumped) > > This is the compiler trying to locate cm3.cfg at different locations. > It doesn't find it and an OSError.E is raised, which should get caught > in M3File.IsReadable, but isn't. So it seems exception handling is > broken as soon as I use system threads. Any ideas on this one? > > Olaf From wagner at elegosoft.com Sun Dec 23 16:36:40 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 23 Dec 2007 16:36:40 +0100 Subject: [M3devel] pthreads on FreeBSD, was: endless exception loop on FreeBSD In-Reply-To: <476D6E04.2000503@luthien.in-berlin.de> References: <20071221132240.uu5elpnqwwc4408s@mail.elegosoft.com> <592A55CF-8680-499A-9911-F461B7562879@cs.purdue.edu> <476D6E04.2000503@luthien.in-berlin.de> Message-ID: <20071223163640.3mk3dmc05c0gsgok@mail.elegosoft.com> >> On Dec 21, 2007, at 7:22 AM, Olaf Wagner wrote: >> >>> I'm trying to add pthread support to the FreeBSD4 platform. >>> My first tentative additions now lead to endless exception loops >>> once any error is encountered until the stack overflows. >>> >>> Does anybody know what's wrong here? I'm not aware that I have >>> changed anything in this area. >> > I seems that I have been linking against a non-reentrant libc. I can > now get a little > farther: > > % ./m3-sys/cm3/FreeBSD4/cm3 -help @M3debugthreads > Stopping from act=0x8a93500 > Stopping act=0x8a93b80 > Stopped act=0x8a93b80 > Stopped from act=0x8a93500 > Processing act=0x8a93500 > Processing act=0x8a93b80 > Starting from act=0x8a93500 > Starting act=0x8a93b80 > Started act=0x8a93b80 > Started from act=0x8a93500 > Stopping from act=0x8a93500 > Stopping act=0x8a93b80 > Stopped act=0x8a93b80 > Stopped from act=0x8a93500 > Processing act=0x8a93500 > Processing act=0x8a93b80 > Starting from act=0x8a93500 > Starting act=0x8a93b80 > Started act=0x8a93b80 > Started from act=0x8a93500 > CStatus failed with errno 2 > > > *** > *** runtime error: > *** Unhandled exception: OSError.E > *** file "../src/os/POSIX/OSErrorPosix.m3", line 50 > *** > > Abort trap (core dumped) > > This is the compiler trying to locate cm3.cfg at different locations. > It doesn't find it and an OSError.E is raised, which should get caught > in M3File.IsReadable, but isn't. So it seems exception handling is > broken as soon as I use system threads. Any ideas on this one? Some additional information: It is really only the PTHREAD setting in m3core/src/thread/m3makefile which makes exceptions fail. If I change it and compile everything again, I get this output from cm3: % ./m3-sys/cm3/FreeBSD4/cm3 -help @M3debugthreads DetermineContext: oldSP = 0xbfbfe74c modelSP: 0xbfbfe70c oldSP: 0xbfbfe74c frame size: 64 CStatus failed with errno 2 CStatus failed with errno 2 CStatus failed with errno 2 CStatus failed with errno 2 CStatus failed with errno 2 CStatus failed with errno 2 Critical Mass Modula-3 version d5.5.0 last updated: 2007-12-17 configuration: /usr/local/cm3/bin/cm3.cfg [...] So all OSError.E exceptions for stat failures are caught, and there are no thread switches at the start of the compiler; it only sets up the model frame for userlevel threads. In contrast, system level pthreads show much activity at the start (why?), and the first exception terminates the compiler. I still haven't got a good explanation for this. Unfortunately, the FreeBSD gdb debugger does not really seem to cope well with threaded programs... All interesting information always is unrecoverable. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sun Dec 23 16:57:29 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 23 Dec 2007 10:57:29 -0500 Subject: [M3devel] pthreads on FreeBSD, was: endless exception loop on FreeBSD In-Reply-To: <20071223163640.3mk3dmc05c0gsgok@mail.elegosoft.com> References: <20071221132240.uu5elpnqwwc4408s@mail.elegosoft.com> <592A55CF-8680-499A-9911-F461B7562879@cs.purdue.edu> <476D6E04.2000503@luthien.in-berlin.de> <20071223163640.3mk3dmc05c0gsgok@mail.elegosoft.com> Message-ID: Ah! Lights turning on in my head... It is probably the case that you have neglected to tell the compiler to avoid using global exception information. You need to set Global_handler_stack FALSE in m3middle/src/Target.m3 for the pthreads- based targets. On Dec 23, 2007, at 10:36 AM, Olaf Wagner wrote: >>> On Dec 21, 2007, at 7:22 AM, Olaf Wagner wrote: >>> >>>> I'm trying to add pthread support to the FreeBSD4 platform. >>>> My first tentative additions now lead to endless exception loops >>>> once any error is encountered until the stack overflows. >>>> >>>> Does anybody know what's wrong here? I'm not aware that I have >>>> changed anything in this area. >>> >> I seems that I have been linking against a non-reentrant libc. I can >> now get a little >> farther: >> >> % ./m3-sys/cm3/FreeBSD4/cm3 -help @M3debugthreads >> Stopping from act=0x8a93500 >> Stopping act=0x8a93b80 >> Stopped act=0x8a93b80 >> Stopped from act=0x8a93500 >> Processing act=0x8a93500 >> Processing act=0x8a93b80 >> Starting from act=0x8a93500 >> Starting act=0x8a93b80 >> Started act=0x8a93b80 >> Started from act=0x8a93500 >> Stopping from act=0x8a93500 >> Stopping act=0x8a93b80 >> Stopped act=0x8a93b80 >> Stopped from act=0x8a93500 >> Processing act=0x8a93500 >> Processing act=0x8a93b80 >> Starting from act=0x8a93500 >> Starting act=0x8a93b80 >> Started act=0x8a93b80 >> Started from act=0x8a93500 >> CStatus failed with errno 2 >> >> >> *** >> *** runtime error: >> *** Unhandled exception: OSError.E >> *** file "../src/os/POSIX/OSErrorPosix.m3", line 50 >> *** >> >> Abort trap (core dumped) >> >> This is the compiler trying to locate cm3.cfg at different locations. >> It doesn't find it and an OSError.E is raised, which should get >> caught >> in M3File.IsReadable, but isn't. So it seems exception handling is >> broken as soon as I use system threads. Any ideas on this one? > > Some additional information: > > It is really only the PTHREAD setting in m3core/src/thread/m3makefile > which makes exceptions fail. If I change it and compile everything > again, > I get this output from cm3: > > % ./m3-sys/cm3/FreeBSD4/cm3 -help @M3debugthreads > DetermineContext: oldSP = 0xbfbfe74c > modelSP: 0xbfbfe70c > oldSP: 0xbfbfe74c > frame size: 64 > CStatus failed with errno 2 > CStatus failed with errno 2 > CStatus failed with errno 2 > CStatus failed with errno 2 > CStatus failed with errno 2 > CStatus failed with errno 2 > Critical Mass Modula-3 version d5.5.0 > last updated: 2007-12-17 > configuration: /usr/local/cm3/bin/cm3.cfg > [...] > > So all OSError.E exceptions for stat failures are caught, and there > are no thread switches at the start of the compiler; it only sets > up the model frame for userlevel threads. > In contrast, system level pthreads show much activity at the start > (why?), and the first exception terminates the compiler. > > I still haven't got a good explanation for this. Unfortunately, > the FreeBSD gdb debugger does not really seem to cope well with > threaded > programs... All interesting information always is unrecoverable. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Dec 23 20:48:18 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 23 Dec 2007 20:48:18 +0100 Subject: [M3devel] pthreads on FreeBSD, was: endless exception loop on FreeBSD In-Reply-To: References: <20071221132240.uu5elpnqwwc4408s@mail.elegosoft.com> <592A55CF-8680-499A-9911-F461B7562879@cs.purdue.edu> <476D6E04.2000503@luthien.in-berlin.de> <20071223163640.3mk3dmc05c0gsgok@mail.elegosoft.com> Message-ID: <20071223204818.zqdh8gl77k4k4c0s@mail.elegosoft.com> Quoting Tony Hosking : > Ah! Lights turning on in my head... > > It is probably the case that you have neglected to tell the compiler to > avoid using global exception information. You need to set > Global_handler_stack FALSE in m3middle/src/Target.m3 for the > pthreads-based targets. Great! This seems to have done the trick. I've now been able to recompile the whole system and run mentor with the FreeBSD pthreads library. I'd never have found this setting, because it was nowhere near I expected the problem. Exception handling is one of the areas I was never familiar with in (C)M3. Probably I should learn to understand how the system works in this respect, too. Is there any documentation about the current state of things apart from the source code? Thanks for your help and the great whole pthreads contribution, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sun Dec 23 20:53:58 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 23 Dec 2007 14:53:58 -0500 Subject: [M3devel] pthreads on FreeBSD, was: endless exception loop on FreeBSD In-Reply-To: <20071223204818.zqdh8gl77k4k4c0s@mail.elegosoft.com> References: <20071221132240.uu5elpnqwwc4408s@mail.elegosoft.com> <592A55CF-8680-499A-9911-F461B7562879@cs.purdue.edu> <476D6E04.2000503@luthien.in-berlin.de> <20071223163640.3mk3dmc05c0gsgok@mail.elegosoft.com> <20071223204818.zqdh8gl77k4k4c0s@mail.elegosoft.com> Message-ID: <697B4834-D0F5-4A9E-8B87-76C92EC0BFA8@cs.purdue.edu> On Dec 23, 2007, at 2:48 PM, Olaf Wagner wrote: > Quoting Tony Hosking : > >> Ah! Lights turning on in my head... >> >> It is probably the case that you have neglected to tell the >> compiler to >> avoid using global exception information. You need to set >> Global_handler_stack FALSE in m3middle/src/Target.m3 for the >> pthreads-based targets. > > Great! This seems to have done the trick. I've now been able to > recompile the whole system and run mentor with the FreeBSD pthreads > library. I'd never have found this setting, because it was nowhere > near I expected the problem. Excellent. > Exception handling is one of the areas I was never familiar with > in (C)M3. Probably I should learn to understand how the system > works in this respect, too. Is there any documentation about > the current state of things apart from the source code? I'm afraid I don't think there is much in the way of documentation other than the code. > Thanks for your help and the great whole pthreads contribution, Let me know if you have any other problems. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > From jayk123 at hotmail.com Mon Dec 24 14:52:03 2007 From: jayk123 at hotmail.com (Jay) Date: Mon, 24 Dec 2007 13:52:03 +0000 Subject: [M3devel] relocation out of range on PPC_LINUX (5.2.6) Message-ID: (My goodness Linux continues to disappoint...not because of this Modula-3 stuff per se, though cminstall kind of stinks vs. somethhing more autoconf-ish..) Anyway: Using the 5.2.6 distribution on Yellow Dog Linux 4.1 (unpatched, I can't quite figure out how to get patches... one reason Linux disappoints, at the same time I can't patch the Linux system, a Windows system rebooted itself at 3am to take an update, which I also don't like..) [jay at localhost t]$ rm -rf PPC_LINUX [jay at localhost t]$ ls -Rl .: total 4 -rw-rw-r-- 1 jay jay 72 Dec 24 04:45 Hello.m3 [jay at localhost t]$ cat Hello.m3 MODULE Hello EXPORTS Main; IMPORT IO; BEGIN IO.Put("hello"); END Hello. [jay at localhost t]$ cm3 -version Critical Mass Modula-3 version 5.2.6 last updated: 2003-06-27 configuration: /usr/local/cm3/bin/cm3.cfg [jay at localhost t]$ which cm3 /usr/local/cm3/bin/cm3 [jay at localhost t]$ cm3 new source -> compiling Hello.m3 -> linking prog [jay at localhost t]$ PPC_LINUX/prog PPC_LINUX/prog: error while loading shared libraries: /usr/local/cm3/pkg/m3core/PPC_LINUX/libm3core.so.5: R_PPC_REL24 relocation at 0x0fe1220c for symbol `memset' out of range [jay at localhost t]$ ldd PPC_LINUX/prog libm3.so.5 => /usr/local/cm3/pkg/libm3/PPC_LINUX/libm3.so.5 (0x0fe94000) libm3core.so.5 => /usr/local/cm3/pkg/m3core/PPC_LINUX/libm3core.so.5 (0x0fdde000) libm3gcdefs.so.5 => /usr/local/cm3/lib/libm3gcdefs.so.5 (0x0fdbb000) libm.so.6 => /lib/tls/libm.so.6 (0x30015000) libc.so.6 => /lib/tls/libc.so.6 (0x3009b000) /lib/ld.so.1 (0x0ffd0000) I won't likely have a computer on which to investigate this over the next week. (Already bringing two. :) ) Building standalone works..just hack m3_link in cm3.cfg to say shared = "". cm3 is already standalone, but in case other executables are built and used.. So the question then becomes: Anyone know what causes this? How to avoid the binaries I'm going to produce having the same problem, perhaps on another machine and not mine? The error seems almost self explanatory. m3core.so.5 starts at 0x0fdde000 and extends to..? presumably something under 0x0fe1220c. Btw, I put in the request to fix alma mater mail forwarding, waiting for them now. - Jay _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007 From jayk123 at hotmail.com Mon Dec 24 19:12:07 2007 From: jayk123 at hotmail.com (Jay) Date: Mon, 24 Dec 2007 18:12:07 +0000 Subject: [M3devel] relocation out of range on PPC_LINUX (5.2.6) In-Reply-To: References: Message-ID: Lots of segfaults once the new cm3cg is shipped.. pretty much for every file.. next week.. - Jay ---------------------------------------- > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Date: Mon, 24 Dec 2007 13:52:03 +0000 > Subject: [M3devel] relocation out of range on PPC_LINUX (5.2.6) > > > (My goodness Linux continues to disappoint...not because > of this Modula-3 stuff per se, though cminstall kind of stinks > vs. somethhing more autoconf-ish..) > > Anyway: > > Using the 5.2.6 distribution on Yellow Dog Linux 4.1 (unpatched, I can't > quite figure out how to get patches... one reason Linux disappoints, > at the same time I can't patch the Linux system, a Windows system > rebooted itself at 3am to take an update, which I also don't like..) > > [jay at localhost t]$ rm -rf PPC_LINUX > > [jay at localhost t]$ ls -Rl > .: > total 4 > -rw-rw-r-- 1 jay jay 72 Dec 24 04:45 Hello.m3 > > [jay at localhost t]$ cat Hello.m3 > > MODULE Hello EXPORTS Main; > IMPORT IO; > BEGIN > IO.Put("hello"); > END Hello. > > [jay at localhost t]$ cm3 -version > Critical Mass Modula-3 version 5.2.6 > last updated: 2003-06-27 > configuration: /usr/local/cm3/bin/cm3.cfg > > [jay at localhost t]$ which cm3 > /usr/local/cm3/bin/cm3 > > [jay at localhost t]$ cm3 > new source -> compiling Hello.m3 > -> linking prog > > [jay at localhost t]$ PPC_LINUX/prog > PPC_LINUX/prog: error while loading shared libraries: /usr/local/cm3/pkg/m3core/PPC_LINUX/libm3core.so.5: R_PPC_REL24 relocation at 0x0fe1220c for symbol `memset' out of range > [jay at localhost t]$ ldd PPC_LINUX/prog > libm3.so.5 => /usr/local/cm3/pkg/libm3/PPC_LINUX/libm3.so.5 (0x0fe94000) > libm3core.so.5 => /usr/local/cm3/pkg/m3core/PPC_LINUX/libm3core.so.5 (0x0fdde000) > libm3gcdefs.so.5 => /usr/local/cm3/lib/libm3gcdefs.so.5 (0x0fdbb000) > libm.so.6 => /lib/tls/libm.so.6 (0x30015000) > libc.so.6 => /lib/tls/libc.so.6 (0x3009b000) > /lib/ld.so.1 (0x0ffd0000) > > > I won't likely have a computer on which to investigate this over the next week. > (Already bringing two. :) ) > > Building standalone works..just hack m3_link in cm3.cfg to say shared = "". > cm3 is already standalone, but in case other executables are built and used.. > > > So the question then becomes: > Anyone know what causes this? > How to avoid the binaries I'm going to produce having the same problem, > perhaps on another machine and not mine? > > > The error seems almost self explanatory. > m3core.so.5 starts at 0x0fdde000 and extends to..? > presumably something under 0x0fe1220c. > > Btw, I put in the request to fix alma mater mail forwarding, waiting for them now. > > - Jay > > _________________________________________________________________ > Share life as it happens with the new Windows Live. > http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007 _________________________________________________________________ The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. http://www.xbox.com/en-US/hardware/wheretobuy/ From jayk123 at hotmail.com Mon Dec 24 19:42:02 2007 From: jayk123 at hotmail.com (Jay) Date: Mon, 24 Dec 2007 18:42:02 +0000 Subject: [M3devel] relocation out of range on PPC_LINUX (5.2.6) In-Reply-To: References: Message-ID: Wow so I built my own svn and almost the same error: [root at localhost subversion-1.4.6]# svn svn: error while loading shared libraries: /usr/local/lib/libsvn_ra_dav-1.so.0: R_PPC_REL24 relocation at 0x0fdb5594 for symbol `strcmp' out of range maybe time to try 5.2 or OpenSuse or Fedora.. Will research more.. -Jay ---------------------------------------- > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: RE: [M3devel] relocation out of range on PPC_LINUX (5.2.6) > Date: Mon, 24 Dec 2007 18:12:07 +0000 > > > Lots of segfaults once the new cm3cg is shipped.. pretty much for every file.. next week.. > > - Jay > > ---------------------------------------- >> From: jayk123 at hotmail.com >> To: m3devel at elegosoft.com >> Date: Mon, 24 Dec 2007 13:52:03 +0000 >> Subject: [M3devel] relocation out of range on PPC_LINUX (5.2.6) >> >> >> (My goodness Linux continues to disappoint...not because >> of this Modula-3 stuff per se, though cminstall kind of stinks >> vs. somethhing more autoconf-ish..) >> >> Anyway: >> >> Using the 5.2.6 distribution on Yellow Dog Linux 4.1 (unpatched, I can't >> quite figure out how to get patches... one reason Linux disappoints, >> at the same time I can't patch the Linux system, a Windows system >> rebooted itself at 3am to take an update, which I also don't like..) >> >> [jay at localhost t]$ rm -rf PPC_LINUX >> >> [jay at localhost t]$ ls -Rl >> .: >> total 4 >> -rw-rw-r-- 1 jay jay 72 Dec 24 04:45 Hello.m3 >> >> [jay at localhost t]$ cat Hello.m3 >> >> MODULE Hello EXPORTS Main; >> IMPORT IO; >> BEGIN >> IO.Put("hello"); >> END Hello. >> >> [jay at localhost t]$ cm3 -version >> Critical Mass Modula-3 version 5.2.6 >> last updated: 2003-06-27 >> configuration: /usr/local/cm3/bin/cm3.cfg >> >> [jay at localhost t]$ which cm3 >> /usr/local/cm3/bin/cm3 >> >> [jay at localhost t]$ cm3 >> new source -> compiling Hello.m3 >> -> linking prog >> >> [jay at localhost t]$ PPC_LINUX/prog >> PPC_LINUX/prog: error while loading shared libraries: /usr/local/cm3/pkg/m3core/PPC_LINUX/libm3core.so.5: R_PPC_REL24 relocation at 0x0fe1220c for symbol `memset' out of range >> [jay at localhost t]$ ldd PPC_LINUX/prog >> libm3.so.5 => /usr/local/cm3/pkg/libm3/PPC_LINUX/libm3.so.5 (0x0fe94000) >> libm3core.so.5 => /usr/local/cm3/pkg/m3core/PPC_LINUX/libm3core.so.5 (0x0fdde000) >> libm3gcdefs.so.5 => /usr/local/cm3/lib/libm3gcdefs.so.5 (0x0fdbb000) >> libm.so.6 => /lib/tls/libm.so.6 (0x30015000) >> libc.so.6 => /lib/tls/libc.so.6 (0x3009b000) >> /lib/ld.so.1 (0x0ffd0000) >> >> >> I won't likely have a computer on which to investigate this over the next week. >> (Already bringing two. :) ) >> >> Building standalone works..just hack m3_link in cm3.cfg to say shared = "". >> cm3 is already standalone, but in case other executables are built and used.. >> >> >> So the question then becomes: >> Anyone know what causes this? >> How to avoid the binaries I'm going to produce having the same problem, >> perhaps on another machine and not mine? >> >> >> The error seems almost self explanatory. >> m3core.so.5 starts at 0x0fdde000 and extends to..? >> presumably something under 0x0fe1220c. >> >> Btw, I put in the request to fix alma mater mail forwarding, waiting for them now. >> >> - Jay >> >> _________________________________________________________________ >> Share life as it happens with the new Windows Live. >> http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007 > > _________________________________________________________________ > The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. > http://www.xbox.com/en-US/hardware/wheretobuy/ _________________________________________________________________ The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. http://www.xbox.com/en-US/hardware/wheretobuy/ From jayk123 at hotmail.com Mon Dec 24 20:10:19 2007 From: jayk123 at hotmail.com (Jay) Date: Mon, 24 Dec 2007 19:10:19 +0000 Subject: [M3devel] relocation out of range on PPC_LINUX (5.2.6) In-Reply-To: References: Message-ID: "research" -- "search the web" configure --with-pic and/or --disable-multilibs sound promsing *-darwin use --disable-multi on the other hand, the thread is six years old, you'd think it'd just work by now.. next week.. - Jay ---------------------------------------- > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: RE: [M3devel] relocation out of range on PPC_LINUX (5.2.6) > Date: Mon, 24 Dec 2007 18:42:02 +0000 > > > Wow so I built my own svn and almost the same error: > > [root at localhost subversion-1.4.6]# svn > svn: error while loading shared libraries: /usr/local/lib/libsvn_ra_dav-1.so.0: R_PPC_REL24 relocation at 0x0fdb5594 for symbol `strcmp' out of range > > maybe time to try 5.2 or OpenSuse or Fedora.. > > Will research more.. > > -Jay > ---------------------------------------- >> From: jayk123 at hotmail.com >> To: m3devel at elegosoft.com >> Subject: RE: [M3devel] relocation out of range on PPC_LINUX (5.2.6) >> Date: Mon, 24 Dec 2007 18:12:07 +0000 >> >> >> Lots of segfaults once the new cm3cg is shipped.. pretty much for every file.. next week.. >> >> - Jay >> >> ---------------------------------------- >>> From: jayk123 at hotmail.com >>> To: m3devel at elegosoft.com >>> Date: Mon, 24 Dec 2007 13:52:03 +0000 >>> Subject: [M3devel] relocation out of range on PPC_LINUX (5.2.6) >>> >>> >>> (My goodness Linux continues to disappoint...not because >>> of this Modula-3 stuff per se, though cminstall kind of stinks >>> vs. somethhing more autoconf-ish..) >>> >>> Anyway: >>> >>> Using the 5.2.6 distribution on Yellow Dog Linux 4.1 (unpatched, I can't >>> quite figure out how to get patches... one reason Linux disappoints, >>> at the same time I can't patch the Linux system, a Windows system >>> rebooted itself at 3am to take an update, which I also don't like..) >>> >>> [jay at localhost t]$ rm -rf PPC_LINUX >>> >>> [jay at localhost t]$ ls -Rl >>> .: >>> total 4 >>> -rw-rw-r-- 1 jay jay 72 Dec 24 04:45 Hello.m3 >>> >>> [jay at localhost t]$ cat Hello.m3 >>> >>> MODULE Hello EXPORTS Main; >>> IMPORT IO; >>> BEGIN >>> IO.Put("hello"); >>> END Hello. >>> >>> [jay at localhost t]$ cm3 -version >>> Critical Mass Modula-3 version 5.2.6 >>> last updated: 2003-06-27 >>> configuration: /usr/local/cm3/bin/cm3.cfg >>> >>> [jay at localhost t]$ which cm3 >>> /usr/local/cm3/bin/cm3 >>> >>> [jay at localhost t]$ cm3 >>> new source -> compiling Hello.m3 >>> -> linking prog >>> >>> [jay at localhost t]$ PPC_LINUX/prog >>> PPC_LINUX/prog: error while loading shared libraries: /usr/local/cm3/pkg/m3core/PPC_LINUX/libm3core.so.5: R_PPC_REL24 relocation at 0x0fe1220c for symbol `memset' out of range >>> [jay at localhost t]$ ldd PPC_LINUX/prog >>> libm3.so.5 => /usr/local/cm3/pkg/libm3/PPC_LINUX/libm3.so.5 (0x0fe94000) >>> libm3core.so.5 => /usr/local/cm3/pkg/m3core/PPC_LINUX/libm3core.so.5 (0x0fdde000) >>> libm3gcdefs.so.5 => /usr/local/cm3/lib/libm3gcdefs.so.5 (0x0fdbb000) >>> libm.so.6 => /lib/tls/libm.so.6 (0x30015000) >>> libc.so.6 => /lib/tls/libc.so.6 (0x3009b000) >>> /lib/ld.so.1 (0x0ffd0000) >>> >>> >>> I won't likely have a computer on which to investigate this over the next week. >>> (Already bringing two. :) ) >>> >>> Building standalone works..just hack m3_link in cm3.cfg to say shared = "". >>> cm3 is already standalone, but in case other executables are built and used.. >>> >>> >>> So the question then becomes: >>> Anyone know what causes this? >>> How to avoid the binaries I'm going to produce having the same problem, >>> perhaps on another machine and not mine? >>> >>> >>> The error seems almost self explanatory. >>> m3core.so.5 starts at 0x0fdde000 and extends to..? >>> presumably something under 0x0fe1220c. >>> >>> Btw, I put in the request to fix alma mater mail forwarding, waiting for them now. >>> >>> - Jay >>> >>> _________________________________________________________________ >>> Share life as it happens with the new Windows Live. >>> http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007 >> >> _________________________________________________________________ >> The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. >> http://www.xbox.com/en-US/hardware/wheretobuy/ > > _________________________________________________________________ > The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. > http://www.xbox.com/en-US/hardware/wheretobuy/ _________________________________________________________________ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_122007 From jayk123 at hotmail.com Tue Dec 25 13:09:31 2007 From: jayk123 at hotmail.com (Jay) Date: Tue, 25 Dec 2007 12:09:31 +0000 Subject: [M3devel] PPC_DARWIN problems, at least config/5.2.6, maybe all moot Message-ID: PPC_DARWIN also has problems...at least in the config. If you take the 5.2.6 archive, install to /dev2/cm3, accept the defaults, claim all the missing unused libs are in /usr/lib (opengl, postgres, x11) you end up with: jbook:/dev2/j/m3 jay$ cat Hello.m3 MODULE Hello EXPORTS Main; IMPORT IO; BEGIN IO.Put("Hello\n"); END Hello. jbook:/dev2/j/m3 jay$ uname -a Darwin jbook 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc jbook:/dev2/j/m3 jay$ cm3 -version Critical Mass Modula-3 version 5.2.6 last updated: 2003-06-27 configuration: /cm3/bin/cm3.cfg jbook:/dev2/j/m3 jay$ cm3 new source -> compiling Hello.m3 -> linking prog jbook:/dev2/j/m3 jay$ PPC_DARWIN/prog dyld: Library not loaded: /var/tmp/cm3/lib/libm3.5.2.dylib Referenced from: /dev2/j/m3/PPC_DARWIN/prog Reason: image not found Trace/BPT trap jbook:/dev2/j/m3 jay$ otool -L PPC_DARWIN/prog PPC_DARWIN/prog: /var/tmp/cm3/lib/libm3.5.2.dylib (compatibility version 5.0.0, current version 5.2.0) /Users/wagner/local/cm3/lib/libm3core.5.2.dylib (compatibility version 5.0.0, current version 5.2.0) /Users/wagner/local/cm3/lib/libm3gcdefs.5.2.dylib (compatibility version 5.0.0, current version 5.2.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.10) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) jbook:/dev2/j/m3 jay$ ls -l PPC_DARWIN/prog -rwxr-xr-x 1 jay admin 20264 Dec 25 04:43 PPC_DARWIN/prog At the temporary cost of giving up dynamic linking, you can fix this by removing M3_SPLIT_LIBNAMES_IF_SHARED and/or M3_SPLIT_LIBNAMES from cm3.cfg, yielding: jbook:/dev2/j/m3 jay$ otool -L PPC_DARWIN/prog PPC_DARWIN/prog: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.10) jbook:/dev2/j/m3 jay$ ls -l PPC_DARWIN/prog -rwxr-xr-x 1 jay admin 1388380 Dec 25 04:48 PPC_DARWIN/prog jbook:/dev2/j/m3 jay$ PPC_DARWIN/prog Hello I will fix the checked in config file...even though it varies a bunch from the 5.2.6 distributed config, it results in the same. And, um, does everyone understand what I did with Win32 and making cminstall obsolete? Ok to do the same on Mac OS X? You know, it's running things out of the path and/or finding them in their "very standard" locations. In fact, you can hard code full paths and be ok. That is, instead of asking the user where their compiler is, hardcoding any of cc, gcc, /usr/bin/cc, /usr/bin/gcc all work fine. Asking them where ar/ranlib are, similar, though the docs say that libtool replaced those, and ar/ranlib vs. libtool is one way in which the checked in config and the 5.2.6 distribution's config vary. I'll try for libtool. The only thing the user really needs to decide is where to install to, and the cfg file can discover their choice without any editing. INSTALL_ROOT = path() & "/.." BIN_INSTALL = path() % executables In terms of wanting to provide some configurable redirection, well, I think an advanced user can manage.. An indirect SYSTEM_CC = "cc" can be left, I guess. You know, I dare say, that platforms have been reduced and converged enough such that..you can get rid of Quake and move it into cm3. Um.. do any of the Unix platforms support other than gcc? Other than GNU ld? Ok, Apple ld is not GNU ld. (Geez, it is just me or is Apple an incredible hodgepodge mess these days? I mean both in terms of their "system architecture" and their tools. The "system architecture" reveals bunches of similar redundant subsystems. Try reading through man ld, man ranlib, just try to understand which flag goes with which mode, which flags are for compatibility with which OS version, and which of the compatibility flags is either ignored or does something useful... and should I say -lGL or -framework OpenGL??) That I don't haven't adjusted to Modula-3 and don't mind/prefer writing Quake instead. :) Some bootstrap was provided. I should look at it, and its config. Otherwise..I'll look into what it takes to build it all and with dynamic linking. Perhaps the bootstrap is just fine. But the checked in config is not. - Jay _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Dec 25 17:02:59 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 25 Dec 2007 11:02:59 -0500 Subject: [M3devel] PPC_DARWIN problems, at least config/5.2.6, maybe all moot In-Reply-To: References: Message-ID: <5EB28A70-CCEC-4855-B714-F0CE03E6DCC6@cs.purdue.edu> On Dec 25, 2007, at 7:09 AM, Jay wrote: > PPC_DARWIN also has problems...at least in the config. This is the cm3.cfg I use for PPC_DARWIN and it works fine for me. Notice that it installs into /usr/local/cm3. -------------- next part -------------- A non-text attachment was scrubbed... Name: cm3.cfg Type: application/octet-stream Size: 12662 bytes Desc: not available URL: -------------- next part -------------- > > > > If you take the 5.2.6 archive, install to /dev2/cm3, accept the > defaults, > claim all the missing unused libs are in /usr/lib (opengl, > postgres, x11) > > > you end up with: > > > jbook:/dev2/j/m3 jay$ cat Hello.m3 > > > MODULE Hello EXPORTS Main; > IMPORT IO; > BEGIN > IO.Put("Hello\n"); > END Hello. > > > jbook:/dev2/j/m3 jay$ uname -a > Darwin jbook 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 > 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh > powerpc > > > jbook:/dev2/j/m3 jay$ cm3 -version > Critical Mass Modula-3 version 5.2.6 > last updated: 2003-06-27 > configuration: /cm3/bin/cm3.cfg > > > jbook:/dev2/j/m3 jay$ cm3 > new source -> compiling Hello.m3 > -> linking prog > > > jbook:/dev2/j/m3 jay$ PPC_DARWIN/prog > dyld: Library not loaded: /var/tmp/cm3/lib/libm3.5.2.dylib > Referenced from: /dev2/j/m3/PPC_DARWIN/prog > Reason: image not found > Trace/BPT trap > > > jbook:/dev2/j/m3 jay$ otool -L PPC_DARWIN/prog > PPC_DARWIN/prog: > /var/tmp/cm3/lib/libm3.5.2.dylib (compatibility version > 5.0.0, current version 5.2.0) > /Users/wagner/local/cm3/lib/libm3core.5.2.dylib > (compatibility version 5.0.0, current version 5.2.0) > /Users/wagner/local/cm3/lib/libm3gcdefs.5.2.dylib > (compatibility version 5.0.0, current version 5.2.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > current version 88.1.10) > /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, > current version 1.0.0) > > > jbook:/dev2/j/m3 jay$ ls -l PPC_DARWIN/prog > -rwxr-xr-x 1 jay admin 20264 Dec 25 04:43 PPC_DARWIN/prog > > > At the temporary cost of giving up dynamic linking, you can fix > this by removing M3_SPLIT_LIBNAMES_IF_SHARED > and/or M3_SPLIT_LIBNAMES from cm3.cfg, yielding: > Dynamic linking works fine for me. > > jbook:/dev2/j/m3 jay$ otool -L PPC_DARWIN/prog > PPC_DARWIN/prog: > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > current version 88.1.10) > > > jbook:/dev2/j/m3 jay$ ls -l PPC_DARWIN/prog > -rwxr-xr-x 1 jay admin 1388380 Dec 25 04:48 PPC_DARWIN/prog > > > jbook:/dev2/j/m3 jay$ PPC_DARWIN/prog > Hello > > > I will fix the checked in config file...even though it varies a > bunch from the 5.2.6 distributed > config, it results in the same. Not sure how that differs with my config file. > And, um, does everyone understand what I did with Win32 and making > cminstall obsolete? > Ok to do the same on Mac OS X? Please don't. I would prefer to keep the OS X install the same as for other Unix/POSIX platforms, if only because it means less splitting of the code base. > You know, it's running things out of the path and/or finding them > in their "very standard" locations. > In fact, you can hard code full paths and be ok. > That is, instead of asking the user where their compiler is, > hardcoding any of cc, gcc, /usr/bin/cc, /usr/bin/gcc all work fine. Why not just hardcode the cminstall config file so it doesn't ask questions except were absolutely necessary. > Asking them where ar/ranlib are, similar, though the docs say that > libtool replaced those, and ar/ranlib vs. libtool is one way > in which the checked in config and the 5.2.6 distribution's config > vary. I'll try for libtool. Please see my config file. > > > > The only thing the user really needs to decide is where to install > to, and > the cfg file can discover their choice without any editing. Indeed. > > > > INSTALL_ROOT = path() & "/.." > BIN_INSTALL = path() % executables > > > In terms of wanting to provide some configurable redirection, well, > I think an advanced user can manage.. > An indirect SYSTEM_CC = "cc" can be left, I guess. > > > You know, I dare say, that platforms have been reduced and > converged enough such that..you can get rid of > Quake and move it into cm3. I'm not sure what you mean by this. > Um.. do any of the Unix platforms support other than gcc? Other > than GNU ld? > Ok, Apple ld is not GNU ld. (Geez, it is just me or is Apple an > incredible hodgepodge mess these days? > I mean both in terms of their "system architecture" and their > tools. The "system architecture" reveals bunches > of similar redundant subsystems. Try reading through man ld, man > ranlib, just try to understand which > flag goes with which mode, which flags are for compatibility with > which OS version, and which of the > compatibility flags is either ignored or does something useful... > and should I say -lGL or -framework OpenGL??) > > > That I don't haven't adjusted to Modula-3 and don't mind/prefer > writing Quake instead. :) > > > Some bootstrap was provided. I should look at it, and its config. > Otherwise..I'll look into what it takes to build it all and with > dynamic linking. > Perhaps the bootstrap is just fine. But the checked in config is not. I have a PPC_DARWIN bootstrap file at ftp://ftp.cs.purdue.edu/pub/ hosking/m3 and in the PPC_DARWIN subdirectory. > > > > - Jay > > Share life as it happens with the new Windows Live. Share now! From wagner at elegosoft.com Tue Dec 25 17:26:33 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 25 Dec 2007 17:26:33 +0100 Subject: [M3devel] PPC_DARWIN problems, at least config/5.2.6, maybe all moot In-Reply-To: <5EB28A70-CCEC-4855-B714-F0CE03E6DCC6@cs.purdue.edu> References: <5EB28A70-CCEC-4855-B714-F0CE03E6DCC6@cs.purdue.edu> Message-ID: <20071225162633.GA6373@elegosoft.com> On Tue, Dec 25, 2007 at 11:02:59AM -0500, Tony Hosking wrote: > On Dec 25, 2007, at 7:09 AM, Jay wrote: > >jbook:/dev2/j/m3 jay$ otool -L PPC_DARWIN/prog > >PPC_DARWIN/prog: > > /var/tmp/cm3/lib/libm3.5.2.dylib (compatibility version > >5.0.0, current version 5.2.0) > > /Users/wagner/local/cm3/lib/libm3core.5.2.dylib > >(compatibility version 5.0.0, current version 5.2.0) > > /Users/wagner/local/cm3/lib/libm3gcdefs.5.2.dylib > >(compatibility version 5.0.0, current version 5.2.0) > > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > >current version 88.1.10) > > /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, > >current version 1.0.0) > > > >jbook:/dev2/j/m3 jay$ ls -l PPC_DARWIN/prog > >-rwxr-xr-x 1 jay admin 20264 Dec 25 04:43 PPC_DARWIN/prog > > > >At the temporary cost of giving up dynamic linking, you can fix > >this by removing M3_SPLIT_LIBNAMES_IF_SHARED > >and/or M3_SPLIT_LIBNAMES from cm3.cfg, yielding: > > Dynamic linking works fine for me. For me, too. > >And, um, does everyone understand what I did with Win32 and making > >cminstall obsolete? > >Ok to do the same on Mac OS X? > > Please don't. I would prefer to keep the OS X install the same as > for other Unix/POSIX platforms, if only because it means less > splitting of the code base. I'd second this. I'd rather have a more intelligent cminstall, which tries to figure out all the information for itself, and then presents the user with a standard setup and directions how to solve any remaining problems. And this way we don't have to bother with more more scripting languages, too. > Why not just hardcode the cminstall config file so it doesn't ask > questions except were absolutely necessary. This would be another approach to making things simpler. We can try both ways at once, though. > >The only thing the user really needs to decide is where to install > >to, and > >the cfg file can discover their choice without any editing. > > Indeed. I wouldn't like to remove any flexibility there is, as in my experience, it will be needed once it has been removed. Perhaps I'll have a try at making cminstall better during the next weeks. The main problem with installation issues is, that one needs access to all relevant target platforms to check things and test them, and that it takes much time to do this ;-) Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Dec 25 17:33:09 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 25 Dec 2007 17:33:09 +0100 Subject: [M3devel] m3cg build failure on powerpc/darwin In-Reply-To: <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> References: <20071216212301.GA25212@elegosoft.com> <76CC5112-9C84-41A6-83BF-553E97BA236C@cs.purdue.edu> Message-ID: <20071225163309.GA7057@elegosoft.com> Just for the records: The solution to the instruction problem below is installing a newer cctools package. Detailed instructions can be found at http://gcc.gnu.org/ml/gcc/2005-03/msg01149.html Olaf On Sun, Dec 16, 2007 at 04:50:38PM -0500, Tony Hosking wrote: > That is a very old Darwin distro. Here is my G4: > > Darwin Kernel Version 8.10.0: Wed May 23 16:50:59 PDT 2007; > root:xnu-792.21.3~1/RELEASE_PPC > > On Dec 16, 2007, at 4:23 PM, Olaf Wagner wrote: > > >Hi, > > > >while trying to build some boot archives build on my PowerBook > >G4, uname -a > > > >Darwin apple.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 > >20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power > >Macintosh powerpc > > > >the compilation died with > > > >/Users/wagner/work/cm3/m3-sys/m3cc/PPC_DARWIN/./gcc/xgcc -B/Users/ > >wagner/work/cm3/m3-sys/m3cc/PPC_DARWIN/./gcc/ -B/usr/local/powerpc- > >apple-darwin7.9.0/bin/ -B/usr/local/powerpc-apple-darwin7.9.0/lib/ - > >isystem /usr/local/powerpc-apple-darwin7.9.0/include -isystem /usr/ > >local/powerpc-apple-darwin7.9.0/sys-include -c -DHAVE_CONFIG_H -O2 - > >O2 -g -I. -I../../../gcc/libiberty/../include -W -Wall -pedantic - > >Wwrite-strings -Wstrict-prototypes ../../../gcc/libiberty/ > >floatformat.c -o floatformat.o > >../../../gcc/libiberty/floatformat.c: In function > >'floatformat_to_double': > >../../../gcc/libiberty/floatformat.c:354: warning: floating > >constant exceeds range of 'float' > >/var/tmp/cccvQbrs.s:508:stfiwx instruction is optional for the > >PowerPC (not allowed without -force_cpusubtype_ALL option) > >/var/tmp/cccvQbrs.s:550:stfiwx instruction is optional for the > >PowerPC (not allowed without -force_cpusubtype_ALL option) > >make[2]: *** [floatformat.o] Error 1 > >make[1]: *** [all-target-libiberty] Error 2 > >make: *** [all] Error 2 > >"/Users/wagner/work/cm3/m3-sys/m3cc/src/m3makefile", line 188: > >quake runtime error: exit 512: cd .; make CC="gcc" CFLAGS="-O2 -g" > > > >--procedure-- -line- -file--- > >exec -- > >include_dir 188 /Users/wagner/work/cm3/m3-sys/m3cc/src/ > >m3makefile > > 5 /Users/wagner/work/cm3/m3-sys/m3cc/ > >PPC_DARWIN/m3make.args > > > >Fatal Error: package build failed > > > >Any ideas? -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Tue Dec 25 20:03:21 2007 From: jayk123 at hotmail.com (Jay) Date: Tue, 25 Dec 2007 19:03:21 +0000 Subject: [M3devel] "why cminstall isn't needed" Message-ID: Here is what happens on Mac OSX 10.4 PowerPC. Where would you like the system installed? [/usr/local/cm3] This is the one thing worthwhile, though the default is fine. 1: /usr/bin/emacsclient 2: /usr/bin/emacs 3: /usr/bin/gnuclient 4: /usr/bin/vi 5: /usr/bin/vim What should be the default text editor for new CM3 users? [/usr/bin/emacsclient](1 of 5) I don't believe this is ever used, not until Reactor comes back. Otherwise it's not a terrible thing to ask. 1: /usr/lib Where are the flex/bison libraries? [/usr/lib](1 of 1) I haven't tested this yet, but the default appears correct, and you don't likely need to specify it. "-lfl" probably suffices. Where are the Postgres95 libraries? By default, nowhere. User could edit cm3.cfg file. Perhaps just comment which parts are more or less expected to be user-edited? Where are the OpenGL libraries? Haven't tested this, but again I believe hardcoding is trivial. Like -framework OpenGL or such. (attached) 1: /usr/lib 2: /usr/local/lib Where are the ODBC libraries? [/usr/lib](1 of 2) Untested, but again /usr/lib appears correct and -liodbc -liodbcinst should suffice. Where are the Motif libraries? Nowhere by default. Where are the X11 libraries? Nowhere by default, but probably hardcodeable if installed. 1: /usr/bin/gcc 2: /usr/bin/cc Where is your C compiler? [/usr/bin/gcc](1 of 2) Both options are fine and equivalent, along with "cc, "gcc", "gcc-3.3", "gcc-4.0". 1: /usr/bin/ar Where is your library archiver? [/usr/bin/ar](1 of 1) This is correct, along with "ar", but the docs suggest shouldn't be used. 1: /usr/bin/ranlib Where is your library indexer? [/usr/bin/ranlib](1 of 1) Ditto. 1: /usr/bin/as Where is your assembler? [/usr/bin/as](1 of 1) This is correct, along with "as". Could also be, e.g. /usr/libexec/darwin/pcc/as, but nothing to be gained by using that directly, right? (gcc has similar actual files) See my point? It's all rather worthless. Hardcoded defaults or $PATH search work. Attached is my config file so far but I am having problems.. - Jay _________________________________________________________________ Don't get caught with egg on your face. Play Chicktionary! http://club.live.com/chicktionary.aspx?icid=chick_wlhmtextlink1_dec -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cfg1 Type: application/octet-stream Size: 12614 bytes Desc: not available URL: From jayk123 at hotmail.com Tue Dec 25 21:32:15 2007 From: jayk123 at hotmail.com (Jay) Date: Tue, 25 Dec 2007 20:32:15 +0000 Subject: [M3devel] PPC_DARWIN problems, at least config/5.2.6, maybe all moot Message-ID: 1) The documentation says -fPIC is the default, so I removed it. But it matters. It doesn't matter for gcc building C. It matters for m3cg building Modula-3. It is the difference between, pic: jbook:/dev2/j/m3 jay$ cat Hello.m3 MODULE Hello EXPORTS Main; IMPORT IO; BEGIN IO.Put("Hello\n"); END Hello. jbook:/dev2/j/m3 jay$ cat PPC_DARWIN/Hello.ms ... bl L_IO__Put$stub ... .data .picsymbol_stub L_IO__Put$stub: .indirect_symbol _IO__Put mflr r0 bcl 20,31,L0$_IO__Put L0$_IO__Put: mflr r11 addis r11,r11,ha16(L_IO__Put$lazy_ptr-L0$_IO__Put) mtlr r0 lwz r12,lo16(L_IO__Put$lazy_ptr-L0$_IO__Put)(r11) mtctr r12 addi r11,r11,lo16(L_IO__Put$lazy_ptr-L0$_IO__Put) bctr .data .lazy_symbol_pointer L_IO__Put$lazy_ptr: .indirect_symbol _IO__Put .long dyld_stub_binding_helper vs. non-pic just plain wow only one whole function to make a call :) : jbook:/dev2/j/m3 jay$ cat PPC_DARWIN/Hello.ms ... bl _IO__Put which nets you the likes of: jbook:/dev2/j/m3 jay$ cm3 -> linking prog gcc -dynamic -o prog _m3main.o Hello.mo -L/cm3/pkg/libm3/PPC_DARWIN -lm3 -L/cm3/pkg/m3core/PPC_DARWIN -lm3core -L/cm3/bin/../lib -lm3gcdefs /usr/bin/ld: _m3main.o has external relocation entries in non-writable section (__TEXT,__text) for symbols: _RTProcess__Exit _RTLinker__AddUnit _RTLinker__InitRuntime collect2: ld returned 1 exit status (Windows also only uses one instruction, through a pointer, for dynamic calls, and the compiler often prefetches the pointer. The difference is, perhaps, that Windows aggregates all the pointers together, not sure about the other systems.. one instruction through a pointer is true for x86 and AM64, not so of the former MIPS, PowerPC, Alpha I believe or current IA64, those require fetching/restore the GOT/TOC (same thing? I should know the difference..) 2) Splitting -L and -l off for shared libs matters. ld /foo/bar.a means link to bar.a, which is a static lib, not even a stub lib or import lib like in Windows -L/foo -lbar probes for /foo/bar.dylib /foo/bar.a man ld: -lx This option is an abbreviation for the library name `libx.a', where x is a string. If -dynamic is specified the abbreviation for the library name is first search as `libx.dylib' and then `libx.a' is searched for. ld searches for libraries first in any directories specified with -L options, then in any directo- ries specified in the colon separated set of paths in the envi- ronment variable LD_LIBRARY_PATH, then the standard directories /lib, /usr/lib, and /usr/local/lib. A library is searched when its name is encountered, so the placement of the -l flag is sig- nificant. If string x is of the form x.o, then that file is searched for in the same places, but without prepending `lib' or appending `.a' or `.dylib' to the filename. 3) lastly, setting DYLD_LIBRARY_PATH=/cm3/lib lets the full paths from one machine not matter so much on another machine. I am going to try out: before: local lib_so = format ("lib%s.dylib", lib) local lib_soxx = format ("lib%s.%s.dylib", lib, version) local lib_pn = LIB_INSTALL & "/" & lib_soxx "-install_name", lib_pn, after: local lib_so = format ("lib%s.dylib", lib) local lib_soxx = format ("lib%s.%s.dylib", lib, version) local lib_pn = LIB_INSTALL & "/" & lib_soxx "-install_name", lib_soxx, see if a path is needed or can just use leaf names. - Jay From: jayk123 at hotmail.com To: m3devel at elegosoft.com Subject: PPC_DARWIN problems, at least config/5.2.6, maybe all moot Date: Tue, 25 Dec 2007 12:09:31 +0000 PPC_DARWIN also has problems...at least in the config. If you take the 5.2.6 archive, install to /dev2/cm3, accept the defaults, claim all the missing unused libs are in /usr/lib (opengl, postgres, x11) you end up with: jbook:/dev2/j/m3 jay$ cat Hello.m3 MODULE Hello EXPORTS Main; IMPORT IO; BEGIN IO.Put("Hello\n"); END Hello. jbook:/dev2/j/m3 jay$ uname -a Darwin jbook 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc jbook:/dev2/j/m3 jay$ cm3 -version Critical Mass Modula-3 version 5.2.6 last updated: 2003-06-27 configuration: /cm3/bin/cm3.cfg jbook:/dev2/j/m3 jay$ cm3 new source -> compiling Hello.m3 -> linking prog jbook:/dev2/j/m3 jay$ PPC_DARWIN/prog dyld: Library not loaded: /var/tmp/cm3/lib/libm3.5.2.dylib Referenced from: /dev2/j/m3/PPC_DARWIN/prog Reason: image not found Trace/BPT trap jbook:/dev2/j/m3 jay$ otool -L PPC_DARWIN/prog PPC_DARWIN/prog: /var/tmp/cm3/lib/libm3.5.2.dylib (compatibility version 5.0.0, current version 5.2.0) /Users/wagner/local/cm3/lib/libm3core.5.2.dylib (compatibility version 5.0.0, current version 5.2.0) /Users/wagner/local/cm3/lib/libm3gcdefs.5.2.dylib (compatibility version 5.0.0, current version 5.2.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.10) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) jbook:/dev2/j/m3 jay$ ls -l PPC_DARWIN/prog -rwxr-xr-x 1 jay admin 20264 Dec 25 04:43 PPC_DARWIN/prog At the temporary cost of giving up dynamic linking, you can fix this by removing M3_SPLIT_LIBNAMES_IF_SHARED and/or M3_SPLIT_LIBNAMES from cm3.cfg, yielding: jbook:/dev2/j/m3 jay$ otool -L PPC_DARWIN/prog PPC_DARWIN/prog: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.10) jbook:/dev2/j/m3 jay$ ls -l PPC_DARWIN/prog -rwxr-xr-x 1 jay admin 1388380 Dec 25 04:48 PPC_DARWIN/prog jbook:/dev2/j/m3 jay$ PPC_DARWIN/prog Hello I will fix the checked in config file...even though it varies a bunch from the 5.2.6 distributed config, it results in the same. And, um, does everyone understand what I did with Win32 and making cminstall obsolete? Ok to do the same on Mac OS X? You know, it's running things out of the path and/or finding them in their "very standard" locations. In fact, you can hard code full paths and be ok. That is, instead of asking the user where their compiler is, hardcoding any of cc, gcc, /usr/bin/cc, /usr/bin/gcc all work fine. Asking them where ar/ranlib are, similar, though the docs say that libtool replaced those, and ar/ranlib vs. libtool is one way in which the checked in config and the 5.2.6 distribution's config vary. I'll try for libtool. The only thing the user really needs to decide is where to install to, and the cfg file can discover their choice without any editing. INSTALL_ROOT = path() & "/.." BIN_INSTALL = path() % executables In terms of wanting to provide some configurable redirection, well, I think an advanced user can manage.. An indirect SYSTEM_CC = "cc" can be left, I guess. You know, I dare say, that platforms have been reduced and converged enough such that..you can get rid of Quake and move it into cm3. Um.. do any of the Unix platforms support other than gcc? Other than GNU ld? Ok, Apple ld is not GNU ld. (Geez, it is just me or is Apple an incredible hodgepodge mess these days? I mean both in terms of their "system architecture" and their tools. The "system architecture" reveals bunches of similar redundant subsystems. Try reading through man ld, man ranlib, just try to understand which flag goes with which mode, which flags are for compatibility with which OS version, and which of the compatibility flags is either ignored or does something useful... and should I say -lGL or -framework OpenGL??) That I don't haven't adjusted to Modula-3 and don't mind/prefer writing Quake instead. :) Some bootstrap was provided. I should look at it, and its config. Otherwise..I'll look into what it takes to build it all and with dynamic linking. Perhaps the bootstrap is just fine. But the checked in config is not. - Jay Share life as it happens with the new Windows Live. Share now! _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Tue Dec 25 22:47:03 2007 From: mika at async.caltech.edu (Mika Nystrom) Date: Tue, 25 Dec 2007 13:47:03 -0800 Subject: [M3devel] PPC_DARWIN problems, at least config/5.2.6, maybe all moot In-Reply-To: Your message of "Tue, 25 Dec 2007 12:09:31 GMT." Message-ID: <200712252147.lBPLl32p030684@camembert.async.caltech.edu> Jay writes: > ... > >You know, I dare say, that platforms have been reduced and converged enough= > such that..you can get rid of >Quake and move it into cm3. Um.. do any of the Unix platforms support other= > than gcc? Other than GNU ld? I take it you don't mean "get rid of Quake" but "get rid of cm3.cfg"? I would certainly agree that cm3.cfg is problematic. I have more than once had apparently unresolvable issues with CM3 that Tony fixed by sending me a new cm3.cfg, which came, seemingly, out of a hat... However I also would think it's a bad idea to reduce configurability. As Olaf said, you'll miss it the moment it's gone. (Someone will.) Non-GNU Solaris and Digital Unix aren't that hard to support with the current code if someone wanted to, for instance. Why make such a hypothetical someone's work harder? (Just an example, I'm sure there are other things.) Mika From jayk123 at hotmail.com Tue Dec 25 23:03:19 2007 From: jayk123 at hotmail.com (Jay) Date: Tue, 25 Dec 2007 22:03:19 +0000 Subject: [M3devel] PPC_DARWIN problems, at least config/5.2.6, maybe all moot In-Reply-To: <200712252147.lBPLl32p030684@camembert.async.caltech.edu> References: Your message of "Tue, 25 Dec 2007 12:09:31 GMT." <200712252147.lBPLl32p030684@camembert.async.caltech.edu> Message-ID: Other platforms should be supportable via cm3 directly eh? I'm just not sure of the value of extension/scripting languages in general, vs. having fewer languages. I very much like not having to compile/link such languages, the tendency toward having garbage collection and builtin collection classes, but I'm not sure which characteristics necessarily go together -- I strongly suspect you can have it all in one language -- static checking, fast compilation to native code, "built in" collection classes or a good library, etc. I don't care that much. You know, everything is configurable, it is a matter of how. What is in the code, what is in data, what is in non compiled code? (code is data and all that..) There does seem to be a line here but it is scientifically (lazily?) hard for me to discern. Regarding the problems with cm3.cfg.. I don't know. Just to backup a sec, I believe one of the "big" pieces of work that Critical Mass did was converting large swaths of Quake code into Modula-3, that code which, I assume, tended to be the same across all machines. Maybe it was just "utilities", maybe it was about perf. So what I wonder then, is if just a bit more shouldn't be done here. Have platforms converged such that less needs to be configurable? Or, then again, the cm3.cfg IS already fairly small. Maybe it is right about where it needs to be. Bigger fish to fry probably -- like, I noticed m3cg and as are run for every single file, maybe there is a gain to batching? (and win32 int64.....) So, back to cm3.cfg. It IS fairly small. Is it down to about what varies per platform? I haven't really surveyed them all.. - Jay > To: jayk123 at hotmail.com > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] PPC_DARWIN problems, at least config/5.2.6, maybe all moot > Date: Tue, 25 Dec 2007 13:47:03 -0800 > From: mika at async.caltech.edu > > Jay writes: > > > ... > > > >You know, I dare say, that platforms have been reduced and converged enough= > > such that..you can get rid of > >Quake and move it into cm3. Um.. do any of the Unix platforms support other= > > than gcc? Other than GNU ld? > > I take it you don't mean "get rid of Quake" but "get rid of cm3.cfg"? > I would certainly agree that cm3.cfg is problematic. I have more > than once had apparently unresolvable issues with CM3 that Tony > fixed by sending me a new cm3.cfg, which came, seemingly, out of a > hat... > > However I also would think it's a bad idea to reduce configurability. > As Olaf said, you'll miss it the moment it's gone. (Someone will.) > Non-GNU Solaris and Digital Unix aren't that hard to support with > the current code if someone wanted to, for instance. Why make such a > hypothetical someone's work harder? (Just an example, I'm sure there > are other things.) > > Mika _________________________________________________________________ Don't get caught with egg on your face. Play Chicktionary! http://club.live.com/chicktionary.aspx?icid=chick_wlhmtextlink1_dec -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Dec 26 05:14:15 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 25 Dec 2007 23:14:15 -0500 Subject: [M3devel] PPC_DARWIN problems, at least config/5.2.6, maybe all moot In-Reply-To: References: Your message of "Tue, 25 Dec 2007 12:09:31 GMT." <200712252147.lBPLl32p030684@camembert.async.caltech.edu> Message-ID: <4A78DF83-6CBF-43AB-AEE0-6E1E25ACDE39@cs.purdue.edu> On Dec 25, 2007, at 5:03 PM, Jay wrote: > Is it down to about what varies per platform? Yes, pretty much... > > I haven't really surveyed them all.. > > - Jay > > > To: jayk123 at hotmail.com > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] PPC_DARWIN problems, at least config/ > 5.2.6, maybe all moot > > Date: Tue, 25 Dec 2007 13:47:03 -0800 > > From: mika at async.caltech.edu > > > > Jay writes: > > > > > ... > > > > > >You know, I dare say, that platforms have been reduced and > converged enough= > > > such that..you can get rid of > > >Quake and move it into cm3. Um.. do any of the Unix platforms > support other= > > > than gcc? Other than GNU ld? > > > > I take it you don't mean "get rid of Quake" but "get rid of > cm3.cfg"? > > I would certainly agree that cm3.cfg is problematic. I have more > > than once had apparently unresolvable issues with CM3 that Tony > > fixed by sending me a new cm3.cfg, which came, seemingly, out of a > > hat... > > > > However I also would think it's a bad idea to reduce > configurability. > > As Olaf said, you'll miss it the moment it's gone. (Someone will.) > > Non-GNU Solaris and Digital Unix aren't that hard to support with > > the current code if someone wanted to, for instance. Why make such a > > hypothetical someone's work harder? (Just an example, I'm sure there > > are other things.) > > > > Mika > > Don't get caught with egg on your face. Play Chicktionary! Check it > out! From hosking at cs.purdue.edu Wed Dec 26 05:17:56 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 25 Dec 2007 23:17:56 -0500 Subject: [M3devel] PPC_DARWIN problems, at least config/5.2.6, maybe all moot In-Reply-To: References: Message-ID: On Dec 25, 2007, at 3:32 PM, Jay wrote: > 1) > > The documentation says -fPIC is the default, so I removed it. > But it matters. It doesn't matter for gcc building C. > It matters for m3cg building Modula-3. Please note that m3cg is based on the GNU release of gcc, *not* the Darwin version. Thus, even though Darwin might have -fPIC as default for Apple's gcc, GNU gcc might not. > It is the difference between, pic: > > jbook:/dev2/j/m3 jay$ cat Hello.m3 > MODULE Hello EXPORTS Main; > > IMPORT IO; > BEGIN > IO.Put("Hello\n"); > END Hello. > > jbook:/dev2/j/m3 jay$ cat PPC_DARWIN/Hello.ms > ... > bl L_IO__Put$stub > ... > .data > .picsymbol_stub > L_IO__Put$stub: > .indirect_symbol _IO__Put > mflr r0 > bcl 20,31,L0$_IO__Put > L0$_IO__Put: > mflr r11 > addis r11,r11,ha16(L_IO__Put$lazy_ptr-L0$_IO__Put) > mtlr r0 > lwz r12,lo16(L_IO__Put$lazy_ptr-L0$_IO__Put)(r11) > mtctr r12 > addi r11,r11,lo16(L_IO__Put$lazy_ptr-L0$_IO__Put) > bctr > .data > .lazy_symbol_pointer > L_IO__Put$lazy_ptr: > .indirect_symbol _IO__Put > .long dyld_stub_binding_helper > > vs. non-pic just plain wow only one whole function to make a call :) : > > jbook:/dev2/j/m3 jay$ cat PPC_DARWIN/Hello.ms > ... > bl _IO__Put > > which nets you the likes of: > > jbook:/dev2/j/m3 jay$ cm3 > -> linking prog > gcc -dynamic -o prog _m3main.o Hello.mo -L/cm3/pkg/libm3/ > PPC_DARWIN -lm3 -L/cm3/pkg/m3core/PPC_DARWIN -lm3core -L/cm3/bin/../ > lib -lm3gcdefs > /usr/bin/ld: _m3main.o has external relocation entries in non- > writable section (__TEXT,__text) for symbols: > _RTProcess__Exit > _RTLinker__AddUnit > _RTLinker__InitRuntime > collect2: ld returned 1 exit status > > > (Windows also only uses one instruction, through a pointer, for > dynamic calls, and the compiler often prefetches the pointer. > The difference is, perhaps, that Windows aggregates all the > pointers together, not sure about the other systems.. one instruction > through a pointer is true for x86 and AM64, not so of the former > MIPS, PowerPC, Alpha I believe or current IA64, those > require fetching/restore the GOT/TOC (same thing? I should know the > difference..) > > 2) > Splitting -L and -l off for shared libs matters. > > ld /foo/bar.a means link to bar.a, which is a static lib, not even > a stub lib or import lib like in Windows > > -L/foo -lbar probes for > /foo/bar.dylib > /foo/bar.a > > man ld: > -lx This option is an abbreviation for the library > name `libx.a', > where x is a string. If -dynamic is specified the > abbreviation > for the library name is first search as > `libx.dylib' and then > `libx.a' is searched for. ld searches for > libraries first in > any directories specified with -L options, then in > any directo- > ries specified in the colon separated set of paths in > the envi- > ronment variable LD_LIBRARY_PATH, then the standard > directories > /lib, /usr/lib, and /usr/local/lib. A library is > searched when > its name is encountered, so the placement of the -l > flag is sig- > nificant. If string x is of the form x.o, then > that file is > searched for in the same places, but without > prepending `lib' or > appending `.a' or `.dylib' to the filename. > > > 3) > lastly, setting DYLD_LIBRARY_PATH=/cm3/lib > lets the full paths from one machine not matter so much on another > machine. > > I am going to try out: > > before: > local lib_so = format ("lib%s.dylib", lib) > local lib_soxx = format ("lib%s.%s.dylib", lib, version) > local lib_pn = LIB_INSTALL & "/" & lib_soxx > > "-install_name", lib_pn, > > after: > > local lib_so = format ("lib%s.dylib", lib) > local lib_soxx = format ("lib%s.%s.dylib", lib, version) > local lib_pn = LIB_INSTALL & "/" & lib_soxx > > "-install_name", lib_soxx, > > see if a path is needed or can just use leaf names. > > - Jay > > From: jayk123 at hotmail.com > To: m3devel at elegosoft.com > Subject: PPC_DARWIN problems, at least config/5.2.6, maybe all moot > Date: Tue, 25 Dec 2007 12:09:31 +0000 > > PPC_DARWIN also has problems...at least in the config. > > > If you take the 5.2.6 archive, install to /dev2/cm3, accept the > defaults, > claim all the missing unused libs are in /usr/lib (opengl, > postgres, x11) > > > you end up with: > > > jbook:/dev2/j/m3 jay$ cat Hello.m3 > > > MODULE Hello EXPORTS Main; > IMPORT IO; > BEGIN > IO.Put("Hello\n"); > END Hello. > > > jbook:/dev2/j/m3 jay$ uname -a > Darwin jbook 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 > 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh > powerpc > > > jbook:/dev2/j/m3 jay$ cm3 -version > Critical Mass Modula-3 version 5.2.6 > last updated: 2003-06-27 > configuration: /cm3/bin/cm3.cfg > > > jbook:/dev2/j/m3 jay$ cm3 > new source -> compiling Hello.m3 > -> linking prog > > > jbook:/dev2/j/m3 jay$ PPC_DARWIN/prog > dyld: Library not loaded: /var/tmp/cm3/lib/libm3.5.2.dylib > Referenced from: /dev2/j/m3/PPC_DARWIN/prog > Reason: image not found > Trace/BPT trap > > > jbook:/dev2/j/m3 jay$ otool -L PPC_DARWIN/prog > PPC_DARWIN/prog: > /var/tmp/cm3/lib/libm3.5.2.dylib (compatibility version > 5.0.0, current version 5.2.0) > /Users/wagner/local/cm3/lib/libm3core.5.2.dylib > (compatibility version 5.0.0, current version 5.2.0) > /Users/wagner/local/cm3/lib/libm3gcdefs.5.2.dylib > (compatibility version 5.0.0, current version 5.2.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > current version 88.1.10) > /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, > current version 1.0.0) > > > jbook:/dev2/j/m3 jay$ ls -l PPC_DARWIN/prog > -rwxr-xr-x 1 jay admin 20264 Dec 25 04:43 PPC_DARWIN/prog > > > At the temporary cost of giving up dynamic linking, you can fix > this by removing M3_SPLIT_LIBNAMES_IF_SHARED > and/or M3_SPLIT_LIBNAMES from cm3.cfg, yielding: > > > jbook:/dev2/j/m3 jay$ otool -L PPC_DARWIN/prog > PPC_DARWIN/prog: > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > current version 88.1.10) > > > jbook:/dev2/j/m3 jay$ ls -l PPC_DARWIN/prog > -rwxr-xr-x 1 jay admin 1388380 Dec 25 04:48 PPC_DARWIN/prog > > > jbook:/dev2/j/m3 jay$ PPC_DARWIN/prog > Hello > > > I will fix the checked in config file...even though it varies a > bunch from the 5.2.6 distributed > config, it results in the same. > > > And, um, does everyone understand what I did with Win32 and making > cminstall obsolete? > Ok to do the same on Mac OS X? > You know, it's running things out of the path and/or finding them > in their "very standard" locations. > In fact, you can hard code full paths and be ok. > That is, instead of asking the user where their compiler is, > hardcoding any of cc, gcc, /usr/bin/cc, /usr/bin/gcc all work fine. > Asking them where ar/ranlib are, similar, though the docs say that > libtool replaced those, and ar/ranlib vs. libtool is one way > in which the checked in config and the 5.2.6 distribution's config > vary. I'll try for libtool. > > > The only thing the user really needs to decide is where to install > to, and > the cfg file can discover their choice without any editing. > > > INSTALL_ROOT = path() & "/.." > BIN_INSTALL = path() % executables > > > In terms of wanting to provide some configurable redirection, well, > I think an advanced user can manage.. > An indirect SYSTEM_CC = "cc" can be left, I guess. > > > You know, I dare say, that platforms have been reduced and > converged enough such that..you can get rid of > Quake and move it into cm3. Um.. do any of the Unix platforms > support other than gcc? Other than GNU ld? > Ok, Apple ld is not GNU ld. (Geez, it is just me or is Apple an > incredible hodgepodge mess these days? > I mean both in terms of their "system architecture" and their > tools. The "system architecture" reveals bunches > of similar redundant subsystems. Try reading through man ld, man > ranlib, just try to understand which > flag goes with which mode, which flags are for compatibility with > which OS version, and which of the > compatibility flags is either ignored or does something useful... > and should I say -lGL or -framework OpenGL??) > > > That I don't haven't adjusted to Modula-3 and don't mind/prefer > writing Quake instead. :) > > > Some bootstrap was provided. I should look at it, and its config. > Otherwise..I'll look into what it takes to build it all and with > dynamic linking. > Perhaps the bootstrap is just fine. But the checked in config is not. > > > - Jay > > Share life as it happens with the new Windows Live. Share now! > Share life as it happens with the new Windows Live. Share now! From jayk123 at hotmail.com Wed Dec 26 06:51:04 2007 From: jayk123 at hotmail.com (Jay) Date: Wed, 26 Dec 2007 05:51:04 +0000 Subject: [M3devel] PPC_DARWIN problems, at least config/5.2.6, maybe all moot In-Reply-To: References: Message-ID: Oh, very good point. "gcc" is Apple and resembles "man gcc", "m3cg" not.. - Jay > CC: m3devel at elegosoft.com > From: hosking at cs.purdue.edu > Subject: Re: [M3devel] PPC_DARWIN problems, at least config/5.2.6, maybe all moot > Date: Tue, 25 Dec 2007 23:17:56 -0500 > To: jayk123 at hotmail.com > > > On Dec 25, 2007, at 3:32 PM, Jay wrote: > > > 1) > > > > The documentation says -fPIC is the default, so I removed it. > > But it matters. It doesn't matter for gcc building C. > > It matters for m3cg building Modula-3. > > Please note that m3cg is based on the GNU release of gcc, *not* the > Darwin version. Thus, even though Darwin might have -fPIC as default > for Apple's gcc, GNU gcc might not. > > > It is the difference between, pic: > > > > jbook:/dev2/j/m3 jay$ cat Hello.m3 > > MODULE Hello EXPORTS Main; > > > > IMPORT IO; > > BEGIN > > IO.Put("Hello\n"); > > END Hello. > > > > jbook:/dev2/j/m3 jay$ cat PPC_DARWIN/Hello.ms > > ... > > bl L_IO__Put$stub > > ... > > .data > > .picsymbol_stub > > L_IO__Put$stub: > > .indirect_symbol _IO__Put > > mflr r0 > > bcl 20,31,L0$_IO__Put > > L0$_IO__Put: > > mflr r11 > > addis r11,r11,ha16(L_IO__Put$lazy_ptr-L0$_IO__Put) > > mtlr r0 > > lwz r12,lo16(L_IO__Put$lazy_ptr-L0$_IO__Put)(r11) > > mtctr r12 > > addi r11,r11,lo16(L_IO__Put$lazy_ptr-L0$_IO__Put) > > bctr > > .data > > .lazy_symbol_pointer > > L_IO__Put$lazy_ptr: > > .indirect_symbol _IO__Put > > .long dyld_stub_binding_helper > > > > vs. non-pic just plain wow only one whole function to make a call :) : > > > > jbook:/dev2/j/m3 jay$ cat PPC_DARWIN/Hello.ms > > ... > > bl _IO__Put > > > > which nets you the likes of: > > > > jbook:/dev2/j/m3 jay$ cm3 > > -> linking prog > > gcc -dynamic -o prog _m3main.o Hello.mo -L/cm3/pkg/libm3/ > > PPC_DARWIN -lm3 -L/cm3/pkg/m3core/PPC_DARWIN -lm3core -L/cm3/bin/../ > > lib -lm3gcdefs > > /usr/bin/ld: _m3main.o has external relocation entries in non- > > writable section (__TEXT,__text) for symbols: > > _RTProcess__Exit > > _RTLinker__AddUnit > > _RTLinker__InitRuntime > > collect2: ld returned 1 exit status > > > > > > (Windows also only uses one instruction, through a pointer, for > > dynamic calls, and the compiler often prefetches the pointer. > > The difference is, perhaps, that Windows aggregates all the > > pointers together, not sure about the other systems.. one instruction > > through a pointer is true for x86 and AM64, not so of the former > > MIPS, PowerPC, Alpha I believe or current IA64, those > > require fetching/restore the GOT/TOC (same thing? I should know the > > difference..) > > > > 2) > > Splitting -L and -l off for shared libs matters. > > > > ld /foo/bar.a means link to bar.a, which is a static lib, not even > > a stub lib or import lib like in Windows > > > > -L/foo -lbar probes for > > /foo/bar.dylib > > /foo/bar.a > > > > man ld: > > -lx This option is an abbreviation for the library > > name `libx.a', > > where x is a string. If -dynamic is specified the > > abbreviation > > for the library name is first search as > > `libx.dylib' and then > > `libx.a' is searched for. ld searches for > > libraries first in > > any directories specified with -L options, then in > > any directo- > > ries specified in the colon separated set of paths in > > the envi- > > ronment variable LD_LIBRARY_PATH, then the standard > > directories > > /lib, /usr/lib, and /usr/local/lib. A library is > > searched when > > its name is encountered, so the placement of the -l > > flag is sig- > > nificant. If string x is of the form x.o, then > > that file is > > searched for in the same places, but without > > prepending `lib' or > > appending `.a' or `.dylib' to the filename. > > > > > > 3) > > lastly, setting DYLD_LIBRARY_PATH=/cm3/lib > > lets the full paths from one machine not matter so much on another > > machine. > > > > I am going to try out: > > > > before: > > local lib_so = format ("lib%s.dylib", lib) > > local lib_soxx = format ("lib%s.%s.dylib", lib, version) > > local lib_pn = LIB_INSTALL & "/" & lib_soxx > > > > "-install_name", lib_pn, > > > > after: > > > > local lib_so = format ("lib%s.dylib", lib) > > local lib_soxx = format ("lib%s.%s.dylib", lib, version) > > local lib_pn = LIB_INSTALL & "/" & lib_soxx > > > > "-install_name", lib_soxx, > > > > see if a path is needed or can just use leaf names. > > > > - Jay > > > > From: jayk123 at hotmail.com > > To: m3devel at elegosoft.com > > Subject: PPC_DARWIN problems, at least config/5.2.6, maybe all moot > > Date: Tue, 25 Dec 2007 12:09:31 +0000 > > > > PPC_DARWIN also has problems...at least in the config. > > > > > > If you take the 5.2.6 archive, install to /dev2/cm3, accept the > > defaults, > > claim all the missing unused libs are in /usr/lib (opengl, > > postgres, x11) > > > > > > you end up with: > > > > > > jbook:/dev2/j/m3 jay$ cat Hello.m3 > > > > > > MODULE Hello EXPORTS Main; > > IMPORT IO; > > BEGIN > > IO.Put("Hello\n"); > > END Hello. > > > > > > jbook:/dev2/j/m3 jay$ uname -a > > Darwin jbook 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 > > 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh > > powerpc > > > > > > jbook:/dev2/j/m3 jay$ cm3 -version > > Critical Mass Modula-3 version 5.2.6 > > last updated: 2003-06-27 > > configuration: /cm3/bin/cm3.cfg > > > > > > jbook:/dev2/j/m3 jay$ cm3 > > new source -> compiling Hello.m3 > > -> linking prog > > > > > > jbook:/dev2/j/m3 jay$ PPC_DARWIN/prog > > dyld: Library not loaded: /var/tmp/cm3/lib/libm3.5.2.dylib > > Referenced from: /dev2/j/m3/PPC_DARWIN/prog > > Reason: image not found > > Trace/BPT trap > > > > > > jbook:/dev2/j/m3 jay$ otool -L PPC_DARWIN/prog > > PPC_DARWIN/prog: > > /var/tmp/cm3/lib/libm3.5.2.dylib (compatibility version > > 5.0.0, current version 5.2.0) > > /Users/wagner/local/cm3/lib/libm3core.5.2.dylib > > (compatibility version 5.0.0, current version 5.2.0) > > /Users/wagner/local/cm3/lib/libm3gcdefs.5.2.dylib > > (compatibility version 5.0.0, current version 5.2.0) > > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > > current version 88.1.10) > > /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, > > current version 1.0.0) > > > > > > jbook:/dev2/j/m3 jay$ ls -l PPC_DARWIN/prog > > -rwxr-xr-x 1 jay admin 20264 Dec 25 04:43 PPC_DARWIN/prog > > > > > > At the temporary cost of giving up dynamic linking, you can fix > > this by removing M3_SPLIT_LIBNAMES_IF_SHARED > > and/or M3_SPLIT_LIBNAMES from cm3.cfg, yielding: > > > > > > jbook:/dev2/j/m3 jay$ otool -L PPC_DARWIN/prog > > PPC_DARWIN/prog: > > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > > current version 88.1.10) > > > > > > jbook:/dev2/j/m3 jay$ ls -l PPC_DARWIN/prog > > -rwxr-xr-x 1 jay admin 1388380 Dec 25 04:48 PPC_DARWIN/prog > > > > > > jbook:/dev2/j/m3 jay$ PPC_DARWIN/prog > > Hello > > > > > > I will fix the checked in config file...even though it varies a > > bunch from the 5.2.6 distributed > > config, it results in the same. > > > > > > And, um, does everyone understand what I did with Win32 and making > > cminstall obsolete? > > Ok to do the same on Mac OS X? > > You know, it's running things out of the path and/or finding them > > in their "very standard" locations. > > In fact, you can hard code full paths and be ok. > > That is, instead of asking the user where their compiler is, > > hardcoding any of cc, gcc, /usr/bin/cc, /usr/bin/gcc all work fine. > > Asking them where ar/ranlib are, similar, though the docs say that > > libtool replaced those, and ar/ranlib vs. libtool is one way > > in which the checked in config and the 5.2.6 distribution's config > > vary. I'll try for libtool. > > > > > > The only thing the user really needs to decide is where to install > > to, and > > the cfg file can discover their choice without any editing. > > > > > > INSTALL_ROOT = path() & "/.." > > BIN_INSTALL = path() % executables > > > > > > In terms of wanting to provide some configurable redirection, well, > > I think an advanced user can manage.. > > An indirect SYSTEM_CC = "cc" can be left, I guess. > > > > > > You know, I dare say, that platforms have been reduced and > > converged enough such that..you can get rid of > > Quake and move it into cm3. Um.. do any of the Unix platforms > > support other than gcc? Other than GNU ld? > > Ok, Apple ld is not GNU ld. (Geez, it is just me or is Apple an > > incredible hodgepodge mess these days? > > I mean both in terms of their "system architecture" and their > > tools. The "system architecture" reveals bunches > > of similar redundant subsystems. Try reading through man ld, man > > ranlib, just try to understand which > > flag goes with which mode, which flags are for compatibility with > > which OS version, and which of the > > compatibility flags is either ignored or does something useful... > > and should I say -lGL or -framework OpenGL??) > > > > > > That I don't haven't adjusted to Modula-3 and don't mind/prefer > > writing Quake instead. :) > > > > > > Some bootstrap was provided. I should look at it, and its config. > > Otherwise..I'll look into what it takes to build it all and with > > dynamic linking. > > Perhaps the bootstrap is just fine. But the checked in config is not. > > > > > > - Jay > > > > Share life as it happens with the new Windows Live. Share now! > > Share life as it happens with the new Windows Live. Share now! > _________________________________________________________________ The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. http://www.xbox.com/en-US/hardware/wheretobuy/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Wed Dec 26 06:55:22 2007 From: jayk123 at hotmail.com (Jay) Date: Wed, 26 Dec 2007 05:55:22 +0000 Subject: [M3devel] when to change version numbers in .dlls/.sos/.dylibs? In-Reply-To: References: Message-ID: There's a mix of versions in the configurations. Presumably at the moment they should all be 5.5 and derive from one shared statement of the version??? jbook:/dev2/cm3/m3-sys/cminstall/src/config jay$ grep %s.dylib * I386_DARWIN: local lib_so = format ("lib%s.dylib", lib) I386_DARWIN: local lib_sox = format ("lib%s.%s.dylib", lib, vmaj) I386_DARWIN: local lib_soxx = format ("lib%s.%s.dylib", lib, version) I386_DARWIN: local lib_so = format ("lib%s.dylib", lib) I386_DARWIN: local lib_sox = format ("lib%s.%s.dylib", lib, vmaj) I386_DARWIN: local lib_soxx = format ("lib%s.%s.dylib", lib, version) PPC_DARWIN: local lib_so = format ("lib%s.dylib", lib) PPC_DARWIN: local lib_sox = format ("lib%s.%s.dylib", lib, vmaj) PPC_DARWIN: local lib_soxx = format ("lib%s.%s.dylib", lib, version) PPC_DARWIN: local lib_so = format ("lib%s.dylib", lib) PPC_DARWIN: local lib_sox = format ("lib%s.%s.dylib", lib, vmaj) PPC_DARWIN: local lib_soxx = format ("lib%s.%s.dylib", lib, version) jbook:/dev2/cm3/m3-sys/cminstall/src/config jay$ grep so.1 * SPARC: local lib_so = format ("lib%s.so.1.1", lib) SPARC: local lib_so = format ("lib%s.so.1.1", lib) jbook:/dev2/cm3/m3-sys/cminstall/src/config jay$ grep so.4 * LINUXELF: local lib_sox = format ("lib%s.so.4", lib) LINUXELF: local lib_soxx = format ("lib%s.so.4.1", lib) LINUXELF: local lib_sox = format ("lib%s.so.4", lib) LINUXELF: local lib_soxx = format ("lib%s.so.4.1", lib) jbook:/dev2/cm3/m3-sys/cminstall/src/config jay$ grep so.5 * FreeBSD3: local lib_sox = format ("lib%s.so.5", lib) FreeBSD3: local lib_soxx = format ("lib%s.so.5.1", lib) FreeBSD3: local lib_sox = format ("lib%s.so.5", lib) FreeBSD4: local lib_sox = format ("lib%s.so.5", lib) FreeBSD4: local lib_soxx = format ("lib%s.so.5.1", lib) FreeBSD4: local lib_sox = format ("lib%s.so.5", lib) LINUXLIBC6: local lib_sox = format ("lib%s.so.5", lib) LINUXLIBC6: local lib_sox = format ("lib%s.so.5", lib) NT386GNU: local lib_sox = format ("lib%s.so.5", lib) NT386GNU: local lib_sox = format ("lib%s.so.5", lib) NetBSD2_i386: local lib_sox = format ("lib%s.so.5", lib) NetBSD2_i386: local lib_soxx = format ("lib%s.so.5.1", lib) NetBSD2_i386: local lib_sox = format ("lib%s.so.5", lib) NetBSD2_i386: local lib_soxx = format ("lib%s.so.5.1", lib) PPC_LINUX: local lib_sox = format ("lib%s.so.5", lib) PPC_LINUX: local lib_sox = format ("lib%s.so.5", lib) SOLgnu: local lib_sox = format ("lib%s.so.5", lib) SOLgnu: local lib_sox = format ("lib%s.so.5", lib) SOLsun: local lib_sox = format ("lib%s.so.5", lib) SOLsun: local lib_sox = format ("lib%s.so.5", lib) _________________________________________________________________ The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. http://www.xbox.com/en-US/hardware/wheretobuy/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Dec 28 09:25:21 2007 From: jayk123 at hotmail.com (Jay) Date: Fri, 28 Dec 2007 08:25:21 +0000 Subject: [M3devel] wierdness around user overrides vs. uname in sysinfo.sh? Message-ID: I wanted to change upgrade.sh to have the following features: 1) optionally skip building m3cc, since it is the slowest part 2) optionally clean between various steps, as was apparently necessary for me I really cannot hack sh though. Sorry. I've tried several times through the years. I just can't stand these languages where pretty much everything is a string. e.g. sh, Tcl, cmd. I admit hypocrisy in that I can and have hacked cmd. So I started rewriting scripts/* in Python. I'm not going to delete scripts/*.sh or anything THAT obnoxious (and get my access revoked), just add a new scripts/python directory. Tempting to call it scripts/jay. I'm making good progess here. Actually I started with Perl, which I have more experience with, but it was frustrating and... Anyway, so the real point here is, I'm reading scripts/* fairly closely. I'd like to at times bounce my interpretation off folks. In particular, I detect some wierdness. Most variables can be set by the caller. I assume that is mostly meant for the user to override things. I agree that is mostly a good thing. However it seems often data is derived, and then later overrides can kick in. In particular, sysinfo.sh sets, e.g. M3OSTYPE and other data based on uname. And it sets CM3_TARGET. But TARGET is then set via the user override, or CM3_TARGET if no user override. I draw one of two conclusions: If a user sets TARGET, such as for a cross build, then user darn well better set other variables manually to. OR sysinfo.sh ought to check for TARGET being set, and derive data from that. It should check preset TARGET or uname, not both. I'm just going to leave it alone. Presumably mostly the overrides are never set. They are mainly for cross builds and/or bringing up new targets probably. There aren't THAT MANY variables anyway. Many could be removed, such as TAR, GREP, CM3*SEARCHPATH, etc. Some are only for Win32. Maybe after this I'll try rewriting scripts in Quake. :) - Jay _________________________________________________________________ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_122007 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Dec 28 11:19:53 2007 From: jayk123 at hotmail.com (Jay) Date: Fri, 28 Dec 2007 10:19:53 +0000 Subject: [M3devel] wierdness around user overrides vs. uname in sysinfo.sh? In-Reply-To: References: Message-ID: hm. another odd email truncation Let me try again.. I wanted to change upgrade.sh to have the following features: 1) optionally skip building m3cc, since it is the slowest part 2) optionally clean between various steps, as was apparently necessary for me I really cannot hack sh though. Sorry. I've tried several times through the years. I just can't stand these languages where pretty much everything is a string. e.g. sh, Tcl, cmd. I admit hypocrisy in that I can and have hacked cmd. So I started rewriting scripts/* in Python. I'm not going to delete scripts/*.sh or anything THAT obnoxious (and get my access revoked), just add a new scripts/python directory. Tempting to call it scripts/jay. I'm making good progess here. Actually I started with Perl, which I have more experience with, but it was frustrating and... Anyway, so the real point here is, I'm reading scripts/* fairly closely (I can read sh well enough.) I'd like to at times bounce my interpretation off folks. In particular, I detect some wierdness. Most variables can be set by the caller. I assume that is mostly meant for the user to override things. I agree that is mostly a good thing. However it seems often data is derived, and then later overrides can kick in. In particular, sysinfo.sh sets, e.g. M3OSTYPE and other data based on uname. And it sets CM3_TARGET. But TARGET is then set via the user override, or CM3_TARGET if no user override. I draw one of two conclusions: If a user sets TARGET, such as for a cross build, then user darn well better set other variables manually too. OR sysinfo.sh ought to check for TARGET being set, and derive data from that. It should check preset TARGET or uname, not both. I'm just going to leave it alone. Presumably mostly the overrides are never set. They are mainly for cross builds and/or bringing up new targets probably. There aren't THAT MANY variables anyway. Many could be removed, such as TAR, GREP, CM3*SEARCHPATH, etc. Some are only for Win32. Maybe after this I'll try rewriting scripts in Quake. :) - Jay _________________________________________________________________ The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. http://www.xbox.com/en-US/hardware/wheretobuy/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Dec 28 12:13:43 2007 From: jayk123 at hotmail.com (Jay) Date: Fri, 28 Dec 2007 11:13:43 +0000 Subject: [M3devel] wierdness around user overrides vs. uname in sysinfo.sh? In-Reply-To: References: Message-ID: wierd.still shows as truncated for me Trying again with a different browser.. I wanted to change upgrade.sh to have the following features: 1) optionally skip building m3cc, since it is the slowest part 2) optionally clean between various steps, as was apparently necessary for me I really cannot hack sh though. Sorry. I've tried several times through the years. I just can't stand these languages where pretty much everything is a string. e.g. sh, Tcl, cmd. I admit hypocrisy in that I can and have hacked cmd. So I started rewriting scripts/* in Python. I'm not going to delete scripts/*.sh or anything THAT obnoxious (and get my access revoked), just add a new scripts/python directory. Tempting to call it scripts/jay. I'm making good progess here. Actually I started with Perl, which I have more experience with, but it was frustrating and... Anyway, so the real point here is, I'm reading scripts/* fairly closely. I'd like to at times bounce my interpretation off folks. In particular, I detect some massive wierdness. Most variables can be set by the caller. I assume that is mostly meant for the user to override things. I agree that is mostly a good thing. However it seems often data is derived, and then later overrides can kick in. In particular, sysinfo.sh sets, e.g. M3OSTYPE and other data based on uname. And it sets CM3_TARGET. But TARGET is then set via the user override, or CM3_TARGET if no user override. I draw one of two conclusions: If a user sets TARGET, such as for a cross build, then user darn well better set other variables manually to. OR sysinfo.sh ought to check for TARGET being set, and derive data from that. It should check preset TARGET or uname, not both. I'm just going to leave it alone. Presumably mostly the overrides are never set. They are mainly for cross builds and/or bringing up new targets probably. There aren't THAT MANY variables anyway. Many could be removed, such as TAR, GREP, CM3*SEARCHPATH, etc. Some are only for Win32. Maybe after this I'll try rewriting scripts in Quake. :) - Jay _________________________________________________________________ The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. http://www.xbox.com/en-US/hardware/wheretobuy/ From jayk123 at hotmail.com Fri Dec 28 12:13:44 2007 From: jayk123 at hotmail.com (Jay) Date: Fri, 28 Dec 2007 11:13:44 +0000 Subject: [M3devel] wierdness around user overrides vs. uname in sysinfo.sh? In-Reply-To: References: Message-ID: wierd.still shows as truncated for me Trying again with a different browser.. I wanted to change upgrade.sh to have the following features: 1) optionally skip building m3cc, since it is the slowest part 2) optionally clean between various steps, as was apparently necessary for me I really cannot hack sh though. Sorry. I've tried several times through the years. I just can't stand these languages where pretty much everything is a string. e.g. sh, Tcl, cmd. I admit hypocrisy in that I can and have hacked cmd. So I started rewriting scripts/* in Python. I'm not going to delete scripts/*.sh or anything THAT obnoxious (and get my access revoked), just add a new scripts/python directory. Tempting to call it scripts/jay. I'm making good progess here. Actually I started with Perl, which I have more experience with, but it was frustrating and... Anyway, so the real point here is, I'm reading scripts/* fairly closely. I'd like to at times bounce my interpretation off folks. In particular, I detect some massive wierdness. Most variables can be set by the caller. I assume that is mostly meant for the user to override things. I agree that is mostly a good thing. However it seems often data is derived, and then later overrides can kick in. In particular, sysinfo.sh sets, e.g. M3OSTYPE and other data based on uname. And it sets CM3_TARGET. But TARGET is then set via the user override, or CM3_TARGET if no user override. I draw one of two conclusions: If a user sets TARGET, such as for a cross build, then user darn well better set other variables manually to. OR sysinfo.sh ought to check for TARGET being set, and derive data from that. It should check preset TARGET or uname, not both. I'm just going to leave it alone. Presumably mostly the overrides are never set. They are mainly for cross builds and/or bringing up new targets probably. There aren't THAT MANY variables anyway. Many could be removed, such as TAR, GREP, CM3*SEARCHPATH, etc. Some are only for Win32. Maybe after this I'll try rewriting scripts in Quake. :) - Jay _________________________________________________________________ Don't get caught with egg on your face. Play Chicktionary! http://club.live.com/chicktionary.aspx?icid=chick_wlhmtextlink1_dec From jayk123 at hotmail.com Fri Dec 28 12:17:53 2007 From: jayk123 at hotmail.com (Jay) Date: Fri, 28 Dec 2007 11:17:53 +0000 Subject: [M3devel] =?windows-1256?q?_Re=3A__wierdness_around_user_override?= =?windows-1256?q?s_vs=2E_uname_in_sysinfo=2Esh=3F=FE?= In-Reply-To: References: Message-ID: [another tactic attempted...] ---------------------------------------- > From: jayk123 at hotmail.com > To: jayk123 at hotmail.com > Subject: test > Date: Fri, 28 Dec 2007 11:15:58 +0000 > > > I wanted to change upgrade.sh to have the following features: > > 1) optionally skip building m3cc, since it is the slowest part > > 2) optionally clean between various steps, as was apparently necessary for me > > I really cannot hack sh though. Sorry. I've tried several times through the years. > I just can't stand these languages where pretty much everything is a string. > e.g. sh, Tcl, cmd. > I admit hypocrisy in that I can and have hacked cmd. > > So I started rewriting scripts/* in Python. > I'm not going to delete scripts/*.sh or anything THAT obnoxious (and get my > access revoked), just add a new scripts/python directory. > Tempting to call it scripts/jay. > I'm making good progess here. > > Actually I started with Perl, which I have more experience with, but > it was frustrating and... > > Anyway, so the real point here is, I'm reading scripts/* fairly closely. > > I'd like to at times bounce my interpretation off folks. > > In particular, I detect some massive wierdness. > > Most variables can be set by the caller. > I assume that is mostly meant for the user to override things. > I agree that is mostly a good thing. > > However it seems often data is derived, and then later overrides can kick in. > > In particular, sysinfo.sh sets, e.g. M3OSTYPE and other data based on uname. > And it sets CM3_TARGET. > But TARGET is then set via the user override, or CM3_TARGET if no user override. > > I draw one of two conclusions: > > If a user sets TARGET, such as for a cross build, then user darn well better > set other variables manually to. > > OR sysinfo.sh ought to check for TARGET being set, and derive data from that. > It should check preset TARGET or uname, not both. > > I'm just going to leave it alone. > > Presumably mostly the overrides are never set. > They are mainly for cross builds and/or bringing up new targets probably. > > There aren't THAT MANY variables anyway. > Many could be removed, such as TAR, GREP, CM3*SEARCHPATH, etc. > Some are only for Win32. > > Maybe after this I'll try rewriting scripts in Quake. :) > > - Jay > _________________________________________________________________ > Share life as it happens with the new Windows Live. > http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007 _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007 From wagner at elegosoft.com Fri Dec 28 17:35:40 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 28 Dec 2007 17:35:40 +0100 Subject: [M3devel] =?utf-8?q?wierdness_around_user_overrides_vs=2E_uname_i?= =?utf-8?b?biBzeXNpbmZvLnNoP+KAjw==?= In-Reply-To: References: Message-ID: <20071228173540.eesjz81kuso8okg4@mail.elegosoft.com> Quoting Jay : > > [another tactic attempted...] > > ---------------------------------------- >> From: jayk123 at hotmail.com >> To: jayk123 at hotmail.com >> Subject: test >> Date: Fri, 28 Dec 2007 11:15:58 +0000 >> >> >> I wanted to change upgrade.sh to have the following features: >> >> 1) optionally skip building m3cc, since it is the slowest part export OMIT_GCC=yes will do just that for all shell scripts, IIRC. >> 2) optionally clean between various steps, as was apparently >> necessary for me It should not be difficult to add that. Something like . "$ROOT/scripts/do-cm3-core.sh" realclean || exit 1 should do the trick. >> I really cannot hack sh though. Sorry. I've tried several times >> through the years. >> I just can't stand these languages where pretty much everything is a string. >> e.g. sh, Tcl, cmd. >> I admit hypocrisy in that I can and have hacked cmd. >> >> So I started rewriting scripts/* in Python. >> I'm not going to delete scripts/*.sh or anything THAT obnoxious (and get my >> access revoked), just add a new scripts/python directory. >> Tempting to call it scripts/jay. >> I'm making good progess here. No harm in that. You may either put the python scripts beside the shell scripts and simply call them *.py, or put them in a subdirectory python or py. Don't call it Jay. >> Actually I started with Perl, which I have more experience with, but >> it was frustrating and... >> >> Anyway, so the real point here is, I'm reading scripts/* fairly closely. >> >> I'd like to at times bounce my interpretation off folks. >> >> In particular, I detect some massive wierdness. >> >> Most variables can be set by the caller. >> I assume that is mostly meant for the user to override things. >> I agree that is mostly a good thing. >> >> However it seems often data is derived, and then later overrides >> can kick in. These are just some simple and useful scripts for maintenance; there was never an overall system design. >> In particular, sysinfo.sh sets, e.g. M3OSTYPE and other data based on uname. >> And it sets CM3_TARGET. >> But TARGET is then set via the user override, or CM3_TARGET if no >> user override. >> >> I draw one of two conclusions: >> >> If a user sets TARGET, such as for a cross build, then user darn well better >> set other variables manually to. >> >> OR sysinfo.sh ought to check for TARGET being set, and derive data >> from that. >> It should check preset TARGET or uname, not both. >> >> I'm just going to leave it alone. If you find obvious inconsistencies or mistakes, don't hesitate to suggest a correction. >> Presumably mostly the overrides are never set. >> They are mainly for cross builds and/or bringing up new targets probably. Cross building is the usual way of porting the compiler to a new target, so it's done more often than you might assume. I've done it lots of times. >> There aren't THAT MANY variables anyway. >> Many could be removed, such as TAR, GREP, CM3*SEARCHPATH, etc. >> Some are only for Win32. >> >> Maybe after this I'll try rewriting scripts in Quake. :) That would be interesting, too. But don't forget that all these scripts are just more or less simple tools for installation and maintenance; the important asset is in all the M3 code. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Fri Dec 28 17:55:16 2007 From: jayk123 at hotmail.com (Jay) Date: Fri, 28 Dec 2007 16:55:16 +0000 Subject: [M3devel] wierdness around user overrides vs. uname in sysinfo.sh? In-Reply-To: <20071228173540.eesjz81kuso8okg4@mail.elegosoft.com> References: <20071228173540.eesjz81kuso8okg4@mail.elegosoft.com> Message-ID: inline (but aggressively trimmed) > Date: Fri, 28 Dec 2007 17:35:40 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > > Quoting Jay : > > export OMIT_GCC=yes > > will do just that for all shell scripts, IIRC. Ah, thanks, will try that. > >> 2) optionally clean between various steps, as was apparently > >> necessary for me > > It should not be difficult to add that. Something like > > . "$ROOT/scripts/do-cm3-core.sh" realclean || exit 1 > > should do the trick. Yeah, I have that locally, but I wanted to make it an option since perhaps/apparently it isn't always needed, and therefore wastes time. And then I got all bogged down in how the command line parsing is shared and I didn't want to add a parameter to every script, and I couldn't figure out how to check the command line ahead of time and then remove what I recognize. Like, if I could assign empty strings to $1 or $2 or $3, would be nice..but seems not possible..and then it just comes back to my strong suspicion that sh just sucks and isn't worth the effort. > don't forget that all these scripts are just... > ...the important asset is in all the M3 code. I know...but... Modula-3 is really slow to grow on me.. this has actually been a very useful exercise in my long delayed adoption of Python. I got my dynamic linking/pic issues worked out and once I get to porting make-bin-dist I'll have it work like my Win32 version -- just a .tar.bz2 file that you extract in the install root or above the install root (still not sure about the archive's root being cm3 or cm3-version or within that).. really, cminstall seems pretty pointless... Index: upgrade.sh =================================================================== RCS file: /usr/cvs/cm3/scripts/upgrade.sh,v retrieving revision 1.3 diff -c -r1.3 upgrade.sh *** upgrade.sh 16 Dec 2007 17:56:24 -0000 1.3 --- upgrade.sh 28 Dec 2007 16:51:34 -0000 *************** *** 28,34 **** some accidental diff here.. *************** *** 50,61 **** --- 50,72 ---- P="${P} cm3" [ "${M3OSTYPE}" = "WIN32" ] && P="${P} mklib" + echo "$ROOT/scripts/do-pkg.sh" "$@" "realclean ${P}" + . "$ROOT/scripts/do-pkg.sh" "$@" "realclean" ${P} || exit 1 + + exit + echo "$ROOT/scripts/do-pkg.sh" "$@" "buildship ${P}" . "$ROOT/scripts/do-pkg.sh" "$@" "buildship" ${P} || exit 1 echo "$ROOT/scripts/install-cm3-compiler.sh" $OPTIONS upgrade "$ROOT/scripts/install-cm3-compiler.sh" $OPTIONS upgrade || exit 1 + echo "$ROOT/scripts/do-pkg.sh" "$@" "realclean ${P}" + . "$ROOT/scripts/do-pkg.sh" "$@" "realclean" ${P} || exit 1 + + echo "$ROOT/scripts/do-cm3-core.sh" "$@" "realclean" + . "$ROOT/scripts/do-cm3-core.sh" "$@" "realclean" || exit 1 + echo "$ROOT/scripts/do-cm3-core.sh" "$@" "buildship" . "$ROOT/scripts/do-cm3-core.sh" "$@" "buildship" || exit 1 - Jay _________________________________________________________________ i?m is proud to present Cause Effect, a series about real people making a difference. http://im.live.com/Messenger/IM/MTV/?source=text_Cause_Effect -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Dec 31 10:48:26 2007 From: jayk123 at hotmail.com (Jay) Date: Mon, 31 Dec 2007 09:48:26 +0000 Subject: [M3devel] cvs question: how to know what I have changed on my machine? In-Reply-To: <20071230163328.GB5689@elegosoft.com> References: <20071230163328.GB5689@elegosoft.com> Message-ID: I swear I looked for this on the web, several times. :) What is the right/fast way to see what I have changed in cvs? Is it really to go to the top of the tree and say cvs diff? Some source control system I have used, makes "checked in" filesread only, requires you to "check out", and keeps track of whatyou checked out.This model seems quite nice.There is a fallback if the network is needed and not available.It is a little annoying, the inevitable failed save, but it is well worth it. I've been doing cvs diff but it seem terribly inefficient. Same question for Subversion, though I haven't looked.It at least seems to rapidly know what I have changed, on my puny tree,and I know it also saves away all the originals, so diff is a client only operation. Oh another question -- how to view history?Like, what i keep doing is navigating to individual files on the web.It's fairly tedious.It'd be nice if checkins at right about the same time, with the same comment,where packaged up in the ui, like Perforce (well, for it, it is just one change)....I usually look at the diffs after commit, besides before. Thanks, - Jay _________________________________________________________________ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Dec 31 21:29:59 2007 From: jayk123 at hotmail.com (Jay) Date: Mon, 31 Dec 2007 20:29:59 +0000 Subject: [M3devel] C/C++ interop/linking thoughts? Message-ID: C/C++ interop/linking thoughts? What are people's thoughts on interop with and C and C++? In particular, that of static linking C and C++ with Modula-3, in the same .dll/.so/.exe?Or that of loading a Modula-3 .dll/.so into a process that is otherwise just C and C++? I ask for NOT the most important of reasons. The Modula-3 dependency on the C runtime on Windows is pretty light, and it is in fact mostly for the startup code. The startup code doesn't do much. Mainly it runs C++ constructors/destructors. And C code can have initializers/cleanup. I think it might be interesting to drive this dependency to zero, but it depends on expectations of C and C++ statically linked into a Modula-3 .dll/.so/.exe working. I know there is C code in the system already. It is light. It works without the startup code in my experience. I already changed Modula-3 .dlls to build with /noentry..exes take a bit more.It's in the config file. There are comments in the config file about it, including the contrary point of a C generating back end . On a very related note, I almost forgot..on Mac OS X, there is shared or static libgcc. The man pages say roughly this: g++ and gcj (Java) specify shared libgcc by default gcc specifies static libgcc by default C++ and Java favor shared in order to enable throwing/catching exceptions across .dll/.so boundaries. "Pure" Modula-3 code wouldn't care about that. Modula-3 code linking with C++ might. Perhaps in these scenarios, the "build system" and linking will tend to escape cm3 anyway?Make Modula-3 static .libs/.a with cm3 but not link the final file with it? I think the current config file links .dylibs(.dll/.so, but usually .dylib in this context, at least by convention) with static libgcc and executables with shared. I found in groveling over the results that, there were four or six functions imported from shared libgcc, little math helpers for division or such. It seems not worth depending on another file for just a few small functions. Just use static? On a less related note, for anyone who likes to go down such paths, I concluded that calling ld directly on Mac OS X is not a great idea, best stick to calling gcc (or g++/whatever) to do the linking, as the current files do. - Jay _________________________________________________________________ i?m is proud to present Cause Effect, a series about real people making a difference. http://im.live.com/Messenger/IM/MTV/?source=text_Cause_Effect -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Dec 31 12:04:53 2007 From: jayk123 at hotmail.com (Jay) Date: Mon, 31 Dec 2007 11:04:53 +0000 Subject: [M3devel] "where to root archives?" In-Reply-To: <20071230162432.C498A10D4596@birch.elegosoft.com> References: <20071230162432.C498A10D4596@birch.elegosoft.com> Message-ID: "where to root archives?" Maybe this is along the lines of "how to format my code?" Religous and unanswerable and strong proponents of every answer? but: A) *.zip|*.tar.gz|*.tar.bz2 shall be named cm3.* or B) cm3-.* ok, no question here, B is it. And shall contain the structure: 1) more than one file/directory at the root bin/cm3(.exe) pkg/libm3/... or 2) root contains only one directory, and it has a version in its name (and target probably) cm3-/bin/cm3(.exe) cm3-/pkg/libm3/.. or 3) root contains only one directory, with no version in its name cm3/bin/cm3(.exe) cm3/pkg/libm3/.. #1 is what the current cminstall-using distributions use I believe.Since it is wrapped by an installer, doesn't really matter.Note though that the enclosing archive is also formed this way I think, but with fewer than 10 files. It seems clearly the worst, unless you know about the tar -C or unzip -d switches, though tar -C doesn'tcreate the output directory, unzip -d does. #2 is VERY popular and tempting for me #3 is what the Win32 builds use currently (scripts/win/make-dist.cmd) It has the advantage of being more directly useable. cd \ unzip cm3-.zip and it goes into \cm3, a reasonable default, but could be preexisting (unzip does prompt I think) If it went to cm3-version, you'd probably want to either rename it, or create a link to it, Window having varying support for different types of links on different versions, not sure if use is widespread. fsutil hardlink create creates file hard links on XP+ mklink creates hardlinks and symlinks on Vista+ probably only file hardlinks and file or directory symlinks At some point, directory links were avoided because a) not required by Posix? b) allows creating cycles I see cycles now on my default installs and have crashed stuff as a result. :( junction from www.sysinternals.com creates directory linkes on...Win2000+? (This is all NTFS only of course, or over SMB to other file systems; actually stupid fsutil demands a local file system, even though underlying CreateHardLink works over SMB..) #2 seems safer, and user can immediatley rename to #3 after extraction. Oh, and in the Explorer GUI, the default is to extract in a directory with the same name as the basename of the archive.That makes #1 slightly better and the others slightly worse. Inevitably it seems the command line is doomed to always check before extracting anyway.. unzip -l foo.zip | more tar tfz foo.tar.gz | more Besides that, it still impresses and bugs me how much smaller .tar.bz2 is vs. anything else...but the Explorer support or .zip filesis also somewhat compelling...except that you have to use the command line with CM3 anyway.... - Jay _________________________________________________________________ The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console. http://www.xbox.com/en-US/hardware/wheretobuy/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Dec 19 04:30:19 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 19 Dec 2007 03:30:19 -0000 Subject: [M3devel] Unix signals and Modula-3... In-Reply-To: <200712182343.lBINhJDL084804@camembert.async.caltech.edu> References: <200712182343.lBINhJDL084804@camembert.async.caltech.edu> Message-ID: The system threads pthread implementation uses a signal and a semaphore to stop/start threads for GC, Other than that, I don't believe signals are being used anywhere else in the run-time system. Also, I should point out that there may be value in retaining the current user-level threads implementation for all targets (we still need to fix some to use setcontext/getcontext instead of setjmp/ getjmp), in which case the same issue applies. I wonder if it makes sense to implement a variant of waitpid inside the threads implementation to do the right thing. We could use a signal there to catch SIGCHLD appropriately in the ThreadPosix implementation and leave it alone with ThreadPThread. What do you think? On Dec 18, 2007, at 6:43 PM, Mika Nystrom wrote: > > Ah yes, you are right. The original issue is that waitpid would > hang the whole runtime and that should not happen with system > threads. If using system threads, waitpid should be called with a > third argument of zero, I believe. Is this already happening? > If not, make the change and if you have a fast machine you may > see a spectacular speedup in your compile times. > > I suppose the easiest solution to this problem is simply to move > all active targets to system threads... > > Still, there are some other areas where Unix signals might be of > interest. I am thinking of things like interfacing with readline > and other C-based libraries that use signals for concurrency. When > I put a readline interface on some Modula-3 programs, I wound up > using an external C program to do readline processing and then > communicating over a pipe or TCP connection, because dealing > with signals seemed like such a hassle. > > Mika > > Tony Hosking writes: >> I'm assuming that waitpid hanging when using system threads is not a >> problem, since the system thread scheduler will schedule other >> threads around the waiting one. The issue is only for the user-level >> threads implementation where a thread blocking on a waitpid call >> would prevent other threads being scheduled. >> >> On Dec 18, 2007, at 7:38 AM, Mika Nystrom wrote: >> >>> Hello everyone, >>> >>> I am in the process of bootstrapping the CVS head of CM3 on an old >>> FreeBSD-4.11 system, and at one point, when I replaced the old cm3 >>> with the new cm3, the compiler got slower. Not a little bit slower, >>> mind you, but about 10x slower. I remember pointing this out to >>> the m3devel list... oh it must have been three or four years ago; >>> one of our grad students at Caltech (Karl Papadantonakis, also >>> author of the caltech-parser) was the first to notice what was going >>> on. >>> >>> It has to do with Process.Wait. (From ProcessPosix.m3.) To repeat >>> what I said a few years ago, the problem lies here: >>> >>> CONST Delay = 0.1D0; >>> BEGIN >>> IF NOT p.waitOk THEN RAISE WaitAlreadyCalled END; >>> p.waitOk := FALSE; >>> (* By rights, the SchedulerPosix interface should have a WaitPID >>> procedure that is integrated with the thread scheduler. *) >>> LOOP >>> result := Uexec.waitpid(p.pid, ADR(statusT), Uexec.WNOHANG); >>> IF result # 0 THEN EXIT END; >>> Thread.Pause(Delay) >>> END; >>> <* ASSERT result > 0 *> >>> >>> In other words: if Process.Wait is called before the child process >>> is done, then the thread pauses 0.1 seconds. >>> >>> In our local version of m3build, we duplicate the Wait code and set >>> the Delay to 0.0. That's OK in a compiler, but it's not OK in >>> general, because you would chew up the CPU on a machine that was >>> doing a lot of long-term waiting. >>> >>> The problem is that the fix that I suggested way back when requires >>> messing with Unix signals (catching SIGC[H]LD instead of using >>> waitpid), which is why I never submitted a fix to the repository, >>> because I am not sure what such a fix might interact with. It seems >>> to me that the correct way of dealing with Unix signals is to have >>> a single thread that talks to the Unix system, registers signal >>> handlers, and takes care, via some object-oriented mechanism, of >>> calling back any M3 threads that are interested in the signals. >>> Would such a thing be possible? Where are signals used in the >>> system today? >>> >>> Mika